刷新プロジェクトの教訓と成功のポイント
話題は、成瀬氏が次回のアーキテクチャ刷新で「絶対に取り入れたい」と考えるKPT（Keep, Problem, Try）の実践例に移る。
まず成瀬氏は、次回も「1人で作り切る」方法を再び採用したいと強調した。これについては、「一人で全体を把握しながらツールを作成することで、複数メンバーで進めるよりもパフォーマンスが高くなる可能性があります」と説明する。一人であれば、誰に何を聞かれても即答でき、チームに安心感を与えるリーダーシップを発揮できる。細かな文化や監査の要件にも柔軟に対応でき、素早くアジリティを発揮できる点も大きな利点だという。
次に「クラウド設計」の重要性についても触れ、「リソースの引っ越しが難しいため、最初にすべての設計を固めておくことが必要」と述べた。また、手作業を避けて仕組み化することで、ミスを防ぎ、リソース管理を厳格に行える環境を整えることが重要だとも強調した。
成瀬氏はベースコードの配布についても言及し、「全員がゼロからクラウドやアプリを学ぶ無駄を省くため、ベースとなるコードを自分が作り、それを共有したことで、チーム全体のノウハウを統一できました」と評価する。同じ基盤を使うことで、各チームが統一した考え方で進められ、効率的に作業が進む体制が整ったというわけだ。
また成瀬氏は、システムやツールの整備についても重要性を説き、次のように語る。「例えばCodeCommitからGitHubへの移行も、ツールの力を借りてスムーズに実施できました。全員が確実に作業できるようにするためには、ツール化が不可欠であり、また『人はミスをする』という前提でツールを作ることが重要です」。機能の拡張や追加もツール化しておくことで容易に行え、改善を繰り返す柔軟な体制を整えられるのだ。
続いて、成瀬氏は「二度とやりたくないこと」として、過去の失敗から得た教訓を共有した。
まず、「AWSアカウントの使い回し」が失敗の一例だ。成瀬氏は、PoC（概念実証）で使い込んだAWSアカウントが混乱を招いた経験から、次のように指摘する。「PoC専用のアカウントを用意し、本番環境と明確に分けることで、不要なユーザーやロール管理に悩まされずに済みます」。
また、「複数チームが同時にスタートする」ことの失敗も挙げた。これをしてしまったために、全チームが同じタイミングで同じ課題に直面し、レクチャーが1日では終わらず、効率もモチベーションも大きく低下したというのだ。「次回があるなら、まず1つのチームで前例を作り、それを他チームに展開していく方が効率的です」と成瀬氏は、反省を込めてこう語った。
さらに、「1年で成果を出そうとすること」の難しさも指摘する。1年で成果を求められる環境では、適切な人材がプロジェクトに割り当てられず、学習しても十分に進められないケースがあったという。成瀬氏は、「兼任ではなく専任の優秀なメンバーを確保し、長期的な視点でプロジェクトを進めることが重要」と説明した。
「チームメンバーに任せすぎたこと」も課題だったという。全体を把握しないと動けないメンバーが多く、成瀬氏は「リーダーがまず前例を示し、少しずつ学びを広げるアプローチが必要」ということを学んだという。また、プラットフォームチームの不在も問題で、「AWSのような専門領域に踏み込むには必要な存在でしたが、必要性をうまく伝えきれず、コスト削減が優先されて技術導入が遅れました」と振り返る。さらに、アーキテクチャ決定での迷いも後悔しており、最終的にはリーダーが明確な方向性を示すべきだと強調した。
まとめとして成瀬氏は、「戦う相手は人の心の弱さと複雑さ」として、「今回私が話した経験やKPTの内容は、多くの方に再現できるはずです。ぜひ皆さん、先駆けを走れるよう頑張ってほしいです」と締めくくり、セッションを終了した。
