システム開発を依頼する前に知っておきたい「打ち合わせの覚悟」

はじめに

クライアントとシステム開発の打ち合わせを重ねていると、毎回感じることがあります。

打ち合わせを2回、3回と重ねるうちに、クライアントが明らかに疲れている。発言が減り、宿題への対応が滞り始め、前回合意したはずの仕様が次の打ち合わせで違うものに変わっていたりする。最初は「自分の進め方が悪いのかな」と思ったこともありました。説明が長すぎるのか、論点の整理が雑なのか、頻度が多すぎるのか。

でも、業種を変え、規模を変え、進め方を変えてみても、同じ現象がほぼ全てのプロジェクトで起こります。社内だけで使う業務システムから、全国規模の利用を想定したプラットフォームまで。完了したプロジェクトも、進行中のものも、残念ながら頓挫してしまったものも、共通して同じパターンが見られました。

ここまで観察を重ねて、ようやく分かったことがあります。これは私の進め方の問題ではないし、クライアントが悪いわけでもない。システム開発という業務そのものが、発注者側に相応の負荷を強いる構造になっているということです。

この記事では、システム開発を依頼する前に知っておいてほしい「打ち合わせの覚悟」について、両方の立場を経験した私の視点でお伝えします。

なぜシステム開発の打ち合わせは「想像以上に大変」なのか

普段やらない作業を集中的に強いられる

システム開発の打ち合わせで発注者に求められるのは、おおよそ次の3つです。

1つ目、自社の業務を言語化すること。普段は感覚や慣習で動かしている業務を、第三者に説明できる形に言葉で起こす作業です。「いつも通り」「現場で判断」といった暗黙知を、明確な手順とルールに変換しなければなりません。

2つ目、未来の運用を想像すること。まだ存在しないシステムを、誰が、どんな場面で、どのように使うかを具体的にイメージする作業です。当然ながら、想像はしばしば現実とズレます。打ち合わせの後半になって「やっぱりこの機能は使われないかも」「逆にこの機能が必要だった」と気づくことが頻繁にあります。

3つ目、関係者の意見を集約すること。経営者、現場担当者、間接部門。立場によって求めるものは違います。それぞれの言い分を聞き、優先順位をつけ、合意点を見つける作業です。

どれも普段の仕事では集中的にやらない作業ばかりです。慣れていない作業を、しかも限られた時間の中で次々と判断していく。打ち合わせを重ねるごとに疲弊するのは、当然と言えば当然なのです。

形のないものを決めるという難しさ

オーダーメイドのスーツや住宅の注文と、システム開発は性質が違います。

スーツや住宅は、サンプルや図面を見ながら「もう少し袖を短く」「リビングは南向きで」と具体的に決められます。完成イメージが視覚的に共有しやすい。

一方、システム開発は完成形が目に見えません。画面の見た目だけなら設計段階で確認できますが、システムの本質は「業務がどう変わるか」「データがどう流れるか」「現場の動きがどう変わるか」という運用面にあります。これらは打ち合わせの中で言葉だけで擦り合わせていくしかなく、認識のズレが起きやすい。だから何度も確認と修正が必要になり、打ち合わせが長引きます。

私自身、発注者として経験した疲労

ここまで読んで「制作者の立場で言うのは簡単だ」と思った方もいるかもしれません。でも、私自身も発注者の立場でこの大変さを経験しています。

化学メーカーで研究開発に従事していた頃、研究プロジェクトのリーダーとして、外部メーカーへの発注を主導していました。開発した技術を実証するための実証機の設計・製作、研究用の組み込み基盤のソフト・ハードの開発委託、社内の研究テーマに合わせたカスタム装置の発注。どれも仕様検討の打ち合わせを何度も重ねました。

その時に感じたのが、社内での調整と発注先への調整・説明が並行する負荷でした。社内では「もっと早く決めてくれ」と言われ、発注先には「もう少し時間がほしい」と伝える。社内の合意が取れた仕様を発注先に持っていくと、技術的に難しいと指摘される。それを社内に持ち帰って再調整する。この往復だけで疲弊した記憶があります。

だから今、クライアントが打ち合わせの後半に明らかに疲れた顔をしているのを見ると、当時の自分の姿が重なります。これは構造の問題なのです。

事前の覚悟：依頼する前に持っておくべき心構え

ここからが本題です。打ち合わせの大変さが構造の問題だとしても、その負荷を軽減する方法はあります。最大のポイントは、依頼する前から覚悟を持っておくことです。

時間の覚悟

規模にもよりますが、私が関わってきたプロジェクトでは、毎週1〜2回の打ち合わせを2〜3ヶ月続けるのが標準的なペースです。1回あたり1〜2時間。これを単純計算すると、打ち合わせだけで合計20〜40時間。さらに打ち合わせの間にある「宿題」への対応時間が、同じくらいかそれ以上必要になります。

「ちょっと相談したい」程度の温度感で依頼すると、この時間の投入量に驚くことになります。本業の合間に対応できる量ではなく、ある期間は集中的に時間を確保する覚悟が必要です。

巻き込みの覚悟

打ち合わせを進めていくと、必ず「あの部署にも確認しないと」「社長にも判断を仰がないと」という場面が出てきます。問題は、それがプロジェクトの中盤以降に発生するケースです。最初から関係者を巻き込んでいないと、後から「あの人に聞いてなかった」が出てきて、決まったはずの仕様が振り出しに戻ります。

依頼する前に、関係しそうな部署・人物を洗い出し、最初の打ち合わせから巻き込んでおくこと。これだけで後半の戻りが大幅に減ります。

意思決定の覚悟

「お任せします」では進みません。システム開発では、機能の優先順位、画面の設計、運用ルール、例外処理のあり方など、無数の判断を発注者側に求められます。

開発者は技術的な選択肢を提示できますが、「自社にとって何が正解か」を決められるのは発注者だけです。「全部入れたい」も「とりあえず動けばいい」も意思決定ではありません。何を捨てて何を残すかを、自分の責任で決める覚悟が要ります。

未知への覚悟

完成形が見えないまま進むフェーズが必ずあります。要件定義の途中、設計の途中。「これで本当に大丈夫なのか」という不安が消えない期間が、システム開発には組み込まれています。

この不確定な状態に耐えられるかどうか。耐えられず途中で方針を大きく変更すると、それまでの議論が無駄になります。完璧に決まってから進むことはできない、ということを最初に受け入れておくのが、未知への覚悟です。

進行中の覚悟：打ち合わせを重ねる中で発生する負荷

事前の覚悟があっても、打ち合わせを始めれば想定外のことが必ず起こります。進行中に発生する負荷についても、あらかじめ知っておくと心構えが違います。

宿題は必ず出る

打ち合わせの場で全てが決まることはありません。「社内で確認します」「資料を用意します」「現場にヒアリングします」といった宿題が、毎回必ず発生します。

この宿題に対応する時間が、打ち合わせ本体と同じかそれ以上に時間を食います。打ち合わせ時間だけを見て「週2時間なら大丈夫」と考えていると、想定外の負荷に追い詰められます。打ち合わせと宿題はセットで時間を確保するのが現実的です。

「言うことが変わる」のは自然な過程

ここがおそらく一番重要な視点です。打ち合わせを重ねていると、前回合意したはずの内容が、次の打ち合わせで違うものに変わっていることがあります。

私の立場では「決まったはずなのに…」と感じる瞬間ですが、発注者側に立てば理由は明確です。社内で確認した結果、別の意見が出てきた。経営者と現場担当者で温度差があった。間接部門から想定していなかった懸念が出た。これは全て、社内調整の自然な過程です。

発注者側は「言うことが変わって申し訳ない」と過剰に萎縮する必要はありません。社内調整の結果として方針が変わるのは、システム開発の前提として組み込まれているものです。

ただし、これを許容できる開発パートナーを選ぶことは重要です。「一度決まったことは変えられません」と硬直的な対応をされると、社内調整の結果を反映できず、結果的に使えないシステムができあがります。

未知への想像のズレ

進行中に必ず明らかになるのが、未知への想像のズレです。

ひとつは、想像が足りていなかった部分。「こんな場面でも使うとは思わなかった」「こういう例外処理が必要だとは気づかなかった」というケースです。打ち合わせの中で初めて気づくことが、想像以上に多くあります。

もうひとつは、逆に過大な期待をしていた部分。「これくらい簡単にできると思っていた」「もっと自動化されると思っていた」という落胆です。技術的な制約や工数の現実に直面して、当初の期待を調整する必要が出てきます。

どちらも打ち合わせの中で起こる正常なプロセスですが、心の準備がないと「こんなはずじゃなかった」という不満につながります。想像と現実のズレは必ず起こると知っておくだけで、心理的な負荷は大幅に下がります。

それでもシステム開発を依頼すべきか

ここまで読んで「そんなに大変ならやめておこうかな」と思った方がいるかもしれません。でも、私が伝えたいのは「やめた方がいい」ではなく「大変さを理解した上で依頼する」ということです。

システム開発による業務改善や新規事業の立ち上げが、企業にもたらす価値は大きい。ただ、その価値を得るには、発注者側にも相応の投入が必要だということです。お金を払えば自動的に得られるものではありません。

そして、「お互いそれなりの覚悟が必要」というのは、発注者だけでなく開発者側にも同じことが言えます。発注者の負荷に伴走できる開発パートナーを選ぶこと。「言うことが変わる」のを社内調整の自然な過程として受け止められるパートナーであること。技術的な提案だけでなく、意思決定の支援までできるパートナーであること。

両者が覚悟を共有して進められれば、プロジェクトは成功に近づきます。

依頼前の自己診断

最後に、システム開発を依頼する前に、ご自身に問いかけてほしいことを並べておきます。

毎週1〜2回の打ち合わせと、その間の宿題対応を、2〜3ヶ月以上続けられますか。関係する部署・人物を洗い出し、最初の打ち合わせから巻き込む準備はできていますか。「お任せ」ではなく、自分の責任で意思決定する覚悟はありますか。完成形が見えない不確定な期間に耐えられますか。社内調整の結果として方針が変わることを、許容できますか。

全てに「はい」と答えられなくても構いません。ただ、これらの問いに正面から向き合ってから依頼に進むのと、何も考えずに依頼するのとでは、プロジェクトの進み方が全く違います。

依頼前の整理については、別の記事でも詳しく書いています。打ち合わせの覚悟と合わせて、ぜひお読みください。

システム開発を依頼する前に整理しておくと、話がスムーズに進むこと
仕様が固まらないまま始めたシステム開発をプロトタイプで乗り越えた話