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

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

残暑厳しい中、いかがお過ごしでしょうか？グレムリンは一見かわいい小動物ですが、真夜中に食物を与えると狂暴化し、水を浴びると一気に自己増殖するので、なかなか手に負えません。(※１)

システム開発の現場でも、一見平穏無事に進んでいたプロジェクトが、工程完了間際に様相が一変することを良く見かけます。今回は、俗にいう「９０％シンドローム」について考察します。

【　「９０％シンドローム」とは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
「９０％シンドローム」（あるいは「９０％症候群」）とは、あるタスク、工程、または、プロジェクト全体が完了間際（９０％ぐらい）までは順調に進捗していたにもかかわらず、急に進捗が止まったり、ひどいときには既に完了した作業の大部分をやり直す必要が生じて、一気に泥沼状態に陥る現象を言います。（※２）

まずシステム開発のプロジェクトで見られる「９０％シンドローム」の具体例をいくつか紹介しましょう。

＜具体例１　外部設計のタスクが進捗率９０％から進まない＞
そもそもあなたのプロジェクトでは、外部設計における各タスクの進捗率はどのように計算しているでしょうか？ウォーターフォール型のシステム開発の場合によく行われる方法は、機能分割されたそれぞれの機能ごとに外部設計書の（１）作成、（２）内部レビュー（開発ベンダー内のレビュー）、（３）外部レビュー（発注側とのレビュー）の３つにタスクをわけて、それぞれの進捗率に重みづけをして、詳細ＷＢＳに落とし込むというやり方です。

図１に示す例では、××機能の外部設計が進捗率９０％で止まってしまっています。ちょうど外部レビューが始まるところなので、おそらく開発ベンダーが提示した外部設計書の内容が、発注側の想定している品質レベルを満たしていなかったために、差し戻しとなってしまったことなどが想定されます。

それにしても、この詳細ＷＢＳでは、進捗が止まってから２週間、担当のＡさんは何を実施していたのか全くわかりません。品質の問題であったとすると、外部設計書の見直し・品質向上を行っているのでしょうか？

＜具体例２　結合テスト工程が進捗率９０％から進まない＞
次は結合テストの例です。テスト工程の進捗率は、テストケースの消化割合で計算することが多いと思います。テストケースの消化が９０％までは順調に推移したのに、それ以降ピタッと止まっています。原因として考えられることは、おそらく簡単には治すことのできない不具合（バグ）が、結合テストの終盤で発覚したのでしょうか。

たとえば機能要件のみに着目したテストケースを設定していたために、性能など処理方式上の問題の検知が遅れたことで、工程終盤になってから全機能に影響する処理方式見直しを行わなければならない事態に陥るなどです。その場合は、デグレードのリスクも高まることになり、さらに消化済みのテストケースを広範囲にやり直す必要性も出てきます。

＜具体例３　本番稼働直前に大きなタスク漏れが発覚してプロジェクトがストップ＞
３つ目の具体例は、当ブログの　【第３４回】カットオーバー・クライテリアとは何か？　で登場した稼働判定会議にて、大きなタスクの漏れが発覚し、それまで順調に推移していたプロジェクトが一気に泥沼状態になってしまうケースです。既にカットオーバーまで時間が無くなっているので、全体の進捗率が何％など悠長なことは言ってられません。とにかく、本番稼働までに実施しておかなければばらない残タスクを洗い出して、こなさなければなりません。

残タスクの量によっては、予定された本番稼働日に、無理やりカットオーバーさせることで生じるかもしれない現場業務の混乱を避けるために、本番稼働時期の延期を決断せざるをえない場合もあります。

たとえば、データ移行ツールの開発とツール機能のテスト自体は実施していたのに、旧システムの本番データを入力として新システムに登録するためのジョブの実行シェルやＪＣＬの作成・テストのタスクが漏れていた場合などです。もしこれらのタスクが本当にプロジェクト計画から漏れていたとしたら、新システムに移行するデータの検証作業についても考慮されていないかったことが想定され、移行計画全体を一から見直しする必要があるかもしれません！

【　「９０％シンドローム」をどうやって予防するのか？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
さあ困った！タスク、工程、プロジェクト全体と、それぞれレベル感に違いはあるものの、スケジュール的にはもうすぐ終わりを迎えようという時期に、まだまだ終われない問題・課題が噴出してしまっています。別に管理を怠ったり、ルールを破ったという認識は無いのに、「品質向上」や「処理方式見直し」や「計画で漏らした移行関連タスク」などのやっかいなタスクたちが、まるで狂暴化したグレムリンのように次々と自己増殖をはじめて、にっちもさっちも行かない状態に陥ってしまいます。

もう既に起きてしまった問題・課題に関しては、その時々の状況に応じて善処するしかないでしょう。まるでがん細胞のように自己増殖するタスクたちを食い止めるためには、がん摘出手術が良いのか、抗がん剤投与が良いのか、もしかしたら既に次工程にがんが転移しているかもしれないことも考慮する必要があるでしょう。システム開発のプロジェクトでは、いったんプロジェクトを中断し、進捗が止まった原因を排除したうえでプロジェクトを再開するなんて話も良く耳にします。

しかし、次からは同じような問題・課題を起こさないように工夫する（継続的改善）のが、プロジェクトマネジメント（≒リスクマネジメント）の役割のはずです。これらの「９０％シンドローム」を予防するためにはどうすればよいのでしょうか？

―――　プロジェクトマネジメント研修を受けてきたばかりの新人Ｐ子さんの意見を聞いてみましょう。

＜新人Ｐ子さん＞　：　「うーん。どれもスケジュールの終わりの方で問題が噴出してるということは同じだけど、それぞれ事象や原因も全然違うみたいだから、それぞれの事象が起きるかもしれない個別リスクとして、それぞれで予防策を考えるしかないんじゃないかしら？」

＜ベテランＰＭのＭ男氏＞　：　「何を寝ぼけたこと言ってるんだ！ここにあげられた具体例はそれぞれ事象も原因も全然違うじゃないか。プロジェクトで起きるかもしれない個別の問題全てに対して予防策を事前に考えるなんて、非効率すぎてナンセンスだろう。とにかくプロジェクトを進めて、問題が起きたら都度最善の策を講じるのが一番なんじゃ！」

・・・

そうですねえ。確かに、個々のプロジェクトは独自性を持つので、どんな問題が起きるかをあらかじめ全て予測して予防するのは難しいかもしれません。しかし、だからと言って、何も対応策を講じなければ、プロジェクトの成功確率は向上するわけがありません。ではどうすれば良いのでしょうか？

「９０％シンドローム」は、スケジュールの最後の方にやっかいな問題が検知されることが大きな特徴と言えます。では、なぜスケジュールの最後の方にならないと検知できないのでしょうか？

当ブログの　【第２回】プロジェクトマネジメントは問題解決だ！　を思い出してください。ここでは、プロジェクトにおける問題を早期発見するために、常にアンテナをはることの重要性について考察しました。そして、　【第４回】プロジェクトにおける問題とは何か？　では、プロジェクトにおける問題をプロジェクト計画と現状のギャップと定義しています。つまり、問題が早期発見できない原因には、プロジェクト計画の出来が大きく関わっていることを再認識する必要があるのです！

「９０％シンドロームを予防するキーポイントは、プロジェクト計画の中にある！」

次回は「９０％シンドローム」の具体的な予防策について考察します。真夏のグレムリンの自己増殖を防ぐ方法とは？

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

工藤武久

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

※１　「グレムリン (映画)」『フリー百科事典　ウィキペディア日本語版』　http://ja.wikipedia.org/wiki/グレムリン (映画)　 2014年7月13日 (日) 06:19　UTC

※２　「９０％シンドローム（９０％症候群）」は、当ブログの　【第３２回】準優勝！と決勝敗退！の微妙な違い　でも登場しています。