ソリューションアーキテクトが語る　失敗しない要件定義の実践術

はじめに　〜本記事について〜

2023年11月にモンスターラボの社員より『ソリューションアーキテクトが起こす、小さな現場革命　〜「炎上案件 ゼロ」を実現する上流工程の仕事術〜』という書籍をKindleより出版いたしました。

・ソリューションアーキテクトが起こす、小さな現場革命　〜「炎上案件 ゼロ」を実現する上流工程の仕事術〜

この書籍が題材としている”ソリューションアーキテクト”ですが、皆様にとっても、まだまだ聞き慣れない職種かと思います。
ところが、我々がをシステム開発を担当させていただく中で、ソリューションアーキテクトが活躍する現場では

・サービスの実現方法がわかりやすく提示され、運用後のイメージが膨らんだ
・プロジェクトに潜むリスクが早い段階で提案され助かった

といった嬉しいお言葉を多数、頂戴しております。
そこで本記事では書籍の紹介も交えながら、ソリューションアーキテクトという職種の活躍と提供価値について連載形式で紹介していきます。
注）これ以降、ソリューションアーキテクトについては”SA”と表記させていただきます。

今回のテーマ：失敗しない要件定義の進め方

第3回目となる本記事では、テーマを「要件定義の進め方」に置き、ソリューションアーキテクトが実践する失敗しない要件定義の進め方をご紹介していきます。

プロジェクト成功の鍵を握る要件定義

要件定義はシステム開発における最上流工程に位置し「今回のプロジェクトでいつまでに何を作り、何を実現するか」といった発注者とベンダー間で必要な「決めごと」を決定・合意するプロセスです。

私自身、案件の成功・失敗の50％以上が要件定義で決まると思っており、具体的には要件定義を怠った先には以下の未来が待っていることでしょう。

・リリース後にほとんど使われない不要な機能に時間と予算を奪われた
・機能数が多すぎて予算と納期が合っていない（最初から炎上前提）
・開発の途中で発注者とベンダーの認識齟齬が多発し、開発が進まない

このような失敗を招かないために、プロジェクトの最上流工程で「今回の開発で作るもの・作らないもの」を決定させ「作るものの内容が予算と納期の観点で妥当か」を見極める必要があります。

要件定義は計画の見直しが許される最初で最後の機会

プロジェクトが数週間・数ヶ月と進むにつれ、予算と納期の変更は難しくなります（既に使ってしまった時間とお金は戻ってきませんよね）。
しかし、開発がほとんど始まっていない要件定義の段階なら、発注者側も妥当性が理解できれば、(プロジェクト後半と比較して)予算と納期の調整がきく段階ではないでしょうか？

これは予算や納期だけでなく、サービスに実装する機能面でみても同じことが言えます。
例えば、当初は想定にはない機能が、サービスリリースにとって必須であることがわかったとします。これが開発中盤だと残りのリソースにも限りがあるので追加予算・納期延伸などが必要に…。しかし、開発初期の要件定義段階で発見できれば「他の機能を来期に回す」など選べる選択肢に幅が生まれるでしょう。

このように要件定義は、発注者/ベンダー双方にとって今回のプロジェクトで損失を生まないための最初で最後の見直しタイミングとなるのです。

要件定義を成功させる５つのSTEP

ここまで要件定義は、プロジェクトの最初に取り掛かる作業で、今後の方向性を決める重要性を秘めていることを説明してきました。

しかし、まだ全体的に曖昧さが多いプロジェクトの開始段階では「具体的に何をすればいいのか？」「どうすればプロジェクトの鮮明度があがるのか？」と作業に戸惑い、苦戦している人も多いのではないでしょうか？

そこで、今回の記事では要件定義の抑えるべきポイントをなるべくシンプルに表現しながら、その中でも「業務フローの作成」「制約と非機能要件」の２つについて具体的な実践術を紹介していこうと思います。

• １．業務フローの作成
  • ・要件定義の最初に発注者の現状・課題をまとめ、どのように解決していくかを体系化した業務フロー図を作成する 
• ２．機能一覧の洗い出し
  • ・作成した業務フローを元に今回の開発で必要な機能を洗い出す
• ３．タスクへの落とし込み
  • ・洗い出された機能を実現するために「誰が・いつ・何をすればいいか」を具体化し、メンバーが動ける状態にする
• ４．制約と非機能要件定義
  • ・今回の開発ではやらないこと・できないことを決め、サービスの健全性を担保する
• ５．スケジュール立案と見積もりの見直し
  • ・要件定義の結果によってプロジェクト計画に変更が必要でないかを見直す

★ポイント 今回紹介できない他の手法については書籍の中で詳しく記載させて頂いております。 ➡︎書籍の購入・閲覧はこちら

実践術１：永続利用可能な業務フローの作成

要件定義における最初の作業としてクライアントからヒアリングした現状・課題をまとめ、どのように解決していくかを体系化した業務フロー図を作成します。

私は、ソリューションアーキテクトとして要件定義を担当する上で、この業務フロー作成は必ず最初にやっています。

ここからは、業務フローはなぜ必要なのか？実際に作成する業務フローの失敗・成功例について順を追って見ていきましょう。

業務フローの必要性：入力と出力を確実に抑え、手戻りを回避する

業務フローを作成する一番大きな理由は、入力と出力の期待値誤りは大幅な手戻りを招くリスクの根源であり、これを確実に回避するためです。

「誰が、何を入力するところから始まるのか？」といった、対象業務のスタートが固まっていない状態でプロジェクトが進むことは経験上、非常に危険です。

これは、後になって最初の入力条件が変更になると、その後に続く全ての処理に影響がでる可能性が高いからです。

アウトプット側にも同じことが言え、利用者が望む最終アウトプットが曖昧な場合、どこに向かえば正解なのか迷子になったり、プロジェクト終盤になってから「必要なのは、これじゃなかった」と大幅な見直しを迫られるケースも…

このようにサービス開発において、入力と出力の変更は全体に及ぼす影響が極めて大きいので、要件定義の最初に抑えることでプロジェクト全体に1本の芯を通すようにしています。

業務フローの失敗事例：機能ごとの依存関係が曖昧

要件定義で作成する業務フローですが、サービス化対象において主に以下２つのことが表現されている必要があります。

・入口から出口までの一連の流れがシステム的に可視化されていること
・実装する機能面における関係性（依存関係）が整理されていること

特に業務フローの作成で失敗が多いのは、後者に記載した「依存関係の整理」です。業務の流れを順に並べていけば前者を満たす業務フローは自然と出来上がってくるかもしれません。しかし、それらの関係性・影響度を意識したフローの作成は意識的に作成しないと、機能ごとの関係性が曖昧なままになってしまいます。

実際に入力処理に変更要求が発生した時に「影響範囲は出力部分だけ」と判断して変更対応を進めた結果、全く予期しない処理にも影響・依存関係が含まれており、想定外の対応に時間とコストを取れるという失敗がありました。

機能ごとの依存関係は、要件定義以降の設計工程で具体化していくことが多いかもしれません。もちろん、それも正しい進め方であり、要件定義段階で大切なのは、機能ごとの依存関係を表現できる業務フローを予め作成しておき、後から追加・確認ができる状態にしておくということです。

業務フローの成功事例：機能ごとの依存関係を明確化

前節で紹介した失敗事例を元に私は以下のようなイメージで業務フローを作成するようにしています。

これは入力・出力に着目した業務フローで、入力/出力には密接な依存関係が発生しており、逆にデータベースおよびデータ抽出処理には依存関係がないことを明示化しています。

このような機能ごとの関係性を明示化したフローを作成しておくことで、将来的な変更が発生したときに影響箇所をすぐに確認できます。

加えて、要件定義以降の設計・開発工程において「【入力/出力処理】と【データ抽出処理】には依存関係を持たせない」ということが意識付けられるので、実際の開発においても両者への関係性を切り離したサービスが作られていきます。

このように機能ごとの関係性が疎結合化することは、サービスリリース後に変更や機能追加が発生した場合でも対応範囲を限定化できるのでサービス全体のコスト削減に繋がります。

実践術２：制約と非機能要件

要件定義が進むと必要な機能やタスクが決まり「今回のプロジェクトでは何をしないといけないか」が明確になってきます。

これは「やることを決める」という作業でしたが反対に「やらないこと・できないことを決める」という作業も要件定義では非常に重要になってきます。

これが「制約と非機能要件」に該当し、例えばWebアプリの開発では

・スマートフォンからの利用は対象外（PCのみサポート）
・タッチパネルでの選択やボタンクリックは不可（マウスのみサポート）

など、要件定義の段階で制約を定義し、発注者と開発ベンダーの双方で文書による合意を結ぶことが推奨されます。

なんとなく「やらないこと」を最初に決めておくことは、非常にネガティブなイメージを持たれるかもしれませんが、そうではありません！！

実際には発注者・開発ベンダー・サービス利用者の全員がハッピーになるために必要な作業であり、その理由を失敗事例も交えながら紹介していきます。

失敗事例：「非機能要件＝悪いこと」の勘違いによる悲劇

過去に社内利用限定のスマホアプリ開発において「誰かがタブレットで利用するかも」と利用者がいるかもわからないタブレット側の動作保証に当初想定以上のリソースを使ってしまい、サービスに必須となる他機能の開発が後半になって遅延するというトラブルがありました。

この場合、要件定義の段階で「タブレットでの利用は本当に必要なのか？」「必要な場合でも優先度はどうなのか？」などの確認と取り決めを行い、優先度が高いタスクを先に進めるなどの考慮が必要でした。

限られた貴重な予算と時間を非効率に利用することは、発注者側にとって望ましい状態とは言えず、利用者にとっても使う予定のないタブレットでの動作保証より、必要とする機能が予定通り使えることが望ましい状態だと言えます。

失敗事例から学ぶ「非機能要件」の進め方

失敗事例でご紹介した通り、限りある予算と時間を適切に利用するためにも「やらないこと・後回しでもいいもの」を発注者と開発ベンダーが協力して決めていくことは大切です。

その進め方としては、まず開発ベンダーが機能要件一覧に対して、優先度やリスクの観点から調整が必要と思われる機能に対して「対応する場合・しない場合それぞれのメリットとデメリット」を定量的にまとめ、それを見て発注者側が「やる・やならい」を判断する流れがおすすめです。

一見するとごく普通なことに感じますが、先程挙げた「タブレット利用」の例では

・発注者：スマホで動くならタブレットも簡単だろう
・開発ベンダー：発注者が必要と言うので大変だけど断るのは…

という両者の思い込みが解消されないまま進んだことが根本の原因としてありました。

ここで開発ベンダーが「タブレットの対応は追加で１０人日必要。その理由は…」など具体的な数値や理由を伝え、それを受けた発注者側も理解と納得感をもって優先度を調整できれば問題は起きなかったかもしれません。

まとめ

今回は要件定義における「業務フローの作成」「制約と非機能要件」を例にまだまだ曖昧なことが多いプロジェクトの序盤で、最高のスタートを切るための実践術をご紹介させて頂きました。

書籍の中では、今回紹介しきれなかった要件定義の他プロセスにおける進め方と実践ノウハウもご紹介しております。

今回の記事に興味を持っていただけましたら、2023年11月に出版された『ソリューションアーキテクトが起こす、小さな現場革命　〜「炎上案件 ゼロ」を実現する上流工程の仕事術〜』にてSAのより詳しい業務内容をご紹介しておりますので、こちらもお手にとっていただけますと幸いです。

サービス・プロダクト開発を検討している企業ご担当者様へ

モンスターラボは、約20年にわたるサービス・プロダクト開発実績から得られたデジタル領域の知見や技術力を活かし、デジタルプロダクト開発事業を展開しています。

先端テクノロジーに対応した高度なIT人材があらゆるプラットフォーム上での開発を支援します。アジャイル開発とDevOpsによる柔軟な開発進行や、国内外のリソースを活用したスケーラブルな開発体制の構築も可能です。 また、リリース後の保守運用や品質向上支援まで伴走可能です。

モンスターラボが提供するサポートの詳しい概要は以下リンクをご確認ください。

➡︎モンスターラボのサービス概要はこちら

案件の相談はこちら