AIを使うと、同時に動かせる仕事の量が増える。
1人のエンジニアが、AIと一緒に複数のモジュールを並行して開発できる。1人のデザイナーが、複数のバリエーションを同時に試せる。1人のライターが、複数の記事の初稿を同時に出せる。これは間違いなく生産性の向上だ。
でも、問題が一つ起きる。「今、何がどこにあるか」が見えにくくなる。
並行作業が増えると何が起きるか
並行して動くものが増えるほど、「どれが完了していて、どれが途中で、どれが止まっているか」の把握が難しくなる。
1つのタスクを1つ仕上げる順番待ち型の仕事なら、今何をやっているかは明白だ。でも10個のタスクが同時に「対応中」の状態になると、そのうちのどれが今誰の手元にあるのか、どれがレビュー待ちなのか、どれが詰まっているのかが、外から見えにくくなる。
自分の作業が増えた分、外注先やチームメンバーに渡したものの状態が見えにくくなる、という逆説が起きる。
「渡した」と「完了した」の間に時間がある
AIで実装が速くなった結果、「作って渡す」のサイクルが短くなった。1日に複数の機能を作って、クライアントに確認依頼を出す。外注先に2件の仕様を送って、どちらも着手してもらう。
このとき、「渡した」と「完了した」の間に時間がある。クライアントが確認中だったり、外注先が対応中だったり。でもその時間、こちらから見ると「止まっている」ように見える。本当に止まっているのか、単に時間がかかっているだけなのか、詰まっているのか——状態が見えないと区別できない。
チャットでやりとりしていると、「渡した」というメッセージは流れていく。その後の状態は、改めて「どうなってますか」と聞かないとわからない。
タスクの状態を見れば聞かなくて済む
解決策はシンプルだ。渡した仕事をタスクとして持ち、受け取った側がステータスを動かす設計にすること。
タスクのステータスが「対応中」「レビュー待ち」「完了」のどれかになっていれば、「今どこにあるか」を聞かなくてもわかる。タスクを見れば状態がわかる。
並行して動いている10件のタスクがあっても、全部のステータスが見えれば「今日確認が必要なもの」「詰まっていて声をかけるべきもの」「もう完了しているもの」を区別できる。
「止まっているタスク」に声をかける
並行作業の多いプロジェクトで最もコストがかかるのは、止まっているものを見つけることだ。
毎日チャットで全員に「あの件どうですか」と聞いていたら、それ自体がボトルネックになる。でも聞かないと止まっていることに気づかない——これが確認連絡が増える構造だ。
タスクのステータスが見える設計にしておくと、「3日間ステータスが動いていないタスク」が目に入る。そこに声をかければいい。全員に聞くのではなく、止まっているタスクだけを対象にできる。
並行させるほど、状態の設計が重要になる
AIで手が増えた結果、「渡す」ことは増えた。渡すだけでは状態が見えない。状態が見えないと、どれが詰まっているか、どれが完了しているかを追いかけ続けなければならない。
AIで並行作業が増えた分だけ、タスクの状態設計が重要になる。チャットで渡してチャットで追いかける設計のままだと、手が増えた分だけ追いかけるコストも増える。
渡したものをタスクとして持ち、状態を可視化する。これが、AIで手を増やしながらプロジェクトを制御するための設計だと思っている。
並行して動く外注先・クライアントのタスクの状態を可視化しながら仕事を進める設計をPaqutで試せます。ゲスト招待は何人でも追加料金なし。
関連記事
確認設計の前回:確認が増えたのは、仕事が増えたからじゃない。
決定履歴の残し方:仕様は変わる。でも「誰が何を決めたか」は残せる。
AIと意思決定ボトルネック:AIが実装を速くした分、意思決定が遅いことが目立つようになった
完了の定義(次回):AIが実装した。でも、誰が「完了」と判断するか。