学習記録:12月22日(土):はじめよう!要件定義 Chapter-09 [準備編]実装技術を決めよう(前編)
これは 俺のインプットアウトプット記録 Advent Calendar 2018 の22日目のエントリーです。
昨日は大まかに区分けしようということで、登場人物(ステークホルダー)と使うサブブロックによって区分けして、全体の見通しを良くしようという章でした。
で、そこから僕なりに以下を学んだ気がします。
- コツコツと丁寧に積み重ねる根気
- 根気を失わない1つ1つの小さな達成感
- 単一責任の原則に基づいた分解
サブブロックをみて、その先にある「合意しなければならないことの多さ」にめげるんではなく、1つ1つ分解してシンプルにし、明らかにしていくことが楽しくなるように考えて行けばいいのかなって思ったりしてます。
ほら、プログラミングしてる時も、Controllerに処理を書いてるうちに、どんどん切り出していって、名前を単一の責務にして、名前と処理内容を同一にできた時って楽しいじゃないですか。
それと同じだなって思ったりしてます。
閑話休題。
というわけで今日は Chapter-09 を進めます。
Chapter-09 [準備編]実装技術を決めよう
システムアーキテクチャと、その次の層の個別の実装技術を決めていく章のようです。
ソフトウェアアーキテクチャの決定
要件定義は合意事項を洗い出したら終わりというわけじゃなく、次の工程、つまり後工程に必要な情報を定める工程とあります。
最終的にプログラミングまで繋いでいくわけです。プログラミングとは言ってしまえばゼロイチに落とし込む仕事、白黒はっきりしてないと実現できないし、はっきりしないまま進めた実装は機能ではなく勝手な行動で、成果を伴うのが仕事であることを考えれば、はっきりしないまま進めるのは仕事とは言えばいはずです。
プログラミングで実現可能な要件にする必要がある
本来、アーキテクチャ設計と呼ばれる作業で、実施時期はプロジェクトマネジメントに基づくとあります。
- 何を使ってプログラミングするのかを決定しないといけない
- 技術選定
- 方式の方針決定(Webなの、スマホからなの、などかな)
実現する道具を探すことでもあり、道具を探すなら、先に要件を定義してからアーキテクチャを決めるべきだという論調もあるのは僕にもわかります。
要件が決まらないと採用する技術も決められないよ、と。
とはいえ。
実装の都合がわからないとソフトウェアの要件が決められないのも事実
とあります。この行間がわかりにくかったんですが、先に出てきた通り「何を使ってプログラミングするのかを決定」する必要、ここでいうとプログラミング言語とかではなく、
- ユーザーは何を使うのか
- スマホなのかPCなのか専用端末なのか
- どんな通信手段なのか
- Webだったらインターネットだろう
- クライアントサーバ型?社内の独自基盤?
- これは要求を聞いた時点でわかりそうだけど…
- 散々言うように「当たり前を定義する」必要がある
ということなのかな、と思いつつ読み進めます。
ソフトウェアアーキテクチャを決める手順
大きく2段階あるとのこと。
- 第一段階:基本的なシステムアーキテクチャを決める
- 第二段階:各部の個別の実装技術を決定する
なるほど大きく間違ってがいなかったようです。
基本的なシステムアーキテクチャを決める
第一段階に、もう少し細かい解説がなされ、以下の選択肢から組み合わせで決めるとあります。
メインフレーム
- 独自基盤のことで間違いないようです
- なんとなく90年代を思い出しますが、必要な理由もあるでしょうし、要望、要求から判断しないといけなさそうです
二層クライアントサーバ型
もう1ついうと、三層(プレゼンテーション・アプリケーション層が分かれていて、アプリケーション層をサーバ側に持つのも選択肢に入るような気がします。
Webブラウザ型
- インターネットを使った三層って解釈でいいのかな
- 一般的なPCサイトってこれでしょうね
モバイル端末+Webサーバ型
- スマホのネイティブアプリ
決めること
サーバの置き場所(オンプレ、クラウド)の検討が必要ではありますが、まずは
- 利用者がどこで
- どのような機器を使い
- ソフトウェアを利用するのか
を決める必要があります。
各部の個別の実装技術を決定する
上述のように、基本的なシステムアーキテクチャを決定したら、第二段階として、システムアーキテクチャを構成する各部に対し、
- どんな言語?
- どんなフレームワーク?
を使って開発を進めるのかを決めていく、とあります。
で、書籍ではこの後に詳細な図が続くのですが、本日はここで力尽きたので明日続きをやります。
感想
一貫して 上から順に1つずつ丁寧に確認して決定し、合意していくこと が身に沁みます。
可能性の低い内容は、ともすれば書籍や講義では略されたり飛ばされたりしがちだな、と思うんですが、例えばメインフレームなど、Web全盛時代に詳しく語るものに触れなくなってきたことも、きちんと触れています。
いやWebでしょ、と最初から思っていたら「あ、軽視しそう」って思ったし、それってそもそものユーザーとのコミュニケーションに問題発生しそうだし、ユーザーが本当に求めていることを要件として定義することをやってるのに、 最初から決めてかかるのはダメだよな って改めて思わされています。
徹頭徹尾丁寧で、諦めずにコツコツ積み重ねた結果、合意できる。これは本当にずっと忘れないように今後も進めたいと思います。
ともすればそれは「当たり前」で済まされそうだけど、自分で何回もテキストに落とし込んでいくし、 思ったら書く、の回数を繰り返す ことで 自分の中の当たり前を言語化する ってことも続けていかなくちゃなってことに気づいたりしました。
結局、要件定義から失敗しているプロジェクトは、
- どこかで軽視した
- 忖度がプロの仕事だと勘違いし空気を悪い意味で読んだ
- 決めてかかった
- モダンにこだわり過ぎた
- そもそもの本質を見極められなかった
ってことなんだろうなって思います。
それらをしないためにも、今後も丁寧にやっていきたいと思います。