Slack の 👍 を、アプリの承認に移す

この記事は、自社の業務アプリ DataParade Core の事例の一部です。全体は 特設ページ にまとめています。

この記事が満たす要求: 「判断が要るときだけ鳴る」（特設ページ /00 の一覧）

AIが下書きを作り、人が承認して、仕組みが投稿する。この流れは、以前はSlackの中にありました。下書きがスレッドに届き、👍を押せば投稿、👎なら見送り。動いてはいましたが、案件ごとにチャンネルが違い、どこで何を待たれているかは、Slackを順に見るしかありませんでした。

承認をアプリに移しました。承認待ちは1つの画面に並び、ホームの「今、最初にやること」のいちばん上に来ます。何を移し、何を移さず、案件ごとに違う段取りをどう1つの仕組みに載せたかを書きます。

アプリがやるのは「並べる」「決める」だけです

承認待ちの画面は、下書きを並べ、承認するか見送るかを受け取るだけです。実際の投稿は、元の仕組みがやります。ブログを公開する処理、ボットが投稿する処理は、以前のまま動いています。

承認待ちの中身を入れるのは、Macの側の道具です。下書きを作った仕組みが、承認待ちの表に1行入れます。アプリはその表を読んで並べ、決めた結果を表に書き戻します。元の仕組みは、投稿の直前に表を読み、承認されていれば投稿します。

投稿の処理をアプリに持ってこなかったのは、持ってくると2か所で同じことをすることになるからです。同じ処理が2か所にあると、片方だけ直して終わります。

段取りは案件ごとに違います。並びは表が持ちます

承認の段取りは、案件ごとに違います。技術ブログは、内容の承認と投稿の承認の2段で、承認したあと定時の処理が公開します。ボットの投稿は1段です。使っていない案件の片付けも1段で、承認したものだけを次の朝の棚卸しが消します。

段の数も並びも、台帳の表が持っています。アプリにも、承認を受け取るプログラムにも、案件の名前や段の名前は書いてありません。表を読むだけです。段を増やしたい案件が出てきたら、表に行を足します。

案件ごとに承認の画面を作り分けると、案件の数だけ画面を保守することになります。案件ページの「積む塊」と同じ考え方です。違いは表に、共通は仕組みに。

判断できるのは「判断待ち」のものだけです

承認も見送りも、「判断待ち」の状態のものにしか効きません。すでに承認したものをもう一度承認しても、何も起きません。押し間違いの二重判断を防ぐためです。

画面には、判断待ち、実行済み、期限切れ、見送り、が分かれて出ます。期限切れは、予定の時刻を過ぎても判断が無かったものです。何が起きたかを、あとから追えます。

見送りには一言を添えられます

見送るときは、一言を添えられます。「日付が古い」「この言い回しはやめる」。この一言は、元の仕組みに伝わります。ボットの投稿なら、下書きが退避され、次の下書きの材料になります。技術ブログなら、直しの指示として扱われます。

一言は必須ではありません。承認は1タップです。「決めるだけでよい」を崩さないためです。理由を書かせると、押すのが遅れます。書きたいときに書ける、が正しい位置でした。

何もしなければ、予定の時刻に自動で出ます

承認待ちには、予定の時刻を持つものがあります。ボットの投稿は、決めた曜日の決めた時刻に出ます。何もしなければ、予定の時刻に自動で出ます。

「承認しないと出ない」にすると、承認を忘れた分だけ投稿が止まります。「見送らないと出る」にすると、止めたいものだけを止めればよくなります。どちらにするかは案件ごとで、これも表が持ちます。案件の片付けは逆で、承認したものしか消えません。消す方向は、黙っていて進んではいけないからです。

Slackと並走し、先に決めた方が勝ちます

移した直後は、Slackの👍とアプリの承認を並走させました。どちらで決めても、先に決めた方が勝ちます。投稿の直前に、アプリの判断をSlack側の状態に写す処理が走ります。

並走の期間を置いたのは、アプリだけにして止まると、投稿が止まるからです。並走のあいだにアプリだけで回ることを確かめ、確かめられたものからSlack側の送信を止める、という順にしました。何を止めるかの一覧は、案件のページに残しています。

「承認」の2文字から、AIが案件を創作しました

Slackで承認していたころの話です。承認依頼のスレッドに「承認」と返したところ、ボットが「○○さんの△△案件、これでいけるということですね」と返しました。そんな案件は存在しませんでした。

原因は、スレッドの返信を受けたボットが、親の投稿を読まずに、2文字だけをAIに渡していたことです。入力が短いほど、AIは文脈を創作します。直したのは、承認・同意・指示の受領は、必ず「何に対してか」を復唱して返す。復唱できなければ、それらしく答えず「特定できないので教えてほしい」と返す。この2つです。

アプリの承認待ちには、この問題がありません。押した行そのものが「何に対してか」です。承認をアプリに移した理由の1つは、これでした。

移さないと決めたもの

Slackにあった運用の全部を移したわけではありません。移す前に一覧を作り、1つずつ決めました。

朝の便に1行入っていた支出の集計は、廃止しました。返信の漏れを見張る仕組みも廃止し、アプリに返信の画面も作りませんでした。週次と月次の文章の報告は、盤があるので移しません。中身の無い目標の欄も、移しません。

移すか廃止するかを決めるときに見たのは、「移した先で誰が見るか」です。見る人のいないものを移すと、見る人のいない場所が1つ増えるだけです。

まとめ

• アプリは並べて決めるだけ。投稿は元の仕組みがやる
• 段の数も並びも表が持つ。案件ごとの分岐を仕組みに書かない
• 判断は判断待ちにしか効かない。見送りには一言を添えられる
• 並走して先に決めた方が勝ち。回ることを確かめてから、元を止める

Slackを順に見て「何を待たれているか」を探すことがなくなりました。開いた瞬間のいちばん上に、承認待ちが並びます。

自社の業務アプリの全体像は 特設ページ に。

石井 亮介（りょうさん）

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

XContact

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