今どきのプロジェクトの多くは問題探索型であり、先を見通せないなかで運営していかなければならない。この連載では、そうしたプロジェクトを「暗闇プロジェクト」と呼び、その種のプロジェクトを主導するマネジャーが持つべき心得や運営のヒントを事例とともに示している。

 今回からしばらく、問題解決について取り上げる。暗闇プロジェクトでは様々な問題が生じるのが当たり前。マネジャーはそれを前提に、うまく舵取りしていく必要がある。そのために何をすべきか、四つのセオリーを見ていこう。

セオリー1
難問にぶち当たったら、むしろ安心せよ

 暗闇プロジェクトでは、頭を抱えてしまうほどの失敗や難問にぶち当たることは珍しくない。それでも難問に直面したら、まずは安心すべきだ。これがセオリーの一つ目である。

 一口に難問と言っても、あらかじめ想定できるものと想定できないものがある。「システムの品質をより高める」というのは、想定できる難問の一つだ。

 ソフトウエアの不具合(バグ)のうち、95%を発見・修正できたとする。できれば100%に近づけたいところだが、実現するのは非常に難しい。残る5%を発見・修正するために必要な労力やコストは、95%のために要した労力やコストを上回る可能性が高い。この難しさは、あらかじめ想定できるものだ。

 どこまで対応するかは、コストとの兼ね合いやユーザーの要求レベルとの兼ね合いに応じて決めていくことになる。信頼性や可用性についても同じことが言える。

「暗闇」では難問が突然、振りかかる

 想定していなかった難問がいきなり降りかかってくる。これが暗闇ブロジェクトの難しさだ。例を挙げよう。

  • 要件定義をまとめるのに100時間を要した。ところが「儀式」のはずの承認の場で、理事長の一言により、ひっくり返る
  • どこから着手すればいいのか、皆目、見当が付かない。アウトプットがゼロのまま、数週間が経過する
  • 最先端のソフトウエア製品を開発し、リリース間近。その段階で、無名のメーカーが同じ機能を持ち、より優れた製品を発表し、業界の話題をさらう
  • 以前にけんか別れした元同僚が、ユーザー側のコンサルタントを務めている
  • 「やりたいようにやれ」「結果は気にするな」と言っていた上司が、突然「数字」を要求し始める
  • 想定していなかった作業が発覚し、数百万円の費用が発生することが判明。なのに、誰が負担するかは曖昧なまま
  • トラブル発生。原因を特定するには、複数メーカーに所属する技術者の協力が欠かせない。だがメーカーは競合同士なので、協力に難色を示している
  • 長い付き合いで「大丈夫」と信じていた顧客が、口約束を守らない