どーも、こんにちは!!
思うところあり、Qiitaにはポエムしかしたためなくなりましたが、それでも寝言は続けたいと思います。
今回のポエムは標題の通り「アーキテクチャが先か機能要求が先か」と言うことです。
「アーキテクチャが先」論
私の周りには「アーキテクチャを先に調査してそこから欲しい機能を作る」というかたがいます。
たとえば最近私の中でホットな話題が多いMinIOやApache Kafkaがアーキテクチャとして使用できるものとした場合、その組み合わせの中でできる機能を模索した結果、ログをApache KafkaでおくってMinIOに溜めてみよう！と言った形です。
「機能要求が先」論
一方で、「機能要求を洗い出し、そこからアーキテクチャを選定する」と言う方法が考えられます。
たとえば、「方々からのログを溜めておきたい、ログはひっきりなしに来るのできちんとした設計が必要」となったときに、じゃぁApache Kafka使ってS3互換のストレージ(例えばMinIO)に溜めたらどうですか？となるわけです。
それぞれのメリット・デメリット
端的に申し上げますと、このようなメリット・デメリットがあると思います。
| 手法 | メリット | デメリット |
|---|---|---|
| アーキテクチャが先 | 調べるアーキテクチャが少なくて良い | 局所解に陥りやすい |
| 機能要求が先 | 要求にフィットした機能を充てやすい | 何でもよく知っていなければならない |
アーキテクチャが先の場合、調べることはかなり少なくなりますのでコストは下げられるでしょう。しかしデメリットとしてそれが最適解である保証はありません。少なくとも調べたアーキテクチャの中では最適解かもしれませんが、それが局所解に陥っている可能性があります。
機能要求が先の場合、調べることと言いますか、知っていなければいけないことがたくさん増えることが予想され、その必要な知識量は膨大になります。しかしそこから要求に適うアーキテクチャを選定する事ができると言うことがメリットとしてあげられるでしょう。
昔教わった「ソフトウェア開発方法論」では･･･
私が二十数年前に大学一年生で教わった方法を例に後者でのソフトウェア開発をちょっとだけ書いておきます。
- KJ法を使って要求をまとめる：KJ法とは川喜田二郎氏が考案した方法でその氏のイニシャルを取ってそう呼ばれています。KJ法では所謂プレストの時点で「要求」や「困っていること」などを次々に付箋紙に書き出してボードに貼り付けます。それをグルーピングしてそのグループ化されたどのようなアプリケーションがあったら良いか考えます
- 必要な機能を洗い出す：1番のKJ法でまとめた要求に対してどのようなアプローチで解決するアプリケーションを作成するか、手法および必要な機能を決定します
- 設計：きちんと設計をします
- 実装：設計書通りに機能を実装します
- テスト：きちんと要求を満たしているかテストします
- 発表：テストがおわったら、ブレストからテストまでの軌跡をまとめ、プレゼンします
というわけで･･･
私は「要求機能が先でアーキテクチャはその後に考える」派なのですが、その逆を考えている人がいるってことを書いてみました。
寝言は以上。おやすみなさい。