「こんな仕事は頼んでいない」と言われる前に

プロジェクトの途中で、顧客からこう言われることがあります。ある日突然ではありません。小さな「あれ？」が積み重なって、少しずつ信頼が落ちていき、ある時点で言葉になります。

これは契約が請負でも準委任でも起きます。ただ準委任では、信頼が落ちている間も、毎月の請求書が届き続けます。

この記事では、顧客の信頼が少しずつ落ちていく理由と、準委任でそれが特に見えにくくなる理由、そして防ぐために最初に決めておきたいことを整理します。案件を回すPMにも、PMから報告を受ける立場の方にも読んでいただけるよう、最後に、案件の状態を確かめるための問いをまとめました。

信頼が落ちる理由1：「何を作るか」を合意していない

プロジェクトでは、設計書や資料、プログラムといった成果物を作ります。ところが、「このプロジェクトでどの成果物を作るのか」「それぞれを、どの粒度で、どの項目で整理するのか」を、顧客と最初に握っていない案件が少なくありません。

握っていないまま作業が進むと、出てくるものと顧客の想像がずれていきます。顧客は、操作マニュアルやデータ移行の計画書も作ってもらえると思っていた。ところが、それは作る予定に入っていなかった。これは「何を作るか」のずれです。顧客は、要件定義書で画面の項目まで確かめるつもりだった。ところが、出てきたのは業務フローと機能の一覧だけだった。これは「どの粒度で作るか」のずれです。どちらも、作った側は手を抜いていません。それでも顧客の目には、「思っていたものと違う」と映ります。

コラム#02で書いた、何を作るかを決めないまま、AIが出した観点をすべてドキュメントにしてしまうケースも、根っこは同じです。何を作るかが決まっていなければ、作れば作るほど、ずれは大きくなります。

信頼が落ちる理由2：合意した相手が、適切ではない

もう一つの大きな穴は、誰と合意したかです。

何を作るかを、項目のレベルまできちんと説明した。顧客の担当者も「いいですよ」と言ってくれた。ところが、その担当者は、業務やシステムに十分な知見を持っていなかったり、決める権限を持っていなかったりする。後になって、業務の責任者や決裁者が成果物を見て、「こういうものだとは思わなかった」と言う。

私が関わった案件でも、こういう場面がありました。窓口の担当者と、画面の項目まで一つずつ確認しながら設計を進めていました。ところが数か月後、初めて設計を見た業務部門の部長が、「この業務は、こういう流れではない」と言ったのです。担当者の確認を取っていた設計は、業務の流れから見直すことになりました。担当者も、私たちも、手を抜いてはいませんでした。決める人に、決めるための説明が届いていなかったのです。

説明したのは事実です。ただ、適切な人に、適切な説明ができていなかった。適切な人を巻き込めていなかったのです。しかも、決める権限を持つ人ほど、成果物そのものより「業務がどう変わるのか」「どこに時間とお金がかかるのか」を知りたがります。設計書を渡して「いいですよ」をもらうだけでは、その人に届く説明にはなりません。

準委任では、ずれが見えないまま進む

この2つの理由は、契約の形に関係なく起きます。違うのは、ずれがどこで表に出るかです。

• 請負：成果物を完成させる責任があり、顧客が検収するまで、基本的に請求はできません。
• 準委任（稼働に応じて請求する一般的な形）：業務を行うことに対して支払いを受けます。成果物を検収する場は、契約の上にはありません。

準委任では、顧客から見ると、期待したものが出てきているのか分からないまま、お金だけが出ていく状態になります。不満は、言葉になる前から少しずつたまっていきます。準委任の契約は、3か月や半年ごとに更新されることが多くあります。たまった不満は、ある更新のタイミングで「次は結構です」という形で表に出ます。

準委任は、アジャイル型や、日本で多いハイブリッド型の進め方と組み合わせて使われることがよくあります。アジャイルにも、スプリントごとのレビューのように、できたものを確かめる場はあります。ただ、納期は守りたい、でも変更には柔軟に応えてほしいという期待のもとで「ドキュメントは必要最低限」と進めると、動くものは見ていても、何が決まっていて、どこまでできているのかを示すものが残りません。ベースが見えなければ、変更を受けるかどうかの相談もかみ合いません。

準委任が悪いわけではありません。要件の変更や体制の見直しを、契約を巻き直さずに柔軟に相談できるのは、変化の多いプロジェクトでは大きな利点です。ただ、請負には、少なくとも検収という「仕様どおりにできているか」を確かめる場があります。だからこそ準委任では、何がどこまでできているのかを、毎月の報告などで自分たちから示していく必要があります。示さなければ、提供している価値は顧客に伝わりません。

信頼が落ちると、何を失うのか

どちらの契約でも、この2つの穴があると、小さなずれが何度も起きます。出てきた成果物が想像と違う。確認したはずの内容を、別の人がひっくり返す。作り直しが入り、時間がかかる。そしてある日、「こういう仕事は頼んでいません」と言われます。

一度こうなると、失うのはその場の雰囲気だけではありません。

• 作り直しを、無償で引き受けることになる：「頼んだものと違う」と言われれば、作り直しの費用を請求しにくくなり、その分が案件の利益を削ります。
• 次の提案がしづらくなる：追加の開発や次の案件を提案しても、「また同じことにならないか」と見られます。
• パートナーとしての立場を失う：一緒に考える相手から、言われたことだけをやる業者へと、見られ方が変わっていきます。

信頼を取り戻すのにかかる時間は、失うのにかかった時間よりずっと長くなります。信頼の低下は、目の前の案件の赤字と、顧客そのものを失うことにつながるのです。

防ぐために、最初に決めておく3つのこと

1. 成果物の一覧と、それぞれの粒度を合意する

キックオフの前後で、このプロジェクトで作る成果物を一覧にし、顧客と合意します。名前だけでなく、それぞれの目的と、主な項目（どの粒度で何を書くか）まで決めておきます。あわせて、それぞれ「何をもって完成とするか」も決めておきます。たとえば要件定義書なら、「対象のすべての業務について新しい業務の流れが書かれ、業務部門の責任者が内容を確認していること」のように、承認する人が判断できる基準にします。完成の基準がなければ、承認する側も、何を見て「いいですよ」と言えばよいのか分かりません。

請負でも準委任でも、この一覧が「何を作るか」の約束になります。準委任で要件や体制を柔軟に変えるときも、この一覧を更新すれば、何が変わったのかを双方で確かめられます。

すべてを同じ重さで承認してもらう必要はありません。顧客によって、細かい設計書をレビューできる力には差があります。書く内容の全体像は変えずに、承認の重さに差をつけます。

• 必ず承認をもらうもの：後から変えると設計の根底が崩れるもの。業務の範囲、データの持ち方、外部システムとのつなぎ方、性能やセキュリティの前提など
• 後から変えてもよいもの：画面の文言や帳票の細かいレイアウトなど、変えても全体に響かないもの

必ず承認をもらうものは、顧客がレビューしやすい形で説明します。設計書をそのまま渡すのではなく、業務の流れに沿って説明したり、画面のイメージやデモを見せたりします。

後から変えてもよいものは、「いつまでに、誰が決めるか」を一覧に書いて合意しておきます。書いておかなければ、後回しにしたこと自体が、見えないずれになります。

2. 誰に説明し、誰に承認してもらうかを決める

成果物ごとに、レビューする人と、承認する人を分けて決めます。承認する人は、その内容に知見があり、決める権限を持つ人です。

その人がなかなか時間を取れないことも、よくあります。それでも、窓口の担当者だけで済ませず、少なくとも節目では承認する人を巻き込みます。どうしても巻き込めない場合は、それをプロジェクトのリスクとして顧客と共有し、記録しておきます。

承認を得た内容を、後から別の人がひっくり返すこともあります。そのときは、こちらの作り直しとして抱え込まず、「変更」として扱います。何が変わり、スケジュールと費用にどう響くのかを示して、顧客と相談します。誰が、いつ、何を承認したのかを記録しておけば、この相談ができます。記録は、特別な仕組みでなくてかまいません。

• 承認の記録：成果物の表紙に承認欄（承認した人・日付・版）を設けるか、承認をメールで返してもらい、成果物の一覧の「承認日」に書き込む
• 変更の記録：変更の一覧（変更管理表）を1つ作り、「何が・誰の依頼で・いつ変わり、スケジュールと費用にどう響くか」を1行ずつ残す。定例の会議で毎回、顧客と確かめる

1で決めた「後から変えてもよいもの」も、決まったらこの変更の一覧に書き込みます。

社内や顧客にゲートレビュー（工程の節目ごとの審査）の仕組みがあるなら、それも使います。成果物の承認を節目に重ねておけば、認識のずれを早い段階で確かめられます。仕組みがなければ、節目だけでも外の目を入れておくと安心です。

3. 報告を「時間」ではなく「成果物」の単位にする

報告は、「今月は何時間働きました」「今週はこれをやりました」になりがちです。しかし顧客が知りたいのは、そのお金で何が進んだかです。

毎月の報告では、1で合意した成果物の一覧に沿って、どれがどこまで進み、どれが承認されたのかを示します。準委任であれば、使った時間がどの成果物に向かったのかも添えます。こうすると、請求書が届いたときに、顧客は「このお金で、これが進んだ」と確かめられます。

案件の状態を確かめる5つの問い

設計書を読み込まなくても、PMに次のことを聞けば、案件の状態はおおよそ分かります。すぐに答えが返ってこなければ、注意が必要です。

1つでも答えに詰まったら、受注前リスクチェック30（無料・約5分・登録不要）で、案件全体を確かめてみてください。

外から見ると、すぐに気づける

承認する人を巻き込めていない。成果物の粒度を顧客と握っていない。こうしたことは、プロジェクトの中にいるPMほど言い出しにくいものです。顧客との関係を崩したくない、社内で「できていない」と言いにくい、そもそも忙しくて立ち止まれない。理由はさまざまです。

一方で、案件の外にいる人が計画や体制を見ると、意外なほどすぐに気づけます。成果物の一覧に承認する人の名前が書かれているか。報告が時間の単位になっていないか。外から見るのは、この記事で挙げたような点だけです。中にいると当たり前になって見えなくなることが、外からは見えます。PMの力の問題ではなく、立ち位置の問題です。

顧客の信頼は、小さなずれの積み重ねで少しずつ落ちていきます。そのずれの多くは、何を作り、誰と決めるのかを、受注前やキックオフの前に合意していないところから始まります。走り出してから作り直すのは、何倍も大変です。

Valmoについて　大型案件の受注前とキックオフ直後に、提案や計画を外から審査し、不採算案件を防ぐ支援をしています。大手SIerのような審査部門を持たない会社の、「外付けの審査室」です。

関連：「AIで工数削減」を見積に入れる前に、確かめるべき5つのこと ・ 大型案件レビュー ・ プロジェクトアシュアランス（案件審査）とは

コラム一覧へ