システム開発だけじゃない―もっと“ふだん使い”できる「要件定義」（前編）
「要件定義」と聞くと、どんなイメージを持ちますか？
情報システムやソフトウェア開発のプロジェクトに携わる方にとっては使い慣れた言葉かもしれませんが、そうでない方には、あまり馴染みがないかもしれません。
JOINSでは、成果の出たマッチング案件を振り返ると、「副業人材が要件定義をリードしたことが成功要因の一つ」という話をよく見聞きします。また、副業人材を探す企業向けのサービス紹介でも、「要件定義からお願いできるのが副業プロ人材の強み」と語っています。つまり、やや「要件定義」推しなのです。
「要件定義」とは何をすることを言うのでしょうか？なぜ、そんなに大切（推し）なのでしょうか？
目次
要件定義とは？
「要件」を「定義」する
「要件定義」を検索すると、その意味や方法、コツなどを教えてくれるページがたくさん見つかります。でも、そのほとんどは（少なくとも検索上位50番目くらいまでは）、情報システムやソフトウェアの開発における上流工程の一部として「要件定義」を説明するページです。
特定の分野の用語として意味を理解するには、情報ソースがたくさんあって助かります。が、その前にもう少し、この言葉が意味するところを輪郭からつかみたい。なのでもう、国語辞典から始めてみます。
- 「要件」 大切な用事、必要な条件。【類語】条件、前提
- 「定義」 物事の意味・内容を言葉で明確に限定すること。
2つをつなげてみると、「大切な用事、必要な条件を、言葉で明確に限定すること」。つまり要件定義とは、「ある目的のために、やること・やらないことを、みんなが理解できるように言語化すること」というイメージでしょうか。
主にシステム開発の文脈で使われる専門用語
先ほども触れましたが、「要件定義」は主にシステム開発の文脈で使われる専門用語です。
「要求」を取捨して、「要件」として合意する
“ステークホルダのニーズ、要望、課題を分析し、利用者や他のステークホルダが必要とするサービスを提供するシステムに対する要求を定義し、ステークホルダと合意して、要件とする。”
例えば、「間接業務のコストを削減したい」という経営ニーズや、とりわけ「経費精算業務を効率化したい」などの業務上のニーズを把握して、目的を実現するうえで解決しなければならない課題を洗い出し、優先順位をつけて取捨選択します。
そして、その業務の仕組みを実現する方法を定義します。例えば、「経費精算シートを起票する時に、過去の履歴をコピー利用できるようにする」、「領収書をスキャンして帳票に自動反映する」などのように、「システムに対する要求」として具体化します。
それらの要求をわかりやすく文書などにまとめて、「要件」として合意します。
「要件定義」が、プロジェクト成功のカギを握る
“システム構築の上流工程における重要プロセス”
“要件定義を適切に実施することにより、それに続く開発プロジェクトの失敗を減らし、構築するシステムに対する品質要求に応え、対象システムにより実現されるビジネスや新たなサービスに、より高い価値をもたらす”
「上流工程における重要プロセス」、「それに続く開発プロジェクトの失敗を減らし」とあるように、要件定義を着実に行うことが、プロジェクト成功のカギを握っています。関係機関による様々な調査結果でも、システム開発の失敗（工期遅延、予算オーバー、品質不良など）の多くは「要件定義の失敗」が原因であることが指摘されています。
筋の良い要件定義は「効果的、作れる、使える」
“要件定義で定義する要件は、経営や業務の改善において効果的で、実際にシステム化することができ、業務で使えることが重要です。そのため、定義した要件の品質を評価する基準として「効果的」「作れる」「使える」の三つが挙げられます。”
要件を定義できたら、その品質をチェックする必要があります。次の3つの基準で評価し、不十分な点があれば追加や修正をしましょう。
- 「効果的」 経営・業務上のニーズに応えられるか、目的を実現するうえで重要な課題を解決できるか。
- 「作れる」 開発担当者から見て、実現可能な仕様か。リソースやスケジュールに無理がないか。
- 「使える」 業務フローが明確か。前後の工程（入力・出力）も含めて、実際に動かせるか。
システム開発以外のプロジェクトにも応用できる
「要件定義」のプロセス（少し詳しく・やさしく）
「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ（独立行政法人情報処理推進機構（IPA））」によると、「要件定義」の主なプロセスは次の4つに分類されます。
- 要件定義マネジメント（RM: Requirements Management）
- ビジネス要求定義（BR: Business Requirements）
- システム化要求定義（SR: System Requirements）
- 文書記述（DD: Documents Description）
上の表現のままだと難しい（かたい）ので、もう少しゆるめに解釈してみます。
ビジネス要求定義（BR）は、「どんな状態を実現したいか」「どの課題を解決するか」を明確にすること。システム化要求定義（SR）は、「そのために何をするか（何をつくるか）」を明確にすること。文書記述（DD）は、明確にしたことが誰にとっても一意に解釈できるようにわかりやすく言語化・資料化すること。要件定義マネジメント（RM）は、そのプロセスが問題なく進捗するように気を配り、道のりを整えること、最後に品質をチェックすること。
このように書きくだしてみると、だんだん意味が読み取れてきます。と同時に、「要件定義」のプロセスが（システム開発の文脈に限らず）色々な仕事に応用できるものであるように思えてきます。
特に「ビジネス要求定義」は汎用的なビジネススキル
中でも、顧客やステークホルダが求めていることを明確にしていく「ビジネス要求定義（BR）」は、「要件定義」の本質ともいえる工程です。ビジネス要求定義は、次のように分解して説明されています。
ビジネス要求定義
1 ビジネス要求の獲得（「実現したいこと」を把握する）
1.1 現状の把握
1.2 問題・課題の抽出
1.3 ゴールの抽出
1.4 手段の抽出
2 ビジネス要求の分析（「実現したいこと」を精査して合意する）
2.1 要求の体系化
2.2 要求の具体化
2.3 優先順位付け
2.4 要求の交渉
3 ビジネス要求の文書化（「実現したいこと」を可視化する）
3.1 文書化
ここでも、「要求」という単語を「実現したいこと」くらいに読み替えてみると、必ずしもシステム開発の文脈だけでなく、あらゆる問題解決の場面で求められる「基本動作」が並べられていることが分かります。
どの課題を解決するか、言語化して合意していくプロセス
顧客やステークホルダの「こういうことで困っている」「こういうことを実現したい」を掘り下げて、「どの課題を解決するか」を特定すること、「そのためにはどうすればよいか」選択肢を並べて、「はじめに何をするか」を選ぶこと、それを言語化して企業と副業人材で合意すること。それらが大切だということは、過去の記事でも紹介してきました。
スモールウィンにつながる副業人材の特徴
“外”から来て、“中”の人になる―副業人材にしかできない「問題解決」（前編・後編）
期待に応える副業人材は、手間を惜しまず「ゴールを握る」（前編・後編）
「問題解決（問題設定）」や「ゴールを握る」動きは、広い意味で「要件定義」と同じことをしています。このことからも、要件定義（特にビジネス要求定義）は、やや抽象的に解釈すれば、システム開発のような特定の領域に限らず、色々な場面で応用できる仕事術である、と言えそうです。
「要件定義」的思考を“ふだん使い”する
主にシステム開発の領域から生まれてきた「要件定義」という言葉、概念。その思考法や動作は、色々な仕事やプロジェクトに応用できるということを（繰り返し、しつこいくらいに）述べてきました。
と、ここまで書いたところで、本当は順序が逆なのかもしれない、と思い始めました。「システム開発の領域から生まれてきた仕事術が、他の広範な領域にも応用できる」ということではなくて、その逆、つまり「広範な領域で求められる仕事術（暗黙知）が、たまたまシステム開発の領域で体系化（形式知化）が進み、『要件定義』という名前がついた」ということなのかも？と。
- もともと、どんな仕事にも必要とされる（「要件定義」的な）仕事術みたいなものが先に存在していた
- でも「要件定義」とは呼ばれず、暗黙知となっていたり、「問題解決」や「ゴールを握る」など別の表現で部分的に整理されたりしてきた
- そこに、システム開発のような大きな投資を伴うウォーターフォールな仕事が現れ、広がってきた
- たくさんの時間やお金を掛けるぶん、不具合や手戻りがあった時のロスが大きいことから、「要件定義」的な上流工程が特に超重要視されるようになった
- その結果、（必要に迫られて）その手法の形式知化・体系化が進み、正式にこれを「要件定義」と呼ぼう！となった・・・のかもしれません。（※想像です）
だから、「要件定義」が汎用的なのは当たり前といえば当たり前で、ここでそんなに繰り返して力説するほどのことでもなかったのかもしれません・・・。
いずれにしても（上記の想像が正しくても、正しくなくても）、「要件定義」はみんなが“ふだん使い”していいものであることは確かで、それはJOINSがサポートする地域企業と副業人材の関係においても同じです。次回（後編）は、その副業人材に期待される“要件定義モード”について考えてみます。
（後編につづく）
（イラスト｜freepik.com）
シリーズ スモールウィンにつながる副業人材の特徴
【スモールウィン】地域企業が抱える課題に副業人材が向き合い、「小さくても具体的な成果」を出すこと。それがお互いの信頼のベースをつくり、「次の仕事」が生まれ、持続的な関係につながっていくとJOINSは考えています。
投稿者プロフィール
