LASSIC Media らしくメディア

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

内製化支援を頼むとき、「伴走してもらう」という言い方をよく使います。ただ、この言葉だけでは、自社の担当者がどこまで手を動かすのかが決まりません。打ち合わせに出るだけなのか、要求仕様を自分たちで書くのか。手がかりになるのが、IPA（独立行政法人情報処理推進機構）が公開している「ソフトウェア開発分析データ集」です。*1 発注する側の関わり方を、9つの項目に分けて記録しています。*1

この項目を見ると、伴走の中身を自社側で先に決められます。ただし、この資料は開発案件の実績を集める項目を定めたもので、内製化支援というサービスの提供範囲や期間を決めた文書ではありません。本記事では、開発の現場を預かるマネージャに向けて、IPAが記録している9つの項目、関与と経験の違い、なぜ「伴走」だけでは決まらないのか、どう決めるのか、つまずきやすい点、そして外部に頼むときに確認しておきたい点を整理します。

IPAが記録している発注側の関わり方

IPAの「ソフトウェア開発分析データ集2022」は、企業から提供された開発案件の実績を集計した資料です。発行は社会基盤センターで、どの案件からも同じ項目を集められるよう、項目ごとに書き方と選択肢が決められています。*1

そのなかに「ユーザ要求管理」という節があります。*1 ここでいうユーザとは、システムを使う側、つまり発注する側の企業のことです。自社の担当者がどう関わったかを、案件ごとに記録します。

並べてみると、伴走という一語で済ませていたものが、関与の度合い、経験、役割分担の明確さ、承認の有無、理解度、人数という別々の項目に分かれていることがわかります。*1 なお受け入れ試験とは、完成したシステムを発注側が使ってみて、注文どおりかを確かめる作業のことです。

関与の度合いと経験の違い

502番は「ユーザ担当者の要求仕様定義への関与度合い」を記録します。*1 選択肢は4段階で、十分に関与、概ね関与、関与が不十分、未関与です。*1 自社の担当者がどこまで手を動かすかは、この4つのどれを選ぶかで決まります。

一方、503番と504番は経験を記録します。503番は「ユーザ担当者のシステム経験の度合い」、504番は「ユーザ担当者の対象業務に関する経験の度合い」です。*1 どちらも十分に経験、概ね経験、経験が不十分、未経験の4段階です。*1

関与と経験は別の項目です。打ち合わせに毎回出ていても、システムの経験が浅ければ503番はaやbになりません。逆に、業務を知り尽くしていても、要求仕様を書く作業に入らなければ502番はaやbになりません。

503番には、判断の例も添えられています。システムの説明に対して、ストレス無く話が通じるならa、概ね話が通じるならb、多くの点で説明を要するならc、全てを説明する必要があるならdです。*1 504番は、業務についての質問にすぐ答えられるか、その答えが正確かで4段階に分かれます。*1

なぜ「伴走」だけでは決まらないのか

資料には「伴走」という言葉は出てきません。出てくるのは、関与・経験・役割分担・承認・理解度・人数という記録項目です。*1 言い換えると、伴走という言葉はこの9項目のどれを指しているのかを示していません。

とくに見落としやすいのが、承認を記録する2つです。506番は要求仕様に対するユーザ担当者の承認の有無、508番は設計内容に対するユーザ担当者の承認の有無で、どちらも有りか無しかの2択です。*1 一緒に作業していても、承認する人を置いていなければ「無し」になります。

もう1つが511番で、実質的なキーマン、つまり要件決定者の人数を記録します。*1 人数を書く欄なので、決める人を置いていない案件では、この欄を埋められません。

この段落の指摘は資料に書かれていることではなく、9つの項目が別々に分かれている事実から筆者が導いたものです。伴走を頼むかどうかの前に、自社側が9項目のどこをどこまで持つのかを決めておく必要がある、ということになります。

どう決めるのか

決め方は、502番の4段階から1つ選ぶところから始まります。要求仕様を自社で書ききるのか、大枠だけ書くのか、相手に書いてもらって内容を確かめるのか。ここを決めると、必要な打ち合わせの回数も見えてきます。

次に、要求仕様づくりと打ち合わせに誰を出すかを決めます。システムの経験がある人と、業務の経験がある人は、同じ人とは限りません。503番と504番が別の項目になっているのは、その2つを別々に記録する必要があるからです。*1

そのうえで、承認する人と要件を決める人を名前で決めます。「受注管理システムの要求仕様は営業企画の課長が承認」「要件を決めるのは情報システム部の2名」——ここまで書ければ、506番・508番・511番に書ける状態になります。

つまずきやすい難所

一つめは、伴走という言葉のまま契約に入ることです。9つの項目のどこを自社が持つのかが決まっていないと、打ち合わせに出ているだけで関与したつもりになります。

二つめは、この資料を内製化支援の契約書の代わりに使おうとすることです。これは開発案件の実績を集めるための項目であって、支援の提供範囲や期間を定めた文書ではありません。内製化支援を受ければどうなるかについて、今回参照した資料に記載はありません。

三つめは、関与の段階を上げれば自社だけで回せるようになると考えることです。資料が記録しているのは、その案件で実際にどう関わったかまでです。関与を上げた結果どうなるかは、今回参照した資料に記載はありません。

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

外部の要員に入ってもらう前に、9つの項目のうち自社が持つものを書き出して伝えてください。「要求仕様は自社で大枠まで書く」「設計内容の承認は情報システム部長」と、このくらい具体的に書ければ十分です。外部の要員（自社で雇わず、作業ごとに契約して働いてもらう人。フリーランスや請負の会社を含みます）に頼む場合、任せる作業と自社が持つ作業がはっきりしているほど、話が早く進みます。

承認する人と要件を決める人は、社内に置いたままにしてください。506番・508番・511番は、いずれも発注する側の担当者について記録する項目です。*1 この3つは自社の担当者について書く欄なので、社外に任せると書く対象がいなくなり、欄を埋められません。

正社員の採用と外部の要員のどちらを選ぶかも、この9項目のどこを自社で持ち続けたいかで変わります。業務の経験を社内に残したいなら採用、特定の期間だけ手を増やしたいなら外部の要員、という分け方になります。

社内に何が残るかという話は内製化支援 自走を目指す前の3つの人材不足で扱っています。

どの工程を社内で担っているかはシステム開発の外部委託｜設計・実装・テストで63.4％にまとめました。

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

抜けるときに何を残してもらうかはSES契約終了で決める6項目｜アクセス権と知財の帰属にあります。

まとめ：伴走を頼む前に決める3つのこと

内製化支援の伴走は、「一緒にやる」という言葉のままでは中身が決まりません。IPAの記録項目に当てはめると、決めておくことは3つに整理できます。第一に、要求仕様への関与を、十分に関与・概ね関与・関与が不十分・未関与の4段階のどれにするかを選ぶこと。*1 第二に、システムの経験がある人と業務の経験がある人は別に記録されるので、誰を出すのかを分けて決めること。*1 第三に、要求仕様と設計内容を承認する人と、要件を決める人の人数を自社側で決めておくことです。*1 この3点を踏まえておけば、「打ち合わせには出ていたのに、要求仕様は相手が書いたままだった」という事態を避けやすくなります。9つの項目のどこを自社が持つかを決めるところまでは社内でできます。その先、手を動かす人が社内にいなければ、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「ソフトウェア開発分析データ集2022」（PDF）（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：IPA「ソフトウェア開発分析データ集2022」。独立行政法人情報処理推進機構 社会基盤センター発行。A5.2.6「ユーザ要求管理」のデータ項目502から509まで、および511_要件決定者の人数の定義と選択肢の一次情報として。本書の著作権は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