はじめての非機能要件

はじめに ​

非機能要件はアーキテクチャを大きく左右するため、抜け落ちや認識齟齬があると大きな手戻りが発生する。そのため、できる限り早期に関係者と合意すべきである。しかし現状、要件定義から合意に至るプロセスは個人の経験に依存しがちで、標準的な手法が確立されていない。

本ガイドラインでは、この様な状況を改善するため、非機能要件について円滑に合意形成するための手法をまとめる。

前提 ​

想定読者 ​

本ガイドラインは、非機能要件の定義と合意をリードする立場の担当者を主な対象とする。「はじめての」と題しているが、まったくの初学者向けの入門書ではない。ここでの「はじめて」は非機能要件定義に取り組むのが初めてという意味であり、具体的には次のいずれかに当てはまる人を想定する（いずれも、個別技術の深い知識は前提としない）。

• プロジェクトのライフサイクルを一通り経験し技術的な勘所はついているが、非機能要件定義を担当するのは初めての人
• 非機能要件定義を経験頼み・我流で進めてきたが、標準的な型を身につけたい人

対象とするシステム ​

本ガイドラインが暗黙的に想定するシステム像は、次の通りである。

本書の構造 ​

本ガイドラインは、最初からすべてを通読する必要はない。読者が直面している課題やプロジェクトのフェーズに合わせて、必要なノウハウへ最短でアクセスできるよう、役割の異なる3部構成とした。

• 第一部（全体プロセス編）
  • 非機能要件を定義し合意するまでの、ドメインに依存しない進め方と思考の型。初めての方はまず通読を推奨する
• 第二部（個別ドメイン・ナレッジ編）
  • 可用性・性能など、要件ごとの具体的な決め方。必要な項目を辞書的に活用する。
• Appendix
  • 業界標準フレームワークや用語の正確な定義。裏取りの補助資料として用いる

非機能要件定義と成長 ​

非機能要件定義に本気で向き合う経験は、次のような形で、取り組む人自身を育てる。

• どう作るかから、何を作るべきかへ視座が上がる
  非機能要件定義は、どう実現するかではなく、何をなぜ作るべきかを議論し、合意する営みである。言われたものを作る立場から、何を作るべきかを考える立場へ転換できる。
• 技術的な深さが問われ、鍛えられる
  要件定義とはいえ、どう実現するか（設計）やどれくらいのコストがかかるかのイメージがなければ、深い要件定義はできない。実現可能性を欠いた要件を避けるには一定の技術的専門性が要り、弱い領域があればキャッチアップが求められる。裏を返せば、ここは技術力が試され、鍛えられる場である。
• ビジネスの視点が身につく
  ビジネスとして達成したいことが、システム要件としてどの項目に落ちるのか。その翻訳を実地で体験することは、技術とビジネスを橋渡しする力を養う。
• 合意形成のコミュニケーション力が磨かれる
  合意は、自分の都合ではなく相手の言葉に合わせて対話することで生まれる。これはアーキテクトに必須のスキルであり、実践の場となる。
• 網羅的に向き合うことで、自分を知る
  特定の非機能要件の実現について経験することはあっても、非機能を網羅的に意識する機会は、この要件定義フェーズをおいて他にない。全体を見渡すことで、自分の弱い領域も見えてくる。それは、己を振り返るきっかけにもなる。

非機能要件定義は、地味で、正解の見えにくい仕事である。しかし、視座・技術・ビジネス・対人・自己認識という専門職の土台が一度に鍛えられる場は、そう多くない。目の前の要件を埋める作業としてではなく、自らの成長の機会として臨んでほしい。

謝辞 ​

このアーキテクチャガイドラインの作成には多くの方々にご協力いただいた。心より感謝申し上げる。

• 作成者: 真野隼記、武田大輝、清水利博、亀井隆徳、河崎泰子
• レビュアー: 澁川喜規、宮崎将太