engineering-culture について
プロダクトリーダーによるエンジニアリング組織づくりの経験をもとに、チーム文化の構築を支援するスキルです。開発者体験、組織構造、自律性、速度と安定性の両立を扱います。
主な機能
- 01開発者の日常的な摩擦の診断
- 02組織構造と製品アーキテクチャの整合
- 03開発者体験とフィードバックの改善
- 04開発速度と安定性の両立
- 05ペアプログラミングによる協業
活用シーン
- 01エンジニアリングのワークフロー上の停滞を特定
- 02製品アーキテクチャに合わせてチーム構成を調整
- 03チームでのペアプログラミングを設計
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/engineering-cultureを入力して読み込まれたか確認します。
同梱ファイルreferences/guest-insights.md
詳細
エンジニアリング文化
優れたエンジニアリング組織を築いた19人のプロダクトリーダーのフレームワークを活用して、ユーザーが強固なエンジニアリング文化を築けるよう支援します。
支援方法
ユーザーがエンジニアリング文化について支援を求めた場合：
- 現状を診断する - チームの規模、取り組み、課題を把握します
- ボトルネックを特定する - 問題がDevEx、組織構造、人材、プロセスのどれにあるかを判断します
- 適切な成果を目指して設計する - スピード、安定性、開発者の満足度に焦点を当てます
- 仕組みと自律性のバランスを取る - 必要なプロセスの量を調整できるよう支援します
基本原則
DevOpsはツールではなく能力です
Nicole Forsgren：「DevOpsは購入するツールチェーンではありません。マーケティングチームが皆さんのお金を得るために、ツールチェーンをDevOpsと名付けたのです。DevOpsとは、技術的能力、アーキテクチャ上の能力、文化的能力、リーンマネジメントの実践からなる一連の能力です。」特定のツールを導入するだけでなく、統合された能力に焦点を当てます。
コンウェイの法則には大きな力があります
Dhanji R. Prasanna：「コンウェイの法則には、本当に大きな力があります。組織構造がそのまま製品になります。チームや連携するグループがどのように編成されているかは、何を作るかに大きく影響します。」組織構造は、アーキテクチャと製品の品質を直接左右します。
エンジニアはアーキテクトへと変わりつつあります
Scott Wu：「Devinは、エンジニアをレンガ職人からアーキテクトへと変えるものだと考えています。その多くは、ハイレベルな指示を出し、自分の望む形を正確に指定できる段階に到達することです。」エンジニアリングの未来では、人間の役割が手作業でのコーディングから、アーキテクチャの監督へと移っていきます。
DevExは基盤です
Nicole Forsgren：「開発者エクスペリエンスとは、日々ソフトウェアを構築する体験のことです。開発者が直面する摩擦や、取り組まなければならないワークフローのことです。DevExが悪ければ、ほかのすべてが役に立たなくなるため、重要なのです。」フロー状態、認知負荷、フィードバックループが3つの柱です。
会社のクロックスピードを最適化する
Albert Cheng：「Duolingoのプロダクト体験は、実際にユーザーごとに1日に何度も変化します。会社のクロックスピードをとても重視しているのです。」高いパフォーマンスを発揮するエンジニアリング文化は、実験を極めて高い頻度で行うことを中心に築かれます。
すべての職種がコードに触れるようにする
Brandon Chu：「プロジェクト管理はすべてGitHub上で行い、PRにコメントしていました。マーケターであっても、ブログ記事をアップロードするには、コミットしてデプロイする必要がありました。」すべての職種がエンジニアリングツールに直接関わるようにして、技術文化を築きます。
人材密度が高いほど、プロセスは少なくて済みます
Michael Truell：「エンジニアリング面では、非常に優秀で冷静な人、外部からの評価よりも優れたものを作ることに注力する人を採用することで、まだ多くのプロセスを導入せずに済んでいます。」組織の間接コストを減らすために、人材の気質を重視して採用します。
ペアプログラミングは十分に活用されていません
Farhan Thawar：「ペアプログラミングは、間違いなくエンジニアリングにおいて最も活用されていないマネジメントツールです。スループットを制限するのは、キーボードに向かう手の数ではありません。優れた洗練された解決策を見つけることです。」知識の共有や洗練された解決策の発見に、ペアプログラミングを活用します。
ユーザーを支援するための質問
- 「開発者の日々のワークフローで、最も大きな摩擦点は何ですか？」
- 「組織構造は、製品アーキテクチャにどのように対応していますか？」
- 「エンジニアは、会議と比べてどのくらいの時間をフロー状態で過ごしていますか？」
- 「チームの『クロックスピード』はどれくらいですか？変更をどのくらいの頻度でリリースし、テストできますか？」
- 「エンジニア以外の職種の人たちは、デプロイのワークフローを理解していますか？」
指摘すべきよくある間違い
- 能力を育てず、ツールを購入する - DevOps ツールチェーンを導入すれば文化的な問題が解決すると期待する
- コンウェイの法則を無視する - 組織構造が、目指すプロダクトアーキテクチャと一致していない
- DevEx を軽視する - 開発者体験の低さが、ほかのあらゆる投資の効果を損なう
- 優秀なチームに過剰なプロセスを課す - 優れたチームに不要な官僚主義を持ち込む
- 顧客価値よりコード品質を優先する - ユーザーの問題を解決することより、完璧なアーキテクチャを優先する
詳細
19 人のゲストから得られた 23 の知見については、references/guest-insights.md を参照してください。
関連スキル
- 技術ロードマップ
- 技術的負債の管理
- プラットフォームとインフラストラクチャ
- デザインエンジニアリング