良い発注者になるための7つの習慣

「発注者としての自分は、ちゃんとやれているんだろうか」。開発会社とのやり取りを重ねるうちに、ふとそう感じたことはないでしょうか。トラブルが起きているわけではない。でも、なんとなく開発会社の顔色をうかがってしまう。要望を伝えるたびに「こんなことを聞いていいのか」と迷う。進捗報告を読んでも、本当に大丈夫なのか判断がつかない——。ひとりで情シスや総務を兼任しながらシステムを管理している担当者にとって、こうした漠然とした不安は珍しくありません。

このカテゴリでは、定例ミーティングの回し方から丸投げ発注の危うさ、進捗報告の読み方、仕様変更の伝え方、検収の視点、納品物の受け取り方、リリース後の不具合対応、保守費の考え方、担当者交代への備え、契約書に書くべき条項、そしてトラブル時の交渉術や解約の伝え方まで、開発会社との関わりを局面ごとに19本の記事で扱ってきました。それぞれの記事は「こういう場面ではこう動く」という具体的な対処法を示すものでしたが、この記事はその集大成として、少し視点を引き上げます。局面ごとの対処法の背景には、実は共通した姿勢があります。それを「良い発注者になるための7つの習慣」として整理し直すのが、このカテゴリの最終回であり、うちシスなび全140本の締めくくりでもある本記事の役割です。

この記事で分かること

開発会社と良好な関係を築き、プロジェクトを円滑に進められる発注者に共通する7つの習慣を、開発会社側の視点も交えながら体系的に整理します。「要件を自分の言葉で説明できる」「窓口を一本化する」「進捗を定期的に確認する」「変更は書面に残す」「検収の基準を事前に決める」「感謝と指摘の両方を伝える」「長期的なパートナーとして関係を棚卸しする」の7つです。それぞれの習慣が、このカテゴリで扱ってきた個別記事のどの論点とつながっているかも示しながら、開発会社とのつきあいかた全体を俯瞰します。

なぜ「良い発注者」を体系化する必要があるのか

システム開発の現場では、プロジェクトがうまくいくかどうかを開発会社の技術力や提案力だけで語られがちです。もちろんそれも重要な要素ですが、実際に多くの現場を見てきた開発会社側の実感として、プロジェクトの成否を大きく左右するもう一つの要因があります。それは発注者側の関わり方です。

同じ開発会社が、同じような予算感で請け負ったプロジェクトでも、発注者の関わり方次第で結果は大きく変わります。要件があいまいなまま進み、検収の段階で「思っていたのと違う」という認識のズレが噴出するプロジェクトもあれば、要件は最初から明確で、進捗確認も適切なタイミングで行われ、検収もスムーズに終わるプロジェクトもあります。この違いを生んでいるのは、多くの場合、発注者側の習慣です。

ここで誤解してほしくないのは、「良い発注者になる」ことは、開発会社に都合よく振る舞うことではないという点です。開発会社に不満があれば伝えるべきですし、価格交渉も遠慮する必要はありません。良い発注者とは、開発会社に従順な発注者ではなく、自社の利益を守りながら、開発会社が実力を発揮しやすい環境を作れる発注者のことです。この2つは対立しません。むしろ、自社の利益を守るための行動そのものが、結果的に開発会社にとっても仕事をしやすい環境につながるという構造があります。以下では、その構造を7つの習慣として順に見ていきます。

良い発注者とは、開発会社に従順な発注者ではなく、自社の利益を守りながら開発会社が実力を発揮しやすい環境を作れる発注者のことです。

習慣1: 要件を自分の言葉で説明できる

良い発注者に共通する最初の習慣は、依頼したい内容を、開発会社の言葉を借りずに自分の言葉で説明できることです。「いい感じにしてほしい」「他社さんがやっているようなシステムにしてほしい」という抽象的な依頼は、開発会社側の解釈に大きな幅を持たせてしまいます。

これは技術的な知識を持てという意味ではありません。技術的な実現方法を考えるのは開発会社の仕事です。発注者が持つべきなのは、「何のために」「誰が」「どんな場面で」使うのかという業務側の言語化です。たとえば「在庫管理を効率化したい」ではなく、「毎朝、紙の台帳と実在庫を照合する作業に30分かかっている。この照合作業をシステム上で完結させたい」というレベルまで具体化できると、開発会社は的確な提案をしやすくなります。

丸投げ発注が失敗しやすいのは、まさにこの言語化を怠るケースです。発注者が「任せる」と言った瞬間、開発会社は業務の詳細を知らないまま設計を進めざるを得ません。その結果生まれるズレは、検収の段階になって初めて表面化し、手戻りや追加費用の火種になります。要件の言語化は、要件定義（何を作るかを発注者と開発会社が合意し、文書化する開発初期の工程）の段階で特に重要ですが、実は開発中の仕様変更や追加開発の依頼でも同じことが言えます。

• 依頼のたびに「なぜそれが必要か」を一文添える: 目的が分かると、開発会社側でより良い代替案を提案できることがある
• 数値や頻度を具体的に伝える: 「よく使う」ではなく「1日に20件程度」のように定量化する
• 完成後の使われ方をイメージして伝える: 誰が、いつ、どの端末から使うのかを共有する

言語化が苦手だと感じる担当者もいるかもしれませんが、これは訓練で身につくスキルです。最初は箇条書きでも構いません。要件を書き出す習慣そのものが、発注者としての基礎体力になります。

習慣2: 窓口を一本化する

2つ目の習慣は、開発会社とのやり取りの窓口を、自社側で一本化しておくことです。複数の担当者がそれぞれ個別に開発会社へ依頼を出してしまうと、開発会社側で情報が分散し、「言った・言わない」のトラブルや、重複依頼、優先順位の混乱を招きます。

とくにひとり情シスや総務兼任の担当者の場合、自分自身が窓口になることが多いはずですが、注意したいのは他部署からの依頼が自分を経由せずに開発会社へ直接流れてしまうケースです。営業部門が「ちょっとこの画面直してほしい」と開発会社に直接連絡し、あとから情シス担当者がその事実を知らないまま状況が進んでしまう、という事態は決して珍しくありません。

窓口の一本化は、丸投げ発注が失敗する理由として整理した「発注者が担うべき5つの役割」のうち、まさに「窓口の一本化」そのものです。この役割を果たすには、社内での周知が欠かせません。

窓口を一本化すると、依頼の全体像が自分の手元に集約されるため、優先順位づけや予算管理がしやすくなります。開発会社側にとっても、誰の指示が正式なものかが明確になり、無用な混乱を避けられます。定例ミーティングを運営する際にも、窓口が一本化されていることが前提になります。

習慣3: 進捗を定期的に、受け身ではなく確認する

3つ目の習慣は、進捗確認を開発会社からの報告を待つだけの受け身の姿勢にしないことです。良い発注者は、定例ミーティングや進捗報告を単なる儀式として消化するのではなく、そこから危険な兆候を読み取ろうとします。

進捗報告の見方について整理したとおり、報告の粒度が急に粗くなったり、これまで具体的だった完了予定日が「調整中」という表現に変わったりする瞬間には注意が必要です。良い発注者は、こうした変化に気づいたら、「大丈夫ですか」という漠然とした確認ではなく、「先週のタスクリストと比べて、この項目はどう進んでいますか」という具体的な質問を投げかけます。

進捗確認を習慣にするうえで意識したいポイントを整理します。

• 定例の頻度を、プロジェクトのリスクに応じて調整する: 要件が固まっている保守フェーズと、要件が流動的な新規開発フェーズでは、必要な頻度が異なる
• 口頭の報告だけでなく、議事録やタスク管理ツールで記録を残す: 「言った・言わない」を防ぐだけでなく、後から振り返ったときに変化に気づきやすくなる
• 進捗が計画通りであることよりも、計画とのズレをどう扱っているかに注目する: 遅れが出ること自体は珍しくない。問題は、遅れをいつ、どう報告してくるか

進捗確認を怠ると、問題が深刻化してから初めて気づくことになります。逆に、過度に細かく確認しすぎると、開発会社側の作業を妨げ、マイクロマネジメントとして関係を悪化させることもあります。適切な頻度と粒度を見極めることが、この習慣の核心です。

習慣4: 変更や依頼は、口約束ではなく形にして残す

4つ目の習慣は、仕様変更や追加の依頼を、口約束のまま済ませずに、何らかの形で記録に残すことです。電話や立ち話で「じゃあこれもお願いします」と伝えただけで終わらせてしまうと、後になって「言った内容と違う」「そんな依頼は聞いていない」という食い違いが生まれます。

仕様変更・追加要望の正しい伝え方で扱ったとおり、変更依頼票のような簡易なフォーマットを使うだけでも、認識のズレは大きく減らせます。専用のツールを導入する必要はなく、メールやチャットで「何を」「なぜ」「いつまでに」という3点を書いて送るだけでも十分な効果があります。

書面化を習慣にするメリットは、トラブル防止だけではありません。過去の依頼内容が記録として残っていれば、次に似たような依頼をする際に参照でき、要件を毎回ゼロから説明する手間も減ります。また、追加費用が発生するかどうかの判断材料にもなります。SOW（作業範囲記述書）（開発会社が請け負う作業の範囲を明文化した文書）で定められた範囲を超える依頼かどうかは、書面に残っていて初めて客観的に判断できるからです。

書面化というと堅苦しく聞こえるかもしれませんが、実際には次のような軽いフォーマットで十分機能します。

件名: [変更依頼] ログイン画面のエラーメッセージ文言変更
何を: エラーメッセージを「入力エラー」から「メールアドレスまたはパスワードが正しくありません」に変更
なぜ: ユーザーからの問い合わせが多いため
いつまでに: 今月末のリリースまでに反映希望

こうした記録は、契約不適合責任の範囲を判断する際や、検収で不具合を報告する際にも、依頼の経緯を示す証拠として役立ちます。良い発注者は、書面化を「開発会社を疑う行為」ではなく「双方を守るための共通の記録」として捉えています。

習慣5: 検収の基準を、検収の当日ではなく事前に決める

5つ目の習慣は、検収で何を確認するのかという基準を、検収の当日になって考えるのではなく、事前に準備しておくことです。検収で見るべきポイントで整理したとおり、表示・データ整合性・権限・異常系・運用シナリオという5つの視点をあらかじめリスト化しておくと、その場で慌てて確認項目を思いつく必要がなくなります。

事前に基準を決めておくことは、検収そのものの質を上げるだけでなく、開発会社との関係にも良い影響を与えます。検収基準が曖昧なまま「なんとなく動いているか確認する」という検収を続けていると、後から不具合が見つかったときに「検収時には問題なかったはずだ」という水掛け論になりやすくなります。逆に、あらかじめ合意した基準に沿って検収を行い、その記録を残しておけば、後から問題が見つかった場合の切り分けもスムーズになります。

検収基準を事前に決める際のポイントを整理します。

• 要件定義やRFP（提案依頼書）（発注者が開発会社に対して、実現したい内容や条件をまとめて提示する文書）の段階で挙げた要件を、検収チェックリストの形に変換しておく
• 異常系のテストケース（不正な入力、通信断など）を最低限含める: 正常に動く場面だけを確認する検収は、実運用で問題が起きやすい
• 検収の合格基準（何をもって「合格」とするか）を、開発会社と事前にすり合わせる: 「バグゼロ」を基準にすると、軽微な表示崩れでも検収が通らなくなり、双方にとって非現実的になる

検収基準を明確にしておくことは、検収という工程を単なる形式的な手続きから、実質的な品質保証の機会に変える最初の一歩です。良い発注者は、この基準づくりを開発が終盤に差し掛かってから慌てて行うのではなく、プロジェクトの早い段階から少しずつ準備しています。

習慣6: 感謝と指摘の両方を、同じ熱量で伝える

6つ目の習慣は、開発会社に対して、感謝の言葉と改善すべき点の指摘を、どちらも同じ熱量で伝えることです。多くの担当者は、どちらか一方に偏りがちです。不満があるときだけ連絡し、良い仕事をしてもらったときには特に何も言わない担当者もいれば、逆に関係を悪くしたくないという理由で、品質に問題を感じていても指摘を避けてしまう担当者もいます。

システムの品質が低いと感じたときの伝え方で整理したとおり、不満を印象論のまま伝えると、開発会社側も具体的にどう改善すればよいか分からず、関係がこじれやすくなります。「なんとなく品質が低い気がする」ではなく、「動作」「保守性」「コミュニケーション」「対応スピード」といった軸に分解し、具体的な事象とともに伝えることで、指摘は建設的なフィードバックに変わります。

一方で、指摘ばかりを伝える関係は長続きしません。良い提案をしてもらったとき、丁寧に対応してもらったときには、その都度、具体的に何が良かったかを伝えることも同じくらい重要です。これは単なる社交辞令ではありません。開発会社側にとって、何が評価されているかが分かることは、次の提案の質を上げるための重要な情報になるからです。

良好な関係とは、何も言わない関係ではなく、言うべきことを言い合える関係です。感謝も指摘も、どちらも「言うべきこと」に含まれます。

担当者が変わったタイミングでの引き継ぎがうまくいかない現場を見ていると、多くの場合、それまでの担当者とのやり取りが記憶頼みで、感謝も指摘も口頭で済ませてしまっていたことが原因になっています。フィードバックをメールやチャットのテキストとして残しておくと、担当者交代の際の引き継ぎ資料としても機能します。

習慣7: 単発の取引ではなく、長期的なパートナーとして棚卸しする

7つ目の習慣は、開発会社との関係を、個別のプロジェクトの集合としてではなく、継続的なパートナーシップとして捉え、定期的に棚卸しをすることです。開発会社と長期的にうまく付き合う方法で扱ったとおり、システムは納品して終わりではなく、何年にもわたって稼働し続けます。その間、保守費の見直しや、担当者の交代、契約更新のタイミングなど、単発のプロジェクトでは意識しなくてよかった論点が次々と発生します。

良い発注者は、こうした論点が発生するたびに場当たり的に対応するのではなく、半年や1年といった周期で、関係全体を棚卸しする機会を意識的に作っています。棚卸しの際に確認したい項目を整理します。

この最後の項目は、開発会社を疑うためのものではなく、ベンダーロックインの状態を発注者自身が認識しておくためのものです。依存すること自体が悪いのではなく、依存していることに気づかないまま関係を続けることがリスクなのです。棚卸しの結果、関係が良好であればそのまま継続すればよく、値上げ交渉や担当者交代への備え、あるいは万一の場合の解約の伝え方まで、あらかじめ考えておくことで、いざというときに慌てずに対応できます。

トラブルが起きたときも、良い発注者の姿勢は変わらない

ここまで紹介した7つの習慣は、平時のつきあいかたを想定したものですが、トラブルが起きたときにこそ、その真価が試されます。トラブル時の交渉術で扱ったとおり、納期遅延や不具合対応の食い違いが起きたとき、感情的に開発会社を責め立てても、問題は解決に近づきません。

良い発注者は、トラブルが起きたときも、これまでの7つの習慣を土台にして交渉に臨みます。要件を自分の言葉で説明できていれば、何が合意事項からズレたのかを具体的に指摘できます。書面での記録が残っていれば、水掛け論を避けられます。検収基準が明確であれば、不具合が「仕様なのか、不具合なのか」の切り分けがしやすくなります。そして、それまで感謝と指摘の両方を伝えてきた関係であれば、トラブル時にも冷静な対話の土台が保たれています。

逆にいえば、平時に7つの習慣を実践していない発注者ほど、トラブル時の交渉が難航しやすいということでもあります。トラブル対応は、日々の関わり方の延長線上にあります。契約書に書いておくべきトラブル条項のような、あらかじめの備えも重要ですが、条項だけに頼らず、日々の習慣そのものがトラブルへの最良の予防策になります。

開発会社側から見た「良い発注者」

このカテゴリは、うちシスなびを運営する株式会社ゼットリンカー自身が受託開発事業を営む開発会社であるという立場上、開発会社に不利な情報も含めて中立に書くことを意識してきました。この最終回では、その開発会社側の視点から見た「良い発注者」についても触れておきます。

開発会社にとって、良い発注者と仕事をすることは、単に気分が良いという以上の意味を持ちます。要件が明確な発注者からの依頼は、見積もりの精度が上がり、手戻りが減り、結果として同じ予算でもより多くの価値を提供できます。窓口が一本化されている発注者との仕事は、コミュニケーションコストが下がり、開発会社側のリソースをより多く実装や設計に振り向けられます。進捗確認を適切な頻度で行ってくれる発注者は、問題の早期発見に協力してくれる存在でもあります。

つまり、良い発注者になることは、開発会社に対する一方的な「配慮」や「気遣い」ではなく、開発会社が持つ実力を、無駄なく自社のシステムに反映してもらうための、発注者自身にとって合理的な戦略なのです。この構造を理解している発注者は、開発会社に対して遠慮しすぎることもなく、かといって高圧的になることもなく、対等なパートナーとして向き合うことができます。

7つの習慣、逆から見るとよくある落とし穴

7つの習慣は、裏返すと「良くない発注者」が陥りがちな落とし穴の一覧にもなります。ここまでのカテゴリ19本を振り返りながら、それぞれの習慣が欠けたときに何が起きるかを整理しておきます。自社の現状を点検する際のチェックリストとして使ってください。

この表を眺めると分かるとおり、7つの習慣は独立した7つの技術ではなく、互いに補い合う一つのまとまりです。どれか一つだけを完璧にこなしても、他が欠けていれば穴が生まれます。たとえば要件を精緻に言語化できていても(習慣1)、それを書面で残していなければ(習慣4)、時間が経つにつれて「言った内容」が曖昧になっていきます。逆に、書面化を徹底していても、進捗を定期的に確認していなければ(習慣3)、その書面が実際にどう反映されているかを追跡できません。

完璧な発注者を目指さなくていい

ここまで7つの習慣を紹介してきましたが、最後に強調しておきたいのは、これらすべてを最初から完璧にこなす必要はないという点です。良い発注者とは、一度も失敗しない発注者のことではありません。要件の伝え方が曖昧になってしまうことも、検収基準を決め忘れて当日に慌てることも、実際の現場では起こり得ます。

大切なのは、うまくいかなかったときに「なぜうまくいかなかったのか」を振り返り、次の依頼や次のプロジェクトで同じ失敗を繰り返さないようにする姿勢です。この振り返りの積み重ねこそが、7つの習慣を血肉化していくプロセスと言えます。開発会社側も、完璧な発注者を期待しているわけではありません。むしろ、失敗を認めて改善しようとする発注者との方が、長期的に良い関係を築きやすいと感じている開発会社は少なくないはずです。

また、7つの習慣のすべてを自分ひとりで背負う必要もありません。社内に上長や他部署の協力者がいるなら、窓口の一本化を周知する際に協力してもらう、検収の際に業務側の視点で確認してもらうといった形で、役割を分担することも可能です。ひとり情シスであっても、すべてを孤独に抱え込む必要はなく、7つの習慣を実践する過程そのものを、周囲を巻き込むきっかけとして使うこともできます。

おわりに: ひとりでも、孤独に立ち向かわなくていい

うちシスなびは、ひとり情シスや総務兼任でシステムを担当する方に向けて、承継・脱Excel・脱ノーコード頼み・脱ベンダーロックイン・AI活用・外注のはじめかた・そして開発会社とのつきあいかたという7つのカテゴリで、実務のヒントを届けてきました。この記事は、その最後のカテゴリの、最後の記事です。

システム担当者としての悩みの多くは、専門知識の不足そのものよりも、「この判断が正しいのか、誰にも相談できずに孤独に決めている」という状況から生まれます。開発会社との関係も同じです。何を確認すればいいのか分からないまま検収印を押し、値上げの相談に「はい」と答えるしかないと思い込み、担当者の交代を黙って受け入れる——。そうした孤独な判断の積み重ねが、気づかないうちに自社にとって不利な状況を作ってしまうことがあります。

7つの習慣として整理した内容は、特別な専門知識を必要とするものではありません。要件を言葉にする、窓口を決める、進捗を聞く、依頼を書面に残す、検収の基準を決めておく、感謝と指摘を伝える、関係を定期的に見直す。どれも、仕組みとして知っていれば、明日から実践できることばかりです。

このカテゴリの他のテーマも、状況に応じてあわせてご覧ください。丸投げ発注がうまくいかない構造は丸投げ発注が失敗する理由と発注者の役割、進捗報告から危険な兆候を見抜くには進捗報告の見方: 危険な兆候の見抜き方、開発会社の返信が遅く不安なときは開発会社の返信が遅い・つかまりにくい。関係が壊れる前にできる対処、リリース後の運用体制の分担は運用フェーズの体制: 社内と開発会社の役割分担で扱っています。

ひとりで担当していても、正しい知識と仕組みがあれば、孤独に立ち向かう必要はありません。このカテゴリで扱ってきた19本の記事、そしてうちシスなび全体で扱ってきた記事の数々が、その仕組みの一部になれば幸いです。開発会社との関係に迷ったときは、いつでもこのサイトに戻ってきてください。