high-output-management について
High Output Managementの原則を、監査可能な実践に落とし込む管理者向けスキルです。生産フロー、指標、マネジメントのレバレッジ、会議、意思決定を扱います。
主な機能
- 01生産フローのボトルネック分析
- 02成果と品質の指標設計
- 03マネジメントレバレッジの監査
- 04タスク単位の委任とモニタリング
- 05会議と1:1の運用
- 06意思決定とOKRの指針
活用シーン
- 01開発や採用の工程上の制約を特定
- 02デリバリー指標に品質指標を組み合わせる
- 03管理者の予定と委任方法を見直す
- 041:1とチーム会議の頻度を設計
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ wondelai/ skills --skill high-output-managementインストール後、Claude Code で/high-output-managementを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/case-studies.mddecisions-planning-okrs.mdindicators-and-production.mdleverage-and-calendar.mdmeetings-and-one-on-ones.md詳細
ハイアウトプット・マネジメント
Andy Grove が Intel を率いた方法にならってチームをマネジメントしましょう。マネージャーのアウトプットは、マネージャー自身が行うことではなく、その組織が生み出すものです。このスキルでは、High Output Management の考え方を監査可能な実践へと落とし込みます。ナレッジワークの生産原則、アウトプット指標、マネジメントのレバレッジ、マネジメントの手段としてのミーティング、明確な意思決定、OKR、そしてタスクに関する成熟度に合わせたマネジメントスタイルを扱います。
中核となる原則
マネージャーのアウトプット = その組織のアウトプット + マネージャーが影響を及ぼす近隣組織のアウトプットです。 メール、ミーティング、レビュー、意思決定など、マネージャーが行うこと自体には価値はありません。それらが合算されたアウトプットをどれだけ高めるかによってのみ、価値が決まります。マネージャーの時間が限られた資源である以上、マネジメントの技術は、ひたすら次の問いを立てることに尽きます。今できることのうち、費やす時間あたりのアウトプットを最も高めるのは何でしょうか。レバレッジの高い活動を選び、負のレバレッジをもたらす活動をなくしましょう。
評価基準
目標:10/10。 以下の原則に照らし、マネジメントの慣行、カレンダー、プロセスを0〜10で評価してください。現在のスコアと、10/10に到達するために必要な具体的な変更を示してください。
- 9-10: 品質と組み合わせたアウトプット指標、TRMに基づく頻度で部下が主導する1:1、タスク単位のモニタリングを伴う委任、報酬に結び付けず意欲的な目標を設定するOKR、予測される重要イベントを中心に組み立てたカレンダー
- 7-8: プロセスに関するミーティングは適切に運営されていますが、活動量の指標がいくつか残っているほか、臨時の意思決定ミーティングや中止されたトレーニングセッションがあります
- 5-6: 1:1が不定期で、指標は忙しさを追跡し、委任は全面的か皆無かのどちらかで、計画は行動ではなく文書を生み出しています
- 3-4: 割り込みによるマネジメントです。進捗報告のための見せかけ、役職による意思決定、年次レビューでの突然の指摘が見られます
- 0-2: 1:1も指標もなく、火消しが日常的な運用形態となり、アウトプットが可視化も測定もされていません
フレームワーク
1. ナレッジワークの生産原則
中核となる考え方: Grove の朝食工場では、3 分で作る卵、バターを塗ったトースト、熱いコーヒーを、許容できる品質と最小のコストで同時に提供します。この考え方には、生産のすべてが含まれています。制約となる工程(卵)を中心にフローを構築し、最も価値の低い段階で問題を解決し、段取りコストが支配的な場合はバッチ処理を行い、需要予測に基づいて作るか、注文を受けてから作るかを意識的に選択します。エンジニアリング、サポート、採用など、すべてのチームが、誰かが工程を図に描いたかどうかにかかわらず、生産ラインを運用しています。
効果がある理由: ナレッジワークでは組み立てラインが見えにくく、フローが見えないと場当たり的な対応を招きます。生産の考え方を取り入れると、フローが可視化されます。制約となる工程がわかれば、それ以外のすべての工程をその周りにスケジュールできます。また、顧客の皿に載る前に卵の段階で不良を見つければ、修正コストをわずかに抑えられます。
主なポイント:
- 制約となる工程を中心に構築します。最も時間がかかる、難しい、またはコストの高い工程を見つけ、それ以外のすべてをそこから逆算して調整します。多くの場合、コードレビュー、ステージング環境へのアクセス、または過重な負担を抱えた専門家が該当します
- 最も価値の低い段階で問題を解決します。欠陥のある仕様は、それを基に3スプリントかけて構築した後ではなく、レビュー時に却下します
- 段取りコストの高い作業(面接、コードレビュー、中断への対応など)はバッチ処理し、段取りコストを複数の作業に分散します
- ナレッジワークのほとんどは注文を受けてからではなく、需要予測に基づいて行われます。トーストが顧客の注文前に焼き上がるように、予測に合わせてパイプラインの人員を配置し、管理されたリスクを受け入れます
- すべての作業を監視することはできません。ブラックボックスとして扱い、少数の指標を通して内部を見えるようにします
適用例:
| コンテキスト | 適用方法 | 例 |
|---|---|---|
| スプリントのフロー | 制約となる工程に合わせてスケジュールします | レビューがボトルネック → 新しい作業を始める前に、レビュアーの時間を確保します |
| 品質ゲート | 最も価値の低い段階で検査します | 仕様レビューで欠陥のある設計を却下し、3週間の構築作業に入る前に対処します |
| 採用パイプライン | バッチ処理し、需要予測に基づいて準備します | 火曜と木曜に電話面談をまとめて実施し、オファー日の予測に合わせて面接担当者の対応能力を確保します |
倫理的な境界: 人ではなくシステムを限界まで稼働させます。生産の考え方で最適化するのは作業であり、人を交換可能な機械として扱うことは決してありません。
関連資料:references/indicators-and-production.md:制約となる工程を見つけたり、ダッシュボードを構築したりする際に参照してください。制約工程の分析、指標ペアの具体例、先行指標とトレンド指標、段階別チャート、オペレーションレビューの進め方を掲載しています。
2. 嘘をつかない指標
中心となる考え方: 活動量ではなく成果を測ります。チームがどれだけ忙しそうに見えたかではなく、実際にリリースされ、その後も機能しているものを測ります。数量を示す指標には必ず品質を示す指標を組み合わせ、一方を犠牲にしてもう一方を最適化できないようにします。また、対処する時間を確保できる先行指標を優先し、予測がどのように変化したかを示す階段状のチャートで予測を報告します。
効果がある理由: 人は経営陣が測定するものに取り組むため、対応する指標のない単独の指標は、その数字を操作するよう促す指示になってしまいます。指標を組み合わせれば、フィードバックループが生まれます。スループットを上げても、障害発生率によって手抜きが明らかになります。先行指標と階段状のチャートを使うと、測定が事後検証から軌道修正へと変わります。
主なポイント:
- コード行数、記録した時間、対応したチケットは活動量です。プロダクション環境で稼働している機能や、解決した問題が成果です。
- 数量と品質を組み合わせます。週あたりのデプロイ数には変更失敗率、クローズしたチケット数には再オープン数、ベロシティにはインシデント数を組み合わせます。
- レビュー待ち行列の滞留時間、ビルドの不安定さ、オンコールのページ発生率といった先行指標は、成果が低下する前に警告します。トレンド指標は、自チームの過去の実績や予測と成果を比較します。
- 階段状のチャートでは、各期間に同じ予測対象期間を再予測します。列を縦に見ると、予測が誠実か、楽観的か、あるいは意図的に低く見積もられているかが分かります。
- 採用担当者の週あたりのオファー数や、1日あたりの処理済み請求書数など、管理業務の指標も工場のように測定します。その際は必ず品質を示す指標も組み合わせます。
活用例:
| コンテキスト | 活用方法 | 例 |
|---|---|---|
| エンジニアリングダッシュボード | 数量と品質を組み合わせる | 週あたりのデプロイ数と変更失敗率を組み合わせる |
| サポート業務 | 成果と、それに伴う品質の指標 | 1日あたりの解決チケット数と再オープン率およびCSATを組み合わせる |
| 四半期予測 | 階段状のチャート | 四半期末のARRを毎月再予測し、各列を縦に見て予測のずれを確認する |
倫理的な境界: 指標で測るのは仕事であり、働く人ではありません。監視に使うと、成果ではなく数字を最適化するよう人々に学習させてしまいます。
3. マネージャーのレバレッジ
中核となる概念: レバレッジとは、マネージャーの時間単位あたりに生み出される成果です。レバレッジの高い活動は、多くの人に一度に影響を与える(トレーニング、十分に準備された意思決定、情報収集など)か、タイミングよく少し後押しするだけで、数か月分の仕事の方向を変えます。カレンダーはマネージャーの生産システムです。重要な予定を予測し、それ以外をまとめ、余力がないときは最初の段階で断りましょう。
効果がある理由: マネージャーの活動は、1時間あたりの成果に桁違いの差があります。レビューの準備に90分かければ、ある人の1年分の仕事を方向づけられますが、1日中口出しをすれば成果を損ないます。カレンダーの予定を成り行きに任せるマネージャーは、声の大きいものに貴重な時間を費やします。
主なポイント:
- 負のレバレッジは現実に存在します。口出し(専門家を細かく監督すること)、優柔不断(他の人が待っている意思決定を先延ばしにすること)、そしてマネージャーの目に見える憂うつさは、いずれもチーム全体に悪影響を増幅させます
- 自分が最もよく知っているタスクを委任しましょう。進捗の監視にかかるコストを最小限に抑えられます。ただし、監視を伴わない委任は放棄であることを忘れないでください
- 人ではなくタスクのレベルで監視しましょう。受け入れ検査のようにサンプルを確認し、タスクに関連する習熟度が低い場合は詳しく、習熟度が上がるにつれて確認を軽くします
- ボトルネックとなる工程を予測しましょう。1:1、スタッフ会議、レビュー、計画をまずカレンダーに入れ、その周囲に割り込みを配置します。逆にしてはいけません
- 稼働率を100%未満に保ちましょう。予定が埋まっているマネージャーは、あらゆる不測の事態を下流の全員の遅延に変えてしまいます。早めに断るほうが、遅れて失敗するよりも低コストです
- 割り込みで作業時間を寸断されるのではなく、相談時間や定例の確認ポイントを設けて割り込みをまとめましょう
活用例:
| コンテキスト | 活用方法 | 例 |
|---|---|---|
| 週の予定設計 | 固定の予定を予測し、それ以外をまとめる | 火曜・水曜の午前に1:1、毎日午後4時にPRレビューをまとめる、月曜に集中作業の時間を確保する |
| 委任 | TRMに応じた監視の深さ | 新入社員の最初の移行作業:計画レビューと毎日の抜き取り確認。ベテランの場合:ロールアウト計画のみ |
| 割り込み | 突発的な連絡を相談時間に置き換える | 1日に2回の相談枠を設け、場当たり的なSlackでのエスカレーションをなくす |
倫理的な境界: レバレッジとは、他者の成果を増幅させることです。自分が誰もが訪れなければならないボトルネックになるまで、情報や承認を独占してはいけません。
参照:references/leverage-and-calendar.md。カレンダーを監査したり、委任の仕組みを整えたりする際は、週次のレバレッジ監査、正・負のレバレッジの一覧、TRMに基づく監視の深さを定めた委任プロトコル、カレンダーの再設計手順、割り込みの管理を確認してください。
4. 会議はマネジメントの媒体です
基本概念: 会議はマネジメントの不備の表れではありません。情報を集め、伝え、決定し、働きかけるというマネジメントの仕事が、実際に行われる場です。プロセス志向の会議(1対1のミーティング、スタッフ会議、オペレーションレビュー)は定期的に開催し、こうした仕事の大部分を担うべきです。会議に割く時間は、カレンダーの約4分の1が目安です。ミッション志向の会議は臨時に開かれ、決定を下すことだけを目的とします。
効果がある理由: 定期的に開催すれば、定例の議題、共通の期待、準備コストゼロによって会議の負担が軽くなり、コストの高い会議を減らせます。問題は1対1のミーティングやスタッフ会議のうちに小さいまま発見され、緊急の意思決定会議に発展するのを防げます。グローブの組織不全の判定基準は、臨時のミッション志向の会議がマネジメントの時間の約4分の1を超えて占めるなら、プロセスに問題があるというものです。
主なポイント:
- 1対1のミーティングは部下のための会議です。部下が議題を用意して持ち込み、上司の役目は耳を傾け、実際に何が起きているのかを知ることです
- 1対1の頻度は、勤続年数や親しさではなく、担当業務に関する習熟度に応じて決めます。業務に就いたばかりなら毎週、熟練者なら数週間ごとに行い、月1回未満にはしないでください
- 双方が、次回の1対1で取り上げる緊急性の低い項目を「保留リスト」に記録します。これにより、割り込みをまとめて減らせます
- 上司が議事録を取ります。合意したアクションを書き留めることで、取り組む姿勢を示し、フォローアップを促します
- 「ほかに何かありますか?」:議題が終わったら、ほかに気になっていることがないか尋ねます。本当の問題が最後の5分で表面化することはよくあります
- スタッフ会議は、進行を管理した自由討議です。マネージャーは講義するのではなく、ソクラテス式に問いかけて議論を促します。繰り返し開かれる「臨時」会議は、プロセス会議であることを認めていないだけです
活用例:
| 状況 | 活用方法 | 例 |
|---|---|---|
| 新しい部下 | 毎週の1対1、議題は部下が用意 | 最初の90日間は毎週60分。議題は前日に届く |
| チームの同期 | 進行を管理した自由討議 | 2分間の近況報告の後、事前に挙げた2つの議題を討議 |
| 繰り返される「緊急」会議 | プロセスに組み込む | 今月3回目の臨時インシデントレビューを、定例のオペレーションレビューに変更 |
倫理的な境界: 1対1のミーティングを状況報告の聞き出しに使うと、相手は本当の問題を持ち込まなくなります。状況報告は文書で行うべきです。
参照:references/meetings-and-one-on-ones.md:会議の頻度を設計するときや1対1を実施するときは、議題テンプレート、スタッフ会議の設計、オペレーションレビューの役割、会議をなくすか判断するためのコスト計算を含む、1対1の完全な実践ガイドを参照してください。
5. 意思決定と計画(OKR を含む)
中核となる考え方: 理想的な意思決定は、自由な議論(すべての意見を出し合い、異論を歓迎する)、明確な決定(簡潔に示す。意見の対立が激しいほど、より明確にする)、全面的な支持(異論があっても決定に従う)という段階を進みます。意思決定は、現在の技術的知識に最も近い、能力を備えた最下位レベルで行います。計画も同じ流れで進めます。環境からの要求を評価し、現在の状況に正直に向き合い、その差を埋めます。計画の成果は文書ではなく、今行う決定とアクションだからです。
効果がある理由: 自由な議論によって、現場にある知識が表面化します。明確な決定によって、最も大きなコストを招く曖昧さを防げます。全面的な支持があれば、全員一致を待たずに組織を前進させられます。そして今日の緊急対応は、昨日の計画の失敗です。計画では、今週の火消しではなく、来年のギャップに取り組みます。
主な知見:
- ピアグループ症候群――同僚たちが互いに様子をうかがい、上位者が判断を後押しするのを待つ状態――は、「ピア・プラス・ワン」によって解消できます。これは、意思決定に決定的な影響を与える権限を持つ上位者が1人、会議に参加する形です
- 意思決定の会議を開く前に、6つの質問に答えます。何を決めるのか、いつまでに決めるのか、誰が決めるのか、誰に相談するのか、誰が承認または拒否するのか、誰に知らせるのか
- 1人で技術的知識と組織的判断力の両方を備えている人がいない場合は、最新の技術的知識を持つ人と、最も優れた組織的判断力を持つ人を組み合わせます
- 決定をひそかに覆すのは優柔不断です。新たな事実に基づいて公然と覆すのはマネジメントです
- MBO/OKR が答えるのは2つの質問です。どこを目指すのか(目標)、そして、そこに近づいているかを確認するために、どのようなペースで進むのか(主要な成果)
- 目標は少数に絞り、主要な成果は議論の余地なく採点できるほど測定可能にします。ある階層の主要な成果を、次の階層の目標にするように連鎖させます。また、報酬と機械的に結び付けてはいけません
適用例:
| 文脈 | 適用方法 | 例 |
|---|---|---|
| アーキテクチャの選択 | 自由な議論 → 明確な決定 → 決定に従う | RFC について1週間議論し、テックリードが決定します。異論を記録したうえで、全員が決定に従います |
| 意思決定の準備 | 6つの質問をまとめたブリーフ | 「6月30日までに決済ベンダーを選定。プラットフォーム PM が決定し、エンジニアリングと財務に相談し、VP が承認する」 |
| 四半期計画 | 連鎖させた OKR | 会社の KR「チェックアウトの p95 を 800ms 未満にする」が、プラットフォームチームの目標になります |
参照:references/decisions-planning-okrs.md。意見の対立が予想される意思決定や計画サイクルの準備に役立つ、6つの質問をまとめたブリーフ、ピアグループ症候群への対策、3段階の計画手法、そして Grove 式の OKR の連鎖と注意点が記載されています。
6. タスクに関連する成熟度、評価、トレーニング
中心となる考え方: 万人にとって常に優れたマネジメントスタイルというものはありません。適切なスタイルは、部下のタスクに関連する成熟度(TRM)、つまり特定のタスクに対する経験、トレーニング、自信によって決まります。TRMが低ければ「どのように」進めるかを構造的に指導し、中程度なら「何を、なぜ」行うかを双方で考え、高ければ合意した目標を定めて軽く進捗を確認します。TRMはタスクごとに異なり、勤続年数や職位とは関係ありません。そのため、タスクが変わったらスタイルもすぐに切り替える必要があります。
効果がある理由: スタイルが合っていないと、どちらの方向でも失敗します。TRMが低い相手に任せきりにするのは、権限委譲を装った放任です。TRMが高い相手に細かく指示するのは、オーナーシップを損なう干渉です。不一致のコストが積み重なるのが人事評価です。1年分のフィードバックが相手に合わない伝え方で届くと、無視された、あるいは侮辱されたと受け取られます。
主な知見:
- スターエンジニアが管理職に昇進すると、エンジニアリングのTRMは高くても、マネジメントのTRMは低い状態です。最も優秀な人であっても、新しいタスクには構造的な支援を用意します
- 人事評価は、上司が行うタスクに関連するフィードバックのなかで最も重要なものです。その唯一の目的は、評価対象者のパフォーマンスを向上させることです
- 評価と伝える内容は分けて考えます。まず書面での評価を完成させ、その後、来年の成果を実際に変える3つのメッセージを別に決めます
- 不意打ちを避けます。評価で相手を驚かせるようなことがあれば、それは上司の失敗であり、その事実は公の場に記録されます
- 調子に乗り始めたエースには、最も手をかけた評価が必要です。「その調子で続けてください」だけでは、最高のパフォーマーが次のレベルに進む機会を奪ってしまいます
- 低次のニーズが満たされた後に人を動機づけるのは、常に高まり続ける自ら設定した基準だけです(アスリートのマインドセット)。その基準を引き上げるために、マネージャーが最も効果的に働きかけられるのがトレーニングです。外部に任せず、自分で実施します。トレーニングを外部に任せることは、基準を設ける責任も外部に任せることだからです
活用例:
| 状況 | 活用方法 | 例 |
|---|---|---|
| 昇進したばかりのマネージャー | タスクごとにTRMを再評価する | スターエンジニアであっても、採用と委任について週1回、構造化された1対1ミーティングを行う |
| 評価の準備 | まず評価し、その後で伝える内容を決める | 書面での評価をすべて作成し、その後、来年の成果を変える3つのメッセージを決める |
| チームの能力向上 | マネージャー自身がトレーニングを教える | EMがインシデント対応コースを全4回で自ら教える |
参照:references/case-studies.md。評価の準備や、昇進したばかりのマネージャーのコーチングに活用できます。3つの実践シナリオ(会議に追われる新任マネージャー、ベロシティは上がるが品質が下がるケース、TRMに基づくコーチングで立て直した失敗評価)を掲載しています。
よくある間違い
| 間違い | 失敗する理由 | 修正方法 |
|---|---|---|
| 成果ではなく活動量を測る | 忙しさは操作でき、成果について何も示しません | リリースされ、問題なく稼働し続けたものを数え、量と品質を組み合わせます |
| 対になる指標を設けずに公開する | チームは品質を犠牲にして数値の最適化を図ります | 指標を運用開始する前に、品質を測る対になる指標を追加します |
| 忙しいときに1対1ミーティングを省く | カレンダー上で最も効果の高い90分を取り消すことになります | 1対1ミーティングを予定された生産工程として扱います。日程は変更しても、決して取りやめません |
| 職位で決定する | 知識は最も低い、適切な能力を持つレベルにあります。職位による決定は、その知識を黙らせます | 自由に議論した後、指名された決定者が明確に決定します |
| OKRを報酬の計算式として使う | 目標を低く、安全に設定することが確実になります | OKRは挑戦を促すツールとして使い、報酬ではOKRの達成率よりも他の要素を重視します |
| 全員に同じマネジメントスタイルを適用する | 経験の浅い人を放置し、経験豊富な人には過度に干渉します | タスクごとに、タスクに関連する成熟度に合わせてスタイルを変えます |
| 価値が最も高い段階で欠陥を見つける | 欠陥が各段階を通過するたびにコストが増大します | 本番環境だけでなく、仕様や計画も確認します |
| 年次評価までフィードバックを保留する | 一度に爆発し、信頼もその1年も失われます | 不意打ちを避けるルールを徹底し、出来事が起きたときにフィードバックを伝えます |
クイック診断
| 質問 | いいえの場合 | 対応 |
|---|---|---|
| チームの成果を一文で説明できますか? | 活動を管理しています | 成果を定義し、それを軸に4〜6個の指標を設けます |
| すべての量的指標に、品質を測る指標が組み合わされていますか? | すでに数値が不正に操作されています | 指標を組み合わせます。処理件数には流出件数、クローズ件数には再オープン件数を組み合わせます |
| チームの制約となっている工程を把握していますか? | 間違った制約を中心に業務の流れを構築しています | 作業が最も長く滞留する場所を見つけ、そこに合わせて予定を組みます |
| 直属の部下は、直近の1対1ミーティングの議題を設定しましたか? | 状況報告のミーティングを実施していました | 議題の設定を部下に任せ、あなたはメモを取ります |
| 1対1ミーティングの頻度は、業務に関する習熟度に応じて設定されていますか? | 管理しすぎている人、または管理が足りない人がいます | 業務を始めたばかりの人は毎週、経験豊富な人は毎月実施します |
| 直近の重要な意思決定は、適切な能力を持つ最も下位の階層で行われましたか? | 知識ではなく役職で決定されました | ミーティングの前に、決定者、相談を受ける人、承認者を明確にします |
| 報酬が関係なくても、チームは同じOKRを設定しますか? | 目標が控えめに設定されています | OKRを報酬の計算式から切り離します |
| 今四半期、チームに何かを直接教えましたか? | 最も効果の高い活動を見落としています | 管理者が教える講座をすぐに予定します |
参考資料
- Andrew S. Grove著、"High Output Management"
- Andrew S. Grove著、"Only the Paranoid Survive"
- John Doerr著、"Measure What Matters"
著者について
Andrew S. Grove(1936-2016)は20歳のときにハンガリーを逃れ、Intelの3人目の従業員となり、社長、CEO、会長へと昇進しました。メモリチップからマイクロプロセッサへと転換する、同社の有名な戦略転換を主導しました。1997年に『Time』誌のマン・オブ・ザ・イヤーに選ばれ、シリコンバレーのリーダーを数多く育てました。また、彼の目標管理システムは、現在テクノロジー業界で標準となっているOKRの手法へと発展しました。