Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち を読んだ。

感想など

章ごとに別々の開発チームの話が展開されていく感じ。

そのぞれのチームに癖があったりする状態なのだけれど、それを乗り越えたりうまいことやろうとしたりしていることをインタビュー形式で共有していただく感じだった。

レガシーシステムがいろいろなところで出てきた。

私もレガシーシステムと戦っている所なので、いろいろ考えて読んでたが、以下が大事なのかなと思った。

• 考古学
• アーキテクチャ
• 腕力
• MVP

考古学

レガシーなシステムはいろいろな事情で意図していない使われ方をしていることがあるので、そこを丁寧に分析していく考古学が必要だと改めて分かった。 その先、どうやってよさそうな状態に持っていくかはまた別の問題だけど。

アーキテクチャ

アーキテクチャが適切だったので、影響範囲を絞って改修ができたシーンがいくつかあったと思う。

どうしても個別のコードは汚くなってしまうけど、大きな視点で見たときに、システムが疎なら、E2E の試験書いて書き換えが進めやすくなるし、考えるときも分けた考えられる。

先々を見通して完全にきれいに維持することはできないけど、依存関係とかインターフェースとか守るべきところを守っておくとたっぱりやりやすいことはあるんだなと。

腕力

ガッとやんないと進まない時があるので、それをやれること。 また、それを許容してリリースできる文化も大事だと思う。

当然これが許容できるのは切り戻しが容易であるなど、文化だけじゃなくて技術的な地盤も関係するけど、

やっぱりパワーがある人がガッと書き換えるとかはできる状態であってほしいなと思った。

ただ、これも、書き換えの対象が閉じていないとお話にならないのでアーキテクチャ的に無理とかはあるのだろう。。

という感じで、いろいろ前提があったうえで振るえる腕力だけど、腕力は持っていたい。

MVP

つくり直そうぜとなったときにどこまで作り直すかという点。

小さく作って育てていこうぜがやっぱりよさそうで、ビジネスサイドとそういう考えで進めていくと共有したうえで進めることがもっと大事。

これも結局文化的な話で、「こうしてください」から始まる開発じゃなくて、「こんなことができないかね？」で始まる開発にならないといけないなと。

まとめ

面白かった。