ITプロジェクト失敗の理由

ＩＴの中から「トラブル」をなくせば、それだけでノーベル〇〇賞ものだと思うんです。だって、世界中で年間何兆円失われているかわからないレベルの損失トラブルが起きているわけじゃないですか。

完璧になくすことはできなくても、私の手の届く範囲内だけでもなんとかゼロにできないかなー？と日々考えているわけですが、ボヤーっと答えは見えるものの、やはり１人では限界があるのかな？って気もしています。

まぁどっちにしても、マネジメント手法(体系)や開発手法(体系？)がある程度固まらないと難しいかもしれませんね。

逆にいえば、私の中では「マネジメント」と「開発体系」がある程度定まっていれば、高い確率でトラブルを防ぐ方法があると言うことでもあります。まぁだからこそ、今まで数多のトラブルプロジェクトを解決してきたわけで。

deliverable

細かいこと、具体的なこと言いだしたら、色々あると思うんですけど、それらを抽象化して１つにまとめると、要するに

　deliverableな進め方をしていないから

ということになります。

deliverable（デリヴァラブル）とは、英語のdeliver（＝届ける、もたらす）＋able（＝できる）の組み合わせが語源で、直訳すると「提供できる、もたらすことができる」という意味で、プロジェクト活動のなかでは

　「納品に必要なモノ、あるいはコト」

と意訳します。もし、失敗したプロジェクトをマネージャー、メンバー、あるいはサポーターとして経験したことがある人は、ものすごくわかると思います。必ず『なにか』が足りていませんでしたよね？

もし、検討や決断が「間違っていた」と言う原因だったとしても、こう読み替えてください。

　「検討が間違っていた」→「検討が十分だという根拠が不足していた」
　「決断を誤った」→「決断する条件の洗い出しが不足していた」

手順的には

「検討するテーマを決める」
↓
「検討完了の十分条件を定義する」
↓
「検討する」
↓
「十分条件を果たしているか確認する」

となるはずが、なんとなく有識者（？）っぽい人を集めて、それらしく個々人の意見を吸い上げているだけの検討会と言うのは多いと思います。「どういう状態になったら完了なのか」と言うゴールをあらかじめ定めている会議体と言うのはとても少ないのです。

だから、中途半端であっても、間違っていても、本人たちの中でなんとなくの妥協点に至れば、勝手に自己満足してしまいます。

こうした「十分」に足りていない状況で、スケジュールばかりを気にしてどんどん進めようとするから、プロジェクトは失敗するのです。

たとえば、各工程ごとに「〇〇設計書をつくる」…なんてアクティビティを定義し、中間成果物として「〇〇設計書」を求めたとします。

ですが、そのルールは本当に

　プロダクトを作成するために、あるいはプロジェクトとして
　成功を収めるために必要十分な、かつ最低限の情報群

となっていますでしょうか？
画面設計を行うから、「画面設計書」が必要とだけ定義できる人は多いかもしれません。では、「画面設計書」の中に記載されるべき情報は、十分な情報群となっていますか？不要な情報は一切記載されない仕組みになっていますか？

そういうことを一つひとつ考えてプロジェクトを遂行するマネージャーやリーダー、エンジニアというものを私はほとんど見たことがありません。

　「ルールだから」
　「会社からそう言われたから」
　「前はそれでうまくいったから」

という思考停止な回答しか返ってきたことがありません。これから始めるプロジェクトにとって、それが最適かどうかを熟考された痕跡がまったく無いのです。

これを私は、

　『既存テンプレート』から『プロジェクト適用』するにあたって
　情報を再利用するための双方向コミュニケーションが障害を起こしている

と呼んでいます。

　コミュニケーション不足
　技術力不足
　仕様検討不足　etc.

と言うのも、すべて  deliverable にとって必要か否か、充足しているか否か、を適切に評価していれば起こりえなかったかもしれません。

START時に「顧客要求事項」があって、その要求からすべてのタスクが分業によって分かれていきます。そして、要求を満たすためだけにスケジュールが進められ、最後は１つの「納品物」と言う形に集約されGOALに辿り着くのです。

当然ですが、次のタスク、次の成果物に何も貢献しないタスクや成果物は、時間の無駄であり、コストの無駄です。「バグを作る」というのは、これに該当します。

また、引用元がハッキリしないタスクや成果物もキケンです。なぜなら、「顧客要求事項」のどれにも該当しないからです。要求にみあった活動をするために見積り、計画を立てている以上、要求に無い活動をすれば、当然

　・「オーバースペック」と言うバグになる
　・スケジュールが逼迫する
　・逼迫した分、コストが増大する

と言った問題を起こすことになります。活動途中で仕様変更等があっても、過去の成果物に遡って修正や追記が必要になるのは、常に deliverable な流れの中に紐づけておくためです。

　「足りているのか、足りていないのか」
　「deliverable の線上に紐づいているのか、いないのか」

常にこの状態監視をおこない、コントロールすることがマネジメントの極意と言って差し支えありません（私は「やりくり」と言っていますが）。

もちろん、具体的な実践レベルではＴＰＯにあわせてどうすることが正解なのか、一つひとつ吟味しなければなりません。ですが、それらの大本はすべて「deliverable の流れに則っているか」で考えるようにしましょう。どの線にも紐づいていない活動は、かならずマネジメントを失敗に追い込みます。