|
なぜ今、「発注側のプロジェクト管理」なのか
工事進行基準の適用が始まった。システム開発における数々のグレーゾーンを排除するために、ベンダにはこれまで以上に高いプロジェクト管理能力が求められることになる。この影響は当然、発注側にも及ぶ。役割分担や要件のグレーゾーンの扱い、仕様変更の扱いなど、これまで発注側の「ごり押し」で通ってきた要求が、（良いか悪いかは別として）簡単には通らなくなってくる可能性が高い。発注側としても、この状況に対応するために、問題定義や要件の明確化およびステークホルダーの調整など、総合的な"上流"の能力を高めていかなければならない。
さて、困難な要件定義が完了したとしよう（※要件定義自体が難題ではあるが、今回のテーマからは外れる）。ここで発注側の仕事は終わりだろうか。あとは進行基準があるのだから、それに則ってベンダがきっちりと仕事を進めてくれるのを待っているだけでよいのだろうか。残念ながら否である。アウトプットや"進行基準"が固められたからといって、建設業界のように「あとはお任せ」にはならない。システム開発における不確実性は、ビル建設の場合とは比べ物にならないくらい高い。ルールができたからといって、もともと困難な作業が簡単になるわけではないのである。
確かにルールが明確になっていれば、計画から逸脱した場合、あるいは仮にプロジェクトが失敗した場合でも、「契約違反」としてベンダを責めることはできる。しかしそこに意味はない。発注側にとっては、システム開発の成功だけが重要なのである。
進行基準の適用はベンダのマネジメント能力を向上させ、プロジェクトの成功率を高めてくれると期待できるかもしれない。しかし「期待」の上にあぐらをかくわけにはいかない。発注側はこれまで通りに、ベンダ管理を実施していかなければならない。否、これまで以上にプロジェクトの状況（＝ベンダの開発状況）に注意を払い、問題があれば積極的に改善要望をあげ、その実施状況や効果を注視していくべきである。その理由は以下の通りである。
- ベンダのパワーが進行基準の適用に割かれることによって、"成果物作成のための実質的な作業"やその管理が手薄になる可能性がある。
- 進行基準の適用にプレッシャーを感じての"にわか勉強のプロジェクト管理"によって、かえって現場が混乱する可能性がある。
- ベンダの意思決定の判断基準において、「進行基準の遵守」が「顧客満足度」よりも（実質的に）上になる可能性がある。
ベンダへのリクエストが不発に終わるパターン
発注側によるプロジェクト管理（＝ベンダへの詳細リクエスト）の最終的な目的は、もちろんシステム開発を成功に導くことにある。スケジュール、スコープ、品質、コストといった各種のプロジェクト目標を、当初の計画通りに達成することである。そのために、発注側が現場の状況、そしてプロジェクト管理の状況を詳細に把握することによって、ベンダが気づかなかった問題の芽を発注側の視点で発見し、ベンダに対して早期の対策立案をリクエストしていくようなアクションを推進していくべきである。
しかし発注側にとって、これを実現するのは口で言うほど簡単なことではない。一般にそれはベンダ側マネジャーの縄張りに踏み込むものであり、契約で明確に謳われていない限り、発注側からはなかなか口を出しにくい領域である。改善の要請どころか、それ以前の実態の把握ですらままならない場合も多い。たとえ実態を把握して改善要望を出したとしても、それが受け入れられるかどうかはベンダ次第である。さらに、対応策が出てきたとしても、それが本当に効果のあるものかどうかは別問題である。
以下、具体的な事例を見てみることにする。
１．現場の開発実態を把握することの困難さ
まずは、ベンダにリクエストを出そうにも、それ以前の状況把握からままならないという状態である。
【事例】
定例会は週に一回開かれていた。ベンダからは作業概況、課題、対策、それに今後の予定といったところが報告されてくる。しかし発注側としてはこの内容に不安を抱いていた。報告を聞く限り、プロジェクトには何の問題もないように思えるのだが、それを疑わせるような事実の断片が見え隠れしていたのである。
例えば、プロジェクト計画書の出来である。ページ数はそこそこあるものの、その内容はほとんどが一般論であり、「今回のプロジェクトだからこそ」といった独自の記述はほとんどなかった。概して粗い内容である。定例会で配布される報告資料も同様に粗い内容であり、先週とほとんど記述が変わらない箇所も多い。課題があっても、その対策の欄には具体的な記述はなかった。
マネジャーの質疑応答も不安を抱かせる要素の一つだった。どんな質問にもよどみなくもっともらしい答が返ってくるのだが、結論は皆一様であり、「問題はない」というものであった。つまり、悪いニュースがベンダから報告されることが皆無なのである。
現場からは、様々な課題や今後の懸念といった話が少しずつ漏れ伝わってきていた。ところがベンダのマネジャーにその話を向けてみても、「問題ありません」とかわされてしまうだけである。現場の担当者が神経質なだけなのか、マネジャーが現場の状況を掴んでいないのか、掴んだ上でひた隠しにしているのか、わからない状況であった。
２．ベンダに改善要望を受け入れてもらうことの困難さ
次に、状況を把握して改善要望を出したとしても、それがなかなか受け入れられないという状態である。
【事例】
報告資料の記述が「薄い」件については何度か改善要望を出しているものの、ベンダ側の動きは鈍いままであった。「どこがダメなのか」「ダメならば具体的な書き方を指示してくれ」とまで言ってくる。要するに発注側の要望をすんなり受け入れる気がないのである。また、受け入れられたと思っても、約束がすっぽかされるのは日常茶飯事であった。ようやく対応してくれたと思ったのもつかの間、しばらくすると元に戻っていることもしばしばであった。
問題を指摘し、問題認識を共有し、改善要望を出しても、なかなか効果的な策が提案されることはなかった。こちらから策を提案しても、そのデメリットばかりが指摘されて、すぐに却下されてしまう。かといってベンダから代案が出てくるわけでもなかった。
発注側はマネジャーの交代を望んでいたが、請負契約の下では、それをベンダに要請することはできない。「プロジェクトの状況が悪い」ということをしつこくベンダの上層部に伝えて、それとなく交代を匂わせることができるだけである。しかしベンダの上層部も、更なる内政干渉を恐れてか、「状況が悪い」という事実でさえも「リカバリ可能」ということで、なかなか認めたがらなかった。
３．改善策によって事態が改善することの困難さ
そして最後に、ようやく出てきた改善策も役に立たないという状態である。
【事例】
プロジェクトに改善の必要性があることをようやくベンダにも認めてもらった。しかしここからが一苦労であった。ベンダからは解決策がなかなか出てこないのである。ようやく出てきたと思ったら、真剣に考えられていないことがすぐに分かるような安易な策ばかりである。
まず、どのプロジェクトでも通用するような一般論の策である。遅延の発生という課題に対しては、「追加資源の投入」あるいは「タスクの並行実施」といった策である。きちんと詳細まで具体化され、本当に実行に移されるならば有効な策となるのだが、具体的なリソースやスケジュールの計画には全く踏み込むことなく、一般論をかざされただけで終わってしまう。
そして「頑張って回復します」という精神論の策である。「残業にてリカバリ」や「休日出勤でリカバリ」といった策である。しかし、これらの策が何ら根本的な課題解決になっていないことは自明である。原因には何ら言及していないのである。やがて同じような課題が再発することは容易に想像できる。
次に、コインの裏返し的な策である。「人が不足している」から「人を投入する」、「品質が悪い」から「品質向上策を打つ」といった「言葉遊び」のような策である。実質的には何も言っていないに等しい。
発注側はベンダの策に疑問を抱きながらも、「これで解決します」と断言されると、それ以上踏み込むことはできなかった。当然、プロジェクトの状況は一向に改善されることはなかった。
ベンダへのリクエストに立ちふさがる2つのハードル
こうした状況に対応するためには、本来であれば、発注側として、以下のようなリクエストを出す必要がある。
- 現状の正しい情報を引き出すために、「曖昧な回答ができないような詳細まで踏み込んだリクエスト」を出す。
- 改善策の策定に動かすために、「改善の必要性を受け入れざるを得ないような事実を根拠とするリクエスト」を出す。
- 策の有効性を高めるために、「改善策の因果関係のロジックを追求するリクエスト」を出す。
ところがいざ実際にこのようなリクエストを投げようとすると、発注側には大きなハードルが立ちはだかる。契約の壁と、発注側スキルの欠如という壁である。
１．契約の壁
契約の壁とは、請負契約の壁を意味する。システム開発における一般的な契約形態である請負契約では、契約に特段の記述がない限り、原則としてプロジェクトの途中でベンダの作業に口出しすることはできない。最終成果物に対してモノを言うことはできるが、その作成過程や中間成果物には口を出すことはできない。定めがない限り、進捗の報告でさえ義務ではない。
とは言うものの、システム開発ではこの解釈は曖昧になっている。契約書に明確な記述がなかったとしても、定例会で発注側がベンダの作業の進捗状況を確認するのは普通の姿である。中間成果物の品質評価を要求することもある。契約にはなかった報告書を作成させることもある。多い少ないはあるが、こうした口出し自体は暗黙の了解になっていると言えるだろう。しかし、法的にはこれらのリクエストには根拠がない。ベンダは断ろうと思えば堂々と断ることができる。
発注側がベンダ作業のブラックボックスにリクエストを出そうとしても、契約を盾に拒否される可能性がある。これが第一のハードルである。
２．発注側スキルの欠如
そもそも発注側は、自前でのシステム開発を（戦略として）放棄したからこそ、請負契約でベンダに依頼している場合がほとんどである。しかしシステム開発スキルの欠如は、ベンダに対するリクエストの質にも影響する。見当外れのリクエストは、単に現場の負荷を重くするだけに終わってしまう。
例えば、進捗報告であるタスクの遅延が報告されたとする。ここで「遅延回復してください」というリクエストは正しいものではあるが、当たり前すぎてプロジェクトにプラスの影響を与えるまでにはいかない。リクエストは、「そうでなければ動かなかったであろうベンダを動かす」ものでなければならない。プロジェクトにプラスの影響を与えるものでなければならない。では、どんなリクエストであれば、ベンダを動かすことができるのだろうか。それを考えるのは、スキルが欠如している発注側にとっては克服が難しいハードルである。
発注側に現場のスキルが欠如しているために、ベンダに対して質の高いリクエストをすることができない。これが第二のハードルである。
ハードルを越えるための基本方針
１．契約の壁を乗り越えるための方針
契約の壁を乗り越えることはできない。ただしシステム開発においては、「請負契約であってもある程度の干渉は認める」という暗黙の了解が双方に存在している。実はベンダにとっても、発注側の干渉は検収時のリスクが低下するというメリットがあるのである。ただし、それが暗黙の了解に依存する以上、そこには双方の納得感や説得力というものが必要になってくる（※あるいは力関係が大きなウェイトを占めることになる）。
どのような根拠や裏付けがあれば、発注側のリクエストに対してベンダも納得し、協力してくれるのだろうか。もちろん、契約書に明記しておくことである。しかし、契約時点では具体的な作業内容もベンダのスキルも見えていないことが多い。そこで有用な“ツール”となるのが各種の計画書である。契約の縛りによって強権的にリクエストを発するのが困難な場合でも、計画書に書いてもらえばそのリクエストも（しぶしぶかもしれないが）呑んでもらえる可能性は非常に高くなる。計画書に中間報告会の実施が記してもらえば、契約書にその記述がなくても、中間成果物を確認し、その内容にリクエストを出すことも可能になる。
計画書の承認とは、後々のリクエストを可能とするための"仕組み作り"の重要な機会なのである。内容をベンダ任せにしていてはいけないし、安易に承認してもいけない。妥協なく仕上げるべき仕事である。プロジェクトの成否がここで決まるくらいの意気込みでコトに当たるべきである。
【事例】
開発が始まったばかりだというのに、発注側とベンダの関係は冷え切っていた。本開発に先だって実施された準備フェーズにおいて、様々な問題が発生し、それが深刻な相互不信を招いていたのだ。
双方が「約束が違う」と感じている。双方が疑心暗鬼の状態に陥っている。かくしてベンダはきっちりとスコープ固めに走り、そして大げさに言えば、それ以外のことは何もするつもりがなかった。発注側が品質に疑問をもって、中間成果物を確認させてもらおうとしても、請負契約を盾に断るような状態であった。
本来であれば今後の展開を心配して、発注側のマネジャーには相当なプレッシャーがかかる事態だが、このマネジャーは落ち着いていた。実はプロジェクト計画書を承認するにあたって、発注側として押さえるべきところをきっちりと押さえていたのだ。発注側として必要な成果物の機能要件や非機能要件が、要件定義書の詳細な記述如何によって左右されることのないように、大レベルの記述で「要件を定義」していたのである。
計画書の記述に関しては、発注側の要求に対してベンダも多少の抵抗はしたはずである。しかしどこまでの重要性の認識をもって抵抗したであろうか。一方、発注側のマネジャーはここがプロジェクトの勝負どころということを知っていた。そして妥協せず、発注側の意向をプロジェクト計画書に反映させた。この時点で、勝負ありであった。
２．発注側スキル欠如を乗り越えるための方針
ベンダに任せっきりにしていたために問題の発覚が遅れ、結果として失敗プロジェクトに陥ってしまう。こうした事態を防ぐために、発注側からの不断の監視とリクエストが必要である。ではどのようなリクエストをすればプロジェクトの危機を未然に防ぐことができるのだろうか。スキルのない発注側はここで途方に暮れてしまうかもしれない。設計書を見せてもらっても、ソースコードを見せてもらっても、手も足も出ない。確かにこのレベルでベンダにリクエストを出そうとするのであれば、スキルを持っていないと難しい。しかし実は、そこまでのスキルを持っていなくても、持っている場合と同等に近い「結果」を残すことは可能なのである。
質問するだけでいいのだ。極論を言ってしまえば、たとえベンダからの回答を理解できなくてもよい。更に、回答を理解できないことをベンダが知っていても構わない。回答を文書の形でもらうだけでいいのだ。
あなたは部下に対して情報処理試験の合格を命じなければならないとする。このとき、あなたは試験の概要さえ知らなくてもよい。勉強の計画を提出させればよい。計画の具体的な中身が理解できなくても構わない。あとは「日々、勉強の進捗記録をつけること」「あとで記録を提出すること」命じておけばよい。たまに状況を確認するだけでよい。たまに質問をしてみるのもよい。質問をしてみて、部下がきちんと解答できるかどうかを確認してもよい。この場合もあなたは問題を詳しく知っている必要はない。部下の解答の正誤を評価する必要もない。「いつでもその解答を評価することができるぞ」という雰囲気を匂わせておくだけでよい。あるいはそれさえも必要ないかもしれない。
単純に言ってしまえばこういうことである。個々の詳細を知っている必要はなく、何を質問するか、何を依頼するか、何を確認するか、それさえ知っていればよいのである。これは個別の業務、個別の技術に依存しないプロジェクトマネジメントの知識である。たとえ自身に現場のスキルがなくても、こういったマネジメントの知識を活用することによって、相手が保有するスキルを相手に使わせることができるのである（※ただし実際の活用にあたっては、シチュエーション別の体系化が欠かせない。後項参照）。
ベンダを動かすには質問が一番である。ポイントを突いた質問であればベンダも回答せざるを得ない。「よい」質問であれば、回答するためにはベンダに何らかの作業が発生する。発注側の狙いは、まさにその作業をベンダにしてもらうことである。依頼してその作業をしてもらうよりも、質問をしてその作業をしてもらうほうが、余程受け入れられる可能性が高くなる。
|
発注側の"ベンダ管理"のレベル
|
|
方法
|
特徴
|
| 実施すべきアクションや従うべきプロセスを、ベンダに具体的に指示して、その実施状況をモニタリングする。 |
発注側が持つスキルや情報がベンダよりも高い場合に効果的である。ただし指示が誤っていると、逆効果あるいは単なる時間の無駄となる。 |
| 実施すべきアクションや従うべきプロセスを、ベンダから提示してもらい、発注側で評価の後、実施にGOサインを出す。 |
発注側が持つスキルや情報がベンダよりも高い場合に効果的である。ただし評価が誤っていると、逆効果あるいは単なる時間の無駄となる。 |
| ベンダからの提案や報告に対して詳細な質問を投げることによって、ベンダ自身の気づきを促す。 |
ベンダの専門性の効果的な活用を促進することができる。ただし無闇な質問はベンダのオーバーヘッドを高める可能性がある。 |
| ベンダに対して期待する成果物の姿だけを伝える。 |
丸投げに近い状態であり、発注側の負担は少ない。ただし「蓋を開けてびっくり」となるリスクを抱えることになる。 |
【事例】
ベンダ側のマネジャーのほとんどは"メインフレーマー"で、長年ベンダ主導でプロジェクトを進めてきた経験しか持たない人ばかりであった。当然、発注側から詳細なリクエストや管理といったものを受けてきた経験はほとんどない。報告内容もスパンも粒度もアジェンダも全てがベンダ主導であった。一方、そんなベンダに引きずられて、発注側もそれが当たり前の状態だと思っていた。
こうした状況でベンダに対して詳細なリクエストをし始めたところ、当然のごとく抵抗に遭うことになった。その場ではしぶしぶ肯定的な返事をしておきながら、実際のアクションは何も起こさない。目に見える問題が生じているにもかかわらず、「問題が生じていないのに、なぜ今のやり方ではダメなのか」と疑問を呈する。
厳しい環境ではあったが、事実を提示し、ロジックを固めながら、ベンダへのリクエストを辛抱強く続けていったところ、少しずつではあるがベンダの姿勢に変化が見られ始めた。理屈の通った詳細なリクエストが、ベンダにとって当たり前の姿になってきたのである。ベンダの行動にも、徐々に変化が表れてきた。報告の粒度や、質問に対する回答の質も改善されてくる。リクエストが実際にプロジェクトに貢献するものだということがわかってくると、各種の提案も受け入れられるようになってくる。
こうした変化は、当然成果物の品質にも反映される。現場を知らない発注側にとっては、ベンダから提出されるドキュメントは、状況を判断するためのほとんど唯一の手段であるが、この品質向上は当然ベンダに対する評価の変化につながっていった。相互の誤解なども生じにくくなり、当初は険悪だったユーザとベンダの関係さえも徐々に改善されていった。
システム開発のスキルが欠如しているというハードルは、プロジェクトマネジメントの知識によって十分に乗り越えられるのである。ではそれはどのような知識だろうか。以下、ベンダへのリクエストの具体例を見てみることにする。
ベンダを動かす"詳細リクエスト"の具体例
以下に紹介する詳細リクエストの具体例は、数多くのプロジェクト管理の教科書の知見と、筆者の現場の経験をインプットとして、シチュエーション別に体系化したものの一部である。紙面の都合上、限られた内容になっているが、イメージを感じ取っていただけたらと思う。決してシステム開発スキルに依存するものではない。
まずは「そのタスクで初めての遅延」か、それとも「先週に引き続いての遅延」かによって対応が分かれる。前者の場合は、まずは報告の信頼性を確認した後で、原因の確認が最初の仕事となる。後者の場合、つまり以前から報告されていた遅延が今回も解消されていない場合は、更にそれが縮小傾向にあるのか拡大傾向にあるのかによって、対応は分かれる。縮小傾向にあるならば、静観していてもよいかもしれない。拡大傾向にあるならば、その原因を確認するために、プロジェクトの「様々な側面」に対して、ベンダに詳細な質問をする必要があるかもしれない。
さて、ここでは「そのタスク初めての遅延発生の場合」だけを例として取り上げることにする。発注側の対応は、以下の図のようなステップとなる。もちろんこれが唯一の正解というわけではなく、あくまでもリクエストのシナリオの一例である。どのようなステップになるかは、プロジェクト管理の一般的な知識を"マニュアル"へと落とし込む際の、その「落とし込み方」次第である。順番が変わることもあるし、並列で実施されることもあるし、別のステップが入ってくることもある。
ただし、上記の抽象度のリクエストでは「本当に」スキルが欠如している担当者が、ベンダに対して具体的で効果的な質問をしていくのは難しいだろう。そのような組織では、ステップごとに更に詳細な「質問することリスト」や「確認することリスト」を作成しておく必要がある。
「報告の信頼性を確認する」ステップであれば、
- 何月何日時点での進捗か？
- 誰がいつどのようにして獲得した情報か？
- 報告スパンが1週間単位なのに、急に5日遅延などということになっていないか？
といった質問／確認項目が考えられる。「報告の信頼性を確認する」ためには、「どのような質問をベンダに投げるべきか」「どのような事を確認すべきか」を考え、「質問すべきこと」「確認すべきこと」をリストアップしていく。「ネタ」に困ったら、巷に数多く存在しているプロジェクト管理の参考書からヒントを得るのである。
「遅延の原因を確認する」ステップであれば、
- 遅延の直接の原因は何か？
- 遅延の根本の原因は何か？
- 遅延にはどんなステークホルダーが絡んでいるのか？
といった質問／確認項目が考えられる。
「原因を分析する」ステップであれば、
- ベンダの原因分析の信頼性はどのように判断すべきか？
- 根本原因と直接原因の因果関係は正しいと思われるか？
- 要条件と十分条件と寄与条件の錯誤はないか？
- 原因分析は一般論レベルで止まっていないか？
といった項目が考えられる。この項目は質問／確認のためのものというよりも、発注側が自ら考察し、判断すべきものかもしれない。
上記の例では、「原因を分析する」ステップの後は3つのステップを並行して実施することになっている。もちろんこれも唯一の正解ではない。組織やマネジャーの考え方や好みによって分類の仕方も項目も違ってくるだろう。あくまでもサンプルであり、一つの例にすぎないが、それぞれのステップでの質問／確認項目は以下の図のようになる。当然、項目の追加や修正の余地は十分に残っている。更に一階層、二階層、レベルを下げて詳細化することもできる。
おわりに
ルールの変更は現場に影響を及ぼす。工事進行基準がどのような変化を現場に及ぼすことになるのかは予測の域を出ないが、発注側としては常に最悪の状況を想定して対策を打っておく必要がある。「発注側のプロジェクト管理」とは、「これはベンダの仕事だ」などと役割に拘泥することなく、「最良の結果を得るためにできること」を発注側自ら積極的に考えていくためのものである。そしてベンダに対する"詳細リクエスト"はその具体案である。リクエストの多くはベンダにしてみれば「言われなくてもやっています」というものかもしれない。しかしそこにあえて詳細な確認を入れていくことによって、プロジェクト目標の達成が確実なものになる。紙面の都合上、十分な説明ができたかどうか不安が残るところであるが、エッセンスだけでも掴んで頂けたらと思う。
|
