motozono.com
ゾノドットコム

要求定義の肝

発注者のためのプロジェクト管理

• 日経コンピュータ（日経BP）の2009年7月8日号に寄稿した「発注者のプロジェクト管理」の元原稿です。

アーキテクトの仕事〜立ち上げ・要件定義

• システム開発ジャーナル（毎日コミュニケーションズ）の創刊号に寄稿した「アーキテクトの仕事〜立ち上げ・要件定義」の元原稿です。

要求定義のエクササイズ１３６

• 2006年に出版した「要求定義のエクササイズ１３６」の元原稿の一部です。最終校正前の原稿なので、粗さも目立ちますがご了承ください。

顧客対応の掟と極意１５３

• 2008年に出版した「顧客対応の掟と極意１５３」の元原稿の一部です。

著書

なぜ今、「発注側のプロジェクト管理」なのか

工事進行基準の適用が始まった。システム開発における数々のグレーゾーンを排除するために、ベンダにはこれまで以上に高いプロジェクト管理能力が求められることになる。この影響は当然、発注側にも及ぶ。役割分担や要件のグレーゾーンの扱い、仕様変更の扱いなど、これまで発注側の「ごり押し」で通ってきた要求が、（良いか悪いかは別として）簡単には通らなくなってくる可能性が高い。発注側としても、この状況に対応するために、問題定義や要件の明確化およびステークホルダーの調整など、総合的な"上流"の能力を高めていかなければならない。

さて、困難な要件定義が完了したとしよう（※要件定義自体が難題ではあるが、今回のテーマからは外れる）。ここで発注側の仕事は終わりだろうか。あとは進行基準があるのだから、それに則ってベンダがきっちりと仕事を進めてくれるのを待っているだけでよいのだろうか。残念ながら否である。アウトプットや"進行基準"が固められたからといって、建設業界のように「あとはお任せ」にはならない。システム開発における不確実性は、ビル建設の場合とは比べ物にならないくらい高い。ルールができたからといって、もともと困難な作業が簡単になるわけではないのである。

確かにルールが明確になっていれば、計画から逸脱した場合、あるいは仮にプロジェクトが失敗した場合でも、「契約違反」としてベンダを責めることはできる。しかしそこに意味はない。発注側にとっては、システム開発の成功だけが重要なのである。

進行基準の適用はベンダのマネジメント能力を向上させ、プロジェクトの成功率を高めてくれると期待できるかもしれない。しかし「期待」の上にあぐらをかくわけにはいかない。発注側はこれまで通りに、ベンダ管理を実施していかなければならない。否、これまで以上にプロジェクトの状況（＝ベンダの開発状況）に注意を払い、問題があれば積極的に改善要望をあげ、その実施状況や効果を注視していくべきである。その理由は以下の通りである。

• ベンダのパワーが進行基準の適用に割かれることによって、"成果物作成のための実質的な作業"やその管理が手薄になる可能性がある。
• 進行基準の適用にプレッシャーを感じての"にわか勉強のプロジェクト管理"によって、かえって現場が混乱する可能性がある。
• ベンダの意思決定の判断基準において、「進行基準の遵守」が「顧客満足度」よりも（実質的に）上になる可能性がある。

ベンダへのリクエストが不発に終わるパターン

発注側によるプロジェクト管理（＝ベンダへの詳細リクエスト）の最終的な目的は、もちろんシステム開発を成功に導くことにある。スケジュール、スコープ、品質、コストといった各種のプロジェクト目標を、当初の計画通りに達成することである。そのために、発注側が現場の状況、そしてプロジェクト管理の状況を詳細に把握することによって、ベンダが気づかなかった問題の芽を発注側の視点で発見し、ベンダに対して早期の対策立案をリクエストしていくようなアクションを推進していくべきである。

しかし発注側にとって、これを実現するのは口で言うほど簡単なことではない。一般にそれはベンダ側マネジャーの縄張りに踏み込むものであり、契約で明確に謳われていない限り、発注側からはなかなか口を出しにくい領域である。改善の要請どころか、それ以前の実態の把握ですらままならない場合も多い。たとえ実態を把握して改善要望を出したとしても、それが受け入れられるかどうかはベンダ次第である。さらに、対応策が出てきたとしても、それが本当に効果のあるものかどうかは別問題である。

以下、具体的な事例を見てみることにする。

１．現場の開発実態を把握することの困難さ

まずは、ベンダにリクエストを出そうにも、それ以前の状況把握からままならないという状態である。

【事例】

定例会は週に一回開かれていた。ベンダからは作業概況、課題、対策、それに今後の予定といったところが報告されてくる。しかし発注側としてはこの内容に不安を抱いていた。報告を聞く限り、プロジェクトには何の問題もないように思えるのだが、それを疑わせるような事実の断片が見え隠れしていたのである。

例えば、プロジェクト計画書の出来である。ページ数はそこそこあるものの、その内容はほとんどが一般論であり、「今回のプロジェクトだからこそ」といった独自の記述はほとんどなかった。概して粗い内容である。定例会で配布される報告資料も同様に粗い内容であり、先週とほとんど記述が変わらない箇所も多い。課題があっても、その対策の欄には具体的な記述はなかった。

マネジャーの質疑応答も不安を抱かせる要素の一つだった。どんな質問にもよどみなくもっともらしい答が返ってくるのだが、結論は皆一様であり、「問題はない」というものであった。つまり、悪いニュースがベンダから報告されることが皆無なのである。

現場からは、様々な課題や今後の懸念といった話が少しずつ漏れ伝わってきていた。ところがベンダのマネジャーにその話を向けてみても、「問題ありません」とかわされてしまうだけである。現場の担当者が神経質なだけなのか、マネジャーが現場の状況を掴んでいないのか、掴んだ上でひた隠しにしているのか、わからない状況であった。

２．ベンダに改善要望を受け入れてもらうことの困難さ

次に、状況を把握して改善要望を出したとしても、それがなかなか受け入れられないという状態である。

【事例】

報告資料の記述が「薄い」件については何度か改善要望を出しているものの、ベンダ側の動きは鈍いままであった。「どこがダメなのか」「ダメならば具体的な書き方を指示してくれ」とまで言ってくる。要するに発注側の要望をすんなり受け入れる気がないのである。また、受け入れられたと思っても、約束がすっぽかされるのは日常茶飯事であった。ようやく対応してくれたと思ったのもつかの間、しばらくすると元に戻っていることもしばしばであった。

問題を指摘し、問題認識を共有し、改善要望を出しても、なかなか効果的な策が提案されることはなかった。こちらから策を提案しても、そのデメリットばかりが指摘されて、すぐに却下されてしまう。かといってベンダから代案が出てくるわけでもなかった。

発注側はマネジャーの交代を望んでいたが、請負契約の下では、それをベンダに要請することはできない。「プロジェクトの状況が悪い」ということをしつこくベンダの上層部に伝えて、それとなく交代を匂わせることができるだけである。しかしベンダの上層部も、更なる内政干渉を恐れてか、「状況が悪い」という事実でさえも「リカバリ可能」ということで、なかなか認めたがらなかった。

３．改善策によって事態が改善することの困難さ

そして最後に、ようやく出てきた改善策も役に立たないという状態である。

【事例】

プロジェクトに改善の必要性があることをようやくベンダにも認めてもらった。しかしここからが一苦労であった。ベンダからは解決策がなかなか出てこないのである。ようやく出てきたと思ったら、真剣に考えられていないことがすぐに分かるような安易な策ばかりである。

まず、どのプロジェクトでも通用するような一般論の策である。遅延の発生という課題に対しては、「追加資源の投入」あるいは「タスクの並行実施」といった策である。きちんと詳細まで具体化され、本当に実行に移されるならば有効な策となるのだが、具体的なリソースやスケジュールの計画には全く踏み込むことなく、一般論をかざされただけで終わってしまう。

そして「頑張って回復します」という精神論の策である。「残業にてリカバリ」や「休日出勤でリカバリ」といった策である。しかし、これらの策が何ら根本的な課題解決になっていないことは自明である。原因には何ら言及していないのである。やがて同じような課題が再発することは容易に想像できる。

次に、コインの裏返し的な策である。「人が不足している」から「人を投入する」、「品質が悪い」から「品質向上策を打つ」といった「言葉遊び」のような策である。実質的には何も言っていないに等しい。

発注側はベンダの策に疑問を抱きながらも、「これで解決します」と断言されると、それ以上踏み込むことはできなかった。当然、プロジェクトの状況は一向に改善されることはなかった。

ベンダへのリクエストに立ちふさがる2つのハードル

こうした状況に対応するためには、本来であれば、発注側として、以下のようなリクエストを出す必要がある。

• 現状の正しい情報を引き出すために、「曖昧な回答ができないような詳細まで踏み込んだリクエスト」を出す。
• 改善策の策定に動かすために、「改善の必要性を受け入れざるを得ないような事実を根拠とするリクエスト」を出す。
• 策の有効性を高めるために、「改善策の因果関係のロジックを追求するリクエスト」を出す。

ところがいざ実際にこのようなリクエストを投げようとすると、発注側には大きなハードルが立ちはだかる。契約の壁と、発注側スキルの欠如という壁である。

１．契約の壁

契約の壁とは、請負契約の壁を意味する。システム開発における一般的な契約形態である請負契約では、契約に特段の記述がない限り、原則としてプロジェクトの途中でベンダの作業に口出しすることはできない。最終成果物に対してモノを言うことはできるが、その作成過程や中間成果物には口を出すことはできない。定めがない限り、進捗の報告でさえ義務ではない。

とは言うものの、システム開発ではこの解釈は曖昧になっている。契約書に明確な記述がなかったとしても、定例会で発注側がベンダの作業の進捗状況を確認するのは普通の姿である。中間成果物の品質評価を要求することもある。契約にはなかった報告書を作成させることもある。多い少ないはあるが、こうした口出し自体は暗黙の了解になっていると言えるだろう。しかし、法的にはこれらのリクエストには根拠がない。ベンダは断ろうと思えば堂々と断ることができる。

発注側がベンダ作業のブラックボックスにリクエストを出そうとしても、契約を盾に拒否される可能性がある。これが第一のハードルである。

２．発注側スキルの欠如

そもそも発注側は、自前でのシステム開発を（戦略として）放棄したからこそ、請負契約でベンダに依頼している場合がほとんどである。しかしシステム開発スキルの欠如は、ベンダに対するリクエストの質にも影響する。見当外れのリクエストは、単に現場の負荷を重くするだけに終わってしまう。

例えば、進捗報告であるタスクの遅延が報告されたとする。ここで「遅延回復してください」というリクエストは正しいものではあるが、当たり前すぎてプロジェクトにプラスの影響を与えるまでにはいかない。リクエストは、「そうでなければ動かなかったであろうベンダを動かす」ものでなければならない。プロジェクトにプラスの影響を与えるものでなければならない。では、どんなリクエストであれば、ベンダを動かすことができるのだろうか。それを考えるのは、スキルが欠如している発注側にとっては克服が難しいハードルである。

発注側に現場のスキルが欠如しているために、ベンダに対して質の高いリクエストをすることができない。これが第二のハードルである。

１．契約の壁を乗り越えるための方針

契約の壁を乗り越えることはできない。ただしシステム開発においては、「請負契約であってもある程度の干渉は認める」という暗黙の了解が双方に存在している。実はベンダにとっても、発注側の干渉は検収時のリスクが低下するというメリットがあるのである。ただし、それが暗黙の了解に依存する以上、そこには双方の納得感や説得力というものが必要になってくる（※あるいは力関係が大きなウェイトを占めることになる）。

どのような根拠や裏付けがあれば、発注側のリクエストに対してベンダも納得し、協力してくれるのだろうか。もちろん、契約書に明記しておくことである。しかし、契約時点では具体的な作業内容もベンダのスキルも見えていないことが多い。そこで有用な“ツール”となるのが各種の計画書である。契約の縛りによって強権的にリクエストを発するのが困難な場合でも、計画書に書いてもらえばそのリクエストも（しぶしぶかもしれないが）呑んでもらえる可能性は非常に高くなる。計画書に中間報告会の実施が記してもらえば、契約書にその記述がなくても、中間成果物を確認し、その内容にリクエストを出すことも可能になる。

計画書の承認とは、後々のリクエストを可能とするための"仕組み作り"の重要な機会なのである。内容をベンダ任せにしていてはいけないし、安易に承認してもいけない。妥協なく仕上げるべき仕事である。プロジェクトの成否がここで決まるくらいの意気込みでコトに当たるべきである。

【事例】

開発が始まったばかりだというのに、発注側とベンダの関係は冷え切っていた。本開発に先だって実施された準備フェーズにおいて、様々な問題が発生し、それが深刻な相互不信を招いていたのだ。

双方が「約束が違う」と感じている。双方が疑心暗鬼の状態に陥っている。かくしてベンダはきっちりとスコープ固めに走り、そして大げさに言えば、それ以外のことは何もするつもりがなかった。発注側が品質に疑問をもって、中間成果物を確認させてもらおうとしても、請負契約を盾に断るような状態であった。

本来であれば今後の展開を心配して、発注側のマネジャーには相当なプレッシャーがかかる事態だが、このマネジャーは落ち着いていた。実はプロジェクト計画書を承認するにあたって、発注側として押さえるべきところをきっちりと押さえていたのだ。発注側として必要な成果物の機能要件や非機能要件が、要件定義書の詳細な記述如何によって左右されることのないように、大レベルの記述で「要件を定義」していたのである。

計画書の記述に関しては、発注側の要求に対してベンダも多少の抵抗はしたはずである。しかしどこまでの重要性の認識をもって抵抗したであろうか。一方、発注側のマネジャーはここがプロジェクトの勝負どころということを知っていた。そして妥協せず、発注側の意向をプロジェクト計画書に反映させた。この時点で、勝負ありであった。

２．発注側スキル欠如を乗り越えるための方針

ベンダに任せっきりにしていたために問題の発覚が遅れ、結果として失敗プロジェクトに陥ってしまう。こうした事態を防ぐために、発注側からの不断の監視とリクエストが必要である。ではどのようなリクエストをすればプロジェクトの危機を未然に防ぐことができるのだろうか。スキルのない発注側はここで途方に暮れてしまうかもしれない。設計書を見せてもらっても、ソースコードを見せてもらっても、手も足も出ない。確かにこのレベルでベンダにリクエストを出そうとするのであれば、スキルを持っていないと難しい。しかし実は、そこまでのスキルを持っていなくても、持っている場合と同等に近い「結果」を残すことは可能なのである。

質問するだけでいいのだ。極論を言ってしまえば、たとえベンダからの回答を理解できなくてもよい。更に、回答を理解できないことをベンダが知っていても構わない。回答を文書の形でもらうだけでいいのだ。

あなたは部下に対して情報処理試験の合格を命じなければならないとする。このとき、あなたは試験の概要さえ知らなくてもよい。勉強の計画を提出させればよい。計画の具体的な中身が理解できなくても構わない。あとは「日々、勉強の進捗記録をつけること」「あとで記録を提出すること」命じておけばよい。たまに状況を確認するだけでよい。たまに質問をしてみるのもよい。質問をしてみて、部下がきちんと解答できるかどうかを確認してもよい。この場合もあなたは問題を詳しく知っている必要はない。部下の解答の正誤を評価する必要もない。「いつでもその解答を評価することができるぞ」という雰囲気を匂わせておくだけでよい。あるいはそれさえも必要ないかもしれない。

単純に言ってしまえばこういうことである。個々の詳細を知っている必要はなく、何を質問するか、何を依頼するか、何を確認するか、それさえ知っていればよいのである。これは個別の業務、個別の技術に依存しないプロジェクトマネジメントの知識である。たとえ自身に現場のスキルがなくても、こういったマネジメントの知識を活用することによって、相手が保有するスキルを相手に使わせることができるのである（※ただし実際の活用にあたっては、シチュエーション別の体系化が欠かせない。後項参照）。

ベンダを動かすには質問が一番である。ポイントを突いた質問であればベンダも回答せざるを得ない。「よい」質問であれば、回答するためにはベンダに何らかの作業が発生する。発注側の狙いは、まさにその作業をベンダにしてもらうことである。依頼してその作業をしてもらうよりも、質問をしてその作業をしてもらうほうが、余程受け入れられる可能性が高くなる。

【事例】

ベンダ側のマネジャーのほとんどは"メインフレーマー"で、長年ベンダ主導でプロジェクトを進めてきた経験しか持たない人ばかりであった。当然、発注側から詳細なリクエストや管理といったものを受けてきた経験はほとんどない。報告内容もスパンも粒度もアジェンダも全てがベンダ主導であった。一方、そんなベンダに引きずられて、発注側もそれが当たり前の状態だと思っていた。

こうした状況でベンダに対して詳細なリクエストをし始めたところ、当然のごとく抵抗に遭うことになった。その場ではしぶしぶ肯定的な返事をしておきながら、実際のアクションは何も起こさない。目に見える問題が生じているにもかかわらず、「問題が生じていないのに、なぜ今のやり方ではダメなのか」と疑問を呈する。

厳しい環境ではあったが、事実を提示し、ロジックを固めながら、ベンダへのリクエストを辛抱強く続けていったところ、少しずつではあるがベンダの姿勢に変化が見られ始めた。理屈の通った詳細なリクエストが、ベンダにとって当たり前の姿になってきたのである。ベンダの行動にも、徐々に変化が表れてきた。報告の粒度や、質問に対する回答の質も改善されてくる。リクエストが実際にプロジェクトに貢献するものだということがわかってくると、各種の提案も受け入れられるようになってくる。

こうした変化は、当然成果物の品質にも反映される。現場を知らない発注側にとっては、ベンダから提出されるドキュメントは、状況を判断するためのほとんど唯一の手段であるが、この品質向上は当然ベンダに対する評価の変化につながっていった。相互の誤解なども生じにくくなり、当初は険悪だったユーザとベンダの関係さえも徐々に改善されていった。

システム開発のスキルが欠如しているというハードルは、プロジェクトマネジメントの知識によって十分に乗り越えられるのである。ではそれはどのような知識だろうか。以下、ベンダへのリクエストの具体例を見てみることにする。

ベンダを動かす"詳細リクエスト"の具体例

以下に紹介する詳細リクエストの具体例は、数多くのプロジェクト管理の教科書の知見と、筆者の現場の経験をインプットとして、シチュエーション別に体系化したものの一部である。紙面の都合上、限られた内容になっているが、イメージを感じ取っていただけたらと思う。決してシステム開発スキルに依存するものではない。

まずは「そのタスクで初めての遅延」か、それとも「先週に引き続いての遅延」かによって対応が分かれる。前者の場合は、まずは報告の信頼性を確認した後で、原因の確認が最初の仕事となる。後者の場合、つまり以前から報告されていた遅延が今回も解消されていない場合は、更にそれが縮小傾向にあるのか拡大傾向にあるのかによって、対応は分かれる。縮小傾向にあるならば、静観していてもよいかもしれない。拡大傾向にあるならば、その原因を確認するために、プロジェクトの「様々な側面」に対して、ベンダに詳細な質問をする必要があるかもしれない。

さて、ここでは「そのタスク初めての遅延発生の場合」だけを例として取り上げることにする。発注側の対応は、以下の図のようなステップとなる。もちろんこれが唯一の正解というわけではなく、あくまでもリクエストのシナリオの一例である。どのようなステップになるかは、プロジェクト管理の一般的な知識を"マニュアル"へと落とし込む際の、その「落とし込み方」次第である。順番が変わることもあるし、並列で実施されることもあるし、別のステップが入ってくることもある。

ただし、上記の抽象度のリクエストでは「本当に」スキルが欠如している担当者が、ベンダに対して具体的で効果的な質問をしていくのは難しいだろう。そのような組織では、ステップごとに更に詳細な「質問することリスト」や「確認することリスト」を作成しておく必要がある。

「報告の信頼性を確認する」ステップであれば、

• 何月何日時点での進捗か？
• 誰がいつどのようにして獲得した情報か？
• 報告スパンが1週間単位なのに、急に5日遅延などということになっていないか？

といった質問／確認項目が考えられる。「報告の信頼性を確認する」ためには、「どのような質問をベンダに投げるべきか」「どのような事を確認すべきか」を考え、「質問すべきこと」「確認すべきこと」をリストアップしていく。「ネタ」に困ったら、巷に数多く存在しているプロジェクト管理の参考書からヒントを得るのである。

「遅延の原因を確認する」ステップであれば、

• 遅延の直接の原因は何か？
• 遅延の根本の原因は何か？
• 遅延にはどんなステークホルダーが絡んでいるのか？

といった質問／確認項目が考えられる。

「原因を分析する」ステップであれば、

• ベンダの原因分析の信頼性はどのように判断すべきか？
• 根本原因と直接原因の因果関係は正しいと思われるか？
• 要条件と十分条件と寄与条件の錯誤はないか？
• 原因分析は一般論レベルで止まっていないか？

といった項目が考えられる。この項目は質問／確認のためのものというよりも、発注側が自ら考察し、判断すべきものかもしれない。

上記の例では、「原因を分析する」ステップの後は3つのステップを並行して実施することになっている。もちろんこれも唯一の正解ではない。組織やマネジャーの考え方や好みによって分類の仕方も項目も違ってくるだろう。あくまでもサンプルであり、一つの例にすぎないが、それぞれのステップでの質問／確認項目は以下の図のようになる。当然、項目の追加や修正の余地は十分に残っている。更に一階層、二階層、レベルを下げて詳細化することもできる。

おわりに

ルールの変更は現場に影響を及ぼす。工事進行基準がどのような変化を現場に及ぼすことになるのかは予測の域を出ないが、発注側としては常に最悪の状況を想定して対策を打っておく必要がある。「発注側のプロジェクト管理」とは、「これはベンダの仕事だ」などと役割に拘泥することなく、「最良の結果を得るためにできること」を発注側自ら積極的に考えていくためのものである。そしてベンダに対する"詳細リクエスト"はその具体案である。リクエストの多くはベンダにしてみれば「言われなくてもやっています」というものかもしれない。しかしそこにあえて詳細な確認を入れていくことによって、プロジェクト目標の達成が確実なものになる。紙面の都合上、十分な説明ができたかどうか不安が残るところであるが、エッセンスだけでも掴んで頂けたらと思う。

はじめに

ITをめぐる技術革新は、システム開発のみならずビジネス環境にも大きな影響を与えています。ITをいかに活用するかがビジネス戦略における重要な課題になってくると、システムに期待される要件も複雑化・高度化していき、それはシステム開発をさらに難しいものにしています。複雑化するシステム開発に対応するために、個々の作業が次第に専門化していくのは必然の流れですが、それは様々な側面で個別最適化を進めてしまうリスクを伴うものです。

ITアーキテクトの役割は、この個別最適化のリスクを回避しつつ、複雑なビジネス要件を実際のシステムに落とし込むまでの先導役あるいは橋渡し役を務めることにあります。その参画は概ね、ユーザや経営コンサルタントによって経営課題が分析され、ITとの接点が見え始めたところから始まると言ってよいでしょう。

ITアーキテクトがなすべき最初の仕事は、IT全体戦略を策定あるいは理解し、当該システムの目的と意義を明確にすることです。何のためにシステムが必要とされているのかを明確にした上で、業務およびシステムのアーキテクチャを設計していく上での前提条件となる要求を抽出し、整理することです。では、プロジェクトの上流工程におけるITアーキテクトの仕事について見ていくことにします。

１．IT活用目的の絞り込み

ひと昔前であればコンピュータ導入の目的と言えば省力化であり業務効率化でした。しかしメインフレームオンリーの時代からC/S、Webシステムへと新しいアーキテクチャの登場と合わせるように、コンピュータの使用目的も多岐にわたるようになってきました。

会社が蓄積している大量のデータをいかにビジネスに役立てていくかという情報活用支援や、経営層による企業の舵取りをサポートするための意思決定支援、新たな事業やサービスを生み出すための付加価値創造支援や、業務プロセス標準化のための支援、従業員の能力開発支援など、その目的は様々です。

IT活用の可能性が広がるにつれて、その目的を明確に定めることは難しくなります。往々にして要件は過剰になりますが、そのリスクは皆さんもよくご承知のことでしょう。プロジェクトは困難を極め、ようやく稼働にこぎつけたシステムも期待はずれという結果になりがちです。このような事態に陥らないためにも、ITアーキテクトは早期にステークホルダーを巻き込み、IT活用の目的を明確にし、その認識を共有していく必要があります。

ポイントは目的を絞るということです。5つも6つもの目的を課せられたプロジェクトは、具体化・詳細化の工程で混乱を引き起こしかねません。確かに目的を絞るのは困難な仕事です。「とりあえず現時点ではそれも入れておけばいいじゃないか」「無理だとわかった時点で考えればいいじゃないか」という意見に抗するのは簡単ではありませんが、ここは最初の踏ん張りどころです。

絞り込みのヒントとしては、事業のライフサイクルの観点から目的を検討することです。ライフサイクルが異なる段階にある企業は、それぞれIT活用の目的が異なるものです。例えば事業創造段階であれば事業創造のためのシステムが必要です。成長段階であればベースの事業を拡大するための標準化や形式化が課題になりがちです。成熟段階であれば無駄なコストを削減し、効率化を図ることが求められます。再編段階では事業の統合などを想定したシステムが必要になるかもしれません。企業のそれぞれの段階にマッチした目的で推していくと、納得感が得られ、コンセンサスも得やすくなります。

２．コストと効果の評価

IT活用の目的が明確になったら、期待される効果が投資に見合うものかどうかを検討します。効率化・省力化のためのシステムであればこの判断は難しくはありません。しかし付加価値創造支援などのシステムでは、効果との因果関係を明らかにするのは困難です。それでも可能な限り、効果を数字で表すことを考えなければなりません。投資が回収できるかどうかは、数字でなければ判断できないからです。

次に考えるべきは投資の効率性です。同じ投資でも、他の分野への投資の方が高い効果が見込まれるならば、このプロジェクトへの投資の必然性は薄れてしまいます。投資が効果的であるだけでは不十分です。他の選択肢と比べても効果的であることが必要です。

最後に考えるべきは投資のリスクです。プロジェクトが計画通りに進まなかった場合、事業の存続までもが議題に上がるようであれば、開始には十分に慎重になるべきでしょう。既存業務や他のビジネスへの影響、さらに中長期的な将来の維持管理の負担を含めて総合的に検討すべきです。

１．全体最適化の必要性

IT活用の目的が定まったら、全体最適化の方針でそれを達成していくことを考えます。上流工程における全体最適化とは、業務（IT活用目的）とシステム双方の最適化を意味しています。目指すところは、ITの活用によって業務のアウトプットの最大化を図ること、そしてそれと同時に、最も効率的なシステムの開発を実現することです。

業務における全体最適化についてですが、部門ごと業務ごとの個別最適化の弊害は指摘されて久しいものがあります。個々の業務がそれぞれ独自の効率化・省力化を追求するが故に、情報の連携やプロセスの統一化など、全体としての最適化が実現できていない状態です。

業務が個別最適化されている状況は、そのまま情報システムの構造に反映されています。全社で統一すべきポリシーが各部門で異なっていたり、全社で共有すべきデータが個々のシステムで個別に管理されています。複数のシステムで同じような業務をバラバラに処理しています。このような冗長なシステムを維持するための負担や、全体最適化されていれば得られるはずだった機会利益は、個別最適化のメリットを大きく上回っているものです。

全体最適化を目指してプロジェクトを進めていくためには、当然ながら個別部門の協力が必要です。そのためには、情報の連携や共有化など、全体最適化をがもたらすメリットを部門の立場から説明することが必要です。また、中長期的なシステム化計画の中で、全体最適化の方針が明確に盛り込まれている必要もあります。

また、全体最適化への動きを妨げるような仕組みの排除も必要です。例えば、全体最適化を進めると個々の業務のサービスレベルが低下したり、現場に新たな負担を強いたりといった問題が発生するものです。こういった問題が部門の評価を下げてしまう仕組みがあるならば、現場では個別最適が最善の選択になってしまいます。評価体系の見直しなど、インセンティブの仕組みから再考しなければならないということです。これはITアーキテクトの手に余る仕事かもしれませんが、関係者への積極的な提言を考えるべきです。

IT活用の目的を明確にし、全社的に全体最適化へのコンセンサスが得られ、そのための課題が見えてきたならば、いよいよ具体的な要求の抽出に入ります。これまでの考え方では、要求フェーズでは顧客の目的やニーズを明らかにすべきであって、実現手段には言及すべきではないというものが一般的でした。明らかにすべきはWhatであり、Howは以降のフェーズで考えるということです。これは、先に実現手段を検討することによって、そもそものシステムの目的やニーズが手段に引きずられてしまったり、他の有効な解決策を検討する余地がなくなってしまうというリスクがあるためです。

しかし様々なベンダーの製品を組み合わせてシステムを構築することが当たり前になってくると、「実現手段は後で」などと悠長なことは言えなくなってきました。組み合わせが自由であるだけに、選択には様々な考慮が必要です。業務の特性や求められる信頼性、具体的な運用計画、投資の許容範囲、全体最適というコンセプト、開発期間の更なる短縮、製品同士の相性、トラブル発生時の対応、中長期的なシステム化計画、など多岐にわたる検討が必要になります。つまりスタート時点から既にHowが重要なのです。

要求の獲得

１．要求獲得の方法

他システム連携やIT基盤の要件を固めていくためには、ITアーキテクチャにそれだけの技術的なバックボーンが要求されます。しかし業務が異なっても基本的な要求定義の作業の本質が変わらないのと同様、アプリケーション分野で蓄積された要求定義のノウハウは、テクニカルな領域においても有効です。

要求獲得の方法は以下のように様々です。業務やステークホルダーの特性に合わせて、適宜組み合わせながら進めていきます。

• 資料収集
• アンケート
• インタビュー
• 現場観察
• FIT&GAP分析
• 業務フロー分析
• ユースケース分析、シナリオ分析
• 会議
• ブレーンストーミング
• カード（KJ法）
• プロトタイピング
• 電子掲示板
• 既存のシステムの分析

２．要求の分類

獲得されたばかりの要求は、テーマも粒度もまちまちです。事業の中長期計画を見据えた戦略的な要求もあり、個別システムの詳細機能に関する要求もあります。

システムコンセプトレベルの要求と、画面項目レベルの要求を同じ議題のテーブルに乗せたり、異なる事業の要求を個別最適の視点で扱ったりすると、混乱してどこから手をつけてよいのかわからなくなってしまいます。まずはこれらの要求を整理することから始めなければなりません。ここで重要なのは、一つの切り口だけでなく複数の観点から分類することです。

獲得した要求は分類し、整理し、型に当てはめてみます。ある要求がぴったりと型にはまっているにもかかわらず、同じような別の要求には型との「隙間」が見つかれば、それは要求漏れを意味しているのかもしれません。型からはみ出ているのであれば、過剰な要求を意味しているのかもしれません。あるいは型（コンセプトや基本方針）に問題があるのかもしれません。

要求を分類する際には、以下のような切り口が考えられます。要求が膨大な場合は更なる細分化を検討します。

• コンセプト
  • 経営目標・・・ビジネス戦略に関する要求です。
  • 全体最適化計画・・・組織、業務プロセス、システムにおける全体最適化に関する要求です。
  • システム化計画（中長期）・・・グランドデザインやライフサイクル、ITアーキテクチャのポリシーに関する要求です。
  • システム化計画（短期）・・・スケジュールや投資可能額に関する要求です。
    
    
• アプリケーション
  • ビジネスプロセス・・・業務の進め方や業務同士の連携に関する要求です。
  • 機能要求・・・システムが実行すべき処理、システムがなかった場合に人手で行うべき仕事に関する要求です。
  • 非機能要求・・・信頼性、使用性、効率性、保守性、移植性など品質に関する要求です。
  • 運用・監視・・・運用、監視の方法やコストに関する要求です。
    
    
• インテグレーション、インフラストラクチャ
  • システム連携・・・業務面およびIT基盤面での、他システムとの連携に関する要求です。
  • IT基盤・・・ミドルウェア、ソフトウェアプロダクト、OS、ハードウェアなどに関する要求です。

要求の妥当性の確認

１．スコープ明確化の重要性

獲得されたばかりの要求にはステークホルダーの生の要望が反映されていますが、IT活用の目的に対して、曖昧であり、過剰であり、あるいは不足であり、相互矛盾が含まれ、構造化されていないのが普通です。アプリケーション要求であれば、これらの要求をコンピュータが理解できるような形に変換してあげなければなりません。IT基盤に関わる要求であれば、システム化計画との整合性を確認していかなければなりません。そしてどちらの要求も、全体最適化の視点から再構成していかなければなりません。

曖昧な輪郭を持つ要求に対して、どのような基準や根拠で境界線を引いていけばよいのでしょうか。境界線の引き方を決めること、そして実際に境界線を引いていくこと、境界線が引かれた要求を理解しやすい形に構造化していくこと、これが次フェーズに作業を引き渡すための要求分析の責務です。ここで、不要な要求は境界線を引いてスコープから除外しなければなりませんが、必要であるはずの要求が漏れていればスコープに追加しなければなりません。その作業を遂行する上で最も強力な根拠となるものが、IT活用の目的であり、全体最適化を中心とするプロジェクトのコンセプトです。

２．アプリケーション要求の最適化

獲得されたばかりの要求には、個別最適化された要求や個人的な要求が含まれているものです。こうした要求は当然のことながら境界線の外に出すか、全体最適の方向に修正されるべきものです。こうした要求を「どうせ一括で開発してもらうのだから一緒に入れておけばよい」という考え方もありますが、これはいただけません。

プロジェクトマネジメントの観点から考えると、先々必ず発生するであろう追加変更要求への対応が難しくなることが挙げられます。システムの目的という原理原則に従わない要求をスコープに含めることによって、「何を開発し、何を開発しないのか」という重要な方針を自ら捨てていることになります。

設計・製造の観点から考えると、目的外の要求を開発スコープに含めるという事は、本当に必要な要求に使用できるリソースが減ってしまうということです。重要性の薄い要求に対応するために、本来開発可能であったはずの機能が縮小されたり、可能であったはずの品質レベルをあきらめたり、といった事態が生じてしまいます。

ユーザの観点から考えると、システムの使い勝手に影響する可能性があります。システムの統一性が薄れ、単に「個人最適化」された機能の集まりになってしまうと、「この機能にできたことがなぜあの機能ではできないのか」「なぜこの機能とあの機能では操作方法が違うんだ」といったことになりかねません。

こうした理由から、要求からは可能な限り不純物を取り除かなければなりません。ある要求をシステムの目的に照らし合わせたときに、直接的にあるいは間接的にでも、きちんと整合性が取れているのかどうかを確認することが重要です。

３．要求の妥当性の確認

さて、分類された要求は、「次の工程に引き渡す」に値するものかどうか、その妥当性を判断しなければなりません。品質が低い要求の集まりは、以降の工程の作業を、不必要に複雑かつ難解なものにしてしまいます。まずは下記の項目について分析を行います。要求の品質を向上させ、構造の理解が容易な、シンプルな要求群に仕上げることが肝要です。

整理が終わった要求は、システムの目的への貢献度や費用対効果、相対的な利益・不利益、リスクなどを考慮して優先順位付けを行います。これらの作業は各ステークホルダーを巻き込みながら行っていくことが大切です。

• 要求の正確性
  • 獲得された要求および要求の記述が正確であり曖昧でないことを確認します。
  • 記述の曖昧さ・・・顧客の要求を曖昧さのない明確な日本語で正確に表現しているか。
  • 解釈の曖昧さ・・・要求の記述は複数の意味に解釈されることはないか。
  • 要求の曖昧さ・・・要求自体に曖昧さはないか。
    
    
• 要求の一貫性
  • 相互に矛盾している要求がないこと、要求がIT活用目的やシステム化のコンセプトに対して整合性が取れていることを確認します。
    
    
• 要求の最小性
  • IT活用目的やシステム化のコンセプトに不必要な要求が混入していないことを確認します。また、冗長な要求が存在しないことを確認します。
    
    
• 要求の十分性
  • 設計が可能な程度にまで要求が詳細化されていることを確認します。
    
    
• 要求の完全性
  • システム化の目的に対して必要な要求がすべて抽出されていることを確認します。
    
    
• 要求のテスト可能性
  • 要求が現実的にテスト可能であることを確認します。
    
    
• 要求の実現可能性
  • 要求が技術的に開発可能であることを確認します。スケジュールやコスト、リソースの面から検討します。

妥当性の確認までを完了した要求については、各ステークホルダーに再確認を依頼します。確認にあたっては、くれぐれも個別最適化された視点に陥らないように周知徹底しておきます。利用できる機会はすべて利用して、IT活用目的や全体最適化のコンセプトを、しつこいくらいに各ステークホルダーの頭にインプットしておくことです。

まとめ

システム開発の上流工程において、ITアーキテクトが関与すべき作業や意識すべき点について検討してきました。この工程におけるポイントは、目的を明確にすること、目的に対して全社的なコンセンサスを獲得すること、そしてこのポイントを外すことなく、技術的な視点からプロジェクトを引っ張っていくことです。

さて、次工程を想定した要求作業の心得は、「いかに分析・設計が容易となるプロジェクトの素地を整えておくか」です。あるべき姿を追いかけながらも、地に足がついた現実解への道筋を一歩一歩確立していくことによって、分析・設計作業への最適な環境を構築することができます。ロスの少ない効率的な引継ぎのためにも、この最適環境の構築を意識しながら作業を進めていくことを心がけましょう。

GUIが当たり前のものになり、コンピュータの操作性は格段に向上しました。コンピュータの利用目的自体も、単なる省力化や業務効率化といったわかりやすいものから、情報活用や経営管理、付加価値創造など、効果がわかりにくく複雑なものへと広がっていきました。ソフトウェアの要求仕様は客観的で容易に確定できるものから、主観的でいかようにも変更されうる曖昧なものへと変わっていったのです。要求定義の作業負荷は明らかに高くなりました。確認・検討しなければならない項目は大幅に増え、確定したはずの要求が変更される率も高くなりました。

今やソフトウェア開発における最大の懸念は、設計や製造の問題から要求定義の問題に移ったと言ってもよいでしょう。現在、この問題を解決すべく日々様々な開発手法が提案され、試行錯誤の真っ只中にいることはご承知の通りです。

しかし要求定義は難敵です。設計や製造で一定の効果を上げてきたはずの「手法を開発するための手法」すなわち工学的な手法がなかなか通用しないのです。要求定義を巡る議論は停滞し、出口のない迷路に迷い込んでしまったかのようです。本来ならばここで一旦立ち止まってみるべきです。どんなに考えても答が見つからないならば、問いが間違っている可能性を考えてみるべきでしょう。どんなに努力しても報われないならば、鉛を金に変える努力をしていないかどうかを振り返ってみる必要があります。

第一章「あなたの要求定義はなぜ上手くいかないのか」では、あまり論じられることのない「要求定義の困難さの原因」について少々深堀りして考察しています。不確実性と曖昧性を伴う要求定義には、「正解」を導くテクノロジーではなく、「妥当な解」を導くマネジメントの考え方が必要とされることがわかっていただけると思います。

第二章「要求定義で徹夜できるか」は、実際の要求定義における作業の心構えです。ここでは、設計や製造では推奨されたかもしれない「理想論」や「あるべき論」の追及はひとまず脇に置き、現実的な対応を心がけることの重要性を強調しています。

第三章以降は要求定義で頻繁に発生する問題を取り上げ、そのそれぞれについて、原因、予防策、治療法を検討していきます。問題の性格上、解は常に「正解」とは限らず、多分に状況依存です。また、その多くはエレガントさに欠ける泥臭いものばかりですが、「妥当な解」を導き出すための有効なヒントとなってくれるはずです。

目的

本書の目的は、要求定義の現場で働く担当者に、状況に応じた「妥当な解」を見つけるためのツールとヒントを提供することです。

ターゲット

本書の読者には、一度は要求定義で「苦しんだ」ことがあるマネジャーや要求定義の担当者を想定しています。本書には数多くの先達の経験と知恵が蓄積されています。過去を踏まえ、問題意識を持って要求定義に望もうとするエンジニアには、実践的かつ有効な現場の行動のヒントを提供できるのではないかと思います。もちろん初心者の方にも、「こういう世界がある」ということを理解していただくにはよいでしょう。ただし基本的に本書は、一度は要求定義の経験のある方の実戦サポートを目的としています。全くの初心者が最初の一歩を踏み出すためのガイドラインとしては、前著「要求定義のチェックポイント４２７」の方が適しているかもしれません。

本書の使い方

実際の要求定義の作業を開始する前に、内容を一通り確認しておくとよいでしょう。問題別に「原因・予防策・治療法」をまとめた「逆引き」の構成となっていますが、プログラミングの「逆引き辞典」のような使い方はお薦めしません。今後の要求定義の作業計画や、プロジェクトの推進計画を策定していく上での、「忘れてはいけない検討項目」を忘れないためのチェックリストとして使用されることをお薦めします。すなわち「治療法」は読まなくても済むような使い方がベストです。

要求定義はシステム開発における「最後の難問」とも言われていますが、開発者や研究者の不断の努力にもかかわらず、「ベストプラクティス」確立までの道のりはまだまだ遠いようです。ゴールが約束された確実な道は存在しません。しかし手がかりが全くないというわけではありません。１００％の結果は約束してくれませんが、その確率を上げてくれるような知識や知恵は、過去の先達によって蓄積されています。あなたの要求定義ななぜ上手くいかないのか。その答は先達の知識や知恵を探ってみることによって見つかるかもしれません。

要求定義の本質としての難しさ

１．創造性の要求

ソフトウェアの製造過程はよく工場に例えられます。ここで注意しなければならないのは、設計者やプログラマが、工場の中のどの役割に当たるのかということです。ベルトコンベアの流れ作業の中で、上流部分が要求定義、中流部分が設計、下流部分がプログラミングという捉え方をしてしまうと、ソフトウェア開発の本質を捉え損ねてしまいます。そのような捉え方をしてしまうと、ついうっかり設計やプログラミングで慣れ親しんだやり方を、そのまま要求定義にも当てはめてしまうようなミスをしてしまいかねません。

実は設計者やプログラマはベルトコンベアの流れ作業の中にはいません。ベルトコンベア上の作業とはコンパイラやリンカの作業なのです。だから全く同じ製品を何回も機械的に生み出すことができるのです。設計者はどこにいるかというと、それは工場自体の設計者です。プログラマは工場を組み立てる職人です。これが正しい例えです。ここで間違えるとテイラーの管理手法をソフトウェア開発の現場に適用しようとする過ちを犯してしまいます。設計士さんや大工さん、職人さんが最高の仕事をするためには何を管理すればよいでしょうか。現在の開発環境を見る限り、再考の必要性がありそうです。

さて肝心の要求定義の担当者はどこにいるのでしょう。要求定義とはどのような作業なのでしょうか。それは工場で何を作るかを決める作業です。自動車メーカーであればトラック工場を作るか、乗用車工場を作るか、フォークリフト工場を作るかを決める作業です。しかし何を作ればよいのかを、どのようにして決めたらよいのでしょうか。簡単に答を出してくれる方程式などあるはずがありません。なぜならそれは企業の戦略に関わる部分だからです。それは形式的なMBA手法を用いて機械的に答を出すプロセスではなく、（その機械的な結論を参考にしつつも）自らの頭を絞って創造していく唯一オリジナルのプロセスだからです。

戦略策定の主人公はあくまで「考える脳」です。単純に公式に当てはめたり、テンプレートの空欄を埋めていくだけの作業ではありません。ポーターの理論を参考にしてもよいでしょう。シナリオ・プランニングもよいでしょう。しかしそれらの手法によって自分の思考や行動が制約されたり形式化されるべきではありません。戦略策定とは、答が決まっているドリルの問題を解くこととは違います。時には自ら答を提案し、逆に質問を創りあげていくような作業を伴うものです。戦略策定が相手にしなければならないのは、現実という無限の可能性です。過去をベースにした「すでに書かれている」思考パターンや行動パターンでは、何が起こるかわからない未来には対応できないのです。

要求定義も全く同様です。「何を作るのか」を創るのが目的であり、そこには結果を約束してくれる手法は存在しません。なぜならそれは、既に存在する「正解」を発見するプロセスではなく、「正解」となるものを創りだすプロセスだからです。「正解」は客観的に存在するものではなく、要求定義の行為を通してはじめて実在しうるものなのです。要求定義に形式的な手法を求めるのは、企業戦略に形式的な手法を求めるのと同じです。例えば、工学的手法を用いてモノを製造する会社だからといって、工学的手法を用いて会社を経営するようなことはしないでしょう。

要求定義の作業の本質は、その創造性にあります。この本質を理解していないと、要求定義の作業は単に顧客から要求を受身で受け取るだけの作業、受け取った要求を形式的にモデル化していくだけの作業になってしまいます。

２．道具としての言葉の限界

要求定義は当然ながら言葉を媒体としています。しかしその言葉の道具としての限界が、真の要求をゆがめてしまうのです。

顧客から開発側に伝えられる要求は、最初から明確な言葉の形で存在しているわけではありません。要求というものは、顧客が感じているニーズが言語化されたものです。もともとのニーズは右脳の中に、言語化が不可能なイメージとして存在していたものです。しかしイメージはそれを持っている本人にしかわかりません。右脳のイメージは他人の右脳には直接には届きません。そこでイメージを論理化し、他人の左脳が理解できる形に変換してあげる必要があります。こうして変換されたものが言語であり、言語化されることによって、開発側は左脳で顧客の要求を理解することができます。

ところで顧客が右脳のイメージを左脳で理解可能なように論理化する際に、必ず情報の欠落が発生します。
例えば、もともと下のような形をしたイメージを
（図１）
■
■■■
下のような構造に押し込もうとすれば、情報の欠落は発生しません。
（図２）
□□□
□□□
しかし雲のような形をしたイメージを上のような構造に押し込もうとすれば、情報の欠落が発生してしまいます。
これがイメージを論理化する際に発生する情報の欠落です。

次に開発側が受け取る情報です。
顧客が雲のようなイメージを持っていたとしても、開発側が受け取る情報は下のように構造化されたものです。
（図３）
■□□
■■■
顧客のニーズを掴むということは、この構造化された情報からもともと顧客の右脳の中にあったイメージと同じものと作り出すということです。
しかしその困難さは容易に想像がつくことでしょう。開発側は自らの過去の経験や知識を動員してイメージを作り出そうとしますが、果たして顧客のもともとのイメージとどれだけ似通っていることでしょうか。どれだけ似ているかは、どれだけ共通の経験、共通の知識基盤があるかどうかにかかっています。

こうして顧客のイメージは論理化の過程で情報が欠落し、開発側のイメージ化の過程で余分な情報が付与されてしまうのです。ついでに言ってしまうと、恐ろしいことにこの過程は、要求定義の担当者から設計者、設計者からプログラマ、といった情報伝達の全ての過程において発生するのです。この言葉の性質と限界をよく理解しないまま要求定義の作業を進めていると、誤解や勘違いが発生することになります。

アプローチの問題

１．不確実性と曖昧性の混乱

要求定義には不確実性と曖昧性という問題が存在します。両者は似たようなニュアンスがありますが、現場の対応は全く違ったものになります。明確に分けて考える必要があります。

不確実性の問題とは、情報不足のために生じている問題です。例えば将来の株価がわからないという問題は不確実性の問題です。ソフトウェア開発において、画面上のある項目を表示するための計算式がわからない、というのも不確実性の問題です。不確実性の問題は無知の問題です。存在はわかっていても、情報不足のため答が出せないのが不確実性の問題です。

一方曖昧性の問題とは、2つ以上の解釈を許すような問題です。ソフトウェア開発において、画面の色について質問をした時の回答が「さわやかな色にしてください」というものであれば、それは曖昧性の問題です。「画面の色について質問しなければならない」ということがわかっていない状況も、ひとつメタの次元での曖昧性の問題と言えるでしょう。解釈や価値観の違いによって答が出せないのが曖昧性の問題です。

不確実性の問題は情報不足が解消されれば結論を出すことができます。そこでは形式的な手法や調査が有効に活用されるでしょう。しかし曖昧性の問題は同種の情報をどれだけ収集しても解決することはできません。なぜなら肝心の問題を明確に定義することができないので、問題の解きようがないのです。問題を解くためには解釈や多義性を解決するための、全く別の種類の情報が必要になります。

最終的にカットオーバーまで漕ぎ着けたシステムの仕様を考えてみます。最終的に確定したこれらの仕様は、全て最初から顧客の頭の中にあったものでしょうか。一部はそうかもしれません。しかし大部分はそうではないはずです。当初は存在していなかった仕様が、要求定義の活動を通して、顧客と開発側の相互作用の中から生まれてきたものです。そしてそれらはまた、会議にたまたま誰が参加したか、という半ば偶然の要素も相まって形成されてきたものです。つまり要求定義とは、「隠れていた事実」を明らかにしていく過程ではなく、それぞれの主観の中から協同で「事実」を作り上げていくような作業です。相互の認識の違いや解釈の違いを埋めていくような作業です。不確実性よりも、曖昧性により上手く対処していかなければならないのです。

要求定義の問題とは曖昧性の問題です。各ステークホルダーが持っている考えや価値観を、積極的に引き出し纏め上げていかなければ、決して解決しない問題です。それは主観的な意見の対立の中からコンセンサスをまとめていくような作業です。不確実性の問題と曖昧性の問題を混乱して対処方法を誤ってはいけません。

２．構造化・形式化への過度の依存

要求定義の作業をモデル化して考えようというアプローチがあります。確かにモデルは構造化・形式化によって、複雑な現実を扱いやすくするための有効なツールです。しかしその扱いやすさは大量の情報の大部分を無視することと引き換えに獲得されたものです。重要な情報であっても、その枠組みから洩れてしまうものもあります。しかしそれらの情報を全て取り入れようとすると複雑化し、今度はモデルとしての役割が全うできなくなってしまい、再び情報の洪水に溺れてしまいます。したがってモデルは、それを構成する要素（パラメータ）と、実質的な有用性（効果）とのバランスを取ったものにならざるを得ません。そしてバランスを取った後のモデルが、本当に現実で有用なレベルまで達しているかどうかはまた別問題なのです。

ここでまず考えなければならないのは、モデルを構築する際の、情報の取捨選択の信頼性です。本当に必要な情報が抽出され、不要な情報が無視されているのだろうか、という問題です。というのも、モデルがモデルとして成り立つためには、それを構成する要素に大きな制約が課せられるからです。まず、要素は客観的で定量化できるものに限られてしまいます。「部長の気まぐれ度」や「社員のやる気」や「ＡさんとＢさんの相性」はモデルを構成する要素から除外されてしまいます。しかしその除外された要素が実はプロジェクトの肝であるという状況は大いに考えられます。

モデルから洩れてしまう情報は、モデルを使用する人間が随時、臨機応変に拾っていけばよい、という考え方もあります。しかし現実はそう簡単にはいきません。枠組みを使用するということは、その枠組みから外れた要素にはほとんど（あるいは全く）目が行かなくなるということです。モデルが完成するまでの歴史や意図を知らずにモデルだけを使っている初心者は、まず間違いなくモデルを信用しきって他の要素には目が行きません。かなりのベテランでさえ、「モデル駆動」のプロジェクトではどうしてもモデルへの準拠ばかりに関心が行くことになります。（※もっとも、構造化には枠内の項目の検討洩れを教えてくれるというメリットもあります）

最初から決まりきった枠組み（プロセス含む）を用意しておいたのでは、その枠にはまるニーズしか取り込めないのは自明です。分析フェーズで構造化を試みるのは全く構いません。しかし要求を獲得する段階からその構造化を意識すべきではありません。

（図１）
構造化・形式化のメリット〜検討漏れがあることを教えてくれる
□□□
□□□

構造化・形式化のデメリット〜最初から枠に洩れた部分は見捨てられる。
（図２）
□□□
□□□

３．効率性の追求

システム開発のプロジェクトには当然、生産性や効率性という指標がつきまといます。しかし要求定義の作業でこれらの指標を追いかけるのは危険です。例えば担当者の情報負荷を、前項で言及した構造化や形式化などによって軽減し、作業の効率化を図ろうとする動きには注意すべきです。そもそも要求定義の担当者は、設計やプログラミングの作業をしているわけではなく、顧客のニーズを掘り起こす作業をしているのです。効率化を問題とすべきではありません。大きな情報負荷を負わなければならないのは当然であり、またそれが目的でもあるのです。

要求定義の作業で重要なのは効率化や負荷軽減ではありません。まずは、より多くの要求、より多くのニーズを掘り起こすことがなにより重要なのです。その作業において、「１時間で3つの要求を獲得した」というような「効率化」で計測できる指標を過度に重要視してはいけません。「浅い」要求を短時間で獲得したからといって、そこには何の意味もないのです。

創造性が必要とされる作業で求められるのは成果物の質です。絵画は完成品そのもので評価されるのです。決して生産性や効率性で評価されるべきものではありません。

４．過去の経験への過信

人間というものは、知らず知らずのうちに過去の経験から獲得したデータを参考にして行動しているものです。したがって、過去の結果を形式的・線形的に当てはめられる対象に対しては、経験値を利用してうまく対応することができます。例えば何年もの付き合いがある馴染みの顧客の、何年もの付き合いがあるシステムに、一般的なパッケージ的な機能を追加しようというような場合には、おそらくプロジェクトは計画通りに進むでしょう。しかし逆に言えばそこまで明確に未来が見えていなければ、不用意な「過去の適用」は現場の負荷を高め、なおかつ要求の品質を落としてしまう危険性があるのです。

熟知している過去の事例のパターン化は、確かに結果と効率性の両方を提供してくれますが、要求定義の作業ではその使用に慎重であるべきです。もちろん全て捨ててしまう必要は全くありませんが、少なくとも盲信すべきではありません。一旦完成したソフトウェアを、全く同じ仕様でもう一度作り直すといった状況では、過去の事例は大いに効果を発揮するでしょう。しかし過去に存在しなかった未来を創りあげていこうとするプロジェクトにおいては、過去の事例は思っているほど頼りにはならないものです。

過去の枠組みはあくまで過去のものです。合理性が自らの非合理性を修正できないのと同様、枠組みは自らの枠組みを越えることはできません。一方、創造性が求められるソフトウェア開発では、常に新しい枠組みを必要とします。過去の事例が得意とするのは、過去から線形的に予測できる未来に対応することです。一方、システム開発の現場で求められているのは、環境の非連続性に対応することです。過去のパターン化が得意とするのは、既知の問題に効率的に対処することです。一方、システム開発の現場で求められているのは、突発的な事象に臨機応変に対応することです。

要求定義において過去の経験や知識は非常に重要なものですが、くれぐれもそれを過信したり依存しすぎることがないようにしなければなりません。

５．プロセスへの過信

プロセスを使用していると、なんとなく対象をコントロールしているような気になるものです。プロセスの指標が制御範囲内にあるだけで、あたかも対象が制御下にあるかのような幻想をいだくのです。しかしプロセスで使用する指標は無限の現実を狭い一側面から観察したものの影に過ぎず、プロセスが勝手にその一側面を選択したに過ぎないことを忘れてはいけません。しかも制御しやすい指標、可視化しやすい指標だけを指標として選んでいるのです。

そもそも要求定義という複雑かつ予測不能な作業を、プロセスという限定的な形式だけで制御しようとすること自体がリスクのある考え方です。多くの場合、プロセスを制御しているという幻想の下で、単に機械的にテンプレートの書式を埋め尽くしているだけです。機械的にテンプレートを埋めていけば進捗がはかどっているように見えますが、それは文字通り「形だけ」の要求定義です。（※そもそも創造的な作業をしている場合、その進捗状況を定量的に把握することはできません。進捗を定量的に把握しているのであれば、おそらくそれは創造的な仕事ではないでしょう。要求定義の作業の最中には完成型が見えないので、現時点の位置がわかるはずがないのです。）

合理的であること、論理的であることへの信仰（要求定義にとってはまさにそれは信仰です）は、手段の合理性のために、最終的な目的に対する合理性を犠牲にしてしまいがちです。目の前のプロセスへの準拠作業に追われてしまい、いつの間にか「準拠すること」自体が最も重要な作業になってしまうのです。

数学の公式は必ず正解へと導いてくれました。種々のプログラミングのテクニックは合理的で論理的で、初心者にもその結果を約束してくれました。設計のテクニックは合理的で論理的で、習熟すれば結果は確実についてきてくれました。確かにソフトウェア開発現場においては、プロセスを使うことによってかなりの程度まで結果をコントロールすることができたのです。しかしこの経験は、新しい環境で新しい問題に直面した場合に、負の効果をもたらすかもしれません。結果を出すためには、合理的で論理的な考え方が必須の条件だと思い込んでしまうのです。学習を重ねてプロセスで結果を出せるようになった人は、プロセスで結果を出せないと、それは学習が足りないからだと思い込んでしまうかもしれません。あるいはプロセスの不備や不足にその原因を求め、更なる細分化とパラメータの増殖に（最後には制御不能になるまで）突き進んでしまうかもしれません。このような担当者は、要求定義の作業に当たっては、設計やプログラミングで学んだ考え方を、一旦リセットする必要があるのです。

６．工学的手法の誤った使い方

工学的手法を要求定義に適用するのは簡単ではありません。規則性の問題や因果関係の問題、ハードデータ特有の問題など、クリアしなければならない問題は多く残されており、未だ設計やプログラミングのそれのように実用段階にあるとは言えません。実際の使用に当たっては、以下の点に注意しながら作業を進めなければいけないでしょう。

• 包括性・抽象性
  手法や技法といった類は、全てを包括的に扱おうとすると抽象的になり、より実体が薄いものになってしまうものです。しかし目の前に問題があるときに、一般原則に則ってそれに対処しようとしてもなかなか難しいものです。例えば手法が指示するアクションや行動ガイドに「適切な要求を獲得すること」などと書かれていても、現場には何の役にも立たないのです。最も重要な箇所が簡単な一文で済ませられてしまうことが非常に多いのです。具体的な状況の中で具体的に考えたほうが余程うまくいくものです。

• 費用対効果
  要求定義に工学的手法を適用することによって、プロジェクトはどれだけコストに見合うだけの見返りを得ることができるでしょうか。手法は、その手法が指示する作業を随時取捨選択することによって、効率的に使用することができるかもしれません。しかし手法を工学的に厳密に使用することを現場に強いると、「無駄な作業」のオーバーヘッドが増加し、結果的にコスト高になってしまいます。

• 理由付けの重視
  工学的手法は個人が経験から得た知識よりも、机上の論理的思考の産物に高い価値を置きます。そしてこの産物が経験豊富な知恵を差し置いて現場をコントロールします。しかし全ての地図が間違いであるのと同様、全ての論理的思考の産物は間違いです。現実は常に机上の論理を超える複雑さを持っています。現場が必要としているのは、合理性よりも実用性です。

• 勘と経験の軽視
  工学的手法は経験豊かなマネジャーや担当者が有効かつ臨機応変に現場をコントロールする力を弱める方向に働きます。地図上の議論が現実に優先しているのです。工学的手法は業務経験の多寡を問いません。しかしこれは、工学的手法が現場の経験不足、知識不足を補うということではありません。むしろ経験不足や知識不足であるという認識を妨げる危険性を持っています。

• 人間の客体扱い
  工学的手法は、以前は人間の存在を無視することによって、「工学的」であることを維持してきました。しかし最近ではそうとばかりも言ってられません。人間を無視した手法が現場では全く役に立たないことが周知になってしまったからです。とは言うものの、物理的な存在ではなく概念的な存在である人間を工学で扱うことの困難さは変わりません。そこで工学的手法が「工学的」であろうとすればするほど、人間をモノ的に扱わざるをえなくなってしまうのです。しかし人間はモノではないので、実践の現場においてその手法はすぐに破綻することになります。

• モチベーション
  労働集約的なソフトウェア開発において、工学的手法は必ずそこに「従わなければならない人」を生み出すことになります。しかし何かに従わなければならない人が、全身全霊を作業に打ち込むことはまずありません。

• 現場のダイナミズム
  ガチガチの規則やルールに縛られた中からオリジナリティあふれる作品が生み出されることはありません。工学的手法でその作業を定義してしまうことは、要求定義で最も重要な柔軟な発想、発想のダイナミズムを殺してしまうことにもなりかねないのです。

• 現場の抵抗
  机上で作成された「楼閣」は、一般に現場からは嫌われます。現場の自律性が奪われるからばかりではありません。それが役に立たないことが直感的に確信をもってわかるからです。そしてそれが本当に必要な作業から、貴重な時間を奪ってしまうからです。しかし現場はしばしば（無意味であることが誰の目にも明らかな場合にも）そのプロセスを強いられることになります。現場の反発が発生するのは当然です。

• 硬直性
  工学的手法を用いるということは、必然的に要求定義活動を硬直的なものにしてしまいます。手法が明確であるほど、論理的でわかりやすいほど、硬直性は高くなります。そして手法を公にし、その手法を使用することを宣言すると、事実上、手法を変更することは不可能になります。一旦宣言した手法を改めようとするならば、大きな心理的な抵抗を克服しなければならないでしょう。

• 適応可能性
  「適応が適応可能性を排除する」とはカール・ワイクの言葉です。確かに恐竜が滅んだのは環境への過度の適応が原因だったかもしれません。もともと要求定義とは曖昧性と多義性を扱う作業です。短期的な効率化を目的とする適応でさえ、それが可能かどうかが疑わしいこの世界で、無理に適応可能性を減じるような施策を打つ必要性はありません。

• 直観の模倣
  工学的手法の限界が誰の目にも明らかになったとき、明確な指示や合理的な理由の説明もないままに、いつの間にか手法から離れてプロジェクトが運営されていくことがあります。最初に大きな看板を掲げてしまったため、それを下ろすことができず、とはいうものの現実には現実的に対応せざるをえなくなったような状況です。行動は直観に従い、後づけで合理的理由を付与するのです。

• 現場のニーズとの乖離
  要求定義の現場で必要とされるのは完璧な工学的知識ではありません。環境変化に柔軟に対応できる適応力と経験です。

このように、要求定義の作業に工学的手法を用いるのは、高いリスクと十分なマネジメントを覚悟しなければなりませんが、手法が持つ論理性や合理性は、本来の目的以外のところでは役に立つかもしれません。仮に使用するのであれば、前述の点に注意しつつ、下記のような使い方を考えるとよいでしょう。

• 顧客のコントロール
  主観的なイメージを理由に顧客を納得させることは（その人に余程の実績と信用がない限り）困難ですが、合理的で論理的な説明は（それが「若造」のものであっても）十分に顧客を説得する力を持つことができます。ここにおいて、工学的手法が本当に機能するかどうかはどうでもよいことです。重要なのは顧客が納得するようなロジックがそこに存在することです。ロジックを明確にし、開発ボリュームや開発に要する工数を視覚化し、顧客の理解を得やすくすることです。要求定義における工学的手法は、実際の要求定義の作業ではなく顧客のコントロールという側面では、しばしば貢献することができるのです。

• 上司のコントロール
  上司が感じている不安は顧客が感じている不安と似ています。工学的手法は「顧客のコントロール」と同じ理由で上司のコントロールにも役に立ちます。定量的で目に見える形でプロジェクトが表現されていると、プロジェクトが制御下にあるものと錯覚してしまうのです。工学的手法はプロジェクトに関連する利害関係者がその有用性を信じている限りにおいて、有用と言えるでしょう。

• チェック洩れのチェック
  顧客の要求を構造化された枠組みに当てはめてみることは、要求の洩れのチェックに大いに役立ちます。主観と感性で獲得された要求だけでは、どうしても洩れが出てきてしまいます。構造化された枠組みと形式的なプロセスは、それをそのまま作業のガイドラインとして用いるのは危険ですが、チェックポイントとして取捨選択しながら利用するならば非常に有用だと思われます。

• 意見調整
  人はそれぞれ異なる経験と異なる知識を持っているので、同じ問題に対しても異なる意見を持つことがよくあります。工学的手法に限りませんが、きっちりとした考え方の基準をチームとして共有することは、こうした経験や知識の違いによる意見の対立を解消する効果があります。

要求定義作業の心構え

これまで見てきた通り、要求定義の作業というものは形式に従っていれば誰でも同じような結果が出せるような作業ではありません。非常に属人的な作業です。作業から顧客や担当者といった人間的要素を排除したモデル化を考えることはできません。人間同士の相互作用が要求定義そのものであり、その相互作用が作業の結果に大きく影響するのです。

人間的要素が大きいということは、（完全なエンジニアリング作業とは異なり）心構えによって結果が影響を受けるということです。実際、要求定義の担当者がどのような心構えを持って作業に当たるかによって、作業の様相や成果物の品質は大きく違ってくるものです。

１．ハイペースを心がける

通常のプロジェクトでは要求定義フェーズの雰囲気はまだまだ和気あいあいとしたものです。顧客の回答は遅れ、会議は延期され、時間が来ると「続きは次回」となります。危機感は全くありません。しかしここで思い出すことです。

• 要求定義フェーズでの一日の遅れは後フェーズの作業では何日の遅れになるのか。
• 要求定義フェーズでの一人日の工数は後フェーズの作業では何人日の工数になるのか。

夜も遅くなり、要求の確認や見直しを明日に延ばしたくなったら思い出すことです。

• 要求定義フェーズでのバグが後工程で発見され、修正される場合に、何倍のコストがかかるのか。
• 新たな要求の獲得が、どれだけ多くの新たな質問を生み出すか。その回答を得るためにどれだけの時間を要するか。

今日獲得した要求を今日チェックしても、すぐにはそのチェック結果を顧客にフィードバックすることはできないかもしれません。それでは今日は早々に帰宅して、明日チェックを実施すればよいのでしょうか。確かに、顧客のアポイントメントが取れていないならば、無理に今日、チェックをする必要はないかもしれません。しかしそれならば、明日のアポイントメントが取れていないこと自体を問題視すべきでしょう。非常にのんびりしている雰囲気です。製造フェーズの追い込み期のプログラマの必死の生産性と比べると、いかにも気が緩んでいる感じは否めません。

特に要求定義フェーズの前半戦では、顧客から出てくる要求は非常に概要レベルであり、数も少ないものです。チェックは短時間で完了します。この次期にヒアリング会議を週に一度などという悠長なペースで行うのは（あえて強い言葉を使いますが）怠慢としか言えません。確かに忙しい顧客を相手に毎日、あるいは二日に一回というペースのヒアリング会議の時間を確保するのは難しいことも事実です。しかしここで、要求定義フェーズの一日が後工程のどれだけの作業に値するのかを思い出すべきです。顧客が多忙であっても、多少強引にでもアポイントメントを取ることです。顧客が「今日も飲みに行く」などと悠長なことを言っているのであれば尚更です。

繰り返します。最初の一週間は毎日、次の二週間は二日に一回、次の一ヶ月は週に二回、といったハイペースで要求を獲得・分析していくことです。そして事前に顧客のアポイントメントを取っておくことです。チェックが終わらなければ徹夜することもあるかもしれません。本当に要求定義だけを目的として徹夜などしなければならないのでしょうか。常識では、そして通常のプロジェクトでは考えられないでしょう。上司もまず間違いなく、そこまですることはないと言うでしょう。しかしここで徹夜することは、試験フェーズで30人が徹夜することを防ぐことになるかもしれないのです。要求定義の担当者は初日から大いなる危機感を持って作業すべきなのです。

ただしここで注意すべきは文書フォーマットなどの非本質的な作業に時間を費やしてはいけないということです。フォーマットをまとめるために徹夜する必要などありません。これは何回も繰り返す必要があるかもしれませんが、くれぐれも最終納品物に直結しない成果物は手を抜いて時間をセーブすることです。納品物でない限り、顧客に見ていただくからといって、きれいなフォーマットにまとめる必要はありません。「きれいなフォーマットにする時間は省いている」ことを説明の上、顧客に見ていただけばよいのです。「昨日の今日」であることは顧客も承知していることですし、フォーマットをまとめるために数時間分のコストをかけても顧客は喜びません。

２．顧客に期待しない

要求定義にあたって、無意識にでも顧客に何かを期待するのは精神衛生上よくないかもしれません。そして要求定義という作業の成果物の観点から考えても良くないでしょう。

期待というと「〜してほしい」という期待を思われるかもしれませんが、ここでの期待とはそのような「積極的」な期待ばかりではありません。「〜すべきだ」「〜するのが当然だ」という暗黙の期待も含まれています。実際に現場で顧客を相手にしていると、開発側の方から顧客に対して苦情を言ったり、強く主張して当然と思われるような理不尽なことが頻繁に発生します。例えば、顧客の回答が遅れたために徹夜で緊急に対応したところ、顧客の回答の誤りが発覚し、結果として開発のマイルストンを外してしまい、今度は進捗会議でそのマイルストンの遅れを顧客から厳しく指摘される・・・といった状況では、顧客に対して一言言いたくなるのも人情です。その一言を言うべきか言うべきでないかはここでのテーマではありませんが、要はこのような状況で言いたくなる「〜すべきだ」「〜するのが当然だ」という「当然」の理屈は引っ込めるべきだということです。

その理屈を言わなくてもすむように、顧客をリードしたり、事前にバックアップや滑り止めの策を取っておくことが大切なのです。そこまで面倒を見なければならないのか、と思われるかもしれません。しかしここで重要なのは正論を主張して、自分の考えの正しさを相手に認めてもらうことではありません。相手を論破して自分の正しさを証明しても、事態が良くなることはありません。第一の目的は、品質の良い要求をできるだけ早急に獲得し、プロジェクトをスムーズに進めることです。「顧客は〜すべきだ」などと愚痴を言わなくても済むようなプロジェクト運営を考えるべきです。正論を主張しても事態が悪化するだけとは、全くストレスの溜まる仕事ですが、要求定義あるいはマネジャーの仕事とはこういうものです。

当然、顧客の心変わりや要求の洩れは当たり前のものとして考えておくことです。「今頃言われても困ります。」「なぜその話が出たときに教えてくれなかったのですか。」「あの時はこうだと言ったじゃないですか。」実際に面と向かって顧客に言えるかどうかはともかくとして、要求の曖昧さに対する開発側のいつもの愚痴です。しかし顧客がどれほど真剣に要求をまとめていこうとしても、こういった事態は容易に起こりうるものです。そもそも要求定義の作業というものは、既に存在しているものを発見していく過程ではなく、存在していなかったものを作り上げていく過程でもあるのです。要求を「発見するもの」と捉えると、「心変わり」や「洩れ」と呼ばれてしまいますが、「創造していくもの」と考えるならば、それは当たり前のものなのです。

要するに、要求定義フェーズの段階では、まだまだ顧客自身でさえ実際にシステムで何をしたいのかがわかっていないものなのです。自分が顧客の立場だったらと考えてみましょう。どれほど真剣に時間をかけて考えたところで、本当に欲しいものを言葉で、しかも期限を区切られた中で相手に伝えられるでしょうか。「これで要求は全部です」と自信をもって言えるでしょうか。おそらく難しいでしょう。「気づかなかったが本当は重要な要求」というものがプロジェクトの終盤を迎えてもまだ発生します。しかしこれが自然の姿です。不自然な姿を「あるべき論」で目標にしてはいけません。この自然な姿を理解し受け入れた上で、プロジェクトを進めていくことを考えていかなければならないのです。一定期間内にきっちりとした要求が出てくるものだと期待する方が間違っています。

顧客に期待すべきではありませんが、一方では「困った」顧客には早々に見切りをつけることを覚えなければいけません。「顧客は〜すべきだ」と言わなくても済むようなプロジェクト運営を心がけることが重要と書きましたが、もちろんこれは「普通」の顧客を相手にした場合のことです。言い方は悪いのですが中には厄介な顧客も存在します。このような顧客に、先々まで読んだ上での心配りのきいたプロジェクト運営は、無駄な投資です。まともな話が全くできないような顧客は滅多にいませんが（99%は「まとも」な顧客だと思います）、それでも確実に存在していることは事実です。そのような顧客に対しては、どれほど譲歩しても相手にとっては「当然」のことと受け取られ、感謝されたり、逆に別の面で譲ってくれたりということはありません。むしろ更なる譲歩を要求してくるものです。この顧客の見極めが遅れると、開発側はいつの間にか蟻地獄にはまったように、いつまでも厳しいプロジェクト運営を強いられることになります。「顧客第一」も顧客によるのです。

３．イメージを構築する

要求を獲得したからといって安心してはいけません。本当の難しさはここから始まると言っても過言ではありません。獲得された要求が果たして開発側が期待している通りに明確で安定しているものとは限りません。要求は言葉を介して伝えられますが、まずはこの言葉には「顧客にとっての意味」があることを理解することです。

言葉が同じだからといって、必ずしも思っていることが同じだとは限りません。ある言葉が意味するものは人によって異なります。言葉にはそれぞれ異なった理解の仕方、解釈の仕方があるもので、同じ言葉でも10人いれば10人それぞれの意味を持っています。共通の精神基盤、共通の経験を持っていれば、その意味するところは相互によく伝わるでしょう。しかし全く異なる環境に育った2人が同じ言葉を使っていたとしても、その意味はお互いニュアンスが少なからず異なったものになっているでしょう。

開発側は開発側の経験と知識から顧客の言葉を理解しますが、これが誤解の発生の原因です。言葉としての要求を獲得したからといってそれで安心してはいけないのです。その言葉の顧客にとっての意味を理解しなければいけません。顧客の要求の基となっている真のニーズは何か、その要求はどのような環境下、状況下で有効か、逆にどのような環境下、状況下では有効ではないか、というところまで掘り下げて考え、言葉のニュアンスのギャップを解消していかなければなりません。このニュアンスを掴むためには、「言葉の収集」ではなく「システムのイメージ」を作ることを意識しなければなりません。

言葉の解釈は個人個人によって微妙に異なっているため、その意味では「言葉とは曖昧なものである」と言うことができますが、別の考え方をすれば言葉ほどはっきりと現実を秩序づけてくれるものはありません。何の境界線もないはずの現実世界を切り刻み、分類し、意味のある秩序を創造するのです。これを逆の意味で考えると、言葉によって語られない現実は全く無視されてしまう可能性があるということです。「語りうるものは明快に語りうるが、語りえないことについては沈黙せねばならない」という言葉がありますが、まさにその通りです。

要求定義で注意しなければならないのは、その目的が「言葉を収集すること」ではないということです。たくさんの言葉を収集し、それで要求を獲得したと思ってはいけません。「語りえないこと」を感じていかなければならないのです。実際に動いているシステムの姿、システムを利用しているユーザの姿をイメージしてみることです。あるいはシステム導入後の業務の姿をイメージしてみることです。それができなければ、顧客の要求を理解していると考えてはいけません。言葉とは実際のイメージの影であり、地図でしかありません。影からどのように現実をイメージするか、地図からどのように現実をイメージするか、そのイメージが顧客と一致しているか、それを考えることが重要なことです。

４．行動の指針

要求定義の作業は、指針に従っていれば間違いないというような単純なものではありませんが、先達の知恵が全く役に立たない世界でもありません。基本的な行動指針くらいは頭の片隅に置いておいても損はありません。使う使わないは別として、多くの選択肢を持っているのはよいことです。

• 知識は最初に詰め込むことができるだけ詰め込むこと。
  プロジェクトの初期段階ではまずは何も考えずに知識を詰め込むことに集中することです。この段階では情報を取捨選択できるような判断力はないのです。参考文献は読めるだけ読み、ヒアリングやインタビューの時間は可能な限り取ってもらうことです。はじめからシステム開発に必要だと思われる情報だけに絞って情報を収集していると、なかなか顧客の業務を「わかった」と言えるような状態にはならないかもしれません。システム仕様を検討するには直接必要ではないかもしれない情報も含めて、不断に情報を詰め込むことによって、突然「わかった」と言えるような時期がやってくるものです。

• 問題の芽には常に目を光らせておくこと。
  要求定義作業が一日遅れると、設計フェーズ、製造フェーズ、試験フェーズでは、それぞれ何人日分の作業が遅れるでしょうか。要求定義の作業品質が低下すると、設計フェーズ、製造フェーズ、試験フェーズでは、その品質をリカバリするためにそれぞれ何人日分の作業が必要になるでしょうか。要求定義フェーズは以降の開発フェーズの基礎を作るべき、非常に重要なフェーズです。ここでの失敗を後の設計やプログラミングのフェーズで挽回することはできません。この重要なフェーズを成功させるためには、失敗の可能性のある要素や効率的な作業の足を引っ張る要素は、思いつく限り、そして可能な限り排除しなければなりません。ぼんやりとしたルーチン作業では問題の芽は発見できません。常に「問題の芽はどこにあるか」という意識を持って日々の現象を観察していかなければなりません。

• 「わかっていないことがわかっていない」情報の存在を常に意識すること。
  問題意識があれば解決のために動くことができますが、問題意識すらなければ現状は何も変わらないでしょう。顧客の要求も同様です。たとえ内容が不明であっても、存在していることがわかっている「未知の情報」ならば対処のしようもあります。予防線を引いておくこともできます。しかし存在自体がわかっていない未知の情報を意識的に収集するのは不可能です。このような未知の情報、必要であっても顧客自身の意識からも洩れている情報というものは必ず存在します。顧客自ら全ての要求（つまりカットオーバー時の要求）について「この点はまだわかっていません」などと積極的に伝えてくれることはありません。いつ発生するか、どこから発生するか、どのくらいの影響になるか、事前には全くわからない要求に対して、その発生に備えておく必要があるのです。

• 経験を過信しないこと。
  過去に同じ業界の同じような業務のシステムを構築した経験があったとしても、その経験を過信してはいけません。一見同じように見える要求でも、顧客の企業風土や経営方針、IT担当者のタイプによって、その詳細仕様はずいぶんと違ってくるものです。過信は、過去の経験という貴重な情報を、単なる要求定義の品質を損ねる障害物にしてしまいます。経験がなければ逐一確認したであろうことでも、なまじっか経験があるために確認せず、かえって失敗してしまうのです。

• 行動に関して、自分の中で画一的・機械的なルールを作らないこと。
  要求定義の現場は様々な要素が複雑に絡み合った世界です。しかもそこでは人間という曖昧模糊とした存在が非常に大きなウェイトを占めています。くれぐれも「こういう顧客は○○だ」「こういうタイプの相手は○○したほうがよい」「このような要求は呑んではいけない」「こういう場合は譲歩すべきだ」のような画一的な考えに陥らないようにしなければなりません。状況は常に変化しています。あるルールは次の現場では全く通用しないと考えるべきです。確かにルールというものは考える手間を省いてくれますが、こと要求定義に関してはその手間を惜しんではいけません。効率を考えてはいけません。都度新しい行動が要求されているものと考えることです。

• 曖昧さを無理に排除しないこと。
  要求を仕様に落とす段階ではまた話は別になりますが、ニーズや要求を獲得している段階ではその曖昧さを無理に排除する必要はありません。曖昧さの中にこそ顧客の真のニーズが隠れているのです。まずはそのニュアンスを掴み取り、ニーズを感覚としてイメージとして掴むことです。そのニーズを感覚的に理解できた上で、顧客とともに明確に仕様を定義していけばよいのです。

• 急ぐこと。ただし慌てないこと。
  要求定義の担当者が納期間際のプログラマのような目をして要求を整理している姿などほとんど見たことがありません。前にも書きましたがこれは逆の姿であるべきです。要求定義の担当者が1人あるいは数人、皆必死に要求を獲得し、整理し、分析する。そしてプログラミングなどの後工程では開発者が数十人、余裕を持って開発している。コスト的にも品質的にも精神衛生上も、これが真の姿であるべきです。これまでは余裕を持って進められてきた要求定義フェーズを、最重要かつ「常に緊急」の作業として位置づけ、実際にそのように行動すべきでしょう。ただし急いで作業を進めることと、慌てて作業を進めることとは違います。踏むべき手順はしっかり踏んで、確認すべき箇所はしっかり確認しながら進めていきます。

５．最後は本人次第

残業が生産性に及ぼす影響については（デマルコなど）様々な文献で指摘されているので、わざわざここで繰り返す必要はないでしょう。以下にその一例を挙げます。

• 急いで考えることはできない。知的労働では急かしても生産性は上がらない。
• 残業は生産性の低下を招く。更なる残業は更なる生産性の低下を招く。
• プレッシャーを与えると最初は生産性が向上する。更にプレッシャーを与えると生産性は急激に低下する。

ここでは残業をネガティブなものとして捉えています。確かに、これまでの経験から考えてみても、「本人のコミットのない」残業は間違いなく生産性の低下を招くような気はします。残業を当てにしてだらだらと仕事をしたり、あるいは疲れてしまって生産性が上がらないといった状況です。しかし一方で、若き日のビル・ゲイツの例を引くまでもなく、一日十数時間、圧倒的な生産性でプログラミングをする人の存在を、（この業界にいれば）一人くらいは身近に知っているでしょう。残業を単純にひとくくりにして論じることはできそうにありません。

違いは何かというと、やはり単純な答えになってしまいますが「やる気」「モチベーション」「意志の力」というところに落ち着いてしまいます。先に、「徹夜をしてでも要求をまとめる」べきだと、要求定義の担当者をずいぶんと急かすような記述をしましたが、それもこの精神面での基盤がないと難しいでしょう。「やらされている」という感覚で徹夜作業をすることほどつらいことはありません。「やらされている」感覚で要求のチェックをしたとしても、おそらく眠い目をこすりながらのぼんやりチェックでしかなく、次のヒアリングで聞くべきことすらほとんど思い浮かんでこないでしょう。これでは折角時間をもらった会議も、その時間を使い切ることなく余らしてしまうのがオチです。要求定義を「モーレツ」に進める方法も、他のあらゆる手法と同じく、いつどんな状況でも結果が約束されているやり方ではありません。あなたが管理者であれば、決してこれを要求定義の担当者に強いるべきではありませんし、あなたが当の担当者であれば、そこまで仕事にコミットメントできるかどうかを自分自身に問うてみるべきでしょう。

護身の心構え

怪我の治療はとても大切ですが、怪我をしないことの方がより大切です。以下、マネジャーや要求定義の担当者が知っておくべきプロジェクトの「護身術」を簡単に紹介します。内容によっては「理想論」に近いものもありますが、それを常に意識しているのとしていないのとでは、いざというときの咄嗟の判断が違ってきます。マキアヴェッリ曰く「古代のローマ人は、紛争に対処するに当たって、賢明な君主ならば誰もが行うことをしたのであった。つまり彼らは、眼前の紛争にのみ役立つ対策を講じたのではない。将来起こりうるものにも、対策を忘れなかったのだ。ローマ人は、あらゆる努力を払って、それらがまだ芽でしかないうちに、つみ取ってしまうことを忘れなかったのである」相手は先読みが困難なシステム開発プロジェクトです。このくらいの抜け目のなさは欲しいものです。

１．オリエンテーションの重要性

• システム開発の本質は技術ではなく人にあると心得ること。
  顧客を説得するのは骨の折れる仕事です。特に「顧客の利益はベンダーの損失、ベンダーの利益は顧客の損失」というようなゼロサムゲームの考え方をする顧客の相手をするのは大変です。しかし「顧客が要求するもの」「顧客が望んでいるもの」を開発するのがシステム屋の仕事である以上、そして目的とするものが「技術そのもの」ではなく「顧客のニーズ」である以上、顧客との折衝は不可避です。方法論による自動化は面倒な「人の要素」をできる限り見えないものにしようとしていますが、そもそもシステムの価値を決めるのは主観という「人の要素」そのものなのです。システム開発の本質は技術ではなく人にあります。どれほど避けようとしたところで、正面から向かい合わなければならない状況は必ず訪れるのです。

• 要求定義の問題はプロセスや契約では抑えられない。顧客の理解を通して抑えていくものと心得ること。
  プロジェクトを成功に導くためには、要求定義の段階で今後発生するであろう様々な問題の芽を摘んでおくことが非常に重要ですが、これは顧客の協力なしに実現できません。開発側の内部努力だけでは限界があります。そして顧客の協力を得るためには顧客の理解を得なければなりません。理解を得るためには顧客にもシステム開発に対する知識を持ってもらわなければなりません。多くの顧客はこれを嫌がります。「お金は払うから後は任せたよ」と丸投げしてしまう顧客もいます。「なぜ私たちが勉強しなければならないのだ。それはそっちの仕事だろう」といぶかる顧客もいます。開発側は開発側で、「欲しいものをはっきりさせてください。後は口を出さずに任せてください」と、自分たちの世界にすぐに引っ込みたがる人もいます。仕様の膨張という大問題にも、プロセスや契約などの技術的な解決を図ろうとします。しかしここで、何が問題を引き起こしているのか、その根本の原因をじっくり考えてみれば、顧客の教育や啓蒙の必要性とその重要性がわかるはずです（※もっとも政治的な問題はどうしようもありませんが）。

• オリエンテーションの目的は、顧客と開発側との間でシステム開発における認識の共通基盤を築くことにあると心得ること。
  私が新人の頃、開発経験が皆無の時代、「バグゼロのシステム」は可能だと思っていました。先輩は「絶対に無理だ」と言いましたが、私は納得できませんでした。そこで先輩はいろいろな理由を挙げて説明してくれましたが、私は納得できませんでした。理屈というものはつけようと思えばいくらでもつくもので、先輩の説明にも「だったらこうしたらいい」「そういう場合はこうしたらいい」と自分なりの理屈を主張して食い下がりました。最後は先輩の「それでも無理なものは無理。お前もやってみればわかる。」という言葉で終わりました。私が少しでも開発経験を持っていたらその会話は、「バグゼロはどうですか」「絶対無理だろう」「そうですね」くらいの会話で終わっていたはずです。私が先輩と共有できる「基盤」を持っていなかったために、先輩の話を理解することができなかったのです。そんなこともわかっていなかった私は納得がいかないままの不完全燃焼でした。しかしもちろん、この不完全燃焼がその後仕事を始めていく上での障害となることはありませんでした。私は社員ですので納得がいかなくても先輩の指示に従うだけだからです。会社の業務は何の滞りもなく進みます。そしてすぐに私も先輩の話が理解できるようになりました。しかし似たような状況が顧客と開発側との間で発生した場合は話は全く別です。「それでも無理なものは無理。お客さんもやってみればわかる。」で終わるはずがありません。トラブルが発生した場合、その会議の数時間の中で「新人」のような顧客を納得させることは不可能です。開発側の状況は前述の先輩と同じような立場にあるのです。しかも相手を不完全燃焼のままにすることはできません。だからといって事前に顧客に「共通の基盤」を持ってくれるように依頼することもできません。できることと言えば、やはりじっくり長い時間をかけて根気強く顧客を教育・啓蒙していくしかないように思われます。「事実なのだから理解してください」といった姿勢ではなく、一生懸命通じるまで説明する粘り強さが必要です。この顧客理解のためだけに小さからぬ工数が費やされてしまったとしても、それだけの価値があるものと信じます。これが本書で言うところのオリエンテーションです。このオリエンテーションをどれだけ手を抜かずに実行したかによって、仕様の膨張をはじめとする要求定義の様々な問題の発生頻度が低下していくのです。

• 顧客にオリエンテーションの必要性を理解してもらうこと。
  システム開発は顧客の協力なしには行えません。しかし顧客の協力を得るためには顧客にその必要性をわかっていただく必要があります。しかし「協力の必要性をわかっていただくためのオリエンテーション」とはいかにも遠回りな感じがします。本当の開発は協力した相手（つまり開発側）がその内部で行うものなので、顧客にとってはオリエンテーションなど時間の無駄にしか思えないかもしれません。確かにオリエンテーションは開発側が作業を進めやすくするためのものです。開発側の都合です。しかし最終的には顧客のための開発側の都合です。顧客の経験が浅いのであれば、なんとかしてでも時間を取ってもらわなければなりません。このオリエンテーションが不可能ならば、おそらくプロジェクト自体も難しいものになるでしょう。

２．護身計画の必要性

• 問題の発生は開発側の責任と認識すること。
  赤ん坊にとって目に映るものは全て未知の連続で、世の中は驚きに満ち溢れていることでしょう。しかし大人になり経験を積むにしたがって、驚くことは滅多になくなってきます。世の中の出来事は大抵は「経験済み」になっていくのです。システムの開発も同様です。個人にとっては驚きの連続かもしれませんが、それもほとんどは、歴史の中では実にありふれた出来事なのです。五月雨式の仕様変更や不条理な要求も、発生して当然、発生しなければ運が良かった程度に考えていてちょうど良いくらいです。これらの問題の発生がありふれたものであるならば、事前にその対応ができていないのは単なる経験不足か勉強不足あるいは怠惰な仕事ぶりと言われても仕方ありません。問題の発生は顧客の問題ではありません。問題のほとんどはその発生が事前に予測されるものです。あるいは誰かが経験済みのものです。開発側が積極的に予防や対策を考えていかなければなりません。問題の発生は開発側の責任と認識し、護身計画を無駄な計画にすべく行動すべきです。

• 完璧な仕事は存在しない。もしものための備えを考えておくこと。
  要求定義フェーズで発生する問題の多くは、（トートロジーのようですが）要求定義の作業品質を向上させることによって削減することが出来ます。しかし人間の仕事に完璧はありません。品質の向上にも限界があり、限界を超えたところで（これまでの努力を無にするような）実に難しい問題が発生したりするのです。一旦発生してしまった問題はプログラムの小さなバグのように簡単に解決することはできません。この万が一の場合に備えてプロジェクトを護る手段を考えておかなければならないのです。

３．契約による護身

• 契約によってリスク管理を行うことを意識すること。
  実際に要求定義の作業を実施していく上で契約書の条項を意識することはあまりないでしょう。しかしマネジャーにとっての契約とはリスクヘッジの手段でもあります。プロジェクトを危機に陥れかねないリスクを承知していながら、いざそれが現実化すると有効な策が全く打てないというのでは、リスクを全く承知していなかったことと同じです。リスクの認識は、その現実化を防止するための具体策現実化した場合の対応策があってはじめて意味があるものとなります。契約はこのようなリスクヘッジの有効な道具として考えるべきものです。

• 契約は自社を守るための最後の防波堤と心得ること。
  実際の開発現場では「契約を意識しながら」作業に取り組むべきではありません。当たり前のことですが、極力協調関係を重視して作業に携わるべきです。ただでさえ難しいシステム開発のプロジェクトは双方の協調関係なくしては成功はありえません。契約を意識した作業はどうしても「こちら側と向こう側の意識」を醸成し、敵対的な関係に陥りやすいものです。契約はあくまで自社を守るための最後の防波堤と考えるべきです。

• 要求定義を準委任契約とし、それ以降の作業を請負契約とすること。またはそのための方策を検討すること。
  要求定義フェーズと以降のフェーズの契約を分割することによって、実際の開発作業の見積を「要求を詳細まで洗い出した後」で行うことが可能になります。当然、見積精度は向上し、プロジェクトが抱えるリスクは小さくなります。
  ◇契約を分割することによる顧客にとってのメリットの例
  
  • 要求フェーズにじっくり取り組むことができるため、要求定義の品質が向上する。
  • 要求定義の品質が向上するため、追加変更要求が減少する。
  • 追加変更要求が減少するため、予算超過や遅延のリスクが軽減される。
  • 遅延のリスクが小さくなるため、品質の確保が容易になる。

• 契約はスケジュールとコストと機能のトレードオフを守るための重要な手段と心得ること。
  プロジェクトの成否を決める肝となる要素は、スケジュール、コスト、および機能（品質）です。これらの要素は相互に密接につながっており、他の要素へ影響を及ぼすことなく一つの要素を変更することはできません。スケジュールを短縮しようとしたらコストか機能、またはその両方に手をつけなければなりません。機能を増やすならばスケジュールを延長するか費用をかけて増員するしかありません。この自明の関係がシステム開発の現場では必ずしも自明とは受け止められてはいません。顧客からの「生産性向上で何とか対応してよ」との一言で、開発側自らこのトレードオフを見て見ぬふりをしてしまうのです。これはプロジェクト崩壊の序曲です。要求に曖昧さが残るのは仕方ありませんが、その曖昧さのリスクを開発側が全て受け入れてしまうのは、更なる曖昧さを助長するようなものです（※顧客自ら努力しよう、協力しようというインセンティブが薄れてきます）。プロジェクトを護るためにも（※これはもちろん顧客のためでもあります）、契約によって、これら３要素の変更に関して明確な「線引き」をしておく必要があります。

【シチュエーション】
仕様の追加変更
・決定されたはずの仕様が、設計・製造段階に入っているにもかかわらず、顧客の都合で変更される。

【予防策】
�@「仕様追加」「仕様変更」の言葉の定義を明確に定め、顧客と共通の認識を合わせておく。
�A仕様の追加変更が発生した場合の対応や、対応の前提条件を、あらかじめ契約の中に明記しておく。

【解説】
追加変更要求の取り扱いは双方納得の上で契約事項の一つとして明記しておくべきですが、その際には言葉の定義を明確にしておく必要があります。「変更とは何か」「どのような変更を仕様変更と呼ぶか」について開発側と顧客との間で事前に意思統一がなされていなければ、契約の中に変更時の対応が記されていても全く役に立ちません。

• 追加変更要求が発生した場合は、費用と納期の再見積を可能とするような契約を結ぶこと。
  例えば新たな要求の内容によっては納期の延長や費用の増額がありうることを顧客に説明し、事前に合意を得ておくことが重要です。実際にプロジェクトが始まってしまうと、新たな予算の増額を依頼するのは難しくなります。顧客の現場担当者では理解してもらえる話でも、予算を握っている人にその重要性を理解してもらい、かつ稟議を通してもらうのは至難の技です。その必要性をどれほど強く顧客担当者に伝えても、相手を板ばさみで苦しめるだけです。将来起こるであろうことを想定して、事前に契約を結んでおくのが一番です。

• 「仕様追加」「仕様変更」の判定基準となるスコープを明確にすること。
  契約時の明確なシステム仕様は、追加変更要求の発生時に予算の増額を要請する際の根拠となるものです。しかし契約時点では個々の要求について、それが「追加」か「変更」か、そのいずれでもないか、を判断できるほど詳細かつ明確に開発対象のスコープを定めることは実際問題として不可能です。したがって「仕様の確定時期」を明確にしておくことが重要になってきます。時期を明確にし、それ以降に発生した仕様については別途取り扱う旨の契約をしておきます。

• 「仕様追加」「仕様変更」の曖昧な判定基準は全て開発側のリスクと認識すること。
  グレーゾーンは力関係の弱い方が負担することになります。顧客は得てしてグレーゾーンを残しておきたがるものですが、グレーゾーンのリスクは全て開発側が負うものと考えておくことです。

【シチュエーション】
外部要因を原因とする遅延
・仕様がなかなか決まらない。回答期限が来ても回答をもらえない。

【予防策】
�@要求定義フェーズで獲得された要求の開発までを契約範囲とし、それ以降発生した追加変更要求については別契約にする。

【解説】
プロジェクトの不確定な部分を別契約にすることによって自社のリスクを切り離すことができます。ある一定期間内にまとめられた要件までを開発の対象範囲と明確に定めることができると、開発側にとってプロジェクトのリスクは格段に減少します。ただしそのリスクの減少は、「当初のコストとスケジュールを守る」という観点からのみ見たものであり、そもそものユーザのニーズの観点から見たものではありません。顧客満足度という点では相変わらずリスクを抱えたままであることに注意しなければなりません。

【シチュエーション】
外部要因を原因とする遅延
・顧客責任の調査作業の遅延にひきずられて、開発側責任の作業まで遅延してしまう。

【予防策】
�@外部要因を原因としてスケジュールに遅延が発生してしまった場合の対応や、対応の前提条件を、あらかじめ契約の中に明記しておく。

【解説】
メンバーの技術力不足や見積ミスなど、開発側の計画の甘さを原因とするスケジュールの遅延は、自らその痛みを噛みしめるべきでしょう。しかしスケジュールの遅延は、その原因が外部にあることも稀ではありません。原因の切り分けがきちんとできていないと、後になって遅延の原因を十把一絡げにして、その責任が顧客側に一方的に押しつけられてしまうことにもなりかねません。その時点になってから「お客さんがすぐに回答をくれないから」などと言い訳をしても９９％は無駄なあがきにしかなりません。

４．見積による護身

• 見積時の情報不足を十分認識した上で、過少見積に注意すること。
  見積時点で獲得している情報は非常に限られているものです。情報が不足していると、実際の開発量も少ないものだと錯覚しがちです。しかし詳細で複雑な仕様や難しい問題は、当初の曖昧な要求の中に隠れていて、見積段階ではわからないことも多いものです。また、当初は影も形も見当たらなかった機能が、開発の半ばを過ぎてから「絶対に必要な機能」として浮かび上がってくることもあります。可能な限り正確に見積ったつもりの数字でも、実際の値はその1.5倍以上になることは稀ではありません。

• 未知の事項も見積の考慮に入れること。
  未知の事項とは、要件自体が未知である場合と、要件は明らかだが必要となる作業が未知である場合の、双方の意味を含みます。見積は（その定義上）既知の情報だけをインプットとして行うものではありません。未知の事項があれば、未知のままで見積を行わなければなりません。しかしそれは未知であることを十分認識し、考慮に入れた上での見積でなければなりません。同じ既知の情報量をベースに見積った値でも、未知の事項を考慮した見積と、全く考慮していない見積とでは、当然ながらその値に大きな差が出てくることになります。

• 未知の事項の見積には、経験以上に頼るべきものはないことを覚悟すること。
  未知の事項に対して何を根拠に見積を計算するのか、という当然の疑問があります。確かにインプットが未知である限り、そこに第三者を納得させるだけの論理的な見積の算出理由は存在しません。もちろん未知をインプットとする手法やツールなどというものは存在しません。ここでは（個別のレアケースを除いては）長年の勘と経験に頼らざるを得ないのです。ただし「勘と経験」という理由で顧客を納得させることはできません。そのためのロジックは別途考えるべきです。（※顧客の利益になる「嘘」ならばついてもよいのかという疑問は残ります。それに対しては「個別判断」としか答えられません。）

• 見積のインプット情報すなわち開発の作業工数に影響を与える様々な条件は、あらかじめ顧客の目に明らかにしておくこと。
  見積はプロジェクトにおける様々な前提条件や制約条件を前提に作成されます。前提条件や制約条件が変われば当然ながら見積の値も変わります。自明の事ですが、この点は顧客にしっかりと認識しておいてもらう必要があります。と同時に、その認識を契約上でも可能な限り明確にしておくべきです。これは、減らすことが可能なリスクは、全て減らすための行動を起こすべきだという、プロジェクトに対する重要な姿勢です。

• 見積条件は十分に顧客に説明し、理解を得ておくこと。
  見積条件を明確に設定せずに、あるいはきちんと顧客に説明せずに提示した見積は、顧客に無用な期待を抱かせる原因になります。十分な説明がない限り、顧客がその見積の前提条件を意識することはありえません。表に出てきた見積の数字をそのまま受け止めて、外的要因の変化などを想像する由もなく、その数字のままでシステムが完成するものと思い込んでしまいます。

• 見積の前提条件が変わった場合には、再見積が可能となる契約を結ぶこと。
  最上流工程において、見積条件の設定は最も重要なポイントの一つです。現実が計画から乖離してきたとき、当初の見積の前提が崩れてきたとき、顧客には再見積の依頼をする必要があります。前提が覆った場合は再見積が可能となるような契約を結んでおくべきです。そうでなければ顧客の気まぐれ（種々の追加変更等）によって自社の利益が簡単に飛んでしまいかねないリスクを放置することになります。

【シチュエーション】
・追加変更要求が次々と発生するが、リソース不足のため対応できない。
・当初の見積と実績との誤差が大きく、計画通りにプロジェクトを進めるためにはリソースが不足している。
・技術的な問題への対応に想定外に時間がかかり、リリース日の厳守が難しい。

【予防策】
�@余裕を持った見積の重要性を顧客に説明し、理解を得る。
�A余裕を持った見積でプロジェクト計画を立てる。
�B顧客の理解が難しい場合は「もっともらしい理由づけ」をしてでも内部に余裕を作る。
�Cどうしても余裕を作れない場合は、追加変更要求が発生する前から、その事後対策の検討を開始する。

【解説】
追加変更要求に対する最も重要かつ効果的な予防策とは、余裕を持った見積と、それを顧客に納得させる説明です。仮に顧客が自社と契約した最大の理由が価格である場合、どのような正当な理由があったとしても費用増額の交渉は難しくなるものです。そこで、あらかじめ見積の中に「枠」を確保しておくのは最も有効な対策と言えるでしょう。ただし余裕を持った「枠」の確保は理屈で言うほど簡単ではありません。確かに余裕を持った見積をすることにより、ある程度の追加変更要求までは吸収することがでます。これは暗黙に見積に含めてしまう場合もあれば、明確に予備費という項目を設定する場合もあります。前者の場合は「発覚」した場合は信頼関係が一気に崩れるリスクは拭えません。後者の場合は事前に顧客への説得作業という「壁」を乗り越える必要があります。いずれの場合でも、余裕を持った見積は競合他社との競争で不利に働くことは間違いありません。本書のテーマから少々逸脱しますが、この「受注前の顧客説得能力」が非常に重要なことは間違いありません。

５．設計による護身

※本書のテーマは要求定義です。設計は本来のテーマではありません。しかし要求定義のミスをカバーする手段として、設計は決して小さくない役割を果たすことができます。

【シチュエーション】
・顧客の複雑な要求を、複雑なまま設計している。
・顧客の要求を、（テクニカルに懲りすぎて）過度に複雑に設計している。

【予防策】
�@プロジェクトのキックオフ時に、開発チーム内で「Simple is Best」をプロジェクト推進方針、設計方針として共有する。
�A顧客の「複雑な」要求は、可能な限りシンプルな機能に落とし込むよう考える。

【解説】
機能そのものの目的として複雑さが要求されるような場合を除いて、機能はできるだけシンプルな仕様、シンプルな作りに抑えるべきです。機能に複雑さを付与する場合でも、まずはシンプルな構造、シンプルな機能を実現することを目指すべきです。機能として「最低限使える」レベルであっても、まずはこのシンプルなシステムが完璧に動作することを確認した後で、複雑さの付与を考えることです。以下は「Simple is Best」が推奨される理由の例です。
・システムが2倍複雑になると難易度は4倍になる。
・システムの難易度が高くなると、費用、品質、納期、全ての面でリスクが高くなる。
・システムの難易度が高くなると、トラブル発生時の故障原因の特定および修正が困難になる。

６．プロセス（変更管理計画）の検討

【シチュエーション】
・頻発する追加変更要求で、プロジェクトが管理の危機に瀕してしまう。

【予防策】
�@変更管理のためのプロセスを導入する。

【解説】
予防策として「変更管理のためのプロセスを導入する」と書きましたが、実は教科書に書いてあるような「変更管理計画」で変更を管理できるほど現実は簡単ではありません。例えば品質をテーマに考えてみます。試験フェーズでできることは現在の品質レベルを知ることぐらいのものであり、そこに至った時点では抜本的な品質向上などは望むべくもありません。本来は品質はずっと前の段階で作りこまれていなければならないものです。スコープ然りです。教科書に書いてあるような「スコープ管理計画」で要求の変更を管理できると思ってはいけません。実際に発生する追加変更要求は、管理計画で管理可能な許容範囲を簡単に超えてしまうのです。「変更管理計画」とは、品質管理における試験フェーズの役割に似て、そもそも目的を達成するための本質的な作業とはなりえないことを忘れてはいけません。余程の大規模システム、重要システムでない限り、現場の臨機応変な対応の補助として考えておく程度がよいでしょう。以下は、追加変更要求の管理プロセスの例です。
・顧客の変更依頼の受付
・ヒアリング・インタビュー
・要求の整理・分析
・影響度調査
・開発前提条件・制約条件の検討
・開発可否の判断（開発側/顧客側）
・修正者への依頼
・修正
・修正の検証
・導入

• プロセスの導入を検討する際には、そのトレードオフの関係を念頭に置いておくこと。
  プロセスというもののご多分に漏れず、追加変更要求への対応プロセスも現場にとってはオーバーヘッドとなります。追加変更要求に対するレビューや開発可否の判断、承認といった管理プロセスは間違いなく現場の負担となるでしょう。それが最終的な顧客価値を付加することはありません。逆に遅延の原因になることを認識しておく必要があります。管理プロセスの意義は、追加変更要求に対して正しい判断を下すことができないリスクと、リソースを無駄に食いつぶしてしまうリスクのバランスから考える必要があります。追加変更要求の管理プロセスは、その必要性とコストのバランスを考えなければならないのです。

• プロセスが役に立つか否かはプロジェクトに依存することを念頭に置いておくこと。
  追加変更要求への対応プロセスは、これまでの「間違った対応」により被ってきた手ひどい失敗を繰り返さないために考えられたものです。しかしその意図は良いのですが、プロジェクトにはそれぞれ独自の要因があり、そのプロセスが実際に役に立つものかどうかは別問題です。したがって現場のオーバーヘッドを増やしてプロセスを導入したとしても、必ずしもリスクの軽減が約束されるわけではないことを認識している必要があります。

• プロセス導入にあたっては、そのプロジェクトの属性に最も合っているプロセスがどのようなものかについて検討すること。
  プロセスというものは、全てのプロジェクトに画一的に適用されるべきではありません。プロジェクトが持つ独自の様々な属性に合わせて、オリジナルのプロセスが作成されるべきです。
  ◇プロセス導入にあたって検討すべきプロジェクトの属性の例
  • プロジェクトの規模（工数、期間）
  • プロジェクトの新規性
  • プロジェクトの複雑度
  • プロジェクトの技術的難易度
    
    
• プロセスを適用するシチュエーションを検討すること。
  プロジェクト毎に作成されたプロセスでも、状況によっては随時臨機応変な対応が要求されます。例えば、影響範囲が特定できる非常に小さな変更要求にまで、重量級のプロセスを適用すべきではありません。選択に当たっては効率的に処理できるような柔軟さが必要です。「プロセスに従わなくてもよいケース」を例として設定したり、別の軽量級のプロセスを準備しておくべきでしょう。どんなわずかな変更でも正規のプロセスに乗せてしまうようなルールを作ってしまうと、開発チームを護るためのプロセスが逆に開発チームを苦しめる結果となってしまいます。

原因の考察について

１．原因とその対処について

問題への対処には予防が一番です。問題というものは一旦発生してしまうと、その治療は困難であることが多く、また、それが可能であっても大量のリソースを消費してしまうものです。発生してしまうと治療がほとんど不可能な問題もあります。要求定義の問題を考える場合は、まずは治療することよりも予防することを心がけておくことです。

ある問題に対処するには、まずはその病気の原因をはっきりさせる必要があります。問題とその原因が単純に１対１で対応づけられるのであればコトは簡単ですが、多くの要素が複雑に絡み合うシステム開発のプロジェクトでは、そううまくはいきません。原因は多岐に渡ります。絡まった要素を解きほぐし、それぞれの原因に対して、それぞれの対応策を考えていかなければなりません。また、ここで「それぞれの原因」と書いていますが、原因は個別の要素に還元できるものばかりではありません。問題は個々の要素からではなく、要素同士の関係性や相互作用の中から生じているのかもしれません。その場合の対応は要素ではなく関係性にターゲットを絞ったものになります。単純に「あいつが悪い」というわけにはいかないのです。

以上のことを前提として、プロジェクトを制御していく上で更に難しいのは、問題を引き起こす個々の原因全てに対応していかなければならないという点です。10個の原因が考えられるならば、10個全てに対応しなければなりません。10個のうち8個まで対応したら80点のシステムができるというものではありません。1個でも見逃してしまえば、それが問題を発症させてしまいます。エンジンもタイヤもギヤも、全てが揃い全ての問題が解決されない限り、クルマはまともに走らないのです。

「問題と原因」と口では簡単に言っていますが、そこには機械を相手にするときのような、結果を確実に約束してくれる予防策や治療法というものはありません。様々な問題を検討するに当たって、文献を開いてみれば書いてあるような単純な予防策や解決策が、問題を解決してくれるだろうと期待することはできません。パラメータに変数をセットすれば目をつぶっていても正解に導いてくれるような公式はありません。事実、要求定義の世界では形式的な解決策は（多くの努力にもかかわらず）未だ研究室のレベルを出ていません。属人的なスキルに大きく依存しているのが現状です。問題を解決するためには、既存のテンプレートに頼るだけではなく都度、自らの頭を働かせる必要があるのです。

２．先達の知恵の利用

正解を約束してくれる公式はありませんが、頭を働かせれば有効に活用できるリソースは存在します。それは過去の先達の貴重な経験から積み重ねられてきた「経験則」です。それは数学よりも国語に近い曖昧なものであり、使用に当たっては各人の経験によって解釈も行動も微妙に（あるいは大きく）異なってくるものです。しかし経験則の価値は、まさにその曖昧さの中にこそあります。曖昧であるがゆえに、人間の特権である想像力と柔軟な判断力を駆使することによって、特定されない様々な場面における個別の問題に、臨機応変にその知恵を活かすことができるのです。

問題の原因を探るにあたって、何の手がかりもなく手当たり次第に当たってみるのは、あながち馬鹿にしたやり方ではありません。特に「未知の問題」を扱う際には、机上であれこれ思案するよりは、よほど有効であったりするわけです。しかしこのやり方を「よく発生する問題」に対して用いるのは非効率と言わざるを得ません。確かに結果を約束してくれる公式は存在しませんが、前述のような先達の蓄積された経験が存在します。それが常に役に立つわけではないという曖昧さは残りますが、まずはここから解決への糸口を探ってみるのが定石と言えるでしょう。

ここで難しいというか面白いのが、実際に過去の知恵をどのように扱うかという問題です。同じノウハウでも文脈が違えば適用の仕方も違います。同じ知恵が使えそうだと判断できる場合でも、あえて「使わなかったらどうなるか」「逆の使い方をしたらどうなるか」などの思考実験をしてみてください。複雑さへの適応センスが養われていくはずです。

ただ、一つ気をつけなければならないのが、「発生頻度が低い問題」に対する先達の知恵や過去の経験です。行為と結果の間には確かに相関関係があったのかもしれませんが、本当にそこに因果関係が存在しているのかどうかはわかりません。実は「逆方向に漕いでいた」にもかかわらず、他の外部要因が「正しい方向に漕いでいた」ために全体として正しい方向に進んだだけなのかもしれません。

３．要求定義の構成要素

問題解決手法の一つとして、「細分化して考える」というものがあります。（MECE的な分類を前提にするならば）この細分化のメリットのロジックが要求定義の問題を扱うに際してどこまで妥当なのかはわかりませんが、少なくとも検討洩れを減らしてくれるフレームを提供してくれることは間違いありません。

細分化の切り口は一つではありません。こうでなければならないという特別な約束はありません。たとえば前著（要求定義のチェックポイント４２７）では要求定義のフェーズを時系列に分類し、そのフェーズ毎にチェック事項を洗い出していきました。これは初心者のための作業手順ガイドという観点から見れば妥当なものだったと思いますが、分類の基準が曖昧で客観性や論理性に薄く、検討洩れの防止という目的にはあまり適してはいないかもしれません。

本書では、要求定義の作業を構成する要素は何か、という切り口から細分化を考えてみます。要求定義の問題は、（当然ながら）要求定義の作業の中にその原因が隠れており、その作業を構成する要素ごとに問題を考察していくことにより、原因の洗い出しの洩れが少なくなると考えるためです。

早速、要求定義の作業を構成する要素を考えてみますが、ここで注意すべきは（これは切り口を検討する際にも言えることですが）、あまり「真実の構成」を見つけようとして頑張らないことです。洩れを防ぐためには構成が論理的であることは重要ですが、相手にしているのが複雑な現実であるということを忘れてはいけません。学問として考えているわけではありません。できるだけ洩れなく現場の問題の原因を洗い出していくのがそもそもの目的です。「現実的」な構成を考えてみることです。

以下は要求定義作業の構成要素の分類例です。

1. 開発組織
2. 顧客組織
3. 業務のASIS（現行業務）
4. 業務のTOBE（システム要求）
5. 要求定義のアクション

この分類の意図、その「ココロ」は、「要求定義の作業とは、『開発組織』が『顧客組織』から『要求定義のアクション』を通じて『顧客のASIS』と『顧客のTOBE』を獲得していく作業」、というものです。

もしかすると違和感を覚えるかもしれませんが、ここでは要求定義の成果物をターゲットに考えているわけではないことに注意してください。成果物をターゲットにするならば、要求仕様書の目次があるいは「構成」となるかもしれませんが、ここでターゲットにしているのはもう一つ上の次元です。本書のテーマは要求定義の成果物の品質ではなく、その成果物を生み出す「元」もしくは「過程」の品質です。

４．自ら「手を動かす」作業のススメ

さて、細分化によって思考が刺激されることは間違いありませんが、細分化が提供できるのはそこまでです。細分化や構造化自体が、問題の原因を洗い出すに当たっての明確な道筋を明らかにしてくれるわけではありません。「解」を論理的に推測したり導いたりするためのツールを提供してくれるわけではありません。美しく精緻化された構成でもそれは同様です。ここから先は合理的思考よりも過去の経験や知識が大きくモノをいうことになります。

ところが人間というものは忘れる動物で、過去に多くの経験を蓄積していたとしても、二度三度と同じ間違いを犯してしまったりするものです。ちょっとしたきっかけさえあれば思い出したはずの記憶も、それがなかったばかりに思い出せず、結果として同じようなミスをしてしまうのです。

要求定義の作業をその構成要素別に検討していくこと自体が、記憶を刺激する重要なきっかけになります。しかしそれだけでは不十分です。ここで役に立つのは、抽象的で一般化された理論ではなく、現実に即した具体的な例です。具体的な例というものは、それを挙げられることによって「あっ、そういえば」といった具合に、関連した記憶を蘇らせてくれるものです。本書では思考と想像力を刺激するような、具体的な原因や予防策の具体例を挙げていきたいと考えています。

ただし本書はあくまでもサポート役にすぎません。あくまでも主役は現場のマネジャーであり、現場のエンジニア自身です。自ら手と頭を働かせることを厭っていてはいけません。例を参考にする場合でも想像力は必要です。漫然と例に倣って手を打っていくだけでは不足です。

例えば、本書では問題別に原因を紹介していますが、その原因が実は他の問題の原因になっていることもあります。他の問題の原因とされているものが、当の問題の原因にもなっていることもあります。本という（重複を許さない）木構造の中でしか情報を整理できない世界で、現実の複雑な情報の絡み合いを表現するのは限界がありますが、その限界は担当者個人個人の想像力で補っていただく必要があります。

また、「情報の絡み合い」とは別に「洩れ」の問題も考えなければなりません。実際、ある問題の原因を（全てのプロジェクトを考慮しながら）ひとつ洩らさず挙げていくことは不可能です。実際のプロジェクトに当たっては、本書の例をガイドにしながらも100%それに頼ることはなく、自らの経験に基づいてオリジナルの「原因リスト」を作ってみることです。

予防策の検討について

予防策の検討は重要な作業ですが、原因の考察に比べればそれほど難しい作業ではありません。要求定義に限らず、正しい問いが与えられれば解の多くは自ずと明らかになるものです。原因の洗い出しと検討が終わった時点で、予防策の多くはさほどの困難なく導かれることでしょう。

ただし、導かれた解（予防策）の実施が、容易であるかか困難であるかはまた別問題です。ここで心に留めておかなければならないのは、具体的な解が見えたならば、その実施が困難だからといって頑張って実施が容易な別の解を探そうとはしないことです。それはおそらく時間の無駄となります。実際のところ、実施が困難な解しかないのであれば、それはプロジェクト自体がそもそも難しいプロジェクトと考えるべきです。プロジェクトが困難なのは、容易な解が思いつかないマネジャーや担当者の責任ではありません。それがそのプロジェクトの性格なのです。そして難しいプロジェクトは、プロジェクトマネジャーの力量に任せるべき部分です。

予防策の実施が必ずしも完全に問題を予防するわけではないということも覚えておくべきです。「では一体何のための予防策か」という話にもなりますが、要求定義とは相手と自分との相互作用です。予防策が対象とするのは客観的な存在だけではありません。対象の中には自分自身も含まれているのです。自分の振る舞いによって結果が変わってくるのは当然です。

また、解はさほどの困難なく導かれると書きましたが、それは解の多くがトートロジー（同語反復）になるようなものだからです。例えば、「顧客が理解していない」ことが問題の原因であれば、予防策は「顧客が理解するようにじっくりと説明する」というようなものになります。一般にトートロジーは「意味なし」というニュアンスで捉えられることが多いのですが、要求定義の世界では決して「意味なし」であるとは言えません。ここで重要なのは論理の正しさや美しさではなく、現実の結果が出るかどうかです。トートロジーであっても、それが現実の行動、効果的な行動に結びつくものであれば、十分有効な予防策と考えることです。ただし言葉だけが踊った、実践的でないトートロジー的予防策には意味がありません。また、美しい論理でつながった予防策でも、それが非現実的であったり、明らかに効果が薄いと思われる場合は、それもまた容赦なく捨ててしまわなければなりません。

予防策の中に具体的な行動が見えない場合は、原因をもう少し深掘りして考えていかなければなりません。原因の深堀りと言っても、純粋な論理から類推して更なる原因を見つけようとするのは難しいかもしれません。ここでは経験や知識がモノを言うことになります。以降、要求定義における主要な１０の問題についてその原因と予防策の例を見ていきますが、そこでは先達の経験と知識を基にした解決のヒントを紹介しています。考え方の参考にしてみてください。

治療法の検討について

１．治療の難しさ

繰り返しになりますが、システム開発で発生する様々な問題は、まずは予防に全力を尽くすことが前提です。一旦問題が発生してしまうと、できることは非常に限られており、しかもその「できること」でさえ本当に問題解決につながるのかどうかはマネジャー次第、担当者次第、プロジェクト次第になってしまいます。確実な結果は約束されません。むしろ期待通りにいかないことの方が多いのではないかと思います。

とは言うものの実際問題として予防も容易ではありません。なぜならば予防策はあくまで過去の事例に則ったものにすぎないからです。ところが過去の事例からは予想もつかない新しいこと、初めてのことがが次々と発生するのがシステム開発の常です。予防策でどこまで当の問題を予防できるのかは「やってみなければわからない」というのが本当のところです。そして予防策の網をかいくぐった問題は必ず発生します。

予防策の網をかいくぐった問題に対しては、もちろん対応しなければなりません。しかし「人間の曖昧さ」と「過去の経緯」を巻き込んだ複雑な原因を根本から解きほぐしていくことは非常に困難です。治療法は得てして対症療法的になりがちですが、その対症療法でさえ、「効けばもうけもの」くらいの効果しかないかもしれません。そしてそのわずかな効果を引き出す治療でさえ、副作用としてプロジェクトに別の大きな「痛み」を強いるものになるかもしれないのです。

特効薬はありません。症状が同じだからといって、千差万別の個別のプロジェクトに共通で効く万能薬はありません。状況状況によって、要素単体にアプローチしなければならないかもしれませんし、要素間の関係性にアプローチしなければならないかもしれません。その関係性にアプローチするためには別の要素にアプローチしなければならないかもしれません。目に見える明らかな効果は、おそらくプロジェクト独自のオリジナルの治療法からのみ得ることができるでしょう。独自の要素を考慮せずに「出来合い」の薬を服用しても、直るか直らないかは「神のみぞ知る」といったところです。もちろん、これが難しいからこそ多くのプロジェクトが「タールの沼」から逃れられずにデスマーチを繰り返しているのですが、なんとも途方に暮れるような現実と言わざるをえません。

本書では何にでも効く万能薬をあきらめる代わりに、オリジナルの解決策を導くためのヒントを提供したいと考えています。「タールの沼」から抜け出るためにはどのような行動を取るべきなのでしょうか。何にアプローチすべきなのでしょうか。しかしその答を獲得するためには、「何を考えなければならないのか」という、考えのきっかけがなければなかなか考えつくものではありません。本書はその「気づき」のきっかけとなるような「問い」や「ノウハウ」を紹介していきたいと考えています。自らその「問い」のについて考察し、次に取るべき行動を考えてみてください。マニュアルはありません。本当の効果が欲しいのであれば、自らオリジナリティのある治療法を考案していくべきなのです。

２．小さな定石集

問題は多種多様であり、治療もその多様性に応じて多様であるべきです。ここではその治療に当たっての心構えを紹介します。

• 「これしかない」というような治療法、問題解決法に対しては、一歩引いたスタンスがよさそうです。治療法が単純明快かつ実施も容易というものであれば、そもそもその問題は発生しなかったはずです。本当に役に立つ治療法というものは、ある状況では役に立って、別の状況では全く役に立たないような二面性を持つものが多いようです。

• くれぐれも「自分の力」だけで問題を解決しようとしてはいけません。「問題が発生した」「原因を見つけた」「原因に対処した」で解決されるような簡単な問題はありません。そのような問題は問題として目に触れる前に解決されてしまうでしょう。問題が問題として表面化してしまった時点で、それらは全て難しい問題と考えるべきです。多方面へのアプローチが必要になるはずです。

• 抗がん剤が副作用をもたらすように、ある治療のための制御がその問題だけにピンポイントで「効く」ことはありえないことを覚悟しておくべきでしょう。必ず何らかの別の効果が生ずるはずです。この副作用の動きには注意を払っておかなければいけません。思わぬところで大きな問題に育ってしまうかもしれません。

• 文献でどれほど魚の知識を仕入れても、泳ぎ、食べ、産卵しているところすら見たことがなければ、どれだけ魚のことを知っていると言うことができるでしょうか。何科の何目という知識、鱗が何枚だという知識は、魚が持っている全情報のほんの一部分のそのまた一部分にすぎません。魚が弱っているのであれば、一面的な定量データのみに頼らずに、魚そのもののリアリティを見る努力をしなければなりません。

• 定量データは現実のスナップショットです。ある一時期の静的な状況を伝えているにすぎません。問題がその静的な側面から明らかになればよいのですが、それが動的な側面すなわち時間の経過と大いに関係があるのならば、定量データは問題解決にはあまり役に立ちません。

• いざ問題が発生してしまうと、要求定義の担当者にできることは限られています。実際、本書で紹介する治療法の多くはプロジェクトマネジメントの領域に踏み込んでいます。実際の問題解決に当たってはマネジャーと二人三脚で進めていくべきでしょう。

問題同士の関係について

本書では要求定義における主要な10の問題を取り上げ、それぞれについて原因や予防策、治療法を紹介しています。ただしここで注意しなければならないのは、問題というものを単独で捉えてはいけないということです。原因があって結果があるという、単純な一方向のみの因果関係を考えてはいけません。問題の多くは相互作用の中から発生し、何が鶏で何が卵か、全くわからなくなっているような状況が普通の現実の姿です。

もちろん本書で紹介している問題同士にも相互関係が存在します（図参照）。単純な構図に見えますが、これはあくまで表面上の現象を結びつけただけのものです。一方向のみの単純な因果関係に見えるものでも、原因レベルまでを考えると、多くの要素と多くの相互作用が存在しています。そこには原因が問題を作り、問題が原因を作ってるような関係があるのです。

問題が発生するとマネジャーが「もっともらしい」対策を打ち出しますが、「この対策は本当に効果があった」と実感できるような対策が打たれたことがあるでしょうか。システム開発の現場でそのような経験をしたことはほとんどないのではないでしょうか。ほとんどの場合、対策を打っても現場の状況はあまり変わらなかったのではないかと思います。当然と言えば当然です。一つの原因だけを小手先の対症療法で叩いても、それで状況が変わるほど現実は単純ではないのです。

この教訓をどのように活かせばよいのでしょうか。前述しましたが、それは思いつく限り全ての予防策・対策を打つということです。10個の原因が考えられるならば、10個の原因全てにアクションをかけることです。鶏か卵かなどと言っている場合ではありません。鶏にも卵にもアクションをかけるのです。当然、担当者の負荷は高くなります。余裕があるように見える要求定義作業も、徹夜しなければならない作業であることがわかると思います。

問題の考察

１．典型的な症状

要求定義フェーズが完了した。スケジュール通り、順調に進んでいる。顧客との関係も良好である。肝心の要求も、定期的なヒアリング会議によって十分に獲得できたものと思う。業務上の意味がよく理解できない要求もあるが、顧客がこれで良いと言っているのでおそらく良いのだろう。意味を深く追求したい気もするが、そこまで詳細にこだわっていてはスケジュールが遅れてしまう。今の時点で進捗を遅らせてまでわざわざ確認することはないだろう。

個別のアプリケーションの概要設計フェーズに入っている。要求をヒアリングする会議は要求定義フェーズで終わりになるはずだったのだが、現在も続いている。本当は最後になるはずの会議で未決事項や保留事項がかなり残っていたため、「では次週もやりましょう」ということで始まったのだが、「なんだかんだ」で次週だけでは終わらずに今までだらだらと続いている。会議の場では、最初は全く話にも出ていなかった要求がちょくちょく出ている。プロジェクトに大きな影響はないとは思うが気になる。進捗自体にも遅延はないがメンバーには時折残業が発生している。

スケジュール上は詳細設計フェーズに入った。とはいえ、一部の機能はまだ概要設計を引きずっている。ヒアリング会議で顧客が毎回新しい要求を出してくるため、なかなか仕様が確定しないのである。そもそもヒアリング会議がまだ存在していること自体がおかしい。なぜこんなことになってしまったのだろう。

詳細設計も佳境である。メンバーの残業時間は目に見えて増大している。しかし新たな要求は「定期的に」発生しており、収まる様子もない。さすがにプロジェクトに危機を感じてきた。顧客にはこれ以上の追加要求は対応できないと伝えたが、「それでは業務がまわらない」と言われると返す言葉がない。メンバーには申し訳ないが、ここは顧客のために頑張ってもらうしかない。

コーディングフェーズに入った。要求は相変わらず不安定なままである。メンバーの中には、明らかに疲労感が漂わせている者もいる。確かに意味のある残業ならば耐えられるかもしれないが、同じ作業のやり直しばかりでは疲れるのも当然だ。ようやく要求にタイムリミットを設けることで顧客の合意を取りつけた。これ以上の仕様の膨張は余程のことがない限りないはずである。

ところが現実には要求のタイムリミットは全く機能しなかった。確かにタイムリミットを設けた直後は要求は発生しなくなったが、それも一時的なものだった。2週間も経つと前と変わらない状態になってしまった。タイムリミットを理由に要求を断っても、「業務がまわらない」という顧客のいつもの主張には勝てないのである。メンバーは明らかに残業過多である。モチベーションが低下しているメンバーもいる。プロジェクトは明らかに危険水域にある。

なぜ要求が確定しないのだろうか。しかしよく考えてみると、新しい要求は次々に発生するが、その最終的な業務上の目的はよくわかっていない。根本的に、何のために必要な仕様なのだろうか。要求定義フェーズで「突っ込んで」ヒアリングしておくべきだったのだろうか。しかし現実的にスケジュールを考えると、そこまでできただろうか。

チームメンバーは皆疲れている。ダラダラ感が漂ってきている。そんな時、一部の機能に、覚えのない仕様が追加されているのが目についた。他の機能もよく見てみると、把握していない仕様の追加が複数見つかった。調査してみると原因は大きく3つに分けることができた。一つはメンバー自身が顧客のために「よかれ」と思って自ら追加した仕様、もう一つはメンバーの単純な技術的興味から追加された仕様、最後は顧客が開発メンバーに直接依頼して追加した仕様であった。要求は既に管理下から離れている。検収のことを考えると頭が痛い。

２．問題の考察

システム開発に携わったことがあるならば誰でも、仕様が延々と膨張していく現場を経験をしたことがあるはずです。私も数多くのプロジェクトに携わってきましたが、仕様が膨張しないプロジェクトに遭遇したことはありません。どのプロジェクトでも多かれ少なかれ、必ず仕様は膨張していったものです。

実際の話として、業務のスペシャリストがしっかりとした要求定義を行っても仕様は膨張するものです。仕様の膨張の原因にはしばしば、要求定義のスキル不足や、業務の理解不足が挙げられるのですが、問題はそれほど単純ではありません。たとえ顧客の担当者以上に業務を理解しているSEでも、重箱の隅まで要求を洗い出せるスーパーマンはいません。そして得てしてこの重箱の隅には、「小さな要求」どころか「新たな重箱」を発生させかねない重大な「きっかけ」が隠れているのです。

さて、簡単に膨張していく仕様ですが、その影響まで「簡単」に考えることはできません。「塵も積もれば」ではありませんが、小さな仕様の膨張でも積み重なればプロジェクトに重大な影響を及ぼします。

例えばコーディングには10分もかからないような「安請け合い」した小さな要求でも、本番リリースまでに必要とされる作業はコーディングだけではありません。再設計から再試験、他の要件との整合性の維持、メンテナンスが必要となる種々のドキュメンテーション、構造の複雑化、保守性の低下、障害時の影響範囲の増大など、プロジェクトに課せられる負荷は多岐に渡ります。仮にその追加仕様が原因で障害が発生した場合、実作業以外に必要となる品質会議などの付随時間・関連作業時間を含めると元々10分のコーディングだったものが一人日にも二人日にもなってしまってもおかしくはありません。

また、正式な変更管理プロセスに乗らない仕様の膨張は、プロジェクト収支を圧迫する大きな原因の一つです。契約金額が固定の請負契約では、仕様の膨張はプロジェクトの成否を左右しかねない重要事と認識すべきでしょう。にもかかわらず仕様の膨張を安易に容認してしまう現場リーダーが多いのもまた事実です。（※話がそれてしまいますが、このようなリーダーには机の前にプロジェクトの予想収支を貼っておき、仕様が膨張するたびに利益が減っていく様子を「見える化」するくくらいのことをしなければ、本当に意識的になることは難しいかもしれません。）

さて、容易に発生し、かつプロジェクトへの影響も無視できない仕様の膨張ですが、流れを逆方向へ持っていくのは非常に困難です。一旦膨張した仕様を縮小させようとすれば、相当のトラブルと混乱を覚悟しなければなりません。急流の中を上流に向けて重い舟を漕いでいくようなものです。実際、一旦「やります」と請け負ってしまった顧客の要求は、苦しくなったからといって「やはりできません」などと簡単に断ることはできないでしょう。膨張してからの対応は困難です。まずは仕様を膨張させないように、予防に全力を尽くすことです。

原因と予防策の一例

１．開発組織の問題

【原因】
・顧客からの要求は最大限に受け入れるべきだという文化が開発組織にある。
・顧客からの要求はルールを破って受け入れても仕方がないという文化がある。
・マネジャーが過剰に顧客志向である。マネジャーが顧客の要求を全て実現しようと頑張ってしまう。

【予防策】
�@（顧客ではなく）自社にとってのプロジェクトの目的と、その目的の優先順位を明確にする。
◇自社にとってのプロジェクトの目的の例
・プロジェクトの利益をあげる。（本プロジェクトでの利益の最大化）
・プロジェクトの利益をあげる。（長期的スパンで見た場合の利益の最大化）
・これまでの顧客との関係を維持する。
・このプロジェクトを「次の大きな仕事」を受注するための布石とする。
�A過度の顧客志向が、自社のプロジェクトの目的に則したものかどうかを判断する。
�B過度の顧客志向による影響が、プロジェクトの目的を失することがないかどうかを検討する。

【解説】
顧客の満足を第一に考え、顧客の要求を全て実現しようとしたシステムは、逆に開発リスクを高め、顧客の失望を買うような結果に終わりかねません。当初の思惑とは正反対に、顧客に最大の迷惑をかけてしまうことになるのです。顧客から「100万円でベンツを作ってくれ」と言われたら、「はい、一生懸命頑張ります」と答えるのが正しい対応ではありません。「100万円ではベンツは作れない」ということを、根気強く説明するのが正しい対応です。そうでなくても開発側自ら、顧客の「便利」になる機能、追加できる機能は次から次へと思い浮かんでくるものです。顧客志向のマネジャーはこれらの機能を全て盛り込みたいと思う自らの願望に気をつけるべきです。S.マコネルは言っています。「約束過多の人は最初は楽ができるが、結局は苦しい思いをすることになる」

【原因】
・そもそも開発側に、仕様の膨張への危機意識が薄い。
・開発側にシステム開発に関する知識や能力が不足している。

【予防策】
・マネジャーあるいは担当者を交代する。

【解説】
開発側の組織の人間が仕様の膨張やその影響に無関心であったり無頓着であるならば、厳しいことを言うようですが、その組織はプロジェクトを推進していく立場としての資格はありません。今から勉強してもらう時間はありません。手遅れになる前にマネジャーやリーダー、担当者を交代すべきです。

【原因】
・開発メンバーが善意から、マネジャーや顧客への確認なく勝手に機能を追加している。

【予防策】
�@勝手な仕様追加、便利機能の追加はプロジェクトのリスクを無用に高め、結果として顧客に迷惑をかける可能性が高まることを開発メンバーに説明する。
�A善意から出たものであっても、勝手な仕様追加、便利機能の追加は厳禁する旨を、開発メンバーに徹底する。

【解説】
開発途中で要求の不備や不足に気づいた場合、プロジェクトへの影響を勘案しながら、そして顧客に確認の上で仕様を追加すること自体に問題はありません。しかし開発者は時に、業務のニーズとは無関係な、あるいは他の機能との調和を壊すような仕様を勝手に追加してしまうことがあります。いわゆる「飾り」や「金メッキ」と呼ばれる仕様で、本人は顧客のために善意で行ったのかもしれませんが、これは（特別な事情がない限り）無条件に禁止すべきでしょう。リソースが無駄に費やされるばかりではなく、システム全体の統一性にも影響を及ぼします。もともとの顧客の要求と実現したシステム仕様の紐付けも曖昧になります。

【原因】
・開発者が技術的な興味から、マネジャーや顧客への確認なく勝手に機能を追加している。
・マネジャーが開発メンバーの「技術者としての本能」を理解していない。

【予防策】
�@まずはマネジャーは、技術者の「自分が知らない技術へのニーズ」を理解すること。
�A技術的関心のためだけに要求されていない仕様を追加させてしまうのは、基本的には厳禁であることを開発メンバーに徹底する。
�Bその上で顧客の要求仕様とシステムコンセプト、およびコストとスケジュールの許す範囲で、開発者の技術的関心へのニーズを満たすための道を探る。

【解説】
仕様の膨張は顧客のリクエストからだけ発生するわけではありません。開発側自ら仕様を膨張させることもあります。例えば技術者には常に、新しい技術や注目を浴びている技術に接していたいという本能的なニーズがあります。そしてこのような技術への欲求が往々にして仕様の膨張につながるのです。これまで「顧客志向」という理由を隠れ蓑にして、本来は不要であるはずの機能が追加され、不要であるはずの技術が実験的に使用されてきました。その結果多くのプロジェクトが危機に陥ってきました。もっとも、技術者の技術への欲求は本能と呼ぶべきものなので、これは否定することは困難です。重要なことは、このような技術者の性向を十分に承知した上でプロジェクトを運営していくことです。プロジェクトを守るために抑えるべきところは抑え、技術者のモチベーション維持のために緩めるべきところは緩めるといった、意識的な制御が必要です。ただし開発メンバーによる無秩序な趣味的、自己満足的な技術の適用には十分注意しなければなりません。

２．顧客組織の問題

【原因】
・ちょっとした要求の追加であればプロジェクトにはほとんど影響はないだろうと思っている。
・要求の追加に当たって、そもそもプロジェクトへの影響や、必要なリソースという考え自体を持っていない。
・「あればよい機能」でも「あれば便利な機能」でも、何でもかんでも要求しなければ損だと思っている。
・顧客の頭の中に、「要求」と「開発に必要なリソース」を結びつける観点が欠如している。

【予防策】
�@使用可能なリソースに変化がない以上、要求が増えれば一つの要求に費やすことができるリソースの量は少なくなることを顧客に説明する。
�A使用可能なリソースに変化がない以上、「あればよい機能」が増えれば「重要な機能」の開発に費やすことができるリソースの量は少なくなることを顧客に説明する。
�B要求が次々に膨張していくと、リソース不足のため、プロジェクトのリスクはそれだけ高まることを説明する。
�C「あればよい機能」や「あれば便利な機能」程度の要求は、削除あるいは次期開発にまわすことを提案する。

【解説】
同じ金額であればできるだけ多くの「モノ」が欲しいと思うのは人情です。しかしちょっとした要求ばかりでも、際限のない機能の拡張はトランプのブラックジャックのようなものです。もう少し、もう少しと積んでいくとある時突然ゼロになってしまうのです。「もう少し」と欲張った機能のために、本当に重要な機能までをも失ってしまう羽目になるのです。顧客には、予算一杯までギリギリに要求を詰め込もうとするのは「危険な賭け」であることを説明しなければなりません。余裕を持った見積でさえちょっとしたことで超えてしまうのがシステム開発なのです。

• 「あればいい」機能を開発するだけの余裕はないものと考えること。
  これまで開発してきたシステムを振り返ってみてください。あってもなくてもいいような機能がついている一方で、最も重要であるはずの機能が機能不足や使い勝手でユーザの不評を買っていることはないでしょうか。あってもなくてもいいような機能を一切開発せずに、最も重要な機能にリソースを注ぎ込んでいれば、システムが生み出す価値はもっと高いものになっていたことでしょう。重要な機能は単に「重要な機能」とラベル付けしただけでは重要であることの意味はありません。リソースの配分という具体的な行動を通じて、実際にその重要性を示さなければなりません。

３．業務のASISの問題

【原因】
・現行でも明確なルールがない業務をシステム化しようとしている。
・現行の業務のルールを詳細まで洗い出せていない。
・開発しようとしているシステムが、そもそもシステム化が難しい業務を対象にしている。

【予防策】
�@システム化の対象と考えている業務の目的と、そこで求められる作業、あるいは作業成果物を明らかにする。
�A過去、どのような属人的な判断、臨機応変な判断で業務が進められてきたかを調査する。
�B過去、どのような例外事項が発生し、都度どのような対応が取られてきたのかを調査する。
�Cシステム化が難しい部分については、無理をせずにきっぱりとシステム化をあきらめる、あるいは延期することを顧客に提案する。

【解説】
コンピュータが得意とするのは単純繰り返し作業です。そして苦手とするのは例外処理や臨機応変な対応です。システム化を考える場合は、このコンピュータの基本的な特性を押えておくことが重要です。システムの目的にもよりますが、場合によっては詳細かつ複雑で難解なマトリックス表や分岐図と格闘するよりも、その業務のシステム化の範囲を縮小することが最適解であったりするのです。現在ではコンピュータの利用目的は、その「不得意分野」への進出が目立ってきていますが、あくまでコンピュータの特性を忘れずにいることが重要です。

４．業務のTOBEの問題

【原因】
・システムのあるべき姿が明確に固まっていない。
・開発しようとしているシステムが、そもそも事前に仕様を決定することが難しい性格を持っている。

【予防策】
�@システムが持つそもそもの性質として、「膨張しやすい」システムなのか「膨張を制御しやすい」システムなのかを見極める。
◇膨張しやすいシステムの例
・新たなサービス創造のためのシステム
・情報活用支援のためのシステム
・業界の変化に対応するためのシステム
◇膨張を制御しやすいシステムの例
・業務効率化、省力化のためのシステム
・業務プロセスの標準化のためのシステム
�A「膨張しやすい」システムすなわちスコープを明確に定めることが難しいシステムの場合、その旨を顧客に説明しておく。
�B「膨張しやすい」システムの場合は、要求フェーズの期間を厳格に区切ることで「スコープ確定」とする。また、この件については、（開発条件等で）事前に顧客の了承を取りつけておく。または交渉しておく。

【予防策２】
�@インクリメンタルな開発プロセスを採用する。

【解説】
システムには仕様膨張につながりやすいシステムと、仕様膨張を抑えやすいシステムが存在します。合理化、省力化のためのシステムは一般に目的や費用対効果を明確にしやすく、仕様の曖昧さも少ないものです。一方、能力開発システムや付加価値創造システムはシステムと目的との因果関係が不明確な場合が多く、要求仕様も曖昧になりがちです。費用対効果がわかりにくく、後々の仕様変更も多くなり、目的に対応する要求仕様の切り分け、境界線も曖昧になりがちです。こうしたシステムの場合は、要求フェーズの期間を明確に区切り、その期間を過ぎて発生した要求については（別プロジェクトでも次のインクリメントでもよいので）明確に今回の開発とは切り離すことが重要です。ズルズルと中途半端に対応しながら進めるは危険です。（※もっとも、開発の効率性を考えて今回の開発に取り込んでしまった方がよい場合もありますが、そこはプロジェクトの個別判断となります）
また、このような先が見えにくいシステムを開発する場合は、インクリメンタルな開発プロセスが適しています。メリットがあればデメリットがあるのは当然で、このプロセスを採用すると１機能あたりのコストは高くなります。ただし先が見えにくいシステムとはそもそもが「手探り」プロジェクトであり、確定した仕様を効率的に開発していくプロジェクトではないので、そこは顧客にも納得してもらうように説明しなければなりません。

【原因】
・システムの目的が明確に絞られていない。

【予防策】
（主要な問題その３「要求の誤解と的外れの理解」参照）

５．要求定義のアクションの問題

【原因】
・要求を選択する仕組みがない、あるいは要求に優先順位をつけていない、あるいは優先順位という考え方がない。
・要求に優先順位が存在していても、開発にその優先順位を反映させる仕組みが存在しない。

【予防策】
�@開発に「優先順位」の考え方を導入することのメリットを顧客に説明する。
◇要求に優先順位をつけることの顧客側のメリットの例
・重要な機能から先に完成することになる。
・後で不要になるかもしれない機能を開発することの無駄を排することができる。
・開発に集中することができ、品質や生産性が向上する。
�A要求の優先順位を曖昧にすることのデメリットを説明すること。
◇要求の優先順位を曖昧にすることのデメリットの例
・要求に優先順位をつけないということは、プログラマにその決定をさせるということになる。
・要求に優先順位をつけないということは、「全ての重要度が高い」ことであると同時に「全ての重要度が低い」ことでもある。それぞれの機能の「重要性」の意識が薄れる原因になる。
�B開発に「優先順位」の考え方を導入するよう提案する。

【解説】
確保可能なリソースから考えて10機能にしか対応できない状況に対して、顧客の要求が12機能にまで膨れ上がってしまった場合、開発側はどのように対応すべきでしょうか。僥倖を期待して、あるいは何も考えずに12機能の完成を目指して遮二無二頑張るのも一つの手ではありますが、その結果は多くの方は経験済みでご承知のことと思います。しかもそのようなシステムに限って、運用が始まってみると実際に使われているのは一部の機能だけだったりするのです。実際、システムに盛り込まれた機能が全て有効に活用されているという例は極めて少ないのが現状です。一度も使われたことがない機能や滅多に使われることのない機能というものは少なからず存在しているものです。
ではなぜ、使われない機能まで作ろうとするのでしょうか。要求定義の不備もその大きな原因の一つですが、そればかりではありません。ここには顧客の心理的な要因も絡んできます。まず、顧客の中で「同じ金額を支払うならできるだけたくさんの機能が欲しい」という意識が働いている場合があります。完成品の工業製品を購入するのであればこの考え方は有効ですが、ソフトウェアの開発にはもちろん当てはまりません。機能を増やせば増やすほど品質は低下していくでしょう。このあたりの力学は、開発側が積極的にシステム開発の実際について説明し、顧客の誤解を解いていかなければなりません。
しかし中にはプロジェクトに及ぼすリスクを理解した上でも、機能の追加を求めてくる顧客もいます。通常、追加要求という形で後から機能を追加すると、別途新たなコストが発生してしまいますが、このリスクを避けるため、「必要になるかもしれない」程度の機能であっても「念のため」を考えて最初から要求に含めてしまうのです。しかし当然ながら、この「本当に必要かどうかわからない」程度の機能のために、「本当に必要な」機能を開発するためのリソースが圧迫されてしまうことになります。
しかしそれは顧客にとっても本心から望んでいることではないでしょう。このような事態を防ぐためには、まずは機能の重要度を明確にし、「本当に必要な」機能には、最初に必要なだけのリソースを割り当ててしまうことです。その結果、「必要かもしれない」程度の機能に対しては、「間に合うかもしれない」程度のリソースしか割り当てることができなくなるかもしれませんが、それは仕方ありません。そうでなければ「本当に必要な」機能にさえ十分なリソースを割り当てることができなくなってしまうのですから。
もちろん、これらの「リソース配分の論理」は開発側の判断だけで行うべきものではなく、事前に顧客の同意を得ておく必要があります。「必要かもしれない」機能の開発は、リソース不足によって機能が縮小されたり中止されたりする可能性について、あらかじめきちんと説明しておかなければなりません。

• 優先順位を決定する際の重要性の基準を明確にすること。
  基準はシステムの目的に合致したものでなければなりません。
  ◇優先順位を決定する際の基準の例
  ・現行のビジネス価値が最も高いのはどの機能か。
  ・将来のビジネス価値に貢献する可能性が高いのはどの機能か。
  ・費用対効果が最も高いのはどの機能か。
  ・開発リスクが最も高い（低い）のはどの機能か。
  ・開発効果がないリスクが最も高い（低い）のはどの機能か。
  ・開発コスト削減に最も効果があるのはどの機能の削減か。

※優先順位は「機能の重要性」×「機能の緊急性」で測られるのが一般的です。

• ゼロベース予算方式の考え方で要求（機能）を制限することについて、顧客の理解を得ること。
  優先順位を明確にする目的は、システム開発にゼロベース予算方式の考え方を持ち込みたい、という考えがあってのものです。しかし見積と実態がかけ離れてしまうのがシステム開発の常です。事前に決めた足切りラインが正しいものかどうかは、実際にやってみなければわかりません。システムの目的や顧客のビジネスを考慮して、「最低保証ライン」「目標ライン」などを設けるのも一つの手です。

  ※ゼロベース予算方式
  �@前年の実績などに関係なく、ゼロから新規に予算を設定する。
  �A作業（機能）の優先順位を決定する。
  �Bその順位に従って予算枠で足切りを行う。
  �C足切りされなかった作業（機能）だけを計画に組み込む。

• 要求の優先順位を明確にし、無用なプレッシャーから現場を解放すること。
  適度なプレッシャーは生産性の向上に多少は貢献するというデータもありますが、現実にはそれが「適度」に収まることは滅多にありません。しかし限度を超えたプレッシャーは往々にして品質の低下、それに伴う生産性の低下、それに伴うモチベーションの低下などの悪影響を連鎖的に引き起こすことになります。ここで優先順位を明確にすることにより、仕様が膨張しても「全てを取り込まなければならない」というプレッシャーから解放されることになります。ただしこの「解放」は、メンバーの意識レベルによっては単なるダラダラ作業を引き起こす可能性もあることを忘れてはいけません。

• どのステークホルダーの要求を優先するのかを明確にすること。
  ステークホルダーによってシステムへの関心の視点は異なっています。どのステークホルダーの視点でシステムを考えるのかを、あらかじめ決めておかなければなりません。
  ◇それぞれのステークホルダーの視点の例
  経営陣
  ・少ない予算で完了する。
  ・短い開発期間で完了する。
  プロジェクトマネジャー
  ・予算内で完了する。
  ・期間内で完了する。
  ・品質が許容範囲内である。
  開発者
  ・新技術が身につく。
  ・技術的な挑戦ができる。
  ・「常識的」な作業時間である。
  エンドユーザ
  ・機能が多い。
  ・使い勝手がよい。
  ・統一感が取れており「驚くような」ことがない。
  ・サクサク動作する。
  ・バグがない。
  保守要員
  ・信頼性のあるドキュメントが揃っている。
  ・バグがない。
  ・バグの修正が容易である。

【原因】
・信頼関係が醸成されておらず、顧客が「優先順位」の重要性を理解していてもその適用を拒否する。

【予防策】
�@インクリメンタルな開発、段階的な納入方式を提案する。
�Aインクリメンタルな開発、段階的な納入で開発を進める。
�B日々の作業を通して顧客の信頼を勝ち取る。
�C残りの開発分について、「優先順位」の考え方を導入するよう提案する。

【解説】
「優先順位」の考え方は合理的であり、顧客も簡単に納得してくれそうなものですが、現実はそれほど甘くありません。事実、「優先順位」の考え方を導入すると、「何が何でも開発しなければならない」というプレッシャーから現場のメンバーを解放することにつながります。成熟度の低いチームではそれが作業の怠慢に発展することも考えられないことではありません。「最後の機能はできなければできなくてもいいや」というような怠惰な空気が醸成される危険性があるのです。これは顧客の最も懸念することの一つです。優先順位を設定した上で「できるところまでやります」と口ばかりに宣言して、実際はのんびりした仕事をされたのでは顧客はたまったものではありません。開発チームにはより以上の高い意識を持って作業をすることが求められます。これができずに優先順位ばかりを取り出していては、顧客からの信頼は回復不可能なまでに低下してしまうでしょう。

【原因】
・要求の正しさや要求の妥当性をチェックする仕組みがない。
・追加変更要求が発生した場合の対応方法や要求管理のルールが事前に明確に決められていない。

【予防策】
�@追加変更要求が発生した場合の（標準的な）変更管理プロセスを作成する。（☆「追加変更要求の発生」−「治療のためのヒント」参照）
�A変更管理プロセスの例外プロセスを検討する。
�B変更管理プロセスをプロジェクトの特性に合わせて改変する。

【解説】
追加変更要求に対する変更管理プロセスを明確に定めている組織はまだまだ多くはありません。まずはプロセスを定めるところから始めなければなりません。もっとも現実の話では、プロセスを定めてはいてもそれをマニュアル通りに運用している組織は少数派でしょう。なぜならプロセスの多くは固定的で融通が利かず、現実のプロジェクトの実情に合わないからです。標準的なプロセスを定めた後は、プロジェクトに合わせてカスタマイズしていく必要があります。プロセスを定める際には、くれぐれも「どのプロジェクトにも通用する」ようなものを作ろうと頑張ってはいけません。無意味な一般化か無駄な精緻化に陥るのが関の山です。

【原因】
・要求管理のルールを定めていても、それを実行できていない。
・要求管理のルールが定められているだけで、簡単に破られる。

【予防策】
�@変更管理プロセスの顧客にとってのメリットを説明する。
◇変更管理プロセスの顧客にとってのメリットの例
・プロセスを経ることによってシステムの統一性や一貫性が保持される。
・プロセスを経ることによって無駄なリソース消費が抑えられる。
・プロセスを経ることによって管理されない要求の混入を防止し、品質低下のリスクが低減する。
・都度、仕様膨張のリスクを検討することによって、プロジェクト崩壊のリスクを低減することができる。
�A要求定義フェーズを終了してから発生した要求には、変更管理プロセスとその例外プロセスが適用されることについて、顧客の了承を得る。

【解説】
ルールというものは実行されてはじめて価値が生ずるものです。そしてルールというものは、参加する全員がそれに従うことによってはじめて価値が生じます。そもそもルールというものは実行可能性を考えて策定されるべきですが、ルールが実行できなかったり簡単に破られたりするのであれば、まずは実行に向けての働きかけが必要です。それが無理であることが最初からわかっているのであれば、現実的な落としどころを考えなければなりません。理想論や「あるべき論」は唱えずに、現実的に「目的が達成できる」案を考えるべきです。

【原因】
・「追加変更要求」の定義が曖昧で、要求管理のルールに乗せる以前の要求の切り分けが困難である。

【予防策】
�@「追加変更要求」の定義を（可能な限り）明確にする。
◇「追加変更要求」の定義の例
・要求仕様書に記述されていない要求は追加変更要求である。
・一定期間を過ぎて発生した要求は追加変更要求である。
�A「追加変更要求」の定義について、顧客の合意を取りつけておく。または顧客と共通認識を図っておく。

【解説】
変更管理のルールが定められていても、それが適用できるか否かの判断ができないのであれば、そのルールは存在しないのと同じです。ルールを作ったら、そのルールがいかなる場合に適用されるのかを、できるだけ明確かつ具体的にしておく必要があります。

【原因】
・要求の出所が一元化されていない。

【予防策】
�@要求の出所を一元化することのメリットを顧客に説明する。
◇要求の出所を一元化することのメリットの例
・無秩序な要求の発生が抑えられ、システムのコンセプトや統一性を維持しやすくなる。
・無秩序な要求の発生が抑えられ、品質低下のリスクが低減する。
・無秩序な要求の発生が抑えられ、スケジュール延長やコスト超過のリスクが低減する。
・要求の管理洩れがなくなり、設計洩れや試験洩れのリスクが低減する。
・要求の管理洩れがなくなり、要求の追跡性や保守性が向上する。
・顧客の要求定義への意識が向上する。（いつでもやってくれと言えばやってもらえるという感覚がなくなる）
�A顧客と相談の上、要求の出所を一元化する。

【解説】
要求の出所が明確に一元化されていない場合、時と場所を選ばず様々なステークホルダーから様々な要求が飛んでくるようになります。これは仕様の膨張につながるだけでなく、管理洩れによる種々のトラブルの発生、システムのコンセプトや全体の統一性を壊す原因にもなります。貴重なマネジャーや担当者の時間も非効率的に費やされてしまうことになります。個々のユーザへのインタビューなど、開発側から積極的に要求を獲得していく場合はもちろん別ですが、基本ルールとしては、顧客からの要求は（要求定義の定例会議などに）一元化してもらうことです。

【原因】
・顧客が開発メンバーに直接要求を依頼している。

【予防策】
�@正式なルートを通さない要求は（基本的には）受けつけない旨を、顧客側に説明する。
�A正式なルートを通さない要求は受領しないように、開発メンバーに徹底する。

【解説】
追加変更要求を、顧客が正式なルート（要求の入り口）を通さないで直接開発メンバーに依頼することがありますが、これはご法度です。「１分で対応できる」ような些細な要求でも、正式なルートを通してもらうように顧客にお願いしなければなりませんし、メンバーにも勝手に要求を引き受けないように徹底しておかなければなりません。要求が管理できずに、後々の問題発生の種を残すことになります。

【原因】
・一旦膨らんだ顧客の要求を削減する仕組みがない。

【予防策】
�@顧客が納得するような「要求削減の条件」「機能削減の条件」を検討する。
◇要求削減・機能削減の条件の例
・明らかにシステムの目的との関係性が薄い場合。
・明らかに便利機能でしかない場合。
・明らかに特定の個人にしか役に立たない機能である場合。
・当該機能の重要性が低く、かつ他の重要な機能の開発を圧迫することが明らかである場合。
・機能を削減しなければプロジェクト自体の崩壊が予見される場合。
�A「要求削減の条件」「機能削減の条件」について顧客と相談する。
※上記条件は判断の基準が難しいですが、少なくとも事前に（要求削減をお願いしなければならなくなる前に）顧客と折衝して了解を得ておくことです。
�B可能であれば契約に上記条件を項目として盛り込む。

【解説】
要求仕様書や設計書に既に記述されてしまったという理由だけからで、実際は重要性の低い機能の開発が続けられてしまうことがあります。誰もが不要と知っている機能を、「一旦決まった機能だから」「一旦約束された機能だから」と強引に開発を進めるのは明らかに間違っています。政治的な動きを好まない、あるいは潔しとしないマネジャーもいますが、最も重要なものは「製品そのもの」ではなく「顧客の満足」ということを忘れてはいけません。

【原因】
・要求定義の作業で開発側が「聞くべきこと」と「裁量で判断すべきこと」の切り分けができていない。

【予防策】
�@システムの目的、システムのコンセプトを明確に理解する。
�A要求を固めていく過程において、顧客に逐一確認して進めていくべき点と、開発側の裁量で進めていくべき点とを、明確に切り分けを行う。
�B裁量で進めるべき点については顧客に不要な確認はせず、要求定義の作業を進めていく。

【解説】
聞かなくてもよいことまで顧客に逐一聞いて確認を取ることは、不必要な要求肥大の原因であり、要求定義の非効率化の原因です。例えばシステムによっては、ボタンの大きさなどは「どうでもよいこと」であり、常識的に判断すべきものです。そのようなシステムではボタンの大きさは開発者の裁量、開発側の標準に任せておくべきです（※もちろんボタンの大きさが重要なシステムもあります）。何を聞き、何を聞くべきでないかの切り分けができていないと、防御的になり、何でも顧客に確認を取ることになります。顧客は聞かれればもちろん、自分達の希望と考えを答えることでしょう。確認するステークホルダーがが異なれば、それぞれ違った意見が出てくるでしょう。かくして要求は詳細化し、「重箱の隅」化し、膨張していくのです。

• 本質とは無関係な細部の仕様は、（とりあえずでも）開発側の裁量に一任してもらうこと。
  システムの目的とは無関係な箇所、取るに足らない細部の仕様で、要求仕様の確定に手間取ることがあります。これは時間の無駄以外の何ものでもありません。そしてそれらの詳細な仕様を（コード一行単位で）ドキュメントに落とすことも、少なくとも一般のビジネスシステムの開発においては費用対効果に見合うものではないでしょう。過剰に開発者の裁量範囲を制限すると、システムは非常にコストの高いものになってしまいます。しかもそのために得られるものは多くはありません。

治療のためのヒント

１．まず対応に向けて検討すること

仕様の膨張とは基本的にサービスで、すなわち無償で対応しなければならない顧客の要求のことを意味しています。もちろん追加費用の交渉が可能な「正式な追加要求」でも仕様は膨張しますが、この項では顧客から正式な追加変更とは認めてもらえない要求に目を向けています。つまり、当初予定の費用もスケジュールも変更することなく、対応しなければならない要求ということです。

約束されていなかった仕様の膨張、想定していなかった仕様の膨張でも、それは必ずしもプロジェクトのスケジュールやリソース計画に影響を与えるものではないかもしれません。そもそもの見積や計画が100％正しいとは限らないのです。まずは仕様に取り込むことを前提に、膨張した仕様への対応を考えてみるべきでしょう。

• 対応に向けての心構え

• まずは開発側内部の「やりくり」だけで対応可能かどうかを検討してみること。
  仕様の膨張に対しての選択肢は最後には「やるか」「やらないか」しかありません。しかし、ほとんどの現場では「やらない」選択肢を選ぶのは非常に難しいのではないかと思います。「やらない」ためには顧客を納得させるだけのロジックが必要です。しかもそのロジックは顧客のロジック、つまり「それがなければ業務がまわらない」という強力な意見に勝たなければならないのです。まずは「やる」方向で考えていかざるを得ないのが、多くのプロジェクトの現状でしょう。

• 銀の弾丸を求めないこと。
  無秩序な仕様の膨張によってプロジェクトが制御不能に陥りそうな時、納期・費用・品質いずれにも影響を及ぼすことなく事態を収拾する方法があればどれほどよいことでしょう。それを本気で望むのは、いわゆる「銀の弾丸」症候群です。熱望するあまりその存在を「確信」し、存在しない「錬金術」を血眼になって探すようなパニックに陥ってはいけません。まずは現実を直視し、合理的な問題の解決を目指すべきです。

• まずは「計画に誤りを見出す」という考え方をすること。
  仕様が膨張してプロジェクトが危機に陥っているならば、膨張した仕様の削減を考えるのが常道です。しかし全ての仕様がシステムの目的と整合性が取れており、しかも全ての仕様がシステムの目的のためには必須のものである場合、仕様の削減を顧客に納得させるのは困難です。トレードオフの原則からすると、必然的に納期・費用・品質のいずれかに手をつけなければ膨張した仕様に対応することはできません。あるいは自社が赤字を覚悟して、仕様も納期も費用も品質も満足させることです。一見正しいように見えるこの論理は、幸いにも机上の論理でもあります。当初の計画に誤差や誤りがないと仮定した場合の話です。他の何物にも手をつけずに膨張した仕様に対応するためには、計画に誤りがあればよいのです。否、計画に誤りを見出さなければならないのです。

• 唯一の可能性は生産性の向上だが、そこに「無理」はきかない。
  この期に及んで使用したこともないような方法論に助けを求めてはいけません。断言します。それは現場にオーバーヘッドを課すだけで、却って逆効果となるでしょう。外部条件に変化がないままでアウトプットを増やすための唯一の方法は生産性を上げることです。しかし労働集約的なシステム開発の作業で生産性を向上すること自体、そもそも非常に困難なことです。顧客の要求を呑むのであれば、あえてその現実を踏まえた上で生産性向上の可能性を探っていかなければならないのです。30年前に比べてコンピュータの性能（生産性）は何倍になったでしょうか。その間、農業の生産性は何倍になったでしょうか。この生産性の伸びの差はどこにあるのでしょうか。問題は根源的です。逆らうことができない「自然の法則」がそこには存在します。外部条件に変化がない以上、追加仕様に対応する唯一の方法は生産性を上げることだけですが、検討に当たってはこの「自然の法則」を無視した無理な計画を立ててはいけません。

• 個々の生産性の向上は必ずしも全体としての生産性向上にはつながらない。
  全てのメンバーに常に全速力で走る事を命じても、必ずしも全体としての作業の進捗がはかどるとは限りません。生産性を論じる場合、常に全体としての生産性を念頭においておく必要があります。例えばＣが作業をするためにはＡとＢの成果物を必要とする場合、Ａだけが急いで完成させてもＢが終わらなければＣの作業を始めることはできないのです。このときの「待ち時間」を別の作業のために使用することもできる、という主張も確かにあるでしょう。しかし人間を、しかも知的作業に関わる人間を全速力で走らせておいて、少し時間が空いたら全く別の作業でまた全速力で走らせるというやり方が果たしてどこまで通用するでしょうか。本人に高いモチベーションや一種の使命感のようなものがあれば話は別ですが、一般的にこのような管理は「やっつけ仕事」を生み、プロジェクトを更なる窮地に追い込むものです。

• 精神論

• リーダーは自らプロジェクトに全力投球しているか。
  リソースに余裕がない中で膨張した仕様に対応するためには、メンバーの献身的な協力が不可欠です。リーダー自身が漫然と作業をしている中でメンバーが全力投球などするはずがありません。仕事をしているフリはすぐに見破られます。徹夜でごまかそうとしても駄目です。もし、これまでの自身の姿勢に問題があったと思われるならば、（パーソナリティにもよりますが）自戒の言葉とこれからの姿勢をメンバーに伝えるのも一つの手かもしれません。急にバタバタと行動し始めても「所詮火がついたから焦っているだけ」と思われては何の効果もありません。（※厳しい言い方ですが、すでにリーダーが「そういう見方」でメンバーに見られている場合、その見方を変えるのは至難の業です。「重要」なプロジェクトならば、デスマーチに陥る前にリーダー交代の選択肢についても考えるべきです。）

• メンバーはプロジェクトに全力投球しているか。
  余程目に余るようなものでない限り、タバコや無駄話、休憩の時間を無闇に禁止したり制限したりする必要はありません。そのような対策はむしろメンバーの士気も生産性も暗黙知を醸成するコミュニケーションも低下させるようなものです。リフレッシュしているのか、本当にさぼっているのか、明確な判断基準を客観的な指標で示すことはできませんが、両者の違いくらいは（余程パニックに陥って盲目になっていない限り）わかることでしょう。

• チーム内コミュニケーションを促進する、あるいは妨げない仕組みを設けているか。
  生産性は周りのメンバーとの協力関係や信頼関係が築かれているときに向上するものです。周りのメンバーと一体感を持って仕事に取り組んでいるときに向上するものです。生産性に影響を与えるのは個々の能力ばかりではありません。例えばおかしな管理ルールをメンバーに押しつけて、その自由なコミュニケーションを妨げるようなことがあってはいけません。

• リーダーはメンバーのためにリスクを冒す覚悟はあるか。
  チームの「盛り上がり」は生産性向上にしばしば不可欠な要素ですが、そのために必要ならば職場ルールでもリーダーの全責任で「破ってしまう」くらいの覚悟がなければなりません。机での飲食は禁止されているかもしれません。ヘッドホンをつけながらの作業は禁止されているかもしれません。しかしそれで生産性の向上が認められるならば、リーダーの責任で許可することも考えなければなりません（※もちろん、隔離された部屋など、他のチームに悪影響を与えない環境に限られますが）。リーダーには、士気を高めるためには必要なことは何でもするくらいの心構えが必要なのです。

• 外圧ではなく、メンバーの「内なるモチベーション」を重視しているか。
  生産性に全く目標値を設定しないケースと、自ら目標値を設定させたケースと、目標値を上から押しつけたケースとを比較した場合、どのケースが最も高い生産性をあげることができるでしょうか。実は、全く目標値を設定しないケースの生産性が他の場合に比べて最も優れた結果を出したとの研究報告があります。要するに知的労働作業は、緻密な管理をしたからといって計画通りに進むものではないのです。「生産性の評価」や「残業規制」や「管理者や顧客からのプレッシャー」など、気にしなければならないものが何もないときに向上するものです。知的労働者の生産性は、外からのプレッシャーではなく内なるモチベーションに基づいて作業を行うときに、最も高くなるものなのです。

• メンバーの作業のサポート

• メンバーが担当している作業に、リーダー自らサポートしたり手伝ったりできる作業はないか。
  自ら設計やコーディングに携わることができないならば、リーダーは極力メンバーのサポート役にまわるべきです。（極論でも何でもなく）コピー屋でもドキュメント係でも何でもよいのですが、とにかく便利屋に徹することです。メンバーの時間は全て、最終成果物に直接貢献するような作業にのみ有効に活用されるようにすべきです。表面上のプライドは多少痛むかもしれませんが、プロジェクトへの執着がプライドを上回るならば、すぐにでもそうすべきでしょう。

• リーダーが何をすべきかをリーダーはわかっているか。
  生産性を向上させる方法を一番よくわかっているのはメンバー自身です。メンバーの生産性向上策について、本来はリーダーがあれこれ考えるべきことではありません。まずはメンバー自身に生産性を向上させる方法を直接聞いてみることです。何が生産性の向上を阻んでいるのか、何が余計なオーバーヘッドになっているのかを聞いてみることです。タスクへの担当者のアサインや作業順序等、マネジメント面が生産性に与えている影響を聞いてみることです。個人の生産性を最大にする方法とともにチームとしての生産性を最大にする方法も聞いてみることです。もちろん、メンバーの意見やアイデアをそのまま実行しなければならないわけではありませんが、中には「目から鱗」の意見もあるはずです。

• メンバーの提案策を安易に却下していないか。
  生産性向上策を最もよく知っているのは現場のメンバーです。生産性向上策についてマネジャーが悩むのは間違っています。その方法を開発者に教えてあげる必要はありません。マネジャーの教える方法が得てして間違っているのです。ところが多くの場合、折角あげられた現場の意見でも（ほとんど何も考えずに）実現性が低いものとして却下されてしまいます。その上で悩んでいるのですが、悩むのは当然です。最も有効かもしれない策を却下してしまったのですから。メンバーの提案策はマイナス点だけがたいそうに取り上げられ、そのメリットが検討される前に却下されがちですが、このような態度は自らの首を絞めているようなものです。

• 「生産性を向上させよ」と指示することの無意味さを理解しているか。
  指示されたからといって突然、才能が開花したり能力が向上するわけではありません。「生産性を向上させよ」という言葉だけで生産性が向上する見込みはほとんどありません。そのような無意味な言葉を発し続けてメンバーからの信頼を失う前に、生産性が向上するような環境を準備することに頭を悩ませるべきです。また、生産性の向上を指示するのであれば、そのやり方を示さなければなりません。やり方を示すことができないならば、少なくともメンバーから生産性向上の方法を聞くべきでしょう。

• 無駄なペーパーワークの削減

• ペーパーワークに埋まってしまわないように気をつけること。
  システム開発では管理者だけではなく、現場の開発者にも多くのペーパーワークが求められるものです。システム開発と言いつつも、そのほとんどの作業がペーパーワークで占められているＳＥはざらにいます。ペーパーワークは設計書ばかりではありません。管理者がその上司あるいは顧客に説明するためのペーパーワークや承認を得るためのペーパーワーク、変更管理や進捗管理など無数の管理のためのペーパーワーク、報告や確認のためのペーパーワーク。それらは納品物である場合もあるし、そうでない場合もあります。何も考えずに受身で作業をしていると、システム開発の作業は非常に多くのペーパーワークで埋まってしまうことになります。

• ペーパーワークにかかるコストを意識すること。
  重量級の方法論に準拠した大規模プロジェクトでは、しばしばペーパーワークのコストが全コストの50%を超えることになります。そこまで「大袈裟な」例を挙げずとも、通常のプロジェクトでもペーパーワークのコストはコーディングのコストを十分に上回っているものです。

• ペーパーワークの修正管理の難しさを理解すること。
  ペーパーワークの修正管理は、厳格に行うことが困難であると同時に、なにより非常に面倒です。機械的な単純労働作業はメンバーを疲弊させてしまいます。「なぜ、こんな無意味な作業をしているのか」とメンバーに疑問を抱かせることによって、プロジェクトの士気も徐々に低下していくことになります。

• ペーパーワークの修正管理の無駄を省くこと。
  最初からきちんとした設計書を書くこと、書こうとすることは無駄につながります。例えば最初に１００時間かけて完成させた設計書ならば、おそらく開発を進めていく中で、あと５０時間はメンテナンスのための時間が必要になるでしょう。最初からきちんとした設計書を書くことは大きな無駄につながります。設計書の作成が顧客との重要な契約事項である場合を除いて、一般のプロジェクトであれば設計書はコーディングが完了した時点で保守用に作成するくらいの気持ちで丁度良いのではないかと思います。

• ドキュメントの作成は可能な限り遅く、そして少なくすること。
  ペーパーワークによって実装が遅れるならば、そして「きちんとした」ドキュメントがなくても実装が可能ならば、ペーパーワークは極力実装後にすべきです。「言った、言わない」の解決はノートの隅に書かれたメモでも十分です。「動かないもの」「最終成果物ではないもの」「無駄になるかもしれないもの」に早々から貴重なリソースを費やすべきではありません。リソースはまずは、「動く製品」に最も多く割り当てられるべきです。

• ドキュメントの作成に貴重な開発者の時間を使うことには極力慎重になること。
  ドキュメントを作成するために、本当にその開発者の技術を要するもの以外は、管理者またはサポート要員が作成すべきです。「替えのきかない」技術者の貴重な時間を、誰でもできる作業のために奪ってはいけません。

• 最終成果物に直接貢献しない中間成果物を作成しないこと。
  プロジェクトで最も重要な成果物とは何でしょうか。顧客にとってどの成果物には価値があり、どの成果物には価値がないのでしょうか。最終目的だけを見据えるならば、そこに至るまでの中間成果物が少なければ少ないほど生産性は高まります。中間成果物の作成が契約にあるならば仕方ありません。しかしそれがあくまで「開発側が決めた」手段であり、最終目的ではないのならば、そのために費やす労力を最小限にする方法を考えるべきです。例えば最終成果物に直接結びつかない「保守のため」のドキュメントを作成するならば、その作成をプロジェクトの（二次的な）目的に最初から入れておくべきです。開発側が「常識」で勝手に判断して、そのためにリソースを費やすべきではありません。例えば設計書を作成するのであれば、その精度やフォーマットへの準拠の必要性を顧客に確認すべきです。そのために必要となるコストや時間を説明し、顧客に判断してもらうことです。開発側自ら、最終成果物に費やすことのできるリソースを減らすような行動を取ってはいけません。最終成果物を作成するために中間成果物は必要です。しかし手段としての中間成果物ならば、手段として役に立つ必要最小限のレベルに抑えるべきです。全ての（中間）成果物は、その成果物の利用目的から見て有用であれば、それが不完全に見えるものであっても問題はありません。目的に対して役に立つか立たないかだけが判断基準です。中間成果物の出来にこだわるべきではありません。

• 成果物は利用目的を考えて作成すること。
  作業の心構え、作業成果物の心構えは「目的のために必要最小限のものを」です。作業の際には、常にその作業の成果物の利用目的を考えるべきです。そしてその目的を達成できる必要最小限のものを必要最小限の完成度で作るべきです。余計なリソースを注ぎ込むべきではありません。貴重なリソースを費やして作成された成果物も、目的からはみ出した過剰な部分は全て、目的の達成を阻むものとして考えることです。本来、目的のために投入可能であったはずのリソースが削減されてしまうのです。

• オーバーヘッドの削減

• メンバーの作業に無駄なオーバーヘッドはないか。
  生産性向上を阻む大きな原因に様々な作業のオーバーヘッドが挙げられます。何をオーバーヘッドと見なすかはプロジェクトによってその認識は違ってきますが、基本的には「製品に価値を付与しない作業」「顧客に価値を生み出さない作業」は全てオーバーヘッドと見なすべきです。
  ◇オーバーヘッドと見なすものの例
  • 各種割り込み作業
  • 各種兼任作業
  • 担当者にとっては5分間分の価値しかない2時間の会議上司への詳細な報告書（・・・これは直接製品に価値を付与することはない）
  • 設計やプロトタイプの作成（これが最終的な製品に価値を付加しないならば無駄である）
  • コミュニケーションのための場所の移動や連絡のための時間、コミュニケーションの伝達ミス
  • 価値を付加しない規則遵守作業
  • 引継ぎ時間
  • 引き継がれない暗黙知
  • 引き継がれない暗黙知を獲得するために要した時間等

• メンバーを割り込み作業や兼任作業から守っているか。
  割り込みはその「大きさ」だけが問題なのではありません。わずかでも作業を中断させる事が問題なのです。マネジャーは得てして小さな割り込みを小さなものとして考えます。例えば「今週の作業時間の報告」などは、ものの５分もあれば十分だと思っているのです。確かにそのために実際に手を動かす時間はわずか５分かもしれませんが、その５分がこれまでの思考を中断させてしまうのです。問題は割り込みの時間ではありません。３分でも１分でも思考の中断が問題なのです。はずみ車ではありませんが、一度軌道に乗った頭の回転を一旦ストップさせ、再び元の回転に戻すためには、大きな労力と時間を要するものです。マネジャーはこのような思考の中断を強いる割り込み作業や兼任作業から担当者を守ってあげなければなりません。ましてやマネジャー自らそれを依頼することなどは論外です。ラインの割り込み作業など、プロジェクトのマネジャーには如何ともしがたいものもありますが、切羽詰った状態にあるのならば、その割り込み作業の削減・免除・延期をメンバーに代わってラインマネジャーと交渉すべきです。

• 管理作業自体が生産性や品質の低下の一因になることを自覚しているか。
  成果物の作成に直接結びつかないオーバーヘッドの最たるものが管理報告用の作業です。たとえそのために必要とされる時間が5分や10分であっても、「書かなければいけない」という意識は8時間頭の中にあるかもしれません。もちろんこれは集中力欠如の原因です。報告の負荷など大したことではないだろうなどと考えずに、軽くできる負荷は全て軽くするつもりでメンバーの作業を見直してみることです。本気で考えれば代替案はいくらでもあります。例えば管理用の報告であれば、リーダー自らメンバーの席まで行って口頭で簡単に確認すればよいのです。本当に忙しいときには、共有フォルダを探してファイルを探してファイルを開いて記述するといった簡単な作業でさえ、非常に面倒でイライラさせるものなのです。

• 知識労働者を管理するための作業が、その成果物の生産性や品質を低下させる一因となっていることを自覚しているか。
  官僚的な管理と意味のない会議で奪われる時間は、（特に大規模プロジェクトにおいて）相当なものになります。設計者が設計に使える時間、プログラマがプログラミングに使える時間は、（後からは全く思い出せないような）実に様々な理由で奪われていきます。本当に生産性を向上させたいのであれば、プロジェクト管理を根本的から見直す必要があります。管理が原因で生産性が低下しているならば、一つの解決策は管理を緩めて現場の判断に任せることです。往々にしてマネジャーは「労働者というものは管理しなければサボるものだ」という考えを持っていますが、これは肉体労働者に対しては有効な考え方かもしれませんが、エンジニアのような知的労働者にはむしろ逆効果となりかねません。そもそもエンジニアというものは、指示されなくとも最も効率的な作業方法を選択するものですし、品質の低下を最も嫌うのはエンジニア自身です。このような知識労働者にとって（的外れな）管理は単に生産性を低下させ、作業への集中を妨げる要因でしかないのです。テイラーの科学的管理法の考え方はエンジニアの仕事にはそぐわないのです。（※もちろん、本当に経験の浅いメンバーや新人に対する管理については、この限りではありません）

• 管理や規則によってチームの成果を最大化することはできない。
  管理や規則が行動原理となっているチームでは、メンバーに管理や規則以上のものを期待するのは難しいでしょう。ガチガチの規則の中で「自主性を発揮せよ」というスローガンが掲げられる事がありますが、これは笑い話にしかなりません。都度変化する現場の状況に対して臨機応変に最適な行動をとっていくために求められる自主性は、管理や規則の中からは生まれてきません。一方、自分の作業成果物がいつ、誰が、どのような作業をするために必要とされるのか、を十分に意識した上での行動や作業は、結果としてチーム全体としての成果の最適化に貢献することになります。しかしこのような行動は、明確な目的意識と行動原理から生まれるものです。官僚的な管理の中から生まれるものではありません。管理のルールや規則は、チームの成熟度を考慮の上で検討されるべきでしょう。

• 無駄な待ち時間の削減

• 無駄な待ち時間の存在を意識しているか。
  マネジャーはまさか自分が生産性の低下の原因だとは思ってもいないことでしょう。しかしマネジャーは往々にして開発者を「待たせる」ことによって生産性の低下を招いているのです。マネジャーが自分の行き先を明示していないために、メンバーは承認や確認をもらうために10分間探し回らなければならないかもしれません。マネジャーが外出していたら、その仕事はその日には着手できないかもしれません。マネジャーは（もちろん自身の行動だけではありませんが）極力、開発者の待ち時間を減らすように意識すべきです。

• 現場の判断をどれだけ許容しているか。
  生産性向上の基本は、「現場に判断させる」です。開発者がある行動を取るために１時間かかるとします。しかしその行動の許可を得るために６時間かかるとします。これが現実の開発の現場です。生産性を高め、作業の進捗を早める最も良い方法は現場に情報を与え、現場に判断させることです。

• 必要なときに必要な情報が必要なメンバーに過不足なく提供されているか。
  ・情報の流通ルートは確保されているか。
  ・情報の流通ルートに障害物はないか。どのような障害物が想定されており、どのような対策が施されているか。
  ・マネジャーやリーダーが「権力志向」であることはないか。（※権力志向のマネジャーは情報を自分だけで持っていたがります）

• 承認や許可の伺いに関するルールが最小限か。メンバーは自分の判断で行動できるか。（権限委譲されているか）
  ・承認や許可は、その必要性がきちんと吟味されているか。「慣習」で課せられていることはないか。

• 過度に官僚主義的になっていないか。
  ・マネジャーやリーダーが「権力志向」であることはないか。

• システムの基本方針やコンセプトが明確になっているか。
  ・個々の詳細な判断のためにマネジャーの指示を仰ぐ必要はないか。

• 標準や規則、及びその適用について明確になっているか。
  ・個々の詳細な判断のためにマネジャーの指示を仰ぐ必要はないか。

• それぞれのメンバーに必要な道具、必要な環境が十分与えられているか。

• 外部インターフェースなど、外部要因による影響を極力抑える努力をしているか。

２．そのままでは対応できない場合に検討すること

対応できないのであれば、対応できない旨を顧客に納得してもらわなければなりません。本項では顧客に納得してもらうためのネタ、またはそのヒントを紹介します。

• 対応が困難な理由の説明

• 膨張した顧客の要求への対応がどうしても困難な場合、その要求は却下せざるを得ないことを覚悟すること。
  あらかじめ「余裕を持った」見積で顧客の承認を得ているのであれば、ある程度の仕様の膨張に対応することは可能です。しかしそうでない場合、つまりギリギリの見積で開発がスタートしている場合、顧客との交渉で踏ん張れないと、後に控えているのはデスマーチの影です。一旦プロジェクトに無理を強いると、更に無理せざるを得ない状況が必ずやってくるものです。「踏ん張りどころ」は最初の「踏ん張りどころ」が一番重要です。

• 要求を呑んだ場合、結果としてリリース日が延期されることになるリスクを顧客に説明すること。
  ・遅延のリスクはどれだけ現実的か。どれだけ可能性があるものか。
  ・リリース日が一日延期されると、その遅延コストはどのくらいに見積られるか。
  ・要求への対応は、遅延リスクに見合うものか。

• 要求を呑んだ場合、納期や費用をそのままで機能だけを追加する場合のリスクを顧客に説明すること。
  スケジュールや予算は、当初の機能ボリュームを前提としています。予備の見積を取っていない場合、スケジュールや予算をそのままで機能だけを追加しようとするならば、いずれかが破綻するのは目に見えています。
  ◇計画にない機能を追加する場合に覚悟しなければならないリスクの例
  • 作業工数の増加→稼動遅延のリスクまたは品質低下のリスク
  • プログラム構造の変更と破壊→品質低下のリスク
  • プログラム構造の複雑化→品質低下、生産性低下、保守性低下のリスク
  • バージョン管理の煩雑さ→品質低下のリスク
    

• どれほどスケジュールが押し迫っていても、人海戦術に頼れる作業と頼れない作業があることを説明すること。
  「カネは出すからこれだけの機能追加を納期厳守でやってくれ」と依頼されても、対応可能な作業と不可能な作業があります。作業が量的な作業に還元されていれば人海戦術で対応できるでしょう。しかし質的作業は要員を何人追加しても「かかる時間はしっかりとかかる」のです。よくある例えですが、「二人の女性がいても妊娠期間を半分にすることはできない」のです。

• 膨張した仕様に対して（多くの）開発組織が実際に取っている「策」の危険性を説明すること。
  多くの場合、費用もスケジュールも再見積されることなく、開発側は膨張した顧客の要求を仕方なく呑んでいます。どのようにしてこの見積の不足分をカバーするのでしょうか。多くのリーダーは自らの責任を放棄し、対応は現場のプログラマ任せになっているのが現実です。それがサービス残業によって対応されるのか、試験項目の省略によって対応されるのかはわかりません。いずれにしろ、最終的には成果物の「品質」で補われることになるのです。

• 納得させるための説明

• 正論だけで顧客を納得させようとは思わないこと。
  正論だけで顧客が納得するわけはありません。それでは単にシステム開発の講義になってしまいます。あくまでも正論を裏づけにして、顧客の感情を納得させることに意識を集中しなければなりません。とはいうものの、顧客を感情的に納得させるためには、正論の裏づけとなる論理もまた必要になるのです。勢いと情熱と感情だけでは不足です。顧客を納得させるためには、確固としたバックボーンが必要なのです。

• 現場の生産性に問題がないことを説明すること。また、実施している生産性の向上策について説明すること。
  リソース不足を理由に仕様の追加が難しい旨を伝えると、「生産性向上で対応して欲しい」などと無理な要請をされることがあります。まずは開発側がどのような努力をしている中で要求への対応が難しい状況になっているのかを、丁寧に説明する必要があります。
  ◇生産性向上策の例
  • 開発ツールの使用
  • 共通コンポーネントの使用
  • 既存コンポーネントの流用
  • コミュニケーションツールの使用
  • コミュニケーションロス防止のための開発環境整備（机の配置等）
  • 各種情報共有による暗黙知の醸成（判断ミスの削減と質問時間の削減）
  • 各種権限委譲による判断待ち時間の削減
  • 各種モチベーション向上策
  • 各種割り込み作業の排除
  • 各種兼任作業の排除
  • 個人の性格を考慮したチーム編成
  • 個人の性格と能力を考慮した作業の割り当て
    
    
• 他社との比較については「消極的に」推論で対応すること。
  システム開発のトレードオフを理解してもらったからといって顧客が納得するとは限りません。トヨタもＧＭも同じトレードオフの中で競争しているかもしれませんが、生産性には違いがあります。「それでも他社だったら対応できるはず」と思っている顧客を納得させるためには、何らかの説得力のある説明が必要です。他社の実情はわからないので推論に基づくことになりますが、それでも説明するのです。推論であることを認めながら説得していくのです。ただしこの場合、ありもしない他社の批判につながらないように気をつけなければなりません。
  ◇顧客を納得させるための推測の例
  「開発能力の違いについて当社はここまで考えています。決して当社の能力が低いわけではありません」というロジックで説明します。
  • 他社の見積はそもそも過小見積だったのではないか。
  • 他社は問題の難しさを理解していないのではないか。
  • 他社はその業務、その技術についての経験が浅いのではないか。
  • 他社はプロジェクトを崩壊に導きかねない「賭け」をしているのではないか。
  • 他社は保守やサポートで「損失補填」をしようとしているのではないか。
  • 他の戦略があるのではないか。（次プロジェクトへの期待など）
  
  
• 顧客の「生産性向上」の要求に対しては、最後には正論で対応すること。
  ◇「正論」の例
  • 生産性向上には日々会社として取り組んでいる。ソフトウェア業界は過当競争の業界であり、そのような努力なしに生き残ることはできない。
  • 生産性向上には日々取り組んでいるが、S/Wは人間による知的労働作業であり、H/Wの生産性向上とは全く別の話である。短期間に10%や20%といった生産性の向上は不可能である。可能であるとすれば、それは何らかの作業を省いた結果である。

３．新たな解決策の模索

仕様の膨張に対して「できない理由」を説明しただけではだけでは顧客は納得しません。顧客は目に見える効果を期待して投資をしているのです。身銭を切っている顧客の立場を考えなければなりません。代替案や新たな対応策を提示しなければなりません。少なくとも、その準備をしておく必要はあります。

• 機能の削減

仕様の膨張に対して最も効果的な解決策はトレードオフのバランスを回復することです。それが「物理法則」に則った自然な問題解決法と言えます。 トレードオフバランスの中でも、機能の膨張に対しては機能の削減で対応するのが最も合理的です。追加の仕様を受け入れる代わりに、重要度の低い機能をシステムから落とします。トレードオフの他の要素への影響が少ないため、現実的な解と言えるでしょう。ただし機能の削減はユーザの抵抗が最も大きいことも事実です。「システム導入の意味がない」という意見に対して「我慢してください」とはなかなか言えません。「次期開発」など、将来に向けた何らかの展望は必要でしょう。

• 削減すべき機能、削減してもよいと思われる機能を洗い出すこと。
  ◇削減すべき機能、削減してもよいと思われる機能の例
• システムの目的との整合性が取れていない機能
• システムの目的との整合性が薄い機能
• 「あればよい」機能、「あれば便利な」機能
• 優先順位の低い機能
• 特定の個人の要求で追加された機能
• 当面は使用されない機能（※ただし２次開発が前提）
  
  
• （該当機能を外す旨の）顧客説明の準備をすること。
  ・該当機能のシステムにおける位置づけを検討する。
  ・該当機能を削減しない場合に想定されるPJ遂行上のリスク（納期・費用・品質等）を検討する。
  ・該当機能を削減してもシステムの目的には影響しない理由を検討する。
  ・該当機能を削減すると得られるPJ遂行上のメリット（納期・費用・品質等）を検討する。
  ・該当機能を削減すると得られるシステム上のメリット（統一性・使用性等）を検討する。
  ・顧客説明のための資料を作成する。
  
  
• 検討内容を顧客に説明すること。

• 一部機能のリリースの延期

  リリースを延期することにより、仕様の膨張による品質のリスクを避けることができます。ただし通常は開発工数が増えてしまうことになるので、追加の費用負担を顧客に要求しなければなりません。もっとも、膨張分以上のリリースの延期が認められるならば、開発要員を削減することによって追加の費用を最小限に抑えることができるでしょう。（※チームのメンバー数が減ると、一般的に一人当たりの生産性は向上します。）

• リリースを延期しても問題がないと思われる機能を洗い出すこと。
  ◇削減すべき機能、削減してもよいと思われる機能の例
  • システムの目的との整合性が取れていない機能
  • システムの目的との整合性が薄い機能
  • 「あればよい」機能、「あれば便利な」機能
  • 優先順位の低い機能
  • 特定の個人の要求で追加された機能
  • 現在のリリース予定日では使用される予定がない機能
    
    
• （該当機能のリリースを延期する旨の）顧客説明の準備をすること。
  ・該当機能のシステムにおける位置づけを検討する。
  ・該当機能のリリースを延期しない場合に想定されるPJ遂行上のリスク（納期・費用・品質等）を検討する。
  ・該当機能のリリースを延期してもシステムの目的には影響しない理由を検討する。
  ・該当機能のリリースを延期すると得られるPJ遂行上のメリット（納期・費用・品質等）を検討する。
  ・顧客説明のための資料を作成する。
  
  
• 検討内容を顧客に説明すること

• 増員

  機能の削減によってもリリース日の延期によってもトレードオフのバランスを回復できない場合は、コストを再検討せざるを得ません。すなわち増員です。厳しい予算の制約がある場合、この解決策は難しいかもしれません。戦略的に開発側が「持ち出し」で対応することを覚悟してもなお、注意が必要です。ブルックスの有名な法則にもあるように「遅れているプロジェクトに増員すると、さらにプロジェクトは遅れる」リスクがあるのです。

• 機能の増加を増員で対応しようとするのはリスクを伴う方法である。
  機能が倍になったらスケジュールは単純に倍以上必要になります。スケジュールを変更しないとすれば必要な増員は倍では全くききません。場合によっては3倍、4倍の増員をしても対応できません。チームの人数が増えると相互コミュニケーションのパスは幾何級数的に増大します。コミュニケーション上のミスやロスが増加します。管理工数も増加します。教育・訓練期間も必要です。一人当たりの生産性は低下します。つまり、機能の増加分だけ線形的な見積で増員しても、それでは全く足りないのです。

• 増員によってスケジュールの短縮を図るのはさらにリスクを伴う方法である。
  仕様膨張対策ではありませんが、「増員ついで」の話です。増員してもほとんどの場合、期待されたスケジュール短縮効果は見込めません。要員を3倍に増員しても先の非線形効果から期間は1/3には縮まりません。2/3でも難しいのではないでしょうか。また、分割不可能なタスクが多い場合、増員は全く効果がありません。また、クリティカルパス上にない作業をどれほど早く終わらせても、全体スケジュールが短縮されるわけではありません。スケジュールの問題を解決するための増員には十分に注意すべきでしょう。

• 要因の確保

• 新規要員の教育・訓練のために費やされる既存メンバーの時間を考慮しているか。

• 新規要員の教育・訓練のために低下する既存メンバーの生産性を考慮しているか。

• 新規要員の立ち上げに許容される時間はどのくらいか。
  ・許容される時間内に、本当に立ち上げが完了するのか。前提条件や制約条件が隠れていないか。

• 新規要員に求めるスキルは明確か。
  ◇新規要員に求めるスキルの例
  ・技術スキル面
  ・プロジェクト独自の技術スキル面
  ・業務スキル面
  ・既存のメンバーとのコミュニケーション面

• 新規要員をどこから調達するか。
  ・社内に適当な要員がいるか。
  ・協力会社からの要員確保は可能か。

• 新規要員を調達する際の制約条件は何か。
  ◇新規要員を調達する際の制約条件の例
  ・コストの制約
  ・時間の制約
  ・性別の制約
  ・環境の制約

• その制約条件で要員確保は可能か。
  ・制約条件を緩和すると要員の確保は容易になるか。

• 要員確保の制約条件に合わせるために、プロジェクトの計画を変更することは可能か。
  ・どのような条件があればプロジェクトの計画を変更することが可能か。

• 新メンバーのオリエンテーション

• 何のために、何を期待されてチームに配属されたのかを明確に説明すること。

• あらかじめプロジェクトの概要資料を渡しておくこと。
  事前の知識もなく、オリエンテーションでいきなり2時間を超えるような長い説明は不可です。説明する側は1回で済ませたいところですが、説明を受ける側はそれでは吸収しきれません。

• 説明時間はたっぷりと取ること。
  説明時間を惜しんではいけません。30分や1時間を惜しむことで、後でその100倍の時間を失うことになりかねません。

• ボリュームが多ければオリエンテーションを複数回に分けること。
  説明時間を惜しんで、一回で済ませてしまおうと思ってはいけません。近道だと思う道は決して近道ではないのです。

• 不明点や疑問点はきちんと聞くように新メンバーに念を押すこと。
  念を押しても聞いてこないメンバーもいます。これはもちろんメンバーに問題がありますが、だからといって放置しておいてよいわけではありません。適宜質問して確かめることです。

• 同じ質問を何度もされても都度丁寧に説明すること。
  一度に頭に吸収できる量はそれほど多くありません。同じ質問をされても「それは説明しただろう」などと返してはいけません。忍耐強く何回も説明することです。

• 説明後は相手の理解を確かめること。
  一度説明しただけで相手が理解したとは思わないことです。本当にわからなければ質問もできません。また、「理解しただろ」などと、理解を「強要」してはいけません。

• どれほどのスキルの持ち主であろうとも、新規参画要員には即戦力は求めないこと。
  即戦力を期待して無理に作業を割り当てても、却って品質の低下を招くだけです。結果として「丁寧に指導した場合」よりも多くのコストを要してしまうものです。

• 新たなチームの一員に対してコミュニケーション上の配慮をすること。
  くれぐれも既存のチームメンバーで固まらないようにします。

• 新メンバーに最初に依頼する作業として下記の作業を検討すること。
  ・ドキュメントの作成・修正
  ・優先度・重要度の低い障害の欠陥部分の特定
  ・優先度・重要度の低い欠陥の修正
  ・コードレビューの実施
  ・試験ケースの技術的なレビューの実施
  ・追加の試験ケースの作成
  ・要員の雑用

• その他の解決策

• メンバーのモチベーションを高め、メンバーの作業をサポートし、無駄なペーパーワークを削減し、無駄なオーバーヘッドを削減し、無駄な待ち時間を削減したとします。その上で顧客に仕様膨張への対応が困難であることを説明し、了承してもらえなかったとします。それでも何とか対応するために、機能の削減やリリース日の延期の交渉、増員の交渉を行いましたがいずれも不調に終わったとします。ここまで来るとさすがに切ることのできるカードの数は少なくなってきます。

• 標準・規則への「過度」の準拠をあきらめてもらうことは可能か。
  「適度」な標準・規則への準拠は保守性を高め、生産性の向上にもつながりますが、これが過度に適用されると逆にオーバーヘッドとなってしまいます。

• 再利用性や保守性をあきらめてもらうことは可能か。
  再利用性や保守性はシステムの「当座の直接の目的」には貢献しません。とにかく最も重要なのが「目先の機能」であるならば、これをあきらめるのは一つの手です。

• 性能・信頼性のレベルを下げてもらうことは可能か。
  非常に高い性能や信頼性を求められるシステムの開発は生産性を低下させることになります。性能・信頼性要件への対応を、次期開発にまわすことができないかどうかを交渉します。（※ただし性能や信頼性は基盤のアーキテクチャに大きく依存するため、目処がないままに安易に約束してはいけません。）

• 新技術をあきらめられるか。
  新技術をはじめて適用するプロジェクトでは、一般に生産性も品質も低下することになります。「後戻り」ができる位置にいるならば、早急に見切りをつけて「慣れた道」を通るのも一つの手です。

• 「素晴らしいな設計」をあきらめられるか。
  「素晴らしいな設計」は頭を使うだけに設計には時間がかかります。メンバーの理解にも時間がかかります。また、一般的に例外事項への柔軟性は低くなりがちです。平凡でシンプルな設計で顧客の要求に応えられないかを検討してみます。

• 最後はやはり、膨張した仕様に対しては対応の対価を求める交渉をすること。
  仕様の膨張とはサービスで対応しなければならない顧客の要求のことですが、対応の自助努力にも限界があります。その場合、まっとうな仕事をするためには相応の対価が必要になる旨を説明し、納得してもらわなければなりません。納得してもらえない場合、赤字を覚悟するか、品質の低下を容認するかを決定するのはマネジャーの責任です。くれぐれも現場の判断にゆだねてはいけません。現場にゆだねるということは、明確な指示はせずともメンバーに無理な要求をつきつけることによって、暗に品質低下を認めたりサービス残業を強要するということになるのです。

システム開発を取り巻く環境の変化

企業の情報システムの歴史はメインフレームによる集中処理の時代から始まりました。この頃のコンピュータの主な利用目的は業務の効率化や省力化にありました。それまで人手に頼っていた様々な定型業務を機械化するものです。やがて80年代も後半に入るとクライアント・サーバによる分散化の時代が始まり、そして現在のWebシステムの時代へとつながっていきます。

こうしたハードウェア・ソフトウェア技術の進歩や新しいアーキテクチャの登場と合わせるように、コンピュータはそれまでの単純な業務の効率化のためだけではなく、多種多様な分野・領域で活用されるようになってきました。例えば、会社が蓄積している大量のデータをいかにビジネスに役立てていくかという情報活用支援や、経営層による企業の舵取りをサポートするための意思決定支援、新たな事業やサービスを生み出すための付加価値創造支援や、業務プロセス標準化のための支援、従業員の能力開発支援など、その目的は様々です。

コンピュータの利用目的の多様化は、コンピュータの仕事の領域がもともと得意とする分野から苦手な分野へと広がってきたことを意味します。コンピュータは単純繰り返し作業に最も強みを発揮するものです。「応用」や「例外」という言葉から連想されるような作業は苦手とするものです。しかし時代とともにコンピュータが利用される目的が「新しい価値の創造」のような、コンピュータが苦手とする領域、つまり曖昧かつ複雑な領域へと移ってきたのです。

利用目的の多様化・複雑化が意味するもの

コンピュータの利用目的の多様化はシステム開発のプロジェクトの進め方自体にも変化を促すことになりました。単なる効率化や省力化を目的としていた時代では、システムの目的やそのための手段は誰の目にも（ほぼ）明らかでした。議論が起こっても、合理主義と技術的な正しさ、あるいは論理的な正しさを追求することによって、単なる根拠のない意見は排除され、その議論は収束していったものです。システムの導入効果は計算式によって求められ、客観的な基準でシステムを評価する事ができました。

しかしコンピュータの利用目的が企業戦略あるいは経営支援といったものと結びつくようになると、システムに求められる要件は「不透明な将来予測」や「ステークホルダーの価値観」あるいは「企業理念」といった曖昧かつ複雑な要素を考慮に入れる必要が出てきました。こうなると議論はなかなか収まりません。論理的な思考と明白な事実だけでは結論には達しません。これまでは満場一致で決定していたような決定事項が、ステークホルダー各々の過去の経験や価値観同士のぶつかり合いによって、なかなか決定できなくなってきたのです。当然、プロジェクトのマネジメントは難易度が増す事になります。

マニュアルが抱える2つの限界

プロジェクトの難易度は高まる一方です。もちろんこの間、プロジェクトマネジメントの知識や手法も着実な進歩を遂げていきました。書店に行けば「プロジェクトマネジメント」と名のつく参考書の類で溢れかえっています。しかし実際の開発現場を目の前にすると、こうしたマニュアル頼みの対応には限界を感じざるを得ません。マニュアルをベースにしたマネジメントの「行き詰まり感」が拭えないのです。その一つが汎用化の限界です。

現実は限られた文字の世界や、抽象化されたフレームワークの世界で表現できるほど単純ではありません。マネジメントが扱わなければならないのは、ただでさえ複雑な現実です。それに加えて、コンピュータの利用目的の更なる多様化という新たな現実もあります。システムに要求される曖昧処理や例外処理は増加の一方です。もはや単純な定型処理だけが求められているわけではありません。

方法論が方法論として、マニュアルがマニュアルとして成立するためには、こうした複雑さを抽象化し、一般化していかなければなりません。ところがそのような処理を経た知識の宿命として、個別の案件を目の前にするとやはり力不足になってしまうのです。マネジメントのノウハウがいかに膨大な過去の事例をベースにしているとはいえ、この宿命には逆らえません。パラメータ化などによって宿命に逆らおうとしても、その結果分厚くなった厚みほどには効果は上がりません。

そしてもう一つがエンジニアリング的知識の限界です。もともとプロジェクトの成否は「人」という要素に大きく依存していましたが、昨今のシステム開発ではその比重が以前にも増して大きくなってきています。ところが「人」に関わる部分はこれまでのプロジェクトマネジメントがあえて深く踏み込んでこなかったところでもあります。「人」を扱う場合には決して無視することができない領域、理念や価値観といった曖昧な領域、形式化が難しい領域、因果関係の成立が難しい領域には、これまでの手法や知識体系はあえて深く言及することはなかったのです。

かくしてこれまでの参考書は、徹底的にマネジメントを解説した後で「それでも政治問題には勝てません」で終わっているのです。確かに、どれほど優秀なマネジャーが最善を尽くしたところで、政治の力には勝てません。確かな技術力と客観的な事実の力で（半ば強引にでも）プロジェクトを成功に導くことができた一昔前の時代であれば、ここで「この問題は私の範疇外です」と脇に放ってしまっても許されたかもしれません。しかし現在のプロジェクトはもともとが価値観の争いになっているのです。政治問題こそが片付ける問題として、プロジェクトの前面に出てきたと言ってもよいでしょう。ここを無視してプロジェクトを進めていくことは、もはやできません。それはプロジェクトマネジメント自体の放棄につながります。

プロマネの仕事

こうした現実の変化に、方法論やマニュアルも指をくわえて傍観してきたわけではありません。計算で結果が求められる世界、因果関係の世界、エンジニアリングの世界から、曖昧な人間系の世界に積極的に足を踏み入れてきています。今やどのプロジェクトマネジメント本でも、「コミュニケーション・マネジメント」など「それらしい」テーマにページを割いています。しかし現実におけるその重要性や作業に割かれている時間の割合から考えると、その扱いはまだまだ軽いものと言わざるを得ません。ほとんどのプロマネ本は、未だにエンジニアリングの呪縛にはまったままです。

確かに「人」の問題はコンピュータサイエンスやソフトウェアエンジニアリングが扱う問題ではありません。技術者を自認する人の中では範疇外の仕事かもしれません。しかし、それは間違いなくプロジェクトマネジャーの仕事の範疇です。理由は何であれ、原因は何であれ、結果としてプロジェクトを成功に導くのがプロジェクトマネジャーの仕事です。それは自然科学というよりも社会学や心理学に近い世界かもしれませんが、マネジャーの仕事の範囲は学問上の切り分けで決まるわけではありません。自然科学の問題であろうと、政治の問題であろうと、プロジェクトの成功を阻む障害物は全て撤去していくのがプロジェクトマネジャーの仕事です。

本書の目的

コンピュータの利用目的の多様化により、人の価値観が重要なシステム要件になってきています。それぞれの哲学のぶつかり合いによって、物事は客観的な事実だけではなく、人間同士の見えない力関係によって決まるシーンも見られるようになってきています。プロジェクトを成功に導くことがミッションであるプロジェクトマネジャーにとって、これらは非常に重要なテーマではありますが、自然科学系のテクニックで扱うには少々荷が重いテーマです。

本書の目的は、こうした現実を踏まえて、これまでのプロジェクトマネジメント本では扱いきれなかった、現場の泥臭い「人」の問題に焦点を当てることにあります。これまでのプロマネ本では軽く扱われがちだった、「人」の領域に焦点を当てることにあります。その意図は、プロジェクトが抱える様々な問題を解決するための新たな突破口の一つとして、エンジニアリングだけでは対応しきれない「人」の問題を真正面から扱おうとするものです。

もちろん全ての問題が「人」への対応如何で解決するわけではありません。「顧客対応」さえやっていればプロジェクトがうまくいくわけではありません。そもそもの前提条件として、エンジニアリングの考え方をベースに置いたマネジメント手法は重要であり、それは疑う余地もありません。ただし、こうした蓄積されたマネジメントのノウハウも、「人」の存在を無視しては効果が半減してしまうことも事実です。これらの無機質なノウハウは、いかに顧客に合わせて適用していくかが重要なポイントになっているのです。既存の知識を本当に有効に活用するためにも、「顧客対応」は必須のテクニックと言えるでしょう。

想定する読者

本書のタイトルには「顧客対応」とありますが、決してベンダ側の読者のみを想定して書かれたものではありません。ユーザ内にあっても担当者にとってはマネジャーが、マネジャーにとっては部長が「顧客」です。本書はベンダ側のプロジェクトマネジャーである弁田君が活躍するベンダ視点の物語になっていますが、扱っている問題は全て、「顧客内」でも立場を変えて同じように対応していかなければならない問題ばかりです。「人」の問題を扱う可能性のある全てのプロジェクト関係者を対象にしています。

★困ったときの掟！誠実な回答、ダメなら「切り出し」て「飛ばす」こと

【弁田君のプロマネ日記】

あるプロジェクトの定例会での話です。その定例会の顧客側の参加 者の一人に、弁田君が苦手としている人がいました。役職的にはある 程度高い位置にいるのですが、プロジェクトには深く関わっている様 子は見えません。弁田君にも彼がどのような役割でどのような作業を 受け持っているのかがよくわかりません。しかしこの人が定例会の場 で、弁田君の報告に対してことごとくツッコミを入れてくるのです。 それが的を射たものであればよいのですが、どうもピントはずれの質 問や指摘ばかりです。回答するのは時間の無駄としか思えないようなものばかりなのです。

他の顧客のメンバーも内心はうんざりした様子が見えますが、もち ろん顔にも口にも出すことはありません。最初のうちは丁寧に回答していた弁田君でしたが、あまりにもあらさがしとしか言えないツッ コミの多さに、辟易としてきました。プロジェクトに何の価値もも たらさないツッコミなのです。それでも平静を装って対応していま したが、頭をフル回転させたり、真剣に考えて回答することは次第 になくなってきました。しかしある時の弁田君は、油断がすぎたよ うです。いつものあらさがしに対して、あまりにも軽々しくあしらっ てしまったのです。いつものピント外れのツッコミだったのですが、 それに対して、「大した問題ではない」という発言をしてしまいました。

この発言が当の相手を刺激してしまいました。お怒りを買ってし まったのです。さらに、「最近の回答はどうも軽くて信頼感に欠けるが、 真剣に考えているのか」と、弁田君の心の中を見透かしたようなスト レートなコメントまでもらってしまいました。「しまった。手を抜き すぎた」と慌てた弁田君でしたが、後の祭りです。この件は上司の謝 罪で事は収まったのですが、以降の定例会でのツッコミが激しくなっ たのは言うまでもありません。知らない人が見れば「いじめ」に近い ものがあったかもしれませんが、こうなった以上、ピント外れのツッ コミにも逐一真剣に対応するしかありません。 　困った弁田君は頼りの先輩に相談してみましたが、「それはお前が 悪い」の一言で結論づけられてしまいました。

先　輩
「馬鹿だなぁ。定例会などの報告の場で顧客からツッコミが 入るのは『お約束』だろう。ツッコミを入れるのが顧客の仕事なんだから。ある程度のあらさがしは当然のこととして、覚悟しておかなきゃ」

弁田君
「わかっていたつもりなんですが、あまりにも時間の無駄とした言いようがないツッコミばかりなんですよ。それに他の顧客もうんざりしていたようだし」

先　輩
「そんなの関係ないだろ。顧客の質問には変わりがないんだから。それにツッコミを入れた方だって、本当に回答が欲しくてツッコミを入れているわけじゃないだろ？ポーズもあるんだから、そういう時はきちんとポーズで返しとけばいいんだよ」

弁田君
「はい」

先　輩
「ツッコミを入れた方は、誠意のこもった回答をもらえればそれで気が収まるんだから。それにツッコミのポイントも大体いつも同じなんだろ？」

弁田君
「ええ、よくわかりますね。そうです。ツッコミが入りそうなところは大体予想がつきます」

先　輩
「だろ？そういう時は、あまりにも特定のテーマにこだわるようだったら、その部分だけ別の会議体に飛ばしてしまえばいいんだよ」

まだまだ大人の対応ができていない弁田君でした。

☆対応の極意！何でも反対屋がいる場合は 厄介な部分を切り出してしまうこと

何にでも反対したがる反対屋という人がいるものです。何かにつけ てあらさがしをしたがる人もいます。ベンダとしてはできれば付き合 いたくない相手ですが、プロジェクト全体から見れば、これはこれで 必要な資質の一つを備えた欠くことのできない人物と考えることもで きます。本当に重要なリスクを指摘することはなくても、それに気づ くようなヒントを与えてくれたり、事前に考えておかなければならな いクレーマー対策を思い出させてくれるものです。

ただしこうしたメリットはあるものの、会議の中では反対屋の存在 は明らかにオーバーヘッドになってしまうことも事実です。屁理屈で あることはわかっていても、経験不足の進行役にとってはうまく切り 返すのはなかなか大変です。このような場合の基本戦略は、反対屋が 主張する厄介な部分だけを切り出して、それを別の会議体に飛ばして しまうことです。反対屋にどうしてもこだわりがあるようであれば、 その件についてだけ話し合う別の会議体を設置してしまうのです。

ただし、明確に反対はしないものの、なぜか「この人がいると会議 がうまく進まない」という厄介な人もいます。例えば顧客内の抵抗勢 力と呼ばれる反対屋の中には、表立って「反対」の意見を言わない人 もいます。表立った反対はしないものの、細かな懸念を指摘して、な かなか前に進ませてくれません。しかしあからさまに表面化しない反 対には対応しづらいものです。こうした場合には意見や考えの違いを 思いきって表面化させるための質問を繰り返すことです。どこの部分 で意見や考え方が合っているのか、異なっているのはどこの部分か、 といったことを徹底的に洗い出して表面化していくことです。明確な 反対がなければ対処のしようがありません。曖昧にプロジェクトの進 捗が妨げられるような状況は避けなければなりません。

☆対応の極意！反対屋の質問や ツッコミの癖を掴んでおくこと

同じ説明をしても人によって質問やツッコミのポイントは異なって くるものです。大局的な見地からの質問や具体的で詳細な施策に関す る質問、論理的な整合性に関する質問やドキュメントのフォーマット に関する質問、コンセプトに関する質問や実現手段に関する質問など、 そのパターンは様々です。説明をする側はこのような様々な質問のパ ことができます。

人というものは質問のパターンやツッコミのポイントがある程度は 固定化されているものです。資料の論理的な流れについて質問した人 は、次の説明の機会でもおそらく論理的な流れについてチェックし ているでしょう。詳細な説明よりも結論にこだわっていた人は、おそ らく次もまずは最初に結論を求めていることでしょう。誤字脱字につ いて指摘してきた人は、おそらく次も誤字脱字をチェックしているで しょう。もちろん幅の広さ狭さはありますが、このようなチェックポイントの傾向は誰もが持っているものです。

説明やプレゼンの前には漫然と資料を準備するのではなく、まずは 出席者を確認して、それぞれの出席者が発するであろう質問やチェッ クのポイントを考えることです。相手の考え方の傾向を知り、質問の ポイントをあらかじめ押さえておくことは、議事をスムーズに進めて いくための非常に効果的な方法です。反対屋がいる場合は、この準備 は特に重要です。そしてその視点から見て説明の内容に問題がないか どうかを確認することです。もっとも、反対屋ばかりを見て会議を進 めるわけにはいきません。最重視すべきはプロジェクトのキーパーソ ンの視点であることは言うまでもありません。そこの準備を踏まえた上での反対屋への対応ということです。

要するに顧客のプロファイルを作っておくということです。質問さ れたときの回答の傾向や、説明に対する質問の傾向などを顧客のス テークホルダーごとにまとめておくと、強力な「顧客対応」対策ツールとなるものです。

☆対応の極意！縄張りを侵して反対屋を 作り上げてしまうことに注意すること

火の車に陥ったプロジェクトに途中から支援やサポートとして参画 するような場面がありますが、こうしたケースでは既存のメンバーの 「縄張り意識」に気をつけることです。こちらは助けに来たつもりでも、 「何も知らないくせにかき回してくれるなよ」といった具合に、向こ うは余計なものと思っている可能性は大いにあります。最初の警戒心 から、何でも反対屋になってしまう可能性は大いにあるのです。

誰でも自分の胸に手を当てて考えてみればわかると思いますが、自 分がこれまで自負を持ってやってきた作業に対して、何も知らない輩 が途中からしゃしゃりでてきて勝手なことを言い出したらどう思うで しょうか。さんざん試してみてうまくいかなかった方法や、そもそも 前提として使うことができない方法を、そうとも知らずにあれこれ「こ うすればうまくいく」とばかりにアドバイスしてきたらどう思うで しょうか。いちいち丁寧に「それは何回も試しました」「それはこう いう理由で駄目なのです」と説明してあげるでしょうか。そんな時間 さえ惜しいので「何も知らないくせに口をはさむな」の一言で済ませ てしまっても、その態度は失礼だとは言い切れません。

仮にこうした勝手な口を慎んでいたとしても、向こうの思いには複 雑なものが残っているはずです。支援が来たということは、それまで の誰かの担当作業に対して上層部から「不合格」の烙印を押されたこ とになります。手が離れてほっとしている担当者もいるかもしれませ んが、自分の担当作業を奪われたという思いを持っている担当者もいるはずです。特に、ある一定の領域に対してプロフェッショナルの意 識を持っている担当者の領域を侵すような支援をしなければならない 場合には注意が必要です。担当者の「縄張り意識」に敏感にならなけ ればなりません。容易に反対者を作り上げてしまいます。

こうした状況で立場や権限を後ろ盾に、浅い知識であれこれ指示し たり命令を出したりすれば、すぐにそっぽをむかれてしまうことは間 違いありません。決してへりくだる必要はまったくありませんが、少 なくとも相手のプライドを傷つけてしまうような言動や行動は慎むべ きです。感情を逆なでされた相手は、容易に「何でも反対屋」になっ てしまい、プロジェクトの進行の妨げになってしまいます。時には、 年上の職人を使う若手の現場監督のようなスキルも要求されるということです。

★困ったときの掟！真面目に答えるべき質問とそうでない質問を区別すること

【弁田君のプロマネ日記】

プロジェクトの雰囲気がよくありません。現場の作業は進んでいる のですが、その成果物の顧客の評価がよくありません。顧客とベンダ が契約の文言の解釈をめぐってもめているのです。成果物の記述範囲 やその粒度などについて、きちんと顧客と合意をしたはずなのですが、 その認識が双方で違っているのです。こうなってくると営業だけに任せているのも心配になってきます。現場の弁田君も「文言の拡大解釈」 にできるだけ応えようと頑張ってはいるのですが、大きなプロジェク トということもあって、なかなか一人の力でどうにかなるというもの でもありません。険悪な雰囲気は解消されることはなく、むしろ日が 経つにつれてさらに悪くなっているようです。

そんなときに顧客がコンサルタントを雇ってきました。詳しくはわ かりませんが、IT とプロジェクト管理全般についてのコンサルタン トということです。実は最近の契約をめぐるやり取りでは、話し合い は若干ベンダ側の有利に傾いてきており、成果物についても弁田君の 主張の正当性が明らかになってきたところです。しかし顧客も自分が 不利になってきたことは認識していたようで、その巻き返しのために コンサルタントを雇ったようです。

さて、定例会の場です。弁田君はいきなり出鼻をくじかれてしまい ました。コンサルタントは弁田君が提出した資料の詳細に、逐一詳細 なツッコミと疑問を投げかけてきます。ツッコミというよりも、ツッ コミを超えたあからさまな攻撃質問です。弁田君は一つ一つ丁寧に答 えていこうとしたのですが、完璧な資料などあるはずがありません。 ちょっとした不備は徹底的にほじくられ、「プロジェクトへの影響」 や「今後の対応方針」など矢継ぎ早の攻撃が続きます。もちろん、そ れら新たな質問に対する回答にも、細かなツッコミが入ります。

　「ちょっと」「思う」などのあいまいな言葉をうっかり使ってしまう と、すぐさま「想像か」とのツッコミが入ります。「本筋ではないの ですが」と前置きをおくと、その前置きに対して「なぜ本筋以外のも のが書かれてあるのか」などのツッコミが入ります。弁田君、さすが にしどろもどろになってきました。

散々な目にあった弁田君です。顧客がこれからさらに攻勢を強め てくることは目に見えています。困った弁田君は先輩に相談してみました。

先　輩
「あはは、それは大変だったなぁ」

弁田君
「これからもこれが続くと思うと嫌になってしまいますよ。うちの立場も微妙になってきそうな感じもするし。どうすればいんでしょうか」

先　輩
「君はまじめだからなぁ。本当のことをいうと、そういう攻撃にはいちいち対応していたら駄目なんだよ」

弁田君
「そんなことを言っても、無視するわけにはいかないじゃないですか」

先　輩
「無視することはないが、真面目に一つ一つ回答していったら、それこそ相手の思うつぼだよ。真面目に答えては駄目だ。むしろ、質問の意図を確認するなど、本質について逆にこちらから質問していくべきだよ。そのコンサルタントを質問攻めにするくらいの気持ちでいかないと」

弁田君
「…………」

先　輩
「相手だって、君に投げている質問の回答を、本当に欲しがっているのか？違うだろ？だったらそこは君がコンサルタントを攻撃できるポイントだよ。どういう目的で質問しているのか、その回答をもらったらどういうアクションを起こすつもりなのか、逆に聞いてみなよ。もちろん向こうも海千山千だから、簡単にこちらの反撃にやられるとは思えないけど。少なくともやられっぱなしじゃ駄目だよ」

質問には絶対に答えなければならない、と無条件に思っていた弁田君にしては目からうろこのアドバイスでした。

☆対応の極意！あからさまな攻撃目的の質問にはまじめに答える必要はない

顧客からの質問には3 種類があります（次頁-図1-1 ）。本当に純粋 な疑問から出てきた質問と、質問のための質問、それから攻撃のため の質問です。1 番目の質問であれば問題は何もありません。顧客の疑 問には誠実に答えていくべきです。2 番目の質問は質問者の体裁作り のための質問です。ポーズのための質問です。質問すること自体が目 的になっており、その回答を得られたからといって実質的に何がどこ に影響するわけでもないという質問です。面倒かと思うかもしれませ んが実害は大きくはありません。対応してあげましょう。注意しなけ ればならないのが3 番目の質問、攻撃のための質問です。本当に純 粋な疑問から出てきた質問でも、中には説明する側にとって非常に厳 しい質問もあります。これと攻撃のための質問を混同してはいけませ んが、はっきりと質問の意図が「攻撃」にあると感じられた場合は、 それなりの対応が必要になります。

一番良くないのは攻撃のための質問に逐一誠実に答えていこうとす ることです。答えられる質問であっても、そこに明確な攻撃の意図が 感じられたのであれば、あえてすぐに答える必要はありません。逆 に相手の質問自体に質問を投げかけ、相手の質問の信頼性や正当性に 疑問を投げかけるのです。その質問の前提には何があるのか、その前 提は正しいのか、その質問は何らかの推測に基づいているのではない か、間違った事実をもとに質問をしていないか、などといった具合に、 質問に対して「突っ込み」を入れていきます。はっきりと質問の意図 を正してみるのも一つの手です。「聞いているのはこちらなのだから、 あなたはただ答えればよい」というような高圧的な相手の回答にもひ るむことはありません。「質問が抽象的すぎて様々な回答の可能性が ある」「正確に回答するためには正確に質問の意図を理解しなければ ならない」などと、攻撃の屁理屈には屁理屈で対抗するくらいの気持 ちを持つことです。質問の目的が、真にプロジェクトのことを考えてのものであれば真剣に対応すべきですが、質問に別の意図を感じられた場合は、それなりの対応をするべきです。

☆対応の極意！どうしても答えられない質問にはどのように対応するか

攻撃目的の質問ではなくても、真剣にプロジェクトのことを考えた 質問でも、中にはどうしても困ってしまう質問、厄介な質問があるも のです。「痛いところをつかれた」と思わされるような質問です。相 手もこちらも慣れているいつもの報告のような「軽い場」であれば、 「すみません、準備不足でした」くらいの対応で済みますが、「重い場」になるとこうもいきません。

最も悪い対応は、嘘や適当なでまかせでその場を逃れようとすることです。これは非常にリスクの高いやり方です。仮にその場を逃れら れたとしても、その嘘を真実にするために、プロジェクトには多大な 負荷がかかることになります。それが嘘であることに気づく人がいな いとも限りません。基本的に嘘はNG です。「あれは自分の主観的な 意見でした」「勘違いでした」などといった言い訳は通じません。そ れをそうと言わずにあたかも事実のように話したこと自体が問題であ り、信用を失わせることです。「勘違い」や「思い違い」であればそ もそもの基本的な能力を疑われることになります。

厳しい質問が飛んできた場合には、まずは時間稼ぎです。相手の質 問を自分の言葉に言い換えて確認してみたり、相手の使っている言葉 の意味を確認してみたりして時間を稼ぎ、その間にフルに頭を回転さ せます。2 人で説明しているような場合であれば、まずはそのパート ナーにバトンタッチしてみるという手もあります。もちろん、「困っ た質問がきたら、とりあえずはお前にふるからな」と事前に示し合わ せておくことは必要ですが。パートナーが四苦八苦している間にも頭 を回転させてうまい落としどころを探ります。パートナーは時間稼ぎ の役割ですが、もちろんここでうまい回答が見つかれば御の字です。

では、それでも厳しければどうすればよいでしょうか。解なしの状 況なので、解を探すことをあきらめるしかありません。目的を「解を 探す」ことから「この場を失敗の場にさせない」ことにすっぱりと切 り替え、「上司を連れてくる」あるいは「調査してくる」などと言っ て次の機会を確保することに全力を尽くすことです。

★困ったときの掟！突然の方針転換に驚かされないため には情報の流れに気をつけること

【弁田君のプロマネ日記】

プロジェクト全体から見ればまだそれほど大きな問題にはなってい ないのですが、弁田君がここのところずっと気になっている遅延の 問題がありました。ある機能を開発するタスクが3 週間ほど前から 遅延し、なかなか回復できていないのです。当初はすぐに回復できるというメンバーの話だったのですが、昨日受けた報告では、それも難 しくなっているとのことです。遅延は回復どころか拡大の傾向を見せ ています。本来であれば、こうなる前に弁田君がメンバーから直に話 を聞けばよかったのですが、マネジャーの仕事は多忙です。報告内容 をそのまま信じてしまうことの危険性は重々承知していたつもりです が、忙しさにかまけて、ついつい楽観的な判断をしていたのです。

弁田君の対応が鈍かったのは、顧客の反応にも一つの原因がありま した。遅延の状況は毎週の定例会で顧客にも報告していたのですが、 特に顧客からの指摘や改善要望は出ていなかったのです。全体から見 ればまだ順調と言える状態だったので、顧客も特に厳しく指摘する必 要はないと考えていたのかもしれません。遅延を報告しても、お決ま りの確認の言葉を口にするだけで、少しも弁田君にプレッシャーをか ける様子はありませんでした。

ところがその顧客が急に当該の機能の遅延について状況を確認して きたのです。これまで定例会の席でも、弁田君の報告を興味なさげに 聞いていた当の担当者が、わざわざ電話をかけて弁田君に現在の進捗 状況を確認してきたのです。

弁田君がこれまで定例会で報告していた通りの説明をすると、「そ れでは困る」と強い調子で返事が返ってきました。「なんとしてでも 計画通りに仕上げてもらわなければ困る」とのことです。これには弁 田君も困ってしまいました。この件は、マスタースケジュールに影響 することでもないので、リスケをして改めて対策を打つということで、 口頭ベースとはいえ顧客と一度は合意が取れていたはずです。それが 今ではリスケは困る！の一点張りです。「リスケの件は合意していた だいたはずでは…」と切り出すと、顧客のテンションはさらに上がり そうになりました。弁田君はすぐさま余計な主張や言い訳は打ち切り、 「何とか考えてみます」と答えることでその場を収め、電話を切りま した。

いったい何が起きたのでしょうか。昨日までOK だったものが急 に今日になってNG になってしまいました。考えられるのは、顧客 の社内で、その担当者の手の届かないところで、何らかの決定が下さ れたのだろうということだけです。それにしてもなぜこれほど急な決 定なのでしょうか。おそらく顧客内部で双方向の情報の流れが滞って いたのでしょう。それが何かの拍子に伝わってしまったということで す。しかしそんな理屈を考えていても、今のこの現状の問題解決につ ながるわけではありません。弁田君、これから発生するだろう「クレー ム対応」のことを考えると気分も滅入りがちです。

☆対応の極意！顧客内部の情報経路を 信じてはいけない

顧客の担当者に説明したからといって安心してはいけません。説明 して納得してもらったからといって安心してはいけません。担当者に 説明したからといって、担当者の上司に説明したことにはなりません。 キーパーソンに説明したことにもなりません。顧客内部の情報経路を 信じてはいけません。「弁田君の例」では単なる情報流通に関する認 識の甘さが根本原因にあったようですが、現実には情報の流れを「せ き止める」動きがあることもあります。より一層困難な状態です。 「きちんと貴社の中で情報を上まで上げてください」と担当者に念 を押しても、なかなかこちらが想定した通りには顧客の内部では情報は流通しないものです。担当者にはじっくりと説明したつもりでも、 担当者があまりにも忙しければ、あるいは担当者のモチベーションが 低ければ、あるいは担当者の考えとは相容れないところがあれば、あ るいは担当者の立場を悪くする可能性のあるものであれば、顧客内部 での十分な情報共有がなされません。単なる言葉のワンフレーズだけ が一人歩きしてしまい、かえって顧客の上層部に誤解を与えるような 結果になるのがオチです。もちろん、いったん与えた誤解をスタート 地点まで巻き戻すのには、相当の労力が必要とされます。

伝言ゲームでは「きちんと伝えよう」と思っていても誤って伝わっ てしまうものです。ましてやその情報の中に自分の立場を危うくする ような、あるいは自分の価値観とは相容れない内容が含まれていれば、 それがどのように顧客の中で流れていくかは容易に想像がつくという ものです。顧客内部でコンセンサスを取ってほしいような情報を担当 者一人に伝える場合は、こうした力学には十分注意しなければなりま せん。担当者は容易に情報の取捨選択を行い、都合の良い情報ばかり を流すことも可能なのです。悪意がなくても、情報の重要度の判断を 誤ることは十分に考えられます。何が重要で何が重要でないかは、立 場や役割によって大きく変わってきますが、ここをきちんと理解して 担当者が社内に情報を流してくれるかどうかはわからないのです。

☆対応の極意！情報を流すためには ポンプが必要である

情報の流れが極端に悪い組織というものが存在します。これは官僚 的な組織に多いようです。「絶対に必要と思われる情報しか流さない」 ような組織です。システム開発のプロジェクトの成否の鍵はコミュニ ケーションにかかっていると言っても言い過ぎではありませんが、そ の鍵が壊れているような組織です。プロジェクトにおける基本スタン スは「必要かもしれない情報もすべて共有する」であるべきですが、 このような組織では「不要かもしれない情報はすべて隠蔽する」とい うものです。

ガチガチに官僚的な組織でシステム開発プロジェクトを進めていく のはなかなか難しいことですが、その一つが情報共有の難しさです。 特に情報というものは権限や権力との結びつきが非常に強いものなの で、これを握っておいて他に与えないということで、自らの力を強化 あるいは維持するというインセンティブが働きます。ここを打ち壊す ためには、いえ、少なくともプロジェクトを効果的に運営するに十分 な程度に壊すためには、単なる顧客への「依頼」だけでは絶対的に不 十分です。目に見える形で情報が流通する仕組みを作らなければなり ません。

例えば議事録であれば、「必要な箇所を抜き出して情報共有する」 のではなく、「共有すると問題のある箇所だけを削除して、あとはす べてを共有する」という方針に変えることです。その取捨選択の判断 基準はマネジャーの主観などではなく、きっちりと誰もが客観的に判 断できるように明示しておくことです。そしていつまでに誰が参照で きるようになっているべきなのかを、きちんと決めておくことです。

顧客の生の声が聞けるような課題解決のための会議であれば、プロ グラマを含めて積極的に開発現場の人間を、定期的にとまでは言わな いまでも、積極的に参加させることです。ここも任意ではなく、きっ ちりとタスク化してスケジュールに組み込んでしまうべきです。情報 というものは放っておいただけで水のように浸透するものではありま せん。そこには労力を伴った積極的な関与が必要とされるのです。

☆対応の極意！半年前に聞いたことが今も 生きていると思い込まないこと

プロジェクトを取り巻く状況は刻々と変化していきます。環境の変 化は当然、システムの目的の変化につながり、それはシステム仕様の 変化へとつながります。両者合意で確定したはずのシステム仕様がい つまで経っても安定せず、コーディングに入っても、場合によっては テストフェーズに入ってもその変更要求が絶えないのはいつもの光景 です。マネジメントや要求定義のスキルが原因でこうした問題が発生 することもありますが、どれほど優秀な担当者が作業に当たっても、 こうした変更要求を根絶することは不可能です。変更は必ず発生する ものとして、それを前提としてプロジェクトの計画を立て、実行して いく必要があります。

さて、その変更についてです。各種の変更がプロジェクトの負荷に なることは間違いありませんが、その負荷を軽減するためには、でき るだけ早期にベンダがその変更内容を把握しておく必要があります。 ベンダへの伝達が、変更発生から遅れれば遅れるほど、プロジェクト への影響は大きくなります。このことは多くの顧客の担当者も理解し ています。大抵の顧客は変更の可能性があれば、まだ上層部で決定に 至る前でもベンダ側にその可能性を伝えてきてくれるものです。逆に ベンダ側も何か変更があればすぐに伝えてくれるだろうと思っています。

ここで「認識」が重要なポイントになります。顧客の担当者が変更 可能性をベンダ側に早期に伝えようとするのは、そのプロジェクトへ の影響を理解し、認識しているからです。もしもその認識がなければ ベンダ側への伝達も遅れてしまうでしょう。環境変化と、それがプロ ジェクトに与える影響について、顧客の頭の中でつながりがなければ、 重要な変更情報が自発的に顧客からベンダに伝えられることはありま せん。ここにリスクがあります。「何を伝えて何を伝えないか」の判 断が、完全に顧客に委ねられているのです。プロジェクトに影響を及 ぼす本当に重要な情報が何であるかを詳細に把握しているのはベンダ です。しかし伝達情報の取捨選択を行っているのは（構造的に当然で すが）顧客です。ベンダはこのリスクを何とかしなければなりません。

顧客の担当者がシステム開発の経験が浅い場合は、特に注意が必要 です。なぜならば、環境変化とそれが及ぼすプロジェクトへの影響に ついて、両者の結びつきが頭の中であまりできていないからです。画 面レイアウトの変更くらいであれば、「これはベンダに伝えなきゃ」 とすぐに気づくでしょう。しかしもう少し抽象度が上がってくると話 は別です。

例えば、業務のあるべき論を追及し、あるべき姿を実現するために スタートしたはずのプロジェクトが、経営状況の悪化によって急にコ ストが目的の中心になってくるような場合です。当初は顧客上層部の 中だけでの話であり、特にシステム仕様を変更するような「手段」の 話は出てきません。「早期にベンダに伝えるべき内容」という認識が 非常に薄い状態です。仮にこの話が担当者レベルのところまで落ちて きたとしても、この変更がプロジェクトに与える影響を当の担当者が 理解していなければ、早期にベンダに伝えるべきだという認識すら持 つことができません。

ベンダは顧客の担当者の認識レベルを把握し、何を伝えてくれて、 何を伝えてくれないか、どのレベルの情報であれば伝えてくれて、ど のレベルの情報は伝えてくれないか、についてある程度想定しておく ことが必要です。そして枝葉はともかく、プロジェクトの幹となるよ うな前提条件や決定事項については、折々に顧客に確認を取っていく必要があります。

決定事項が変更になることはよくあることですし、それがベンダに 伝わらないこともよくあることです。「聞いていないからやりません」 と契約を盾に却下するのは最終手段です。その前にまずは心構えです。 半年前に聞いたことが、今も生きていると思い込まないことです。プ ロジェクトを取り巻く環境はもちろんですが、「人の考えは自然に変 わっていくもの」くらいの感覚をもって、積極的に「情報の更新」に 臨むことが重要です。

★困ったときの掟！あら探しが得意な顧客にプレゼンしなければならない！〜ツッコミを誘導するおとりを準備してお くこと

【弁田君のプロマネ日記】

「見てください」というので弁田君がレビューをしてみると、なるほ ど悪くはないのですが、「キレ」がないというか、何か一つピンとく るものがありません。これといった問題は見当たらないのですが、単にテンプレートに埋め込んでいっただけの「無機質感」があるのです。

弁田君「結局、これは何が言いたいのかな？」

後輩君「何がといいますと？定例の報告書なのですが…」

弁田君「いや、要するに、その報告で顧客が知りたいことは何か、を意識しながら書いたのか？ということだ」

後輩君「……」

弁田君「報告書を書くのであれば、まずはその報告に対する顧客のニーズを考えないといけないし、プレゼンをするのであれば、プレゼンに対する顧客の評価基準を考えないといけないよ」

後輩君「確かにそういう視点は意識していませんでした」

弁田君と後輩君は、あらためて顧客の立場に立ってその報告書をレ ビューすることにしました。第三者が見れば、特にこれといった問題 もなく、合格点は十分にあげられる出来だと思われます。しかし顧客 のニーズという観点で見直すと、内容が発散して、言いたいことが絞 りきれていない感は否めません。弁田君は一通りポイントを指摘する と、明日までの宿題として後輩君に修正してくるように指示しました。

翌日、弁田君は再度後輩君の報告書をレビューしました。以前のも のと比べると随分と進歩しています。しかしドキュメントというもの の宿命でしょうか。どれほど完璧に思えたドキュメントでも、あらさ がしをしようと思えば不備や不明な点はいくつか見つかるものです。 弁田君もすぐに弱い箇所を何点か指摘することができました。

すると後輩君は「あっ、そうですね」と言ってすぐに直そうとします。 ここで弁田君はその手をストップさせます。

弁田君
「おっと、直すのはもう少し考えてからにした方がいいぞ」

後輩君
「えっ、どうしてですか。またツッコミを入れられるだけですよ」

弁田君
「まぁ、それはそうだが、どんなに完璧に作ろうとしてもどこかに“あら”は絶対に残るもんだ」

後輩君
「それは仕方ありません。無限に時間をかけられるわけはありませんから」

弁田君
「どうせ指摘されるなら、最初から指摘されるところを作っておくという手もある」

後輩君
「えっ、どういうことですか」

弁田君
「わざとツッコミやすそうなところを残しておいて、ツッコミをそこに集中させるんだ。そしてその部分だけに集中して質疑応答をあらかじめよく考えておくんだ」

果たして実際の定例報告では見事にこの作戦が功を奏しました。顧 客の中にいた「あらさがし担当大臣」は見事にこちらが作った“あら” を逐一指摘してくれました。もちろん、想定していた質疑応答だけでは 対応できないツッコミもありましたが、それでも後輩君、唐突に他の 部分を指摘されるよりはずっと落ち着いて対応することができました。

☆対応の極意！プレゼン資料は顧客の判断基準を 意識して作成すること

下手な営業は自分の「売りたい」という気持ちばかりが前面に出て しまって失敗します。「結局は自分が売りたいだけだろ」という顧客 の心理的な反発につながってしまうのです。プレゼン資料もいわば営 業ツールのようなものなので、同じような心理で作成すると似たよう な反応を引き出してしまいかねません。確かに、プレゼン資料を作成 する場合には、どうしてもこちらが言いたい事が先走ってしまいます。 「これをわかってください。あなたのためになるはずです」となって しまいます。しかしこれが顧客にはなかなか響かないのです。

よく聞かれるアドバイスが「顧客のニーズを意識しろ」というもの です。これは確かに間違ってはいないのですが、当たり前すぎて、そ して言っていることが大雑把すぎて、具体的にどのようなアクション につなげていったらよいのかがわかりません。そもそも顧客のニーズ は資料作成における重要なインプットの一つであり、これを外した資 料などというものは考えられません。

重要なのは顧客がプレゼンを判断するときの基準です。資料の作成 にあたっては、顧客が何を判断基準にしてプレゼンを評価するのかを 考えることです。こちらが訴えたいことやわかってもらいたいことも 確かに重要ですが、それ以上に顧客の聞きたいことは何か、顧客の判 断基準は何か、を考えることです。どれほど自社が誇り、あるいは 強みに思っている技術やサービスでも、顧客が関心を持ってくれる とは限りません。自社の強みが何であるかは、この際関係ないのです。 それを顧客のメリットや関心にどれだけつなげられるかが重要なのです。

顧客の中期計画を入手しているでしょうか。概要だけでも聞き出そ うとしているでしょうか。キーパーソンがやりたいと思っていること を知っているでしょうか。それについてヒアリングをしてみたことは あるでしょうか。様々な評価基準の優先順位について、探りを入れて いるでしょうか。顧客のニーズを把握するのは基本中の基本です。そ こから一歩進んで、「今回のプレゼンが何で評価されるのか」を意識 しながら資料を作成することが大切です。

☆対応の極意！プレゼンでは一つのポイントに 絞り込むこと

システム開発には多くの費用がかかるものです。そしていったんリ リースされてしまうと、追加や変更のたびに少なからぬ費用がかかる ものです。いきおい顧客は今回の開発期間中に、できるだけ多くの 機能を盛り込もうとするものです。しかしスコープに対するルーズな 感覚はリソース不足を招きます。全体のリソースに限りがあるところ にたくさんの機能を詰め込もうとするために、一つの機能あたりに費 やすことができるリソースが少なくなってしまうのです。かくして、 「あればよい」程度の機能だけでなく、最重要の機能までもがこの影響を被ることになります。まったくメリハリのない状態です。

プレゼンも同様です。限られた時間内に欲張って多くの内容を詰め 込もうとすると、一つ一つのテーマの内容が薄くなってしまいます。 本当に顧客の心に印象を残そうとするのであれば、重要なポイントを 一つに絞り込むことです。あれもこれもと詰め込んでも、顧客の頭に 残らないばかりか、場合によっては「調子のいいことばかり言ってい る」という印象を持たれかねません。

プレゼンで一つのポイントに絞り込むと、メッセージが顧客の頭に 強く残るものです。顧客が本当に必要としているもの、本当に関心が もっているものをリサーチし、一点に絞ってアピールするのです。こ れによって強いメッセージを残せるばかりか、プライオリティの存在 を顧客の頭しっかりと残すことにもつながります。つまり「今回はこ れが重要なので、そのほかはあきらめてください」と正々堂々と主張 することができる基盤を築くことができるのです。

☆対応の極意！プレゼン用の資料はあえて不完全な仕上がりにしておくこともある

プレゼンの場において聞く側の立場の人間は、特に内容に不満がな くても「何か一つは突っ込んでやろう」と待ち構えているものです。 それが仕事という面もあります。内容に不満があれば尚更のことであ り、今後の事業に関わる重要なテーマであればさらにその傾向は強く なります。重要なプレゼンになると、受けて立つ側も必死です。徹底 的に想定される質問を洗い出し、それぞれの質問に対する回答を徹夜で準備します。

一つのテクニックとしては、プレゼンの中に「突っ込みやすいとこ ろ」をわざと何点か入れておくことです。瑕 か 疵 し をわざと混入させてお くのです。もちろん、あからさまな資料の欠陥はかえってこちら側 の能力を疑われることになるのでそのあたりのバランス感覚は必要で す。ただし、この「突っ込みどころ」をあらかじめ入れておくのは、 想定外の質問を避けるための、あるいは他の弱点に気づかせないため のかなり有効な戦術です。顧客の注意をこちら側が準備した「突っ込 みどころ」に集めてしまうのです。

「おとり」と言っては喩えが良くないですが、本質ではないところ でも「どこかケチをつけてやろう」と狙っている相手にはちょうどよ い対策です。ただし、このようなテクニックを使ってもよい状況と、 使うべきではない状況があるのは当然のことです。本当に“あら”を なくし、完璧を目指すべきドキュメントがあることも事実です。駆け 引きにも許される状況と許されない状況があることくらいはわきまえ ておかなければなりません。

★困ったときの掟！正論をストレートに通そうとすること自体が難しい

【弁田君のプロマネ日記】

弁田君が以前率いていたプロジェクトチームに、少々癖のあるメン バーが一人いました。彼についてはあらかじめ上司や先輩から、「仕 事はできるけど使いづらいかもしれないぞ」と話には聞いていました が、弁田君はそれほど不安には思っていませんでした。弁田君はこれ までも「要注意人物」と呼ばれるメンバーと一緒に仕事をしたことが あるのですが、弁田君との間に限っては特にトラブルを起こすことも なく、まったく普通に付き合うことができたからです。弁田君はいい 意味で「人に期待しない」ようなところがあり、それが関係に良い影 響を及ぼしていたのかもしれません。

プロジェクトが始まると、なるほど上司や先輩の言うことの意味が わかるような気がしました。確かに仕事はできそうです。論理的な思 考はできますし、決断も早く、与えられた作業もてきぱきとこなして いきます。しかしあくが強いというか、自己主張が強いというか、確 かに「癖」を感じます。ちょっと顧客の前に出すのはためらわれるタ イプです。常に自分が正しいと信じ込んでいるところがあり、いった ん信じたことについては、周囲の空気を読んで行動するということが できないのです。正論を押し通してしまうのです。だからといって彼 にチーム内の作業だけに閉じ込めてしまうわけにはいきません。年齢 的にも経験的にも社内ポジション的にも、彼にはそろそろリーダー的な役割が期待されているのです。上司からも「できればリーダーとし て育ててほしい」というリクエストももらっています。

ということで、弁田君は思いきって彼をチームリーダーに任命して いたのですが、顧客からの評判は案の定あまり芳(かんば)しいもの ではありません。彼が顧客と接する場には弁田君も極力同席して、な るべく彼の癖が前面に出ないように配慮をしていたのですが、それで も顧客受けはよくありません。ただしそれでも弁田君は「問題ない」 と判断していました。少なくとも仕事の結果は出していたからです。 顧客もこの点は認めてくれています。「仕事はやってくれているんだ けど…」といった評価です。もちろん現状を放置していたわけではあ りません。顧客とのコミュニケーションの取り方や、説明や説得の仕 方、場の雰囲気の重要性、感情を抑えることの重要性などについて、 折を見つけては彼に教育していました。もっとも、その効果のほどは 疑問だったのですが。

彼の問題点については、弁田君の日々の顧客フォローによって、 プロジェクトではそれほど大きな問題にはなっていませんでした。 「ちょっと変わったチームリーダー」と見られていたくらいです。こ れには顧客の担当者が大人だったということもあります。顧客は個人 的な好き嫌いを仕事に持ち込むことはしないタイプだったのです。弁 田君が恐縮していると、苦笑いしながらも「最低限、結果を出してく れればいいよ」と、大目に見てもらっていたのです。弁田君もそういっ た顧客の対応に少々甘えていたところもありました。

問題になったのは、顧客の担当者が異動になった時のことです。新 しく入ってきた担当者が大人の対応ができるようなタイプではなく、 問題の彼と真正面からぶつかってしまうようなタイプだったのです。 懸念はしていたのですが案の定、問題はすぐに発生しました。新しい 担当者は彼の「癖」を敏感に察したのか、初めから彼を拒絶するモー ドに入っています。

定例報告などではまずはあら探しから始まります。問題の彼がどれ ほど仕事ができるといっても、完璧ではありません。小さなミスはあ ります。その重箱の隅を、あたかも重要な問題であるかのように指摘 してくるのです。そのような指摘を受けてしまうと、彼も彼で我慢す ることはありません。自らが感じている嫌悪感を隠そうともしません。 やがて当然のように、彼が率いているチームの成果は目に見えて落ち ていきました。

事件が起こったのは設計書の顧客レビューの場面です。ここで最終 的な画面仕様の確認を行っていたのですが、顧客から一部の表示項目 が不足しているとの指摘がありました。しかし、指摘の点は以前から 検討課題として顧客とも共有していたところです。弁田君も彼もここ は重要なポイントだと踏まえ、慎重に検討を進め、顧客と合意の上で 要件を固めたつもりでした。それが一転、その合意を翻すような指摘 です。

もっとも、このような出来事はよくあることです。こういったケー スでは相手の気持ちを考えながら丁寧に説明すれば、ほとんどの顧客 は（しぶしぶでも）わかってもらえるものです。しかし顧客と彼の関 係は既に相当冷たいものになっていました。

顧客との合意を心配した弁田君は、事前に「正論は控えろ」と言っ ておいたのですが、いざ打ち合わせになると、彼は最初から見事な正 論を展開していきます。最初から不機嫌そうな顧客の顔はさらに不機 嫌になっていきます。彼はおかまいなしに正論を主張し続けています。 前提条件から合意に至った経緯から理詰めで説明していきます。あか らさまには言いませんが、その口調からは「私は正しい、あなたは間違っている。だからあなたは私の言うことに従うべきだ」というよう なニュアンスが強く感じられます。弁田君、彼の話を時々遮ろうとす るのですが、それでも彼は気づきません。「やばい」と思った弁田君 は強制的に彼の話を中断させようと思ったのですが、その判断は一瞬 遅かったようです。顧客はキレ気味に一言。「そうですか。要するに あなたが言いたいことは、あなたが正しくて私が間違っているという ことですね。なるほど、よくわかりました」。

さすがの彼もここで「そうです」とは言えずに黙っています。弁田 君もすぐに「そんなことはありません」などと、軽々しくその場を取 り繕うような言葉は吐けないような雰囲気です。

☆対応の極意！正論で顧客を納得させようとしてはいけない

議論の対象が事実であれ何であれ、「間違いなくこちらが正しい」 とわかる場合があります。誰もが納得せざるをえないようなロジック や、誰もが認めざるを得ないような証拠を手にすることがあります。 ここで最悪の行動は、鬼の首を取ったかのごとく、正論で顧客を論破 しようとすることです。次に良くないのは、手にした正論で顧客を納 得させようとすることです。

すべての意思決定や要決定事項が客観的な事実で決まっていくもの であれば、そうした強引なやり方ももしかすると通用するかもしれま せん。しかし残念ながらシステム開発における決定事項は、すべてが 事実によって機械的に導かれるものではありません。むしろ現実には そうした決定の方が少ないものです。多くは（後からよく考えてみれ ば）推測や気まぐれや個人的価値観によって決められていくのです。 このような世界において、顧客の感情は重要な位置を占めることにな ります。正論を無理やり通したとしても、得られるものよりも失うも のの方が圧倒的に大きいのです。

正論で顧客を納得させようとしてはいけません。こちら側の正論が 通るということは、向こう側が間違っていたということになります。 これまで散々意見を主張しあってきたのに、急に「私が間違っていま した」などと、笑顔で自らの誤りを受け入れてくれるような「できた」 人間はそうはいないものです。真正面から「あなたは間違っている」 と言われて心穏やかでいられる人間はそうそういません。しかもそこ が相手の価値観やこだわりに触れるようなところであれば尚更です。 少々大げさな物言いになってしまいますが、どんな正論でも相手のプ ライドを傷つけるような結果につながるのであれば、それは決して受け入れられることはないということです。

ただしこれは、正論を通すなと言っているわけではありません。通 さなければならない正論は通さなければなりません。正論は主張すべ きではないとは言いつつも、それは正論が必要ないというわけではあ りません。ただ、それを顧客の感情を害してまで、無闇に表に出して はいけないということです。通すための工夫が必要だということです。 例えばこうした場合には説得をあきらめ、相手が自ら気づいて、自ら 意見を修正したように持っていく必要があります。ヒントを与えつつ、 （場合によっては）こちらはまだ正論のロジックには気づいていない ことを装いつつ、といった高度な綱渡りをしなければなりません。時 間が許されるのであれば、ゆっくりと気づかれずに啓蒙していきたい ところです。

こちら側が望むゴールは「顧客が○○という考えを持っている」と いう状況を作り出すことにあります。正論はそのための単なる手段の 一つにすぎず、必ずしも使用しなければならないものではありません。 こちら側の論理的な正しさを主張するのが目的ではありません。目的 はプロジェクトを成功裏に進めていくための環境を作り出すことで す。誰の影響によって、またどのような原因によって顧客の考えが変 わったとしても、それはどちらでもいいことです。顧客の考えが正し いものに変わってくれさえすればよいのです。そこだけにターゲット を絞って解決策を考えていくべきです。

☆対応の極意！顧客から嫌われると 説得はなかなか難しくなる

　客観的な判断で行われるべき決定事項が、担当者同士の相性や個人 的な好き嫌いで決められてしまってはたまりません。しかしこれが現 実というものです。意思決定の判断において、人間の好き嫌いの影響 を無視することはできません。顧客から極端に嫌われてしまった場合 は、こちらの言っていることの内容がどれほど正しくても、それを顧 客に受け入れてもらうのはかなり難しくなります。本当に顧客のため になる提案でも理解してもらうのは至難の技です。好き嫌いの問題が、 信頼度の問題にすりかわってしまうのです。不条理に思われるかもし れませんが、これは自分自身のことを考えてみれば納得できるでしょ う。人は感情の動物です。物事を決定する際には、この感情というも のが大きなウェイトを占めていることは疑いようもない事実です。

確かに中には「できた」人間もいて、「大嫌いな相手の提案でも内 容が正しければ受け入れる」という人もいるでしょう。「仕事におけ る判断に、個人的な好き嫌いは持ち込まない」という人もいるでしょ う。それはそれで立派なことなのですが、ベンダが顧客の「立派なと ころ」に頼って仕事をしてはいけません。もちろん顧客の全員が立派 であるわけでもありません。ここで「個人的感情と仕事は切り離して 考えるべきだ」という「あるべき論」をかざしても意味はありません。 あるべき論から遠い世界にいる顧客でも、それが現実というものです。 変わるべきなのは顧客ではなく、あくまでこちら側なのです。

☆対応の極意！極意 ただし顧客に好かれることを 一番に考えてはいけない

顧客に好かれていると様々な提案も通りやすくなるものです。した がって顧客に好かれるための戦略は悪い戦略ではありません。顧客か ら嫌われてしまうと説得は難しくなりますし、顧客から好かれている に越したことはありません。しかし顧客からの好感度が一番というわけではありません。一番に考えるべきことは「いかに顧客から信頼を 獲得するか」ということです。好感度は重要ですが、それ以上に顧客 からの信用や信頼の方に重きを置くべきでしょう。人の好き嫌いは時 とともに変わっていく可能性がありますが、顧客からの信用は一度定 まってしまうと、それが変わることはほとんどないのです。失った信 用を回復するのは、嫌われた相手から好きになってもらうよりもはる かに困難です。

重要な情報は嫌われることを覚悟してでも顧客に伝えなければなり ません。本当にプロジェクトのために必要なのであれば、顧客の耳に 痛いことも正直に伝えていかなければなりません。一番恐れるべきこ とは、顧客からの好感度を落とすことではなく、顧客からの信用を落 とすことです。

★困ったときの掟！決定事項を「最終決定事項」と勝手に思い込まないこと

【弁田君のプロマネ日記】

顧客が現在のプロジェクトの体制に、新たにPMO（Project Management Office：プロジェクト支援部門）を設置しようとし ていることは弁田君も知っていました。実際に、顧客の担当者からも 弁田君に相談がありました。確かに現在のプロジェクトの状況は良い とは言えませんが、それはPMO を置いたから解決するような単純 なものではないことは弁田君にはわかっていました。ところが顧客 はPMO を設置しさえすれば問題は解決するくらいの安易な認識しか 持っていないようです。弁田君はそこに危険な臭いを感じ取っていま した。つまりPMO がプロジェクトに貢献するどころが、逆に現場の オーバーヘッドを増やしてしまい、さらにプロジェクトが危機にさら されるのではないかと考えていたのです。

顧客の担当者の話では「まだアイデア」程度とのことだったので、 まだまだ決定は先の話だと弁田君は思っていました。話が本格化して きたら真剣に反対しようと思っていました。ところが、弁田君が休日 を取っていた短い間に、PMO の設置が顧客の中で正式決定されてし まったのです。まだまだだと思っていたところ、実はかなり話が進ん でいたようです。弁田君は「しまった」とほぞをかみましたが、決まっ てしまったことは仕方ありません。

しかし納得がいかない弁田君は顧客の担当者に決定の経緯を聞いて みました。すると弁田君が理解していたスピード感はそれほど間違っ てはいないことがわかりました。顧客の担当者自身も急な決定に驚い ているとのことです。普段はプロジェクトにほとんど関与していない のですが、たまたま顧客の部長がPMO の話を伝え聞いて、「それは いい」とその場で「GO 」の決定を下してしまったとのことです。

聞けば聞くほど危険な臭いがします。単純に、進捗が思わしくない から進捗PMO 、品質が思わしくないから品質PMO を置くというの ですが、詳しく聞いてみると権限もなく、現場から離れて長い年月が 経っている「おじいちゃん」が担当になる見込みとのことです。しか もこの「おじいちゃん」、とてもやる気で今から「報告は毎日あげさ せる」と息巻いているらしいのです。弁田君は確信しました。これは 間違いなく現場のオーバーヘッドになるだけで、進捗にも品質にも逆 効果にしかなりません。プロジェクトにとっていいことは一つもあり ません。大変なことになりそうです。弁田君は早々に先輩に相談して みました。

弁田君
「これからどうやってプロジェクトを回していけばいいのでしょうか。PMO はやる気満々なんですが、はっきり言ってプロジェクト管理については素人なんです。このPMO 対策が必要だと思うんですが」

先　輩
「PMO 対策？そんなことしても余計にパワーを使ってしまうだけだよ」

弁田君
「といっても何もしないままではプロジェクトが危なくなってしまうだけです」

先　輩
「そんな決定、ひっくり返せばいいんだよ。顧客の中の誰も乗り気じゃないんだろ？その部長以外は」

弁田君
「まぁ、そうですが、そんなことできるんですか？部長がもうOK を出してしまいましたが」

先　輩
「できるかどうかじゃなくて、やるんだよ」

一度決まったことは従うしかないと思っていた弁田君にはびっく りする先輩の言葉でした。

先　輩
「そんな決定、部長の気まぐれで決まったようなものだろ？だったら部長の顔をつぶさないように気をつけながら、周り で何かロジックを作ってあげて、ひっくり返せばいいんだよ」

弁田君、完全に理解しました。明日、顧客の担当者に相談してみる つもりです。きっと作戦の立案に乗ってくれるに違いありません。

☆対応の極意！決定は偶発的なものである。 最終決定以外はひっくり返すチャンスはある

会議などでいったん決まったことをひっくり返すことは、なかなか 難しいことのように思えます。そのような考えさえ思いつかないかも しれません。しかし何らかの前提条件が成立して初めて意味のある決定だったにもかかわらず、その前提条件が崩れてもなお、その決定 が延々と生き続けるなどということはよくあることです。意味がなく なった過去の決定に縛られて、意味のある活動を行えないとしたら、 それは「意思決定」の本末転倒的な使い方です。もちろんいったん決 まったことを誠実に履行していくのは大切なことです。お互いの信頼 関係にも影響します。しかし本当に意味のある、そして時にはやらな ければならない「ひっくり返し」もあるものです。

さて、決定の場では、その前提条件が明確に俎 そ 上 じょう （まな板の上）に 上げられることはありません。要求の取捨選択や変更修正の取扱いに ついて、逐一明確な基準をもって決定を下してはいません。プロジェ クト計画書はレビューにはかけられるものの、記述内容の根拠を一行 一行逐一確認していくことはしません。何事かが決まった理由は聞け ば出てくるものの、反論の余地を多分に残していることが圧倒的に多 いものです。その決定が妥当なものであることを示すロジックには、 かなりの疑問点と曖昧な点が残されているはずです。現実には、決定 の多くは、実に曖昧かつ怪しげな根拠に基づいてなされているもので す。ある検討事項について、会議の場でどのような結論に至るかは、 その場の偶発的な事象にかなりの程度左右されるということです。

会議室の予約が取れなかった。会議の時間が変更された。キーマン の参加が不可能になった。会議の噂を聞きつけた「あまり関係がない 人」が会議に参加してきた。会議が重要な電話で中断された。中断中 にまったく別の議題で盛り上がった。その日に業界を揺るがすビッグ ニュースがあった。近々人事異動がある予定になっている。会議が延々と続き、皆の集中力が切れてきた…。

このような気まぐれな出来事によって、結論が白から黒に変わって しまうことも稀ではありません。議題が総論から各論へ移り、詳細な 案件が検討される段に至っては、この傾向はさらに強くなります。顧 客の内部でも意見が割れていたり、異なるステークホルダーがそれぞ れ矛盾した要求を出してきたり、といった状況において、決定事項の 正当性や根拠はかなり曖昧なものになっています。誰かがたまたま目 にした雑誌記事や伝え聞いた噂、キーパーソンが突然思い出した過去 の経験などによって、決定が大きく左右されてしまうのです。論理的 に導かれたように思える結論でも、実際には主観や過去の経験、勘や 感情、といったものが大きく作用しているのです。

決定事項の多くには必ずしも強力な論理的裏づけは存在していませ ん。たまたまあるメンバーが会議に遅れたかどうか程度の出来事で結 果が変わってくるのです。これはある決定が本当の最終決定でもない 限り、くつがえすことのできる余地は多分に残されている可能性を示 しています。一度決定されたからといって、議事録に記録されている からといって、あきらめることはありません。別の「場」が設定され れば、別の結論が導かれるかもしれません。ある決定に不都合を感じ たならば、新たな「場」を設けることによって、その決定をくつがえ す動きをすることも可能です。

☆対応の極意！決定して喜んでいてはいけない。 常にひっくり返る可能性を考えること

「ひっくり返し」の可能性があるということは、同時に「ひっくり 返される」可能性もあるということです。会議で決定事項がようやく 決まったからといって喜んでいてはいけません。決定の「場」に注意 する事です。よくある話が、その会議に欠席した人がすでに決まった はずの決定事項にNG を出すようなケースです。顧客に決定を急か したところ、顧客内部で「あの人はいつもこういうことを言っているから大丈夫だろう」などと勝手な判断が行われ、その本人確認のない ままでベンダに決定サインを送ってしまうと、このような事態に陥り ます。

ベンダはその決定事項に基づいて作業を進めてしまいます。決定が 覆ったとき、ベンダに非はありませんから当然顧客を責めてもよいの ですが、だからといって覆った決定が再び基の結論に戻るかどうかは わかりません。往々にして決定事項は覆ったままで、そしてベンダに はスケジュールの延期を認めるなどの補償は一切ないままで、これま で通りの計画通りのプロジェクトの遂行を求められるものです。「私 は正しい」と主張しても意味がないのです。

顧客から「決定しました」という情報をもらって油断してはいけま せん。決定事項というものは想像以上に簡単にひっくり返るものです。 「本当に大丈夫ですか」「最終決定ということでよいのですよね」と念 を押したところで、その決定事項の本当の信頼性が高まるわけではあ りません。せいぜい心の不安が解消される程度のものです。決定事項 と言えども言葉の解釈の問題にまで持ち込まれてしまうと、有効性は あっという間に失われてしまいます。「顧客はあのように言っている が、もしもひっくり返ったらどうするか」といったリスクは、あくま で自ら引き受けていく心構えが大切です。

★困ったときの掟！場を読んで効率的にプロジェクトを回 していくこと

【弁田君のプロマネ日記】

プロジェクトマネジャーにもなると、現場の作業を100 パーセン ト見ているわけにもいかず、様々な割り込み作業が入ってくるもので す。それでも現場主義をモットーとしている弁田君としては、できる 限り現場に接している時間を長くしようとしているのですが、やはり 時間は限られています。面倒くさい各種の事務作業や管理作業もこな していかなければなりません。最低限の現場確認程度のフォローしか できない日も珍しくはありません。

なかなか時間が取れない弁田君でしたが、久々にまとまった時間が 取れたので、この機をチャンスとばかりに、たまりにたまったドキュ メントにひととおり目を通しておこうと考えました。こうしてドキュ メントの確認を進めていくうちに、だんだんと不安になってきました。 レビューを通しておくべき人間にきちんとレビューを通しているの か、という不安です。弁田君は早速担当のSE を呼んで確認しました。

弁田君
「この部分だけど、○○部のシステムと連携を取らなければな らないところだよね」

担当者
「そうです」 弁田君「ちゃんと向こうの担当者に話を通している？」

担当者
「いえ、お客さんに聞いたところ、連携はお客さんの方で考えるからいいとのことです」

弁田君
「そうか…」

それでも弁田君の不安は解消されません。これまで幾度となく、こ のような場面で納得してしまい、痛い目にあってきています。顧客の 担当者にも弁田君が自ら足を運んで確認することにしました。

弁田君
「この部分ですけど、○○部のシステムとは調整がすんでいますか？」

顧　客
「あぁ、そこは放っておいて構わないです」

弁田君
「ですが、向こうと連携を取らなければならないところです よね」

顧　客
「そうなんですが、そこはそのまま進めてもらって構いません」

いよいよ弁田君の不安は大きくなってきます。こういった場面でも、 これまで幾度となく痛い目にあってきています。顧客の言葉だからと いって信用はできません。あとでひっくり返ったら、大変なのは弁田君です。

弁田君
「ここの部分ですが、もしも後になってから向こうからNG が出たら、再度設計からやり直しになってしまうリスクがあります」

顧　客
「いいから、大丈夫ですって」

弁田君
「では念のため、私が先方に確認してきてもいいですか」

顧　客
「いいから、余計なことはしないでください。勝手に調整なんかに行かないでくださいよ。面倒になるだけなんだから。そ れからこれは今から言っておきますけど、△△課長には何か聞かれても適当にはぐらかしておいてくださいね。正直な事 を言ってはダメですよ。こっちの課長に聞いてくださいくらいの回答でごまかしておいてください」

プロジェクトのリスク軽減のために提言したはずが、逆に顧客から お叱りをいただいてしまいました。後で聞くところによると、○○部 の△△課長はとにかく話が通じない人で、どうでもよい枝葉にこだわ り、打ち合わせになるといつも膨大な時間が無駄に費やされるとのこ とです。それだけならばまだよい方で、相談ごとはほとんどのケース で「反対」の立場を取るので、これを「了承」にまでこぎつけるため には、多大な労力を要し、待ち時間が発生し、プロジェクトの進捗に まで影響を及ぼすほどだということです。

正直ベースですべてを明らかにして話してしまうと、とんでもない ことになってしまうのだそうです。また、この課長は昨日と今日とで は話の結論が違うことも日常茶飯事だそうです。ですからここは先方 の課長には相談せず、勝手に事後承諾で進めるということだったので す。そしてその勝手な行動は、○○部の部長の暗黙の了解も取りつけ ているから大丈夫だとのことです。

顧客の内部には何があるのかわかりません。顧客対応は本当に難し いとため息をつく弁田君でした。

☆対応の極意！曖昧さを駆使して プロジェクトを進めていくこともある

要件をきっちりと決めていきながら、仕様書の文言は可能な限り一 意になるように記述すること。決定事項は誤解のないように明確な言 葉で表現し、ステークホルダー間で相互に内容を確認すること。これ らは理想論に近いところもあり、厳密に進めていくのは容易ではないのですが、品質の高いシステムを構築していくためには必ず頭に入れ ておかなければならないことです。これらがまったく管理されずに放 置されたままでは、プロジェクトの遂行もシステムの品質も、危機に 瀕することになります。

曖昧さの排除は一種の宗教のようになっています。事実、システム 開発において曖昧さというものはトラブルを引き起こす主要な原因で あり、何が何でも排除すべきものと思われています。確かにコンピュー タに仕事をさせるためには曖昧さを排除しなければなりません。仕様 に曖昧さが残っている状態では、設計は進まず、プログラムを書く こともできません。曖昧さの排除はシステム開発における大昔からの 重要なテーマであり、要求フェーズでも設計フェーズでもそれ以降の フェーズでも、曖昧さを排除するための数多くの手法や技法が開発さ れてきました。

しかしここで大問題があります。この理想論の通りにきっちりとプ ロジェクトを進めていこうとすると、プロジェクトがなかなか前に進 まないのです。プロジェクトというものは多様な価値観を持つ人々が それぞれの利害関係を抱えながら複雑に絡み合っているものであり、 細かな点での齟齬や矛盾などは洗い出したらキリがないような側面を 持っています。プロジェクトの基盤中の基盤である「プロジェクトの 目的」や「システムの目的」といった重要な定義でさえ、よくよく確 認してみるとそれぞれの認識が異なっていたりするものです。

また、個々の要件は「灯台」である「プロジェクトの目的」との整 合性が考慮されて取捨選択されていくべきですが、ステークホルダー 同士の利害が絡むこともあり、なかなか理屈通りには進みません。「声 が大きい人」が感情的になってしまうと、誰も正論で抑えられなくなっ てしまう場合もあります。

プロジェクトに参加しているステークホルダーが皆、論理的で合理 的な判断をする人ばかりであれば何の問題もないのですが、そのよう な「できた人間」はめったにいません。新たに導入されるシステム によって仕事の内容がガラリと変わったり、これまでもっていた既得 権益がどうなるかわからなくなってしまうような人にとっては、プロ ジェクトの理屈だからといって簡単に呑めるものではないでしょう。

要するに、感情を伴う人間同士が複雑に絡み合うプロジェクトでは、 その遂行を完全に合理的に進めていくことはできないのです。仮に個 人的な利害や厄介なしがらみを完全に排除することができれば、プロ ジェクトにとってこれほど理想的な環境はないのですが、それを望む のは難しいでしょう。マネジャーはこれら難しい課題とともにプロ ジェクトを前に進めていかなければならないのです。

ここで、曖昧さというものはプロジェクトを前に進ませるための重 要な方便であることも理解しておくべきです。政治の世界ではよく「玉 虫色の決着」という言葉がよく聞かれますが、まさにそれと同じ決着 方法に対するニーズが、システム開発のプロジェクトでも存在してい るのです。もちろん玉虫色がコンピュータに通じるはずはなく、いず れはそういった曖昧さは完全に取り除かれるべきなのですが、当面の プロジェクトを前に進めるためには難しい決定事項は曖昧にしておい たほうがよいこともあるのです。

例えば実践にあたっては、様々な決定事項や検討事項を「重要要件」 と「キーパーソン」という2 つのキーワードから、あらためてじっく りとプロジェクトを見直してみることが必要です。あるステークホル ダーにとっては「重要な幹」かもしれないが、プロジェクト全体から 考えれば「枝葉」にすぎない要件については、少なくともマネジャー の心の中では「軽く」考えておくべきです。キーパーソン以外のステークホルダーの意見は、表面上はともかく心の中では「軽く」考えてお くべきです。

ただし、これを顧客に対する裏切りと考えてはいけません。マネ ジャーの仕事はプロジェクトを成功に導くことです。プロジェクトを 失敗に陥らせる可能性のあるリスクは極力排除していかなければなり ません。プロジェクトの成功が「全ステークホルダーの満足」にある のならば別ですが、そうでないのであれば、きちんとプライオリティ づけをしてプロジェクトをまわしていく必要があります。そのために は前述のような運営もやむをえないということです。

では、「軽く」考えるとはどういうことでしょうか。それが「プロジェ クトをきっちりと理想論の通りには進めない」という理屈につながっ ていきます。「声の大きい人」が異論を唱えそうな「軽い」議題につ いては、あえて曖昧なままでプロジェクトを進めてしまうということ です。「枝葉」の議題については、決まっていないことや検討しなけ ればならないことがあっても、あえて表面化させずに放置しておくと いうことです。最初のうちから貴重なリソースを「軽い」議題のため に費やすことはせず、まずは重要な議題に重点的にリソースを割り当 てていくことです。

「軽い」議題を軽いままにしておく、すなわち「声の大きい人」が その存在に気づいて会議のテーブルに「軽い」議題を乗せることを防 ぐためには、それなりの工夫が必要になることもあります。具体的に は情報の遮断です。あるいは情報の抽象化です。情報を大枠で伝え て詳細は伝えないということです。あくまで嘘はつくことはせず、概 要レベルの説明や検討で留めておくのです。詳細については、いずれ は検討しなければならなくなりますが、そのために貴重なリソースを 早々に費やしてしまうことは避けなければなりません。

★困ったときの掟！状況に合わせて行動を選択すること

【弁田君のプロマネ日記】

弁田君がプロジェクトマネジャーになる前の話です。弁田君は長い 間、「きっちりとした」リーダーの下について仕事をしていました。 そのリーダーはとにかく何でもドキュメントに残すタイプでした。打 ち合わせの前には、それがどんなに小さなものでもアジェンダを用意 し、打ち合わせの内容は必ず議事録に残しました。相手が議事録を取っ ている場合でも、照合用に必ずこちら側でも取っていました。チーム 内部では毎日ミーティングが開催され、日々の各メンバーの作業状況 や今後の作業予定などが逐一確認されました。こうしたプロジェクト の進め方は確かにオーバーヘッドが高くなります。ただし、弁田君は 長い間そのやり方に染まっていたこともあり、またお互いが現在どん な仕事を抱えているのかがわかるなど、実際の作業上のメリットも感 じていたため、そのやり方については特に疑問などは感じていません でした。顧客からの評判も上々であれば尚更です。

やがて弁田君はそのリーダーの下から独立して、自らチームを引っ 張るリーダーの役を任せられるようになりました。その最初のプロ ジェクトでのことです。以前のリーダーのやり方にすっかり染まって いた弁田君は、同じように「きっちりと」仕事を進めようとしました。 他のチームリーダーがもっと「軽い」やり方で作業を進めていること は知っていましたが、これまでに成功してきたやり方です。顧客から も評価されてきたやり方です。弁田君としては「こっちが王道だ」と いうような思いもありました。

しかしプロジェクトが始まってみると、このやり方のオーバーヘッ ドが思いのほか高いことに気づかされました。プロジェクトの規模が 大きかったために会議が多く、会議に参加するだけで作業時間の多く が取られました。その日の実作業が、アジェンダ作りと会議への参加 と議事録作成だけで埋まってしまうということも、珍しくはありませ ん。プロジェクトマネジャーからは「弁田君のチームは大丈夫か」と 声をかけられましたが、弁田君はその真意を測ることはできず、単に 「大丈夫です」と答えることしかできませんでした。

それから2 週間、弁田君のチームの状況はいよいよ厳しいものに なってきました。弁田君のチームだけが残業時間が飛びぬけているの です。さすがに弁田君も気が気ではなくなってきました。やがて弁田 君はプロジェクトマネジャーから呼ばれました。結論から言うと、弁 田君の「きっちりとした」やり方を見直せとのお達しでした。「顧客 のため」を自認している弁田君としては100 パーセント納得できる 指示ではありませんでしたが、状況が状況なだけに反論はできません。 反論どころか、マネジャーからはさらにショックなことを聞かされま した。今回の指示は顧客からのクレームが発端になっているというの です。顧客曰く、「議事録を取ってもらうために高い金を支払ってい るわけではない」ということです。

まったく同じやり方で進めても顧客からの評価は正反対になること もある。弁田君は「正しい」と信じていたやり方が否定されたことに よってショックを受けると同時に、「ではこれから何を指針に進めて いけばよいのか」という不安感にさいなまれることになりました。し かしこれは「絶対に正しい方法というものはない」という、弁田君にとっては新しい学びでもありました。

☆対応の極意！前回うまくいった方法が 今回うまくいくとは限らない

モノが相手であれば前回うまくいった方法は今回もうまくいくで しょう。だからこそ物理法則が成り立ちます。工学が成り立ちます。 しかしヒトが相手になるとそれはまったく保証されません。ヒトは必 ずしも心理学が教える通りに行動するわけではありません。変わりや すい環境の中で、あるいは新しい情報が次々と発生していく中で、常 に同じ意見や同じ考えを持ち続けてもらうのは、それが同一人物で あっても簡単なことではありません。その変わりやすい意見でさえ、 人が変われば意見そのものから違っているのです。

確かに人は信念や価値観といった「変わりにくいもの」も持ってい ます。しかしそういった「アイデンティティを構成している」ような 重要なものを除いては、複雑で不確実な環境の中で、人の意見や考え というものはとても移ろいやすいものです。以前は通用した方法論が、 同じ顧客に対してでさえ通用するかどうかはわかりません。これが新 しい顧客、初めての顧客であれば尚更のことです。前回通用した顧客 対応の「テクニック」や、前回のプロジェクトで好評だったプロジェ クトの進め方が今回も歓迎されるとは限りません。

「この方法で進めていこう」とあらかじめ決めていたベンダは、ス タート時点でつまずき、うろたえることになります。自分の頭の中で はこれからどうやってプロジェクトを進めていくか、そのイメージが 固まっていたのに土台から崩されていくような感覚です。それが以前 から繰り返し使われてきた進め方であり、これまでの顧客の誰もが理 解を示してきてくれた方法であれば、ベンダは混乱し、当惑してしま うでしょう。

しかしここで、今までずっとうまくいってきた方法が使えないから といって、それを顧客の無知や常識のなさに責任を押しつけてはいけ ません。ましてや、前にうまくいった進め方がまったく理解されなく ても「わかっていない顧客だ」などと怒ってはいけません。プロジェ クトというものは一つとして同じものはありません。仮にこれまでの やり方が9 割方通用するようなプロジェクトであっても、残り1 割に ついてはやり方を変えていかなければなりません。そしてその1 割が プロジェクトの肝であることもあるのです。

☆対応の極意！「ベストプラクティス」は 顧客ごとに異なっている

経験を積んでくると、「この問題にはこの解決策」というように、 ある程度は解法のパターンのようなものが身についてくるものです。 そして成功を重ねていると、あたかもそこにはベストプラクティスが 存在しているような錯覚を覚えてしまいます。自分はそれを「掴んだ」 という感覚にとらわれてしまいます。しかし顧客は皆それぞれ異なっ ていることを思い出さなければなりません。顧客はそれぞれ異なった 常識を持っており、その常識によって同じ提案でも良く見えたり悪く 見えたりするものです。外的な条件がまったく同じでも、企業に根づ いている常識や文化によって、各種の判断は違ってくるものです。「ベ ストプラクティス」であるはずの提案が顧客から却下されてしまった としても、そもそもその「ベストプラクティス」は、単に限られた自 分の経験の中でのみ通用するものにすぎなかったと思うことです。ここで「ベストプラクティス」を守るために、「例外」を処理するため のパラメータを設定しようなどとは思わないことです。

プロジェクトマネジメントに「ベストプラクティス」が存在すると いう考え方は非常に魅力的です。それが存在すれば頭で考えることは 少なくなり、脳はそれを自動的な作業に置き換えることが可能になる からです。しかしプロジェクト管理で「何が普遍的に正しいのか」と いう問いほど、前提を誤った問いもありません。プロジェクトは千差 万別であり、そもそも「これが正しい」という絶対の道は存在しません。

プロジェクトマネジメントは常に未知との闘いです。経験が浅く、 リスクがまったく見えていないマネジャーは、簡単にリスクを現実化 させてしまいます。楽観的に何も考えずに前に進んでいって、プロジェ クトを危機に陥らせてしまいます。一方で、慎重すぎるマネジャーは 顧客の要求について徹底的にリスク調査します。新たに発生した選択 機会について、どちらの道を選ぶべきかを徹底的に調べ上げます。そ れでも完璧な調査は不可能なのでどうしても確信が持てません。様々 なリスクが頭をよぎります。判断ミスによって責められる自分の姿も 思い浮かびます。かくして最終決断が遅れます。これこそプロジェク トマネジメントが突きつけられている現実なのです。

要求定義のチェックポイント４２７（翔泳社）（2004/10/20）

要求定義のエクササイズ１３６（翔泳社）（2006/10/23）

要求定義実践のポイント（秀和システム）（2006/12/21）

顧客対応の掟と極意１５３（翔泳社）（2008/11/5）

PM　Magazine　Vol.004（翔泳社）（2005/11/21）
「今すぐ使える要求定義のチェックポイント作成法」

開発の現場　Vol.006（翔泳社）（2006/10/12）
「要件定義“本番”に備える」

開発の現場　Vol.009（翔泳社）（2007/07/11）
「曖昧さを排除せよ→曖昧さを使いこなせ」

システム開発ジャーナル Vol.1（毎日コミュニケーションズ）（2007/11/29）
「アーキテクトの仕事〜立ち上げ・要件定義」

開発の現場　Vol.012（翔泳社）（2008/4/14）
「顧客との見積り交渉術」

日経コンピュータ　2009年7月8日号（日経BP社）（2009/7/8）
「発注者のプロジェクトマネジメント」

DB Magazine　2010年9月号（翔泳社）（2010/7/24）
「要求定義を上手に乗り切る顧客タイプ／シーン別の対処法」

ThinkIT
「プロジェクト管理基盤」整備のススメ〜対症療法に陥らないために〜
第１回：プロジェクト管理基盤とは何か　（2007/08/10）
第２回：プロジェクト管理の前提条件　（2007/08/17）
第３回：顧客と上司を説得する方法　（2007/08/24）
第４回：個人のスキルの問題をどう解決するか　（2007/08/30）

ITPro
プロマネを独りにさせない方法
システムの現場が求める「サポーター」（2008/06/02）
現場に入り込み、問題の芽を摘む （2008/06/09）
重要なのは目的意識と「人」への理解（2008/06/16）

EnterpriseZine
現場の「困った」を解決する！顧客対応の掟と極意
顧客から要求を迫られた時に知っておくべき対応の掟（2008/11/13）
顧客との話がいつまでも平行線の場合の対処法（2008/12/18）
顧客を怒らせてしまった場合の対応の掟（2009/1/13）