本記事は
【プルリクウィーク】
5日目の記事です。
💻
4日目
▶▶ 本記事 ▶▶
6日目
📚
はじめに
こんにちは！最近また子どもたちがバナナハマり期に入っていて、バナナのスケーリングが間に合っていない志水です。前回のハマり期は一気にスケーリングさせたタイミングで食べなくなり、一人でコツコツ食べる羽目になったので、今回のバナナスケーリング戦略(BSS)は慎重にいきたいと思います。
現在、私たちのチームは、17個のプロジェクトを担当しており、15名のチームです。その中に開発チーム2つと運用チーム1つがあります。それぞれのチームにはリーダーがいて、3-6名のメンバーが所属しています。
チームが多くのプロジェクトを抱える中で、効率的な作業プロセスの確立が求められています。その中でも特に重要なのが、プルリクエスト（PR）の承認プロセスです。PRはコードの品質を保ち、バグを未然に防ぐための重要なステップですが、全てのPRを一人で承認するのは効率的ではありません。
本記事では、SECIモデルを活用し、AWS CDKを用いたAWSのプルリクエスト（PR）の権限をチームリーダーに委任する手法について解説します。このプロセスを通じて、メンバーに必要な知識を効果的に伝達し、リーダーが自立してPRを管理できる体制を整えます。さらに、権限委任後のフォローアップとして、委任がスムーズに機能しているかをモニタリングし、問題点を洗い出します。現状全てを完璧に実行しているわけではないものの、理想としてはこのような運用を目指しています。
SECIモデルとは？
SECIモデルは、知識創造のプロセスを共同化・表出化・連結化・内面化の4つのステップで説明する理論です。これらのステップは、暗黙知と形式知の相互変換を通じて進行します。まず、暗黙知と形式知について説明します。
- 暗黙知: 個人の経験や直感、洞察に基づく知識で、言語化や文書化が難しいもの。
- 形式知: 文書やデータとして明文化された知識で、他人と共有しやすいもの。
次に、各ステップにおける暗黙知と形式知の変換を説明します。
共同化（Socialization）
- 暗黙知 → 暗黙知
- 例: OJT（オン・ザ・ジョブ・トレーニング）で経験やノウハウを直接共有する。
表出化（Externalization）
- 暗黙知 → 形式知
- 例: 暗黙知を言語化し、ドキュメント化や口頭での説明を通じて明文化する。
連結化（Combination）
- 形式知 → 形式知
- 例: 複数の文書やデータを統合して、新しい知識を創造する。
内面化（Internalization）
- 形式知 → 暗黙知
- 例: 文書化された知識を実践し、個人の経験として吸収する。
SECIモデルでは、この4つのプロセスを繰り返していくことで、チームや個人のスキルが上がります。
PR権限委任の必要性
もともとは私がリーダーで、メンバー2名の合計3名のチームでプロジェクトを回しており、その時は自分が全てのPRを見ていました。
チームがどんどん肥大化しても、ある程度までは全プロジェクトの全PRをレビューしていました。理由としては、PRレビューがシステムの品質に関わると思っているので、チーム全体の品質担保として全チェックが必要だと考えていたからです。ただ、それが次第に回らなくなってきて、レビューに遅延が発生するなど、プロジェクトメンバーに迷惑がかかるようになってきました。
これを機に信頼できる各リーダーへ権限を委任することにしました。
SECIモデルを活用したPR権限委任のステップ
SECIモデルの4つのプロセスを用いて、チームリーダー個々のPRレビュースキルを向上させながら、PRレビューの権限をどのように委任していくかを説明します。
共同化 (Socialization)
元々私とリーダーはレビュワー・レビュイーの関係だったため、私からのレビューを通じてリーダーに対して経験やノウハウを共有していました。これを経験することで、だいたいどのような事を意識して指摘をしているか、という観点が共有出来ました。
また、チーム全員が参加する朝会などのミーティングで、最新の技術やベストプラクティスを共有します。例えば、CDKを使用したIAMポリシー設定のベストプラクティスを紹介します。また、PRレビュー時の心構えや留意点をディスカッションしました。
表出化 (Externalization)
PRレビューのプロセスや基準、CDKの実装ガイドライン、コードの静的解析の結果やテスト標準化に関するドキュメントを作成し、リーダーに提供します。リーダーが中心となって、知識を文書化し、他のリーダーに共有します。例えば、CDKを使用した具体的な実装例についても文書化します。
連結化 (Combination)
文書化された基準やプロセス、静的解析のツールと結果、標準化されたテストケースを統合し、リーダー全体で共有するためのシステムを構築します。具体的には、Confluenceを使用してチーム用のスペースを作成し、そこに必要なドキュメントを作成していきます。最新のツールやプラットフォームを活用して、知識の統合と共有を効率化します。
さらに、形式化された知識を活用することで、ChatGPTやAmazon Bedrockなどの生成AIを用いてPRのレビュー精度を向上させることも目指します。生成AIは、統合された知識ベースを活用して、コードの品質を自動的に評価し、フィードバックを提供します。これにより、レビュアーの負担を軽減し、レビューの一貫性と品質を向上させることができます。
内面化 (Internalization)
リーダーが実際にPRをレビューし、静的解析やテスト標準化のプロセスを実践することで、形式知を自分の暗黙知として吸収します。フィードバックセッションを開催し、レビュー結果についてのディスカッションを行い、知識を深化させます。
品質管理のステップ
SECIモデルを活用してPR権限を委任した後も、そのプロセスが適切に機能しているかを確認し、必要に応じて改善を加えることが重要です。以下に、品質管理を継続的に行うための具体的なステップを示します。
KPIの設定とモニタリング
PR権限委任後の品質を維持・向上させるために、以下のようなKPIを必要に応じて設定し、これらを定期的にモニタリングします。これにより、委任の有効性を評価し、調整を行うことができます。
レビュー効率
- 平均レビュー時間: 各PRのレビューにかかる平均時間を計測し、委任前後で比較します。
コード品質
- デプロイ失敗件数: CDKコードの変更により発生したデプロイ失敗の件数を計測します。
- リソースの不整合数: デプロイ後に発生したリソースの不整合の数を計測します。
テストの成功率
- テスト成功率: コミットごとに実行されるテストの成功率を計測します。
セキュリティ遵守率
- セキュリティ警告数: cdk-nagを用いたセキュリティチェックの結果として検出された警告の数を計測します。
- セキュリティインシデント数: 実際に発生したセキュリティインシデントの件数を計測します。
フィードバックと改善
定期的にフィードバックセッションを開催し、KPIの結果を共有します。これにより、全員が品質管理の重要性を理解し、共通の目標に向かって努力することができます。また、フィードバックを基にプロセスの改善点を見つけ出し、継続的な改善を推進します。
まとめ
SECIモデルを活用したPR権限の委任と品質管理は、知識創造のプロセスを通じてチームの効率と生産性を向上させる有効な手段です。今後は、PR権限の委任だけでなく、多様な知見にもSECIモデルを積極的に適用し、継続的な改善を進めながら、より良いチームビルディングと組織作りを目指しましょう。
このブログを通じてコミュニティへの表出化を行うことができたと考えています。次は、プルリクウィークで他の人の記事を参考にしながら、連結化以降のプロセスをスパイラル的に改善していくことを期待しています。それでは！
