公式スキル · 経営者の原則
マスク流 5ステップの要件見直し
業務プロセスや仕様を、イーロン・マスクが語った5つのステップの順番で見直す。要件と責任者を疑い、削り、単純にし、速くし、自動化は最後にする。
Not affiliated with or endorsed by Elon Musk or their companies. About these principles: Elon Musk's ideas, explained.
Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。
使う場面
- プロセスや承認の流れが遅く重くなった
- ワークフローを自動化する前、そのためのソフトウェアを買う前
AI に渡すもの
- 工程ごとのプロセスか仕様
- 要件ごとの責任者
- 工程ごとの作業時間と待ち時間
- 動かせない制約とその出典
できあがるもの
責任者の名前と判定つきの要件の表、削ったものと戻す必要が出たときのわかり方、単純化、高速化、最後に自動化するもの、見直しの日。
手順
- 要件と工程を並べる 1行に1つ。それぞれの横に、責任を持つ人をチーム名ではなく人の名前で書く。だれの名前も挙がらなければ「責任者なし」と書く（原則2）。
- 要件をひとつずつ疑う それをなくしたら何が壊れるか、責任者はなぜそうだとわかるのかを問い、残す・変える・削る候補のどれかをつける。もっともらしく聞こえる要件にも同じ問いをかける（原則1）。
- 削る 削る候補をすべて計画から外す。どれが元に戻せるかを書き、いくつかは戻すつもりでいる。プロセスを回してみて1つも戻らなければ、たぶん削り方が足りない（原則3）。
- 残ったものを単純にする ここで初めて、工程をまとめ、受け渡しを減らし、申請書を短くし、選択肢を減らす（原則4）。
- 速くする 単純にしたプロセスのサイクルタイムを縮める。待ちをなくし、まとめて処理する量を減らし、早く決める（原則5）。
- 自動化は最後に 安定して自動化できるようになったものと、手作業のまま残すものを挙げる。削った工程に向けて計画されていた自動化があれば、印をつける（原則6）。
- 見直しの日を決める 担当者、戻すことになったものを確かめる日、測る指標（サイクルタイム、エラー率、週あたりの時間）を決める。
SKILL.md の全文
AI が読むファイルそのものです。 ダウンロード
---
name: musk-style-five-step-algorithm
description: 業務プロセス・製品仕様・ワークフローを、イーロン・マスクが2021年の Starbase のツアーで説明し、ウォルター・アイザックソンの伝記がアルゴリズム（the algorithm）と呼ぶ5つのステップの順番で見直す。要件をひとつずつ疑い、その要件に責任を持つ人の名前を書き、部品や工程を削り、そのあとで単純化し、次に速くし、自動化は最後にする。プロセスが遅く重くなったとき、ワークフローを自動化する前やそのためのツールを買う前、だれも理由を説明できない要件が仕様にあるとき、5ステップのアルゴリズムを当てはめたい、要件をすべて疑いたい、工程を削りたいと頼まれたときに使う。
---
# マスク流 5ステップの要件見直し
これは、イーロン・マスクが2021年の Starbase のツアーでのティム・ドッド（Everyday Astronaut）とのインタビューで公に語り、Entrepreneur と Fortune が伝えている原則である。Fortune はウォルター・アイザックソンの2023年の伝記をもとにしている。イーロン・マスク本人やその会社とは関係がなく、推薦も承認も受けていない。このスキルは、1つのプロセスか仕様を5つのステップに順番どおりに通し、疑うこと、削ること、単純にすること、速くすること、そして最後に自動化することを返す。
## 基本ルール
- イーロン・マスクの言葉や意見として、出典にあるもの以外を書かない。
- イーロン・マスクになりきったり、口調をまねたり、本人の声で書いたりしない。ユーザーの資料を下の原則に照らして見直す。
- 順番を守る。疑うことと削ることを済ませていない工程について、単純化、高速化、自動化を提案しない。
- 法令、安全、締結済みの契約から来る要件は、その要件に責任を持つ人に聞くことで疑い、このスキルが削ることはしない。[要確認: 責任者／条項] と書き、そのことを明記する。
- 要件の責任者や工程にかかる時間をつくらない。わからないものは [要確認: …] と書く。
- この方法が合わないときはそう書く。たとえば、すでに最小限で、人手や処理能力が足りないだけのプロセス。
## 原則
1. **だれが決めた要件でも疑う。** マスクは、要件はだれが出したものでも間違いなくどこかおかしい、だれでもときどき間違えるのだから、と述べ、頭のいい人から来た要件はいちばん危ない、十分に疑わないかもしれないから、と話している。出典：Starbase のツアー、Part 1、2021年（動画）、Entrepreneur、2021年。
2. **要件には人の名前をつける。** 要件や制約には、部署ではなく、それに責任を持つ人の名前がついていなければならない。要件は、それを考えた人がいなくなっても残りうるからだ、と述べている。出典：Starbase のツアー、Part 1、2021年（動画）。
3. **部品や工程を削ることに全力を尽くす。** 人は念のためにと部品や工程を足したがる傾向が強く、削ったものを戻すことが少なくとも10%の割合で起きていないなら、削り方が足りない、と述べている。出典：Starbase のツアー、Part 1、2021年（動画）、Entrepreneur、2021年。
4. **単純化・最適化は3番目。** この順番の理由として、優秀なエンジニアにとてもよくある誤りは、存在すべきでないものを最適化することだと挙げている。出典：同上。
5. **速くするのは4番目。** 速くするのは、最初の3つを済ませてから。自分の墓を掘っているなら、答えは速く掘ることではなく掘るのをやめることだ、というたとえを使っている。出典：同上。
6. **自動化は最後。** マスクは、テスラのモデル3で手順を逆にたどり、削る前に自動化してしまったと話している。Fortune はアイザックソンの伝記を紹介する記事で、同じ5つを同じ順番で挙げ、フリーモント工場をはじめからすべての作業を自動化する形で計画し、のちに改めたことを書いている。出典：Starbase のツアー、Part 1、2021年（動画）、Fortune、2023年。
## 使う場面
- プロセス、申請書、承認の流れ、製品仕様が遅く重くなった。
- ワークフローを自動化する前、そのためのソフトウェアを買う前。
- だれも理由を説明できない要件が仕様にある。
- 1つの障害の根本原因を探すときには使わない（ohno-style-five-whys を使う）。バリューストリーム全体のムダを種類ごとに分けるときにも使わない（ohno-style-seven-wastes を使う）。
## 用意するもの
- プロセスか仕様を、工程ごと、または要件ごとに。
- 要件ごとに、わかれば、どこから来たかと、だれが説明できるか。
- わかれば、工程ごとの作業時間と、工程のあいだの待ち時間。
- 自動化やツールの購入の計画があれば、その内容。
- 動かせないとわかっている制約（法令、安全、契約）と、その出典。
## 手順
1. **要件と工程を並べる。** 1行に1つ。それぞれの横に、責任を持つ人をチーム名ではなく人の名前で書く。だれの名前も挙がらなければ「責任者なし」と書く（原則2）。
2. **要件をひとつずつ疑う。** それをなくしたら何が壊れるか、責任者はなぜそうだとわかるのかを問い、残す・変える・削る候補のどれかをつける。もっともらしく聞こえる要件にも同じ問いをかける（原則1）。
3. **削る。** 削る候補をすべて計画から外す。どれが元に戻せるかを書き、いくつかは戻すつもりでいる。プロセスを回してみて1つも戻らなければ、たぶん削り方が足りない（原則3）。
4. **残ったものを単純にする。** ここで初めて、工程をまとめ、受け渡しを減らし、申請書を短くし、選択肢を減らす（原則4）。
5. **速くする。** 単純にしたプロセスのサイクルタイムを縮める。待ちをなくし、まとめて処理する量を減らし、早く決める（原則5）。
6. **自動化は最後に。** 安定して自動化できるようになったものと、手作業のまま残すものを挙げる。削った工程に向けて計画されていた自動化があれば、印をつける（原則6）。
7. **見直しの日を決める。** 担当者、戻すことになったものを確かめる日、測る指標（サイクルタイム、エラー率、週あたりの時間）を決める。
## 出力の形式
```markdown
# 5ステップの見直し：[プロセスか仕様]
これは、イーロン・マスクが公に語った原則である。イーロン・マスク本人やその会社とは関係がなく、推薦も承認も受けていない。
## 1. 要件とその責任者
| # | 要件か工程 | 責任者（人の名前） | なくすと何が壊れるか | 判定 |
|---|---|---|---|---|
| | | | | 残す／変える／削る |
## 2. 削ったもの
| 項目 | 元に戻せるか | 戻す必要があるとどうわかるか |
|---|---|---|
## 3. 単純にしたこと
- [変更]
## 4. 速くしたこと
- [変更と、見込みのサイクルタイム]
## 5. 自動化（最後に）
| 工程 | いま自動化／あとで／しない | 理由 |
|---|---|---|
## 手をつけなかった動かせない制約
- [要件] - [出典] [要確認: 責任者]
## 見直し
担当者：[名前] · 日付：[日付] · 指標：[指標]
## 使った原則
[番号つきで、出典とともに]
```
## 例
**入力：** 「うちの制作会社では、新しいクライアントの受け入れに9営業日かかっています。工程は次のとおりです。営業が40項目のヒアリングシートを埋める。担当ディレクターがそれを CRM に打ち直す。キックオフ資料を毎回ゼロから作る。経理がすべてのクライアントに与信チェックをかける。法務が標準の契約書を確認する。クライアントにウェルカム資料の PDF を送る。ヒアリングシートから CRM への転記を自動化するツールを買おうとしていたところです。与信チェックはだれが求めたのかわかりません。4年前に1件の貸し倒れがあってから加わりました。」
**出力（抜粋）：**
```markdown
これは、イーロン・マスクが公に語った原則である。イーロン・マスク本人やその会社とは関係がなく、推薦も承認も受けていない。
## 1. 要件とその責任者
| # | 要件か工程 | 責任者（人の名前） | なくすと何が壊れるか | 判定 |
|---|---|---|---|---|
| 1 | 40項目のヒアリングシート | 責任者なし | [要確認: キックオフで使う項目はどれか] | 変える：だれかが読む項目だけ残す |
| 2 | CRM への打ち直し | 責任者なし | シートから CRM に直接入るなら、何も壊れない | 削る |
| 3 | すべてのクライアントへの与信チェック | 責任者なし（1件の貸し倒れのあとに追加） | 高額の未払いのリスク | 変える：一定の契約金額を超えるときだけ [要確認: 経理の責任者] |
| 4 | 法務による標準契約書の確認 | [要確認: 法務] | [要確認] | 動かせない制約：責任者に聞く |
| 5 | ウェルカム資料の PDF | 責任者なし [要確認] | [要確認: クライアントが読んでいるか] | 削る |
## 2. 削ったもの
| 項目 | 元に戻せるか | 戻す必要があるとどうわかるか |
|---|---|---|
| CRM への打ち直し | 戻せる | キックオフでクライアントの情報の抜けが見つかる |
| ウェルカム資料の PDF | 戻せる | クライアントから同じ初期設定の質問が続く |
## 5. 自動化（最後に）
| 工程 | いま自動化／あとで／しない | 理由 |
|---|---|---|
| ヒアリングシートから CRM への転記ツール | しない | 自動化しようとしていた工程を削った |
```
## 送る前のチェック
- [ ] 出典を示す一文と、本人や会社と関係がないことを示す一文が出力にある。
- [ ] どの要件にも人の名前があるか、「責任者なし」と書いてある。
- [ ] ステップを順番どおりに当てはめ、削る前に自動化したものがない。
- [ ] 削ったものに、元に戻せるかと、必要だったときにどう表れるかが書いてある。
- [ ] 法令、安全、契約から来る要件は削らず、責任者に確かめるよう印がついている。
- [ ] 見直しの日付、担当者、指標が決まっている。
## よくある失敗
- 目に見える解決策だからと、自動化や新しいツールから始める。
- 削るべきだった工程を磨く（よりよい申請書を作る）。
- 「コンプライアンス上必要」を、人の名前と条項なしに受け入れる。
- 戻したものがゼロなのを成功だと思う。
チームで使う
AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む
変更履歴
- v1.0.2 · · Example: the welcome pack PDF is now in the requirements table, with no owner and its use marked to check, before it appears under Deleted.
- v1.0.1 · · Example output now opens with the attribution and not-affiliated lines, as the skill's own checks require.
- v1.0.0 · · First release.
出典
出典は英語のページです。