LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

頼んだものと違うものが上がってきた。テストの段階になって、そもそもの前提が食い違っていたと分かった——。外部人材に開発を頼む現場では、こうした行き違いが起こりがちです。IPA（情報処理推進機構）の要件定義ガイドは、ソフトウェア開発プロジェクトを対象にした2016年の調査をもとに、工期遅延の理由の50％以上が要件定義の問題にあるとしています。^*1 外部人材活用の要件不足とは、任せる作業、求めるスキル、成果の基準のどれかが言葉になっていないまま、依頼を始めてしまう状態を指します。

要件を依頼の前に書き出しておけば、頼む側と受ける側が同じ前提で作業を始められます。ただし万能ではなく、どれだけ丁寧に書いても、依頼の時点では決めきれない事項が残ります。本記事では、開発の現場を回すマネージャーに向けて、要件不足で起きる行き違い、依頼の前に書く3つのこと、あいまいな言葉の直し方、決めきれない事項の扱い、そして外部人材に頼むときにつまずきやすい点を整理します。

外部人材活用の要件不足とは

外部人材に開発を頼むときの要件は、大きく3つに分けられます。1つ目は任せる作業で、どのシステムの、どの範囲を担当してもらい、どこから先は担当に含めないかです。2つ目は求めるスキルで、その作業をこなすのにどんな経験と技能が要るかです。3つ目は成果の基準で、何がどうなっていれば作業が終わったとみなすかです。

IPAの「ユーザのための要件定義ガイド 第2版」は、改訂にあたり、発注する企業と開発会社の双方の委員に要件定義の問題をあらためて挙げてもらい、分類しています。その中には「成果物に抜け・漏れ・あいまいが存在する」「そもそも開発スコープがあいまいである」「要件定義の体制が不十分である」といった問題が並びます。^*1 3つの要素に当てはめると、スコープのあいまいさは任せる作業の不足に、体制の不十分さは求めるスキルの不足に、抜け・漏れ・あいまいは成果の基準の不足にあたります。

要件定義ガイドは主に企業の情報システムの開発を想定した資料です。それでも、頼む側の頭の中にある前提を文書にして相手に届けるという点は、フリーランスや業務委託のエンジニア1人に頼む場合も変わりません。要件不足は、頼む相手の人数や契約の形にかかわらず起こります。

要件不足で起きる行き違い

要件定義ガイドは、要件を記録した文書があいまいだと、定義した結果が正しく伝わらず、開発されたシステムに仕様漏れや仕様誤りが入り込むとしています。そのうえで、起こる問題として次の3つを挙げています。^*1

• 設計工程以降の成果物のレビューで指摘が多発し、設計期間が延びる
• 利用部門が参加するテストで指摘が多発し、要件定義にまでさかのぼる大幅な手戻りになる
• 本稼働後に、機能の実装漏れや仕様誤りの指摘が多発し、業務運用に支障をきたす

3つの問題は、見つかる時期が後になるほど直す範囲が広がります。設計のレビューで見つかれば設計書を直して済むこともありますが、テストで見つかれば要件にまで戻り、本稼働後なら業務そのものに影響が出ます。ガイドは、こうした機能不足への対応でシステム開発の遅延や費用の増加が起き、システム導入時に期待した投資対効果が得られなくなるとしています。

外部人材活用の失敗というと、頼んだ相手の技量に目が向きがちです。しかし、頼んだ作業の範囲や完了の基準が文書になっていなければ、相手が優れた技術者でも、頼む側の想定どおりの成果にはなりません。要件定義ガイドも、発注する側と受ける側の責任や役割分担が不明確なまま進め、紛争や訴訟に発展するケースが増えていると指摘しています。^*1 起きてしまった失敗の原因をたどる手順は「外部人材活用の失敗の原因分析、直接原因と根本原因の違い」で扱っています。

依頼の前に書く3つのこと

要件を書くのは、頼む側の役目です。IPAの「情報システム・モデル取引・契約書（第二版）」も、要件定義書は発注者が作成し、開発会社は専門的な知識と経験に基づいて調査・分析・整理・提案・助言などで支援するという形を定めています（第14条）。^*2 外部人材に要件の整理を手伝ってもらうことはできますが、何を任せ、何をもって終わりとするかを決めるのは頼む側です。

3つの要素ごとに、書いておきたい中身と書き方の例をまとめると次のようになります。

任せる作業では、担当に含めない作業まで書いておくのが要点です。範囲の外にある作業は、書いておかないと「当然やってくれるもの」と「頼まれていないもの」に解釈が分かれます。本番環境への反映、既存データの直し、利用者への説明などは、どちらが受け持つかを一行ずつ書いておきます。

求めるスキルは、任せる作業から逆算して書きます。要件定義ガイドは、要件定義に必要な業務・技術のスキルを持つ人員を外部から調達することがほとんどだとしています。^*1 外から人を迎えるのが普通だからこそ、どの作業にどのスキルが要るかを頼む側が言葉にしておくと、候補者の経歴と照らし合わせやすくなります。

成果の基準は、後回しにされやすい項目です。作業の途中で基準を決めようとすると、すでにできあがった成果物に合わせた基準になりがちです。依頼の時点で、何を渡してもらい、どう確かめるかまで決めておきます。

あいまいな言葉の直し方

要件定義ガイドは、要件定義の文書からあいまいさ（内容が不明確、複数の解釈ができる、など）を除くための注意点を表にまとめています。外部人材への依頼文にもそのまま使えるのは、次の3つです。

• 抽象的な単語は、定義を明確にして使う。特に「〇〇管理」が何をすることかをはっきりさせる
• 形容詞や副詞を使ったときは、補足の説明を付ける
• 箇条書きにできるものは箇条書きに、表にできるものは表にする

ガイドは形容詞と副詞の例として、「大量のハードディスク容量」を「ハードディスク容量≧100GB」に、「高速で動作する」を「入力後1秒以内に応答がある」に直す書き方を示しています。^*1 「使いやすい」「速い」「きれいなコード」のような言葉は、書いた人と読む人で思い浮かべる中身が違います。数値や具体的な条件に置き換えられない言葉は、成果の基準に使わないようにします。

「〇〇管理」も読み違いが起きやすい言葉です。「在庫管理の改修」と書いたとき、頼む側は在庫数の表示の直しを考えていても、受け取った人は入出庫の記録や棚卸しの機能まで含めて見積もるかもしれません。ガイドは、業界や企業、事業部門に固有の言葉をまとめておき、関係者の間の齟齬をなくすよう勧めています。^*1 社内だけで通じる言葉は、依頼文とは別に用語の一覧にして渡しておくと、読み違いを減らせます。

依頼の前に読んでもらう

書いた依頼文は、渡す前に第三者に読んでもらいます。要件定義ガイドは、定義すべき内容は多岐にわたるため抜け漏れを完全に防ぐのは難しいとしたうえで、過去の案件などから不具合が入り込む観点を整理し、レビュー観点としてまとめてからレビューすれば、抜け漏れを抑えられるとしています。^*1

外部人材への依頼文なら、観点を3つの要素にそろえると使いやすくなります。「担当に含めない作業が書いてあるか」「求めるスキルが任せる作業と結び付いているか」「成果の基準に数値か確かめ方があるか」の3点です。読む人には、その作業を実際に担当したことのある社内のエンジニアが向いています。

依頼を受けた外部人材にも、着手の前に読んでもらいます。モデル契約書は、要件定義書の作成に必要な事項を明確にしたり内容を確かめたりする場として要件定義検討会を置き、発注者と開発会社は検討結果に拘束されるとしています（第16条）。さらに、できあがった要件定義書が検討会での決定事項に合っているかを双方が点検し、責任者の記名押印で確定する手続きを定めています（第17条）。第17条の解説は、要件が曖昧なままでは正確な見積りが困難になり、その後の開発段階で問題が生じるおそれがあるとしています。^*2

1人の外部人材に頼む場合でも、依頼文を一緒に読み合わせ、質問が出た箇所を書き直し、合意した版を日付つきで残しておく進め方は取り入れられます。受ける側から出た質問は、そのまま要件不足の箇所を教えてくれる材料になります。

決めきれない事項の扱い

どれだけ丁寧に書いても、依頼の時点で決めきれない事項は残ります。モデル契約書の解説も、実際のプロジェクトでは、ある程度の積み残し事項を残したまま次のフェーズに進まざるを得ないことが多いとしています。

そこで第36条は、未確定事項の内容とその確定予定時期、確定によって委託料や作業期間などの条件の変更が要る場合に発注者がそれを受け入れることなどを、書面にしておく手続きを定めています。^*2 決まっていないことを伏せたまま依頼を始めるのではなく、「ここはまだ決まっていない」「いつ決める」「決まったら作業が増える場合がある」と先に書いておく考え方です。

外部人材への依頼文でも、未確定の事項を一覧にしておくと、受け取った人は見積もりに幅を持たせるか、決まるまで手を付けない部分として分けておくかを判断できます。決まった後に作業の中身を変えるときは、口頭で済ませず、変更の内容と理由を書いた文書で伝えます。途中で変わった仕様を段階に分けて記録する方法は「外部人材活用の失敗を減らす、仕様変更を4段階で残す記録」で紹介しています。

つまずきやすい点

一つ目は、要件を打ち合わせの口頭だけで伝えて終わりにすることです。その場では伝わったように見えても、文書が無いと、作業の途中で解釈が分かれたときに、どちらの理解が正しいかを確かめる手がかりがありません。話した内容は、その日のうちに依頼文へ書き足しておきます。

二つ目は、求めるスキルを経験年数や言語名だけで書くことです。年数や言語名だけでは、任せる作業をこなせるかどうかは判断できません。前の表のように、任せる作業に近い作業を担当した経験があるかという形で書くと、面談で確かめる内容とも結び付けやすくなります。

三つ目は、成果の基準を「見れば分かる」で済ませることです。頼む側にとって当たり前の品質も、初めて加わる外部人材には分かりません。基準が無いまま納品を受けると、受け入れるかどうかの判断が担当者ごとに変わり、外部人材活用の失敗として後から問題になりやすくなります。

まとめ：外部人材への依頼で確かめておきたい3つの点

外部人材活用の要件不足を防ぐうえで、確かめておきたい点は3つに整理できます。第一に、任せる作業を、担当に含めない作業まで書くこと。第二に、求めるスキルを、任せる作業から逆算して書くこと。第三に、成果の基準を数値や確かめ方で書き、決めきれない事項は一覧にして残すことです。この3点を踏まえておけば、「頼んだものと違うものが上がってきた」という事態を避けやすくなります。依頼文の書き方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」（PDF）（https://www.ipa.go.jp/archive/publish/qv6pgp0000000wrt-att/000079352.pdf）。出典：独立行政法人情報処理推進機構 社会基盤センター（2019年）。1.1.3（工期遅延理由の分析〔JUAS「ソフトウェアメトリックス調査2016」をもとに作成〕、発注する側と受ける側の関係）、2.2.1 問題の抽出と整理、5.1.1(2) 文章のあいまいさを排除し要求を正しく伝達する（表5.1）、5.2.1(1) 組織的なレビュー、6.2.1 勘どころ①、6.2.8 冒頭を参照（2026年9月確認）
2. *2　参考：IPA「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第二版＞（2025年4月8日更新）」（Word）（https://www.ipa.go.jp/digital/model/ug65p90000001ljh-att/000087884.docx）。出典：第14条（要件定義作成支援業務の実施）とその解説、第16条（要件定義検討会）とその解説、第17条（要件定義書の確定）とその解説、第34条（システム仕様書等の変更）、第36条（未確定事項の取扱い）とその解説を参照（2026年9月確認）
3. *3　参考：IPA「情報システム・モデル取引・契約書（第二版）」（https://www.ipa.go.jp/digital/model/model20201222.html）。出典：公開ページ。第二版の更新日（2025年4月8日）を参照（2026年9月確認）

Tweet