柔らかいソフトウェアアーキテクチャを作っていきたい

(ポエムです)

最速で成長し続けられるようなアーキテクチャの柔らかさってどうやって作っていけるのだろうか。

まず何は意思決定して固く設計して、何は意思決定を遅らせるのか、遅らせたとして、いつまで遅らせるのかを都度判断していく必要がある。

そしてそれをチームの共通認識にするために意思決定プロセスを皆が理解できる水準のドキュメントを残したり、レビューやガイドライン等ですり合わせないとズレがチリツモで大きくなっていく。チームが分割されたり、人数が多くなるほど難易度が上がる。

そして、設計の意思決定は事業特性や自分たちの事業に対する解像度にモロに依存するので、結局は事業解像度を上げにいく動きがセットで求められる。上げにいく動き自体をENGがやることは少ないかもしれないが、理解はしていなければならない。それをしないと開発も前に進まない。

また、そういったイテレーティブな活動を技術的負債をゼロに維持したまま進めていくことは人類には不可能だと思った方が良い。

よって、どの程度の技術的負債を抱えているかは常に意識しておきたい。そして負債には利息があり、コア機能に近い領域の負債、借入期間が長い負債ほど利息も積み上がっているようなイメージを自分は持っている。

これは例えばスクラム開発においてのリファインメントで相対見積もりで開発を進めている時などに、実測値との乖離が大きい状態が続いた場合に判明しやすい。以前と同様のボリューム、難易度のはずなのになぜこんなに大変なのか？それはシンプルに利息分含めた技術的負債、複雑性が積み上がっているからだと思う。

そして各負債は

• 返済し切るのか

• 利息率を下げるのか、

• 利息を敢えて払い続けるのか

を意思決定していく必要がある。例えば数年に1回しかいじらないLPにイケてないコードが残っていた場合、そっとしておくという意思決定が有用なことも多い。

「モノリスをマイクロサービスに」、「フレームワークを置き換えましょう」みたいな大掛かりなアプローチも利息率が極限まで高まって負債が貯まる速度がおかしくなったソフトウェアに対して意思決定されたものだと思う。でもそれはプロダクトのバランスシートの左側にプロダクト価値という資産が十分貯まっている前提での話であるべき。

まあ偉そうに色々書いたけど、めっちゃ難しいし、面白い。