モデル・ギャラリーって何処かにない？

　とある講演録を読んでいたら、ミュージシャンも他人の曲を聴いて、真似て弾くことを繰り返してうまくなっていくように、モデリングも優れた教材を真似して試してうまくなるはずなのに、いい教材がない、という意見があった。（渡辺さんのBlogにもありますが）
　モデル・ギャラリーは何処かにないのだろうか？
　
　僕がイメージするモデル・ギャラリーは、DOAやOOAという技術レベルではなく、業務に特化したモデル群。小売、製造業、金融、医療、などの業界で頻繁に出てくる業務フローをモデル化したもの。
　そして、そのモデルは、システムとして落とせるものでなくてはならない。業務用語だけの話で閉じているだけでは、ITエンジニアとして無意味だから。
　となると、本でもインターネットでもなかなか見つからない。

　すぐに思い浮かぶ本はアナリシスパターン―再利用可能なオブジェクトモデル」。しかし、難しくて読みにくい。
　最も読みやすく役立ちそうな本は、渡辺さんの本生産管理・原価管理システムのためのデータモデリング」ぐらい。この本の最後にある会計の章は、DOAの観点から説明されていて、非常に分かりやすい。他の会計の本は、経理屋の視点から書かれているので、モデルへ変換するのに手間がかかる。

　最近、面白そうだと思うのは、モデリング道場ML。
　2ヶ月前に「『酸っぱいブドウの論理』と『甘いレモンの論理』」を題材としてモデルに書いてみる話題があった。こんな話をモデルにできるのか？と疑問に思っていたが、その時の児玉さんのコメントが面白い。
　この現象は心理学でいう認知的不協和に当たるそうだが、似たような話として、

「UFOがX月X日に降りてくると大々的に宣伝していた団体が，その日に降りてこなかったという事実を突きつけられて，その団体のメンバーはどのような行動を取ったか，なんて心理学の授業で教わりませんでしたか。」

と。その答えは、他のアーカイブにあります。面白すぎ(^^)

IT業界は残業が多いのですか？

　今日、母校の大学へ会社説明会に行ってきました。
　3回生の人から
「IT業界は残業が多いと聞いたのですが、本当ですか？」
と尋ねられて、返答に正直困りました(^^;)
　この業界のビジネスマンは、後輩から上記の質問をされた時、どのように答えているのだろうか？

　僕の少ない業界経験では、1年に1回は修羅場が津波のようにやって来る。終電帰り、休日出勤、徹夜の開発が1ヶ月くらい続いて、本番システムリリース後、ようやく落ち着いて元の生活に戻る。初めて徹夜で作業させられたときは、皆さんこんな安月給でよく仕事しているなあ、と他人事のように思っていた。

　この業界、1ヶ月200時間労働なんて当たり前。
　はぶさんの本
では「月40時間程度の残業が3ヶ月続いたくらいで過労死なら、この業界の人間90%は死んでいます」と書かれていますが、同感。
　青色ダイオードの中村修二さんは、その業績にもかかわらず低収入だったため、「スレイブ中村」と言われたそうだが、IT業界で働いている人達も奴隷と言われても仕方ないのかもしれない。

　学生さんには、「確かに残業する時はありますが、普通は1時間程度の残業で退社できますよ」とかわしておいたが、最初から最後までそんなプロジェクトは滅多にない。
　学生さんにこれだけIT業界の評判が悪いと、今後、優秀な頭脳はこの業界に入って来ないかもしれない。

＃余談ですが、最近の日本に犯罪が多いのは、日本人男性の働きすぎに原因があるんじゃないかと思う。
＃つい20年前までは、こんなに残業して働いている人はそんなに多くなかったのでは？
＃親子夫婦そろって朝ご飯、夕ご飯を毎日取っている日本人の家庭って、今の日本に存在するのだろうか？
＃多分、存在しないと思う。
＃殆どの日本人の家庭は壊れていると思う。多分、普段は母子家庭になっている。最近は共働きが主流だから、たまたま一つの住居に住んでいるだけで、皆バラバラに生活していないか？
＃そんな生活は人間的（むしろ、本能として自然）なのだろうか？　子供の成長にとって悪い影響しか与えていないのではないか？

　経営者だけでなく、現場のエンジニアも今の環境を改善していくことを考えないと。

プロジェクトの危険信号は会議で分かる

　プロジェクト管理者になって、ミーティング（会議）が多くなり、また自らミーティング（会議）をコントロールする必要性が出てきたが、＠ITの記事「プロジェクトの危険信号は会議で分かる」を読んで、プロジェクトの成功率とミーティングの時間は反比例することを改めて実感した。

　僕の過去の経験からして、ミーティング（会議）が1時間を軽く越えるプロジェクトは失敗している。成功したプロジェクトは、どんなミーティングも30分以内に終わった。だから、基本的にミーティングはなくてよいか、あるいは30分以下で十分と思う。

　そもそもミーティングや会議を開く理由は何なのか？　開発者一同を集めて説明したり、利害関係者を集めて承認を得るプロセスは無駄。
　開発者には各々その時々に応じて説明すればいい。開発者はプロジェクト全体の動向を知る必要なく、課せられたタスクをスケジュール通りにこなしてくれればいいから。
　利害関係者を一同に集めたとしても、その場で生産的な結論に至ることは稀。むしろ、お互いの利害の観点から眺めた問題提起を頂くぐらいしか利点がない。それは個別にメールで尋ねれば十分。

　とはいえ、会議はやはり存在し、議事録を取る作業を初めてやったのだが、そこで大事なポイントは2つあるように思う。
　一つは、会議で決定した内容をリストアップすること。その意味は、議事録が後でメールで渡されると、その時点で議事録の内容は全関係者でコミットされたという事実に変わるから。当たり前のことだが。
　もう一つは、次回延期になった議題の納期と担当者を明示すること。これによって、次回の会議の議題が少なくとも1つ以上は決まったことになる。その担当者が納期までに解決できなければ、それなりの理由を説明せねばならなくなる。だから、担当者欄に書かれると、次回の会議では緊張感あふれる雰囲気になりやすい。
　
　とある勉強会で、更にもう一つ指摘を受けたことは、目的と達成度を書き記すこと。
　会議はどうしてもダラダラなりがちゆえ、時間と人員というリソースを結構無駄に使うときが多い。だから、当初の目的を明確にすること、そして目的がどれだけ達成されたのかという目安を書き記すと、会議の生産性が一目で分かる。
　実際にやってみたら、達成率が50%を超える項目は半分以下だった。反省(^^;)
　でも、全ての項目で達成率が100%なら、会議をやる必要はない。事前のメールで十分だから。
　故に、会議の生産性と達成率は何らかの関係があるかもしれない。

　会議とは関係ないが、今のプロジェクトでは朝礼と夕礼をやっている。朝礼でその日にやる作業をメンバーから聞き出し模造紙にリストアップして壁に張り付け、夕礼でその結果を聞くだけ。メンバー全員が起立したまま10分ほど集まるだけなのだが、これだけでプロジェクトが結構うまく回る。
　平鍋さんの朝会ガイドに似ているが、平鍋さんのやり方の方がノウハウが多いので非常に参考になる。例えば、メンバーが話しやすい雰囲気を作ることとか、話が脱線しないコツとか。
　
　この辺りのノウハウは、XPやアジャイルの方がはるかに洗練されている。チームビルディングのプロセスは、アジャイルが得意とする分野ではなかろうか？
　プロジェクト管理者の仕事は、スケジュール管理も大事だが、ミーティングのコントロールも大事であることを再確認した。