LASSIC Media らしくメディア

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

要件定義を進められる人が社内にいない。かといって外部の人に頼むと、どこまで任せてよいのか分からない——。上流工程でフリーランス活用を考える現場では、こうした迷いが起こりがちです。上流工程とは、システムを作り始める前に、何のために何を作るのかを決める段階を指し、本記事では構想・企画と要件定義の2つを合わせてこう呼びます。

外部の人に加わってもらえば、社内に足りない経験や知識を補えます。ただし万能ではなく、外部に頼んでも、要件定義の責任は頼む側に残ります。本記事では、上流工程を外部に頼む側の担当者に向けて、頼めることと残る責任、相手に伝える内容、委託の手続きが日程に与える影響、そして外部に委託するときに確認しておきたい点を整理します。

上流工程のフリーランス活用とは

上流工程は、大きく2つの段階に分けられます。1つは構想・企画で、業務のどこをシステムにするのか、どれだけの予算と期間をかけるのかを決めます。もう1つは要件定義で、システムが備えるべき機能や、画面・伝票や報告書などの出力・データの中身を決めていきます。どちらも、その後の設計やプログラムの作成の土台になる段階です。

上流工程のフリーランス活用とは、この2つの段階の作業の一部を、社外の個人に業務委託で担ってもらうことです。業務の聞き取りを進めてもらう、要件定義書のたたき台を書いてもらう、といった頼み方が考えられます。頼む側は発注者、頼まれる側は受注者という立場になります。

では、受注者に頼んだとき、発注者の側には何が残るのでしょうか。この問いに答える手がかりになるのが、IPA（独立行政法人情報処理推進機構）のソフトウェア・エンジニアリング・センターがまとめた冊子「実務に活かすIT化の原理原則17ヶ条」です。^*1 以下、この冊子を「資料」と呼びます。

原理原則17ヶ条とは

資料の第1章に置かれているのが「超上流から攻めるIT化の原理原則17ヶ条」です。資料はこれを、「「超上流」フェーズを発注側、受注側の双方がうまく進めるためのポイント」をまとめたものだと説明しています。^*1 資料は超上流を「要件定義フェーズのような超上流工程」とも書いており、本記事でいう上流工程とほぼ重なります。^*1

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

資料は発注者と受注者という立場で書かれていて、受注者が会社か個人かを分けていません。そのため、フリーランスに上流工程を頼む場合にも、受注者あての項目と発注者あての項目をそのまま当てはめて読めます。

外部に頼めることと残る責任

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

行動規範のほうは、自社でできるかどうかに関係なく、「発注者は、要件定義段階で受注者をうまく活用する。」とだけ書かれています。そのうえで基本的な考え方は、「ただし、受注者が支援する場合であっても、要件定義で作成した成果物に対する責任は発注者にあります。」と書いています。作業を頼むことと、責任を渡すことは別の話だということです。

図の右の箱にある「書いてあるものは実現させる。書かれていないものは作らない」は、次の節で見る原理原則17の一文です。上流工程で何をどこまで文書にしておくかが、そのまま出来上がるシステムの中身を決めることになります。

相手に伝える内容はどこまで必要か

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

原理原則12は「表現されない要件はシステムとして実現されない」です。基本的な考え方では、「行間を読め」「言わなくても常識」で済ませた要件が、発注者と受注者のトラブルのもとになるとしています。^*1 社内の人なら黙っていても分かることでも、上流工程から加わったフリーランスの人には、書いて渡さなければ伝わりません。

原理原則14は「「今と同じ」という要件定義はありえない」です。資料は「「同じ」という言い方が正しく伝わるのは、具体的なプログラム、コード体系、テーブルなどそのとき存在する個別の形を持ったものについてです。」とし、「現行システムをどう使っているか、という点から調査をしなければなりません。」と求めています。^*1 コード体系は社内で決めた番号や記号の付け方、テーブルはデータを入れる表のことです。

表のモックアップは、画面や帳票（伝票や報告書などの書類）の見本のことです。3つの行動規範は、どれも発注者がする作業で、要件を表現する、使われ方を調べる、受注者に説明する、の3つです。受注者に頼めるのは要件を書き起こす作業の手伝いで、何を伝えるかを決めるのは発注者だと考えておくと、段取りを組みやすくなります。

社内の承認で企画の期間が減った例

資料の第4章には、上流工程の社外委託をやめた製造業の例が「「超上流」強化、予算オーバーを減らす」として載っています。第4章は、日経コンピュータの記事をもとに編集したものだと注記されています。^*1 この企業のIT部門は、「システム化の構想・企画検討や要件定義といった超上流フェーズの作業を、社外のコンサルタント会社などに依頼することをやめ、自前で取り組むことにした。」とされます。

問題になっていたのは、超上流の作業の一部を社外のコンサルタント会社に委託していたことだとされます。^*1 具体的には、「社外に発注する際は、経営会議で承認を得る必要があった。」というもので、稟議書（社内で承認を求める文書）を作って会議にかけ、承認をもらうまでに3カ月かかることがあったといいます。^*1

この企業には、「構想・企画フェーズであればどんなに時間がかかったとしても6カ月で終わらせる必要があった。」という締切がありました。そのため「この6カ月のうち稟議や承認に3カ月かかるので、構想・企画には実質3カ月しか取れないプロジェクトが少なくなかった。」とされています。^*1 構想・企画の期間を短くしていたのは、委託先の力量ではなく、社外に委託するための社内の手続きだったことになります。

ただし、これは1社の例で、しかも要件定義より前の構想・企画の話です。この例だけで、上流工程を外部に頼むのがよいか悪いかは決まりません。頼むまでにかかる日数を、日程の中に数えておく必要があることを示す例として受け取っておくとよいでしょう。

つまずきやすい点

一つ目は、何を頼むかを決める前に、契約へ進んでしまうことです。資料が外部の活用を有効だとしたのは、自社だけでは実施できない場合でした。ところが実際には「人手が足りないから誰かに入ってもらう」という理由から話が始まりがちで、何が自社でできないのかを確かめる前に人を探し始めてしまいます。そうなると、先の表の3つの作業が誰の仕事なのかもあいまいになります。

二つ目は、「今と同じで」と伝えて済ませてしまうことです。社内の人どうしなら通じる言い方でも、上流工程から加わったフリーランスの人には、いまのシステムが実際にどう使われているかは分かりません。原理原則14が求めるとおり、使われ方の調査を誰がいつ行うのかを決めておかないと、受注者はいまの画面や機能をそのまま作り直すだけになります。

三つ目は、頼むまでの手続きの日数を数え忘れることです。第4章の例のように、社内の承認に時間がかかる会社では、契約が決まる前に上流工程に使える日数が減っていきます。

外部に委託するときに確認しておきたい点

まず、表の3つの作業を誰が担うのかを決めておきます。要件を文書や見本で表現する作業、いまのシステムの使われ方を調べる作業、受注者に説明する作業は、どれも発注者あての行動規範です。受注者に手伝ってもらう部分と、自社の担当者が引き受ける部分を分けて書き出しておくと、どちらもやらないまま進むことを防げます。

次に、社外に委託するための承認に何日かかるかを確かめます。稟議書の作成から承認までの日数を出し、構想・企画と要件定義に使える日数から差し引いておくと、日程の見込みが立てやすくなります。承認に時間がかかる会社ほど、早めに手続きを始めておくことが大切です。

最後に、受注者に渡す文書をそろえる順番を決めます。現行システムの仕様書、使われ方を調べた記録、例外処理の扱いの順に、いつ誰が用意するのかを決めておくと、当たりまえの前提の伝え漏れを減らせます。要件定義で何を決めるのかは「要件定義と要求定義の違い」で整理しています。

まとめ：上流工程で確かめておきたい3つの点

上流工程でフリーランス活用を進めるうえで、確かめておきたい点は3つに整理できます。第一に、自社だけでは何ができず、受注者に何を手伝ってもらうのかを先に決めること。第二に、受注者が支援しても要件定義の成果物の責任は発注者に残り、当たりまえの前提や例外処理まで漏れなく伝える必要があると心得ておくこと。第三に、社外に委託するための承認にかかる日数を、日程の中に数えておくことです。この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カ月という締切、第4章が日経コンピュータの記事をもとに編集されたものである旨の注記）を参照（2026年9月確認）

Tweet