#有料記事にしていますが全文読めます 。

　自分のチームが担当している業務の成果として、チームメンバが非機能要件の考え方とアーキテクチャを説明することになりました。
自身で資料を作成／するわけではなかったけれど、メンバの資料レビューを通じて色々と思うことがあり、非機能要件の重要性を色々な局面で人に伝える人に向けて自分の考えを記載してみます。

1. 非機能要件(Non-functional requirement)とは？

Wikipediaによると、

システム設計や情報システム開発上の要求分析において、要件、システム要件といった機能面以外の全般を指す。
機能要件を実装するための設計がシステム設計であり、非機能要件を実装するための設計がシステムアーキテクチャとなる。

機能要件は「要件に対するシステムのふるまい」の形で記述され、（中略）
一方、非機能要件は、特定の状態のシステムとしてではなく、機能の全体的な特性を「システムが要件を満たさなければならない」の形で記述される。

と書かれており、「非機能要求グレード」として

1. 可用性
   * 可用性、耐障害性、災害対策、回復性、成熟性
2. 性能・拡張性
   * 業務処理量、性能目標値、リソース拡張性、性能品質保証
3. 運用・保守性
   * 通常運用、保守運用、障害時運用、運用環境、運用・保守体制、運用管理方針
4. 移行性
   * 移行時期、移行方式、移行対象（機器）、移行対象（データ）、移行計画
5. セキュリティ
   * 前提条件・制約条件、セキュリティリスク対応、セキュリティ診断、（中略）
6. 環境・エコロジー
   * システム制約/前提条件、システム特性、適合規格、機材設置環境条件、環境マネージメント

上記の６つの大項目に分類されている。

2. 非機能要件／アーキテクチャ設計の重要性

　私はWikipediaの記載の通り、非機能要件の本質とは「システムのふるまい」ではなく「機能の全体的な特性」だと考えているし、特性を形に表したものがアーキテクチャだと思っている。しかし、周りを見てみると非機能／アーキテクチャの検討や設計ができていないと感じることが多い。それはなぜかと言われると、自分が担当する機能の設計／実装しかこれまで経験しておらず、そもそもアーキテクチャの検討や設計をする必要がなかった。というのが正直な理由だと思う。システム全体の設計（アーキテクチャ設計）は、プロジェクトのアーキテクトと呼ばれるようなひとり／一握りの人が担当し、アーキテクトが設計した方針に従って開発を進めれば良かったということもある。
または、アーキテクト不在のまま十分に非機能要件の検討やアーキテクチャ設計がなされておらず、開発の終盤やシステム公開後に非機能に関する問題（性能／運用／可用性など）が発生し、開発した機能についても設計からやり直しをする羽目になっていたのでは無いかと思う。（稀ではあるが実際に起きている話）

　では、なぜ本来はアーキテクトが担務する仕事を、開発メンバ一人一人が意識する必要があるのか。以下の背景がある
- プロジェクト予算の小規模化
- 開発期間の短期化
- プロダクトからサービスへのシフト化（常時起動）
これらの背景により、少人数／短期間で目に見える成果を出さねばならなくなり、開発メンバがアーキテクトを兼務する必要が出てきていると思う。

　また、短期化かつサービス化を実現するために多くの開発では、単体の機能開発から、他社（AWS／Azure／Google/OSSなど）が開発した複数の機能(PaaS/FaaS)と組み合わせたサービスシステムの開発に変化していることも大きな要因だと言える。さらにクラウドのサービスでなくとも、自社や関係会社が開発した機能をWEB API経由で活用する事が非常に多い。

このような背景から、開発者にとって「機能の全体的な特性」を考慮した非機能要件の検討／アーキテクチャ設計が非常に重要になっている。

3. アーキテクチャ設計の難しさ、面白さ

　アーキテクチャ設計の難しさは何かと聞かれると困る人も多いと思う。
私はアーキテクチャ設計の難しさとは、開発を依頼する側が「機能の全体的な特性」なんて知らない／興味がなくても
価値や必要性を伝えて形にしなければならない事から来ると考えている。
大抵の場合は、非機能を考慮すればするほど検討費用〜開発費用／開発期間が膨れ上がり、依頼する側にとってもそこまでの費用／期間は許容できないということになるが、いざ利用し始めると使いづらい（運用／保守）／遅い（性能が許容できない）／会社のセキュリティ監査が通らない（セキュリティ）など、時には合意した要件であったのに現場が許容できずクレームが発生するリスクがある。勿論、要件書に非機能について明記すればクレームが来ても賠償責任を問われることは無いかもしれないが、依頼元との信頼関係が壊れてしまい今後のビジネスが破談になってしまうのも困りものである。

　しかしこういった理解のギャップは、依頼元が技術知識がないために発生するものでもないと思う。私は依頼元や開発担当者が、「システム」を利用者が自在に使う「道具：ツール」のように捉えていることが原因ではないかと考えている。道具とは利用者にとって「機能」そのものであり、「機能」に特化して仕様を検討／設計すると、開発者は自分の考えと利用者の考えに違いを見出せず、自分の作りたいように作ってしまう。
　

　本当は、道具だってPL法があり道具を使う人が誤って怪我をしたり、周囲に危害を加えないような考慮をした設計が必要である。このように書いていると、読んでいる人は非機能の検討や設計って面倒だなと思うかもしれないし、非機能要件の一覧表を作って、毎回確認すればいいと思うかもしれない。

　それらは正しい考えだと思うけれど、私は別の考え方もしてみたいと思う。
非機能要件とは、「機能」をどうすれば「使い続けてもらえるか？」を考える事だと考えている。
つまり、最初の機能提供のモチベーションは「XX機能が必要だから」という単純なものだとして、機能を提供して一度使ったら終わりにするのではなく、せっかく作るのだからより長く、多くの人に使ってもらえるためにはどうしたら良いかを考えたい。
時にはメンテナンスをして性能を上げたり、たくさんの人に手に取ってもらえる場所に置き直したり、先輩から後輩に独自の使い方を伝授してもらったり、新人が新しい使い方を発見できたりというような、利用者の体験（UX）を通じて愛着を持ってもらえると嬉しいと思う。

　システム開発を通じて、作り手の意図と利用者の意図の交換ができる仕組みを妄想しているとワクワクしませんか？と私はチームメンバに今度聞いてみたいと思っている。これこそアーキテクチャ設計の面白さだと私は思う。