DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

2017年8月3日に第３次安倍第３次改造内閣が発足しました。しかし、未だに日報・森友・加計問題疑惑解明のための臨時国会召集を求める声も強く、前途多難な船出となっているようです。。。

ん？体制変更、問題解決のための臨時の会議招集、、、なんだかトラブル中の大規模プロジェクトの一場面を思い起こしますよね。。。やっぱ職業病かも？

ということで、今回は大規模プロジェクトの会議事情について考察します。（※１）

【　システム開発失敗の主因はやはり要件定義！　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
本題に入る前に少し脱線しますが、先日（2017年7月9日）のＰＭＩ日本フォーラムでの講演　『なぜリスクマネジメントは形骸化してしまうのか？ ～ 実効性のあるリスクマネジメント定着化についての一考察 ～』　において、大規模プロジェクトの失敗の要因は要件定義工程という日本情報システム・ユーザー協会（ＪＵＡＳ）の統計データを紹介しましたが、なんと『日経コンピュータ8月3日号』の「変わるＩＴトラブル－開発失敗編」という特集記事にも同じ統計データが紹介されていました。（※２）

この記事は「システム開発を成功させるハードルは下がるどころか、上がっている。・・・ユーザ企業はIoT（インターネット・オブ・シングス）の時代に向け要件定義やプロジェクト管理の能力を一段と磨く必要がある。」として、記事の締め括りには以下３つの教訓が示されています。

教訓
■パッケージのカスタマイズはトラブルの元
■開発を分割すれば失敗リスクが低下
■１人月でも不足なら開発ストップ

やはり大規模プロジェクトはリスクマネジメントが大事であり、トラブル拡大を防ぐためにはプロジェクト全体リスクのモニタリングとその対応戦略（たとえば開発ストップ）のタイムリーな発動が必要ということで、私の講演論旨と共通している点が多いと感じました。記事の詳細については本誌をご覧ください。

もちろん要件定義工程では、経営層やエンドユーザなどのさまざまなステークフォルダから真の要求を引き出して、システムの要件を定義することになるため、数多くの会議が開催されることになります。

そして、ＩＴトラブルの主因は要件定義ということなので、要件定義工程で開催される会議体も、なかなか思うように運営できていないということになるはずです。

【　システム開発プロジェクトの会議体定義　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
プロジェクトを立ち上げる際、プロジェクト計画立案の一環として、プロジェクトの体制図を明確化するとともに、効率的に進捗状況を共有したり、迅速に課題をエスカレーションするためのコミュニケーションプランとして、会議体を定義します。たとえば、当ブログの　【第５５回】プロジェクト八景～品質評価の多面性　で登場した図１に示すような体制で要件定義を進める場合に、どんな会議体を定義するかを考えてみましょう。

ここでは対象期間を要件定義工程期間（３ヶ月と仮定）に絞り、キックオフミーティング、工程完了判定会議などは除いて、要件定義期間中継続的に実施する会議体に焦点をあて、発注側視点での会議体定義として考えてみます。

うーん。そんなに大きなプロジェクトでもないのに、これだけ会議体が多いと会議に参加している時間だけでなく、資料準備や議事録確認なども含めて、会議に関係する時間はかなり多くなることが想像されます。大規模プロジェクトの場合は、進捗関連の会議だけでもその種類の多さに、プロジェクト全体をマネジメントするプロジェクトマネージャとしてはどこで何が起きているのか把握しづらくなってしまいます。

そんなときは、図１の体制図の中でステアリングコミッティ（以下ステコミ）参加メンバを点線の枠で囲っているようなやり方で、体制図上にどの会議体はどのレイヤーのメンバが参加するかを明示するという方法もありますが、それだけではごちゃごちゃしてわかりづらくなります。そこで、たとえば図３に示すような、プロジェクトの会議体の構造を図示して、情報のエスカレーションルートをわかりやすく表現します。

この例ではチームの数も少ないため、ずいぶんシンプルな構造に見えますが、大規模プロジェクトでチーム数も多くなり、さらにマルチベンダー体制の場合などには、かなり複雑なコミュニケーション構造になるはずです。プロジェクトに関係する全てのステークフォルダがプロジェクト状況をどのようなコミュニケーションルートで共有されているか理解する上でも、このような「見える化」は有用です。

たとえば、図３の例では、１のステコミはまあ良しとして、２~４の会議体が同じ幅のボックスになっていることから冗長感が強いように見えるので、会議体を統合できないか検討すべきであり、統合できないとしてもそれぞれの会議体の参加者や目的にメリハリをつけたり、資料の流用などを検討するなどして、同じような議論の繰り返しによる無駄を無くし、会議運営効率化の工夫が必要なことが明白になります。

【　発掘！大規模プロジェクトの「あるある」会議事情　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さて、プロジェクト体制図をもとに効率的なコミュニケーションを実現するための会議体構造を定義したのは良いのですが、実際にプロジェクトが進行していくと、さまざまな問題・課題にぶち当たることで、なかなか計画通りにうまく会議運営ができないことが多々あります。

ここでは、特に大規模プロジェクトでどんなことが起きるのか、私のこれまでの体験などをもとにご紹介します。

＜　大規模プロジェクトの会議事情　＞

１．特定キーマンがあらゆる会議への参加を余儀なくされる！

どのプロジェクトにも、全体感を持っていて、いろいろな課題に的確に意見を出せるキーマンが存在すると思います。このキーマンは、事前の情報をあまり詳細に把握していなくても、会議に参加すると会議に提示されている資料や会議の流れの中で的確に状況を汲み取り、参加者が納得する発言をできるものです。

こうしたキーマンは、プロジェクトが暗礁に乗り上げ始めると、会議体定義では参加メンバとして定義されていないのに呼び出されて意見を求められることが増えてきます。そして、いつの間にかあらゆる会議体から呼び出されることになり、せっかく優秀な人材なのに、会議に追われることでそのキーマン担当のタスクがまったく進まなくなって、プロジェクト全体としては余計に進まなくなってしまうという事態に陥ります。

そのキーマンがプロジェクトマネージャの場合は、さらに時間の制約が加わることで、プロジェクトコントロールができず、担当まかせの行き当たりばったりのマネジメントに陥ってしまします。「自分の仕事は土日しかできない！」なんてボヤキも良く耳にしました。責任感の強い方は、どうしても課題を放置できずに、長時間労働が続いて疲弊してしまうので要注意です。

２．プロジェクト状況悪化でステコミ開催頻度がどんどん増える！

ステコミは、経営層も参加してプロジェクト全体リスクを評価することで、プロジェクト運営に関する重要な意志決定を行う大事な会議体です。プロジェクトが暗礁に乗り上げると、日々発生する問題課題への対応にプロジェクトマネージャやＰＭＯが多忙になって、ステコミに報告する資料に的確にプロジェクト状況を示すことができずに、意志決定がくだせないなんてことが起きてしまいます。

意志決定の遅れはプロジェクト運営に影響を与えることになることから、通常は月に1回程度開催のところを意志決定残がある場合は翌週も開催するとか、ステコミ開催頻度がどんどん増えることがあります。そうなると、ますますプロジェクトマネージャやＰＭＯの稼働を圧迫して、落ち着いたプロジェクトコントロールができなくなるなんてこともよく起きます。

３．課題解決のための臨時打合せがどんどん増える！

要件定義がうまく行っていない場合、要件を決めるための検討会議が増えるのは目に見えています。課題解決がなかなか進まないと、いろいろなステークフォルダから、「とにかく関係者を集めて短時間で決めてしまえ！」なんて大号令がかかり、明確な課題解決のためのシナリオを持ち合わせていない関係者が集まって、勝手に自分の思いを語りだすことで、ますます課題解決が進まなくなって、課題解決会議だけが増えていくということになります。

臨時の会議招集が増えると、参加者のスケジュール調整をするだけでも時間がかかったり、中途半端に参加できないメンバがいて結論が出せなかったり、課題解消の加速どころか、逆にますます課題を増殖してしまう結果を招くことも多いのです。臨時の会議招集を増やすのは、モグラたたき的な対症療法にすぎず、せっかく構造的に定義した会議体が機能しなくなって、プロジェクト状況がどんどんわからなくなるという悪循環に陥ってしまいます。

４．恒常的な会議室の不足！

要件定義が暗礁に乗り上げ、会議体が増えるということは、プロジェクト体制強化のために、プロジェクト参加メンバの追加を伴うことが多いはずです。大規模プロジェクトの場合は、ただでさえプロジェクトに準備されている座席や会議スペースがひっ迫していることが多いので、さらに追加メンバの座席確保のために会議スペースが削られることもよく行われます。

課題解決のための会議は増えているのに、会議スペースが削られることになると、そもそも会議室が無くて会議が開催できないなんてことになりかねません。実際、トラブルプロジェクトで会議室が不足した場合に、近くの喫茶店やファミレスを臨時の会議スペースとして使ったり、プロジェクト予算を使って近くのホテルの会議室を利用したり、早朝に会議を実施するなど、あの手この手を使って会議を開催したりした経験もあります。

思い返せば、まだまだ「あるある」はでてくるのですが、今回はこの辺にしておきます。
このように、特に大規模プロジェクトの会議運営は特にたいへんであり、プロジェクト計画の段階でしっかりしたコミュニケーションプランを立案しておく必要性を再認識すべきです。

そして、プロジェクトが暗礁に乗り上げて、会議運営がうまく回らなくなってきたときには、場当たり的に会議を増やしたり、会議参加者を増やすというアプローチは悪循環を生みやすくなることを認識し、マスタースケジュールや体制図、スコープ定義などの全体計画に立ち返って抜本的な見直しを行うべきです。

会議体が増えていくという現象は、多くの場合はスコープが拡大している兆候ととらえ、早々にスコープの見直し（要求のトリアージ）も検討する必要があります。（※３）

「会議体の増殖はスコープ拡大の兆候ととらえ、抜本的な全体計画見直しを検討しよう！」

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　今回のブログタイトルは、以前フジテレビ系列で放映されていた『発掘!あるある大事典』を参考にさせていただきました。
・「発掘!あるある大事典」『フリー百科事典　ウィキペディア日本語版』
2017年7月1日 (土) 11:37 utc https://ja.wikipedia.org/wiki/発掘!あるある大事典

※２　『日経コンピュータ』2017年8月3日号、日経BP社より
・P032　特集「変わるITトラブル　開発失敗編　やはり要件定義が主因」

※３　スコープ拡大、トリアージについては、当ブログの以下の回も参考にしてください。
・【第３９回】トリアージでデスマーチを脱却せよ！
・【第４０回】膨張するプロジェクトとトリアージ依存症
・【第４１回】プロジェクト体制図にバルタン星人が現れるとき