脱出！ 暗闇プロジェクト

品質、納期、費用、機能のどれかをバッサリ切る

「ダメに決まってる」との前提から始める（下）

　暗闇プロジェクトが、自社の実験的なパイロットプロジェクトとして始まるとは限らない。顧客相手の通常の契約形態のプロジェクトが「暗闇」である場合もある。開発を請け負うシステムインテグレータにとって、契約の内容次第では非常にリスクが大きいプロジェクトとなる。

プロジェクトが支離滅裂？ そんなことは当たり前

「ダメに決まってる」との前提から始める（上）

　この連載では、先が見えない「暗闇プロジェクト」を任された場合に参考になりそうなヒントやノウハウを紹介している。今回からしばらく、プロジェクトの最初期の段階である準備・構想段階での心得を見ていく。「どうせダメに決まってる」と言われているプロジェクトをうまく立ち上げるセオリーを見ていく。

「理屈」の人でも意思決定の99％は「感情」で行う

コンセンサス醸成の基本姿勢と“小手先”テクニック（下）

　この連載では、先が見えない「暗闇プロジェクト」を任された場合に参考になりそうなヒントやノウハウを紹介している。前回は、プロジェクトを進める際に顧客のコンセンサスを取っていく際に役立つセオリーを紹介した。今回はその続きである。顧客との合意を取り付けるのがいかに難しいか、実感していただきたい。

顧客の意思決定プロセスを「把握できた」と考えるのは大甘

コンセンサス醸成の基本姿勢と“小手先”テクニック（上）

　SIerのエンジニアであるS氏は、ユーザー企業Q社に半常駐状態。客先内で最も技術に詳しいこともあり、便利屋として何かと重宝されている。今回も変な割り込みが入ってきた。「そっちにITに詳しい人がいるそうだね。この件を見てほしいのだけど」との依頼があり、S氏の部署の部長は二つ返事でOKを出した。

顧客満足度は自ら高める、受け身の考え方は捨てよ

「暗闇」でも変わらない顧客との関係づくりの秘訣（下）

　ユーザー企業大手のA社では、これまで社内の各業務部門が独自にシステムを構築するのが当たり前だった。さすがにA社内でも、このような状況を問題視するようになり、システムを企画・構築する上で標準化すべき領域については、システム部門に一括して権限を集約することになった。

システム要求を出すのは「会社」ではなく「個人」

「暗闇」でも変わらない顧客との関係作りの秘訣（上）

　システムの目的を明確にすることは、プロジェクトの初期段階での最重要課題だ。若手プロジェクトマネジャーのB氏はプロジェクトの冒頭で、顧客企業X社に「システムの目的を教えてもらえますか」と確認した。先方の答えは「業務の効率化によって、顧客サービスの向上を図る」というものだった。

「あり得ない選択肢」を数合わせで入れるのは極めて危険

重要な提案で必要なカタチへのこだわり（下）

　ユーザー企業R社は東日本と西日本に大規模なコールセンターを持つ。大昔からの歴史的な経緯で、それぞれ異なるベンダーの顧客管理システムを導入した。背景には複雑な政治的な問題があり、その問題を解決してシステムを統合するよりも、システムを別々に構築したほうがよいと判断した。

「正しい解決策だから受け入れられる」は子供の考え

重要な提案で必要なカタチへのこだわり（上）

　ユーザー企業A社が進めているシステム構築プロジェクトでの月例会議当日。ベンダー側でプロジェクトマネジャーを務めるN氏は、進捗遅れの説明をしなければならない。いつもは姿を見せないA社の部長も参加するそうで、N氏の上司はそわそわしている。だが当のN氏は平然としていた。

安易な「問い」がプロジェクトの破綻を招く

会議の回し方で乗り切るコツ（下）

　ユーザー企業E社でのシステム要件定義の場面。システム部門のメンバーが集まってアプリケーションやインフラの設計方針を検討している。その最中に新人がこんな質問を発した。「このインタフェースは標準に準拠すべきでしょうか？」。新人にとっては素朴な疑問である。ところが、この問いに全員が凍りついた。

難しい会議でツッコミをかわす三つのセオリー

会議の回し方で乗り切るコツ（上）

　様々なステークホルダーが一堂に会する会議を、いかにスムーズに回すか。プロジェクト運営ではこのスキルが欠かせない。特に「暗闇」の状態では、意見がまとまらないだけでなく、勝手な言動や行動を取る人が出てくるのは珍しくない。そんな状況でも会議を回すための三つのセオリーを紹介しよう。

ユーザーは「無知だが非常に頭が切れる」を前提に臨む

「二枚腰」でコントロールする現場マネジメント（下）

　この連載では、先が見えない「暗闇プロジェクト」を任された場合に参考になりそうなヒントやノウハウを紹介している。今回も現場マネジメントに関するセオリーを取り上げる。決定を急にひっくり返す、相手が非常に頭が切れる、旧来のレビューの進め方を適用しようとする場合にそれぞれどう対応すればよいかを見ていこう。

理不尽なユーザーの態度に振り回されない三つの極意

「二枚腰」でコントロールする現場マネジメント（上）

　「我々はITの専門家ではないので」。システム導入プロジェクトで、顧客やユーザーがよく口にするフレーズである。こう言っておくことで、何かあった場合の責任を回避したいとする担当者の気持ちが表れている。ベンダーは、こうした顧客の態度を嫌がるどころか、むしろ歓迎する。

多数決で仕様を決めて“炎上”、少数意見に目を向けよ

創作し合意する要件定義のテクニック（下）

　新人プロジェクトマネジャーA氏は、「現場ユーザーへの要件ヒアリングは準備が肝心」と考え、質問項目を思いつくまま10個、20個と挙げたリストを持って現場に臨んだ。ところが、その中で使い物になった質問は3、4個しかなく、残りは前提条件が全く違っていたなどで、その場では使えなかった。

予期せぬ“危機”に事前に手を打つ秘策

創作し合意する要件定義のテクニック（上）

　この連載では、先が見えない「暗闇プロジェクト」を任された場合に参考になりそうなヒントやノウハウを紹介している。今回と次回では、暗闇プロジェクトに役立つ要件定義の進め方を紹介する。この種のプロジェクトでは要件を創作し、合意していかなければならない。今回は、要求仕様に関する二つのセオリーを紹介する。

パターンが見えたと思ったら危険、「再現性」の追求はNG

現場での調査結果の整理・分析術（下）

　原因や理由、法則性を探究したい。こうした「法則化への願望」は人間の本能とも言えるものだ。しかし要求定義の特に初期フェーズで、「きっと何らかのパターンや法則が見いだせるはず」と考えてはならない。暗闇プロジェクトでは、パターンが見えた、と思ったら危険だと捉えるべきだ。

「客観的なデータ」は幻想、定量データは必要悪

現場での調査結果の整理・分析術（上）

　プロジェクトマネジメントでは、定量データに基づく管理が重要になる──。教科書の多くは、このように説明している。だが、暗闇プロジェクトでは、こうしたデータにこだわることがかえって足を引っ張るケースが少なくない。「数字」に振り回されずに、現場での調査結果をどのように整理・分析すればよいのか。

矛盾している回答はむしろ歓迎、ダメな「武器」も時に役立つ

ゼロから始める要求定義の現場心得（下）

　ユーザー（仕様ホルダー）からシステムに対する要求を計画通りに取得・整理できている。とても望ましい状況のように思えるが、暗闇プロジェクトではリスクの兆候と捉えるべきである。「暗闇」に挑戦しているのではなく、頭の中にでき上がっているテンプレートを現場に当てはめている可能性が高いからだ。

情報は「質」より「量」、ヒアリングで「なぜ」は禁句

ゼロから始める要求定義の現場心得（上）

　現代のシステム構築・導入プロジェクトの多くは、前例がない、あるいは経験がないといった、先の見えない「暗闇プロジェクト」と言える。この連載では、暗闇プロジェクトを任された場合に参考になりそうなヒントやノウハウを紹介している。今回と次回は、現場における要求定義の心得に焦点を当てて、六つのセオリーを紹介…

［ベンダー姿勢編2］意思決定に「内政干渉」する

　現代のシステム構築・導入プロジェクトの多くは、前例がない、あるいは経験がないといった、先の見えない「暗闇プロジェクト」と言える。この連載では、暗闇プロジェクトを任された場合に参考になりそうなヒントやノウハウを紹介している。今回は前回に続いて、ベンダーの姿勢に関するセオリーを取り上げる。

［ベンダー姿勢編1］「政治的」な見積もりを受け入れる

　「暗闇プロジェクト」では、事前に詳細なプランを立てるのは困難。サイコロを振ってでも、とにかく行動を起こすことから始めたい。プロジェクトに参加するベンダーは、「政治的」に決まった見積もりをあえて受け入れ、対応していく姿勢が大切だ。