IPOAとは：IPO図（Input-Process-Output）に行動を足す

IPOAとは：IPO図の入力・処理・出力に「行動」を足した考え方

IPOAは、Input（入力）、Process（処理）、Output（出力）、Action（行動）の頭文字をとった言葉です。仕事を「何を受け取り、どう処理し、何を渡し、それを受け取った人が何をするか」の四つに分けて見ます。

• Input（入力）：判断や作業に必要な材料。案件の状態、日付、担当者、現場のメモなど。
• Process（処理）：材料を整えるルールや手順。抽出、集計、照合、分類、要約など。
• Output（出力）：受け手が読む成果物。一覧、通知、帳票、ダッシュボード、文書の下書きなど。
• Action（行動）：成果物を受け取った人やシステムが、次に決めること・動くこと。

ポイントは、設計する順序と、実際に動かす順序を分けることです。動かすときは入力を処理して出力し、受け手が動きます。一方、何を作るかを考えるときは、最後のActionから逆向きに辿ります。

IPO図・IPOモデル（Input-Process-Output）との違い

Input・Process・Outputの三つで仕組みを捉えるIPOモデルは、システム分析やプログラム設計で古くから使われてきた考え方です。入力を受け取り、処理して、結果を出力する。仕組みの中身を説明するには、この三つで足ります。

• IPO：仕組みが入力を正しく出力に変えるかを見る。完成の条件は「出力が正しい」こと。
• IPOA：出力を受け取った人が次の行動を決められるかまで見る。完成の条件は「行動が起きる」こと。

ただ、業務の現場で困るのは、出力のあとです。帳票や画面が予定どおりに出力されても、それを見た人が何も決めなければ、仕事は前に進みません。IPOモデルは、その出力が誰のどんな行動につながるかまでは問いません。

IPOAは、この「出力の受け手」を設計の対象に含めます。Outputが正しく作られたかではなく、Actionが起きたかで完成を判断する。これがIPOとIPOAのいちばん大きな違いです。

なぜActionから逆算するのか

データ活用や自動化の企画は、手元にあるデータから考え始めがちです。とりあえず全部集め、集計し、画面を作る。それでも、会議で開かれない、更新が止まる、という結果になることがあります。

入力から作り始めると、どの項目が必要かを判断する基準がありません。そのため「念のため」の項目が増え、集計の種類が増え、画面が複雑になります。完成してから使い道を探すことになり、受け手の判断に合わなければ作り直しです。

Actionから逆算すると、判断に要る情報だけが残ります。同時に「この判断に必要な日付が、そもそも入力されていない」といった、実装の前に解くべき業務上の不足も早く見つかります。ダッシュボードが使われない原因は、画面の出来よりも、このActionが決まっていないことにある場合が少なくありません。

IPOAの進め方：5つの手順

IPOAは、紙一枚やスプレッドシートでも始められます。一つの判断について、次の順に書き出してみてください。

• 手順1　Actionを一文で書く：「誰が」「いつ」「何を見て」「何を決めるか」。「把握する」「確認する」で終わる場合は、確認したあとに何を決めるかまで書きます。
• 手順2　Outputを決める：その判断に必要な最小限の項目、形式（一覧・通知・帳票など）、届くタイミングと場所を決めます。
• 手順3　Processを決める：抽出や集計のルール、例外の扱い、人・仕組み・AIのどれが担当するかを決めます。
• 手順4　Inputを洗い出す：必要な項目ごとに、どこで発生し、誰が入力し、どの頻度で更新されるかを確かめます。
• 手順5　一周させて確かめる：実際の一回分の仕事で、入力から行動までを流し、決定まで辿り着けるかを見ます。

手順1がいちばん難しく、いちばん大事です。受け手が決まらないまま手順2以降に進むと、Outputは「あると便利そうなもの」の集まりになります。逆に、Actionの一文が決まれば、残りの三つはかなり自然に決まります。

手順4では、足りない入力が見つかることがよくあります。そのときは処理を工夫して穴を埋めるより先に、誰がいつ入力するかという業務の取り決めを見直します。入力の質が、出力と行動の質の上限になるためです。

記入例：営業会議で停滞案件のフォローを決める

説明用の仮想例として、毎週月曜の営業会議で、動きの止まった案件のフォローを決める場面をIPOAに分けてみます。

• Action：止まっている案件ごとに、次の連絡担当と期限を決める。
• Output：対象案件、最終接点日、担当者、確認事項が1画面に並ぶ一覧。
• Process：進行中の案件のうち、一定期間接点がないものを抽出し、最終接点日の古い順に並べる。何日を「止まっている」とみなすかは会議で決める。
• Input：案件ID、状態、最終接点日、担当者、判断に必要なメモ。

Inputまで辿ったところで、最終接点日が空欄の案件があると分かったとします。この場合、画面を作り込む前に「接点があった日に、誰が記録するか」を決めるほうが先です。IPOAは、実装の前に業務側の不足を見つけるためにも使えます。

同じ型は営業以外にも使えます。たとえば経理の月末確認なら、Actionは「請求漏れの可能性がある取引ごとに、確認先と期限を決める」、Outputは「受注済みで未請求の取引の一覧」、Processは「受注データと請求データの突き合わせ」、Inputは「取引ID・受注日・請求日・金額」のように分けられます。題材が変わっても、行動する人、タイミング、決める内容を具体化する進め方は同じです。

よくあるつまずきと直し方

IPOAを書いてみると、次のようなところで手が止まることがよくあります。

• Actionが「見る」「把握する」で終わる：把握したあとに何を決めるのかを一段深く書きます。決めることがなければ、そのOutputは定期的に作らなくてもよいかもしれません。
• Outputに項目を詰め込みすぎる：判断に使わない項目は、元のデータに残しておけば十分です。一覧から元の記録へ戻れる導線のほうが役に立ちます。
• Processがブラックボックスになる：抽出の条件や例外の扱いを文章で残します。AIに任せる場合も、何を渡し、何を返させるかを決めます。
• Inputの負担を見落とす：入力する人が誰で、その人の手間が増えないかを確かめます。入力が続かない仕組みは、やがて出力も止まります。
• 一周させずに完成とする：画面が表示された時点で終わらせず、受け手が実際に決定できたかまで確かめます。

AIに任せる範囲も、IPOAで分ける

生成AIやAIエージェントを業務に入れるときも、IPOAの四つに分けると役割分担を考えやすくなります。

• Input：AIに渡す資料と、渡してはいけない情報を決める。
• Process：要約・分類・下書きなどAIに向く処理と、期限計算や照合などルールで処理すべきものを分ける。
• Output：参照元や判断の理由を添えて、人が確かめられる形で返させる。
• Action：対外的な連絡や確定処理など、人が承認してから実行するものを決める。

何でも一つのAIに任せるのではなく、AIに任せる処理、通常の仕組みで行う処理、人が判断する行動を分けると、失敗したときに止める場所や、人へ戻す条件も決められます。AIを入れることではなく、受け取った人の仕事が前へ進むことを完成の条件に置きます。

sento.groupのAI合宿でも、IPOAを軸に、最後に取りたい行動から逆算して「AIに渡す情報・任せる処理・確かめる成果物」を決めるところから演習を始めています。

使われる仕組みかを確かめるチェックリスト

作ろうとしているもの、すでに作ったものが使われるかどうかは、次の4段階で確かめられます。下の段から順に、満たしているかを見てください。

• 「これを誰が、いつ見て、何を決めるのか」を一文で言える。
• Outputの各項目が、その決定のどこに使われるかを説明できる。
• Processのルールと例外の扱いが、担当者以外にも分かる形で残っている。
• Inputの各項目について、入力する人と更新のタイミングが決まっている。
• 実際の一回分で、入力から決定までを通して確かめた。
• うまくいかなかったときに止める条件と、直す担当が決まっている。

まず、いま作ろうとしているもので試す

新しいダッシュボードや自動化の企画があれば、まず「これを誰が、いつ見て、何を決めるのか」を一文にしてみてください。答えにくければ、画面や機能を増やす前に、その受け手と話す価値があります。

その一文が決まったら、判断に必要な出力、処理、入力へ逆算します。IPOAは大きな設計書を作るためだけでなく、いま作ろうとしているものが本当に使われるかを確かめるためにも使えます。

すでに作ったダッシュボードが使われていない場合の切り分け方は関連記事「ダッシュボードが使われない理由」で、IPOAで整えたデータを日々の業務として回す考え方は「データオペレーションとは」で解説しています。