ITのシステム開発プロジェクトはなぜ遅れるのか？プロジェクトの本当の目的とは

こんにちは。

 

長年ITのシステム開発プロジェクトに関わっている方、デスマ（デスマーチ：死の行軍）を経験したことは一度や二度ではないはず。

先の見えないトンネル。

現場のメンバの疲弊感。

中には鬱（うつ）になって辞めていく人も。

デスマになっても何もいいことはありません。

 

誰も好きでプロジェクトを遅れさせている訳ではないのにも関わらず、気づいたら遅れています。

そもそもITプロジェクトはなぜ遅れるのでしょうか？

 

いつもは糖質制限の話をしている私ですが、今日はITのシステム開発プロジェクトが遅れる原因を分析し、問題を明らかにしてきます。

 

こんな楽勝なプロジェクト、遅れるはずがない

次のプロジェクトを想定します。

 

既存のシステムのプログラム改修。

ただし、話の単純化のために仕様書作成、テスト実施、改修前後の比較書類作成などを含まず、プログラムの修正作業のみとする。仕様変更もないものとする。

 

改修箇所は１５箇所。

そのうち、軽微な改修が１２箇所。正味の見積もり工数はそれぞれ１時間〜半日。

リスクを見込んでも、十中八九、一日あれば十分。

残り３箇所においても、それぞれ正味の見積もり工数はせいぜい１〜２日。

リスクを見込んでも、十中八九、３日あれば十分。

 

改修作業を担当する技術者はこのシステムに精通しており、技術レベルは十分なものとする。

 

１２機能×1人日＋３機能×３人日の、合計２１人日の作業工数でお客様とは合意している。

 

こんな楽勝なプロジェクト、遅れるはずがない、と思いますよね。

このプロジェクト、どのように進めていきますか？

まずは、単純にこんな感じでスケジュール作成するとしましょうか。（土日は考えないものとします）

 

ひとつひとつの作業、それぞれ余裕（バッファ）を含んでいるため、こんなざっくりした感じのスケジュールでも遅れるはずがないと思いますよね。

でも、遅れます。

なぜか。

 

よくある話としては、

• 担当者が風邪などの病気で休んだ
• ３日と見積もっていた作業が、実際には５日かかってしまった

ありがちな話です。

 

人間がやる以上、上の例のような不確定要素は考えておかなければいけません。

仕様変更ならお客様に費用負担の請求ができます。

しかし、病気や見積もり精度が低かったことは、自分たちでそのリスクを許容し、費用を負担しなければなりません。

 

見積もり時間と実際の作業時間のずれかた

そもそも見積もりっていうのは、見積もりであって、確定ではありません。

しょせん、この作業はこのくらい時間がかかるだろう、という程度の確率論でしかありません。

実際に見積もり以上に時間がかかることもありますし、見積よりも時間がかからなかったということもあります。

 

もう一度、先のプロジェクトの前提を確認しましょう。

• 改修箇所１２箇所について見積もり工数はそれぞれ１時間〜半日、十中八九1日あれば十分
• 残り3箇所について見積もり工数はそれぞれ1日〜2日、十中八九3日あれば十分

それを図にするとこうなります。

 

 

見積もり上、十中八九、1.0日で終わる作業っていうのは、結局、実際には1時間で終わることもあれば1日以上かかることもあり、おおむね0.5日で終わる確率が最も高く、1日で終わらない可能性も1割程度ある作業ということです。

見積もりが十中八九３日で終わる作業についても同様。

 

これ、多くの人が見積もるとき、

「たぶん0.5日あれば十分だろうけど、余裕を持って、1.0日にしておこう」

と、各作業に本能的に余裕（バッファ）を含んで見積もるものです。

このように、見積もりに余裕（バッファ）を含んでいるのに遅れてしまうっていうことが、この議論における問題提起です。

このような余裕（バッファ）を含まない見積もりについてはこの議論の対象外です。

 

見積もりのずれをスケジュールに反映できないのが問題

この見積もりに含んだ余裕（バッファ）を、スケジュールに考慮しないのが最大の問題です。

 

いま、見積もり工数1.0日の作業が３つあるとします。

普通、スケジュールを作成するときに、この３つの作業を一日毎にならべます。合計３日で作業するスケジュールになります。

 

でも実は、見積もり1.0日とは、「おおむね0.5日で終わる確率が最も高い作業だが、0.5日の余裕（バッファ）もたせ、1.0日とした」、というものでした。

そこで、各作業ごと、本当の見積もり時間と余裕（バッファ）に分けてスケジュールに並べてみます。

一日ずつ、余裕（バッファ）が含まれているのが分かります。

余裕（バッファ）が有ることから、担当者は毎日午前中に作業完了させて午後に遊んだりしはじめます。しかし、スケジュール上は遅れなしとなります。

 

さて、このとき、３日目の作業が実は、1.0日で終わらずに、1.5日かかってしまったらどうなるのでしょうか？

３日目に遅れ発生になってしまいます。

それは、１日目と２日目に遊んでいた罰なのでしょうか？

実は、担当のITエンジニアが優秀であればあるほど、起こりえる話なのです。

この理由は後ほど。

 

では、この場合、スケジュールはどのようにすれば良いのでしょうか？それはこうです。

工数1.0日の各作業には余裕（バッファ）が含まれているため、その余裕（バッファ）だけを取り出します。

そしてあとに余裕（バッファ）だけを並べてやればいいのです。

こうしておけば、３つ目の作業が実際には1.5日かかるものだったとしても、あとに取り出した余裕（バッファ）を使って３日間のスケジュール内で作業を完了させることが出来ます。

優秀なITエンジニアは細切れのバッファを浪費する

実際にスケジュールしてみよう

ではこの考え方を、先に想定した15のプログラムを改修するプロジェクトに適用してみましょう。

 

各作業ごとに含まれていた余裕（バッファ）を取り出してひとまとめにします。

すると、作業工数は10.5日、余裕（バッファ）は10.5日になります。

そこで、作業工数10.5日を目標として完成を目指し、残りの10.5日は余裕（バッファ）にしておくことで、もし、見積もり工数よりも実際の工数がオーバーしてしまった場合や担当者が体調不良で休まざるを得なかった場合であっても、余裕（バッファ）の分でカバーできるというわけです。

いいことだらけですね。

 

で、問題はここからです。

はじめに作成したスケジュールを覚えていますか？これです。

 

これまで述べてきた考え方を、このスケジュールに落とし込んでいきましょう。

こうします。真面目に言っています。

 

こんなのはスケジュールとは呼べない、という批判が来そうです。

そういう批判をする人は、こんなスケジュールを作ってしまいそうです。

 

いやね、分かるんですよ？WBSとかガントチャートとか呼ばれるツールと工数を連動させるからこんな風にせざるを得ないっていうね、そういう意見があるのも承知しています。

でもそれが本質的な問題ではありません。

 

見積もりってなんだっけ？

見積もり1.0日の意味を再確認しましょう。

実際には1時間で終わることもあれば1日以上かかることもあり、おおむね0.5日で終わる確率が最も高く、1日で終わらない可能性も1割程度ある作業

のことでした。

 

では、上のスケジュールで、もし、プログラム１とプログラム２の改修作業が両方とも１時間で終わっちゃったらどうするのでしょう？

その日はもう、作業、終わり？

いや、ひょっとしたらプログラム３の改修が1.0日以上かかるかも知れないので、遊んでないで、すぐにプログラム３の修正作業に入らないといけないですよね？

 

見積もりなんていうのは、作業をやる上では基本的に当てになりません。

だから、作業が早く終わってもすぐに次の作業にとりかかって、見積もりをオーバーするかもしれない作業へのリスクに備えるために、無駄な時間を排除すべきです。

その無駄の最たるものが

「あー、今日のノルマ達成したから、もういいや。後は遊ぼう。」

っていう時間です。学生症候群の一種かも知れません。

 

上の「ダメなスケジュール」であっても、一見、無駄が排除されているように見えます。しかし、実は、それに合わせてやっぱり「今日のノルマ達成」となり次第、遊び始めるのです。

なぜ?私がそうだから。

 

でもこれ、優秀なITエンジニアの、普通の特性です。

空き時間を見つけて、趣味のプログラム有用なツールを作り出したりすることはしょっちゅうやります。

 

では、なぜ優秀なITエンジニアはこんなことをしてしまうのでしょうか？

 

仕事を早く終わらせることに対するインセンティブが働かない日本の企業

見積もりが21.0日の仕事を実際は10.5日で終わらせた場合、多くの日本の企業ではそのITエンジニアをどのように扱いますか？

ほとんどが次のパターンです。

• 「見積もりが甘かったんだ、楽な仕事だったね」とされて、むしろ評価が上がらない
• 問答無用で次の仕事を押し付けられる、が、評価は上がらない

こんなの、馬鹿らしくなって、まともに仕事しやしませんよ。

 

ITエンジニアってその能力によって最大１００倍効率が違うなんてよく言われます。

能力によって、作業時間に違いが出るのは当たり前なんです。

その能力の評価が出来ないから「見積もりが甘かった」なんて結論になるのです。

じゃあ作業実績が見積もりをオーバーしたら「見積もりがダメだった」という結論になるのですか？

違いますよね。

担当者の能力不足だった、なんて言われたりしますよね？

 

こんな不条理に付き合う人間はいません。

だから、ITエンジニアが優秀であればあるほど、仕事をやっているふりをしてテキトーにスケジュール通り進んでいるように見せかけるんです。

で、空き時間を作りだして、遊んだり勉強に当てる、と

 

そもそも、仕事を早く終わらせれば、その分原価が下がって、利益が増えますよね？

だから、作業っていうのは無駄を排除して出来るだけ早く終わらせるべきなんです。

それを評価しなくてどうするの？っていうことです。

利益を出さなくていいから別に遊んでていいよっていう企業は別ですが。

 

スケジュールは誰のため？

WBS（Work Breakdown Structure）とかガントチャート（以下WBSで統一）で漫然とスケジュールを立てていることにも問題があります。

 

たしかに、WBSはメリットがあります。

• 顧客から見てわかりやすい
• プロジェクトメンバの意識を統一させることが出来る
• 作業の洗い出しをきっちりやることで作業の漏れを防止できる

とか、他にもいろいろあるでしょう。

 

そのスケジュールって誰のためのものですか？

それで利益が出ますか？

 

最大の目的は利益を生み出すこと

WBSはメリットが多く、確かに、WBSなしで仕事を進めるのは難しいでしょう。

しかし、WBSを重視するあまり、仕事をスケジュール通りに終わらせることが目的になってしまうのが一番の問題です。

 

考えなければならないのは、利益を出すためにどうするか、です。

そのためには、各作業に組み込まれた余裕（バッファ）を取り除き、それを作業遅延のリスクと利益のための貯金としてまとめておかなければなりません。

「今日はノルマを達成したから、今日はあとは遊ぼう」という意識を完全に排除するのです。

 

だから、「このダメなスケジュール」

 

ではなく、こっちの「余裕（バッファ）を意識したスケジュール」

を提示して、各作業に組み込まれた余裕（バッファ）を徹底的に排除し、余裕（バッファ）を後にまとめておくという意識づけが大事になってきます。

 

スケジュールを守るのことが目的ではなく、システムの価値を高めながら利益を出して事業の永続化を目指すのが本来の目的なのですから。

 

どうしても、こんなスケジュールのあらわし方は許せない！という場合は

こんなふうでも別にいいですけどね。

 

まとめ

ここまで述べてきた内容では、ITプロジェクトを単純化し過ぎていてそのまま当てはめることは出来ない、という反論はあるでしょう。

そうではなくて、ここまで単純にしたプロジェクトでさえ遅れることがあるという、ITプロジェクトの作業の不確実性を問題にしているのです。

 

さて、物事を突き詰めて考えたり発想を転換させたりして、一度常識を疑ってみるというのは、物事の本質を見極めるためには必要な作業です。

私は一度、ITプロジェクトにおいてWBSなんて完全に必要がない、と仮定して考えを巡らせたことすらすらありますし、実際、ウェイトは低いです。

しかし、これまでの常識にとらわれて、WBSを盲信しているITプロジェクトのリーダ、マネージャも中には存在します。

そのことは、これまで炭水化物が人間に必要な栄養素であるとかケトン体は害であると信じられてきた医学界の常識が覆されつつある、今日の糖質制限を通じた議論と同じような構図が見えてくる気がします。

 

悪いのはWBSではなくて、WBSのメリットとデメリットを正しく理解して、しょせんWBSもひとつのツールであると割り切れないプロジェクトリーダ、マネージャに問題があるのです。

WBSなんて、外科手術で言ったら、心電図とか血圧計などに相当するものなのではないでしょうか。決して手術野をすべて見渡せるような万能な機械などには相当しません。

WBSも使いつつ、他のツールで補ったり、様々な考え方のいいところは取り入れたりしながら成果を出していくのが、あるべき姿なのではないでしょうか？

 

私も、何かを盲信するのではなく、批判や反対意見にも耳を傾けながら、いいものはいいと評価して取り入れていきたいものです。

 

それでは。