元ネタがあれば、書くことには困らないし、すぐに書き終わるぞ( ^ω^ )と考えた、しょっさんです

実際に書いてみると、おおまちがいだったことに気が付きました。原稿書けよ、俺って本気で感じています。

要件定義をしていく

要求編はまだ続きます。前回では、「想いを言葉にできる」人をアーキテクトとすると定義しました。では、その想いをどうやって言葉にしていくか。手法とフレームワーク、注意点を確認します。

良い要件定義とは

まず、そもそもの「要件定義」の目標を定めましょう。

先日ご紹介したIT アーキテクト育成ハンドブックや、Wikipediaでは、次のように記されています。

要求の充足評価では、ビジネスシステムの効果測定が可能な評価項目を明確化し、それを具体的に計
測できる基準を明確にしてゆきます。その上で設計したアーキテクチャに基づくシステムの要求に対す
る目標達成の見通しを明確にするのです。そしてその結果は要求者に対して合意形成すると共に、下流
のシステム設計者に技術移管と指導することが重要です。 「IT アーキテクト育成ハンドブック」

「要件定義」は（開発依頼のあったソフトウェアやシステムについて）顧客が望んでいる機能や仕様などについて、その概略をまとめた文章・文書を指すこともある[3]。ただしこうしたことをまとめた文書は通常は「要件定義書」と呼ばれる。Wikipedia

重要なポイントは次の二つです。

1. 機能や仕様をまとめたもの
2. 効果測定可能な評価項目

簡単にまとめましたが、いずれも難関です。それでは、これらポイントから「良い」要件定義と評価するための、具体的な内容に落とし込んでいきましょう。

1. 機能や仕様をまとめたもの

個人的な経験則も踏まえて、次の3つがポイントです。

1. お客様が必要と認識しているすべての機能が、網羅されていること (FR:needs)
2. 実際に利用するユーザーの視点に立って、期待値を超える機能が網羅されていること (FR:seeds)
3. 異常動作時における動作・方針が定められていること (FR:exception)

これらが「網羅」されていることが重要です。1.に特に重点が置かれがちですが、実現したい機能以上に、その機能が利用しやすかったり、利用したくなるような UI/UXは重要です。Web系やモバイル系では、UI/UXデザインの画面デザインベースで勧められるケースも多く、解消されている感はありますが、それらの正当性や提案は ITアーキテクトからできるべきと考えます。

忘れがちな「障害が発生した場合」の処理は、方針が定まっていないと、個々に方向性の異なった異常対処を行うことになりますので、かならず含めましょう。「それって可用性要件では?」としか感じないインフラエンジニアは、「クレジットカード番号の検証が済んで、カード会社への要求もすんで、お客様への請求処理まですすんだけれども、そこで障害が発生してDBに処理状況が保管できなかった」ケースは、どの非機能要求に含めるのか考えてみてください。なお、このフロー自体おかしいので、真似しないでくださいネ。

最後に、「その機能は本当に必要ですか?」

2. 効果測定可能な評価項目

1. 技術動向や、お客様の経営課題・経営状況・予算など制約条件が考慮されていること (NFR:制約)
2. すべての機能は、効果測定可能な評価基準を定めて「数値で」判断できること (NFR:品質)
3. すべての機能は実現可能であること (reliability)

これらも「網羅」できていることが、必須条件です。さっきから「MECEMECEMECEMECE」うるせえよ( ﾟдﾟ )ｸﾜｯ!!と思われるかもしれませんが、これが担保できないとなりませんし、担保する方法も無きにしもあらずです。今日は書きませんが。

多少 ITアーキテクトをかじっていた人にはおなじみの、「非機能要件」です。可用性、性能・拡張性、移行性、セキュリティなどなどがここに含まれます。しかし、それらは 2.で示している、ソフトウェア(アプリケーション)の品質的要件です。それらすべてを実現することが正しいのではなく、1.の社会的、企業的制約条件にしたがって、何をどこまで実現するかが関わってきます。

なお、「制約」とは、今のお客様の力では変更することができないもの、例えば法的効力、予算などです。「非機能要件」とは、お客様が個々で定めることのできる「目標」です。すべてのシステムは24/365で稼働する必要などなく、自社営業時間内(たとえば、9:00-17:00)だけ 99.9%のシステム稼働率を目標にすれば、夜は止まっていても良いなど、そのシステムの目的によって変わるものです。重要性などにより、データの保全性や、可用性も変わることでしょう。しかし、システム稼働要件を100%とすることは実質不可能ですから、落とし所をどこにするかを、納得いく「数値」へ確定することが重要なポイントです。

そして、「数値化」です。「システムテストしますよー」といったとき、一体何を基準にそれらを評価するのでしょうか。「〜の機能が動くこと」とは何を持って動くことと判断するのでしょう。「それは、すべての機能が正しく動作することです」といった場合「では、1万人が同時にアクセスする可能性があるこのシステムにおいて、それらの機能は、どのように動作することが正常動作でしょうか」という反証に答えるすべがなければなりません。機能テストだけを済ませておいて、実際にサービスインした後、「動かないんだけどー」は、この数値目標がないために起こります。性能テストを行うにしても、「何をクリアできたら、この性能テストはいいんだっけ…」となったら、破綻目前です、おめでとうございます、サービスイン後に寝られない日々が続きますね( ^ω^ )ﾆｺﾆｺ

最後に「実現可能性」が担保できるシステムであることを、よくよく検証してください。すべての要件と非機能要件がでてきて、それらをすべて記述できたら「完成ヽ(´ー｀)ノ」ではありません。例えば「役所に問い合わせが必要な処理があり、これは1分間に20回しかコールできない制約がある」のに「役所へ問い合わせる機能は、最大で1分間に100回コールする可能性がある」は相反する要件です。よくあるのは予算が不足するケースです。要件定義では「要件まとめたぞヽ(´ー｀)ノ」で終わりではなくて、システムの概要が見えている、または想定アーキテクチャは記述できているべきです。そして、実現するべきシステムの概算は準備できていて、ホントに予算内に納まりそうかどうかのアセスも必要です。デスマーチの温床となる基本は、スケジュール不足ですが、その要員工数は1日を何時間で作業させるつもりなのか、テストを実施する環境はあるのか、法的にリスクはないのか、お客様の責任者は退職しないか、十分にあんテナを貼る必要があります。

良い要件定義を実現するには

これらを遂行するために必要なことは、システム工学において要求分析として定められています。実際に、この要求分析に従って実現することは、不可能であることは見ていただければ明確です。とは言え、本来、ITアーキテクトやコンサルタント、ITエンジニアに求められる能力とは、それ相応のものであることは理解しておかねばなりません。とは言え、何を学んでおくべきか、何を知り得るべきか、については世の中に便利なフレームワークや体系がありますので、これらを利用しない手はありません。ただし、技術的知識よりもITアーキテクトは、コミュニケーション能力が重視されます。

それらについては、次回以降。これ、完成するのかな。

まとめ

まだ推敲したい段階ですが、FR/NFRともに3:3の項目が出ているので、後はより詳細に書いていくくらいしかなさそうなので、この辺にしました。