システムアーキテクトの失敗から得た学びを振り返って、次システム設計するときに同じ過ちを繰り返さないようにプラクティス化しました。
前提
- システムのこと
- システム規模は中くらい
- ３年間稼働しており、現在も成長中サービスでエンハンス案件多い
- 筆者のこと
- エンジニア歴8年（インフラ構築、SRE的な業務がメイン）
- 現職は中途入社で2年目
- これまでは保守的なことがメイン業務なのでアーキテクト経験はあまりない
ことの経緯
突如、ある要件を満たすようなアーキテクチャを設計することになりました。
既存システムで保持しているデータを外部に連携することが主な要求です。
自分のポジションは、案件の開発リーダーです。
要求はプロダクトオーナーが決めて、私がそれを要件に落とし込んで設計します。
設計したものは、有識者含む開発メンバーにレビューしてもらいます。
この設計&レビューのプロセスで想像以上に時間がかかり、スケジュールが大幅に遅延しました。
要求がシステムを複雑化させれたとはいえ、優秀な方ならもっとスムーズに進められたはずです。
一言でいうとアーキテクチャ経験の少なさが要因です。
進め方の何が悪かったのかを振り返ると、大きく3つの過ちがあったので、これらをプラクティスとします。
1. 何を軸に決めるのかを意思決定者と目線を合わせておく
これは一番最初にすべきことでした。
うちの職場はとても自由度が高く、新しいサービスを使うことに割と賛同してくれる方が多い印象です。
(例えばDatadogの新サービス、Amazon Bedrockを活用した運用効率化など)
むしろ、チャレンジングなことの方が目を惹く印象です。
でも時と場合によりけりで、今回は稼働中サービスにインフラを追加します。
最近は大きめな障害を起こしたこともあり、システムを止めないことに最も関心があります。
私はその前提があることを考慮せずに、保守実績のないサービスや、コア機能に大きめな改修を入れようとしていました。
結果、肯定的な意見はあまり貰えず、実装/保守コスト低の案を採用することになりました。
シンプルで運用しやすいことなのか、多少保守難易度が高くてもスマートにしたいのか、組織が何を重要視するのかによって選択するアーキテクチャは変わってきます。
上位目線の判断ができる有識者にシステム設計する上で、新サービスに対する温度感や明確な判断軸がないか確認しておくと良いです。
2.手段が先行しないこと
自分がイケてると思ったAWSのサービスでも、使い易さ、実装難易度といった観点で見れば、他の人にとってはイマイチということがあります。
そういった評価すべき別の軸を見落として、このサービスは銀の弾丸だ！と思い込んで前のめりになっていました。
気が付かないうちにこれを使いたいという手段が先行して、平等に評価するという姿勢を崩していました。
分かっていても誰しもが陥りがちなことですが、常に客観的な視点を持つことを忘れてはいけません。
仮にチャレンジングなアーキテクチャにするなら、しっかりと全体を見渡して、他にも実現方法を調査した上で、その良さを伝えることが大事です。
3.要求をどう実現するかだけでなく、構成をよりシンプルにするための要件を探る。
スタンスの話で、要件をどう実現するかを決めるのが自分の責務だと何処かで思い込んでいました。
これは本当に良くなくて、要求レベルを落とすことができるかもしれないのに、頑張ってどう実装するかを必死に考えていました。
要求をこのように変えられたらシンプルになるよね？とコメントを貰ったとき、ハッと気付かされました。
要求を鵜呑みにするのではなく、開発の難易度を伝えた上で、実装や構成をよりシンプルにできる妥協案を提案するべきです。
後々、無理に要求を実現したことでシステムが複雑化し、変更容易性が失われたり、システム障害を起こしてしまったら、WinWinではありません。
本当にその機能は必要なのか、もっと要求レベルを下げられないかといった疑いは常に持ち、システムを守るために要求の落とし所を探るスタンスを持てるようにしたいです。