ID:48647さん

株式会社Omakaseの5名のエンジニアチームで、複数のAWS／Kubernetes基盤、企業HP、業務自動化、AI利用ルール整備に関わる技術判断、担当割り振り、進行、委任後レビュー、運用プロセスをマネジメントしていました。自ら実装する領域と、他メンバーへ委任する領域の責任分界も管理していました。

チーム内の特定の個人や暗黙知を「単一障害点」にせず、急な休み・退職・担当変更が発生しても、他のメンバーが判断・実装・運用を継続できる状態を作る責務がありました。また、ミスの防止を個人の注意力や経験だけに依存させず、IaC、GitOps、自動テスト、監視・通知、レビュー、Runbook、利用ルールなどの仕組みによって構造的に減らすことを重視しました。そのうえで、AWS／Kubernetes基盤、企業HP、日報Bot、AI利用ルールといった性質の異なる業務について、責任者、変更範囲、確認方法、障害時の対応がチームから見える状態にし、品質と速度を両立しながら継続的に改善できる組織を目指しました。

私がマネジメントで最も重視しているのは、組織の中から「単一障害点」をなくすことと、ミスの根絶を個人の注意力ではなく仕組みで目指すことです。優秀な担当者が頑張り続けることを前提にした体制は、その人の急な休み、退職、担当変更によって止まります。また、手順を知っている人が注意して作業すればよいという運用では、繁忙時や引き継ぎ時に同じミスが再発します。そのため、個人の頭の中にある判断材料や作業手順を、他のメンバーが確認・再現できる形へ移すことを技術リードの責務と考えました。 対象となる5名チームでは、AWS／Kubernetes基盤の構築・運用、企業HP、日報Bot、AI利用ルールなど、性質の異なる業務を並行していました。私自身も実装を担っていたため、すべてを抱え込むと、私が新たな単一障害点になる問題がありました。一方で、単純に作業を割り振るだけでは、背景や判断基準が伝わらず、成果物の品質が担当者ごとにばらつきます。そこで、仕事を「誰が作業するか」だけでなく、「誰が要件を決めるか」「誰が実装するか」「誰が受け入れを判断するか」「誰がレビューするか」まで分け、責任分界を言語化しました。自分が実装する領域と、他メンバーへ委任して品質と合意形成を担う領域も意識的に分けています。 技術基盤では、繰り返し可能な作業をTerraformやGitOpsでコード化し、変更をレビュー可能にしました。共有Argo CD管理基盤と、Ethereum・Zamaのノード基盤は、共通するEKS、Secrets、監視の考え方をそろえつつ、各基盤固有の更新方法や障害切り分けは分離しました。すべてを一つの標準へ押し込むと、個別要件が見えなくなり、かえって事故につながるためです。共通化できる部分と個別に判断すべき部分を分け、監視、通知経路、アップグレード、障害切り分けをRunbookとして残すことで、担当者以外も変更の意図と確認方法を追えるようにしました。 ミスを減らす際には、チェックリストを増やすだけでなく、可能な部分を自動化し、人が判断すべき箇所を明確にしました。企業HPはWordPressを移行元とする構成から、Astro／TypeScript中心の静的サイトとMarkdown／Git管理へ移し、コンテンツ変更を実装、テスト、レビューと同じ流れで確認できるようにしました。 日報業務では、裁量労働下で必要な記録を手入力すると記入漏れが発生し、Jiraとの二重入力にもなっていたため、GitHub、Slack、一部Notionの履歴から下書きを作る日報Botを設計・実装しました。ただし、AIの出力を正しいものとして確定せず、各自が加筆修正してデイリーミーティングで利用する流れにしています。自動化によって入力負担を減らしつつ、最終判断は人が持つ設計です。長時間処理についても、途中保存、自動再開、外部監視を組み込み、失敗を担当者が常時見張る運用にしないよう工夫しました。 委任する業務では、口頭説明だけで終わらせず、目的、背景、成果物、レビュー観点を共有しました。AI利用ルールの整備では、情報資産、リスク、ポリシーを整理する必要性を私から提案し、規定作成などの実作業は別担当へ委任しました。私は成果物レビュー、関係者との議論、合意形成、利用管理の確認を担当しました。これは単に作業を手放すのではなく、担当者が主体的に進められる範囲と、私が品質責任を持つ範囲を分けるためです。 また、Codex／Claude Codeなどの生成AIを要件整理、実装支援、テスト、レビューへ利用していますが、AIの出力に依存することも別の単一障害点やミスの原因になります。そのため、仕様、計画、テストを記録し、要件との照合、テスト結果、人によるレビューを工程に含めています。ドキュメントも作ること自体を目的にせず、コード、テスト、Runbookなど、実際の変更や運用時に参照される場所へ残すことを意識しました。 こうした取り組みにより、基盤では構成と運用手順、企業HPではコンテンツ変更とテスト・レビュー、日報Botでは人の加筆修正を含む業務フロー、AI利用ルールでは委任とレビューの責任分界という形で、チームが確認・改善できる対象へ落とし込んでいます。 単一障害点やミスを完全になくしたと断定するのではなく、属人化や失敗が見つかるたびに、個人の注意喚起で終わらせず、再発を防ぐ仕組みへ変えることを継続しています。これが、私がマネジメントで一貫して重視している考え方です。