■ 1. 仕事が止まる理由の捉え方
- 手順への期待:
- プログラマーとして、仕事にも名前をつけて、分けて、手続きにしたくなる
- 手順どおりに進めれば、何かよい結果に近づけるはずだと思ってしまう
- 止まる理由の言語化:
- 同じ「進まない」でも、終わりが見えないのか、一歩が大きいのか、人に見せるのが怖いのかは異なる
- 止まっている理由を言葉にすると、次に何を変えるかを考えられる
- 手順があると、進んだところと、まだ止まっているところを話しやすくなる
- 手順の事後的な見直し:
- 手順を決めた時点では、相手の事情まで全部わかっているわけではない
- 進めた結果を見て、足りなかった前提や、変えたほうがよい手順を探す
- 擬似完了感:
- 準備に時間を使ったことを、完了に近づいたことと取り違える場合がある
- 資料が増え、体裁が整っても、相手が必要とする結論や根拠が欠けていることがある
- 時間や作業量だけで進み具合を測らないために、この区別を使う
- 他者的完了:
- 自分が十分だと感じる自分的完了と、相手が次へ進めると判断する他者的完了を区別する
- 誰が何に使うかを確かめ、判断に必要な材料を終了条件に入れる
- 全員を満足させる必要はなく、受け手が明日の自分でもよい
■ 2. 終わらせるための5ステップ
- 5ステップの位置づけ:
- 相手が次へ進めるところまで仕事を運ぶため、決めろ、分けろ、始めろ、出せ、回せの5手順を定義した
- 順番を一度守れば終わるという保証ではなく、止まった理由に応じて戻り、進め方を変えるための手順
- 決めろ:
- 「十分に調べる」だけでは、調べるほど対象が広がり、出す時点を選べない
- いつまでに、どこまで、何ができていればよいかを、まず仮に決める
- 例として、明日の打ち合わせに向け、候補2つの違いと選ぶ理由を1枚にすると決めてみる
- その条件で相手が判断できるかを確かめ、前提が違ったら理由を残して見直す
- 分けろ:
- 終わりを決めても、「設計する」「調査する」では何から手をつければよいかわからない
- 何がわからないかで、次の一歩は変わる
- ゴールが不明なら受け手に期待を聞き、方法が見えないならやり方を一つ調べ、できるか不安なら小さく試す
- 「調査する」を「判断できていない点を書き出す」へ変え、何を開き何をすればよいか選べる大きさにする
- 始めろ:
- 一歩を小さくしても、資料を探し、道具を開き、通知を見る間に取りかかりが遅れる
- 次の一歩に使うファイルを開き、必要な資料を隣に置き、気が散る通知は止める
- やる気だけに頼らず、始めるまでに探したり迷ったりする手間を減らす
- 準備は、今の一歩を実行できるところで区切る
- 出せ:
- 直せる所を探し続けると、いつまでも人へ渡せないため、出す水準を60点と呼ぶ
- 60点とは、相手が次の行動や判断を選べる状態
- 方向性を見てもらう資料なら、結論・根拠・迷っている点がわかれば、相手は修正点を返せる
- 誤りを4割残してよいという意味ではなく、渡す目的に応じて範囲を絞り、その範囲の条件を満たす
- 回せ:
- 出すと、作る側だけでは気づけなかった相手の困りごとが見えてくる
- 指摘を受けて落ち込むだけでも、言われた文面を直すだけでも、次の迷いが残る
- 「わかりにくい」なら、結論が見えないのか、比較材料が足りないのかを確かめる
- 相手の反応を受けて、何をいつ変えるかを決めるのが回せ
■ 3. AIがあっても終わりが見えない理由
- 終了条件の曖昧さ:
- 作る力が増すほど、何をもって終えるかを決めたくなる
- 終了条件が曖昧なまま案を追加すれば、AIが手伝っても終わりは遠のく
- エージェントの位置づけ:
- エージェントは、道具を使い、結果を見て作業を進めるAI
- 作成だけでなく、比較・確認・組み合わせる作業も任せられる
- 共有するものは、目標・終了条件・任せる範囲の3つ
- 任せる前に、条件を満たしたと何で確かめるか、どこまで変更してよいかを決める
- 任せた範囲を越えるときは、結果と相談したい点を返してもらう
- 一手ずつ指示する手間を減らし、任せた結果を使うところまで自分の仕事として進める
- 作れる時代ほど問われる終える力:
- AIに「もう少し良くして」と頼むたび、別の案が出てくる
- 試す負担が小さくなるほど、「もう作れないから終わり」とは区切りにくくなる
- 「改善案が尽きたら完了」では、良い案を見つける力が、そのまま終わりを遠ざける
- 今回の相手に何が必要か、何を見送るか、その比較と採用もAIと進めたい
■ 4. 決めろ: 目的と任せる範囲の共有
- 何を作るかの前に何を解決するか:
- AIが5ページの資料を作れても、費用と期待する効果がなければ、予算を判断する仕事は止まったまま
- 何を作ったかに加えて、相手が何をできるようになったかを確かめる
- 作る側が早く終えても、使う人の手作業が増えるなら、その手間と頻度を確かめる
- 速さ・費用・使いやすさの優先順位も共有する
- 誰のどんな判断や行動を助けたいかをAIにも渡し、終了条件や確認方法を考えてもらう
- 任せる範囲は失敗から考える:
- 見つけられるか、戻せるか、誰に影響するかで、任せる範囲を決める
- 隔離して試せる大きな変更もあれば、多くの利用先に影響する一行の設定変更もある
- 本番を書き換えない調査なら、読み取りだけの権限で進める
- 変更を試すなら、影響がほかへ広がらない環境と戻し方を用意し、その範囲で確認まで任せる
- 人に確認を頼むなら、判断に必要な材料・時間・権限も用意する
- 問題があれば、誰が何を変え、どう止めるかも決めておく
- すべてに承認を挟むとその人が仕事を抱えるため、何を判断するために見るかを絞る
- 終了条件の共有:
- 期日・分量・品質から、人とAIが共有する終了条件を揃える
- AIは共有した終了条件に照らして、次に何を調べ、作り、確かめるかを選ぶ
- 必要な資料、使える道具、何で結果を確かめるかも、任せる前に揃える
- 終えるときは成果が終了条件を満たしたかを確かめ、その根拠とともに相手へ渡す
- 何を終えるかを揃え、そこまでの進め方を任せる
- 終了条件を変える際の作法:
- AIが独断で達成しやすい条件へ変えず、変更を決める相手に理由を伝えて相談する
- 目的が変わっていないのにテストが通らないから期待する結果を消せば、達成したかを測れない
- 必要なデータが手に入らないなら、代わりに何を確かめれば判断できるかを相談する
- 新しい事実に合わせて条件を変えることと、できていないことを隠すことは違う
- 以前の条件で進む人とAIにも、変えた点と影響を伝える
- 仕事が不要になったら中止も選び、達成と中止を区別してやめる理由も共有する
■ 5. 分けろ: わからない所から切り出す
- わからなさの5層:
- 何を作るかもまだ決まらないなら、わからなさの5層で先に調べることを選ぶ
- 期待・ゴールが不明なら受け手に確かめ、進め方が不明なら方法を一つ調べ、実現可否が不明なら小さく試す
- まだ確かめていない前提を一つ見つけて、それを調べる仕事にする
- 一度に変えるものを絞り、どの前提で頼み、何を変え、何が起きたかを残す
- 探索の完了条件:
- データを使えるか調べる依頼なら、試した結果と、使える条件や制約を渡す
- 使えなかった場合も、別の方法を選べる材料が揃えば、その調査は区切れる
- 探索の仕事は、次の判断に必要な材料が揃えば完了
- 分けた仕事の統合:
- 個々の完了を集めただけでは、相手が使えるとは限らない
- 担当ごとに前提や完成の基準が違えば、組み合わせたときに食い違いや不足が見つかる
- 分担する前に、誰が使い、何ができれば終わりかを各担当にも伝える
- 共通の前提と、次の担当へ何をどんな形で渡すかを揃える
- 一緒に変えなければ成り立たないものまで分けると、調整が増える
- 個々の作業を進めやすくすることと、あとで組み合わせる手間の両方を考える
- 分けるときに全体を確かめる仕事も含め、まとめる担当と確認方法を決める
■ 6. 始めろ: 一回試して結果を見る
- 準備を足し続けない:
- AIにも、今の一歩に必要な資料や道具を揃え、一回試して結果を確かめるところまで任せる
- その一歩を動かせるなら、準備を足し続けず始める
- ループエンジニアリング:
- 一回動かしたら、結果を終了条件と比べ、次の一手を選ぶ
- 何を観測し、目標とどう比べ、結果に応じて次の行動をどう変えるかを設計する
- この作業中の進め方をループエンジニアリングと呼ぶ
- 期待した結果にならなかったのか、確認そのものを実行できなかったのかを見分ける
- 作ったものを直すか、確認に必要な環境や情報を揃えるかを選び、任せた範囲でもう一度試す
- 止める条件の明示:
- 「ここまでできました」という応答が返っても、依頼した仕事が全部終わったとは限らない
- Codexの/goalのように、目標と進捗を保持して複数の応答にまたがり作業を続ける機能もある
- 終了条件との照合から、完了・続行・中断を分ける
- 追加案があるだけでは続行せず、上限で止まったことを達成にはしない
- 未達なら不足を調べ、同じ試行で情報が増えないなら試し方を変える
- 判断待ちなら、未達の条件、必要な判断、成果と記録の場所を残し、続きから再開できるようにする
- 時間や費用が上限に達したら、実行する仕組みでも止められるようにする
- AIが自分で完了と判定して止まっても、その判定が正しいとは限らない
- 実行が止まったことと、成果を使えると判断することを区別し、実物と確認結果を残してもらう
- 反応が返る速さに合わせる:
- 結果が返る前に同じ成果へ変更を重ねると、どの変更に対する結果かが曖昧になる
- 確認する対象が変われば、受け手は確認をやり直し、次へ進むまでに時間がかかる
- 自動テストの結果を見る前に同じ不具合への修正を重ねると、前の修正が効いたかもわからない
- 資料も、相手が読んでいる途中で差し替えると、確認する対象がずれる
- 何を確かめた結果なのかを残し、その結果を見てから修正する
- 確認もAIへ任せ、一度に渡す量を絞り、待つ間は結果に依存しない別の仕事へ移る
- 自分の作業時間に加えて、相手が使えるまでの時間を見る
■ 7. 出せ: 相手が動ける形で渡す
- 動いたと使ってよいの差:
- 方向性を確認する依頼なら、試作を相手が評価できる形で渡せれば、その一回は完了
- その確認だけでは、実際の利用に必要な条件を満たしたことにはならない
- 本番へ反映するなら、実際に使う環境で必要な動作を満たすか、問題時に戻せるかを確かめる
- その確認や修正もAIに任せられる
- 受け手や利用場面が変わったら、終了条件を見直す
- 60点を、未確認のまま本番へ出す理由にはしない
- 完了報告に添えるもの:
- 成果を渡すときは、相手に何を判断し、どう動いてほしいかも伝える
- 「できました」に加えて、何を確かめてそう判断したかを示す
- 成果、確かめた条件と結果、未確認の点と影響の3つを揃える
- 必要な確認と報告の整理もAIに任せ、依頼や変更の記録へたどれるようにする
- 記録は判断を後から確かめ直すために残し、ログを全部貼ればよいとは考えない
- 判断をたどれることと、その判断が正しいことは別
- 確認の思い込み:
- 確認結果が揃っていても、確かめた条件自体が相手の求める条件と違う場合がある
- 作った側と確認する側が同じ思い込みで確かめれば、別のエージェントに頼んでも見逃す
- 一覧の検索結果をダウンロードする仕事で、画面の行だけを出す前提を共有すれば、同じ前提のテストは通る
- 受け手と確かめた条件では検索条件に合う全件が必要であり、画面外の行が不足する
- 画面外にも対象の行がある入力で、必要な全件が出るかを比べる
- AIにも、作成時の思い込みがあれば失敗する例と、未確認の条件を探してもらう
- 合格の根拠になるのは、実際に確かめた条件まで
- 確認役を増やすなら、何の見落としを補うのかを決める
- 完了と改善の分離:
- 改善できるところが残っていても、今回の仕事は終えられる
- 終了条件を満たし、相手が次の行動を取れる形で成果と根拠を渡せたら、一回を区切る
- 相手が判断するための材料が足りないなら、渡す前に補う
- 材料が揃っているなら、追加の改善を続けるより、いったん出して反応を確かめる
- 追加案を今回へ含め直すなら、追加で得られる効果と、相手を待たせる負担を比べる
- 変更を判断する相手と終了条件や期限を更新し、合意が変わらなければ次の候補へ残す
- どこまでも作れるとしても、どこまでも欲しいわけではない
- 「まだ良くできる」と思えるところで出し、相手の反応から次に良くする場所を選ぶ
- 出す怖さの3つの顔:
- 条件が揃い、追加の改善を見送ると決めても、自分の名前で出す怖さは残る
- 評価が怖ければ、見てほしい点を絞って出す
- 限界が見えるのが怖ければ、今の成果と自分の価値を分け、今回の成果への指摘として受け取る
- 終えたあとの空虚さが気になるなら、次にすることを一つ決め、それは休むことでもよい
■ 8. 回せ: 渡したあとに変える場所を選ぶ
- 終えたあとの見直し基準:
- 相手が使い始めたあとも、問題や目的の変化が見つかれば対応する
- 別案を思いつくたびに作り直すと、相手に選び直しや手順を覚え直す負担が生まれる
- ファイルは差し替えられても、相手が確認や操作を覚えるために使った時間は戻せない
- 別案の有無より、いま使う人への影響から見直す
- 誤った結果が使われるなどの問題なら、利用の停止や差し戻しも含めて対応する
- 調査と修正をAIに任せる場合も、任せた範囲を超える判断は依頼した人に相談してもらう
- 切り替えるときは、変更内容と理由、使ってほしいファイルや参照先を伝える
- 指摘の整理と返却:
- 指摘を受けたら、まず自分の感情と、相手が伝えた事実を分ける
- AIには指摘の要点を整理し、何を求められているかを言い換えてもらう
- AIの説明は相手の意図を確かめた結果ではなく、解釈で直す場所が変わるなら相手に確かめる
- 何をいつまでに直すかを決め、修正と確認をAIに任せる
- 直した結果を相手に返し、困っていたことが解決したかを確かめる
- 目的や優先順位まで変わるなら、終了条件を見直してから進める
- 次の一回への反映:
- 相手の判断に役立った材料、AIへ渡し忘れた前提、確認に時間がかかった理由が次の材料になる
- うまく進んだことも手戻りが起きたことも、次の一回を考える材料とし、もう一度決めろへ戻る
- うまく進んだ方法は生かし、手戻りの原因になった条件や任せ方を一つ見直す
- どう結果が変わるかを予想してから、似た仕事で試す
- 手戻りや待ちが減ったか、確認の手間がどれだけ増えたかを比べる
- 負担だけ増える対策は変えるかやめる
- 全部を自分で作らなくても、次に確かめようと思える場所は増やせる
■ 9. 終わらせる力
- 自分の仕事だと言える根拠:
- 自分の仕事だと言える根拠は、自分が打った文字数だけではない
- 何を解決するかを選び、作成や確認をエージェントに任せる
- うまくいかなければ、確認した条件や任せ方を見直す
- 終わらせる力の定義:
- 今回必要なことを終了条件にし、確認結果をもとに相手へ渡すものを決める
- 追加案が残っていても、今回の仕事を区切って相手へ渡すことが終わらせる力
- 実践の問い:
- 止まっている仕事について、誰に何を渡せば一回終えられるかを考える
- 何で確かめるか、何を相談してもらうかまでAIと書いてみる
- わからない所が残るなら、そこを調べる一歩から任せる
- 終えたあとの時間:
- 早く終えたあとの時間まで、同じ仕事の改善で埋めなくてよい
- 次に何をするかも、休むことも、自分で選びたい
- あなたが終わらせたものを、誰かが待っている
■ 10. 参考資料
- 『おい、とりあえず終わらせろ』:
- nwiizo著、ダイヤモンド社、2026年
- 5ステップ、擬似完了感、他者的完了、60点、出す怖さ、フィードバックの出典
- 岡野原大輔『ヒトとAI』:
- 岩波新書、2026年
- 第8・21章は理解と学び、第15〜19章は判断と責任、指揮と統合、監査・変更・停止を扱う
- 第11・25章は人の有限性と、選んで終わらせることを扱う
- 仕事への応用は本発表の解釈
- ループエンジニアリングの位置づけ:
- ループエンジニアリングは、サイバネティクスの再発見
- 観測と目標の比較、停止条件、評価の範囲、任せたあとの学びが論点