LASSIC Media らしくメディア

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

上流工程に外部の力を借りると、発注側には何が残るのか。フリーランス活用では、ここが決まらないと段取りが組めません。

手がかりになる資料があります。IPA（独立行政法人情報処理推進機構）のSEC（ソフトウェア・エンジニアリング・センター）がまとめた冊子「実務に活かすIT化の原理原則17ヶ条」です。*1 第1章に置かれているのが「超上流から攻めるIT化の原理原則17ヶ条」で、資料はこれを「「超上流」フェーズを発注側、受注側の双方がうまく進めるためのポイント」をまとめたものだと説明しています。*1

超上流の範囲を資料は細かくは定めておらず、「要件定義フェーズのような超上流工程」という書き方をしています。*1 この記事では超上流を、構想・企画と要件定義を指す語として使います。この決め方は記事のものです。

断りが2つあります。1つは、資料に「フリーランス」という語が出てこないことです。資料は発注者と受注者という役割で書かれ、受注者が会社か個人かを分けていません。そこでこの記事は、個人に頼む場合も受注者の側に当たるとみなして読みました。この当てはめはこの記事のものです。2つめは、資料が「17ヶ条は原文をそのまま使用する。」「17ヶ条を使用・参照する場合出典を明記する。」という条件を付けていることです。*1 原理原則と行動規範は原文のまま引きます。参照したのは平成22年10月12日発行の第1版です。

資料が挙げるのは、独自でできない場合の活用

まず資料の作りです。17の項目は「原理原則」「基本的な考え方」「行動規範」でできています。*1 原理原則が短い言い切り、基本的な考え方がその背景、行動規範が具体的な行動です。資料は行動規範を「行動規範は、原理原則に基づいて、受注者・発注者のそれぞれが具体的にどのように行動すべきかを示したものです。」としています。*1 以下、資料の番号で原理原則9のように呼びます。

原理原則9は「要件定義は発注者の責任である」です。*1 その基本的な考え方は条件付きです。「発注者によっては、人的資源、経験、スキルなどの問題で、独自で実施できない場合もあります。」とあり、「このような場合、受注者をうまく活用し、不足しているシステム知識を補うことが有効であり、受注者に一部委託し、支援を受けることもあります。」と続きます。*1 有効だとされたのは、独自で実施できない場合です。行動規範には条件が付かず、「発注者は、要件定義段階で受注者をうまく活用する。」とだけあります。*1

そのあとに条件が付きます。「ただし、受注者が支援する場合であっても、要件定義で作成した成果物に対する責任は発注者にあります。」*1 手を借りることと責任を渡すことは別だ、と資料が明記した箇所です。

何を省いてよいかの基準は資料に無い

相手に何をどこまで伝えるのか。フリーランス活用で迷うところですが、資料は減らしてよい範囲の基準を示していません。

原理原則17は「要件定義は説明責任を伴う」です。*1 「システム開発の受託側から見た原則は「受託した要件として、書いてあるものは実現させる。書かれていないものは作らない。」ことです。」とあり、「基本的には当たりまえの前提や例外処理であっても漏れなく伝達する必要があります。」と続きます。*1

原理原則12は「表現されない要件はシステムとして実現されない」です。*1 基本的な考え方は、「行間を読め」や「言わなくても常識」で済ませた要件が、発注者と受注者のトラブルの原因になる、としています。*1 原理原則14は「「今と同じ」という要件定義はありえない」で、「「同じ」という言い方が正しく伝わるのは、具体的なプログラム、コード体系、テーブルなどそのとき存在する個別の形を持ったものについてです。」とし、「現行システムをどう使っているか、という点から調査をしなければなりません。」と求めます。*1 コード体系は社内で決めた番号や記号の付け方、テーブルはデータを入れる表、次の表に出るモックアップは画面や帳票の見本です。この3つの言い換えはこの記事のものです。

3行とも発注者あてで、表現する、調査する、説明する、という作業です。資料は社内と社外を比べていないので、社外だと量が増えるとまでは書かれていません。

社外委託の手続きが構想・企画の時間を削った例

同じ冊子の第4章に、上流工程の社外委託をやめた企業の例があります。「「超上流」強化、予算オーバーを減らす」です。*1 資料は第4章を日経コンピュータの記事をもとに編集したものだと注記しています。*1 外部の力をすすめる例ではなく、やめた側の例です。

この製造業のIT部門は「システム化の構想・企画検討や要件定義といった超上流フェーズの作業を、社外のコンサルタント会社などに依頼することをやめ、自前で取り組むことにした。」とされます。*1 理由は「ボトルネックになっていたのは、超上流フェーズにおける一部の作業を、社外のコンサルタント会社に委託していたことだった。」で、その中身は「社外に発注する際は、経営会議で承認を得る必要があった。」です。*1

稟議書を作って会議にかけ、承認をもらうまでに3カ月かかることがあった、とされます。*1 そして「構想・企画フェーズであればどんなに時間がかかったとしても6カ月で終わらせる必要があった。」という締切があり、「この6カ月のうち稟議や承認に3カ月かかるので、構想・企画には実質3カ月しか取れないプロジェクトが少なくなかった。」とあります。*1 すべてではなく、少なくなかった、という書き方です。

読み取れるのは、外の人の力量ではなく、社外へ委託するための社内手続きが構想・企画の時間を削っていた、ということです。この読み方はこの記事のものです。1社の例で、しかも要件定義より前の構想・企画の話なので、外注の可否が決まるわけではありません。

つまずきやすい難所

フリーランス活用で引っかかる点を2つ挙げます。この2つを選んだのはこの記事です。

1つめは、資料の条件と現場の順番が逆になりやすいことです。資料が活用を有効だとしたのは、独自で実施できない場合でした。*1 実際には人手が足りないから頼むという順番で始まるので、表の3行が誰の作業として残るのかが決まりません。

2つめは、頼むまでの日数が工程を食うことです。第4章では、稟議から承認までに3カ月かかることがあったとされます。*1 手続きの日数を数えずに外部を前提にすると、上流工程に残る日数が削られます。この見方はこの記事のものです。

社外に頼む前に決めておきたい点

フリーランス活用を決める前に3つを決めておきます。この3つはこの記事のもので、資料が契約条項を示すわけではありません。

1つめは、表の3行を誰がやるのかを割り振ることです。いずれも発注者あての行動規範なので、*1 相手に渡すのか自社に残すのかを決めないと、どちらもやらないまま進みます。

2つめは、承認までの日数を数えることです。第4章で3カ月かかっていたのは、稟議書を作って会議にかけ、承認をもらうまででした。*1 自社で同じ範囲に何日かかるのかを出し、上流工程に残る日数を引き算します。

3つめは、渡す文書をそろえる順番です。資料は漏れなく伝達することを求め、*1 省いてよい基準を示していません。現行の仕様書、使われ方の調査記録、例外処理の扱いの順に、いつ誰が用意するのかを決めます。この並べ方はこの記事のものです。

要件と要求の言葉の使い分けは、別の記事「要件定義と要求定義の違い」で整理しました。

まとめ：借りても、責任と伝える範囲は残る

冒頭の問いは、上流工程に外部の力を借りると発注側に何が残るのか、でした。答えは3つです。第一に、資料が活用を有効だとしたのは「独自で実施できない場合」で、その場合に「受注者に一部委託し、支援を受けることもあります。」としています。*1 第二に、責任は残ります。「ただし、受注者が支援する場合であっても、要件定義で作成した成果物に対する責任は発注者にあります。」とあります。*1 第三に、伝える範囲も残ります。資料は「基本的には当たりまえの前提や例外処理であっても漏れなく伝達する必要があります。」とし、*1 省いてよい基準を示していません。表現する、調査する、説明するは、いずれも発注者あての行動規範です。加えて第4章には、稟議から承認までに3カ月かかることがあり、構想・企画に実質3カ月しか取れないプロジェクトが少なくなかった、という1社の例があります。*1 以上から、上流工程のフリーランス活用を決める前に、表の3行を誰がやるのかと、承認までに何日かかるのかを出しておくことになります。この整理はこの記事のもので、資料が段取りを示すわけではありません。

よくある質問

出典

1. *1　参考：IPA-SEC「実務に活かすIT化の原理原則17ヶ条」（PDF・平成22年10月12日第1版）（https://www.ipa.go.jp/archive/publish/qv6pgp0000000zef-att/000005141.pdf）。出典：独立行政法人情報処理推進機構 ソフトウェア・エンジニアリング・センター「実務に活かすIT化の原理原則17ヶ条」（平成22年10月12日第1版第1刷発行）。17ヶ条の利用方法（原文をそのまま使用すること、出典を明記すること）、原理原則・基本的な考え方・行動規範という構成と行動規範の定義、超上流工程の書き方、原理原則9「要件定義は発注者の責任である」、原理原則12「表現されない要件はシステムとして実現されない」、原理原則14「「今と同じ」という要件定義はありえない」、原理原則17「要件定義は説明責任を伴う」の各記述、および第4章4.3「「超上流」強化、予算オーバーを減らす」（超上流フェーズの内製化、社外発注に経営会議の承認が必要だったこと、稟議と承認に3カ月かかることがあったこと、構想・企画フェーズの6カ月という締切と実質3カ月しか取れないプロジェクトが少なくなかったこと、第4章が日経コンピュータの記事をもとに編集されたものである旨の注記）の一次情報として（2026年9月確認）

Tweet