作成した背景
カケハシでは新規プロダクトや大掛かりな改修に対し、Well Architected Frameworkに基づいたレビューを行っています。一方、フレームワークは汎用的に記載されており、特にAWSや非機能要件に慣れていないメンバーには各項目の具体的な内容がイメージしづらい側面があります。そこで、開発メンバーにとってより使いやすいよう、カケハシで利用している技術に応じて各項目を具体化しました。
特徴
280項目を採用
カケハシで採用している技術やプロセスをもとにWell Architected Frameworkの5本の柱とその質問を具体化した結果、280項目となりました。設問数に圧倒されないよう配慮しつつ、セキュリティは最も重要なので厚めに配置しています。
＊第六の柱、サステナビリティは一旦除外しています
フェーズに応じた絞り込み
細かくチェック項目を書きだすと無限に増えてしまいます。プロダクトの成熟度に応じて必要なものは変わってくるので、フェーズに応じてチェック項目を絞り込みができるように作成しました。
フェーズ列として、Starter / Pro / Enterprise の3種類があります。プロダクトの重要度や対象顧客によってグレードが上がり、必要な項目が増えていきます。
Go / No Goではない
あくまでも開発メンバーが使い、プロダクトを改善するためのツールであり、バツをつけるための監査が目的ではありません。
ローンチ直前以外にも使う
開発に入った早い段階でなるべくレビューの声をかけるようにしています。ローンチ直前のレビューに頼ると、せっかく見つかった事象を修正することは困難です。シフトレフトですね。
運用上苦労している点
Well Architected Frameworkへのキャッチアップが必要
Well Architected Frameworkに全体的に改訂が入り、項番がずれることがありました。
スプレッドシート自体のメンテナンス
スプレッドシートは汎用ツールなので限界があります。2021年に登場したWell Architected ToolのCustom Lensはまだ日本語が使えません。今後の対応が期待されます。
どこまでチェックリストに記載すべきか
ありとあらゆる状況をチェックできるようリストに追記していくとすると、ローンチチェックリストが辞典より分厚くなってしまいます。そうしたとしても、認識していないこと、今後変わっていくことを書き下すことは不可能です。
上記の悩みはミクロ経済学では完備契約と不完備契約、金融業界ではルール準拠とプリンシプル準拠の議論と似ています。 https://www.fsa.go.jp/common/conference/danwa/20070912.html
ルールベースのほうが自動化がしやすいメリットはありますが、多すぎて圧倒される、改訂が困難という弱点があります。プリンシプルベースだと逆に裁量が多すぎる、なにが適切なのか分かりづらいという欠点があります。
考えあぐねるところですが一つの方策として、組織全体の学習/スキルアップにより、あえて書かなくてもわかることを増やしていくという方法があります。そうすればより間違いやすい部分だけに着目できるでしょう。
今後の展開
まずは例えば四半期に一度、リストに基づいて現状を確認するといった取り組みを検討中です。 他にはre:invent 2021で登場したサステナビリティの柱を取り入れることを考えています。
文責: 高木
