nDiki : トム・デマルコ

トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解

今年の1月からプロジェクトマネジメントをいくつか担当することになったのだが、まだまだ経験不足。 ということで遅ればせながら、「ゆとりの法則」を読み始めた。 誤った方向にマネージメントを進めていく前に手に取ってよかった。

社長からの「何をやっていいのかわからないスタッフがいるのでどんどん指示を出して、遊んでいる時間(指示待ち時間)を作らないようにして欲しい」というリクエストに違和感を感じていたのだが、この本の中にはその違和感が何かが説明されているようだ。

「適応型ソフトウエア開発」でも管理するのではなくリーダーシップをとってコラボレーティブにプロジェクトを進めていくといったような事が書かれていたと思う。

頭では理解しているのだがなかなか実践できない。 プロジェクトのスケジュールをにらみつつ、またチームをまとめつつ意思決定を下していく技術を身につけなくては。 一技術者としての能力を向上も忘れずに。

• ゆとりの法則

---

[ 読書ノート ] [ お薦めの本 ] [ コンピュータ書籍 ]

トム・デマルコ ピープルウエア 第2版 - ヤル気こそプロジェクト成功の鍵

[ コンピュータ書籍 ]

先月読んだゆとりの法則に引き続き、トム・デマルコ2冊目。

• Peopleware

片道1時間以上電車に揺られるところまで打ち合わせに行くので、その間に読もうかと出かける前に書泉へ行って買ってきた。

トム・デマルコ / ティモシー・リスター 熊とワルツを

来週の移動中の読み物として買っておく。

• 熊とワルツを - リスクを愉しむプロジェクト管理

第2章 リスク管理はおとなのプロジェクト管理だ

チーム・リーダー 「この件については明日会議を開きますが、事態は悪化しそうです」

プロジェクト・マネージャー 「では会議をやめよう」

(熊とワルツを p.15)

新幹線の中で読む。

いつもながらトム・デマルコの著書は明快。 普段プロジェクトではっきりとしないけれど何となく心にひっかかっているものが、しっかりと書かれている。 素晴しい。

私的10大ニュース2004 [ work ]

今年の大事件、マイブームなど。

プロジェクトマネジメント

入社して満3年。今年は随分仕事の内容が変わってきた。 トム・デマルコの本を読んでみたり。 事後評価セッションを実施してみたり。

サーバ移行

DNS サーバ、メールサーバ、Web サーバを一斉入れ換え。Debian GNU/Linux に移行。 RAIDではまる。

RAIDまわりが何かよろしくないようだし、ホスト自体以前デスクトップとして使っていたPCなので安定したものに置き換えたい。

飲み会

現代の経営(上)読了

P.F.ドラッカーの「現代の経営」を読み終えた。

1954年出版ということで冷戦時代背景における論調の内容があったりと多少違和感があったりする部分もあるが、本質の部分はもちろん健在。

内容的には比較的大きな企業の上層クラス向けに向けられた感じがする。 経営書としては当然なのだが企業中心の視点ということで、自分の立場としてはやはりすっきりしない部分がある。

文章もかたい感じ。図もないし、箇条書き化もほとんど無い。

明快で人をより重視しているトム・デマルコの著書の方が自分にあっていると思うのは、やはりソフトウェア屋だからか?

1度読み通したけれど、ドラッカーの言いたい骨子をまだ掴み切れていないようだ。 いつかもう一度ゆっくり読み直す必要があるな。

• 現代の経営

---

[ 読書ノート ]

今日のさえずり: 東京トイレマップとか懐かしすぎる

2011年06月07日

• 08:50 World IPv6 Day 今日と勘違いしてた。
• 12:43 トム・デマルコのデッドラインが読みたくなったので上のフロアにいったらあったら本棚にあったので借りてきた。第2版じゃないけど、そんなに変わらないよね?
• 12:43 RT @mixi_engineers: Let's 検証！ - iPad 2カバーに秘められた恐るべき陰謀を暴く - http://alpha.mixi.co.jp/blog/?p=2949
• 13:40 iPad 2 午前中に配達完了になってる。今日は定時で帰りますよ。
• 13:49 チキンフィレオセットS 490円。 (@ マクドナルド 南青山店) http://4sq.com/kI6d6h
• 15:22 東京トイレマップとか懐かしすぎる。
• 15:26 東京トイレマップって、Webやぎの目/デイリーポータルZの林雄司氏のサイトだったのか。
• 15:56 分類器って書くとなんかカッチョ悪いな。しかし日本語文中に classifier って書くのもアレだし。
• 17:08 @yakifumi Apple 製品初めてなので楽しみです。 iOS 5 になると母艦不要というのが良さそうですね。
• 19:13 ザ・退勤。
• 19:23 ん、この山手線の蛍光灯、青味が強いぞ。
• 20:55 まずは iTunes ダウンロードしてる。
• 21:00 今日配信の「週刊フレッツ vol.401」、World IPv6 Day については一切触れず。
• 21:01 RT @matsutakegohan1: 占い師に占ってもらった。僕の恋愛対象は二年後に中国かマレーシアかインドネシアの二十代前半の女性らしい。何もわかってない若い子を教育しないと無理と言われた。まじか。
• 21:04 同梱のちっちゃな紙に書かれた URL にアクセスして、目についた[今すぐダウンロード↓]を押して落ちてきたのを実行したら「おまえ64bit だろ。おれじゃねえぜ。」的なダイアログを出されて涙。
• 21:26 iPad 2 きた。 http://flic.kr/p/9RcWo8
• 21:26 注文した時に作った Apple ID 入れたら「まず My Info Web page にログインしなよ」と。
• 21:34 また質問と回答考えなきゃならないの。
• 21:41 また「Apple ID を作成しましょう。」ってでてきた。
• 22:17 iPad 2 に back ボタンが無いのに慣れるまでどれぐらいかかるのかな。
• 22:26 とりあえず Twitter 公式クライアントをインストールした。

インターンシップ制度を受け入れたチームメンバが個人として期待するといいんじゃないかと思うこと

インターンの方が配属されるとチームが賑やかになるとともに、チームメンバの皆さんも忙しくなりますよね。就業体験型のインターンシップでは、ほとんどの場合ふだんの業務を抱えながらインターンの方をフォローすることなるので大変かと思います。

新しい人が配属された直後はチーム/個人の生産性が落ちるという話はトム・デマルコ氏の本を読むまでもありません。フォローをしている間は自身の担当業務ができなくなるので個人的な生産性は落ちることがほとんどでしょう。ここはトレードオフとしてチーム全体で受け入れるべきだと思います。

さて会社・人事・部署それぞれに期待するところがあってのインターン制度ですが、個人では何を期待していけば良いのでしょうか。

インターンシップ制度に個人として期待するといいんじゃないかと思うこと

インターンの方に良い就業体験を提供できるようにしていく一方で積極的に自身でも学んでいきたいと私は思っています。目新しいところはありませんが、個人レベルでは以下のような点を期待するといいのではないかなと考えています。

人に教える事による自分自身の学び

人に教えようとすると「あれっ?」となることは仕事に限らずあると思います。私は説明するタイミングであらためて用語の定義を確認しなおしたり、手順をドキュメント化したりしてみています。

インターンの方の得意な分野からの学び

インターンの方の研究テーマや人生経験などから、学べることはいろいろあると思っています。ですので「この人面白いことやってそう! チームとしても学びがありそう!」という方に来ていただけるようにできるだけしています。

インターンシップ期間中はチーム内 LT をしてもらったり、ランチで話をきかせてもらったり、あるいは自分の知らないような工夫点を業務時間中に教えてもらうようにしています。

また、私が社会に出て働き始めた頃に担当したインターンの方はその後しばらく一緒に仕事をすることになりました。別々の会社になった今でもばったり再会して情報交換させてもらって学ばせていただいています。そういうのもいいものだなと思います。

間接的な学び

今は直接インターンの方についたりはしていないのですが、どのような就業体験を提供できるのかを考えたりこういった記事をまとめてみたりと、どの立場でも取り組んで学べることはあるなと思っています。

インターンの方にとっても自身にとっても、短期的な利得よりは長期的にみて良い成長の糧となればいいのではないでしょうか。

---

[ opinion ]

第3回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会3回目。今日は第3章 アジャイルの原則。

原則を語るにしては計画駆動との対比が多く、ちょっと読後感がすっきりしませんでした。「アジャイルの原則」の章なのにスクラムの話しか出てこないのもちょっと残念でした。スクラムにおけるアジャイルの原則という章だったら気にならなかったんですけどね。

イテレーティブとインクリメンタルの話のところでは

スクラムでは、イテレーティブな開発とインクリメンタルな開発の両方の利点を活用する。そうすることで、両者を個別に用いる際の欠点を無視できるようになる。

とさらりと書いてあるのですが、これは参加者でも引っかかっている人がいましたし、私もちょっと釈然としませんでした。両方の利点を活用するという点は良いのですが、欠点を無視できるようになるというのは説明しきれていないなと。

「3.3 予見と適応」では

コミットメントを先延ばしにし、重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。

とし「判断することのコスト」曲線と「判断しないことのコスト曲線」が交わる最終責任時点がその瞬間であるとしています。主張は理解できますが、結局この曲線が明確になることは無いですし結局勘に頼らざるを得ないと感じました。

アジャイルの原則自体はしっかりしたものだと思っているのですが、この章ではそれがうまう伝わってこない気がしました。

WIP にまつわる話

作業者の手持ちではなく、作業の手持ちに注目せよ

は、あらためて思い返すことが出来て読んで良かった点です。この話はトム・デマルコの「ゆとりの法則」でも言われていることで再認識することができました。

• ゆとりの法則

「稼働率」と「フロータイム」「リードタイム」「WIP」のあたりは製造業だとメジャーな話ですがソフトウェア開発においては、それほどは話題にならない気がします。

勉強会でも、腑に落ちない人が多かったようです。空いた時間はもったいないので他の仕事を着手した方が無駄がないんじゃないかとつい考えてしまいますよね。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド