システム開発を学びたい!ビジネススキルを身につけたい

2-6 システム要件定義の進め方・必要成果物とは?

システム要件定義の進め方とは?【完全初心者ガイド】社内SE必見 システム開発を学びたい!
システム要件定義の進め方とは?【完全初心者ガイド】社内SE必見
社内SE
社内SE

システム要件定義を一人で推進できるようになりたい!

どのようにシステム要件定義を進めるのか基本的な手順を知りたい!

と言った社内SEの悩みに答えます。

この記事で理解出来る事・得られる事
・少額のシステム開発の要件定義を一人で推進
・要件定義の流れと各工程で必要な成果物の関係が理解
・要件定義推進の不安払しょく
・要件定義力向上の為お薦め書籍

✔記事の信ぴょう性

kato
kato

SIer SE→現、一部上場企業社内SE(IT歴15年以上)。過去、基幹システム開発~グローバル16拠点への導入等実績。社内SEの為の情報サイトIT Comp@ss運営者。社内SE講師としても活躍。自身の社内SEとしての学びや経験を元に情報をお届けします。

要件定義を上手く進める為に必要な3ステップ

ステップ①システム開発プロジェクト全体の成果物理解
システム開発の成果物・ドキュメント一覧まとめ【DLリンク有】

ステップ②要件定義に必要な成果物とは?の理解 本記事
システム要件定義の進め方・必要成果物とは?

ステップ③要件定義書で使える成果物サンプルで時短 
DLしてすぐ使える要件定義書|テンプレート・サンプル・成果物(社内SE/情シス向け)


※当ページのリンクには広告が含まれる場合があります。

本記事で解説する「システム要件定義の進め方」の範囲

本記事で解説する「システム要件定義の進め方」の範囲とは?

本記事では、一般的に要件定義の進め方で解説される範囲よりも広範囲で解説します。(下記図、黄色抜きの部分)

理由は、要件定義の推進は要件定義が始まる前段取りが重要です。あまり語られることのない要件定義の一歩手前から解説し、工程のつなぎを意識して解説します。

これにより、社内SEの方がシステム要件定義に入るために必要な準備や重要な前提条件の確認も網羅的に解説できます。

本記事で紹介するプロセスと成果物の関連性は以下です。サンプルDLはこちらです。

NOプロセス主要成果物
1業務要求整理・理解・業務フローAS-IS
・業務フローTO-BE
・要求一覧
2プロジェクト立ち上げ準備・計画書,又はキックオフ資料
3システム超概算算出・社内投資審議フォーム
・ベンダー正式見積書・発注書
4システム開発ベンダーとの契約手続き・NDA(秘密保持契約書)
・基本or個別契約書
5システムキックオフ・キックオフ資料
6業務要件整理・FIX・ヒアリングシート
・業務要件一覧
*業務要求整理で利用した成果物の最終版
7システム要件整理・FIX・システム要件一覧
・機能一覧

システム要件定義・要件定義書とは?意味を解説

Map lying on wooden table

システム要件定義を成功させる上で、【システム要件定義を含む要件定義がシステム開発で最も肝となるプロセス】です。

なぜシステム要件定義が肝となるプロセスで重要なのか?から解説します。

システム要件定義とは?なぜ重要か?

システム要件定義とは、業務要件定義の一部。全部ではない
システム要件定義とは、システムの要件を決めるだけではなく後工程の段取りも行う
システム要件定義とは、無形なアイディアを有形に変える行為だから難しい

システム要件定義とは、業務要件定義の一部。全部ではない

要件定義は主に、
・業務要件定義
・システム要件定義

に分類されます。以下図をで詳しく解説します。

要件定義の一部がシステム要件定義です。

上記図では、レベル10と仮定した業務レベルを右のLV15の状態に引き上げようとしています。この場合、システムの箱だけではなく、業務自体もレベルアップしている様子が分かると思います。この意識がまずは欠落する業務ユーザーが多いです。

システム要件定義とは、システムの要件を決めるだけではなく後工程の段取りも行う

システム要件定義では、要件定義を決めるだけが仕事ではありません。業務ユーザーが発案したアイディアに基づきシステム開発を立ち上げるフェーズです。システム要件の整理と並行して、プロジェクト立ち上げ準備も必要です。

後ほど、システム要件定義に必要な成果物をプロセス・進め方と合わせてご紹介します。

システム要件定義とは、無形なアイディアを有形に変える行為だから難しい

なぜ、そもそもシステム要件定義が難しいのか?】この解を持っておくと、ストレスが激減します。

理由は、ちょうど要件定義のプロセスが無形のアイディアを有形に変える行為だからです。

言い換えると、システム要件定義とは、
企画フェーズからモノ作りフェーズへと収束させる分岐点。広まったアイディアを業務ユーザーと合意し収束させるアクティビティー」と言えます。(以下図参照)

この意識の有無でそもそもシステム要件定義の難易度・重要度の理解につながります。

システム要件定義が、アイディアを形にする行為=ビジネス要求・アイディアという無形をソフトウェアという有形にする行為の分岐点になります。

だからこそ、システム要件定義でよく言われている文章化は非常に重要になります。理由は、無形のアイディアを、まずは形ある紙に落とす行為だからです。

この理解・説明なしでは、上司に「要件定義書重要だ!」と罵声を浴びせられても腑に落ちません。この理解があれば、「なぜ成果物が重要か?なぜ要件定義は難しいのか?」が腹落ちします。

あわせておすすめ

システム開発の失敗(遅延)の50%は要件定義によるものです。「システム開発の遅延理由の50%は「要件定義の失敗」事例と回避策」で詳しく解説しています。

システム要件定義の王道プロセス・進め方

システム開発の一連の流れの黄色抜きの部分を詳しく解説していきます。

システム要件定義の王道のプロセス・進め方

  • 業務要求の整理・理解
  • プロジェクト立ち上げ準備
  • システム概算算出
  • システム開発ベンダーとの契約手続き
  • システムキックオフ
  • 業務要件整理・FIX
  • システム要件整理・FIX
  • 開発工程へ

*尚、本記事は、社内SE向けに作成したものです。要件定義を自社内で実施する前提のプロセスで記載しています。全て外注の場合、以下の図の一番左のプロセスからコンサルと呼ばれる部隊が参画し要件定義まで行い、開発部隊に引き渡す流れになります。

早速、プロセスごとに、【進め方のポイント】と【必要な成果物】を解説していきます。

業務要求の整理・理解

必要成果物

このフェーズでは、業務ユーザーが中心となり、ビジネスの企画に基づき新しい業務・サービス開始の為に必要な要求をまとめ上げます。その計画書・企画書に基づき業務要求をまとめていきます。

一般的に、業務フローのAS-ISを作成し、それに基づき新しい業務を想定したTO-BEのフローを作成していきます。

例えば、今まで4日で提供していた製品開発を、半分の2日にすることがビジネス的チャレンジとします。その場合、新しい製造機械の導入、レポートの作成等がシステム業務要求となります。

ポイント:業務要件定義には、システム化要件以外も含むべき

この業務要件には、システム要件だけではなく全ての業務観点での要件も定義されるべきです。

先ほど登場した図で言うと以下の部分です。

業務要件にシステム化要件以外もきちんと含まれるべき理由

体験談:
大抵(8割、、感覚値ですが)この業務要件の整理が業務ユーザーだけではできません。

システム構築=業務改善完了!みたいな意識結構多いです。

システムは、業務改善の一部!!

そもそも、業務ユーザーが実施しなければいけない意識すら欠落しています。

社内SEは何をしなければいけないのか?

要件定義を成功に導くために、業務側がそういった業務要件の整理も当然必要な事を教えてあげる必要があります。

社内SEの仕事
・業務ユーザーに業務要件の整理は業務の仕事であることを認識させる
・それができて初めて「業務ユーザー」が求めている要件はこれですよね?と一覧にまとめるお手伝いが出来る

並行して開発プロジェクト立ち上げ準備をしよう

必要成果物

システム化の要求が見えてくると大抵業務ユーザーはワクワクがとまらず、なぜかシステムが出来た気になります。かなり理不尽な納期を要求される場合があります。

早めに予算的・納期的に現実的な状況を共有するために、ベンダーの巻込み推進がお薦めです。*慣れてくるとベンダーなしであなた自身で工数・納期も大体見積もれるようになります。

この時期にやっておいた方がいいのが、プロジェクトの立ち上げ準備です。

既に既存システムの追加開発・改修の場合、既存ベンダーに今回の案件概要を伝え、リソース・体制の調整が必要な状況の共有がお薦めです。

もし、まったくの新規案件であるならば、今回の要件に合うシステムパッケージまたは、開発を請け負ってくれるベンダーアプローチが必要です。ベンダー一括見積のおすすめのサイトは、【 【これは楽!】システム開発の外注探しに便利!一括無料見積りサイト|】の記事でご紹介しています。

システム概算算出

必要成果物

・社内投資審議フォーム・企画書
・ベンダー正式見積書・発注書

モノづくりに移行するために、社内の投資審議・上程などの内部プロセスを通過する必要があります。

社内の必要書類に関しては、以前審議された社内資料を参考にすることを強くお勧めします。審議する人が見慣れた形式や聞きなれた言い回し、コンテンツを用意してあげると審議もスムーズです。

アウトプットの質を改善したい人向けの書籍は、【【SEのための図解の技術、文章の技術】決めごとを文章にする能力】です。【【厳選】SEにおすすめ本20冊と勉強方法|社内SE/情シス必見】の記事で紹介しています。

システムベンダーとの契約手続き

必要成果物/書類

社内承認が無事完了したら、いよいよベンダーを巻込みシステム要件定義へと進みます。そのために、まずは契約手続きをします。

一般的には、NDAと言われる秘密保持契約書と個別または基本契約書を結びます。システム開発に関連した契約モロモロあまり詳しくない、もっと勉強したい!という方は、以下の記事を参照ください。

2-4 システム開発の契約3種3形態を正しく把握しよう
システム開発の契約ってどうなってるか理解したい!言葉の違いもいまいちわからない と言った悩みに答えます。 この記事を読み進めることでシステム開発を推進する、情シ...

システムキックオフ

必要成果物

・キックオフ資料

ベンダーとの契約手続き、及びリソースの調整が完了したらシステム関係者でキックオフを実施します。

キックオフの流れとしては、

一般的に
①プロジェクトの目的・背景 (業務側でキックオフがあれば内容を抜粋)
②システムに求められる要件
③想定構成図
④関係者の役割定義
④体制図
⑤大まかなマイルストーン
⑥現時点での見えているリスク

を共有します。

中小の社内SEが手掛ける案件では、PMO(プロジェクトマネージメントオフィス)という、プロジェクト推進を支援する役割の人がアサインされない場合がほとんどです。

その場合,あなた(PLの方)がシステム検討と並行してプロジェクトマネージメントの全体のアドミン系の準備も必要になります。

その場合、上記の他に以下の準備が必要です。

⑦会議体
⑧資料格納場所
⑨コミニケーションルール

業務要件整理・FIX

必要成果物

無事システムキックオフが済んだら、次に実施することは、業務要件のFIXです。

ビジネスに対する業務改善・新しいサービスを検討するわけですので、当然終わりなき戦いです。しかし、一定量の開発する要件を定めなくてはモノづくりができません。

上段でご説明した、無形のアイディアを有形に変える作業ですので、このアイディアが絶えず変化していては有形のソフトウェアで表現できません。

〇ポイント

実際問題、業務に過度な期待は禁物です。

出来る業務の方は言われなくても、業務フローを構築し要件をしっかりとまとめ上げます。

何もしてくれない業務とどうお仕事を進めるか?選択しは3つです。
①何もしないでほっておく
②たたかれ台としてフローを作成してあげる
③業務フロー作成を手伝う・やってあげる

お薦めは②です。理由は、①だとビジネスが改善しない。③だと、実際の業務が始まった際に業務ユーザーがフローに責任がない。②だと、システム目線ではありますが、プロジェクトを進めつつ、業務フローが必要な認識も共有できます。

システム化要件のヒアリング

システム化要件を固めていくために、ヒアリングを実施していきます。システム化の要件は以下の3つの軸で整理しアウトプットにまとめていきます。

システム要件定義のヒアリング方法は以下の記事にまとめました。

【現場ですぐ使える】 要件定義書の書き方とコツ|目次・項目・ヒアリングサンプル例
要件定義書って何を書けばいいかよくわかりません。 と言った悩みに答えます。 この記事を読むことで、要件定義書を書く上で、必要な【目次・項目・ヒアリングサンプル】...

システム要件整理・FIX

必要成果物

業務要件の一覧が完成されれば、それをもとにシステムの要件一覧と機能要件一覧を作成します。

ここでしっかりと、「何の業務をするため」に「どんな機能をどこで作るのか?」をすり合わせ合意する事が非常に重要です。

システム開発フェーズへ

ここまでで大まかなシステム要件定義の流れをお伝えしました。

次は、開発工程です。その前にプロジェクト上様々なリスク・不明確な部分が残されている場合に概念検証=POC(Proof of Concept)を実施する場合があります。

概念検証(PoC)も使い方を知っておくとあなたのシステム開発能力を上げてくれます。合わせて、「PoC無茶ぶりつらい「PoC(概念検証)プロセス」の進め方とは?」の記事を読んでみてください。

システム要件定義を独学で勉強するお薦め書籍

システム要件定義の進め方・プロセスに関して解説しました。

業務要件から開発までシステム要件定義の前後のプロセスごとにどのような成果物が必要か?理解できたのではないでしょうか。

さらに、詳しくシステム要件定義を独学で学びたい人におすすめ書籍は、「厳選8冊|システム要件定義を学ぶおすすめ本【脱初心者向け基礎】」でご紹介しています。合わせて参照ください。

社内SEの勉強におすすめ!システム開発が学べる本22冊【厳選】
ITエンジニア(SE・社内SE・情シス)として何から勉強したらいいか分からない 現場で認められる実力を伸ばしたい!どんな本が社内SEの勉強にオススメか知りたい ...

システム要件定義プロセスと成果物一覧まとめ

ここまでの解説でシステム開発における、システム要件定義の重要性・位置づけ・各プロセスと必要な成果物を理解できたと思います。最後にここまでのおさらいとして、ご紹介したプロセス・成果物・関連を一覧と図にまとめています。

システム要件定義前後のプロセスと必要成果物一覧

NOプロセス主要成果物
1業務要求整理・理解・業務フローAS-IS
・業務フローTO-BE
・要求一覧
2プロジェクト立ち上げ準備・計画書,又はキックオフ資料
3システム超概算算出・社内投資審議フォーム
・ベンダー正式見積書・発注書
4システム開発ベンダーとの契約手続き・NDA(秘密保持契約書)
・基本or個別契約書
5システムキックオフ・キックオフ資料
6業務要件整理・FIX・ヒアリングシート
・業務要件一覧
*業務要求整理で利用した成果物の最終版
7システム要件整理・FIX・システム要件一覧
・機能一覧

システム要件定義で使える各種サンプルは、「システム要件定義で使える成果物サンプル・テンプレートまとめ」の記事でまとめています。

システム要件定義フェーズの成果物の関連図

それぞれの成果物にも依存関係があり、前工程の成果物がインプットとなる後続の成果物を作ることが出来ます。システム要件定義の成果物の関連性も理解しておきましょう。

要件定義成果物関連図

初めての要件定義は何をどこから準備しなければいけないか分からず不安になると思います。

最初から全て完璧に用意するのは正直難しいですが、比較的規模の小さい案件からチャレンジし進め方のあなたなりの型が出来てくるとストレスレスにぬけ漏れなく要件定義を進めることが出来ます。

要件定義を失敗させないために、合わせて学びたい考え方は、「Amazonに学ぶシステム要件定義を失敗を未然に防ぐ考え方のコツ」の記事でご紹介しています。

次の記事 

驚愕!システム開発の遅延・失敗の50%は要件定義から。回避策はこれ
システム要件定義のよくある失敗を知っておいて未然に防ぎたい! といった、疑問に答えます。 この記事では、システム開発で最も重要な要件定義。その要件定義でよく発生...
タイトルとURLをコピーしました