LASSIC Media らしくメディア

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

外部人材活用がうまくいかなかった。そう感じることはあっても、何が起きたのかを言葉にしようとすると、意外と手が止まります。「認識がずれていた」「思ったより時間がかかった」——このくらいしか出てこないと、次の依頼で同じことが起きます。

ここで参考になるのが、IPA（独立行政法人情報処理推進機構。情報処理の分野で国が設立した法人）が公開している「ソフトウェア開発分析データ集2022」です。*1 複数の企業から集めた開発案件の実績をまとめた資料で、案件で起きたことを記録するための項目と選択肢が決められています。*1

この資料には失敗事例は載っていません。載っているのは、何が起きたかを同じ言葉で書き残すための形です。本記事は、開発の現場を回しているマネージャに向けて、IPAが決めている仕様変更の記録の仕方、「不明」という選択肢が意味すること、依頼のたびに何を残しておくか、つまずきやすい点、外部に頼むときの確認事項を順に整理します。

IPAは仕様変更をどう記録しているか

「ソフトウェア開発分析データ集2022」には、仕様変更がどのフェーズで起きたかを記録する項目があります。*1 フェーズとは開発の段階のことで、システム化計画、要件定義、基本設計、詳細設計、製作、結合テスト、総合テストという順に進みます。*1

注目したいのは、仕様変更の書き方が4段階に分かれていることです。*1 変更なし、軽微な変更が発生、大きな変更が発生、重大な変更が発生の4つ。*1 項目の定義には「工数への影響度合い」と書かれているので、*1 どれを選ぶかは、その変更で作業がどれだけ増えたかで決まります。

この4段階を、案件を記録する企業がフェーズごとに記入します。*1 つまり、同じ「仕様変更があった」でも、要件定義で軽微な変更があったのか、製作の途中で重大な変更が出たのかを分けて残せる形です。

「不明」という選択肢が意味すること

もう一つ見ておきたいのが、テストに関する3つの項目です。テスト計画書はあったか、その計画書のレビューはしたか、テスト工程で網羅性を測ったか。*1 どれも選択肢は、有り、無し、不明の3つです。*1 ここでいう網羅性とは、テストすべきもののうちどれだけを実際にテストしたかという割合のことです。*1

ここで大事なのは、3つめの「不明」です。無しは「やらなかった」、不明は「やったかどうか分からない」。記録が残っていなければ、あとから振り返っても不明にしかなりません。

しかも、資料が求める水準は高くありません。テスト計画書については「テスト計画が作成されていれば良い。テスト計画文書の形は問わない。」と補足されています。*1 一冊にまとまっていなくても、開発計画書の中にテスト計画を含める形でも構わない、とされています。*1

レビューも同じで、「誰によるレビューかは問わない。」と補足されています。*1 プロジェクト内のレビューでも、発注側のレビューでも、第三者のレビューでもよい、という書き方です。*1 それでも不明が残る理由はいくつも考えられます。記録を取る決まりがなかった、担当者が代わった、記録が委託先にしかない——どれであっても、あとから振り返る材料は手元にありません。

依頼のたびに残しておく3つ

ここまでを、外部に頼むときの形に置き換えます。依頼のたびに残しておくのは3つです。

1つめは、仕様変更が出たフェーズと、4段階のうちどれに当たるかです。*1 「要件定義で大きな変更が1件」という書き方で足ります。変更の中身まで書かなくても、どの段階でどれだけ作業が増えたかは残ります。

2つめは、テスト計画書とそのレビューの有無です。*1 資料はテスト計画の文書の形を問わないとしているので、*1 依頼書にテストの進め方を書いて、それをテスト計画として扱うこともできます。ただし、依頼書がテスト計画にあたるとまで資料が書いているわけではありません。

3つめは、網羅性を測ったかどうかです。*1 測った場合は、その割合まで残しておくと次の案件と比べられます。

この3つを残しておけば、次に外部人材活用を考えるときに、前回何が起きたのかを不明ではない言葉で話せます。なお、これを残せば失敗が減るかどうかについて、今回参照した資料に記載はありません。資料が定めているのは記録の形までです。

つまずきやすい難所

一つめは、うまくいかなかった理由を人の問題として書き残すことです。この資料の項目は、どのフェーズで、どれだけ作業が増えたかを記録する形になっています。*1 誰が悪かったかを書く欄はありません。

二つめは、変更の中身だけを残して、段階を残さないことです。中身の記録は案件ごとに違うので、並べて比べにくくなります。「要件定義で大きな変更」という形も一緒に残しておけば、案件をまたいで数えられます。

三つめは、この資料を評価の基準として使うことです。これは実績を記録して集計するための取り決めであって、外部に頼んだ相手を採点するための基準ではありません。採点の仕方について、今回参照した資料に記載はありません。

外注時に確認しておきたい点

外部に頼むときは、記録を残すことを依頼書に書いておいてください。「仕様変更が出たら、フェーズと4段階のうちどれかを残す」「テスト計画とそのレビューの有無を残す」「網羅性を測ったかどうかを残す」の3行で足ります。

残す役割を決めておくことも大切です。外部の要員（自社の社員ではなく、作業を委託して働いてもらう人。個人のフリーランスのほか、開発を請け負う会社に所属している人も含みます）に記録まで頼むのか、社内で残すのか。ここを決めないまま進めると、契約が終わったあとに「不明」だけが残ります。

正社員を採用するのか、外部の要員に頼むのかを次に決めるときも、この記録があるかどうかで話が変わります。前回どのフェーズで作業が増えたのかが分かっていれば、そのフェーズに強い人を探せます。分かっていなければ、また同じ条件で探すことになります。

工数をどこまで数えるかの決め方は外部人材活用のトラブル｜社内工数と外部委託工数の違いで扱っています。

外部に頼む範囲そのものの決め方は外部人材活用と内製化の進め方｜自社で高めたい機能は3つにまとめました。

契約が終わったあとの引き継ぎは業務委託の契約終了時、アクセス権と成果物の扱いで整理しています。

入ってもらう人のスキルの確かめ方は外部エンジニアのスキル確認、4つの軸で評価するにあります。

まとめ：次の依頼の前に決める3つのこと

外部人材活用がうまくいかなかったとき、それを次に生かせるかどうかは、記録が残っているかで決まります。決めておきたいことは3つです。第一に、仕様変更をフェーズごとに4段階で残すこと。*1 変更なし、軽微な変更が発生、大きな変更が発生、重大な変更が発生の4つで、どれを選ぶかは工数への影響度合いで決まります。*1 第二に、テスト計画書とそのレビューの有無を残すこと。*1 資料は文書の形を問わないとしているので、*1 依頼書にテストの進め方を書いて、それを計画として扱うこともできます。第三に、網羅性を測ったかどうかを残すこと。*1 そのうえで、この3つを誰が残すのかを先に決めてください。外部の要員に頼むのか社内で残すのかを決めないと、契約が終わったあとに「不明」だけが残ります。なお、記録を残せば失敗が減るかどうかについて、今回参照した資料に記載はありません。

よくある質問

出典

1. *1　参考：IPA「ソフトウェア開発分析データ集2022」（PDF）（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：IPA「ソフトウェア開発分析データ集2022」。独立行政法人情報処理推進機構 社会基盤センター発行。データ項目121（要求仕様変更の発生状況）と430〜432（テスト計画書の有無、テスト計画書のレビューの有無、網羅性測定の有無）の定義・選択肢・補足説明の一次情報として。IPAの資料は無断で改変したり配り直したりできないため、この記事は示された定義を引用し、表と図は内容をもとに作成した。資料の図表そのものは写していない（2026年9月確認）
2. *2　参考：IPA「ソフトウェア開発分析データ集2022」（公開ページ）（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。本編と業種編・サマリー版という構成と、収録されている指標の範囲の確認として（2026年9月確認）
3. *3　参考：IPA「ソフトウェア開発分析データ集」（https://www.ipa.go.jp/digital/software-survey/metrics/index.html）。年度ごとに公開されていることの確認として（2026年9月確認）

Tweet