週次の報告会議で、人によって報告の粒度がばらばらだったことはないでしょうか。ある人は数字だけ、ある人は経緯だけを話し、聞く側は毎回頭の中で並べ替えています。このページでは、その疲れの正体を「型が決まっていない」という視点から見ていきます。
会議室で起きている小さな事故
架空の場面を考えます。週次会議で、営業のAさんは進捗を数字で報告します。「先週の商談は3件進み、うち1件が見積もり段階に進みました」と、結論から淡々と話します。続いて発言する制作のBさんは、経緯を時系列で話し始めます。「先週の頭にラフ案を作って、水曜に一度修正が入って、木曜にまた別の指摘があって……」と続き、着地点が最後まで見えません。
司会は内心で「それで、今どこまで進んでいるのか」と焦りながら、Bさんの話が終わるのを待ちます。会議が終わるころには、司会は「結局何が決まったのか」を、自分の言葉でもう一度まとめ直す羽目になります。この並べ替えの作業は、本来なら発言の時点で済んでいるはずの仕事です。
同じことは依頼のやり取りでも起きます。問い合わせ対応の担当者に「あの件、対応しておいて」とだけ依頼が来る場面を考えてみましょう。担当者は「あの件とはどれのことか」「いつまでにやればいいのか」を、依頼した本人に聞き返します。依頼者は別の会議に入っていて、返信は夕方まで来ません。その間、担当者は他の仕事を進めながら、頭の片隅でこの件の続きを気にし続けます。締切も優先度も書かれておらず、担当者は依頼者に聞き返してから着手します。聞き返しのやり取りだけで半日が過ぎることも、珍しくありません。
さらに厄介なのは、この摩擦が個人の間だけで終わらないことです。週次会議の後、司会が「今日の内容を整理しておきます」と、10分の非公式なフォロー会議を別に開くことがあります。本来の会議で決着していれば不要だったはずの時間が、後からもう一段積み増しされる形です。
ここで一度、AさんとBさんの報告に、良し悪しの差があったわけではない点を確認しておきます。Aさんの数字もBさんの経緯も、それぞれ必要な情報であり、どちらも間違ってはいません。問題があるとすれば、それは話す順番や粒度が、あらかじめ揃えられていなかったことだけです。
これらに共通するのは、話す内容そのものではなく「やり取りの形」が決まっていないことです。何を渡せば、何が返ってくるのか。誰が、いつ、どの順番で話すのか。この取り決めが曖昧なままだと、内容がどれだけ正しくても摩擦が生まれます。
型が無いと何が起きるか — 代償を分解する
「型が無いだけで、そこまで大きな問題になるのか」と感じるかもしれません。そこで、型が無いことの代償を、時間の流れに沿って分解してみます。
まず、依頼を受けた側が、依頼の意図を推測する時間がかかります。次に、推測が外れていた場合、確認のやり取りが1往復発生します。さらに、確認の返事が来るまでの待ち時間が、他の作業を止めることもあります。最後に、期限ぎりぎりで意図の食い違いが発覚すると、作り直しの時間まで発生します。この4段階は、依頼のたびに繰り返される固定費のようなものです。
たとえば、1回の依頼で10分の推測と1往復の確認が発生すると仮定すると、1日に5件の依頼をやり取りする担当者では、それだけで50分が消えている計算になります。これは特別に不注意な職場の話ではなく、型を決めていなければ、どの職場でも起こり得る構造です。しかも、この50分はあくまで1人分の見積もりです。依頼者と担当者の双方が同じだけの時間を消費しているとすれば、チーム全体では、その2倍近い時間が、日々静かに失われている計算になります。個人が特に非効率なのではなく、やり取りの構造そのものが、時間を静かに消費し続けているのです。
コンピュータの世界にある「型」の発想
コンピュータのプログラム同士がやり取りするときも、同じ問題が起こり得ます。あるプログラムが、別のプログラムの内部の作りを推測しながら依頼を送るとしたら、推測が外れるたびにエラーが起き、原因を調べるだけで時間がかかります。違うのは、コンピュータの世界ではこの摩擦を、慣習ではなく取り決めとして先に潰しておくという点です。
あるプログラムが別のプログラムに処理を依頼するとき、事前に「窓口の形」を決めておきます。これを本書では「インターフェース」と呼びます。窓口の形とは、何を渡せば何が返るかの約束のことです。例えば「注文番号を渡すと、配送状況が返る」という約束を先に決めておけば、依頼する側は中身の仕組みを知らなくても、正しく依頼できます。配送状況を調べる処理が、後からどれだけ複雑に作り変えられても、窓口に渡すものと返ってくるものの形さえ変わらなければ、依頼する側は何も困りません。
逆に、この窓口の約束を決めずにシステム同士をつなぐと、何が起きるでしょうか。一方のシステムが「日付は2026年8月27日という形式で送る」つもりでいて、もう一方が「日付は8/27/2026という形式で受け取る」つもりでいたとします。窓口の形が事前に一致していなければ、データはそのまま誤って読み込まれてしまいます。エラーにすらならず、間違った日付として処理が進んでしまうことさえあります。窓口の約束を先に固定しておくことは、こうした食い違いを未然に防ぐための作業なのです。
さらに、やり取りの手順そのものにもルールがあります。これを「プロトコル」と呼びます。プロトコルとは、誰が先に何を送り、相手がどう応答するかという、やり取りの順番の取り決めです。
窓口の形（インターフェース）と、やり取りの手順（プロトコル）は、セットで機能します。窓口だけ決めても、話す順番が毎回バラバラなら、結局は摩擦が残るからです。例えるなら、窓口の形は「何を書く欄があるか」という申請書の書式であり、手順は「その申請書を、誰から誰の順に回すか」という決裁の流れにあたります。書式だけ整えても、回す順番がその場任せなら、申請は迷子になります。
よくある反応 — 「毎回状況が違うから型は作れない」
ここまで読んで、「うちの依頼は毎回内容が違うから、型になじまない」と感じた方もいるはずです。これは自然な反応で、実際に内容が毎回違うこと自体は事実です。ただし、型として固定するのは内容ではなく、やり取りの「入れ物」の形です。依頼の中身が毎回違っても、「目的・期限・優先度」という欄の並びは固定できます。会議の議題が毎回違っても、「結論から話す」という発言の順番は固定できます。内容の多様さと、やり取りの構造の一貫性は、両立できるものであり、対立するものではありません。
もう1つ、よくある反応があります。「細かく型を決めると、相手を信頼していないようで気まずい」というものです。これも裏を返せば、型を決めない方が、実は相手への負担が大きい場合があります。型が無いと、受け手は依頼者の意図を推測し、外れていないかを常に気にしながら動くことになります。欲しい形をあらかじめ伝えておくことは、相手を疑うことではなく、相手の推測の負担を減らすことだと捉え直せます。
3つ目によくあるのは、「今のやり方を変えるのが面倒」という反応です。これも無理はありません。長年同じやり方で回ってきた依頼のやり取りを、急に変える必要はありません。このページで扱う型は、既存のやり取りを禁止するものではなく、選択肢を1つ増やすものです。まずは、聞き返しが多いと感じる依頼や会議を1つだけ選んで、そこにだけ型を当ててみれば十分です。うまくいけば、他の依頼や会議にも少しずつ広げていけばよく、一度に全てを変える必要はありません。
この章の見取り図
この章では、依頼と報告というオフィスの日常を、この2つの概念で読み解きます。まず、依頼そのものの「型」を決めるという発想を、コンピュータの「API」という仕組みから借りて見ていきます。API とは、あるプログラムが別のプログラムに機能を提供するときの、窓口の仕様のことです。
次に、会議体や報告フォーマットを「プロトコル」として捉え直します。その後、やり取りを会議で行うべきか、チャットで済ませるべきかを、コンピュータの「同期・非同期」という区別を借りて考えます。最後に、担当者が変わっても仕事が止まらない状態、つまり「疎結合」について扱います。疎結合とは、部品同士のつながりが緩やかで、片方を交換しても他方に影響が出にくい状態のことです。これは、引き継ぎのしやすさに直結する考え方です。8章で見た「共通化」が業務の中身を揃える発想だったのに対して、この章で扱うのは、業務の中身ではなく、業務同士の「つなぎ目」を揃える発想だと考えてください。
なぜ「型」を決めることに時間を使う価値があるのか
型を決める作業は、一見すると遠回りに見えます。目の前の依頼にすぐ着手した方が早いと感じるかもしれません。しかし、型が無いまま依頼と報告を繰り返すと、毎回同じ聞き返しと手戻りが発生します。一度決めた型は、その後の全てのやり取りで摩擦を減らし続けます。型を決めるコストは一度きりですが、型が無いことのコストは、やり取りのたびに毎回発生し続けます。最初の一回に少し時間をかけるかどうかが、その後の何十回分の摩擦を左右する、という構図です。
これは、個人の頑張りや気配りで解決する話ではありません。やり取りの構造そのものを設計し直すという、仕組みの話です。8章で見た共通化は、同じ作業を2度作らないための工夫でした。この章で扱う型は、同じ聞き返しを2度させないための工夫だと言い換えられます。対象は違っても、狙いは「繰り返し発生する無駄を、構造の側で先に潰す」という点で共通しています。次のページから、依頼の型を決めるという発想を具体的に見ていきましょう。
持ち帰り
- 会議や依頼で感じる疲れの多くは、内容ではなく「やり取りの形」の未整備が原因である
- インターフェースとは、何を渡せば何が返るかという窓口の約束のことである
- プロトコルとは、誰がいつ何を話すかという、やり取りの順番の取り決めのことである
やってみる
次に誰かに何かを依頼するとき、「何を」「いつまでに」「どの形式で」返してほしいかを一行だけ添えてみてください。