昔に『人月の神話』は本を買って読んだはずだけど、手元には残っていないので、該当部分だけ O’Reilly Online Learning で読み直してみました。“Hopes for the Silver” という節に、世の中では銀の弾丸と目されているけれど、Brooks 自身はそこまでは思わない近年の技術的進歩が列挙されているんですが、Ada とその他の高級言語の発達、オブジェクト指向プログラミング、と時代を感じさせる並びの後に来るのがなんと人工知能! でもここで
The techniques used for speech recognition seem to have little in common with those used for image recognition, …
教授! 我々はついにその2つを繋げられるなにかを見つけましたよ! というところで本題へ。
複雑さはどこから来るのか
複雑さには色々な場所からやってくる。
まずはドメインというか、解決するべき問題そのものから発生する複雑さ。いわゆる SE っぽい仕事の人々はこういう本を読んで、RDBMS のスキーマとかを延々と議論している、というのは私の偏見。金融とか医療とかにも、何かドメイン特有の複雑さがあるんだろうと思う。
ソフトウェアを書くプラットフォームから来る複雑さ。私は Android のフレームワークとしての良し悪しについて議論するほど Android アプリを書いていないけれど、Web アプリケーションは結構書いていて、HTML + CSS + JavaScript は、プラットフォームとしては格別に複雑だと思うし、* { Box-sizing: Border-box } FTW なんてのを見ると、複雑さの一部については偶発的なものといってもいいと思う。
もっと一般化すると、これは時間からくる複雑さともいえる。レガシーな仕様や実装が事態を複雑にすることは良くある。1900年の1月と2月を除いては。
クライアントサイドの、ソフトウェアが走る環境の多様性からくる複雑さ。Facebook の Year class: A classification system for Android なんかは、モバイル (といっても Web) をちょっとやっていた身としては、なるほどこういう手があったのかという感心があった。
そういえば Alexa 時代は、自然言語処理からくる複雑さに悩まされることが時折あった。基本的には Intent と Slot という形に抽象化されていて、自分が機械学習っぽいことをする必要は無いのだけど、それでも抽象から複雑さが漏れていることはある。
こうやって振り返ってみると、今に自分がやっているサーバーサイド仕事は複雑さが、無いというと語弊があるけれど、あまり四方八方からくる感じはない。複雑さの多様性に欠けている。
自分のソフトウェアは基本的にはデータセンターの中で走るだけだし、プラットフォームとしての Linux は、ソフトウェアごとに違う設定ファイルにはうんざりしつつも、Web とは比べものにならないくらい単純。プロダクトマネージャーと話はするけれど、ドメインの専門家とユビキタス言語を作りましょう、というほどドメインに距離も複雑さもない。
大企業は専門化しがちなのかもしれないなあ。チームの規模として大小色々やっている karino2 さんはどうですか?