nDiki : 2005年10月19日

コミットメント・リスト vs ガントチャート

会社の人が市販のガントチャートソフトウェアを購入して、現在本格導入を検討しているとのこと。

 社内にはコミットメントをコアにした管理手法もあり、
 その優位性は十分に認めている。

 しかし、単純にガンチャートがすきなのである。
 特に見た目、がね。

 — GAKUさんの日記 「これは好みなのだ」 2005年10月18日 13:10 より

とのことだ。 コミットメント・リスト派とはまさに私の事である(多分)。 いい機会なので自分の中でも、コミットメント・リストとガントチャートについて整理しておこう。

ここで言うところのコミットメント・リストというのはすごい会議で紹介されているものである。

ちなみに私はプロジェクトマネジメントについては教育を受けたこともないし、明確な手法を導入したプロジェクトマネージャーの下についたこともない。 「ガントチャートは駄目」だとも思っていない。 以下は試行錯誤を繰り返している中での現在の私見である。

どちらも特徴・欠点があり適材適所(と好み)があるのだと思う。 両方同時に使っているケースもあるであろう。 またこれらは一つのツールであるから、本来はもっと上位の管理手法まで議論しなければならないであろう。

モデル

コミットメント・リストでは「期日」という点で「成果」をリスト化する。 一方ガントチャートでは「期間」という点で「作業」をリスト化する(たいがい)。

• 作業時間がある程度精度よく見積もれる
• 作業時間と成果が比例的である

であるような場合はガントチャートで計画しやすい。

逆に言うとそうでない場合は、コミットメントベースの方が合っているように感じる。

ガントチャートを利用したマネジメントの特徴

• マネージャーからのトップダウン的なスケジュール向き
• リソースの多重度を把握しやすい (本来はかけもちさせない方がいいと思うが)
• 比較的多人数のチームでもいける
• リソースがタスクに時間を割く割合を設定できる (やろうと思えば)
• 人月計算/コスト積算できる
• プロジェクト外からの割り込みの発生によって狂いやすい
• 成果がみにくい
• チェックしにくい
  • 「進んでますか?」「はい作業中です」「どれぐらい?」「うーん、30%ぐらい」
• ぱっと見、計画できている気がする
• 期間が長いと、チャートが見にくくなる
• 1日単位で見積もりたくなる
• 休日が気になりだす

コミットメント・リストを利用したマネジメントの特徴

• 担当の裁量を尊重・重視
• コミットメントのクロスチェックがしやすい (コミットメント、メジャーメントの明文化)
• 期日前にせっぱつまりやすい
• 依存関係が複雑だと把握しにくい
• 専用のソフトウェアがなくても可能
• 他のプロジェクトと兼任しているリソースの稼働状況がわかりにくい
• 線表派からみると計画だと思ってくれないかも

自分がガントチャートでうまくいかなかった点

ソフトウェア開発で線を引いてみたときの感想

• スケジュールの変更があった時に面倒
• 現状とあわなくなってくるとだんだん見なくなった
• 結局だんだんメンテナンスしなくなってしまう
• 進捗チェック時に、ガントチャートで○○%と入力しても適当で意味がなかった

コミットメント・リストでうまくいっている点

• 成果が達成できているか、そうでないかが明確
• 達成できていないコミットメントのチェック、フォローができている
• 担当自身が忘れていたコミットメントもクロスチェックで再認識できる
• コミットメント一つ達成するたびに「いい気分を味わえる」

まとめ

現在自分がマネジメントしているような、ソフトウェア開発の含まれる少人数体制のチームではコミットメント・リストベースがかなりイケているように思われる。

必要であるならば適応型ソフトウェア開発にあるような、タイムボックス(サイクル)を設定してコンポーネントを割り当てる形で長めの計画をコミットすればよいであろう。

ガントチャートは、それこそ「依存関係のある工程が順番に進んでいく」「クリティカルパス重要」のようなプロジェクトにはいいんだと思う。 自分が扱っているプロジェクトがそういうものではないのだなと。