失敗するプロジェクトの原因
プロジェクトマネジメントを成功させるためには、失敗事例をもとに原因を理解し、学習することになります。一般的なことは多くの文献がありますので、ここでは少し原因を深堀してみることにします。深堀する理由には、仕様祖語が発生して仕様変更を余儀なくされたことで、納期が遅れた・プロジェクトが赤字になった等を良く聞きます。仕様齟齬が問題なのはわかりますが、なぜ仕様齟齬が発生したのか？、この理由を探ってみたいと思います。
プロジェクトが失敗する原因として「仕様の理解力」「王道のマネジメント」「事実を論理的に見る」の３つのことが出来ていないことがあげられます。
補足となりますが、全てにプロジェクトに当てはまるとは限りません。しかしながら、少しでもプロジェクトマネジメント成功の手助けにはなるはずです。結果的にＩＴ業界全体の底上げとなり、業界の発展に貢献できたら幸いです。
- 仕様の理解力
お客さまの業務を含めて細部まで理解する。これにより仕様含めた設計ミスを防止することで、後工程からの戻りを減らす。 - 事実を論理的に見る
感覚で判断はしない。事実を論理展開することで、問題点を発見できます。 - 王道のマネジメント
担当者に丸投げしない。プロジェクトマネージャーが、全てにおいて責任があることを理解しマネジメントする。問題は、原因分析も大切だが、解決しなければ先に進まない。
仕様の理解力
仕様の理解力は、お客さまの業務を深く理解しないことで、仕様ミスや設計ミスを発生させてしまうことです。これにより、後工程からの手戻りが発生してしまい、想定外の工数が発生することになってしまいます。
多くの有識者は、プロジェクトの問題・課題は上流で潰すことを推奨しています。その通りで、問題・課題を上流で潰すということは、曖昧さを残したり、場当たり的な対応（場当たり的な対応は根本的な問題を残すことと一緒）を取らないことだと思います。この曖昧さを残さないためには、お客さまの業務を細部まで理解して、仕様書にするということです。
とはいえ、現実的なこととしては、聞いていないという反論があると思います。もちろん、聞いていませんから仕様書にすることは出来ません。これには、お互いの思い込みにより発生します。
たとえば、ECを設計するうえで、受注した商品の物流業務がありますが、ピッキングがどのようなことをするのか理解の乖離があります。あくまでも例えですが、SI企業は「受注した商品を棚から持ってくる」、業務部門は「ピッキングリストが印刷され、リストに従って、最適なルートを通り、まとめて10件のお客さまの商品を持ってくる。その際には、在庫数を1減らす。」であると思っているかもしれません。つまり、広さと深さが全然違います。業務部門は、SI企業は業務を理解しているものと思い込んでいますから、端から端までの全てを話すことはしません。大まかな流れと（個人的に）現状の問題点を話してきます。SI企業は、この話の内容から仕様書におこしていくのですが、実は仕様としては足りていません。もしかしたら、ピッキングルートに交通ルールがあるとは思ってもいないかもしれません。在庫も、ECで管理しているバーチャル在庫と、倉庫で管理しているリアル在庫があるとは理解していないかもしれません。
確かに、実際に業務に携わらなければ、詳細な業務を理解することは難しいです。しかしながら、ピッキング1つとっても、自分がピッキングするとしたら、どういう業務をするのか？、どういう機能が必要か？、等々のイメージがあって、はじめてお客さまと、本当のヒアリングが出来るのです。このスキルがSI企業には必要不可欠となってきます。イメージ出来ていないままでヒアリングをすると問題もわからず質問すら出来ませんから、ヒアリングは浅いものでしかなく、結果的に聞いてないとなってしまいます。もしくは、この時はわかったつもりになっているだけかもしれません。
それぞれの業界には、基本的な常識があります。他業種からみれば、常識ではないかもしれませんが、業界にいる人は常識と思っています。だから、相手も当然ながら知っているだろうと思い込んでしまいます。これが、仕様の乖離をうむ大きな要素の1つになっていると思います。過去の経験から、新しい業界の仕事の際には業界入門を読み、基礎知識を入れてから挑んでいました。これだけでも、専門用語の意味や、業界のビジネスモデルを理解できますから、お客さまの業務イメージが想像でき易くなります。業界の常識には、理由があります。この理由を理解するようにすれば、誰でも理解することは出来ると思います。後は、ひたすら訓練をしてください。どのような業種・業態であっても、キャッチアップできるスキルが身に付きます。
事実を論理展開して真実を知る
事実を論理的に見るとは、感覚（感情）で理解するのではなく、事実を論理展開して真実を知るということです。事実は、個人視点で解釈された報告ではなく、プロジェクト共通で誤解のない報告です。また、論理展開とは事実と業界知識から、問題・課題がないか把握することです。たとえば、担当者から「○○プログラムの開発が終わりました。」と言われたときに、プログラムの開発の定義は、全員一緒でしょうか？ コーディングという人もいるかもしれませんし、単体テストまでかもしれません。それぞれの定義の理解によって、実際の進捗は違ってきます。まずは、同じ定義で話すことが必要です。これで、事実を正しく集めることが出来ます。この事実をもとに、納期までの期間と進捗具合から、エンジニアは足りているのか？、経験が浅いエンジニアに補佐を付けた方が良いのか？、不具合の発生傾向からリスクはどこに潜んでいるのか？、等々を知ることです。
昔々に、このような事例がありました。某大手SI企業の品質保証を請け負った時のことですが、残念ながら参画した時には既にプロジェクト進捗が悪い状況で、下請けのプロジェクトマネージャーがリカバリー計画を提出していました。内容としては、休日出勤と工程を並行して進めることで納期を守れるとのことでした。一見すると良さそうな感じではあるのですが、良く見ると工程に必要な工数と人員計画に矛盾がありました。この工数からすれば、納期まで全員が不眠不休で働なければなりません。これでは、そもそも労働違反ですし、実行することは不可能です。結局のところ、エンドユーザーさまには、当初の納期には出来た機能だけを収め、残りは数か月遅れて納品することになりました。
もしかしたら、このケースは事実を知っていて、無理とも言えずに間違った報告をしたのかもしれませんが、前々から事実をもとに論理展開したマネジメントをしていれば、納期遅れを最小限にすることが出来たかもしれません。プロジェクトには多くのエンジニアが関わります。しかも、自社だけとは限りません。ですので、事実を聞き出すことも大変なことかもしれません。だからこそ、定義などを決めて実行することで、事実から真実を把握したプロジェクトマネジメントが出来るようになると思います。
王道のマネジメント
王道のマネジメントとは、基本的には有識者が創り上げた優れたフレームワーをもとにプロジェクトをマネジメントすることです。
もし問題が発生したら、なんとかしようとする気持ちは、正しいです。ただ、事実に基づき論理的に出来ることを対策案として進めなければなりません。なんとかなると自分に言い聞かせるのではなく急がば回れです。プロジェクト費用も、根性論だけで失敗するよりも、論理的に出来る計画を立てプロジェクトメンバーの精神的(モチベーション) を高めて進めた方が、結果的に早く安く済みます。ようは、王道から脱線してしまったら、王道に戻すということです。
実行するためには、SI企業・IT部門のベクトルをあわせなければなりません。
しかしながら、SI企業の実態は利益を優先してなのか担当者に丸投げをしたり、兼務することが見受けられます。それで成功すれば、誰も文句はないのですが失敗する確率が高まるのも事実です。プロジェクトマネージャーは、全てにおいて責任があることを理解しマネジメントしなければなりません。プロジェクトマネージャーは、プロジェクトの上に立つ人ですから、人の責任にしたり、言い訳はしないはずです。責任を持って対応することが求められて、そのための行動をしなければなりません。
考えがちなのが、要求通りに動くよう辻褄合わせをすることです。しかし、これが積み重なると、DB設計やアーキテクチャーに歪が生じてしまい、余計な影響範囲が広がり根本的な修正を余儀なくされることも想像できます。面倒かもしれませんが、問題が発生した都度、常に設計思想になるように修正することです。面倒と思うかもしれませんが、問題の先送りはリスクになるだけです。
他方で、企業のIT部門は、SI企業を下請け業者と勘違いをして丸投げをしている場合があります。これでは、SI企業との溝をつくり、品質を落とすことにつながります。また、悪いケースになると、SI企業の足を引っ張ることにもなり兼ねません。これでは、IT部門としての成果をだすことが出来ません。IT部門の成果は、投資対効果です。SI企業に丸投げをする仲介ではありません。
このように、お互いの立場でプロジェクトが進行していきます。本当に望んでいるのはプロジェクトの成功です。目先のことから開放されることではありません。しっかりとゴールを見据えて、1歩1歩を確実に正しく進めることが重要です。道に迷ったら、ドキドキしながら勘に頼らず進むのではなく、一旦立ち止まり本来の道（王道）に戻り継続することの方が、安心して確実にゴールに辿り着きます。
まとめ
補足となりますが「業務はIT部門が知っている」「SI企業は構築（技術）を知っている」という話もあります。その通りではあるのですが、全てではありませんが、経験則からすれば現実とは乖離があります。
IT部門は、業務を７割程度しか知りません。企業にもよりますが、IT部門はネットワークインフラもあれば、メール・スケジュール・勤怠管理・人事・給与・財務、営業支援等々と、企業に必要なIT全般をマネジメントしています。ですから、企業全ての業務を詳細に知っていることは無理難題なのです。また、業務部門も日々ITの変更を要しない改善をされているはずです。ですから、IT部門が常に最新の業務状態を知ることは現実的ではありません。
また、SI企業は、技術を有している人財はいますが、プロジェクトに参画しているとは限りません。表現を変えると、SI企業の全員がプロフェッショナルではないということです。最近では、技術の進歩や広域になってきていることもあり、プログラミングは出来るがDB設計を知らないプログラマー、ネットワークインフラやミドルウェアを知らないSEが多いようです。しかしながら、ネットワークやミドルウェアを知らずに構築すると、パフォーマンスや運用設計に影響があります。たとえば、アプリケーションログはデバックやトラブル時のためだけではなく、運用監視や不正時のトレースをするという重要な役割も担っています。ですから、ログの内容、レベルなども正しい設計をしなければなりません。パフォーマンスも本来なら、実行計画を見てSQLのチューニングとなりますが、INDEXを張ること程度しか出来ません。INDEXを張ることのデメリットもありますから、これも正しい設計をしなけばなりません。
SI企業は構築することに責任がありますから、技術の専門知識を有していなければなりません。技術の広がりは理解しますが、個々のエンジニアとしては難しいようであれば企業として、それぞれの分野の有識者を集め構築しなければなりません。
このことはは、全てに当てはまるわけでもなく、あくまでも事例ではありますが、実態とかけ離れた内容でもないと思います。素晴らしいお仕事をされて企業も多数います。ただ、少数かもしれませんが、当てはまる企業もあるのも事実です。事業会社にとっては、選定基準の材料として、SI企業やコンサルティングは、お客さまの成果になるお仕事が出来るようになるための参考になれば幸いです。
