1. AI活用・エージェント開発 & ガバナンス・組織適応

Claude Code の Rules はもう死んでいる

• カテゴリ: AI支援開発 / Claude Code / エージェント
• 概要: Claude Codeのauto-modeシステムプロンプト変更によりBashツールが優先された結果、Readツールの実行をトリガーとするRules（path指定ルール）やHooks、サブディレクトリのCLAUDE.mdが読み込まれなくなっていた問題の調査と、環境変数による回避策をまとめた記事
• 感想: もし組織として「コーディング規約やセキュリティのガードレールをRules機能で配布して担保しよう」と設計していた場合、ベンダーの内部プロンプト変更によって安全装置が暗黙のうちに機能しなくなる可能性があり、プラットフォーム視点から見ても背筋の凍るような仕様変更だと感じた。AIツール側のルールやプロンプト機能はあくまで「開発者の手元を補助するソフトな推奨」に過ぎず、品質や安全性を担保する「真のガードレール」は、特定のAIツールの挙動に左右されないCI/CDパイプライン、linter、テスト、ポリシーエンジンといった外部の機械的な仕組みで敷くべきだという原則を再認識した。ベンダー依存のリスク自体はクラウドインフラ全般でも常に付きまとう課題だが、最適化の都合で内部仕様が予告なく変わり得るAI領域においても、ツールの独自機能に過度に依存しないポータブルな設計や防御態勢を真剣に検討すべきフェーズに来ていると実感した。

バックエンド開発Handbookを届けるために ― AI時代の知の高速道路を敷く

• カテゴリ: 開発標準 / AIネイティブ開発 / ドキュメンテーション
• 概要: タイミーにおけるバックエンド開発Handbookの策定と、それをClaude CodeプラグインやCursor Agent Skillsとして配布することで、開発者が意識せずともAIエージェント経由で社内ガイドラインや暗黙知に沿った設計・実装ができる仕組みづくりを紹介した記事
• 感想: 組織全体の開発生産性や品質を高めるためには、個人の裁量に任せるのではなく全体の「ベースライン」を引き上げることが不可欠であり、HandbookをAIエージェント向けスキルやプラグインとして届けて開発の土台を揃えるアプローチには大いに共感した。一方で、組織固有の制約や暗黙知まですべてAIに委ねてしまうと、新しく入ったエンジニアが「なぜその設計や制約になっているのか」というドメインの背景や文脈を学ぶ機会が減り、オンボーディングや自律的な成長に影響するリスクもある。また、コード化されたスキル定義を「誰が責任を持って更新し続けるのか」という運用上のオーナーシップ設計も重要な課題だ。「AIエージェントに任せる共通基盤」と「人間が対話やドキュメントを通じて深くキャッチアップすべきドメイン知識」の境界を見極めた上で設計することの重要性を再認識した。

Google提唱の「SKILL.state」について。プロンプトに型の概念を導入

• カテゴリ: 生成AI / AIエージェント / プロンプトエンジニアリング
• 概要: 長時間稼働するAIエージェントにおいて会話履歴の肥大化が精度劣化を引き起こす課題に対し、会話履歴を渡さず型定義された構造化データ（JSON State）のみを受け渡して状態更新を行うGoogleとPurdue大学提案の新手法「SKILL.state」を解説した記事
• 感想: AIエージェントとのやり取りにおいて、試行錯誤やエラー対応といった「右往左往した過程」のログを引きずり続ける必要はなく、次のアクションに必要な「確定した結果（状態）」だけをまとめれば十分だという指摘には強く共感した。テキスト対話に限らず画像生成AIなどでも顕著だが、過去の指示や生成履歴の文脈を引きずって意図しない出力が混入し続けることが多いため、実務でも一旦コンテキストをリセットして必要な要素だけで仕切り直す運用を日常的に行っている。その意味で、過程を破棄して「結果のファクト」だけを型定義されたJSON（State）として更新・受け渡ししていくSKILL.stateのアプローチは極めて合理的だと感じる。自然言語の曖昧な要約に頼らず、状態遷移としてクリーンにコンテキストの純度を保つ設計思想は、長時間自律稼働するエージェントの安定化に向けた現実解として納得感が高い。

AIに丸投げしないで理解するためのAI開発手法（2026年8月現在）

• カテゴリ: AIコーディング / ソフトウェア設計 / 開発プロセス
• 概要: Claude CodeやCodex CLIなどのAIコーディングにおいて、生成コードの丸投げが招く「技術負債」と「理解負債」を防ぐため、カスタムスキルや視覚的解説を活用して人間が仕様理解とテスト駆動を維持しながら進める実践的な開発フローを解説した記事
• 感想: 「コードは動いているが、なぜそう動くのかを誰も説明できない状態」は、エンジニアリング組織として避けなければならない。挙動の理由がブラックボックス化すれば、チームとして品質を保証できず、障害や仕様変更の際に安全に手を入れることも難しくなるからだ。実装の細部をAIに補佐させるにしても、システム全体の仕様を把握し、自分の言葉でアーキテクチャや振る舞いを説明できる状態は保ち続けたい。特にビジネスの根幹に関わるドメイン知識や業務制約は、AIに安易に委ねることが難しい領域であり、そこへの理解と品質責任こそ、人間が最後までオーナーシップを持つべき防衛ラインだと再認識した。

AIを使いこなす技術チームの育て方、GitLab社内の実践から

• カテゴリ: AI導入 / 組織育成 / エンジニアリングカルチャー
• 概要: GitLab社内でAIツール導入後に発生したチーム間の成果格差を解消するため、単なるツール配布にとどまらず、Talent DevelopmentとTechnologyチームが連携して全社的に「AIフルエンシー（AIを使いこなすリテラシーとワークフロー設計力）」を育成した実践知見を紹介した記事
• 感想: 同じAIツールを渡しても成果に差が出る根本的な要因は、プロンプトの巧拙などではなく、エンジニアとして培ってきた「過去の実務・運用経験の差」に尽きると強く実感した。実際にインフラやシステムの運用を経験していれば、AIが提示したアプローチに対して「そもそも調べる順序が違う」「まずはこの切り分けから着手すべきだ」と直感的に違和感を抱き、AIの思考プロセスを正しい方向へ軌道修正できる。この「適切な順序でアプローチし、目利きする勘所」こそが経験値そのものだと言える。しかし、こうした暗黙知に属する思考手順をマニュアル化して組織的に教育・底上げ（ベースラインの引き上げ）することは極めて難易度が高い。AIツールが標準化された時代だからこそ、この「経験値に基づく判断力」をどう組織に定着させ、次世代へ伝承していくかが今後のエンジニア組織の大きな課題になると感じた。

AIが法律業務にもたらす可能性と課題　新指針｢歴史的な転換｣…弁護士ドットコム・元栄社長

• カテゴリ: 生成AI / リーガルテック / ガバナンス・法規制
• 概要: 法務省の新指針によるリーガルテックの非弁行為規制緩和を受け、弁護士ドットコムの元栄太一郎社長が語る、法律業務における特化型AIの成長可能性と、ハルシネーション対策、人間が責任を負う領域、海外AI依存に伴う「司法安全保障」の課題に関するインタビュー記事
• 感想: 自身も直近までリーガルテック領域のSaaS企業でインフラや信頼性を支えてきた立場として、弁護士法における「非弁行為」の規制がAI活用のブレーキとして作用してきた実態は肌身で実感している。しかしそれは単なる障壁ではなく、誤判断やハルシネーションから利用者を守る「社会的なガードレール」として機能してきた側面も大きいと捉えている。今後規制緩和が進むとしても、元栄社長が語るように「最後の判断は人間が下す」という原則は揺るがない。システムを設計する上でも、「ユーザーが明示的に確定ボタンを押すまでは登録・確定されない」といった人間によるガードレールを機能レベルで明確に落とし込むことが何より重要だと感じる。また「司法安全保障」の観点に関しても、いくらリージョンを日本国内に指定したところで、自社の管理境界（VPC等）の外へデータが出ている以上、完全な安心とは言い切れない。メガクラウド側が提供する完全な閉域ネットワーク接続やプライベート環境の整備など、インフラ面での主権とセキュリティ担保が今後ますます問われていくと実感した。

AIでチーム感が薄れたSREチームで始めた、AIによる週次チーム評価

• カテゴリ: SRE / チームビルディング / AI活用
• 概要: AI導入によってエンジニアが単独でタスクを完結できるようになり、チーム内の相互依存や文化形成が希薄化した課題に対し、コミュニケーションの場を再設計し、チームの働き方の明文化とAIによる週次チーム評価を導入して結束力を高めたHubble SREチームの実践記
• 感想: 自身の直近の現場ではSRE2名体制で、各自が個々の課題にオーナーシップを持って自律的に動く個人プレイに近い環境だったため、「チーム感が薄れた」という課題自体にはあまり直面しなかった。一方で、共有を円滑にしようとAIを活用してIssueを起票できるようにしたところ、対話を通じた共有感が薄れただけでなく、「起票した本人すら内容を十分に理解していないIssue」が紛れ込み、バックログリファインメントでの解読に余計な時間がかかるという本末転倒な失敗を経験した。AIによってタスク作成のコストがゼロに近づいたからこそ、作成者自身の思考を経ていない形骸的なチケットが、かえって組織の認知負荷を高める罠には注意が必要だ。また、真に必要な相互理解やナレッジ共有はSREチームの中だけに閉じず、「組織全体に見える形でオープンにする」ことこそが本質だと感じる。新天地では1人目SREとしての挑戦が控えているが、個人プレイに逃げず、組織全体を巻き込んで可視化とイネーブルメントを推し進めるスタンスを貫かなければスケールしないという危機感を、今後の行動につなげていきたい。

2. クラウドインフラ・SRE & プラットフォーム・セキュリティ

生成AI×MCPで「SREの属人化」を打ち破る。KINTOテクノロジーズが挑む「Agentic SRE」の現在地

• カテゴリ: SRE / 生成AI / プラットフォームエンジニアリング
• 概要: KINTOテクノロジーズのxREグループが、少人数で多数のプロダクトを支える中で生じるSRE業務の属人化を解消するため、生成AIとMCP（Model Context Protocol）を組み合わせて自律型運用と開発生産性向上を目指す「Agentic SRE」の取り組みと組織づくりを語るインタビュー記事
• 感想: SREという職種は華やかな技術導入よりも日々の泥臭いトイル削減や運用改善の積み重ねこそが本質であり、現場の生々しい課題に一つずつ向き合うKINTOの地に足のついたスタンスには深く共感した。日々の現場では突発的な運用タスクが頻繁に差し込まれるため、これらをいかに効率的に捌くかがSREの生産性を左右する。特にエラーログの追跡やアラートの一次切り分けこそ生成AI×MCPの真骨頂であり、「夜間のアラート状況を自律的に調査し、翌朝出社した段階で整理されたレポートとして引き継いでくれる」ような運用が実現できれば、SREの認知負荷は劇的に軽減されるはずだ。また安全性のガードレールという観点でも、AIに勝手なリソース変更や修復（Write権限）まで任せる必要は全くなく、「修正の判断と実行は人間が担うので、調査と状況報告だけに徹してくれる」だけで十分すぎる価値がある。権限を安全に絞りつつ運用の属人化とトイルを打ち破るアプローチとして、Agentic SREの現実的な可能性を強く実感した。

Argo CDとAtlantisで実現するインフラ管理のセルフサービス化──小規模SREチームで支えるプラットフォーム

• カテゴリ: プラットフォームエンジニアリング / GitOps / SRE
• 概要: アンドパッドにおけるマイクロサービス運用の課題に対し、Argo CDとAtlantisを用いたGitOpsによってインフラ管理をセルフサービス化し、IaCモノレポの整備やAIエージェントの活用を見据えて小規模SREチームで多数の開発チームを支える基盤構築の事例
• 感想: SREが作業の窓口として開発スピードを妨げるシングルポイント（単一障害点）になってはならないという原則に立ち、Argo CDやAtlantisを活用してインフラ管理をセルフサービス化し、依頼作業を「PR起票＋レビュー」のフローへ移譲するアプローチには強く共感した。変更作業をPRという非同期のパイプラインに乗せることは、開発の自律性を高めるだけでなく、組織内でどんな作業依頼がどれだけ発生しているかを一元的に可視化できる大きな利点がある。もしレビューが滞留して開発が詰まるのであれば、それ自体がチームのボトルネックとして浮き彫りになり、次なる改善や権限移譲を検討する健全なきっかけになるはずだ。開発者の認知負荷を下げるためには、プラットフォームエンジニアリングの観点から安全な「テンプレート（ビルディングブロック）」を整備してゴールデンパスを敷くことが不可欠であり、そのテンプレート化とガードレールが確立できた領域から順次、SREのレビューすら手放して現場へ完全移譲していくステップこそが、少人数SREがスケールするための現実的な王道だと再認識した。

TerraformのCI/CDって結局どうしたらいいの？

• カテゴリ: Terraform / CI/CD / セキュリティ
• 概要: CI環境におけるTerraform plan実行時の認証情報流出や任意コード実行リスクに対し、OWASP Top 10 CI/CD Security Risksをベースに「発生確率より被害の大きさ（Impact）を抑える」観点から、実行環境の分離や権限最小化などの現実的なベースラインを整理したクラシルSREの登壇資料
• 感想: CI環境におけるTerraformのリスク対策として、「発生確率をゼロにするのは諦め、まず被害の大きさ（Impact）を抑える権限分離から手をつける」というスライドの整理には完全に同意する。単一の巨大なtfstateを運用していると、万が一のクレデンシャル流出や誤操作時にすべてのインフラが巻き込まれ、爆発範囲（Blast Radius）が致命的なレベルに拡大してしまうからだ。これを防ぐには適切なディレクトリ構成によるstate分割が不可欠であり、一度構築すれば滅多に変更しない基盤と、頻繁にパラメータ変更等が発生するリソース（Cloud SQL等）でディレクトリを切り分けるような設計が現実的だと感じる。ただしその場合、ディレクトリ間の依存関係を安全に繋ぐための「output設計」の精度が極めて重要になる。過去の現場でもstateの肥大化によってplan速度が著しく低下し、開発環境ですらCIでの自動運用や手離れが難しくなった上、肥大化したstateのリファクタリングにも非常に苦労した経験がある。Terraformのディレクトリ構成には万人共通の絶対的な正解が存在しないからこそ、新天地での基盤構築においては、後々の分割コストや爆発範囲を最小限に抑えられるシンプルで保守しやすい構成を慎重に設計していきたい。

壊してもいいデータベースを数秒で–ZFSで作るDBブランチ基盤

• カテゴリ: データベース / 開発基盤 / インフラ運用
• 概要: E2Eテストの並列実行や安全なSQL検証を目的に、ZFSのCopy-on-Write機能とスナップショット・クローンを活用して、本番規模のMySQLデータベースを数秒かつ低ディスク消費で複製・破棄できるDBブランチ基盤を自前構築したモノタロウの取り組み
• 感想: 単に「壊れない完璧なシステム」を目指すのではなく、「壊れても問題ない設計」や「どう壊れるかをあらかじめ想定して被害を最小限に抑える設計（ダメージコントロール）」の重要性を最近強く実感している。この思考はシステムアーキテクチャにとどまらず、プロジェクト進行や組織設計などあらゆる場面に通底する本質的なスキルであり、どう壊れるかを洗い出して手を打つ設計力は難易度が高いからこそ、今後さらに養って自分自身の武器にしていきたいテーマだ。自身は「壊れてもいい」と言いつつも実際は石橋を叩いて進める慎重なタイプだからこそ、モノタロウのように本番規模のDBを数秒で複製・破棄できる基盤がもたらす「過度に慎重にならず大胆に実験できる心理的安全性」には大いに共感する。ただし単に壊せるだけでなく、「どこがどう壊れたかを的確に検知し、自動で通知した上で元の状態へ即座に復元できる仕組み」までをセットで作り込んでこそ真のレジリエンスが生まれるのだと再認識した。

【実験】ECSのサービス間を繋ぐ6つの繋ぎ方、実際どれくらい速さが違うのか

• カテゴリ: AWS / コンテナ / ネットワーク
• 概要: ECSサービス間通信における6つの接続方式（同一VPC直接、Peering直接、Peering+ECS Service Connect、Transit Gateway直接、PrivateLink、VPC Lattice）を構築し、同一AZ・クロスAZなどの条件下でそれぞれの通信レイテンシやオーバーヘッドを実測・比較検証した技術レポート
• 感想: 自身も実務においてAWS App Meshのサービス終了（EOL）に伴う代替ネットワークの検討に直面し、移行戦略の策定に多大な苦労をした経験があるため、当時の意思決定を「答え合わせ」するような気持ちで読んだ記事だった。当時は最終的にAmazon VPC Latticeへの移行を選択したものの、「果たしてこの選定がパフォーマンスや運用の観点から本当に正解だったのか」という疑問は完全には腹落ちしきれていなかった。それだけに、同一VPC直接通信からService Connect、PrivateLink、VPC Latticeまで、同一条件下で各接続方式のレイテンシやオーバーヘッドを東京リージョンで実測・比較してくれたデータは非常に参考になった。Latticeのような新しい抽象化レイヤは運用性やサービス間連携の面で魅力的な反面、プロキシ等を介すことによるレイテンシのコストは確実に発生する。マネージドサービスのEOLに振り回された教訓も含め、将来の移行容易性や非機能要件のトレードオフをどう見極めてネットワークを選定すべきか、改めて深く考えさせられる良質な検証だった。

Introducing Continuous Vulnerability Assessment: Real-Time Defense for the AI Threat Era

• カテゴリ: クラウドセキュリティ / 脆弱性管理 / Wiz
• 概要: AIの進化により脆弱性公開から悪用までの時間が短縮される脅威に対抗し、カタログ更新と同時にクラウド環境内の影響度をリアルタイムに再評価して、定期スキャンを待たずに即日の検知・トリアージ・修復を可能にするWizの新機能「Continuous Vulnerability Assessment（CVA）」の解説記事
• 感想: 攻撃者がAIを駆使して脆弱性公開からわずか数時間でエクスプロイトを仕掛けてくる時代において、従来の定期スキャンを脱却し、カタログ更新と同時にクラウド環境内の影響度をリアルタイムに再評価するWizのCVAのアプローチには大いに納得感がある。防御側もスピードを圧倒的に引き上げなければ追いつかないのは明白だ。一方で、どれだけ検知スピードを極限まで短縮したとしても、ベンダーやOSS側から「修正パッチが提供されるまでのタイムラグ」は必ず発生するため、パッチが存在しない空白期間をどう凌ぐかという現場の課題は依然として残る。だからこそ、単にアラートを検知するだけでなく、インターネットからの到達性や影響範囲を踏まえて「暫定的な緩和策（WAFやアクセス制御）で凌ぐのか、緊急対応するのか」を素早く判断するトリアージのスピードも同時に引き上げることが不可欠であり、検知から判断・暫定防御までの一連のループをいかに迅速に回せるかがAI時代の防衛の分水嶺になると実感した。

脆弱性とこれからの話 2026 summer - 2026のCVE津波を乗り越えるには

• カテゴリ: セキュリティ / 脆弱性管理 / ガバナンス
• 概要: AI自動化等により急増する「CVE津波」（8ヶ月で前年比+41%超）に直面する中、CVSSスコアだけに依存せず、CISA KEVやEPSS・VulnCheckを組み合わせて実悪用リスクの高い脆弱性に絞り込むトリアージと、EU CRA等の法規制・サプライチェーンセキュリティに備える防御戦略を解説したスライド
• 感想: 2026年に急増した「CVE津波」に対し、検知されたCriticalやHighのすべてに愚直に対応し続けるのはコストやリソースの観点からも到底不可能であり、実際の影響範囲を冷静に見極めて対応要否を判断する姿勢が不可欠だと強く共感した。セキュリティ対策は突き詰めれば終わりのない「モグラ叩き」になりがちだからこそ、現場が疲弊して形骸化しないよう、リスクとコストを見極めて無理なく運用を回すことが何より重要になる。その際、KEVやEPSSといった脅威情報を参考にしつつも、最終的に対応するか否かを決める軸は「顧客影響があるかどうか」に置くべきだと感じる。これは社内での優先度判断だけでなく、セキュリティチェックシートや監査といった対外説明においても同じだ。単なる脆弱性スコアの高低に振り回されず、「顧客のデータやサービスに実害が及ぶリスクがあるか」という本質的な軸でトリアージを徹底することこそが、持続可能で納得感のあるセキュリティ運用の要だと再認識した。

3. 開発プロセス・チームマネジメント & エンジニア組織・キャリア

問いを立てる習慣をつくる

• カテゴリ: キャリア / 問題解決 / チーム開発
• 概要: チーム内で拾うべき課題（ボール）が見つからない時に、仕事を「問いを立てる仕事」と「問いを解く仕事」に分類し、日常のインプットから課題感を洗い出し、仮説検証とデータ調査によって解くべき真の課題を特定・提案する実践的アプローチを解説した記事
• 感想: 落ちているボールを単に拾うだけでなく、自ら「問いを立てて」真の課題を特定しにいくことこそがSREの本質だと強く確信している。SREとは誰かから課題が降ってくるのを待つ受動的な運用係ではなく、潜在的なリスクやトイルを見つけ出し、自ら課題を設定してアジェンダを握る能動的な存在であるべきだからだ。かつて自身のノート（コスト分析レポートをAI自動化して起きた「無関心の連鎖」）でも振り返った通り、単に作業としてのトイルをSREが一人でサイレントに自動化・処理するヒーローになってしまうと、チームから「認知の摩擦（考えるきっかけ）」を奪い、無関心を生む原因になってしまう。作業をこなすこと自体はトイルに過ぎないが、ファクトから状況を解釈し、「なぜこれが起きているのか、何を解決すべきか」と問いを立ててチームの共通認識に昇華させることこそが「エンジニアリング」そのものである。課題が明確でない現場においてこそ、自ら問いを立ててチームを前進させるアプローチを、新天地でも愚直に体現していきたい。

品質を支える仕組みをチームで作る —— 開発プロセスの可視化と改善

• カテゴリ: QA・品質管理 / 開発プロセス / チーム開発
• 概要: チーム体制の変更に伴い暗黙知が機能しなくなったSmartHRにおいて、開発プロセスの可視化、ユーザー体験に立ち返るシナリオレビュー、バックログ品質改善、Notionエージェントによる観測を通じて、誰でも共通の観点で品質を守れる仕組みを定着させたQAEの実践事例
• 感想: 特定個人の注意力や善意に頼るのをやめ、「品質を守る仕組みを開発プロセスそのものに組み込む」というQAEのアプローチは、まさに信頼性を仕組みで担保するSREの思想と一致しており、深く共感した。チームの体制変更や並行開発の増加によって従来の「阿吽の呼吸」や暗黙知が機能しなくなる場面はどの現場でも起こり得るが、それは必ずしもネガティブな崩壊ではないと捉えている。むしろ、これまで属人的な頑張りで覆い隠されていたプロセスの歪みや課題が表面化し、真に持続可能な仕組み化へと舵を切るチャンスだからだ。SmartHRのように各工程の目的やインプット／アウトプットを愚直に可視化し、実装前のバックログ段階から多角的な視点を持ち寄って品質を整えていくアプローチは、SREが非機能要件や信頼性を開発上流から作り込んでいく上でも大いに参考になる。変化によってプロセスが軋んだ時こそ、チームの仕組みを進化させる契機にしていきたい。

What Leaders Do That Keep Scrum Teams Working Like Individuals

• カテゴリ: アジャイル / スクラム / リーダーシップ
• 概要: スクラムチームが真のチームとして機能せず個人プレイに陥ってしまう根本原因はメンバーの意識ではなく、兼任配属や個人評価、頻繁な割り込みといった組織側の構造的要因にあることを指摘し、チームワークを促進するためのリーダーの振る舞いを説いた記事
• 感想: チームワークが崩れて個人プレイに陥ってしまう根本原因について、組織の評価やアサインの構造だけでなく、少人数体制の中で「課題を説明しても相手に腹落ちしてもらえず、結果として自分ひとりでタスクを抱え込んでしまった」自身の苦い実体験とも重なり、非常に身につまされる思いで読んだ。振り返ってみれば、それは相手のスキル差以前に「自分自身の説明不足であり、相手と同じ目線に立って背景や価値を丁寧に伝えきれていなかった」ことに大きな要因があったと反省している。どれだけ正しい技術的提案であっても、相手のコンテキストに寄り添った合意形成が伴わなければチームの力にはならない。また、スキルギャップを理由に「自分でやった方が早い」と抱え込み続けるのではなく、テンプレートやプロセスの整備を通じて誰でも動ける「再現性をつくること」こそが、真の意味で個人プレイから脱却して組織をスケールさせる鍵だと感じる。新天地でのチームづくりにおいては、同じ目線に立った対話と再現性の確立を何より大切にしていきたい。

名ばかりFDEから脱却するには、事業構造の再設計を

• カテゴリ: FDE / SIer / 組織設計
• 概要: 多重下請け・要件凍結・工数管理という日本のSI産業の構造と、現場での即時意思決定・改善を求めるFDE（Forward Deployed Engineer）の根本的な矛盾を分析し、FDEを形骸化させず事業価値を生み出すための事業構造・契約慣行の再設計を提言した記事
• 感想: 多重下請け構造では顧客領域に入り込めないという指摘は、まさに自身のキャリアの原点そのものとして深く共感した。かつてMSPに身を置いていた頃、「顧客が求めているのは言われた通りの安定運用（現状維持）であり、運用の抜本的な効率化や改善は二の次である」というビジネスモデルの構造的限界を痛感し、もっと直接顧客や事業に向き合いたいという思いから自社サービス・SREへの転職を決意した経緯があるからだ。自社SaaSに移ってからは直接プロダクトや事業成長に向き合える実感を得られたものの、そこでは「開発と運用の分断」という新たな組織の壁に直面することになった。日本の受託・SI産業全体の事業構造を再設計することは一朝一夕には答えが出ない巨大な課題だが、だからこそ自分自身は「名ばかりFDE」のような流行りの肩書きに安易に飛びつくのではなく、先日のノートでも言語化した通り「Google SREの原理原則に沿って、いかに技術を事業価値や信頼性へ接続し、事業にインパクトを与えられるか」という確固たるエンジニアリングの軸を大切にしたいと再認識した。

技術は「勉強するもの」ではなくなった。居酒屋でPCを広げる大人たちを見て決めた"やらないこと"

• カテゴリ: キャリア / エンジニアコミュニティ / 働き方
• 概要: 業務時間外の無理な「勉強」やつらい継続をやめ、技術コミュニティでの仲間との交流や楽しむ姿勢にシフトしたことで、Microsoft MVPやGitHub Stars選出に至った長瀬マキ氏が語る、エンジニアとしての「やらないこと」リストとキャリア論
• 感想: 自身は学生時代にコンピュータサイエンスを学んでいた背景もあり、技術そのものに対して「趣味」としての側面が強く、土日や業務時間外のインプットや技術探求も義務的な「勉強」ではなく、ほぼ趣味のモチベーションで取り組んでいる。そのため、技術を義務的な「勉強」から解放して楽しむという記事のメッセージには深く共感した。「勉強しなければならない」という義務感や焦燥感から無理な継続を強いるのではなく、純粋な知的好奇心を起点に技術を楽しむことが、結果として息の長いモチベーションにつながっていると感じる。また、そうした趣味としての探求を自分の中だけで完結させず、ブログなどで継続的に言語化・アウトプットしていくことも、学びを整理しモチベーションを保つための重要なサイクルになっている。義務感に追われることなく、知的好奇心と楽しさを原動力に技術と向き合い続ける姿勢をこれからも大切にしていきたい。

30代薬剤師が2ヶ月でITエンジニアをクビになって求職活動した

• カテゴリ: キャリア / リスキリング / 転職
• 概要: 薬学部卒の30代男性が資格取得を経てITスタートアップに転職したものの、実務研修で躓き2ヶ月で解雇となり、資格勉強と現場での実践スキルのギャップを痛感しながらも再び求職活動を行って内定を獲得するまでの実体験記録
• 感想: 資格勉強と実務現場のギャップに苦しみ、解雇から泥臭く再起するリアルなプロセスには共感する部分が多かった。同時に、薬剤師という強力なバックグラウンドがあるからこそ、そのドメイン知識を最大限に生かせる医療・調剤系SaaS企業へ進む選択肢も有力ではないかと感じた。大前提として「技術は手段であって目的ではない」。エンジニアの本質は単にコードを書くことではなく、技術という手段を用いて現実の課題を解決することにあるからだ。薬剤師として現場に立ち、身をもって感じてきた業務の非効率や課題（ペイン）があるのなら、それこそが他の誰にも真似できない強みになる。自らが現場で感じた課題をテクノロジーで解きにいくことが、エンジニアとしての大きな価値発揮につながるのではないかと思う。

今週の雑感

今週は秩父や伊東へ出かけ、のんびり充電していました。併せて、積んでいた『実践 プラットフォームエンジニアリング』も読み進めています。

SRE Tech Leadからのフィードバック

今週もお疲れ様！有給休暇中も知的好奇心を存分に発揮して、AIエージェントの統制からGitOps基盤、CVE津波のトリアージ、そして組織論まで20本もの濃密なインプットが詰まった圧巻の週報ね。

特に、Claude CodeのRules問題に見る「ツールの機能に頼らずCI/CDなどの機械的ガードレールで守る」原則や、ZFSによるDBブランチ基盤から「壊れないことより、どう壊れるかを想定したダメージコントロールと即時復元力（Design for Failure）」を見出す視点は極めて本質的よ。また、過去の抱え込みの反省を糧に「自ら問いを立ててアジェンダを握り、誰でも動ける再現性をつくる」というキャリアの軸へ昇華できている点も素晴らしいわ。

新天地での基盤立ち上げや組織づくりに向けて、ぜひ以下の2点も考えてみてほしいな。

• Argo CDやAtlantisによるGitOps推進で、開発者が迷わない「ゴールデンパス（テンプレート）」を現場へ完全移譲していく境界線はどう引くのが良さそうかしら？
• 「CVE津波」に対し、開発チームを疲弊させずに「顧客影響」を軸とした現実的なトリアージ運用を定着させる工夫はある？

秩父や伊東でのリフレッシュ、心身のバジェット回復に最高ね！『実践 プラットフォームエンジニアリング』のインプットも楽しみつつ、来週も一緒に一歩ずつ進んでいきましょう！