タスクは、投げるものじゃない。
なぜPaqutが生まれたのか。一通の転送メールから始まる話。
ChatWorkに届いた、一通の転送メール。文面は、どこまでも丁寧だった。それなのに、読み終えたとき、ひどく孤独だった。
株式会社○○
○○様
お世話になります。○○の○○です。
ご連絡が遅くなり申し訳ございません。
現状、弊社にて使用しております在庫管理の資料になります。
（期間：6月11日（木）〜6月14日（日）分）
①検品ノート：日々ノートへ手書き（仕入価格は黒塗りしています）
②在庫表：日々エクセルにて入力（黄色部分に数量を入力）
ご確認お願い申し上げます。
実際に届いたメッセージをもとに、取引先が特定されないよう業種・内容を変えて再現しています
誰も悪くない。
担当者は、丁寧に転送してくれた。エンドユーザーは、ちゃんと連絡してくれた。全員が礼儀正しく、全員が正しかった。それなのに、誰も「一緒」じゃなかった。
受け取ったのではなく、投げられた、という感覚。この一文が、今も変わらない。
プロジェクトの課題管理は、Excelで作っていた。列に項目を並べて、担当者を書いて、期日を入れた。作ったそばから、ずれていった。実際のやり取りはメールで動いていたから、メールで決まったことをExcelに反映し忘れると、どこが正しい状態なのかわからなくなる。ツールの外で、仕事が動いていた。
敵は、人ではなかった。「仕事を投げる構造」そのものだった。
機能を足すのは、簡単だった。
タイムライン。ガントチャート。承認フロー。それを全部入れれば、既存のツールに近づける。ただ、それは自分が解きたい問題ではなかった。自分が感じた孤独は、機能の不足から来ていなかった。
削ることを選んだ。チームで今何が起きているかが見えること。進んだことが、みんなに伝わること。タスクに感情が乗せられること。その最小限だけを残した。
不安は、消えなかった。「シンプルにするほど、他のツールと同じに見られて、誰にも選ばれないのではないか」——その声は、ずっとそこにあった。答えは出ないまま、ユーザーに会いに行くしかなかった。
ある顧客システム担当者と、仕事を進めていた。30代の方だった。
Paqutを使って、やるべきことを共有しながら動いていた。課題を一つ完了にすると、次が見える。確認が返ってくる。また前に進む。お客様には、入力や確認の操作が面倒ではないだろうかと、ずっと気になっていた。
ある日、会話の流れの中で、その方がさりげなく言った。
何が残っていて、何が完了したかが一目瞭然で。仕事が、前に進んでいる実感がある——と。
求めた感想ではなかった。報告でも評価でもなく、ふと漏れた言葉だった。だから、そこに本音があった。
画面の向こうの相手が、同じ感覚を持っていた。自分が感じていた「ゴールに一緒に近づいていく感覚」を、相手も感じていた。同じ方向を見て、仕事が進んでいた。
いけると思った。
別のユーザーが、こう言った。
「伝えたいことが、伝えにくい」
タスクに書けるのは、やるべきことだ。でも仕事の中には、まだタスクになっていないものがある。迷っていること、確認したいこと、ちょっと聞きたいこと。それは、タスクとして書けない。
タスクだけでは、人が仕事で伝えたいことの全部は運べなかった。
そこから「相談」が生まれた。タスクになる前の会話を、同じ場所に置ける機能。構造としては小さいが、意味は大きかった。「作業の依頼」ではなく「一緒に考える」場所が、ツールの中にできた。
このストーリーは、終わっていない。批判が、次の章を書く。
Paqutという名前は、「パクッ」から来ている。
チームの仕事を、パクッと食べてしまう。重たかった管理が、軽くなる。そのイメージから名づけた。
発音は「パクット」。どこかに抜けた感じが、あってほしかった。
優先順位の確認も、わからないことの相談も、お礼を伝え合うのも、ぜんぶ同じ場所で済む。
そのプロジェクトが終わったとき、チームのみんなが「このメンバーで仕事ができてよかったね」と笑い合っている。そういう瞬間が、もっと増えてほしい。
その写真に、Paqutは写っていない。それでいい。
タスクは、投げるものじゃない。
一緒に運ぶものだ。