はじめに

要件書にはお客様の意図が込められていますが、限られた紙面ですべてを書ききるのは難しいものです。そもそも、きちんとした要件書が届くケースばかりではなく、簡単な概要資料やA4ペラ1枚の説明だけで「こんな感じで見積もれますか？」というご依頼も実際にはかなり多いです。

今回は、そういった状況も含めて、見積依頼をいただいたときにPMOとして何を見ているか、という話です。

非機能要件は、早めにテーブルに載せたい

機能要件は書かれていても、性能やセキュリティ、運用保守といった非機能要件にはあまり触れられていない、ということがよくあります。お客様の関心事は「何を実現したいか」ですから、これはごく自然なことだとも感じます。

ただ、非機能要件は開発規模やコストにかなり効いてきます。「ピーク時にどこまで耐えるか」「障害時にどのくらいで復旧させるか」でインフラ構成もコストも変わるので、見積に入る前に軽く会話する場を設けるようにしています。まずは「このあたり、どうお考えですか？」くらいの温度感で十分です。

スコープの境界は、一緒に確認する

「システムの構築をお願いしたい」と言われたとき、どこまでがスコープに含まれるかは、案外お互いに違うイメージを持っています。データ移行は？テスト範囲は？マニュアルは？導入支援は？ ――ここを曖昧にしたまま進むと、プロジェクト終盤に「それも入ってると思ってました」「いえ入ってません」の応酬が始まります。誰も幸せにならないやつです。見積段階で一緒に確認しておくだけで、だいぶ違います。

見積の打ち合わせ（ヒアリング）前に、ちょっとだけ話す

「業務を効率化したい」と言っても、何を・どの部分を・どのくらい、で方向性はまったく違います。お客様の中では明確でも、まだ言葉になっていないことは多い。

なので、見積依頼の直後に30分くらいの打ち合わせをお願いすることが多いです。要件の読み合わせではなく、「今困っていること」「一番やりたいこと」を聞かせてもらう場。これだけで見積の方向性がだいぶクリアになります。

全体像がまだ固まっていないなら、無理に一括で見積もらず、フェーズを分けて提案します。まず最小限で立ち上げて、動かしながら次を考える。お客様にとっても、動くものを見てから判断できるほうが安心なはずです。

「お任せします」の受け止め方

「お任せします」はありがたい言葉ですが、額面どおりに受け取って「わかりました」で終わらせると、後で「そうじゃなかったんですけど…」が発生します。経験上、「お任せ」は「信頼しているから好きにしていい」ではなく、「よくわからないから、うまいことやってほしい」に近いことが多い。ここを読み違えると、納品後に壮大な「思ってたのと違う」祭りが開催されます。

以下は、システム開発における「要件定義の難しさ」を風刺した図です。

この図では、お客様が本当に必要としているシステムを「タイヤブランコ」に例えています。しかし実際には、お客様自身が必要以上に複雑な要望を出してしまったり、その内容を受け取ったプロジェクトリーダーや各担当者が要件を十分に理解できないまま解釈を加えたりすることで、結果として「奇怪なブランコ」「華美なブランコ」「過剰なブランコ」「無理なブランコ」へと変化していきます。

システム開発において、関係者ごとの認識のズレや過剰な解釈が積み重なることで、本来必要だったシンプルな姿から乖離してしまう――その様子を表現した風刺となっています。

お任せいただいた部分でも「こういう考え方で進めますね、違ったら言ってください」と添えておく。これだけで「勝手に決められた」感がなくなります。

見積書もコミュニケーションのひとつ

見積書は金額を伝える書類ですが、プロジェクトの輪郭を共有するツールでもあります。「含まれるもの」と「含まれないもの」を両方書いておく。「データ移行は含まれていません、必要なら別途」と書いてあるだけで、お客様側も次を考えやすくなります。

ここは個人的にかなり重要だと思っているポイントですが、見積書の前提条件を書くとき、つい専門用語で書いてしまいたくなります。でも見積書を見るのは技術者だけとは限りません。決裁者や事業部門の方が目を通すことも多い。そこをぐっと抑えて、相手に伝わる言葉に置き換える。「詳しく書く」より「わかりやすく書く」のほうがずっと難しいですが、ここは踏ん張りどころです。

たとえば「ECS Fargateを前提とする」と書くのと、「クラウド上に環境を構築し、アクセス量に応じてサーバーが自動拡張される構成を前提としています」と書くのでは、伝わる範囲がまったく違います。

技術的な正確さは当然保ちつつ、見積書を手に取った方が「何をどうするのか」をざっくりでもイメージできるレベルで書く。この書き分けができるかどうかで、見積書が「金額表」で終わるか「会話のきっかけ」になるかが変わってきます。

あと、「全部入りのプランA」と「コア機能に絞ったプランB」を並べて出す。お客様が予算やスケジュールと照らし合わせて選べる状態にしておくことが大事です。

まとめ

見積はプロジェクトの最初の接点であり、信頼関係の出発点でもあります。お客様が実現したいことを正しく理解して、プロジェクトの輪郭を一緒に描く。その対話を見積のプロセスに組み込んでおくことが、結局は一番効いてきます。

次回は後編として、プロジェクト進行中に現れる”小さな変化”にどう気づき、どう対処するかについて書きます。