第７回　大規模プロジェクトの体験を通して（その２：問題発生の要因について）

筆者が経験したり聞いたりした問題プロジェクトは、全てプロジェクトの序盤に問題の要因が潜んでいました。
大規模プロジェクトほど問題を認識する時期がプロジェクトの後半になりますから、大問題に発展する確率が高かったのです。厳しい受注条件のプロジェクトであろうと、余裕のある受注条件であろうと、問題プロジェクトは発生します。どのような開発標準（各メーカの、作業標準やＰＭＢＯＫ）に準拠しようと、どのような管理ツールを活用しようと問題プロジェクトは発生します。大規模プロジェクトは、結合試験段階になってから問題を抱えていたことが顕在化するので、そうしても対策が後手に回るのです。もっと運が悪いと、ユーザ総合試験が始まってから問題が顕在化したプロジェクトもありました。小規模のプロジェクトでしたら、普段からお互いに顔を見たり会話をしたりしているので問題の顕在化時期が早くかつ直にリカバリされるために問題視されませんでした。しかしながら１０，０００人月以上のプロジェクトになると、お互いに見たことも会話したことも無い人がプロジェクト・メンバの大多数を占めるので、各メンバの報告数値を頼りにプロジェクトの状況を把握するしかないのです。報告された状況が事実であることを確認する有効な手法もありませんし、大人数のメンバやチームの心理的状態を的確に判断する手法もありません。

大規模プロジェクトにおける問題発生の第一の要因は、プロジェクト規模が大きいことそのものが問題でした。
計画段階でコストも納期も余裕のあったプロジェクトが、要件定義や基本設計の段階で欲張って検討過剰となり、コストの半分以上を使い果した結果、最後は問題プロジェクトになりコストも納期も２倍以上を費やしたプロジェクトを身近で聞きました。一方では、コストも納期も厳しい（赤字覚悟で受注）プロジェクトが、予定よりコストを削減（黒字化）して予定通りに完成させたプロジェクトを身近で見ました。両プロジェクトの差は、プロジェクト・メンバの危機感の差だったようです。受注条件が厳しいプロジェクトは要件定義や基本設計の段階から、危機意識をメンバ全員に植え付けて、コスト管理および品質管理の仕組みを必死に構築していました。計画よりも常に前倒しにＰＤＣＡサイクルを回して、各作業を常に前倒して完了させた結果、コストも予定より削減されました。協力会社を含めたメンバやチームの心理状態を良好な状態に保つことに非常に熱心に努力をしていました。逆に余裕があったプロジェクトは、緊張感やコスト意識が薄弱だったので、メンバやチームの動機付けの配慮もマネジメントとの仕組みも出来ていませんでした。多数のメンバが参加していると、各人の責任範囲が小さく感じてしまい、相互依頼心が強くなり緊張感が緩むものです。この問題の予防策は、プロジェクト開始時に、チーム全員に緊張状態を作り、その緊張感を最後まで維持することです。大規模プロジェクトは長期間作業が続くので、緊張感を常時維持することが生理的に難しくなります。緊張感を大規模プロジェクトで維持するためには、何らかの工夫が必要です。長い工程の中に、厳しくチェックするマイルストーンを適度な間隔で設定すると、高い緊張状態が反復して生起するので、最後まで緊張感を維持することが可能となります。

第二の問題は、大規模プロジェクト程、リスク対策が難しくなることです。
規模変動のリスク、構築技術未熟のリスク、インタフェース不整合のリスク、要員スキル不適合のリスク、外部環境変化のリスク、作業漏れのリスク、意識不統一のリスク、作業手順不統一のリスク、作業管理手法不統一のリスクなど様々なリスクが存在し、リスク対策が複雑になります。網羅的にリスク対策をするよりも、費用対効果を考慮して重点的にリスク対策を考えるのが当然です。多くのプロジェクトは、主に規模のリスク、技術的なリスク（新規の機能実現のリスク、厳しい性能実現のリスクなど）に重点を置きます。しかし、重点リスク以外のリスク対策に不備があり、問題の解決に手間取り大問題に発展することが多かったようでした。また、実施した対策が不完全なために解決が長期化し、副次的な問題（コミュニケーションの欠如やモチベーションの低下など）が発生して、結果的に大問題に発展したプロジェクトを数多く見ました。特に悩ましい問題は、ユーザ要件の決定時期が遅延する問題でした。これは技術的スキルよりも、お客様に早く仕様決定を誘導するスキルが重要であり、意思決定・コミュニケーション・人間関係などの心理的要因を配慮した解決策が必要です。この問題をお客様側の問題として放置すると、開発側(受注側)にも必ず影響が波及するので、何らかの解決策が必須です。この類の問題解決には、技術スキルの補強よりもお客様側のメンバの追加・交代という人事措置が必要になることが多くあります。 プロジェクト開始当初からコミュニケーションの仕組みと良好な人間関係を構築して、予防措置を講じておくべき問題です。メンバやチームの良好な心理状態を構築する仕組みとして、チームの意思決定の仕組み、コミュニケーションの仕組み、情報共有の仕組み、プロジェクト進捗状況把握の仕組みが特に重要です。常時仕組みを監視して、仕組みに不具合があれば修正することが必要です。更には主要メンバの良好な人間関係構築（相性が良い）が重要です。お客様に言いにくいことも正直に言える（価値観を共有していて、真摯に受け止められる）良好な雰囲気が理想的な人間関係です。

第三の問題は、問題が絶え間なく発生するために、いつも問題解決の優先度付けに悩まされることです。
作業遅延問題、品質不良問題、性能不足問題、スキル要員不足問題などは、サブシステム単位や参加企業単位で見るとどこかで常時発生していました。大抵は、複数問題（作業遅延、スキル不足、品質問題など）が重複して発生し、連鎖反応的に同じようなことが別のサブシステムや別の参加企業に波及して発生しました。大規模プロジェクトでは、問題をメンバ全員が認識して相互協力して解決することが殆ど無く、小さなグループ単位で相互無関係に問題の対策を実行していました。リーダーも多くのグループを相手に相互協力を的確に指示出来る程の器量のある人は少ないので、大規模プロジェクトの多くは纏まりの悪いチーム状態が続きました。そして、次第にモチベーションが低下して問題プロジェクトに発展していきました。そもそも大規模プロジェクトを一人のリーダーの器量に依存することが問題なのです。チームのメンバ全員で対処する仕組みが必要であり、そのためには小さな管理可能な集団がＰＤＣＡサイクルを確実に実行し、プロジェクト全体がＰＤＣＡのサイクルとして有効に機能することが重要なのです。リーダーが全知全能の神のように、大規模プロジェクトの複雑なリスクを全て読み切り、メンバ全員に的確に指示を出して、問題解決するような期待はすべきではありません。メンバ全員がプロジェクトの目標を明確に理解して、小さな集団が全体目標に向かって自分の責任範囲を果たしながら、全体目標に出来る限り近づける仕組みの構築が重要です。端的に言うと、普通のリーダーの基で、小規模な個々の集団が、心理的に良好な状態を維持し、自律的にＰＤＣＡサイクルを回し、相互にコラボレーションを発揮しながら、全体目標に近づける仕組を構築すれば、どんなリスクや問題が発生しようともプロジェクトは大きな失敗をせずに遂行できるはずなのです。

この仕組みを構築・洗練していくことが、大規模プロジェクトの失敗を防止する対策だと思います。大規模プロジェクトとは、最初から複雑な問題を内在し、問題の認知が遅延し、様々な問題が同時多発する特徴を持っているのです。