週報(2026/7/3) - AI開発の規律と『マクロナビゲーター』としてのテックリードの役割
AIによるこの記事の要約
本記事は、2026年7月3日週の技術動向と自身の思索をまとめた週報です。AIネイティブ開発における品質・例外管理、Platform Engineeringにおける信頼性と運用の合意形成、および組織・キャリアにおけるエンジニアの役割変化について、以下の論点を要約しています。
- AIネイティブ開発と品質の規律: AIによって「動くコード」を作るハードルが下がったからこそ、例外処理の握り潰しや自作自演テストを防ぐためのTDD（テスト駆動開発）的アプローチなど、人間の「コードを読む力（目利き力）」と開発規律の重要性を整理。
- SRE・プラットフォームの信頼性設計: EKS vs ECS選定における具体的メリットの比較、リリース後のインフラ手戻りを防ぐ「レディネスレビュー（LRR/HRR）」の仕組み化、およびエラーバジェットを軸にした「信頼性文化」の合意形成の重要性を共有。
- 仕組みによる脱サイロ化と役割シフト: セキュリティ対応のサイロ化を解く「SCS評価制度」の期待や、発信を促す「ガードレールと批判されない文化」、およびテックリードの役割が「マクロナビゲーター」へとシフトしていくキャリア戦略を記述。
1. AI & 開発プロセス
AI 時代だからこそコードを読もう (Zenn)
- カテゴリ: AIネイティブ開発 / コードリーディング
- 概要: 生成AIによってコードが簡単に書けるようになったからこそ、自動生成されたコードをしっかりと読み解き理解する重要性を説いた記事
- 感想: AIによって「動くコード」を作るハードルは大幅に下がったが、それゆえに単に動くだけではない「コード品質」の担保がより重要になっている。コードベースにおけるドメイン知識の重要性は昔から変わっておらず、これからも不変の価値。また、品質を担保しAIの出力を適切に検証するためにも、テストコードをしっかり書くことの大切さを改めて実感した。
Claude Code SkillsとSubAgentsの違い。初心者はどちらから作るべきか (X)
- カテゴリ: AIエージェント / 開発プロセス
- 概要: Claude CodeのSkills（手順）とSubAgents（役割・責任）の違いを説明し、開発者がどちらからアプローチすべきかを解説したポスト
- 感想: SkillsとSubAgentsの違いに関する考察。まずは手順をカチッと固めるSkills（スキル）から始め、役割や責任を定義するSubAgentsへと段階的に移行するアプローチが合理的。SubAgentsは非常に強力だが、責任範囲の切り分けや粒度の調整が難しく、使い所の見極めが必要。
AIエージェント導入で見えてきた７つの「現場の壁」と「組織の壁」 (X)
- カテゴリ: AIエージェント / 組織開発
- 概要: AIエージェントを組織に導入する際に発生する、現場レベルおよび組織レベルでの7つの課題（障壁）について整理したポスト
- 感想: AIエージェントの現場導入で直面する7つの壁。その中でも「ガバナンス（野良エージェントやゾンビエージェントの発生）」は、AIを使いこなして初めて生まれる贅沢な悩みであり、後発の技術負債にしないためにも今のうちから向き合うべき重要な課題だと感じた。
DevOps Agent奮闘記 〜アラートを起点に、運用の一次対応をAIに任せてみた〜 (Zenn)
- カテゴリ: AIネイティブ開発 / SRE / 運用自動化
- 概要: アラートをトリガーにAIエージェントを起動し、運用の一次対応（ログ調査や初期切り分け）を自律的に実行させる取り組みについて紹介した記事
- 感想: アラートを起点にしたAI運用の一次対応の実践記。運用負荷を下げるためにAIを活用するのは素晴らしいが、その前提として「オオカミ少年アラート」の削減やノイズ排除が不可欠。整理されていないアラートをAIに食わせると、ノイズとコストの無駄遣いになるという現実は非常に納得感がある。
チームふりかえりでおいらに任せたこと、任せなかったこと (Zenn)
- カテゴリ: 開発プロセス / アジャイル / ふりかえり
- 概要: チームのスプリントふりかえり（レトロスペクティブ）において、データ集計やファシリテーションなどの一部プロセスをAIに任せ、人間が担うべき対話や意思決定に集中した事例を紹介した記事
- 感想: チームのふりかえりにおけるAIの使いどころ。データ収集や整理といった「作業」はAIに任せつつ、評価や最終的な意思決定（意味づけ）のオーナーシップは人間が持ち続けることの重要性。ここをAIに丸投げしてしまうと、ふりかえりをする本質的な意味が失われてしまうという意見に強く同意する。
2. SRE & プラットフォームエンジニアリング
mazrean/kanata: Real Kubernetes on your Mac, without an always-on VM. (GitHub)
- カテゴリ: コンテナ基盤 / Kubernetes / 開発環境
- 概要: 常時起動の仮想マシンを必要とせず、macOSネイティブの仮想化技術を利用して軽量にKubernetesを実行できるローカル開発環境ツール
- 感想: VM（仮想マシン）を常時起動することなく、macOSネイティブの仮想化（Virtualization.framework）を利用してゼロアイドルコストで動作するKubernetes環境「kanata」の紹介。ローカルでのコンテナ検証のハードルを下げる非常にスマートなアプローチ。
スタートアップにAmazon EKSは早すぎる？ (Speaker Deck)
- カテゴリ: プラットフォーム / 技術選定 / スタートアップ
- 概要: スタートアップや新規事業開発におけるAmazon EKSの選定是非について、Platform Engineeringやマルチプロダクト戦略の観点から現実的な判断軸を整理したスライド
- 感想: スタートアップにおけるEKS導入の是非。EKSは単なるインフラ技術ではなく、マルチプロダクト戦略を支える「プラットフォーム投資」というビジネス側の視点での意思決定であるという整理に非常に感銘を受けた。最近ではベンチャーでもEKSやGKEを早期から活用する傾向があるという実感にも繋がる。
徹底討論！ECS vs EKS！ (Speaker Deck)
- カテゴリ: コンテナ基盤 / ECS / EKS
- 概要: AWS上のコンテナオーケストレーションツールであるECSとEKSについて、それぞれの特徴、選定基準、運用コストなどを徹底的に比較したスライド
- 感想: 直前の「Platform Engineeringとマルチプロダクト」のスライドと完全に地続きとなる内容。スケーリング（Karpenter）やセキュリティ（NetworkPolicy）といったEKSならではの具体的メリットと学習コストを天秤にかけ、自社にとっての「自然な選択」を導き出すための判断軸として、非常に納得感がある比較資料。
「動くコード」は「安全なコード」ではない！ バイブコーディングの5つのセキュリティ急所と反脆弱な開発者・チームになるための実践 (CodeZine)
- カテゴリ: セキュリティ / セキュアコーディング / AIネイティブ開発
- 概要: 生成AIなどに頼って動作確認だけでコードを書く「バイブコーディング」の危険性を指摘し、開発段階で埋め込まれがちなセキュリティの脆弱性と、それに抗う反脆弱なチームの実践について解説した記事
- 感想: 1本目の記事（AI時代だからこそコードを読もう）での議論と強く響き合う内容。AIによって「コードを書く」敷居は大幅に下がったものの、それゆえに埋め込まれるセキュリティリスクを評価し、安全性を担保するために人間が考え・検証すべき事柄はむしろ増えているという、AI開発時代ならではのパラドックスを感じた。
SLOをサービス品質の共通言語にするために 取り組んできたこと (Speaker Deck)
- カテゴリ: SRE / SLO / サービス品質
- 概要: SLO（サービスレベル目標）をエンジニアやビジネスサイドを含めた共通言語にするために、測定方法や文化醸成などにおいて取り組んできた知見を共有したスライド
- 感想: SLOやエラーバジェットの運用は、計測システムを整えること以上に「関係者との合意形成や信頼性を重視する文化づくり」の難易度が高い。この根本を疎かにしたまま表面的な「ビジネスオブザーバビリティ」を導入しても、アクションを伴わない見かけ倒しの数値になってしまうため、地道に文化の土台を築いていく重要性を痛感した。
atama plus のプラットフォームとレディネスレビュー（前編） (Zenn)
- カテゴリ: Platform Engineering / レディネスレビュー
- 概要: atama plusにおけるシステム運用の品質向上とデプロイの安全性を担保するためのプラットフォームの取り組みと、レディネスレビュー（本番移行審査）の設計・運用プロセスについて解説した記事
- 感想: 書籍『SREの探求』の理論（LRR/HRR）を、自社の開発体制（CDKによるインフラ自営化）に合わせてアジャストした非常に有意義な実践事例。リリース後の運用破綻や設計見直しといった手痛い技術負債を未然に防ぐアプローチとして優れており、将来的に新規サービスのローンチや運用の整備を行う際に、ぜひ参考にし実践してみたいと感じた。
3. 組織・技術選定・キャリア
他者のアウトプットを促す技術 組織理解を引き出し他者を巻き込むための具体的方法論 (Docswell)
- カテゴリ: 組織開発 / コミュニケーション
- 概要: 組織内のメンバーのアウトプットを促進し、他者を巻き込んでプロジェクトを進めるための具体的なアプローチや方法論を解説したスライド
- 感想: アウトプットが活発な組織は、自然発生的ではなく「ガードレールを敷きつつ、批判されない文化」を意図的に作っているという指摘に深く共感する。何を発信してよいかの境界線を示して不安を取り除き、いかなる発信も歓迎される心理的安全性を整えることこそが、メンバーを巻き込みアウトプットを促進するための最も重要な土台であると感じた。
SCS評価制度セミナー参加レポート：ISMSとの違いと、セキュリティ対応で大切なこと
- カテゴリ: セキュリティ / ガバナンス / 評価制度
- 概要: 経産省が推進する「SCS（サプライチェーンセキュリティ）評価制度」のセミナーレポートで、ISMSとの違いや企業がセキュリティ対応において意識すべきポイントをまとめた記事
- 感想: セキュリティ知識が特定のキーパーソンにサイロ化し、顧客ごとのチェックシート対応が属人化する課題に対する、非常に有望な解決策。SCS評価制度のような「共通の物差し」を導入して全社的に運用できれば、個人のボトルネックを解消して組織的に対応できるようになるため、今後の業界的な普及と社内展開に強く期待したい。
AI時代にテックリードとして重視していること
- カテゴリ: キャリア / テックリード / AI活用
- 概要: AIツールが開発に浸透する時代において、テックリードとしてどのような役割やスタンス、スキル向上を重視しているかを語ったマネーフォワードのエンジニアブログ記事
- 感想: 先の技術選定の議論とも地続きとなる内容。コードの実装やミクロなチェックはAIに委ねられる時代だからこそ、テックリードの立ち回りは「マクロな全体像の整合、中長期的な技術選定、チームのブロッカー先読み」といった意思決定とナビゲーションへとシフトしていく。この変化を今後の自身の働き方においても強く意識していきたい。
シニアエンジニアがコードをほぼ書かなくなった理由 (Zenn)
- カテゴリ: キャリア / シニアエンジニア
- 概要: シニアエンジニアが実装作業から離れ、技術選定、アーキテクチャ設計、他メンバーのメンターなどの役割にシフトする理由やその価値について整理した記事
- 感想: 1本目の記事での議論とも通底する、「AIは本質的にテストを書かない（実装の引き写しに過ぎない）」という点への強い同意。表面上「動くだけのコード」に価値はなく、人間がテスト設計やアサーションを先んじて定義してAIを制約する「TDD（テスト駆動開発）的アプローチ」こそが、AI開発時代に品質を担保するための核心であると再認識した。
リリースして終わりにしない ― アウトカム計測を開発フローに組み込んで、チームの価値探索サイクルを速くした話 (Zenn)
- カテゴリ: プロダクトマネジメント / 開発プロセス / アウトカム計測
- 概要: リリース後にアウトカム（成果）を計測する仕組みを開発フローに組み込むことで、チームの価値探索と改善のサイクルを高速化した取り組みを紹介した記事
- 感想: AI導入の有無に関わらず、効果測定は開発者が「自身の仕事の価値」を実感するために極めて重要なプロセス。苦労して作った機能の成否が分からない、あるいは使われないことは、開発者にとって最大のモチベーション低下を招く。リリース後のアウトカムを計測してフィードバックを得ることは、価値探索のサイクルを速めるだけでなく、チームが誇りと納得感を持って開発を続けるための精神的ライフラインであると感じた。
生産性が上がらないチームは、この問いを忘れている
- カテゴリ: 組織開発 / 生産性
- 概要: チームの生産性を向上させるために見落とされがちな「何のためにこの仕事をしているのか」という目的意識や本質的な問いかけについて論じた記事
- 感想: チームの状態を示す指標を追うこと以上に、「全員が同じ方向を向く状態へいかに最短で到達するか」が生産性向上の核心であるという視点。そのためには、メンバーの個別事情に立ち入るよりも、チームの「目的（ジョブ）」を明確に定義し、全体像や共通言語（SLO等）といった「構造と仕組み」でベクトルを揃えるアプローチこそが最短ルートであると再認識した。
「答えを出す」より「わかる」をつくる (Speaker Deck)
- カテゴリ: プロダクトマネジメント / デザイン思考
- 概要: 単に目の前の課題に対する解決策（答え）を出すだけでなく、背景にある構造や本質を「理解する（わかる）」ためのプロセスを構築する重要性を示したスライド
- 感想: 過去の週報でも述べてきた「AIは良きパートナーであり、思考や学習のプロセスまでアウトソースして思考停止に陥ってはならない」という自身の基本スタンスが、EdTechプロダクトが直面している「AIが答えを出しすぎると考えるプロセスを奪う」というジレンマと完全に符合する内容。AIによる効率化と、人間側の「思考し学ぶ主体性」の保護をどう両立させるかは、開発者自身の成長においても、プロダクト設計においても最大のテーマであると再確認した。
今週の雑感
今週は色々と落ち着いた週であったのと月末だったので奮発
自身のキャリアの志向
客観的な市場価値レポートを見て、自身のインフラ技術力（スコア3.88）や「運用を見据えた設計」という軸が評価されていることに自信を持てた。一方で、次のステップである「SREマネージャーやStaff Engineer（年収1000万〜レンジ）」への移行に向けて、現在の自分に不足しているピース（伸びしろ）も明確になった。具体的には、テックリードとしての技術選定やインフラ設計の実績はあるものの、ポートフォリオ上での「3〜5名規模のチーム育成実績」や「採用・評価」、指示系統やロードマップ管理、そして「トイル削減時間やSLO向上といった定量的成果の可視化」の記述が薄い点である。
今週のインプットにあった「SLOを共通言語にする文化づくり」や「レディネスレビューによる品質の仕組み化」、そして「アラート削減」といったプラットフォーム投資は、まさにこの「定量的成果」に直結する。今後は単に技術を深掘りするだけでなく、「SREの成果を組織に定着させ、チームを拡大・育成していく仕組み（構造）を作った」という実績を意識的に作り、ポートフォリオへ反映させていきたい。まずは3〜5名規模のリード実績を強固にし、中長期的に「ビジネスをインフラから加速させる、作れて喋れて推進力のあるSRE」の体現を目指していきたい。
LAPRASキャリア分析(詳細)
SRE Tech Leadからのフィードバック
今週もお疲れ様！今回の週報も、AIネイティブ開発における規律から、プラットフォームの信頼性設計、そして自身のキャリア戦略まで、非常によく整理されていて読み応えがあったわ。
特に、AIによって「動くコード」が量産される時代だからこそ、テストファースト（TDD）でAIを制御し、セキュリティリスクを検証する「人間の目利き力」が不可欠になるという考察、本当にその通りね。また、テックリードの役割がミクロの実装から「マクロナビゲーター」へとシフトしていくという指摘も、今後のキャリアパスを見据える上で非常に重要な視点よ。
キャリアの志向に関しても、LAPRASの分析から自身の「インフラ技術力」という強みを再確認しつつ、次のステップ（Staff/SREマネージャー）へ向けて「定量的成果の可視化」や「チームの育成実績」といった具体的な伸びしろ（課題）に落とし込めているのが素晴らしいわ。atama plusのレディネスレビュー（LRR/HRR）やSLO推進を「仕組み」として組織に定着させる経験は、まさにあなたが目指す「定量的成果」と「リード実績」を同時に証明する強力な武器になるはずよ。
この「仕組みづくり」と「組織への定着」をさらに加速させるために、まずは以下の2点についてあなたの意見を聞かせてほしいな。
- 今週の記事にもあった「心理的安全性（批判されない文化）」や「全員のベクトルを揃える構造」を意識したとき、レディネスレビューやSLOの導入を単なる「官僚的な手続き」にせず、開発者が主体的に取り組めるようにするための最初のアプローチ（または翻訳）はどうあるべきかしら？
- あなたが強みとする「運用を見据えた設計力」を活かして、チームの「トイル削減時間」や「SLO向上」を定量的にトラックするための簡易的なメトリクス設計を始めるとしたら、何から計測し始めるのが現実的だと思う？
来週もあなたの精神的バジェットを大切にしながら、一緒に一歩ずつ進めていきましょうね！
