どうでもいい話題も、図にすればなぜか深く見えてくる。
この番組は頭の体操、時々悪ノリ。見えるようで見えない構造をスッキリ整理する、そんな図解系ラジオです。
今回のテーマは「リクライブ8人中5人がコロナに。どうしようを図解」です。
「要件定義している時間がない」。災害現場や制作現場の非常時では、それが現実です。
3回にわたるポッドキャストでは、突発的な大量欠勤をきっかけに、山本純平さんが“要件推理”という独自の思考法で状況を整理し、業務フローの可視化からAIによるタスク再分配のプロトタイプまで、一気通貫で形にしていきました。この記事では、その“最短距離で動く方法”を具体例とともにご紹介します。
※ 本記事はポッドキャストの内容を元に生成AIを活用して記事化・図解しています。
要件定義ではない、要件推理とは？
要件推理とは、システム開発の初期工程である「要件定義」を、スピードと仮説思考で置き換えるアプローチです。
通常の要件定義では、クライアントの課題や要望を詳細にヒアリングし、文書化してから設計へと進みます。しかし、災害現場や緊急対応のように時間が限られた環境では、その手順を踏む余裕がありません。
そうしたとき、山本さんは「聞いてまとめる」よりも「推理して提示する」を選びます。つまり、相手の話を全部聞き終える前に、「自分が現場責任者ならこう組む」という仮説をまず提示し、相手に“叩いてもらう”ことで要件を早期に具体化していくのです。
この考え方は、IT開発だけでなく、現場オペレーションの設計や組織改善にも応用できます。目的は「正確な仕様を作ること」ではなく、「動く仕組みを最短で作ること」。不確実な環境下でも前に進むための、“要件定義の外側にある推理法”が要件推理なのです。
要件定義の外側にある「要件推理」――大量欠勤の初動対応
事件は突然に起こりました。8人チームのうち、最大6人が体調不良で離脱。前の週はなんとか回せても、翌週の納品が危うい――そんな非常事態で、山本さんが取ったのは、仕様書を整えることではなく、「自分が責任者ならこう組む」という仮説を先に出すことでした。これがまさに“要件推理”です。
課題は三つに整理されました。
①欠勤の予兆が読めないこと。
②休んでも回る仕組みがないこと。
③外部パートナーの活用が弱いこと。
理想像として、スマートリングなどで体調兆候を検知し、クラウド上でタスクを一元管理。AIが稼働と締切を見て自動再分配し、それでも溢れたタスクは登録済みパートナーへ自動的にSOSを送る――そんな流れを描きました。
ここで大事なのは「正しさ」より「速さ」です。完璧な情報を待つより、80％の仮説を出して関係者が「これはできる」「ここは無理」と話し合える土台をつくること。それが非常時に前へ進む最短距離なのです。
“読める”業務フローを描く――平時と有事の二層設計
次に取り組んだのは「業務フローの可視化」です。誰が・いつ・どのシステムで・何をするかを、太線でシンプルに描きます。A3で読めないフローは現場の敵です。
レーンは〈マネージャ／スタッフ／パートナー／システム〉の4本に固定します。
平時のフローは「依頼受領→タスク登録→担当アサイン→進捗更新→レビュー→完了」という一本線。ここで“ふだんの基準”をつくります。
一方で、有事のフローは別レーンで「体調アラート→影響タスク抽出→AIによる再分配案生成→マネージャ承認→社内振替／外注依頼→進捗一元管理」。
外注時には契約・権限・データ授受などの“手続きの差分”も枝として明示し、平時との違いをわかりやすくします。
業務フローは“正解を描くもの”ではなく、“会話を生むもの”です。
全員が同じ図を見て議論できることが、次章で紹介するプロトタイプの精度を上げる鍵になります。
動くものが正義――AIでタスクを再分配するプロトタイプ
机上の空論はここで終わります。まずは、可視化しやすく、公開日が固定されている「ポッドキャスト編集業務」を題材にしました。
データ定義は必要最低限で構いません。
件名、概要、クライアント、担当者、状態（未対応・対応中・完了）、優先度（高・中・低）、カテゴリ（Web・動画・Podcastなど）、公開日、想定工数、保管リンク。
これだけで業務の流れは十分に整理できます。
プロトタイプでは、欠勤者の「公開日直前タスク」を抽出し、他メンバーの当日工数と締切を考慮してAIが自動的に再分配案を提示します。
マネージャーがワンタップで承認すると、タスクが更新され、全員の負荷が7〜9時間程度に平準化されました。
“明日の混乱”を前日に潰せる仕組みが、ここで見えてきたのです。
今後はスキルタグ（編集／デザイン／収録など）や機材・リモート可否を属性として追加することで、より精緻な分配が可能になります。
重要なのは「全部を自動化しない」こと。属人性の低い領域から段階的に始めることで、最小労力で最大の効果を得られます。
予算と契約の壁を越える運用設計――小さく始めて効くところから
理想は魅力的ですが、現実は予算と契約の壁があります。ここは割り切りが大切です。
- 体調予測は“あると良い”。スマートリング導入は任意にとどめ、まずは欠勤申告フォームと早期連絡ルールで代替します。
- 外注は“常時プール”を整備します。スキルカード、単価表、NDAや契約テンプレート、データ授受ルールを先に準備しておきます。
- 見積りは“段階課金”。①業務フロー合意 ②最小プロト作成 ③対象業務拡張――という3段階で、都度合意する方式にします。
運用面では、公開日×工数で赤信号を自動点灯（2営業日前に閾値超なら即アラート）。
AI提案→承認→通知→タスク更新を1クリックで完結できるようにし、マネージャーが「判断」に専念できる環境を整えます。
まとめ――非常時を“ふつう”にする
A3で読める業務フロー、最小限のデータ定義、そしてAIによるタスク再分配――この三点が揃えば、「休んでも回るチーム」の骨格が完成します。
完璧を目指さず、まずは公開日が固定された業務から始める。小さく始めて効くところから広げる。それが、非常時を“ふつう”に変える最短距離なのです。
要件定義は「正確さ」を積み上げる営みですが、要件推理は「速さ」で前へ進むための思考法です。
非常時にはまず推理で動くものをつくり、それを叩いてもらいながら精度を上げていくことが大切です。
