ビジネスと狭義のエンジニアリングの関係性のポエム

企業活動の全ては売上を上げるために存在する。
であれば社員一人一人の行動は最終的に売上として現れる必要がある。
（もっと言うとかかった経費以上に売上がある必要がある）
エンジニアリングにまつわる全ても最終的には売上という数字として表れないといけない。
何をどうやって作るかを日々考えて実行することが売上に繋がっていないといけない。

エンジニアリングによって売れないものを売ることはできない。
（エンジニアリング自体が直接売上になる受託とかSESは別として）
より速く作ってリリースするとか、確実に動くように作るとか、使いやすいものを作るとか（これは狭義のエンジニアリングからはちょっと外れるかも）、売れてるものを機能強化するとか、速く省エネで動くようにするとか、そういうことはできる。
逆にエンジニアリング単体ではそれ以外はできない。

エンジニアリングによって直接提供できる価値を抽象化するとロバストネスとアジリティになる。
常に理想的なエンジニアリングが行われている理想的な状態を考えた場合（まあそんなのありえないんだけど）ロバストネスとアジリティはプロダクトが成長すればするほど下がる。
上がることはない。ある程度維持はできるかもしれない。

なぜ下がる方向しかないか、それは複雑性を0以下にはできないから。
トータルで見て複雑性を上げない努力がつまり狭義のエンジニアリング、とここでは仮定する。

ところで無限に知能の高い生物がアプリケーション開発するとしたら、たぶんバイナリを直接書くのが一番複雑でないアプローチのはずだ（無限に高い知能があったらコンピュータ要らない説はあるけども）
そこから逸脱するアプローチは全て人間の頭の性能限界によるものだ。
たとえばなぜプログラミング言語があるかといえば、人間にとってはコンピュータは抽象化しないと理解できないものだからだ。

しかし今となっては信じられないがスーパーファミコンあたりまではアセンブラで書いてたらしい。
アセンブラで書いてたのにはメモリもCPUも貧弱だったからという理由もある。
コンパイラもなかったしコンパイルも遅いしコンパイラによる最適化も貧弱だった。
メモリやCPU資源が潤沢になると（あとネットワークとか使える道具が増えると）大きなものを作ることができるようになってきた。
大きなものを作ろうと思ったとき、機械語やアセンブラでは抽象度が低すぎてきびしい。
だからプログラミング言語が必要になる。

構造化プログラミングやオブジェクト指向やMVCやレイヤードアーキテクチャやマイクロサービスも突き詰めると同じ理由で存在する。
人間は巨大なものを巨大なまま理解できない。分割統治したい。
分割して部品単位だったり部品同士の抽象化された繋がりにすることでやっと理解できる。
ただ問題があって、部品に分割し部品の組み合わせになることで、全体としての複雑度は単純に上がる。
分割するためのレイヤーが増えるので、機能が変わっていなくても、分割しただけでトータルでは複雑になる。
全体の複雑性を上げないためにはレイヤーは少なければ少ないほどいい。
しかし部品の粒度が大きく複雑になると理解できなくなってくる。
もっと細かく分解できるツールが必要になる。
そんな感じで開発手法やアーキテクチャが進化してきた。

おそらく扱ってるものの大きさによって適切なツールが変わるのだろう。
単機能のコマンドを作るのにいきなりクリーンアーキテクチャでインタフェース作ってDIする人はいないはずだ。
構造化すらしないのではないか。

最近マイクロサービス疲れが流行っている。
新しいツールだからというのもある。
たとえばオブジェクト指向が誕生してふつうになるまで40-50年くらいかかった。まだ理解してない人もいる。新しい道具もふつうになるまで同じくらいかかるだろう。
マイクロサービスアーキテクチャを採用したとして、みんなどうサービスを分割したら良いかわからない。
分割統治のツールとしてもとびきり複雑だ。
ユーザーからみてサービスが5個とか10個とかあったらそれは分割した方が良いだろう。
そうでなければレイヤーを増やしたぶん無闇に複雑になっていないか？

複雑になればアジリティは下がる。ロバストネスでなくなる。

複雑にしてはいけない。

作ると複雑になるから機能はシンプルがいい。

エンジニアリングもシンプルがいい。

そう考えたとき、現状はベターですか？