「エンジニアリング戦略の作り方」を読んだ
「エンジニアリング戦略の作り方」 / Will Larson (岩瀬 義昌、岩瀬 迪子 訳) を読んだので感想を書く。
内容の概要
この本の1章を見ると、
本書はエンジニア戦略、つまりエンジニアリング分野において適切な判断を下す方法に焦点を当てています。
と書いてある。当たり前だが、
- エンジニアリング分野に絞っている
- 適切な判断を下す方法について書かれている
ということがわかる。
戦略のたて方の具体的なステップについては、「良い戦略、悪い戦略」 / リチャード P.ルメルト のアプローチをエンジニアリング分野にまとめなおしたもの、と紹介されている。
戦略をたてるステップとして以下を上げている。
- 探求: やろうとしている戦略に関係していることを幅広く調べる
- 診断: 課題の詳細を分析し、理解する
- 洗練: テストやモデリングを通じて検証、改善をする
- 運用: 戦略に基づいた行動を実行させる仕組みをつくる
本の後半では具体的な事例を元に、これらのステップでどういうことを行っているのかが説明されている。
所感
戦略とは？
著者が「戦略は常に存在する」と述べている通り、この本における「エンジニアリング戦略」は無意識的にかなりのソフトウェアエンジニアが行っていることだと思う。
自分も仕事のRailsプロジェクトで新規サービスをたちあげるにあたって、リポジトリを分割せず、packwerkを導入して依存関係に制限をいれる方針にしたことがあるが、これも言ってみればエンジニア戦略の一つだった。
未来に影響がある、何かしらの決断は全てここでいう戦略としてしまっても問題ないように思う。
問題はそういった決断を戦略として明示的に文書などでまとめておくべきか？というところにありそうだ。
戦略を書き出すことで、組織や個人の学びにつながる、と本書は主張している。
あまりに些細な技術選定の結果まで戦略として書き出す必要はないかもしれない。ただ、この本にもあったように、過去の技術選定をまとめて、「このチームでは戦略としてはこういう方針になっていそうだ」、というところを文書化してチームメンバーとの意識のすり合わせをする、などの活用はできそうだ。
日々の仕事に役立てそうか？
現在働いている会社は小規模なので、あまりここまで考える必要もないのかなと感じた。一方、大規模な会社で、かつそれなりにコード資産もあるような状況だと、変更をするコストも大規模になる。そうなるとここまでステップをしっかり踏む必要があるのだろうな、と感じた。
とはいえ、少しは前述のステップを暗黙的に活用していたところもあると思う。前述のpackwerk採用について少し考えると、
- 探求: packwerkのことは何かのWeb記事で知っていた。
- 診断: 新サービスをたちあげるにあたり、何が問題になりそうか、を考えた。まずは、少人数でメンテナンスしないといけないこと。また、一部共通ロジックがあること。これらにより、別リポジトリ、別サービスにしてしまうよりは、同じリポジトリで管理したほうが保守コストが少なそうだと考えた。ただし、暗黙的に依存関係が野放図に増えていってしまうことは防ぎたい、考え、packwerkとした。
- 洗練: package_todo.ymlでの依存関係の管理方針などは随時アップデートした
- 運用: 新サービスをリリースしたあとも開発時はpackwerkを使いながら開発を続けている
とあてはめることはできる。
この本を参照することで、これらを暗黙的に行っていた状態から、意識的に行えるようになりそうだ。
その他
Wardlyマップの存在は知らなかったので、機会があれば活用してみたい。
特に昨今のAIの躍進により、(一部の)開発はインスタントなものになってきた。「何を作るか？」がより重要になってきているように思う。
Wardlyマップを使って、AIの影響も考えつつ戦略をたてられるとよさそうだ。
