こんにちは！中島です。

今日は、システム開発の工程において最難関といわれる要件定義についてお話しようと思います。

依頼通りにシステム要件をまとめ開発を行なったにも関わらず、 大半の機能が使われないままお蔵入りとなってしまう事があります。

本記事では、合理的で実用性の高いシステムを構築するために必要な要件定義スキルをまとめています。

「はじめてプロジェクトマネージャーになったので、要件定義の進め方を学びたい」

「現状分析の方法やヒアリングにおけるポイントを、今一度確認して整理したい」

という方は、ぜひ参考にしてみてください。

要件定義とは？

要件とは、「システムによってこれを可能にしたい」「このようなシステムが欲しい」 といったシステムに求める機能・性能です。

要件定義では、開発者側は要件をヒアリングし、システムで実現すること/しないことを要件として揺るぎなく定義します（要件定義書という形でドキュメント化するのが一般的です）。

要件定義はプロジェクトの成否を分ける最重要プロセス！

日経コンピュータのITプロジェクト実態調査 2018によると、プロジェクトが失敗する最大の原因は、要件定義のプロセスにあることが分かります。

要件定義に不備があると、いかに設計や製造が完璧だったとしてもその後の手直しが必要となります。

また、要件定義の不備が発覚するのは往々にしてプロジェクトの終盤になってからであり、

大きな手戻りが発生してしまうことも珍しくありません。

これが、要件定義がシステム開発の工程で最重要にして最大の難所と言われる所以です。

満足を得られなかった理由の筆頭は「要件定義が不十分」、 コストを順守できなかった理由の筆頭は「追加の開発作業が発生」、 スケジュールを順守できなかった理由の筆頭は「システムの仕様変更が相次いだ」だった。 スケジュールを守れなかったプロジェクトで最も苦労した工程を尋ねると「要件定義」が筆頭に来た。 〔……〕プロジェクトが失敗する理由は要件定義の不備に集約できる。要件定義とは導入する情報システムで実現したい事項を整理し、決めることだ。 要件を曖昧にしたままプロジェクトを進めてしまうと、経営者や利用者が真に求めていたシステムができあがらず、品質ないし満足度が下がる。プロジェクトの途中で要件に問題があると気付いた場合、要件定義をやり直し、仕様を変更したりするため、スケジュールが遅れる。修正後の要件に基づいて追加開発をすればコストがかさむ。 日経コンピュータは2018年の調査報告記事で「まず必要なのは要件定義を疎かにしないこと」と書いていた。

出典：プロジェクト失敗の理由、15年前から変わらず

要件定義のつまずきポイント

なぜ要件定義プロセスでの失敗が絶えないのでしょうか？

その原因の１つに、「コミュニケーション不足」が挙げられます。

以下のような性質から、発注者側と開発側との間で、認識の齟齬が起こりやすい構造にあります。

①プロジェクトの目的意識の違い

プロジェクトには経営層、業務部門などのステークホルダー(利害関係者)が関与します。

社内システム構築においては、以下のようにそれぞれの価値観や目的意識は異なります。

• 経営層→コスト削減や業務効率化への期待
• 業務部門→自分達の業務を楽にしたいという期待/現状のオペレーションが変わることに対する不安

例えば「業務効率化」という言葉１つをとっても、経営者にとっては「コスト削減」、業務部門にとっては「作業負担の軽減」が焦点となるでしょう。

プロジェクトの取りまとめ役が機能せず、いずれかの立場に偏向すると、真のニーズを取りこぼしてしまう恐れがあります。

 

◆社内システム開発におけるプロジェクト体制図

②技術的な阻害要因

経営層や業務部門はエンジニアリングの分野に明るくないことが殆どです。

一方で、開発側は業務部門からの協力無しに固有業務について知り得ません。

互いが自身の常識で話をしたり、それを分かったフリをすることで認識のズレは生じます。

ワンポイント：要件定義において「現行通り」のような曖昧な表現はNG

③潜在ニーズ / ニーズの変容

発注者が自身のニーズを正確に把握しているとは限りません。

本質的な業務課題が不鮮明な場合は、本人さえ自覚していないニーズが隠れていると考えられます。

さらに、プロジェクトの初期段階では漠然としたイメージしか出来ないため、ニーズを網羅的に洗い出すことは困難です。

また、情勢の変化によって業務のあり方が変わり、全く違ったニーズが発生するケースもあります。

手戻りを防ぐための要件定義の進め方

I　ゴールの明確化

要件定義の第一ステップは、プロジェクト全体のゴールを明確に定義することです。

通常、立場によって価値観は異なり、それぞれの目的意識にはギャップがある状態です。

仮にゴールが曖昧なままプロジェクトが進行していくと、真に必要な機能の判断がつかず、プロジェクトの破綻にも繋がりかねません。

ゴール策定の意義はこうしたギャップを解消し、プロジェクトに関わるメンバー全員が当事者意識を持ったチームを作ることにあります。

つまり、ゴールとは組織全体の共通認識を形成できるほど、分かりやすく納得度の高いものでなくてはならないのです。

プロジェクトのゴールを明らかにする手法として、ゴールデンサークル理論が有効です。

ゴールデンサークル理論とは、「WHY→HOW→WHAT」の順番で思考し、物事の本質を捉えるフレームワークです。

システム開発では、なにを作るか？（WHAT）やシステムでどのように変わるか？（HOW）に意識が向かいがちです。

しかし、それらに先立ってなぜ作るのか（WHY）の部分について十分な議論をしなければなりません。

「なぜ」を繰り返し考え、上位の目的を辿ると経営課題の解決や企業理念に繋がってくるはずです。

核心部分から定めていくことで将来構想やコンセプトが明快になり、プロジェクトに参加するメンバーの理解が圧倒的に得やすくなるのです。

ワンポイント：システム化の背景（なぜ作るのか？）が明確になっていること、組織内での合意形成が為されていることを確かめましょう。

Ⅱ　現状分析

現状分析には２つの狙いがあります。

１つは、現行の業務フローのどの部分が課題となっているのかを明らかにすること。

そしてもう１つは、課題部分について現行業務の完全なリストアップを作成することです。

現状分析は以下のような流れで行います。

1.業務フローの作成

まず初めに全体の流れをざっと洗い出し、どの部分が課題となっているのかを確かめることが肝心です。

そのため、スイムレーンチャートのような業務の流れを一通り記述するフォーマットが有効です。

部署や役職ごとに業務プロセスを整理し、作業のなかで重複や複雑さが発生している箇所を見つけます。

◆授業の振替管理業務でのスイムレーンチャートの例

2.詳細な業務の洗い出し

次に課題部分に関して、アクティビティ（業務を細分化したタスク）のリストアップを行います。

アクティビティには作業者、作業時間、発生頻度、利用システムなどの情報を付け加えていきます。

3.課題一覧の作成

前の過程で発見した課題について作業内容、作業時間、発生頻度、課題詳細などの項目に沿って整理していきます。

どのような種類の課題なのか課題エリアを分類しておくことで、施策を考える手助けになります。

◆課題一覧の例

Ⅲ　システム構想策定

システム構想策定では、課題解決を図る施策と、それによる結果（=将来像）を明らかにします。

システム構想策定は以下のような流れで行います。

1.  施策検討

現行の業務フローと課題一覧から見えてきた施策を一覧として書き出します。

施策一覧のなかには、効果の大きい施策 / 小さい施策、簡単に実現できる施策 / 実現が困難な施策があります。

そのなかで、プロジェクトのゴールに照らして費用対効果の高い施策のみを厳選します。

2.将来業務フローの作成

システム導入による業務プロセスの変更点を書き出し、それに基づいて将来業務フローを作成します。

各関係者を巻き込み、多様な視点で将来業務フローを検証することが重要となります。

Ⅳ　機能要求の洗い出し

将来像を実現するために必要となる具体的な機能要求をリストアップします。

後に要件の抜け漏れが発生しないよう、このフェーズではできる限り多くの機能要求をあげることが求められます。

テクニックのひとつとして、発散と収束を分ける手法が使えます。

発散とは、発想を広げてアイデアを沢山出すこと。

収束とは、アイデアを絞り込んでいくことです。

機能要求の洗い出しの段階では、要否の判断は行わずアイデア出しにのみ集中しましょう。

Ⅴ　 機能の取捨選択・優先順位付け

機能要求のうち、システムとして実装する機能選定を行います。

FM（ファンクション・マトリクス）とは、機能ごとに「ビジネスベネフィット」「組織受入態勢」「技術的容易性」の３つの観点から評価する優先順位の基準となるツールです。

ビジネスベネフィットとはプロジェクトのゴールに対する貢献度が高いこと。

組織受入態勢とは、システムを簡単に使いこなせること。

技術的容易性とは、簡単に作れることです。

それぞれの基準ごとに３段階（High / Mideun / Low）で評価し、その合計スコアが高いものから優先的に作ります。

そして、スコアが低いものについては、実装を先送りにしたり、スコープ（システムの開発範囲）から外したりします。

FMによる利点は、スコープが限定される点です。

システム開発にありがちなのが、機能の要否の判断がつかずに必要性の薄いものまで実装し、予算オーバーやスケジュール超過に陥るケースです。

FMの一貫した判断軸が、予定外の機能追加による失敗を防いでくれます。

FMのもう１つ利点は、意思決定のプロセスが誰の目からも明らかになる点です。

実装を見送った機能について、その意図はレーティングからもみてとることが出来ます。

口頭で「この機能は諦めてください」と伝えるよりもずっと心理的負荷が小さく、発注者との合意形成に一役買ってくれるのです。

◆社内システムにおける勤怠登録機能に関するFMの例

Ⅵ　 非機能要件

非機能要件とは、機能面以外でシステムに求める要件のことです。

非機能要件は、以下の6つの大分類で構成されています。

抜け漏れの可能性がある場合は、お伺いをたてましょう。

1.可用性

「可用性」とはシステムがどのくらい継続して動作できるかの能力のことです。

「いつ、どのくらいのシステム停止を許容できるか」を検討していきます。

2.性能・拡張性

「性能」はシステムの処理性能を、「拡張性」は将来的に性能をどの程度増強できるかを指します。

通常の業務時とアクセス集中時でシステムの応答速度はどのくらいであれば良いか等を検討していきます。

3.運用・保守性

「運用」はシステム導入後の動かすための操作を、「保守性」はビジネスの変化に応じた機能の追加・修正などの改修作業が行いやすいか否かという項目です。

バックアップの範囲や頻度、障害監視の仕組みなど検討していきます。

4.移行性

旧システムの既存データからの移行に関する要求をまとめる項目です。

移行するデータの範囲、移行中のシステムの稼働の可否、トラブル対応などについて目標を設定します。

5.セキュリティ

システムの安全性に関する目標を設定する項目です。

不正アクセスによるデータ漏洩を防ぐ仕組みや、データ暗号化の方法、侵入検知システムや侵入防止システムが監視した通信ログの保存期間等を検討していきます。

6.システム環境・エコロジー

システム環境はハードウェアがどんな環境に置かれているか(耐震や湿度)、エコロジーは環境負荷に関する要求をまとめる項目です。

Ⅶ　 プロトタイプ検証

プロトタイプ検証の意義は、新しい業務フローの課題を早いタイミングで発見することにあり、プロジェクト後期に効果を発揮します。

どこに欠陥や改善の余地があるのか課題の先出しをし、認識合わせをすることで効率的に開発を進められるのです。

プロトタイプ検証では「作り込みすぎない」ことがポイントです。

プロトタイピングは、関係者全員で作っては壊しを繰り返す作業なので、たたき台らしい見た目で作るのが肝心です。

仮に画面設計までつくると作業時間も掛かる上に、本筋ではない箇所にまで議論が及んでしまいます。

（例えば、レイアウトやボタンのデザインなどのディティール部分）

初期段階では　ブループリントで設計するのがお勧めです。

ブループリントはユーザ視点でサービスのタッチポイントやデータの流れを図式化するツールです。

これにより、ユーザを中心におきながら機能単位でシステムを可視化し、整理検討することが出来ます。

アナログでも充分機能するので、低コストかつスピーディに検証可能です。

◆請求データの自動作成機能におけるブループリントの例

要件定義の精度を高め、プロジェクトを成功に導きましょう

失敗に陥りやすい要件定義ですが、要件定義の進め方のコツや必要なスキルはお分かりいただけたでしょうか。

合理的で使いやすいシステムを開発するためにも、各関係者を巻き込んで共に創り上げていくこと、発注者の要望の解像度を徐々に高めていくことが重要です。

精緻な要件定義を行い、プロジェクトを成功させましょう。

おわりに

クランチタイマーでは、システムの構想段階からお手伝いし、お客様のビジネスの価値を高めることを目指しております。

システム開発でお困りごとがあった際はぜひ我々にご相談ください。