学習記録：12月23日(日)：はじめよう！要件定義 Chapter-09 ［準備編］実装技術を決めよう（後編）
これは 俺のインプットアウトプット記録 Advent Calendar 2018 の23日目のエントリーです。
書いてたけどエントリーとして出し忘れてました。
昨日は実装技術を決めるということで、基本的なシステムアーキテクチャとして、メインフレームなのか一般的なWebなのかアプリなのか、などを決めた上で、各部の言語やフレームワークをどうする？のところで終わってました。
というわけで今日は Chapter-09 を読了していきます。
Chapter-09 ［準備編］実装技術を決めよう（続き）
システムアーキテクチャを決めたら、次は各部の実装技術です。
各部の個別の実装技術を決定する
どんな言語やフレームワークを使って、それぞれの部位のソフトウェアを開発していくのか、という話になります。
毎度ながら、書籍の図を自分で描いてみます。
システムアーキテクチャを決めた後の第二段階、これだけのことを決めないと実装イメージに近づかないということがわかるかなーと思います。
大手企業の方言でいろんな表現があるものの、基本設計、詳細設計、システム設計、外部設計など、工程に合わせた内容を当てはめて行けば、必ず検討事項および決定事項になる項目が、緑の吹き出しで表現されているわけですが、これを全部要件定義の時点で蹴ってきているプロジェクトに出会ったことがない僕は、本当の意味で幸福ではなかったんだろうなあと思ったりはします。
とはいえプロジェクトにはいろんな事情があるのはわかるし、それを解決してこそ仕事と考えるのもわかるんですが。
でもここで思うわけです。俺たちもお客さんを選ぶのが普通である、と。お客さんと我々は真の意味で対等でしょうし、対等であるという姿勢で望むことが結果として、お客さんに対しての結果を正しく出せる、プロとして導ける。
それ以外の上下関係や、営業成績としての無価値な値引きは断り、対等なビジネスをできる相手を厳選していくのが本筋なんだろうなっていつも思います。
もちろん、要求、要望を要件にしっかり落とし込む、その過程でお客さんのやりたいこと、企画、熱意を形にする、という「仕事の大前提」があった上での話ではありますけれども。
と、それはさておき。
この図で検討すべき項目が書籍では箇条書きされています。
クライアント側
ユーザーが実際に使う内容ですよね。
- ユーザアクションの検知方法は？
- マウス
- タッチ
- 音声
- 入力や受信データの保持方法は？
- データと画面上の項目との連携方法は？
- 画面遷移はどのように行う？
- クライアント側のプログラミング言語はなに？
通信
- 通信プロトコルは？
- 通信データのフォーマットは？
サーバ側
解説
最低限のインタラクション（人間が何かアクション(操作や行動)をした時、そのアクションが一方通行にならず、相手側のシステムなり機器がそのアクションに対応したリアクションをする、の意味）を構成するだけでもこれだけの項目が必要ということです。
ここ、すっごい曖昧なまま進むこと多いよなって思うし、曖昧にした結果、例えば言語とフレームワークの決定が遅れて人員確保が遅れて失敗したまま運用してるプロジェクトもプロダクトも知ってますし、サンプル作るにも、何で作ればいいの、モックだけで無意味になるのはダメだよな、って思ったりしました。
実装技術を決める意味と僕の思い
要件を実装に落とし込む方法、それは選定した技術次第で多種多様になるよね、とあります。ここの落とし込みは要件定義のスコープ外になるのでこの書籍では深掘りしてませんが、
要件定義の前に、1つのインタラクションすら実装できないなら、実現は心もとない
という言葉に心から同意します。
上流下流という言葉を嫌う傾向にあるよね、でもそれ本質的に余計に曖昧にしてるんじゃねぇの？ってことは以前のエントリに書いた気がします。が、上流とそれ以外は別物と考える傾向もあるなと思います。無意識にね。
でもそこで、要件定義と実装ってどうなの？切り離せるの？となると
絶対に切り離せない
と僕は思いますし、切り離して成功したプロジェクトは見たことないです。それだけ僕が「切り離して、もしくは曖昧なまま失敗したプロジェクトに多く在籍していた」ってことにもなるんですけど。
それは別として、 前工程で決めたことを後工程に繋げて送っていく 、ってことが本題な訳ですよね、プロジェクトの。
その中で、後工程とのつながりを曖昧にしたまま もっともらしい日本語でごまかす のは、僕は愚の骨頂だと思っています。
そんなん炎上するだけだし、誰も幸せにならない。
基本的な実装の裏付けはこの「実装技術選定」の時点で用意しておかねばならんのだな、って思います。
感想
イケてる言語、フレームワークがこれだからやろうぜ、っていう技術選定、結構見るんですよね。
でも、ほとんど炎上してるんですよ。まじで。例を挙げるとキリがない。
一方で、 本当にそのプロジェクトに必要な技術は何か を妥協せずに決めていったプロジェクトは大抵成功してるし、いい人材も集まるし、 のちのメンテや運用も回って たりします。
今流行ってる言語やフレームワークが、少なくとも5年後に先端なのか。先端じゃないにしろ、生き残って言語やフレームワークコミュニティとして世界的に運用されているのか。
これはサービスの行く末と大きくリンクすると僕は考えています。
よりシンプルにできて、ロックインされない技術。基盤。
可能な限り、そういうものを選んで行きたいし、できる限り、枯れた部分に根ざしたエンジニアとしての活動をしていかねばな、っていうことを、読んでいて思ったりしたのでした。
だから俺は、データベースやDNSが好きなんだろうなあ、って思ったりもしました。
まだまだ根っこの技術の習得も知識も経験も深掘りも足りませんが、 足りないって自覚があるのは成長の証 だと思って今後もやって行こうって思ったりもしました。
未来はやることがたくさんあって楽しいぞ、っと。