AIを使い倒した先にあるのは、目的から逆算して仕事を設計する組織なのではないか。
コーディング、ドキュメント作成、調査、レビュー、会議準備。生成AIは、人間が時間をかけてきたさまざまな仕事を支援するようになった。人間の知識や経験にAIを組み合わせ、一人ひとりができることを増やす。この使い方を、ここでは「Human + AI」と呼ぶ。
ただ、AIの活用を突き詰めると、個人の生産性だけでは説明できない変化が見えてくる。AIに仕事を任せるために情報や判断基準を整理すると、人間も仕事を進めやすくなる。さらに、既存の仕事を誰が担当するかにとどまらず、その仕事が本当に必要なのかを問い直せるようになる。
私は、この変化を「Human + AI」「Human or AI」「Outcome First」という三つの段階で考えている。すべての組織がこの順番で進むという予測ではない。AI活用と組織設計の関係を捉えるための、一つの見方だ。
Phase 1：Human + AI ― 人間の能力を拡張する
最初の段階では、人間がAIに指示を出し、AIが作業を支援する。ソフトウェア開発なら、次のような使い方がある。
- 要件を渡してコードを書いてもらう
- プルリクエストをレビューしてもらう
- ログを解析してもらう
- 技術調査やドキュメント作成を任せる
人間が持つ知識や経験、業務の背景をAIに伝えながら、一緒に仕事を進める。この段階でのAIの役割は、人間の能力を拡張することにある。
仕事によっては、人員を増やすよりも、今いるメンバーがAIを使って対応できる範囲を広げるほうが合理的な場合もあるだろう。AIの利用料に加え、指示や確認にかかる時間も含めて考える必要はあるが、仕事量の増加に対応する選択肢は増える。
一方で、AIを使うほど、毎回説明しなければならない情報の多さに気づく。
「このプロジェクトでは、このルールに従う」「仕様はこのドキュメントにある」「この設計を選んだのには、こういう経緯がある」「この顧客には、こういう事情がある」。
こうした仕事の背景や前提、判断に必要な情報を、ここでは「コンテキスト」と呼ぶ。人間同士なら暗黙の了解で済んでいたことも、AIに任せるには説明が必要になる。AI活用は、組織にどれだけ暗黙知があるかを知るきっかけにもなる。
Phase 2：Human or AI ― 個人の知識を組織で共有する
毎回同じ説明をしていると、その情報をあらかじめ参照できる形で残したくなる。個人の頭の中にあったコンテキストを、組織で共有する情報へと移していく段階だ。
開発組織なら、たとえば次のような文書が考えられる。
- プロジェクトの概要や利用手順を記したREADME
- 設計上の判断とその理由を残すADR（Architecture Decision Record）
- AI向けの作業指示を記したCLAUDE.mdやAGENTS.md
- コーディング規約やプロジェクトのルール
- 成果物が満たすべき受け入れ基準（Acceptance Criteria）
- 運用手順書（Runbook）やFAQ
- 設計書（Design Document）や意思決定の記録（Decision Log）
必要な情報が整理されると、「あの人に聞かないと分からない」仕事の一部が、「この文書を読めば進められる」仕事に変わる。
これはAIだけのための整備ではない。新しいメンバーが背景を理解しやすくなり、担当者が変わっても引き継ぎやすくなる。AIに伝わるように情報を整理することが、人間の働きやすさにもつながる。
その結果、仕事によっては、人間とAIが常に組みになって進める必要がなくなる。必要な情報と判断基準を共有できれば、人間が担当することも、AIに任せることも選びやすい。この状態を「Human or AI」と呼びたい。
もちろん、文書を整えただけで、あらゆる仕事をAIに任せられるわけではない。それでも、特定の人だけが持っていた情報を共有することで、実行方法の選択肢は広がる。
人間かAIかを選ぶ前に、仕事の目的を問い直す
最初は、人間とAIのどちらでも仕事を進められる状態が理想なのではないか、と考えた。だが、この考え方では、既存の仕事をそのまま続けることが前提になっている。
たとえば、「毎週、報告資料を作る」という仕事があるとする。Human or AIの発想なら、人間が作るか、AIに作成を任せるかを検討する。
しかし、その仕事の目的が「経営者がプロジェクトの状況を把握し、必要な意思決定を行えるようにすること」なら、報告資料以外の方法も考えられる。ダッシュボードで状況を確認できれば十分かもしれないし、異常が起きたときだけ通知すればよいかもしれない。判断が必要な項目だけを自動でまとめる方法もある。
目的を満たせるなら、毎週資料を作る仕事自体をなくす選択もできる。担当を人間からAIに変えるだけでは、この可能性を見落としてしまう。
Phase 3：Outcome First ― 達成したい状態から仕事を設計する
そこで出発点にしたいのが、「何を実現したいのか」という問いだ。私は、この考え方を「Outcome First」と呼んでいる。ここでいうOutcomeは、資料やコードといった成果物を作ることによって、実現したい状態を指す。
仕事を設計するときは、次の順番で考える。
- 何を実現したいのか
- 現状と目指す状態には、どのような差があるか
- その差を埋めるために、何を変える必要があるか
- 判断や実行に必要な情報は何か
- どの方法なら、目的を最も合理的に達成できるか
実行手段を選ぶのは、その後だ。人間が担当する、AIに任せる、従来のソフトウェアで自動化する、ルールを見直す、外部サービスを使う。これらを組み合わせることも、不要な業務を廃止することもできる。
この順番なら、「AIで何ができるか」に検討範囲を限定せずに済む。AIを使う理由も、目的を達成するうえで適した手段だから、という明確なものになる。
AIの導入を、業務を見直す機会にする
業務改善を「どうAI化するか」から考えると、今ある仕事をそのままAIに置き換えようとしがちだ。先ほどの報告資料の例なら、資料作成を速くすることに意識が向かう。
まず確かめたいのは、その業務が今も必要なのかということだ。必要であっても、仕組みやプロダクトを変えることで作業を減らせるかもしれない。手順が明確なら、従来の自動化で十分な場合もある。そのうえで、AIに任せる範囲と人間が担う範囲を考えたい。
こうした判断が当たり前になれば、「AI活用」という言葉を使う機会も減っていくのかもしれない。業務システムでデータベースを使うたびに「DB活用」と呼ぶわけではないように、AIも必要に応じて選ぶ技術の一つになる。
AI利用率や導入数だけを追っていては、業務をなくすことで得られた改善を捉えにくい。見るべきなのは、目的の達成にどれだけ近づいたかだと思う。
AIがうまく働かない理由から、組織の課題が見える
AIに仕事を任せようとしてもうまくいかないとき、原因をたどると、組織側の課題が見つかることがある。
- 必要なドキュメントがない
- どれが最新の情報か分からない
- 判断基準が曖昧になっている
- 情報が散在し、必要なときに見つからない
- 担当者の経験や暗黙知に頼っている
- 責任範囲や仕事の進め方が明確になっていない
これらは、人間が経験や会話で補ってきた問題でもある。AIに任せる過程で、これまで説明せずに済ませていた前提や、曖昧なまま運用していた手順が表に出てくる。
AIがうまく働かない原因をすべて組織に求めることはできないが、導入時のつまずきは、仕事の進め方を見直す手がかりになる。AIの価値は作業時間の短縮だけでなく、こうした課題に気づく機会を生むことにもあるのではないか。
AIが使いやすい環境から、目的を達成しやすい組織へ
AIの導入当初は、AIが理解しやすい文書を作り、参照しやすい場所に情報を置き、判断基準を明示することに力を注ぐ。
その整備が進むと、人間も情報を探しやすくなり、判断の経緯を学びやすくなる。引き継ぎのたびに同じ説明を繰り返す負担も減らせるだろう。
目指したいのは、目的の達成と意思決定に必要な情報がそろい、それを使って仕事を進められる組織だ。原点はAIが働きやすい環境づくりであっても、行き着く先は組織全体の仕事の進めやすさにある。
Human + AIで個人の能力を拡張し、Human or AIで仕事の担い手を選べる範囲を広げる。そしてOutcome Firstで、目的に照らして仕事と実行手段を選び直す。この変化は、AIの導入をきっかけに、組織が自らの仕事を問い直していく過程だと捉えられる。
AIを使い倒すからこそ、「この仕事をAIに任せられるか」の一歩先まで考えたい。「そもそも何を実現したいのか。そのために、この仕事は必要なのか」。そこまで問い直せたとき、AI活用は組織設計の話になる。