業務をシステムに合わせるのを、やめました

打ち合わせが始まる5分前に、前回何を約束したのかを思い出そうとして、チャットをさかのぼる。メールを開く。議事録を探す。そういう時間が、毎日ありました。

いまはその時間がありません。プロジェクトの台帳を1ページ開けば、前回からいまに至るまでの流れが並んでいます。会議で決まったこと、そのあとに届いたやりとり、相手の会社の動き、こちらが手を動かした内容まで。

この記事は、その台帳をどう作ったかの話です。ただ、作り方そのものより先に伝えたいことがあります。この台帳は、うちの会社にしか合いません。そして、そのことが重要なのです。

つないでいるのは、この14です。

打ち合わせの記録 … Zoomの文字起こし／HiNotes
やりとり … Gmail／Slack／dejiren／Teams／Messenger／LINE WORKS
そのほか … Outlook（予定）／Backlog（課題）／各社サイト・ニュース／Notion／Google ドライブ／Claude

この組み合わせは、うちの仕事の形そのものです。同じ組み合わせの会社は、たぶんありません。

まず、できあがったものをご覧ください。

実際の手順やつまずいた点は、体験談として別にまとめています 👉 案件の状況を、自分で思い出すのをやめた話（X）

何が変わったか

この台帳に、私は入力していません

最初に、いちばん大事なことを書きます。

私はこの台帳を、更新していません。打ち合わせの記録も、チャットのやりとりも、宿題の一覧も、相手の会社の動きも、全部あとから自動で入ります。ステータスを直すことも、サマリを書き直すこともありません。

それでも中身は最新です。

私がこの台帳に文字を書き込む場所は、ひとつしかありません。案件ページのコメント欄です。「この論点はもう解決した」「次はここまで持っていきたい」「この名前は違う人です」。そういうことを、思いついたときにふだんの言葉で1行だけ書きます。

書いたコメントは、翌朝の総括に反映されています。フォームでもなければ、決まった書き方でもありません。文章のまま読み取られて、本文が書き換わります。

コメントは、他のどの材料よりも優先されます

集めた材料には順番をつけてあります。議事録、チャット、メール、前回の総括、そしてコメント。このうちコメントを、いちばん確度が高いものとして扱っています。

理由は単純で、いちばん新しいからです。議事録は打ち合わせの時点の話ですが、コメントは私がその日に書いたものです。両者が食い違ったら、コメントを正としています。

具体的には、こう動きます。

• コメントに「この課題は解決済み」と書けば、その課題は次の日から「未解決」の欄に出てきません
• コメントに「次はここを確認する」と書けば、それが総括の「次の一手」に入ります
• コメントに「この名前は誤りで、正しくは別の人」と書けば、誤った名前はページのどこからも消えます

3つ目は、AIの判断に任せていません。人の名簿に照らして正しい名前が確定できるときだけ、機械的に置き換えています。AIの判断に委ねると、たまに置き換え損ねるからです。

指示の取り消しは、コメントを解決済みにするだけです

ここは自分でも気に入っている作りです。

指示を出したあと、それが終わったらコメントを「解決済み」にします。Notionのコメント欄にもとからある機能です。すると、そのコメントは翌日から材料に入らなくなります。未解決のコメントだけが読み込まれるようにしてあるからです。

つまり、指示の有効期限を、私が管理しなくてよくなりました。 「もうこの指示は要りません」と書き足す必要はありません。終わったら、チェックを付けるだけです。

指示を出す場所と、取り消す場所が同じで、しかもどちらも1アクションで終わる。ここを作り込んだおかげで、台帳に向かう時間がほとんどなくなりました。

打ち合わせの前に、思い出す時間がなくなりました

以前は、打ち合わせのたびに前回の記憶を組み立て直していました。約束したこと、宿題になったこと、相手が気にしていたこと。どれも記録は残っているのですが、残っている場所がばらばらでした。

いまは開くだけです。組み立て直す作業がなくなりました。

見に行く場所が、1つになりました

案件のページに、その案件に関することが集まっています。打ち合わせの記録も、チャットのやりとりも、メールも、相手の会社が公表した動きも、同じページにあります。

「あれはどこで話したんだったか」を考える必要がなくなりました。どこで話したかは、もう覚えていなくてよいのです。

手で書いていた頃より、内容が正確になりました

意外に思われるかもしれません。自動でまとめると、内容は雑になると思われがちです。実際は逆でした。

人が書くと、書き漏らします。あとから書くと、細かいところを忘れています。そして、うまくいった話は書きますが、うまくいかなかった話は書かないものです。

自動なら、全部残ります。なぜその日に更新されたのかという理由まで残ります。都合の悪い動きも、消えません。

だから、確かめに行かなくなりました

ここが、この記事でいちばん伝えたい因果です。

台帳の内容が正確になったから、元のチャットを開き直す用事が消えました。 その結果として、管理にかかる手間が大きく減りました。

順番が逆ではありません。自動化そのものが手間を減らすのではないのです。信じられない台帳なら、結局こちらから確かめに行くことになります。それでは何も減りません。むしろ、確認する場所が1つ増えるだけです。

品質が上がって、初めて手間が減ります。

台帳ができること

開けば、いまの状況がわかります

案件のページには、いまの状況、これから来る節目、最近のやりとり、関係者ごとの動き、そして短い要約が並んでいます。上から順に読めば、その案件がいまどうなっているかが掴めるようにしてあります。

昨日その案件で起きたことが、全部そろっています

会議も、チャットも、こちらがAIと一緒に手を動かした作業も、同じ時間軸に並びます。

昨日その案件で何が起きたのかを知りたいとき、複数の場所を見比べる必要がありません。翌朝には、1本の流れになっています。

目で追っていないやりとりも、集めてあります

正直に言うと、すべてのチャットを毎日見てはいません。動きの少ない部屋もあれば、しばらく開いていない部屋もあります。

それでも、集めることだけは毎晩しています。見ていなくても、たまっています。だから「見逃していないか」を心配しなくてよくなりました。

相手のことを、覚えています

人の名簿を持っています。同じ人が場所によって違う呼ばれ方をしていても、1人にまとめます。聞き取りを間違えた名前も、正しい人に寄せます。

そのうえで、その人がどういう進め方をする人なのかを持っています。何を大事にして、どう返してくる人なのか。それがわかると、次に何を渡すべきかが決めやすくなります。

取引先の会社としての動きも、置いてあります

会社の名簿も持っていて、その会社が公表している動きを自動で拾ってきます。

案件の相手が、会社としていま何をしているのか。それを知るために先方のサイトを見に行く、ということがなくなりました。更新があったときに、案件のページに載ります。

名簿は、私が育てません

新しいやりとりの部屋ができることがあります。新しい相手と個別のやりとりが始まることもあります。

そういうとき、台帳は勝手に決めません。「この部屋が増えていましたが、どの案件に入れますか」とチャットで聞いてきます。 最初のメッセージを1行添えて、判断できる形で届きます。

こちらは答えるだけです。一度答えれば、その部屋はもう聞かれません。

同じことを、人の名簿でもしています。名簿に無い名前が、別々の打ち合わせで2回出てきたら「この方を名簿に登録していいですか」と聞いてきます。1回きりの方は聞いてきません。一度だけ会った方まで全部聞かれると、通知が読まれなくなるからです。

つまり、登録という作業を私がしていません。 聞かれたら答えるだけです。

これがないと、集める範囲が古いままになります。私が「新しい部屋ができたから登録しないと」「あの方を名簿に入れないと」と気づく必要をなくすための仕組みです。台帳を育てる作業を人の気づきに任せると、忙しい時期ほど止まります。

Macを開かなくても、同じページが出ます

集めて判断しているのは手元の1台ですが、たまる先はクラウドです。だから見る側は端末を選びません。

移動中でも、先方の会社でも、同じページが出ます。打ち合わせの直前に確認するのは、たいていiPhoneです。

全体を俯瞰する画面も、同じ台帳から作られます

案件のページは1件ずつ見るものですが、それとは別に全体を1枚で見る画面を持っています。

いちばん上に出るのは「仕事の流れ」です。今月あらたに発生した件数、終わる見込みの件数、そしてその差し引き。増え気味なのか、減り気味なのかが1行で出ます。抱えている件数そのものより、増えているのか減っているのかのほうが判断に効きます。

その下に、重要な案件が最新の要約つきで並び、自分の関与のしかた別の件数、重要な案件のガント、議事録のカレンダー、期限を過ぎた宿題、取引先の最新ニュースと続きます。

作るのに特別なことはしていません。同じ台帳を、見せ方を変えて並べているだけです。案件・議事録・宿題・会社がすべて同じ場所にあるので、俯瞰の画面を別に作る必要がありませんでした。

変わった案件だけ、翌朝わかります

全部の案件を毎朝見る、ということはしていません。前日に動きのあった案件だけが、朝に届きます。

ここは、意識して絞ったところです。裏では、かなりの量が動いています。 14の入口から集めて、どの案件の話かを決めて、要約を作り直して、人と会社の名簿と照らして、全部の案件のページを組み直す。毎晩それをやっていますが、その作業が動いたこと自体は、知らせません。 私の判断を必要としないからです。

出しているのは2つだけです。1つは、更新のあった案件の一覧。どの案件に、打ち合わせが何件、やりとりが何件あって、私のコメントが反映されたかどうかまで並びます。もう1つは、今日の打ち合わせの準備。予定ごとに、前回の議事録が付いてきます。

通知の設計は「何を出すか」ではなく、「何を出さないか」で決めました。 全部知らせる通知は、すぐ読まれなくなります。読まれなくなった通知は、無いのと同じです。

見るべきものを選ぶ作業を、やめました。

どう作ったか

「管理したい」から始めると、続きません

最初に決めたのはここでした。人が入力する台帳にしない。

管理したいという動機から作った仕組みは、たいてい入力が続かなくなって止まります。忙しい日ほど書かれません。そして、忙しい日ほど大事なことが起きています。

だから台帳を、書く場所ではなく、たまる場所として作りました。台帳は入力先ではなく、出力です。

動かすのはプログラム、決めるのはAI

役割をはっきり分けました。

集める、整える、書き込む——この3つはプログラムの仕事です。決まった手順を、決まった通りに繰り返します。AIに任せているのは、要約することと、判断することだけです。

そして人は起動しません。決まった時刻に勝手に動きます。朝には終わっています。

AIに考えてもらう量を、意図して絞る

全部をAIに読んでもらう作りにはしていません。

毎日必要なものと、週に1回でよいものを分けました。軽い判断と、重い要約を分けました。渡す分量にも上限を置いています。

質を落とさずに量を絞る、というのは設計の一部です。何でも読んでもらえばよいものが出てくる、というわけではありません。

絞りすぎて、依頼を捨てていました

ただし、絞りすぎると壊れます。

やりとりが案件に関係あるかどうかを判定する処理で、本文の冒頭だけを渡していた時期がありました。長い依頼のメッセージは、前置きの挨拶で冒頭が埋まります。その結果、取引先からの依頼そのものを「関係なし」と判定して、捨て続けていました。

渡す量を増やして、取りこぼしていた分を拾い直しました。どこを削ったかを覚えていないと、静かに壊れます。

いちばん時間をかけたのは、「どの案件の話か」を決めるところでした

ここからが本題です。

集めるのは、全体の半分でしかありません。残りの半分は、集めたものがどの案件の話なのかを決めることでした。ここに、いちばん時間をかけました。

記録に残っている改修は47件ありますが、そのうち15件がこの部分です。しかも最初の週から最後まで、途切れずに出続けています。ほかの課題は一時期で収まったのに、これだけが終わりませんでした。

打ち合わせ・チャット・AIとの作業で、手がかりが違います

同じ「振り分ける」でも、材料によって手がかりが違います。

打ち合わせは、予定に付けた題名が第一の手がかりです。出席者と、話された中身で補います。そのために、会議の題名の付け方そのものを全部見直して統一しました。

チャットは、部屋の名前と相手で決まります。部屋が案件に対応していることが多いので、強い手がかりになります。

AIとの作業には、手がかりがありません。作業の中身を読んで判断してもらうしかありません。しかも1つの作業が、複数の案件にまたがることがあります。

3つとも、別の作りが必要でした。

一般的な言葉ほど、間違って結びつきます

いちばん多かった失敗は、識別する力のない言葉で結びついてしまうことでした。

会社名が入っているというだけで、まったく別の案件に入る。定例会議の名前に共通の単語があるだけで、取り違える。よく使う言葉ほど、強く当たってしまいます。

対策は2つです。識別する力のない言葉を、判定から外すこと。そして、迷ったら決めないこと。同点なら、どちらにも紐づけません。間違って入るより、空欄のほうが害が小さいからです。

案件に親子を作ったら、照合が壊れました

案件が増えてきたので、まとめ役の案件をつくって、その下に個別の案件をぶら下げました。整理としては正しかったのですが、自動処理が壊れました。

まとめ役の名前は、下にぶら下がる案件よりも短くて、一般的な言葉になります。すると、下の案件と同点になったり、まとめ役のほうが勝ってしまったりします。

まとめ役を、照合の対象から外すことで直しました。整理のために作ったものが、機械の判断を狂わせる。この種のことは、作ってみるまで気づけません。

2ヶ月半、ここだけはずっと直していました

なぜ終わらないのか、理由ははっきりしています。

案件が増えます。呼び方が増えます。材料の種類も増えます。 だから、振り分けの精度は一度作って終わりにはなりません。育て続けるものでした。

そうなると、育てる手段のほうが大事になります。人が「新しい部屋ができたから登録しないと」と気づいて手を入れる、という運用は続きません。忙しい時期ほど気づけないからです。

だから、知らない部屋を見つけたら向こうから聞いてくるようにしました。こちらは答えるだけです。振り分けが終わらない仕組みなら、終わらせないための入口を用意しておく。そういう考え方にしました。

性格は書きますが、その日の機嫌は書きません

人のことを記録するときに、先に決めたことがあります。何を書かないかです。

疲れている、機嫌が悪い、その日うまくいかなかった——こうしたことは書きません。繰り返し観測されても、「疲れやすい人」といった評価に固定しません。うまくいかなかった出来事を、その人の欠点として積み上げることもしません。

書くのは、変わりにくい部分だけです。どう進める人なのか、何を大事にする人なのか。観察できる行動として書きます。

この線を引いたのは、実際に失敗したからです。放っておくと、人の記録は感情の日記になっていきます。そしてその調子が、案件のまとめにまで移ります。

人の記録は、放っておくと評価になります。 だから、何を書かないかを先に決める必要がありました。

0件は、平和なのか、壊れているのか

自動で集める仕組みには、独特の弱点があります。届いていないことが、平穏に見えるのです。

ある部屋からのやりとりが、毎日0件で記録されていました。静かな部屋なのだと思っていました。実際には、取り込みの仕組みが壊れていて、契約に関するやりとりが1件も残っていませんでした。

いまは、一定の期間なにも届かない状態を、異常として扱います。何も起きていないことと、届いていないことは、区別しなければいけません。

そして、なぜその日に更新されたのかを、人が読める言葉で残すようにしました。理由がわからない更新は、正しくても信用されません。

この2つは、信頼性の話に見えて、手間の話です。 信じられなければ確かめに行くことになるので、信じられるようにすることが、そのまま手間を減らすことになります。

だから、自分用に作るべきです

最初にお伝えしておくと、はじめのうちは手間が増えます。 作る時間もかかりますし、動き始めてからも直し続けることになります。楽になるのは、そこを越えてからです。

越えたあとに起きたことは、3つあります。1つめは、管理にかかる手間が大幅に下がったこと。2つめは、お客様への品質が上がったこと。前回の約束も、相手が気にしていたことも、抜けたまま打ち合わせに入ることがなくなりました。

そして3つめが、いちばん大きいと感じています。案件の事務的なことに、頭を使わなくなりました。 何をどこまで話したかを覚えておく、思い出す、探す——そこに使っていた分が、考えることと決めることに回せるようになりました。

作ったのは、最初の2週間でした

動くようになるまでは、2週間でした。

そこから今日まで、2ヶ月半あります。その2ヶ月半は、全部、直していた時間です。

何を直してきたか

大きく6つの時期に分かれます。

最初は土台づくりで、打ち合わせの記録を要約するところまででした。次が、動かない理由をひとつずつ潰す時期。そして、案件ページが自動で書かれるようになり、台帳らしくなった時期。

そのあと、集める入口を広げました。次に、精度と信頼の時期が来ます。訂正が本文まで届くようにし、届いていないことを検知し、なぜ更新されたのかを出せるようにしました。最後に、案件そのものの構造に手を入れました。

直す対象が、「動くか」から「正しいか」へ、そして「信じられるか」へと上がっていったのがわかります。

直せたのは、自分で作ったからでした

ここで話が変わります。

最初に作ったものは、自分の仕事の形に合っていませんでした。それは作ってみるまでわかりませんでした。そして、合わないと気づいてから直せたのは、自分で作ったものだったからです。

できあいの道具なら、合わないまま使い続けるしかありませんでした。

そもそも、できあいの道具では届かない場所がありました

これは好みの問題ではありません。

うちの場合、打ち合わせの記録が2系統あります。やりとりの場所は5つ以上に分かれています。この組み合わせを丸ごと扱えるできあいの道具は、ありません。 しかも組み合わせは、会社ごとに違います。

さらに大きな問題があります。連携の許可が下りない相手がいるのです。

取引先の側に入って仕事をしていると、その場の管理権限は自分にありません。正式な受け口を開けてもらうには許可が要りますが、頼んでも通らないことがあります。

できあいのサービスは、「連携の許可が下りる」という前提で作られています。 その前提が成り立たない側には、原理的に届きません。

だから、正式な受け口だけには頼れませんでした。画面から読む、記録役を置く——そういう別の手を、自分で持つ必要がありました。自作は、届かせるための唯一の方法でした。

作り込む時代、合わせる時代、そしてもう一度

ここで少し、大きな話をします。

かつては、自社の業務に合わせてシステムを作り込んでいました。業務に道具を合わせたかったからです。ただ、これは高くつきました。作った人がいなくなると直せなくなり、だんだん古くなっていきました。

だから次の時代が来ます。できあいのサービスを使い、業務のほうを道具に合わせる。作り込みの負担から降りて、標準に寄せるのが正解とされました。実際、それは合理的でした。

そして、いまです。AIによって、作る負担が小さくなりました。もう一度、道具を業務に合わせられるようになったのです。

一周回って、自社に合わせる時代に戻ってきました。ただし今度は、作るのが安い。

前提が変わったのに、やり方だけ残っています

「業務をシステムに合わせる」というのは、作るのが高かった時代の合理性です。

その前提は、もう成り立っていません。今回の台帳は、動くようになるまで2週間でした。以前なら、この規模は何ヶ月もかかる話でした。

我慢して合わせる理由が、なくなっています。

自分用に作るなら

最後に、これから自分の会社で作ろうとする方に向けて、うちが通った順序を書いておきます。

1. 入力してもらう台帳にしない。 台帳は、書く場所ではなく、たまる場所として設計します。

2. 動かすのはプログラム、決めるのはAI。 集める・整える・書き込むは自動で回し、AIには要約と判断だけを頼みます。

3. 自分の情報源を、全部入口にする。 どこでやりとりしているかは会社ごとに違います。ここが、いちばんオリジナルになる部分です。

4. 振り分けは、自分たちの呼び方に合わせて育てる。 正式名称ではなく、実際に使っている呼び方を登録して、増やし続けます。ここが核心です。あわせて、分からないものは向こうから聞いてくる形にしておきます。育てる作業を人の気づきに任せると、続きません。

5. 何を書かないかを、先に決める。 特に、人に関する記録は先に線を引きます。

6. 信じられるようにする。 更新の理由を残し、届いていないことを検知します。信じられて初めて、手間が減ります。

7. 使いながら直し続ける。 作ったあとのほうが、長い。直せる形で作っておきます。

使っている道具

参考までに、いま動いているものを並べておきます。特別なものは使っていません。

数えると、つないでいる先は14種類あります。打ち合わせの記録が2つ、やりとりの場所が6つ、そのほかが6つ。この組み合わせは、うちの仕事の形そのものです。

ここで強調したいことが1つあります。プログラムに追加した部品は、ほぼゼロです。 Python にもとから入っているものと、AIを呼ぶための部品だけで動いています。

「自分用に作る」と聞くと大掛かりに思えますが、実態はこの程度です。新しい基盤を導入したわけでも、専用のサーバーを立てたわけでもありません。すでに使っている道具を、つなぎ直しただけです。

まとめ

1. 自分の事情に合わせた自動の仕組みを、机の上ではなく、使いながら作りました。
何が合っていないかは、動かしてみるまでわかりません。作る期間より、直す期間のほうが長くなります。

2. その結果、台帳の品質が上がりました。
人が書くより正確になりました。書き漏らさず、忘れず、都合の悪いことも残ります。

3. 品質が上がったから、確かめに行かなくなり、管理の手間が減りました。
自動化が手間を減らすのではありません。信じられるようになって、初めて減ります。

作るコストが下がったいま、道具に合わせて業務をゆがめる理由は、以前より小さくなっています。

データも人もAIも、つながるから、先がある。

あなたの会社の情報は、いまどこに散らばっているでしょうか。

作り方は、3本のノートに分けて書きました。

• 作り方ノート①「要約の質は、AIに渡す材料で決まっていた」 👉 AIの要約が浅いのは、渡している材料が足りないから
• 作り方ノート②「集めたあとの仕分けに、2ヶ月半かかった」 👉 APIで取れないチャットを集めて、案件ごとに仕分ける
• 作り方ノート③「案件と、人と、会社。3つの名簿を持つ」 👉 案件・人・会社の3つの名簿を、1つの台帳につなぐ

実際にどう作ったか、どこでつまずいたかは、体験談としてこちらにまとめています 👉 案件の状況を、自分で思い出すのをやめた話（X）

石井 亮介（りょうさん）

データパレード 代表取締役

XContact

㈱データパレードの代表取締役で、高田馬場の町中華「一番飯店」のChief Data Officerも務めています。BIツールのセールスエンジニア・システムエンジニア・カスタマーサクセス歴15年。大学のデータサイエンス教育で講師も担当してきました。現在は自社業務のほとんどをAIに移管し、AI10部署と50を超える自動処理が24時間動く「AI経営」を実践中。その実践知をこのブログで発信しています。