超上流工程とは？概要から流れ、取り組みのコツまでを徹底解説

システム化への第一歩ともいえるのが「超上流工程」です。超上流工程では、経営層、情報システム部門、業務部門がそれぞれ連携しながら、システム導入で目指すべき方向性を決めていきます。

本記事では、独立行政法人 情報処理推進機構 ソフトウェア高信頼化センター（以下：IPA/ SEC）が出版する『経営者が参画する要求品質の確保』に記載の情報を参考に、超上流工程の概要からコツまでを分かりやすく解説いたします。

超上流工程とは、システムやソフトウェアの開発プロセスにおいて、事業や業務の検討から要件定義に至るまでのプロセスを、ひとつの工程としてとらえたものをいいます。

IPA/ SECによると、「システム化の方向性」「システム化計画」「要件定義」の3つを超上流工程として定義しています。

出典：独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター編
『経営者が参画する要求品質の確保』SEC-BOOKS

上記の画像にあるように、一般的な開発プロセスは次の流れで進められることが多いです。

1. システム化の方向性の決定
2. システム化計画の作成
3. 要件定義の実施
4. システム仕様の策定
5. ソフトウェア仕様の策定
6. プログラミング
7. ソフトウェアテストの実施
8. システムテストの実施
9. 運用テストの実施

つまり超上流工程は、システム開発における最初のステップであり、プロジェクト成功の可否を左右する重要な業務です。

下記では、超上流工程における各業務の詳細を解説いたします。

出典：独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター編『経営者が参画する要求品質の確保』SEC-BOOKS

システム化の方向性を決める段階では、経営方針や現場からのニーズなど、さまざまな課題や状況を踏まえ、システム導入で実現したい姿を大まかに定義します。

まずは社内における業務の現状や問題点を把握し、具体的に何を解決したいのかを明確にします。その後、RFP作成、候補ベンターとの打ち合わせを経て、システム化で自社が目指すべき方向性を大まかに決定する流れです。

この段階では、まだベンダーは決定しておらず、提示される見積書は仮試算程度である場合が多いです。また、必要に応じてコンサル契約を結び、パートナーと併走して取り組みはじめる企業もあります。

出典：独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター編『経営者が参画する要求品質の確保』SEC-BOOKS

システム化計画においては、前の段階で明らかにした「システム化の方向性」をより具体化するために、要求分析の実施やシステム化計画書の作成をおこないます。

要求分析は、システムで実現したい内容をエンドユーザーへヒアリングし、言語化したものを文書化してまとめるプロセス。具体的には、「どのような業務フローが理想的か」「ソフトウェアを使ってできないと困ることは何か」といった内容を現場の担当者から聞き出します。

要求分析が終わったら、業務部門や情報システム部門が中心となってシステム化計画書を作成します。計画書には、プロジェクト体制や導入スケジュール、大まかなシステム要求といった内容が盛り込まれるのが一般的です。

システム化計画書の作成後、再度RFPを送付し、候補ベンダーからより具体的な見積提案を受けます。返ってきた見積内容をもとに、システム化の方針の具体化や発注先の絞り込みをおこないます。

出典：独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター編『経営者が参画する要求品質の確保』SEC-BOOKS

要件定義のプロセスでは、前段階でおこなった、要求分析や見積提案の内容を踏まえて、システムに求める機能や性能を具体化していきます。たとえば、以下の内容を決めます。

• 事業要件：ビジネスモデル変革、新規事業など、理想の事業形態を実現するために必要な要件
• 業務要件：理想とする業務フローを実現したり、業務の問題点を解消したりするのに必要な要件
• 機能要件：エンドユーザーの要求する業務や手順を実現するために必要な機能の要件
• 非機能要件：機能要件で定めた以外の、潜在的なニーズの要件

要求定義は、発注側が一方向的に作成するのではなく、ベンダーやコンサルと話し合いながら一緒に作り上げます。システム開発にあたっては発注側・ベンダーの間に相反する思惑があるので、いかにして共通認識に近づけられるかがポイントです。

そして、要件定義書のレビュー・RFPの再送を経て、検討ベンダーから送られてくる概算見積をもとに発注の可否を検討します。業務部門や情報システム部門だけでなく、経営層も積極的に関わり、最終決定を下します。

「超上流工程には時間をかけずに、システム設計の段階で煮詰めた方がうまくいく」「実装がはじまらない限りには何も決められない」といった意見を耳にしますが、これらの考えは間違いです。逆に超上流工程で議論を深めないと、見積や仕様の固まり具合に大きな誤差ができてしまいます。

以下は、Barry Boehm著の『Software Engineering Economics』の図に基づき、IPA/SECが作成した、開発段階ごとにおける規模の誤差を表したグラフです。

上の画像を参考にすると、上流工程であればあるほど、最終的な規模との誤差が大きく開いています。つまり、誤差が大きい超上流工程にて要求仕様をしっかりと固め、現実的な見積内容で合意していけば、後の工程で誤差を少なくしていけるのです。

「いざ導入プロジェクトを開始したものの、追加のカスタマイズが必要だとわかり、予算が大幅に超過してしまった」「プログラミングの段階で現場からさまざまな意見が上がり、機能要件を大幅に見直さなければならなくなっている」といった問題をよく聞きます。しかしそれは、超上流工程にて十分な議論を重ねられていない証拠だともいえるでしょう。

超上流工程では、得られる情報が少なくあいまいさが大きいため、やみくもに取り組んでしまったり省略してしまったりしがち。しかし、後のベンダーとのトラブルや炎上といったリスクを鑑みれば、ほかの工程よりも慎重に取り組むべきであることは明白です。

ここでは、システム化の方向性を決めるうえで、とくに大事な「業務検討」と「方向性の確認」のプロセスにおけるポイントをご紹介いたします。

業務検討のプロセスでは、業務一覧表や業務フロー図を作成・確認し、改善すべき対象を探し出します。加えて、経営者やシステム担当者、業務の運用担当者へヒアリングを実施し、現在発生している問題から根本的な改善点を見つけ出します。

ヒアリング時に注意すべきは、担当者が必ずしも問題の原因を理解しているとは限らない点です。たとえば「毎月月末に間接業務が多く発生しているので、負担を軽減したい」といった意見が営業担当者から寄せられたとします。しかし、こうした情報は表面的なものに過ぎないため、さらに深掘りをして原因究明をする必要があります。

そこで、「月末に間接業務が多く発生してしまうのはなぜなのか？」について、営業責任者へヒアリングすると、「経費精算を手作業でおこなっており、経理担当者とのやり取りや決裁に多く時間を費やしている」ことが大きな原因だとわかることもあります。

また、経理担当者から「経費精算で申請書と領収書を一つひとつ目視で確認する必要があり、非常に非効率」といった意見が寄せられたことから、部門にまたがって経費精算の効率化が課題であることが明確になることもあるでしょう。

こうしてさまざまな意見を集約し、どの業務から先に取り組むべきなのか、優先順位付けをします。業務のボトルネックを見つけ出し、自社が今取り組むべき優先課題を見つけ出しましょう。

業務検討のプロセスで顕在化した課題を解決するために、具体的にどのような方向性でプロジェクトを進めるのかについて明確にします。最低限、下記3つのポイントは押さえておきましょう。

たとえば、ひとえに「システム化をして業務を効率化したい」といっても、経営層やシステム部門、運用担当者それぞれで、「効率化」でイメージする内容が異なります。たとえば、システム部門にとっては「データがシームレスに統合されること」であり、運用担当者にとっては「業務負荷が軽減されること」です。

それぞれが違う認識をもっていると、部門や階層間を超えた議論が深まりません。「会社としてその業務がどのようにあるべきなのか」といった全体視野を持ち、同じ目線で話し合いを進めましょう。

システム化計画のステップで重要なのは、「要求分析」と「システム化計画書の作成」の2点です。ここでは、下記2点のポイントをご紹介いたします。

最初に、自社の要求をベンダーへ伝えるために要求分析をおこないます。経営層、システム部門担当者、業務の運用担当者へヒアリングを実施し、自社が求めるシステムの詳細を具体化します。

なお、要求分析には以下の4要素が存在します。

ビジネス要求：品質、コスト、納期など

システム要求：対応機能、インターフェースなど

ハードウェア要求：性能、耐久性、重量など

ソフトウェア要求：アーキテクチャ、保守性など

また、顕在的な情報である「機能要求」のほかに、潜在的な「非機能要求」も意識して把握するのがポイント。たとえば「A画面→B画面→C画面へとスムーズに遷移できる設計にしてほしい」といった機能要件に対して、「遷移スピードが0.5秒以内」「稼働率99%以上」など、隠れたニーズを明確にします。

要求分析が完了したら、要求定義書を作成して情報を整理します。いかに深掘りした情報をヒアリングできるか、バラバラな要求をひとつにまとめられるかがポイントです。

続いて、システム化計画書を作成していきます。具体的には、下記の内容を記載するとベンダーとのやり取りがスムーズにいくのでおすすめです。

• システム化プロジェクトを実施する背景・目的
• システム化の事業方針（事業戦略、中長期戦略、短期戦略）
• 事業・業務の全体図
• システム化の業務範囲
• システム化に必要な要素（業務フロー、システム概要、インフラ構成、サービスレベルなど）
• プロジェクトの実行計画
• 投資対効果（開発工数、定量的・定性的な費用対効果）

加えて、それぞれの計画や要素に誰が主体となって取り組む予定なのかを明記しておくと、責任所在が明確になります。計画書を初めて読むベンダーでも理解できるような内容にするのがポイントです。

要件定義の段階では、要求定義で決めた内容を開発スケジュールへ落とし込むために、さらに詳細な機能や業務フロー、データの流れなどを明確にします。

要件定義で決める内容は、前述したとおり「事業要件」「業務要件」「機能要件」「非機能要件」の4つです。ここでは、さらに深掘りするために、機能要件と非機能要件で明確にすべき項目をご紹介いたします。

要件定義は、「5W1H」を意識して作成することがコツです。ベンダーへもれなく情報を伝えられるよう、精査しながら作成してください。

この記事では、超上流工程の概要と、各ステップにおける取り組みのポイントについて解説いたしました。まとめると、以下が超上流工程で取り組む内容です。

超上流工程は、課題特定から認識共有、要件・要求定義まで幅広い業務を実施するほか、それぞれで高い専門知識を必要とするのが特徴です。そのため、自社ですべてを一貫しておこなうのは人材の足りない企業にとっては至難の業。必要に応じてコンサルティングサービスを活用するなどして、生産的に進める体制を整えましょう。

ぜひこの記事を参考に、超上流工程への理解を深めて取り組んでみてください。