mcpField
E
engineering-health

engineering-health

github.com/refoundai開発1.4k332 回インストール15 週間前に更新
リポジトリ

engineering-health について

エンジニアリングチーム向けの健全性・生産性支援スキルです。Lenny's Podcast と Newsletter の知見を基に、デリバリー速度、技術投資、開発者体験、品質の両立を支援します。

主な機能

  1. 01Core 4 または DORA で基準を設定
  2. 02コードから本番までのボトルネック特定
  3. 03技術投資を事業 ROI で説明
  4. 04多面的な生産性指標の活用
  5. 05AI ツールの価値評価
  6. 06技術的負債と品質の管理

活用シーン

  1. 01ソフトウェアデリバリーの測定
  2. 02レビューやデプロイの遅延特定
  3. 03技術的負債への投資提案
  4. 04AI がエンジニアリングに与える影響の評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/refoundai/lenny-skills --skill engineering-health

インストール後、Claude Code で/engineering-healthを入力して読み込まれたか確認します。

同梱ファイルreferences/artifacts.mdreferences/guest-insights.md

詳細

エンジニアリングの健全性と生産性

技術的な卓越性と、戦略的な開発者への投資のバランスを取り、高いデリバリー速度を維持しましょう。

Lenny's Podcast と Newsletter に登場した18人のゲストと投稿から得られた知見を活用して、エンジニアリングの健全性と生産性についてユーザーを支援します。

支援方法

  1. 健全性のベースラインを設定する - Core 4 または DORA のフレームワークを使い、チームのパフォーマンスの定量的・定性的な出発点を確立します。
  2. ワークフローを最適化する - コードの完成から本番環境へのデプロイまでの過程にあるボトルネックを特定し、隠れたデリバリー速度を引き出します。
  3. 技術的負債を管理する - 技術への投資をビジネス上の ROI として説明し、機能開発以外の作業への賛同を得ます。
  4. AI ツールを活用する - AI を開発ライフサイクルに取り入れ、エンジニアが構文ではなくアーキテクチャに注力できるようにします。

基本原則

量より価値で AI を評価する

Chip Huyen:「生産性を測定するのは本当に難しいです。そこで私は、チームの全員にとても高価なコーディングエージェントのサブスクリプションを提供するのと、追加で1人採用するのとでは、どちらがよいかをマネージャーに尋ねるよう勧めています。ほぼすべてのマネージャーが、追加の人員だと答えるでしょう。」

AI ツールのコストと成果を、単に生産性の向上幅だけで見るのではなく、追加の人員を雇う価値と比較します。

アーキテクチャに注力する

Inbal S:「AI ツールを使ってソフトウェアを開発する人は、考え方を変える必要があります。AI ツールをどう使えば成功につながるのかを考え始めなければなりません。もはや実際にコードを書くことだけではなく、より大局的な視点、つながりのあるユーザー体験、連携するシステムへと考えを発展させていくことが重要です。」

AI に手作業での構文記述を任せ、エンジニアが高水準のシステム設計とプロダクトへの理解により多くの時間を使えるようにします。

AI に対応できるよう社内ツールを近代化する

Mike Krieger:「すぐにマージキューなど、別の要因がボトルネックになりました。書かれるコードも提出されるプルリクエストも大幅に増えたため、マージキューを全面的に再設計する必要がありました。プルリクエストの半数以上が Claude Code によって生成されています。」

AI によるコーディングでプルリクエストの量が大幅に増加しても対応できるよう、マージキューなどの社内ツールを再設計する必要があります。

多面的な生産性を測定する

Nicole Forsgren:「生産性とは、基本的にどれだけの仕事をどれだけの期間で成し遂げられるかだと思います。だからこそ、全体を捉える測定指標がとても重要です。力ずくで進めることはできませんよね。私のチームや多くの同僚が生産性を研究する際に、コミュニティの効果も含めるのはそのためです。ソフトウェア開発はチームで取り組むものだからです。」

成果物の量だけを測る指標は避け、チームの連携、持続可能性、ワークフローの摩擦を含めたバランスの取れた視点を用います。

品質の関門を自動化する

Sherwin Wu V2:「毎日、PR の100%を Codex がレビューしています。つまり、本番環境に入るためにマージされるコードはすべて Codex が確認し、PR に改善案や変更案を提案するということです。」

コードの量が増えても品質を維持できるよう、手動レビューをボトルネックにすることなく、AI を活用した自動レビューを導入します。

AI の進歩を測定する

Dhanji R. Prasanna:「AI を非常に積極的に活用しているエンジニアリングチームは、週あたり約8~10時間の削減を報告しています。このような数値を聞くたびに、重要なのは、これが今後も変わり続けるということです。これが現在のベースラインです。」

AI を積極的に活用するチームが週あたりに削減した時間を記録し、技術の成熟に応じて変化するパフォーマンスのベースラインを確立します。

コード削除を奨励する

Farhan Thawar:「Delete Code Club があります。いつだって100万行以上のコードを削除できることがあり、信じられないほどです。」

古くなったコードを積極的に削除し、システムの複雑さが開発速度を低下させないようにします。

技術的負債をレバレッジとして捉える

Gaurav Misra:「スタートアップの仕事は、技術的負債をあえて抱えることだと、私は本当に思います。そうすることで、大企業よりも速く事業を進められるからです。大企業は技術的負債を抱えず、通常はすぐに返済するか、スタートアップだった頃の技術的負債を返済し続けています。」

新たに市場に出せる価値を届ける速度が大幅に上がる場合は、意図的に技術的負債を抱えることを選びましょう。

最後の一歩を最適化する

「チームのベロシティを高める」より:「エンジニアと話し合い、レビュー、承認、デプロイのプロセスを速める機会を探しましょう。」

コードの完成からデプロイまでの技術的なワークフローに注力し、リリース速度を大幅に高めましょう。

テンプレートとフレームワーク

  • Core 4 フレームワーク(Core 4 の紹介:プロダクトのベロシティを測定・改善する最善の方法)- 互いに緊張関係を保つよう設計された4つの側面を持つ、統合的な開発者生産性フレームワークです。これにより、チームのパフォーマンスをバランスよく把握できます。共同執筆者
  • DORA メトリクス(Four Keys)(Nicole Forsgren)- ソフトウェアデリバリーのパフォーマンスを測定する4つのメトリクスで、速度と安定性に分かれています。
  • エンジニアリング効率への投資に関する ROI の提示方法(Core 4 の紹介:プロダクトのベロシティを測定・改善する最善の方法)- 開発者エクスペリエンスの改善について、経営陣にビジネス上の妥当性を示すための、相互補完的な2つの切り口です。
  • Core 4 ベースライン調査テンプレート(Core 4 の紹介:プロダクトのベロシティを測定・改善する最善の方法)- エンジニアリングチームに送信し、Core 4の4つの側面すべてにわたるベースライン測定値を収集できる、すぐに使える調査テンプレートです。回答は匿名である必要があります。
  • 地味な投資の正当化プレイブック(Casey Winters)- 技術的負債、パフォーマンス、UX の改善への賛同を得るための戦術です。
  • Polishing Season(年次品質向上の取り組み)(Linear のプロダクト開発方法)- 年末に毎年行う取り組みで、Linear が集中して時間を確保し、ユーザーから寄せられたバグ、細かな不便、品質上の問題を修正します。
  • SPACE フレームワーク(Nicole Forsgren)- バランスの取れたメトリクスを実現するため、複雑で創造的な作業を5つの側面から測定するフレームワークです。
  • Crying Octopus Button(細かな不便の報告)(David Singleton)- 開発環境に組み込まれた社内ツールで、作業の妨げとなる要因をすぐに報告できます。
  • 四半期ごとの Grease Week(Duolingo のプロダクト開発方法)- プロダクトチームがバグと技術的負債の解消に専念する、四半期ごとの専用の1週間です。
  • 技術的負債の滑走路(Gaurav Misra)- 技術的負債を財務上のレバレッジのように捉え、「金利」を使って、負債がスタートアップにとって致命的になる時期を判断する考え方です。

詳細を含む一覧は references/artifacts.md をご覧ください。

ユーザーに役立つ質問

  • 「エンジニアリングの稼働能力のうち、現在、保守と新機能の開発にそれぞれどのくらいの割合を使っていますか?」
  • 「コードが完成してから本番環境にデプロイされるまで、通常どのくらいかかりますか?」
  • 「開発者を対象に調査を行い、日々のワークフローで最大の妨げとなっている点を特定しましたか?」
  • 「技術的負債の返済と新機能の開発のどちらを選ぶかについて、明確なフレームワークがありますか?」
  • 「エンジニアリング組織で AI ツールの効果や利用状況を、現在どのように測定していますか?」
  • 「現在、プロダクトの品質向上を妨げている、特に大きな細かな不便や UX 上の問題を3つ挙げると何ですか?」

よくある間違いとして指摘すべきこと

  • 成果への影響よりも生のアウトプットを測定する - コード行数やPRの数に注目すると、コードの品質が見落とされ、燃え尽きやシステムの脆弱化につながる可能性があります。
  • すべての負債を悪いものとして扱う - あらゆる技術的負債を避けると、スタートアップがプロダクトマーケットフィットを見つけるのに十分な速度で進めなくなる可能性があります。
  • 自動化された指標だけに頼る - 定量データから問題の存在は特定できますが、具体的な摩擦点を診断するには、開発者からの定性的なフィードバックが必要です。
  • 安全網となるテストへの投資が不十分 - 堅牢なユニットテストがなければ、エンジニアはコードをリファクタリングしたり、何かを壊すことなく迅速に作業したりする自信を失います。

詳細

18人のゲストから得られた21件すべての知見については、references/guest-insights.mdを参照してください。

関連スキル

  • PRD の作成
  • リリース速度
  • AI 支援プロトタイピング
  • AI エージェントを活用した開発

コメント