目的ドリブンとは｜合目的的思考をエンジニアの仕事で使う型と計算例

ツールの使い方：上の「目的確認シート」は、頼まれた仕事を目的から整理し直すための入力欄です。6つの欄（頼まれたこと・やること／目的／達成の基準／手段／今回はやらないこと／期限）に書くと、出力を3つの形から選んでコピーできます。

• 依頼した人に送る確認メッセージ：「この理解で合っていますか。」で終わる文面です。チャットにそのまま貼れます。
• 作業メモ（Markdown）：手段がチェックリストになります。チケットやプルリクエストの説明に貼れます。
• 生成AIへの指示：目的と達成の基準に照らして、手段の抜け・余分、もっと小さな手間の別案、基準の言い換えを頼む文面です。

欄の下の「見直しのヒント」には、目的が空のとき、目的が「〜を作る」「〜を導入する」の形で手段のままのとき、目的がやることの言い換えのとき、目的が120字を超えるとき、達成の基準が空のとき、基準に数字がないとき、手段が空のとき、手段が7個を超えるとき、「今回はやらないこと」が空のときに、直し方の一言が出ます。書き方に迷うときは、見本のボタン（ログ集約の導入・週次レポート・テストの自動化）を押すと記入例が入ります。入力した内容は端末の中だけで組み立てられ、どこにも送信されません。

この記事で実際に動かしたものは、目的確認シートの3つの出力と、Python で書いた3本の計算（作業の並べ替え・確認の期待値・テストの選び分け）です。計算に使ったデータはすべて架空で、その旨を各節に書いています。

目的・目標・手段は、次のように上から下へつながります。下の段は、上の段を果たすための方法です。

flowchart TD
  P["<b>目的</b>（何のために）<br>障害の原因をすぐ見つけられる"]
  G["<b>目標・達成の基準</b>（どこまで）<br>原因のログを10分以内に見つける"]
  M1["<b>手段1</b><br>ログを<br>集める"]
  M2["<b>手段2</b><br>IDで<br>検索する"]
  M3["<b>手段3</b><br>探し方を<br>書く"]
  P --> G
  G --> M1
  G --> M2
  G --> M3

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS、Python 3.13.18（標準ライブラリだけ）で3本の計算を実行し、出力をそのまま載せています。計算に使った作業一覧・テスト一覧・確率はすべて架空の値です。目的確認シートは、記事に組み込むものと同じスクリプトを Chromium 153.0.8010.12（Playwright 1.63.0、Node.js 22.23.4）で開き、見本3つと自作の入力8通りで、3つの出力と見直しのヒントの文面を取り出しました。図は Mermaid CLI 11.16.0 で描画できることを確かめています。言葉の意味はコトバンク（デジタル大辞泉・精選版 日本国語大辞典）、書籍の書誌は出版社の発表で確かめました。生成AIに指示を送った結果は、この記事では測っていません（指示の文面を取り出したところまで）。（確認日 2026年11月11日）

目的ドリブン・合目的的とは（言葉の意味と読み方）

この節では、「目的ドリブン」「合目的的」「合目的」という言葉の意味と読み方、出どころが分かります。

目的ドリブンは「目的に駆動される（purpose-driven）」という意味の言葉です。 「ドリブン（driven）」は英語の drive の過去分詞で、ケンブリッジのビジネス英語辞典は、cost-driven や market-driven のような語の driven を「caused or influenced by something or someone（何か・誰かによって引き起こされる、影響される）」と説明しています。データドリブン（データをもとに決める）、テスト駆動開発（テストを先に書く）、イベントドリブン（出来事をきっかけに動く）と同じ「〇〇ドリブン」の形で、「何を起点に判断するか」を表します。目的ドリブンなら、起点は目的です。

合目的的は「ごうもくてきてき」と読みます。 「合・目的・的」と区切ると読みやすく、「目的に合う」＋「〜のさま」という成り立ちです。辞書の語釈は次のとおりです。

［形動］ある物事が一定の目的にかなっているさま。「合目的的な運動方針」（デジタル大辞泉「合目的的」）

ある事物が一定の目的に適合しているさま。（精選版 日本国語大辞典「合目的的」）

「的」が2つ続くので書き間違いに見えますが、辞書に載っている正しい形です。精選版 日本国語大辞典は、初出の実例として宮沢俊義『憲法講話』（1967年）の一節を挙げています。

「合目的」と「合目的的」の違い

辞書の語釈はほぼ同じで、デジタル大辞泉は互いを類語として挙げています。「合目的」だけで形容動詞として使えますが（合目的な方法）、今の文章では「的」を足した「合目的的な」「合目的的に」の形や、名詞の「合目的性」がよく使われます。意味の差を気にするよりも、「この手段は、あの目的にかなっているか」と言い換えられるかどうかで使えば、取り違えは起きません。

この記事での使い分け

この記事では、目的ドリブンを「目的から順に決めていく進め方」、合目的的を「決めた手段が目的にかなっている状態」という意味で使います。前者は順番の話、後者は確かめる観点の話です。

なお、『目的ドリブンの思考法』（望月安迪 著、ディスカヴァー・トゥエンティワン、2022年）という書籍があり、出版社は「戦略コンサルタントの思考の『型』を解説した」本として発表しています。この記事の整理（問いの型、5分の目的確認、3本の計算、判断表）は、エンジニアの仕事に合わせて独自に組み立てたもので、書籍の内容をまとめたものではありません。体系立てて学びたいときは書籍にあたるのが確実です。

目的・目標・手段の違い（同じ仕事でも目的で正解が変わる）

この節では、目的・目標・手段の3つの違いと、目的が違うと選ぶべき手段が変わる具体例が分かります。

目的は「何のために」、目標は「どこまで」、手段は「どうやって」に答えるものです。 デジタル大辞泉は用法の欄で、目的は目標に比べて抽象的で長期にわたる目あてで内容に重点があり、目標は目ざす地点・数値・数量などに重点があってより具体的だ、と説明しています。

大事なのは最後の行です。手段は「終わった」が目に見えますが、目的は「果たせた」が見えにくいので、間に数字で確かめられる目標（達成の基準）を置きます。この記事とツールでは、目標のことを「達成の基準」と呼びます。

目的が違うと、正解の手段が変わる例

頼まれる言葉は同じでも、目的が違えば合目的的な手段は変わります。エンジニアの仕事で5つ並べます。

どの行も、AとBのどちらが正しいという話ではありません。目的が決まらないうちは、手段の良し悪しは決められない、ということです。テストの行は、あとの節で小さなデータを使って実際に選び分けます。

目的と目標の粒度（どのくらい先のことを書くか）

目的は、仕事の大きさに合わせた粒度で書きます。大きすぎる目的は日々の判断に使えず、小さすぎる目的は手段と区別がつきません。

手段の目的化が起きるしくみと、エンジニアの仕事での典型例

この節では、手段がいつの間にか目的にすり替わる理由と、開発の仕事で起きやすい形、目的に戻すための問いが分かります。

手段の目的化とは、目的のために選んだはずの手段を、行うこと自体がねらいになってしまうことです。 グロービス経営大学院の用語集は「もともと、ある目的を実現するために手段を選択したはずなのに、その手段を実行すること自体が目的化してしまうこと」と定義しています。これは誰かの心がけの問題というより、仕事の進み方そのものに原因があります。

数字については、経済学者グッドハートの名で知られる指摘があります。人類学者のマリリン・ストラザーンは1997年の論文で、これを「When a measure becomes a target, it ceases to be a good measure（測るものが目標になると、良いものさしではなくなる）」と言い表しました。カバレッジやチケット数は役に立つものさしですが、それ自体をねらいにすると、もとの目的とずれていきます。

エンジニアの仕事での典型例

症状から目的に戻す問い

目的を言葉にする5つの問いとビフォー・アフター

この節では、頼まれた仕事の目的を1文にするための問いと、手段のままの目的文を直した例が分かります。

仕事は、たいてい手段の形で届きます。 「ログ集約を入れておいて」「レポートを作って」という頼まれ方がふつうで、目的は頼む側の頭の中にあります。次の5つの問いを順に当てると、目的が言葉になります。

1. 1何のためにやりますか最初の問い。答えが「〜を作るため」なら、まだ手段。もう一度問う
2. 2終わったあと、誰がどうなっていればよいですか目的を「人」と「状態」で言い直す。いちばん効く問い
3. 3それが叶わないと、何が困りますか困りごとが出てこなければ、やらなくてよい仕事かもしれない
4. 4どうなれば、果たしたと言えますか達成の基準。時間・件数・割合と、確かめ方を決める
5. 5今回やらないことは何ですか目的に効きの小さい作業を先に外す。途中で広がるのを防ぐ

目的文の型

答えは、次の型に入れると1文になります。

〈誰〉が、〈どんな場面で〉、〈何をできる／どうなっている〉ようにする
（いまは〈現状〉）。

例：問い合わせ対応の担当者が、電話中に、注文一覧を待たずに開いて
    注文を探せるようにする（いまは開くまで8秒、月末は20秒を超える）。

型のポイントは3つです。主語を「作る側」ではなく「使う側・受け取る側」にすること、文末を「〜ようにする」「〜できる状態にする」という状態にすること、かっこの中に現状を書いて差が分かるようにすることです。主語が「私たちが」「システムが」になったら、手段を書いている合図です。

ビフォー・アフター6組

目的から逆算する手順（5分でできる目的確認）

この節では、目的→達成の基準→手段→やらないこと、の順に決める手順と、依頼した人に送る確認メッセージの実物が分かります。

順番は「目的→達成の基準→手段→やらないこと→確認」です。 手段から書き始めると、思いついた手段に合わせて目的を後づけしてしまいます。上から順に決めると、下の段の迷いが減ります。

flowchart TD
  A["頼まれたこと<br>（たいてい手段の形で届く）"] --> B["1. 目的を1文にする<br>誰が・どうなっていればよいか"]
  B --> C["2. 達成の基準を決める<br>数字と確かめ方"]
  C --> D["3. 手段を並べる<br>目的に効く順"]
  D --> E["4. やらないことを書く"]
  E --> F["5. 依頼した人に確認する"]
  F -->|違っていた| B
  F -->|合っていた| G["着手"]

確認メッセージの実物（目的確認シートの出力）

「注文一覧の表示を速くして」と頼まれた場面を想定し、目的確認シートに6つの欄を書いて「依頼した人に送る確認メッセージ」を取り出しました。次がそのままの出力です。

「注文一覧の表示を速くする」の進め方を、目的から確認させてください。

目的：問い合わせ対応の担当者が、電話中に注文一覧を待たずに開いて注文を探せるようにする（いまは開くまで8秒、月末は20秒を超える）。
達成の基準：注文10万件の検証データで、一覧の表示が2秒以内。月末の件数でも3秒以内。
進め方：
1. 遅いSQLを実行計画で特定する
2. 検索条件の列に索引を足す
3. 一覧を50件ずつのページ分けにする
今回やらないこと：画面デザインの変更、検索以外の画面の高速化
期限：11月21日

この理解で合っていますか。目的や基準が違っていたら教えてください。

この文面のよい点は、相手が「はい」か「そこは違う」で答えられることです。「目的は何ですか」と白紙で聞くと相手は一から説明することになりますが、こちらの理解を先に書けば、相手は直すだけで済みます。たとえば「2秒でなくても5秒でよい」「画面デザインも今回やってほしい」という答えが返れば、着手前に手段が変わります。

同じ入力から取り出した「作業メモ（Markdown）」は次のとおりです。手段がチェックリストになるので、チケットの説明にそのまま使えます。

# 注文一覧の表示を速くする

## 目的
問い合わせ対応の担当者が、電話中に注文一覧を待たずに開いて注文を探せるようにする（いまは開くまで8秒、月末は20秒を超える）。

## 達成の基準
注文10万件の検証データで、一覧の表示が2秒以内。月末の件数でも3秒以内。

## 手段
- [ ] 遅いSQLを実行計画で特定する
- [ ] 検索条件の列に索引を足す
- [ ] 一覧を50件ずつのページ分けにする

## 今回やらないこと
- 画面デザインの変更
- 検索以外の画面の高速化

## 期限
11月21日

書きかけのときに出る「見直しのヒント」

わざと手段のままの目的を入れて、ヒントの文面を確かめました。

ヒントは文の形を見ているだけなので、内容が目的として妥当かどうかまでは判断しません。最後は、依頼した人の「合っています」で確かめます。

仕事を頼む側の書き方は、関連記事「仕事の任せ方と依頼テンプレート｜5W1Hと権限委譲レベル表」で扱っています。この記事は、頼まれた側が目的を確かめる方法を扱います。

数字で確かめる1：目的への効き÷時間で作業を並べ替える

この節では、作業一覧に「目的への効き」と「かかる時間」を付けて並べ替える方法と、効きが0の作業に使う時間の割合を計算した結果が分かります。

やり方は、作業ごとに「目的への効き」を0〜3の4段階で付け、時間で割るだけです。 効きの目安は、3＝これがないと目的を果たせない、2＝あると達成が確かになる、1＝あれば少し良い、0＝目的とは関係がない、です。ログ集約の導入を例に、架空の作業一覧12件で計算しました。

# 目的への効き（0〜3）÷ 時間 で作業を並べ替える（データは架空）
purpose = "障害調査で、原因のログを10分以内に見つけられる"
tasks = [  # (作業, 時間h, 効き0-3)
    ("転送エージェントを5台に入れる", 6, 3),
    ("時刻とリクエストIDで検索できるようにする", 4, 3),
    ("リクエストIDをアプリのログに出す", 3, 3),
    ("検証環境で2週間試し、探す時間を測る", 2, 3),
    ("保存期間を30日に設定する", 1, 2),
    ("探し方の手順を1ページにまとめる", 1, 2),
    ("アラートをチャットに流す", 3, 1),
    ("ログの形式を全サービスでJSONにそろえる", 10, 1),
    ("全サービスへ一斉に展開する", 12, 1),
    ("ダッシュボードの色とレイアウトを整える", 5, 0),
    ("製品比較表を20項目に広げる", 4, 0),
    ("導入報告のスライドを20枚作る", 4, 0),
]
total_h = sum(h for _, h, _ in tasks)
total_e = sum(e for _, _, e in tasks)
print(f"目的: {purpose}")
print(f"作業 {len(tasks)} 件 / 合計 {total_h} 時間 / 効きの合計 {total_e} 点\n")
print(f"{'順':>2} {'効き':>3} {'時間':>4} {'効き÷時間':>8} {'累計時間':>10} {'累計の効き':>10}  作業")
cum_h = cum_e = 0
rows = sorted(tasks, key=lambda t: (-t[2] / t[1], t[1]))
for i, (name, h, e) in enumerate(rows, 1):
    cum_h += h; cum_e += e
    print(f"{i:>2} {e:>4} {h:>5}h {e/h:>9.2f} {cum_h:>4}h({cum_h/total_h:>4.0%}) {cum_e:>3}点({cum_e/total_e:>4.0%})  {name}")
zero_h = sum(h for _, h, e in tasks if e == 0)
low_h = sum(h for _, h, e in tasks if e <= 1)
core_h = sum(h for _, h, e in tasks if e == 3)
print()
print(f"効き0の作業の時間: {zero_h}h / {total_h}h = {zero_h/total_h:.1%}")
print(f"効き0〜1の作業の時間: {low_h}h / {total_h}h = {low_h/total_h:.1%}")
print(f"効き3の作業だけの時間: {core_h}h / {total_h}h = {core_h/total_h:.1%}")
h80 = e80 = 0
for name, h, e in rows:
    h80 += h; e80 += e
    if e80 / total_e >= 0.8: break
print(f"効きの合計の80%以上に届く時点: {h80}h（全体の {h80/total_h:.1%}）で {e80}点（{e80/total_e:.1%}）")

実行結果です。

目的: 障害調査で、原因のログを10分以内に見つけられる
作業 12 件 / 合計 55 時間 / 効きの合計 19 点

 順  効き   時間    効き÷時間       累計時間      累計の効き  作業
 1    2     1h      2.00    1h(  2%)   2点( 11%)  保存期間を30日に設定する
 2    2     1h      2.00    2h(  4%)   4点( 21%)  探し方の手順を1ページにまとめる
 3    3     2h      1.50    4h(  7%)   7点( 37%)  検証環境で2週間試し、探す時間を測る
 4    3     3h      1.00    7h( 13%)  10点( 53%)  リクエストIDをアプリのログに出す
 5    3     4h      0.75   11h( 20%)  13点( 68%)  時刻とリクエストIDで検索できるようにする
 6    3     6h      0.50   17h( 31%)  16点( 84%)  転送エージェントを5台に入れる
 7    1     3h      0.33   20h( 36%)  17点( 89%)  アラートをチャットに流す
 8    1    10h      0.10   30h( 55%)  18点( 95%)  ログの形式を全サービスでJSONにそろえる
 9    1    12h      0.08   42h( 76%)  19点(100%)  全サービスへ一斉に展開する
10    0     4h      0.00   46h( 84%)  19点(100%)  製品比較表を20項目に広げる
11    0     4h      0.00   50h( 91%)  19点(100%)  導入報告のスライドを20枚作る
12    0     5h      0.00   55h(100%)  19点(100%)  ダッシュボードの色とレイアウトを整える

効き0の作業の時間: 13h / 55h = 23.6%
効き0〜1の作業の時間: 38h / 55h = 69.1%
効き3の作業だけの時間: 15h / 55h = 27.3%
効きの合計の80%以上に届く時点: 17h（全体の 30.9%）で 16点（84.2%）

この架空の一覧では、全体の30.9%の時間（17時間）で、効きの合計の84.2%に届きました。 残りの38時間は、効きが0か1の作業です。読み取れることは3つあります。

• 効きが0の作業は、手を抜くのではなく「今回やらないこと」に移します。 比較表を20項目に広げる、報告のスライドを20枚作る、ダッシュボードの見た目を整える、の3件・13時間は、「原因のログを10分以内に見つける」には効きません。別の目的（関係者に説明する、など）があるなら、その目的の仕事として分けて扱います。
• 時間が大きく効きが1の作業が、いちばん見落としやすい所です。 全サービスへの一斉展開（12時間）とログ形式の統一（10時間）は、やる意味はありますが、今回の基準（検証環境で10分以内）には要りません。基準を果たしてから次の仕事にします。
• 順位の上位は、小さくて効く作業でした。 保存期間の設定と探し方の手順（各1時間・効き2）が先頭に来ます。大きな作業から手を付けたくなりますが、並べ替えると着手の順番が変わります。

効きの点数は主観で、人によって1点ずれます。それでも0点かどうかは、たいてい意見が一致します。 点数を細かく争うより、0点の作業を見つけて外すことに使うのが向いています。優先順位の付け方そのものは、関連記事「意思決定フレームワーク一覧｜決め方の選び方と意思決定マトリクス例」で扱っています。

数字で確かめる2：最初に5分確認する場合と、確認せず着手する場合

この節では、目的を確かめる5分が手間に見合うかどうかを、かかる時間の期待値で比べた結果と、見合うかどうかの境目が分かります。

比べ方は単純です。 目的を取り違えたまま進むと、作業の一部がやり直しになります。確認にも時間がかかり、確認しても取り違えが残ることがあります。この3つを仮の値で置いて、期待値を計算します。

どの値も調査にもとづく数字ではなく、計算のために置いた仮の値です。自分の仕事の感覚に合わせて置き直せるよう、コードを載せます。

# 目的を確かめずに着手する場合と、最初に5分確かめる場合の、かかる時間の期待値（確率は仮の値）
import random
C = 5 / 60          # 確認にかかる時間（5分）
R = 0.5             # 目的を取り違えたとき、やり直しになる割合（作業時間の半分）
D = 0.8             # 5分の確認で取り違えに気づける割合（確認しても2割は残る）
def no_check(w, p):  return w + p * R * w
def check(w, p):     return C + w + p * (1 - D) * R * w
print(f"前提: 確認 {C*60:.0f}分 / やり直しの割合 R={R} / 確認で気づける割合 D={D}\n")
print(f"{'作業時間':>6} {'取り違えの確率':>8} {'確認なし':>8} {'5分確認':>8} {'差':>8} {'確認が有利':>6}")
for w in (0.25, 2, 8, 40):
    for p in (0.02, 0.05, 0.10, 0.20, 0.30, 0.50):
        a, b = no_check(w, p), check(w, p)
        print(f"{w:>8}h {p:>12.0%} {a:>10.2f}h {b:>8.2f}h {(a-b)*60:>+8.0f}分 {'はい' if a > b else 'いいえ':>6}")
    print()
print("損益分岐の確率 p* = 確認の時間 ÷ (D × R × 作業時間)")
for w in (0.25, 0.5, 1, 2, 4, 8, 16, 40):
    ps = C / (D * R * w)
    print(f"  作業 {w:>5}h → p* = {ps:>6.1%}" + ("（100%を超える＝確認しても元が取れない）" if ps > 1 else ""))
# 式の検算: 乱数で20万回ためす
random.seed(343)
w, p, n = 8, 0.20, 200_000
sa = sb = 0.0
for _ in range(n):
    wrong = random.random() < p
    sa += w + (R * w if wrong else 0)
    caught = wrong and random.random() < D
    sb += C + w + (R * w if (wrong and not caught) else 0)
print(f"\n検算（作業8h・確率20%・{n:,}回の試行）: 確認なし 平均 {sa/n:.3f}h（式 {no_check(w,p):.3f}h） / 5分確認 平均 {sb/n:.3f}h（式 {check(w,p):.3f}h）")
# 確認の精度が低い場合
print("\n確認で気づける割合 D を変えた場合（作業8h・確率20%）")
for d in (0.2, 0.5, 0.8, 1.0):
    b = C + 8 + 0.20 * (1 - d) * R * 8
    print(f"  D={d:.1f}: 5分確認 {b:.2f}h / 確認なし {no_check(8,0.20):.2f}h / 差 {(no_check(8,0.20)-b)*60:+.0f}分")

実行結果です。

前提: 確認 5分 / やり直しの割合 R=0.5 / 確認で気づける割合 D=0.8

  作業時間  取り違えの確率     確認なし     5分確認        差  確認が有利
    0.25h           2%       0.25h     0.33h       -5分    いいえ
    0.25h           5%       0.26h     0.33h       -5分    いいえ
    0.25h          10%       0.26h     0.34h       -4分    いいえ
    0.25h          20%       0.28h     0.34h       -4分    いいえ
    0.25h          30%       0.29h     0.34h       -3分    いいえ
    0.25h          50%       0.31h     0.35h       -2分    いいえ

       2h           2%       2.02h     2.09h       -4分    いいえ
       2h           5%       2.05h     2.09h       -3分    いいえ
       2h          10%       2.10h     2.10h       -0分    いいえ
       2h          20%       2.20h     2.12h       +5分     はい
       2h          30%       2.30h     2.14h       +9分     はい
       2h          50%       2.50h     2.18h      +19分     はい

       8h           2%       8.08h     8.10h       -1分    いいえ
       8h           5%       8.20h     8.12h       +5分     はい
       8h          10%       8.40h     8.16h      +14分     はい
       8h          20%       8.80h     8.24h      +33分     はい
       8h          30%       9.20h     8.32h      +53分     はい
       8h          50%      10.00h     8.48h      +91分     はい

      40h           2%      40.40h    40.16h      +14分     はい
      40h           5%      41.00h    40.28h      +43分     はい
      40h          10%      42.00h    40.48h      +91分     はい
      40h          20%      44.00h    40.88h     +187分     はい
      40h          30%      46.00h    41.28h     +283分     はい
      40h          50%      50.00h    42.08h     +475分     はい

損益分岐の確率 p* = 確認の時間 ÷ (D × R × 作業時間)
  作業  0.25h → p* =  83.3%
  作業   0.5h → p* =  41.7%
  作業     1h → p* =  20.8%
  作業     2h → p* =  10.4%
  作業     4h → p* =   5.2%
  作業     8h → p* =   2.6%
  作業    16h → p* =   1.3%
  作業    40h → p* =   0.5%

検算（作業8h・確率20%・200,000回の試行）: 確認なし 平均 8.799h（式 8.800h） / 5分確認 平均 8.242h（式 8.243h）

確認で気づける割合 D を変えた場合（作業8h・確率20%）
  D=0.2: 5分確認 8.72h / 確認なし 8.80h / 差 +5分
  D=0.5: 5分確認 8.48h / 確認なし 8.80h / 差 +19分
  D=0.8: 5分確認 8.24h / 確認なし 8.80h / 差 +33分
  D=1.0: 5分確認 8.08h / 確認なし 8.80h / 差 +43分

作業が8時間で取り違えの確率が20%なら、確認なしの期待値は8.80時間、5分確認すると8.24時間で、差は33分でした。乱数で20万回ためした平均（8.799時間と8.242時間）も式と合っています。境目だけを抜き出すと次のとおりです。

境目の式は p* = C ÷ (D × R × 作業時間) です。ここから、目的確認の使いどころが数字で言えます。

• 作業が長いほど、確認は見合います。 境目の確率は作業時間に反比例します。1日かかる仕事なら、40回に1回の取り違えでも元が取れます。
• 短い作業では、確認が損になります。 15分の作業に5分の確認を毎回足すのは、この前提では見合いません。「何でも目的を聞く」が正解ではない、ということです。
• 確認の質が低くても、長い作業なら得です。 気づける割合 D を0.2まで下げても、8時間・20%の場合の差は＋5分でした。上手に聞けなくても、聞く意味は残ります。
• この計算に入っていない効果もあります。 やり直しは自分の時間だけでなく、レビューした人や待っている人の時間も使います。その分は入れていないので、差は控えめに出ています。

数字で確かめる3：同じ「テストを自動化する」でも目的で選ぶテストが変わる

この節では、同じ10本のテスト候補から、目的ごとに最もよい組み合わせを選ぶと中身がどれだけ変わるかを、小さなデータで計算した結果が分かります。

「テストを自動化する」は手段です。 目的が「リリース前の確認時間を減らす」なら、手で確かめている作業を置き換えるテストが効きます。目的が「壊れたことに早く気づく」なら、短い時間で回り、不具合をよく見つけるテストが効きます。架空の10本で、次の3通りを選び分けました。

Cは目的ではなく、ものさしをねらいにした場合です。組み合わせは1,024通りしかないので、全部を調べて最もよいものを選びます。通る行数は、テスト同士で重ならないものとして足しています。

# 同じ「テストを自動化する」でも、目的で選ぶテストが変わる（データは架空）
from itertools import combinations
# (ID, テスト, 実行秒, 直近90日に見つけた不具合の数, リリース1回で置き換わる手作業の確認(分), 作る時間h, 通る行数)
T = [
    ("T1", "金額計算の単体テスト",            4, 6,  5,  3,  400),
    ("T2", "入力チェックの単体テスト",        3, 4,  5,  2,  350),
    ("T3", "注文APIの結合テスト",            40, 5, 20,  6,  900),
    ("T4", "在庫引当の結合テスト",           55, 3, 15,  6,  700),
    ("T5", "ログインから購入までのE2E",     240, 2, 45, 10, 1500),
    ("T6", "管理画面のE2E",                 300, 1, 40, 12, 1300),
    ("T7", "帳票PDFの見た目の比較",         180, 1, 35,  8,  300),
    ("T8", "設定ファイル読み込みのテスト",    2, 2,  0,  1,  150),
    ("T9", "メール文面のスナップショット",   20, 0, 25,  3,  200),
    ("T10", "値の出し入れだけの処理のテスト", 5, 0,  0,  2, 1200),
]
SEC, BUG, MAN, BUILD, LINES = 2, 3, 4, 5, 6
tot = {k: sum(t[k] for t in T) for k in (SEC, BUG, MAN, BUILD, LINES)}
print(f"全10本: 実行 {tot[SEC]}秒 / 不具合 {tot[BUG]}件 / 手作業の置き換え {tot[MAN]}分 / 作る時間 {tot[BUILD]}h / {tot[LINES]}行\n")
def best(value, cost, budget):
    top = None
    for r in range(len(T) + 1):
        for c in combinations(T, r):
            cs = sum(t[cost] for t in c)
            if cs > budget: continue
            key = (sum(t[value] for t in c), -cs)
            if top is None or key > top[0]: top = (key, c)
    return top[1]
def show(label, c):
    ids = " ".join(t[0] for t in c)
    s = {k: sum(t[k] for t in c) for k in (SEC, BUG, MAN, BUILD, LINES)}
    print(f"{label}\n  選んだテスト: {ids}")
    print(f"  実行 {s[SEC]}秒 / 作る時間 {s[BUILD]}h / 見つけた不具合 {s[BUG]}件（{s[BUG]/tot[BUG]:.0%}） / "
          f"手作業の置き換え {s[MAN]}分（{s[MAN]/tot[MAN]:.0%}） / {s[LINES]}行（{s[LINES]/tot[LINES]:.0%}）\n")
    return s
print("並べ替え1: 置き換わる手作業(分) ÷ 作る時間(h)   ← 目的A「リリース前の確認時間を減らす」")
for t in sorted(T, key=lambda t: -t[MAN] / t[BUILD]): print(f"  {t[0]:<4}{t[MAN]/t[BUILD]:>6.2f}  {t[1]}")
print("並べ替え2: 見つけた不具合(件) ÷ 実行(分)         ← 目的B「壊れたことに早く気づく」")
for t in sorted(T, key=lambda t: -t[BUG] / (t[SEC] / 60)): print(f"  {t[0]:<4}{t[BUG]/(t[SEC]/60):>6.1f}  {t[1]}")
print("並べ替え3: 通る行数 ÷ 作る時間(h)               ← 数字C「カバレッジを上げる」")
for t in sorted(T, key=lambda t: -t[LINES] / t[BUILD]): print(f"  {t[0]:<4}{t[LINES]/t[BUILD]:>6.0f}  {t[1]}")
print()
A = best(MAN, BUILD, 24)   # 作る時間24h以内で、手作業の置き換えを最大に
B = best(BUG, SEC, 120)    # pushごとに2分以内で回る範囲で、見つかる不具合を最大に
C = best(LINES, BUILD, 24) # 作る時間24h以内で、通る行数を最大に
sa = show("目的A: リリース前の確認時間を減らす（作る時間24h以内で、置き換わる手作業を最大に）", A)
sb = show("目的B: 壊れたことに早く気づく（pushごとに120秒以内で、見つかる不具合を最大に）", B)
sc = show("数字C: カバレッジを上げる（作る時間24h以内で、通る行数を最大に）", C)
ia, ib, ic = ({t[0] for t in x} for x in (A, B, C))
jac = lambda x, y: len(x & y) / len(x | y)
print(f"AとBの重なり: {sorted(ia & ib)} / 一致度（共通÷どちらかにある） {jac(ia, ib):.0%}")
print(f"AとCの重なり: {sorted(ia & ic)} / 一致度 {jac(ia, ic):.0%}")
print(f"BとCの重なり: {sorted(ib & ic)} / 一致度 {jac(ib, ic):.0%}")
print(f"\n目的Bなのに Aの選び方をした場合: 実行 {sa[SEC]}秒（120秒の {sa[SEC]/120:.1f}倍）、見つかる不具合 {sa[BUG]}件 → Bの選び方 {sb[BUG]}件の {sa[BUG]/sb[BUG]:.0%}")
print(f"目的Aなのに Bの選び方をした場合: 置き換わる手作業 {sb[MAN]}分 → Aの選び方 {sa[MAN]}分の {sb[MAN]/sa[MAN]:.0%}")
print(f"数字Cを目的にした場合: 見つかる不具合 {sc[BUG]}件（Bの {sc[BUG]/sb[BUG]:.0%}）、置き換わる手作業 {sc[MAN]}分（Aの {sc[MAN]/sa[MAN]:.0%}）、行数は {sc[LINES]}行で最大")

実行結果です。

全10本: 実行 849秒 / 不具合 24件 / 手作業の置き換え 190分 / 作る時間 53h / 7000行

並べ替え1: 置き換わる手作業(分) ÷ 作る時間(h)   ← 目的A「リリース前の確認時間を減らす」
  T9    8.33  メール文面のスナップショット
  T5    4.50  ログインから購入までのE2E
  T7    4.38  帳票PDFの見た目の比較
  T3    3.33  注文APIの結合テスト
  T6    3.33  管理画面のE2E
  T2    2.50  入力チェックの単体テスト
  T4    2.50  在庫引当の結合テスト
  T1    1.67  金額計算の単体テスト
  T8    0.00  設定ファイル読み込みのテスト
  T10   0.00  値の出し入れだけの処理のテスト
並べ替え2: 見つけた不具合(件) ÷ 実行(分)         ← 目的B「壊れたことに早く気づく」
  T1    90.0  金額計算の単体テスト
  T2    80.0  入力チェックの単体テスト
  T8    60.0  設定ファイル読み込みのテスト
  T3     7.5  注文APIの結合テスト
  T4     3.3  在庫引当の結合テスト
  T5     0.5  ログインから購入までのE2E
  T7     0.3  帳票PDFの見た目の比較
  T6     0.2  管理画面のE2E
  T9     0.0  メール文面のスナップショット
  T10    0.0  値の出し入れだけの処理のテスト
並べ替え3: 通る行数 ÷ 作る時間(h)               ← 数字C「カバレッジを上げる」
  T10    600  値の出し入れだけの処理のテスト
  T2     175  入力チェックの単体テスト
  T3     150  注文APIの結合テスト
  T5     150  ログインから購入までのE2E
  T8     150  設定ファイル読み込みのテスト
  T1     133  金額計算の単体テスト
  T4     117  在庫引当の結合テスト
  T6     108  管理画面のE2E
  T9      67  メール文面のスナップショット
  T7      38  帳票PDFの見た目の比較

目的A: リリース前の確認時間を減らす（作る時間24h以内で、置き換わる手作業を最大に）
  選んだテスト: T2 T5 T7 T9
  実行 443秒 / 作る時間 23h / 見つけた不具合 7件（29%） / 手作業の置き換え 110分（58%） / 2350行（34%）

目的B: 壊れたことに早く気づく（pushごとに120秒以内で、見つかる不具合を最大に）
  選んだテスト: T1 T2 T3 T4 T8
  実行 104秒 / 作る時間 18h / 見つけた不具合 20件（83%） / 手作業の置き換え 45分（24%） / 2500行（36%）

数字C: カバレッジを上げる（作る時間24h以内で、通る行数を最大に）
  選んだテスト: T1 T2 T3 T5 T8 T10
  実行 294秒 / 作る時間 24h / 見つけた不具合 19件（79%） / 手作業の置き換え 75分（39%） / 4500行（64%）

AとBの重なり: ['T2'] / 一致度（共通÷どちらかにある） 12%
AとCの重なり: ['T2', 'T5'] / 一致度 25%
BとCの重なり: ['T1', 'T2', 'T3', 'T8'] / 一致度 57%

目的Bなのに Aの選び方をした場合: 実行 443秒（120秒の 3.7倍）、見つかる不具合 7件 → Bの選び方 20件の 35%
目的Aなのに Bの選び方をした場合: 置き換わる手作業 45分 → Aの選び方 110分の 41%
数字Cを目的にした場合: 見つかる不具合 19件（Bの 95%）、置き換わる手作業 75分（Aの 68%）、行数は 4500行で最大

読み取れることを4つ挙げます。

• AとBで共通して選ばれたのは T2 の1本だけで、一致度は12%でした。 同じ「テストを自動化する」でも、目的が違うと中身はほぼ別物になります。
• 目的を取り違えると、達成は半分以下になりました。 目的がBなのにAの選び方をすると、見つかる不具合は7件（Bの選び方の35%）で、実行時間は443秒と制約の3.7倍です。逆に、目的がAなのにBの選び方をすると、置き換わる手作業は45分（41%）にとどまります。
• 数字Cは、悪くはないが、どちらの目的にも合い切りません。 行数は4,500行で最大になり、不具合も19件見つけますが、実行は294秒で push ごとの120秒に収まらず、手作業の置き換えは75分（Aの68%）です。そして、不具合も手作業の置き換えも0の T10 に2時間を使っています。数字を追うと「効きが0でも数字が伸びる作業」が入り込む、という形がここに出ています。
• 並べ替えの先頭が、目的ごとに違います。 目的Aの先頭は T9（メール文面のスナップショット）、目的Bの先頭は T1（金額計算の単体テスト）、数字Cの先頭は T10（値の出し入れだけの処理）でした。「どのテストから書くか」という最初の一歩が、目的で変わります。

実際の仕事では、AとBの両方が目的になることもあります。そのときは、Bの組（push ごと）とAの組（リリース前）を分けて回す、という設計になります。目的を分けて書くと、手段も分けて設計できます。

場面別の使い方（要件・レビュー・障害対応・見積もり・会議・資料）

この節では、仕事の場面ごとに、目的を確かめる一言と、合目的的でない例を直した例が分かります。

場面が変わっても、問うことは同じです。 「この作業は、誰がどうなるためのものか」を、その場面の言葉で聞きます。

障害対応の行は、目的に順番があることを表しています。障害の最中の目的は「利用者が使える状態に戻す」で、原因を知ることはその次です。場面ごとに「いまの目的は何か」を声に出すだけで、判断が速くなります。

障害のあとに原因を掘り下げる方法は、関連記事「なぜなぜ分析のやり方｜システム障害の例とテンプレート」で扱っています。

生成AIと目的（手段だけを頼むと起きること・指示の型）

この節では、生成AIに仕事を頼むときに目的と達成の基準を渡す理由と、そのまま使える指示の文面が分かります。

生成AIは、頼まれた手段を速く、ていねいに仕上げます。 そのため、手段だけを渡すと、手段の目的化が人よりも速く進みます。「ログ集約の設定ファイルを書いて」と頼めば設定ファイルは出てきますが、その設定が「原因のログを10分以内に見つける」に合っているか、もっと小さな手間で済む方法がないかは、目的を渡していなければ確かめようがありません。

目的と基準を渡す指示の実物（目的確認シートの出力）

先ほどの「注文一覧の表示を速くする」の入力から、「生成AIへの指示」を取り出しました。次がそのままの出力です。

次の仕事を手伝ってください。手段の提案よりも先に、目的と達成の基準に照らして考えてください。

# やること
注文一覧の表示を速くする

# 目的
問い合わせ対応の担当者が、電話中に注文一覧を待たずに開いて注文を探せるようにする（いまは開くまで8秒、月末は20秒を超える）。

# 達成の基準
注文10万件の検証データで、一覧の表示が2秒以内。月末の件数でも3秒以内。

# いま考えている手段
- 遅いSQLを実行計画で特定する
- 検索条件の列に索引を足す
- 一覧を50件ずつのページ分けにする

# 今回やらないこと
- 画面デザインの変更
- 検索以外の画面の高速化

# 期限
11月21日

# お願い
1. 目的に対して、手段に抜けや余分がないかの指摘をお願いします。
2. 目的をもっと小さな手間で果たせる別の手段があれば、理由と一緒に挙げてください。
3. 達成の基準があいまいなら、確かめられる形に言い換える案をお願いします。

この指示は、手段を作らせる前に、手段そのものを目的と基準に照らして見直させる形になっています。たとえば「索引を足す前に、一覧の初期表示の件数を絞るだけで2秒に収まらないか」といった別案を引き出すための聞き方です。返ってきた案をそのまま使うのではなく、目的と基準に照らして人が選びます。なお、この記事では指示の文面を取り出したところまでを確かめており、生成AIに送った結果は測っていません。業務の情報を生成AIに渡すときは、使うサービスの提供元の最新の規約と、所属先の決まりを事前に確かめることをおすすめします。

AI駆動開発で人が持つもの

コードを書く速さが上がるほど、「何を書かせるか」を決める部分が仕事の中心に残ります。AI駆動開発で人が持つべきものは、目的と達成の基準です。 手段は AI と一緒に何通りも出せますが、どれが合目的的かを決めるものさしは、目的を知っている人にしか置けません。目的確認シートの6つの欄は、そのまま AI に渡す仕様の最小単位になります。

指示の書き方そのもの（例示・役割・出力形式）は、関連記事「生成AIプロンプトのコツ8選｜例示・役割・出力形式」で扱っています。

近い考え方との違い（イシュー・仮説思考・なぜなぜ分析・OKRなど）

この節では、目的から考えることと、名前の似た考え方・枠組みとの関係と使い分けが分かります。

どれも対立するものではなく、答える問いが違います。 目的ドリブンは「何のためにやるか」を最初に置く進め方で、ほかの考え方は、その前後で使う道具として組み合わせられます。優劣はなく、場面で選びます。

「なぜ」という同じ言葉でも、なぜなぜ分析の「なぜ（原因）」と、目的を問う「なぜ（何のために）」は向きが逆です。目的を聞くつもりで「なぜやるのですか」と言うと、理由を問いただされたように聞こえることがあるので、「何のために」「終わったあと、どうなっていればよいですか」と言い換えると伝わりやすくなります。

チームの目的と基準をそろえる方法は、関連記事「OKRの書き方とエンジニア向けの例｜KPIとの違いとスコア計算」で、目的から手段へ枝分かれさせて書き出す方法は、関連記事「ロジックツリーの作り方と例｜Why・How・Whatの違いとMECE切り口一覧」で扱っています。

目的を考えるときのつまずきと直し方

この節では、目的を確かめようとして止まりやすい所と、その直し方が分かります。

「目的が複数ある」は、いちばんよく起きます。テストの計算で見たとおり、2つの目的を1つの手段でまとめて果たそうとすると、どちらにも合い切らない組み合わせになりがちです。目的を分けて書き、手段も分けると、それぞれが小さく済みます。

どこまでさかのぼるかの判断表と、目的にこだわりすぎない場面

この節では、「何のために」を何段さかのぼれば足りるかの目安と、目的確認を省いてよい場面が分かります。

「何のために」は、問い続けるといくらでも上に行けます。 ログ集約→障害を早く直す→利用者の信頼→事業の継続、とさかのぼれますが、上に行くほど手段の選び方には影響しなくなります。止める目安は次の3つです。

• 手段の選び方が変わらなくなったら止める。 もう1段上を聞いても、選ぶ手段が同じなら、それ以上は要りません。
• 達成の基準が言える段で止める。 「利用者の信頼」には今週の基準が置けませんが、「原因のログを10分以内に見つける」には置けます。
• 自分と依頼した人で決められる範囲を超えたら止める。 それより上は、知っておく背景として1行で書けば足ります。

目的にこだわりすぎない場面

目的から考えることは万能ではありません。次の場面では、目的確認を省くか、あとに回すほうが合目的的です。

• すぐ終わる定型作業：15分の作業に5分の確認は、計算上も見合いません。手順が決まっていて結果を元に戻せる作業は、そのまま進めます。
• 緊急の復旧：目的は「使える状態に戻す」と決まっています。その場で「そもそも」をさかのぼらず、復旧のあとで振り返ります。
• 試してみないと分からない仕事：調査や試作は、目的を固める材料を集める段階です。「2時間だけ試し、分かったことで目的を書き直す」と時間で区切ります。
• 目的がすでに共有されている繰り返しの仕事：毎週同じ目的で回している作業は、目的が変わったときだけ確かめ直します。

目的を問うこと自体も手段です。「目的を確認すること」が目的になっていないかも、同じものさし（効き÷時間）で見ます。

よくある質問

Q. 目的ドリブンとは何ですか？ A. 仕事を「何のためか（目的）」から決め、達成の基準・手段・やらないことの順に逆算する考え方です。「ドリブン（driven）」は「〜に駆動される」という意味で、データドリブンと同じ形の言葉です。

Q. 合目的的の読み方と意味は？ A. 「ごうもくてきてき」と読みます。デジタル大辞泉は「ある物事が一定の目的にかなっているさま」と説明しています。「合目的的な設計」のように、手段が目的に合っていることを表すときに使います。

Q. 合目的と合目的的の違いは？ A. 辞書の語釈はほぼ同じで、デジタル大辞泉は互いを類語として挙げています。「合目的な」とも「合目的的な」とも言えますが、今の文章では「合目的的」と、名詞の「合目的性」がよく使われます。

Q. 目的と目標の違いは？ A. 目的は「何のために」、目標は「どこまで」です。デジタル大辞泉は、目的は抽象的で長期にわたり内容に重点があり、目標は地点・数値・数量などに重点があってより具体的だと説明しています。この記事では目標を「達成の基準」と呼んでいます。

Q. 手段の目的化とは何ですか？ A. 目的のために選んだ手段を、行うこと自体がねらいになってしまうことです。手段は目に見え、数えやすく、引き継がれやすく、完了が言えるために起きます。「終わったあと、誰の何が変わったか」と問うと目的に戻れます。

Q. 目的を聞くと、失礼になりませんか？ A. 白紙で「目的は何ですか」と聞くと、相手に説明の手間をかけます。自分の理解を先に書き、「この理解で合っていますか」と確かめる形にすると、相手は直すだけで済みます。目的確認シートの確認メッセージはこの形になっています。

Q. 目的が複数あるときは、どうしますか？ A. 目的ごとに達成の基準を書き、ぶつかるときにどちらを先にするかを依頼した人に決めてもらいます。記事のテストの計算では、2つの目的で選ぶテストの一致度が12%でした。目的を分けると、手段も分けて設計できます。

Q. 「何のために」は、どこまでさかのぼればよいですか？ A. 手段の選び方が変わらなくなる段、達成の基準が言える段、自分と依頼した人で決められる範囲、のどれかに当たったら止めます。日々のタスクなら1つ上、設計やツール選びなら2つ上が目安です。

Q. 小さな作業でも、毎回目的を確かめるのですか？ A. いいえ。記事の仮の前提（確認5分・やり直しは作業の半分・確認で8割気づく）では、15分の作業は取り違えの確率が83.3%を超えないと見合いません。1日かかる仕事は2.6%で見合うので、長い仕事ほど確かめる意味があります。

Q. 生成AIに頼むとき、目的まで書く意味はありますか？ A. あります。手段だけを渡すと、その手段の中だけで答えが返り、目的に合っているかを確かめる材料がありません。目的・達成の基準・やらないことを渡し、手段の抜けや余分、もっと小さな手間の別案を先に聞くと、作らせる前に手段を見直せます。

Q. データドリブンとの違いは？ A. 起点が違います。データドリブンは「データをもとに決める」、目的ドリブンは「目的から決める」です。両立するもので、目的と達成の基準を先に決め、基準を果たせたかをデータで確かめる、という順に組み合わせます。

Q. 『目的ドリブンの思考法』という本と、この記事の関係は？ A. 同じ言葉を題名にした書籍（望月安迪 著、ディスカヴァー・トゥエンティワン、2022年）があります。この記事は、エンジニアの仕事に合わせて問いの型・計算・判断表を独自に組み立てたもので、書籍の内容をまとめたものではありません。

まとめ

• 目的ドリブンは、目的→達成の基準→手段→やらないこと、の順に決める進め方。合目的的（ごうもくてきてき）は、手段が目的にかなっているさまを表す言葉。
• 仕事は手段の形で届く。「終わったあと、誰がどうなっていればよいか」を1文にし、自分の理解を書いて「この理解で合っていますか」と確かめる。
• 手段の目的化は、手段が見える・数えやすい・引き継がれる・完了が言える、というしくみで起きる。数字がねらいに替わったら、もとの目的と並べて書き直す。
• 架空のデータでの計算では、効き0の作業が時間の23.6%を占め、30.9%の時間で効きの84.2%に届いた。目的が違うと、同じ10本から選ぶテストの一致度は12%だった。
• 5分の確認は、8時間の仕事なら取り違えの確率2.6%で見合い、15分の作業では見合わない。長い仕事・手段の選択肢が多い仕事で使い、定型作業と緊急の復旧では省く。

最初の一歩は、いま手元にある仕事を1つ選び、ページ上部の目的確認シートに6つの欄を書いて、確認メッセージを送ってみることです。

参考・出典

確認日はいずれも 2026年11月11日です。

• コトバンク「合目的的」（デジタル大辞泉・精選版 日本国語大辞典）：https://kotobank.jp/word/合目的的-497615
• コトバンク「合目的」（デジタル大辞泉・精選版 日本国語大辞典）：https://kotobank.jp/word/合目的
• コトバンク「目的」（デジタル大辞泉。目的と目標の用法）：https://kotobank.jp/word/目的
• コトバンク「手段」（デジタル大辞泉・精選版 日本国語大辞典）：https://kotobank.jp/word/手段-528794
• Cambridge Dictionary「driven」（Business English）：https://dictionary.cambridge.org/dictionary/english/driven
• 株式会社ディスカヴァー・トゥエンティワンの発表（PR TIMES、2022年3月27日）「VUCA時代に望む成果を得る思考法とは？新進気鋭の戦略コンサルタントの思考の「型」を徹底解説した『目的ドリブンの思考法』発売」：https://prtimes.jp/main/html/rd/p/000000812.000018193.html
• 望月安迪『目的ドリブンの思考法』ディスカヴァー・トゥエンティワン、2022年（ISBN 978-4-7993-2831-6）
• グロービス経営大学院 MBA用語集「手段の目的化」：https://mba.globis.ac.jp/about_mba/glossary/detail-12279.html
• Wikipedia（英語版）「Goodhart's law」（Strathern, M. (1997) "'Improving ratings': audit in the British University system", European Review, 5(3) の一文の出どころを確認）：https://en.wikipedia.org/wiki/Goodhart%27s_law

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。