超上流工程とはなにか、システム化への第一歩を決める重要性を徹底解説

システム化への第一歩ともいえるのが「超上流工程」です。

超上流工程では、経営層から情報システム部門、業務部門がそれぞれ連携しながら、システム導入で目指すべき方向性を決めていきます。
本記事では、超上流工程とは何か、超上流工程の重要性を解説していきます。

最後までお付き合ください。

超上流工程とは

超上流工程とは、IPA（情報処理推進機構）のSEC（ソフトウェア・エンジニアリング・センター）の定義から、システムライフサイクルにおける設計などの上流工程よりもさらに上流の「システム化の方向性」「システム化計画」「要件定義」を行う工程です。

この工程では、そもそもの目的や必要な計画を明確にすることが重要になります。
ここからは、説明した3つの工程が関係してきます。

超上流工程で最も重要なことは、対象のシステムに携わるステークホルダーが積極的に参加することです。
ステークホルダーとは、経営層、システム化の対象となる業務を担う業務部門、システムの利用者、システム部門、ITベンダーなどが対象です。ちなみに「超上流工程」という言葉は日本独自のもののようです。ご存じでしたか？

超上流工程は2007年に、標準的な開発プロセス/手順のガイドライン「共通フレーム2007」として規格化され、ソフトウエア・ライフサイクル・プロセスの国際規格である「ISO/IEC 12207（JIS X 0160）」にも準拠しています。

「システム化の方向性」

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

まずは社内における業務の現状や問題点の把握をし、把握した内容に優先順位をつけていきます。これにより解決すべき内容が明確になります。
そのあとは、RFP作成、ベンダーとの打ち合わせなど経て、システム化で自社が目指すべき方向性を決定する流れとなります。

「システム化計画」

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

要求分析は、システム化で実現したい内容を発注者へヒアリングし、言語化したものを文書化してまとめる工程です。具体的には、「現在システムを使っていないために困っていることはあるか」といった内容を主にヒアリングします。

要求分析が完了したら、システムの業務部門や情報システム部門が中心となってシステム化計画を作成します。計画には、プロジェクト体制図や導入スケジュールなど、システムへの要求以外の計画に関する内容も記載します。

「要件定義」

要件定義は、システム開発工程の中で最も重要とされる工程です。

なお、要件定義の重要性については、他のブログで触れていますので、よろしければそちらのブログも覗いてみてください。
過去ブログ↓

超上流工程で取り組むポイントとは？

【システム化の方向性】

（1）業務のプロセスを検討する

（2）検討した具体案の共通認識を持つ

主に、この2点が重要になってくる箇所です。

業務のプロセスを検討する

業務検討のプロセスでは、業務一覧や業務フロー図を作成の上、改善すべき対象を洗い出します。
システム開発担当者やその関係者が、業務の運用担当者へヒアリングを行い、現在発生している問題から根本的な改善点を見つけ出します。

ヒアリング時の注意点としては、担当者が必ずしも問題の原因を正確に理解しているとは限らず、表面的な情報が含まれている可能性も考慮し、状況に応じて深掘りをするなど、真の原因を探れるようにすることです。

また、対立的な意見を集約したり、業務のボトルネックを抽出したり、改善すべき対象のうち、どこから先に取り組むべきかの優先順位をつけたりすることも重要です。

検討した具体案の共通認識を持つ

検討した結果は、以下の項目を具体案としてまとめるようにします。
なお、まとめた具体案については、ステークホルダー全員の共通認識となるように共有しましょう。

・システム化の目的

・システム化の具体的な実現案

・プロジェクト体制の取り組み方法

【システム化計画】

システム化計画では、以下の2点をポイントとして押さえるとよいでしょう。

（1）要求をヒアリングし詳細化する

（2）必要な情報を網羅する

要求をヒアリングし詳細化する

要求分析を行うために、経営層、システム部門担当者、業務の運用担当者へのヒアリングを実施しますが、ヒアリングにて獲得した要求は、まず、ビジネス要求、システム要求、ハードウェア要求、ソフトウェア要求に分類していきます。

ビジネス要求 組織の目的や目標、顧客/市場の要求・顧客満足、品質・コスト・納期、従業員の満足	システム要求 情報システム、システム機器が備える機能、システム/サブシステム、インターフェース
ハードウェア要求 高性能、高品質、低価格・軽量・防水、操作性の高い、ユーザーインターフェース	ソフトウェア要求 アーキテクチャ（ソフトウェアの構造）、プロダクトライン化、個別のソフトウェア製品/部品、保守性・変更容易性

要求の分類が終われば、次は各々の要求を詳細化していきます。この際、顕在的な要求としての「機能要求」以外に、潜在的な要求としての「非機能要求」を意識して把握することがポイントとなります。たとえば、「遷移のスピードが何秒以内」といった要求が「非機能要求」に該当します。

ここでは、「非機能要求」の獲得を意識したヒアリングの実施とともに、バラバラな要求をひとつにまとめるための分析も重要な要素となります。

必要な情報を網羅する

システム化計画では必要な情報が網羅できるよう、計画書には必ず以下の項目を盛り込みます。

プロジェクトの背景・目的 システム化の業務範囲 システムに求められる要素 プロジェクト実行計画の策定 投資効果による評価

IPAにシステム化計画の事例がありますので、ご参考にください。
超上流から攻めるIT化の事例集：システム化の方向性と計画　引用

【要件定義】

要件定義では、「業務要件」「機能要件」「非機能要件」の3つの要件を必ず押さえましょう。
なお、3つの各要件定義で押さえるポイントを以下の表にまとめましたので、参考にしてみてください。

業務要件	システム化の背景・目的 システム化の狙い 業務関連図 As-Is業務フロー To-Be業務フロー 業務一覧 課題一覧 用語の定義
機能要件	機能一覧 システム構成図 画面一覧 画面遷移図 画面レイアウト 帳票一覧 帳票レイアウト バッチ処理一覧 テーブル・ファイル一覧 テーブル関連図 インターフェイス一覧
非機能要件	可用性 性能・拡張性 運用・保守性 移行性 セキュリティ システム環境・エコロジー

超上流工程の重要性

最後に、超上流工程の必要性について、次の2点を重要ポイントとして挙げておきます。

後工程での変更・手戻りリスクの防止

業務要件があいまいなままシステム開発を行えば、テスト段階でシステム機能の漏れや業務要求との違いが発見され、設計や開発への手戻りが発生する可能性がある。要件定義プロセスで十分に内容を詰めておけば、これらのリスクを回避することが可能になる。

ダイナミックな業務改革効果の導出

業務改革による経営効果を得るためには、経営戦略を実現するための各業務のあるべき姿を描き、現状とのギャップを明らかにしたうえで、ギャップを解消するための新しいITを活用した業務モデルを作成する必要がある。

2005年12月の『ITソリューションフロンティア』引用
野村総合研究所の水野満氏「超上流工程における検討のポイント」

まとめ

ここまで超上流工程の重要性を述べてきましたが、いかがでしたでしょうか。
最後に、今回の記事のポイントをまとめておきます。

・超上流工程は、システム開発の最上流に位置し、プロジェクト成功のカギとなる ・「システム化の方向性」「システム化計画」「要件定義」を行う工程をまとめて超上流工程と呼び、この工程名は日本独自のもの ・「システム化の方向性」では、業務プロセスの検討と具体化した案の共有がポイントとなる ・「システム化計画」では、獲得した要求の分類と、要求の詳細化がポイントとなる ・「要件定義」では、「業務要件」「機能要件」「非機能要件」の3つを押さえるのがポイントとなる

弊社QualityCubeでは、超上流工程での品質課題に対して様々なサービス提供が可能で、要求定義の代行や要件定義の代行をはじめ、幅広くサービスをご用意しております。超上流工程での品質課題のみならず、システム開発に関するご課題やお悩みごとがございましたら、お気軽にお問い合わせください。