キックオフの前に、お客様との事前すり合わせが1回あります。今回は、その日のための準備に充てた数日の話です。
作った準備資料は6シート。アジェンダ、体制案、進め方の叩き台、確認事項、デモ方針、当日の役割分担。この手の資料は、たいてい自社の説明で埋まります。会社紹介、実績、体制、私たちの強み。
今回は、そこを削るところから始めました。
説明を圧縮して、ヒアリングに15分確保した。
アジェンダの重心を「お客様の成功条件を聞く」に置きました。この案件が終わったときに、お客様の中で何がどうなっていれば成功と呼べるのか。それを本人の言葉で聞く時間を、15分確保しました。
15分を作るために、当社側の説明を圧縮しました。実績紹介も体制の詳細も、聞かれたら答えれば済みます。聞かれる前に話すことは、その場では成果になりません。
要件定義の失敗は、たいてい要件の抜けではありません。そもそも何を成功と呼ぶかが合っていないまま進むことです。機能は全部作った、納期も守った、それでもお客様が満足しない。この構図は、初回の15分を取らなかったところから始まっています。
判断を求めるなら、判断材料まで用意する。
体制は2案で持っていくことにしました。プロジェクト管理を誰が担うかで構成が変わるからです。
ここで意識したのは、「どちらがよいですか」と聞かないことでした。2案それぞれについて、何が強くなって何が薄くなるのかを添えました。お客様に選んでいただくのは結論であって、比較検討そのものは私たちの仕事です。
進め方の叩き台も同じ考え方で作りました。私たちの標準手順を押し付ける書き方をやめ、お客様の様式とツールに合わせる前提の表現に統一しました。進め方でもめる時間は、要件を詰める時間から差し引かれます。
言いにくい確認を、先に16件並べた。
この期間で一番あとから効いた作業がこれです。確認しないと進められない事項を、先に16件洗い出しました。
内訳は、その日に確認すべきもの8件、要件定義の期間中に確認するもの6件、契約に関わるもの2件。中には言い出しにくいものも入れました。本物のデータを見せていただけるか。開発環境に入らせていただけるか。個人情報をどう取り扱うか。
この3つは、聞かないまま進むと後半で必ず詰まります。本物のデータを見ないまま設計した画面は、実データを入れた瞬間に破綻します。環境に入れないまま作った連携は、繋ぐ日に動きません。
言いにくいことを最初に聞くのは、丁寧さではなくリスク管理です。
デモは、あえて5分に絞った。
準備していると、動くプロトタイプを当日フルで見せたくなります。前日までに82箇所直したものが手元にあるからです。
そうしませんでした。事前すり合わせでは要望があったときだけ5分のダイジェスト、フルデモはキックオフでやる、と決めました。
理由は2つあります。ひとつは、事前すり合わせの主役はヒアリングであって、デモを始めると必ず15分が消えること。もうひとつは、動くものを見せると、お客様の期待が「もうできている」に振れてしまうことです。
だから開示のルールも文書にしました。画面を見せるときは、これは実装済み・これは画面イメージのみ・この数字は参考値、と必ず区別して言う。プロトタイプは説明を助ける道具で、完成の証明ではありません。ここを曖昧にしたまま進めた案件は、後から必ず揉めます。
個人のPCの中にある資料は、資産ではない。
この期間には、もうひとつ地味な作業をしました。担当者のPCにしか存在しなかった図解資料を、全員が使える場所に移して整理したのです。
打合せの前に、誰かが個人で作った分かりやすい図が出てくることは、よくあります。それが個人の手元にあるままだと、その人が出られない日にプロジェクトの説明力が落ちます。
同じ理由で、社内の打合せで決めた前提も文書に落としました。期間の見立て、成果物の点数、報告と課題管理の運用方針。口頭で合っているつもりの前提が、一番あとで揺れます。
動くものがあると、営業の打ち手が変わる。
ここまでの判断は、どれも一見「AIと関係のない進め方の工夫」に見えます。実際には、全部つながっています。
自社の説明を削れたのは、説明の代わりに見せられる実物があったからです。実績を語らなくても、動くものを5分見せれば力量は伝わります。デモを我慢できたのも、同じ理由でした。手札が1枚しかなければ、初回で全部出すしかありません。キックオフでフルデモができると分かっているから、事前すり合わせでは出さずに済むのです。
本物のデータや環境アクセスを最初に求められたのも、実装がもう始まっているからでした。「設計が終わったら必要になる」ものではなく、今日困っていることとして聞けます。だから具体的に頼めます。
従来の上流工程は、成果物が紙しかないために「説明する・聞く・持ち帰る」の繰り返しになっていました。AIを主力にして実物が先にできると、営業の段階から「見せる・決める」に変わります。工程が速くなったのではなく、打合せで起きることの中身が変わったのです。
準備とは、当日の時間配分を設計する作業だった。
この数日でやったことを一言でまとめると、資料作りではありませんでした。限られた打合せ時間を、何にどれだけ使うかの設計です。
自社説明を削り、比較検討を先に済ませ、言いにくい確認を先に並べ、デモを我慢する。どれも、当日の時間を「決めること」に寄せるための判断でした。
次回は、分かっていないことを数えて表に出した話です。
※本記事の件数は当社側の作業実績です。お客様・システムを特定できる情報は記載していません。進め方や所要時間は案件の規模・体制により異なります。
連載「案件日誌」（全7回）第1回：受注した日に、プロトタイプを82箇所直した第2回：初回打合せのアジェンダから、自社の説明を削った（本記事）第3回：分かっていないことを、数えて表に出した第4回：プロトタイプを、本物の作りに寄せた第5回：「動いたように見えて何も起きない」を潰した（近日公開）第6回：守れない約束を、資料から削った（近日公開）第7回：机上の比較をやめ、実測で決めた（近日公開）