SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

人生を『変化するシステム』として捉える

AIで仕事は速くなった。なぜ忙しさは減らないのか #2

「できた」は、役に立ったかどうかより先に届く

 では、確認待ちが増えているのに、なぜ作成の高速化を続けるのでしょうか。依頼者が受け取る結果には、早く返るものと、遅れてしか返らないものがあります。「資料ができた」という報告は、提出した時点で届きます。その資料で利用者が判断できたか、足りない情報を聞き直したかは、使われるまでわかりません。

 行動からその影響が現れるまでの時間差が遅延です。遅延は結果を待ちきれずに諦める原因にもなります。しかし、今回の職場では逆のことが起きています。遅い結果が届く前に早く返った結果だけで成功と判断し、次の仕事を増やしているのです。AIで作成と提出だけが速くなり、そのたびに次の仕事を受けるなら、確認や利用の結果が返るまでに引き受ける件数はさらに増え得ます。

 [t:;600]

 観測するもの いつ見えるか その時点でわかること

 作成時間・提出件数 作成して提出したとき 作成工程で処理できた量

 確認待ち・差し戻し 確認工程に入ってから 後の工程に残る負担

 利用者の判断・追加の問い合わせ 資料が使われてから 目的に役立ったかどうか

 「フィードバックを速く回す」という言い方だけでは、どの行を戻すのかが抜けています。提出件数だけを仕事の配分へ戻せば、増えるのはまず提出です。確認待ちが依頼者へ伝わらないままなら、後の工程で負担が増えていても、作る側には増産をやめる理由が届きません。連絡の頻度を上げても伝える中身が同じなら、このずれは残ります。

 遅い結果が届くまで、すべての仕事を止める必要はありません。確認を終えた仕事と、まだ確認していない仕事を分けて、次に受ける量を判断します。利用者に届いた後の見直し日も決めておけば、早い報告だけで成功が確定するのを防げます。欠陥や差し戻しが増えた場合は、その日を待たずに受け方や確認方法を変えます。

 完了報告だけで次を増やすと、成果がわかる前に仕事量が決まります。

確認待ちがなくなれば、早く帰れるようになるのか

 ここで、作成だけでなく確認も速くなり、確認待ちがなくなったとします。資料は必要な品質を保ったまま、以前より早く利用者へ届きます。先ほどは作成担当の時間だけを測っていましたが、今回は利用者にも届いた改善です。では、その職場の人は早く帰れるでしょうか。確認を速くしても空いた時間を何に使うかは、まだ決まっていません。

 仕事を割り当てる人が「勤務時間は作業で埋める」ことを目標にしているとします。作業が速くなって空き時間が生まれると、この人にとっては目標との差が広がります。そこで次の仕事を追加し、空き時間を減らします。この差は縮まります。この循環が働いているなら、作業を速くしても忙しさは元へ戻ります。

 決めた目標といまの状態との差を縮める向きに働く循環を、調整ループ(バランスループ)と呼びます。強化ループと並ぶ、もう一つの循環です。戻る先は過去の状態とは限りません。目標が変われば、同じ調整の働きが別の状態を保ちます。

 この職場の調整ループが目指しているのは作成担当の時間を埋めることです。確認待ちを減らすことは目標に入っていません。先ほどの強化ループは提出を増やし、この調整ループは空き時間を埋めます。速くなって浮いた時間は追加の仕事に使われるので、作成がどれだけ速くなっても余白は残りません。

 この目標が、「空き時間をゼロにする」と明文化されているとは限りません。早く終わるたびに次の仕事が入り、休息や学習には時間が配られないなら、その配り方から目標を推測できます。ただし、仕事を渡す人の本心を言い当てる話ではありません。見るのは、空き時間が生まれた後に、実際に何が追加されたかです。追加の仕事がないのに帰る時刻が変わらないなら、勤務時間の固定や別の義務など、この循環の外にある条件を調べます。

 確認待ちが残っている実際の職場へ戻ります。この職場では空き時間を埋める代わりに、確認待ちを許容できる範囲へ戻す調整を選べます。

 まずは仕事を割り当てる人と確認担当が、待ちの許容量を決めます。期限内に確認できる件数から決めた上限です。待ちがこの許容量を超えたら、新たに確認へ回す資料を減らし、残っている資料の確認を優先します。回さなかった資料が作成担当の手元にたまるだけでは意味がないので、新たに引き受ける仕事も一緒に減らします。

 (−)の矢印は、他の条件を同じにして前の量を増やしたとき、後ろの量を減らす向きの影響です。前の量を変えなかった場合との比較なので、実際の件数が減るとは限りません。確認を終える件数が増えても、それ以上に提出が増えれば、確認待ちは増えます。

 この図を一周してみます。確認待ちが増えると、許容量を超えた分が増えます。超えた分が増えると、新たに確認へ回す件数は減ります。回す件数が減れば、最初に増えた確認待ちは抑えられます。提出が次の提出を増やした強化ループとはここが異なります。

 調整ループと呼ぶのは、仕事を減らしたからではありません。測っている待ちと許容量との差が、次に受ける量を変えているからです。なお、確認を終える件数そのものが落ちているなら、受付を絞るだけでは足りません。確認の手順や担当の配置も見直します。

調整を強めれば、安定するのか

 待ちを減らそうとしているのに受付を絞る週と、一気に増やす週を繰り返すことがあります。たとえば、仕事を割り当てる人が前週の確認待ちの数字を見て、今週の受付量を大きく変える場合です。実際にはもう待ちが減っていても、古い数字を見て受付を絞り続けます。逆に、待ちが少なかった週の数字を見て受付を増やせば、手元の資料がたまり始めても気づくのは翌週です。

 目標へ戻そうとする働きはあるのに、判断が現在の状態に追いついていません。調整ループは、遅れた情報で強く動かすと、落ち着かせたい量をかえって揺らすことがあります。

 報告を早くすれば、この遅れは縮められます。それでも別の遅れは残ります。受付を減らしても、すでに受けた資料の確認が終わるまでには時間がかかるからです。数字が届くまでの遅れと、手を打ってから効果が出るまでの遅れは分けて見ます。

 受付量を変えられる人は、次の三つを並べます。確認待ちの記録を更新した日、前に受付を変えた日、その後に新たに提出された件数と確認を終えた件数です。受付を絞った後も、以前に受けた資料の確認は続いています。だから、待ちがまだ多いという理由だけで制限を重ねるのではなく、提出が確認を下回って待ちが減り始めているかを確かめます。

 反対に、受付を変える前から依頼の総量そのものが増減しているなら、揺れの原因は調整の遅れだけではありません。外から来る依頼の波と、自分たちの受付の変え方が作った波を区別します。

増えるものと、戻るものは同じとは限らない

 ここまでに三つの循環を見ました。三つは同じ職場で同時に働き得ます。「この職場は強化ループか、調整ループか」と一つを選ぼうとすると、それぞれが見ている量の違いを落とします。提出件数が増え続ける一方で、作成担当の空き時間はいつもゼロ付近に戻るということも起こります。仕事が増えることと、余白が残らないことは矛盾しません。

 [t:;600]

 循環 結果から配分へ戻る経路 何が変わるか

 提出を増幅する強化ループ 提出実績が次の割り当てを増やす 処理できる間は、提出の増加が次の増加につながる

 空き時間を埋める調整ループ 空き時間が生まれると追加の仕事を渡す 空き時間は減るが、仕事量は増える

 確認待ちを減らす調整ループ 待ちの超過を見て受付量を抑える 確認待ちの増加を抑える向きに働く

 強化と調整という名前だけでは、互いに打ち消し合うかどうかは決まりません。最初の二つは、どちらも仕事を増やす側へ働きます。三つ目は、確認待ちの数字を仕事を割り当てる人へ届けることで、その追加を抑えます。同じ調整ループでも減らそうとしているのが空き時間なのか、未確認の資料なのかで選ぶ行動は変わります。

 どの循環が強く現れるかも途中で変わります。確認待ちが少ない間は、提出の実績を見て割り当てが増えます。待ちが許容量を超えた後は受付の制限が働き、増加が止まるかもしれません。

 ただし、件数が頭打ちになっただけでは制限が効いたのか、依頼そのものが減ったのかを区別できません。待ちがいつ許容量を超え、誰がどの数字を見て割り当てを変えたかを追います。図の形だけでは、いつ増加が止まるかまでは決まりません。

次の割り当てまで機械が決めるなら

 ここまでは、人が提出の実績を見て、次の仕事を渡す場面を考えました。次に、この割り当てをAIを含む自動化の仕組みに任せる場合を考えます。機械は資料を作るだけでなく、人や別の機械へ次の仕事を割り当てます。成功の記録として提出件数だけを渡せば、その件数を見て追加の割り当てが決まるところまで、人が毎回判断しなくても進みます。早く返る完了報告と、遅れて分かる確認の負担とのずれが、そのまま機械の次の行動を決めます。

 この場合、人が確認待ちの数字を後から眺めるだけでは、追加の割り当ては止まりません。自動化の範囲を決める人が、割り当ての条件に二つを含めます。確認待ちが許容量を超えていないか、そして、確認待ちの記録が古くなっていないかです。

 確認待ちが許容量を超えたときや、確認状況を取得できないときは、新たな割り当てを保留するという設計が候補になります。保留した案件は、状況を見直す担当へ返します。人が気づくまでに増えた仕事も残るので、すでに受けた仕事の期限と担当をたどれるようにしておきます。

 条件を書いたことと、条件どおりに止まることは別に確かめます。試験環境で確認待ちを許容量より多くしてみて警告が出るだけなのか、実際に次の割り当てが保留されるのかを見ます。確認待ちの記録を取得できなかった場合も、待ちがゼロの場合とは区別されなければなりません。警告は増えるのに割り当てが続くなら、表示する情報を増やす前に、判定の結果が割り当てに反映される仕組みを直します。

 誰かが最後に責任を持つと決めても、その人に停止や割り当て変更の権限がなければ、この循環には介入できません。保留した後に何を確かめれば再開するかも決めます。行き違った依頼を誰が取り消し、誰が期限を調整するかも同じです。仕組みを使い始めた後は、提出の実績を見て何件の仕事が追加されたかを追えば、意図した範囲で動いているかを確かめられます。割り当てるのが人でも機械でも、増えた仕事は同じ確認担当のところへ届きます。

次のページ
増やしてよい仕事を、どの結果で見分けるか

この記事は参考になりましたか?

人生を『変化するシステム』として捉える連載記事一覧
この記事の著者

nwiizo(ヌウィゾウ)

インフラエンジニアとしてホスティングサービスの開発・運用に携わり、深夜のオンコール対応をきっかけに、運用のあり方を本気で考えるように。現在は株式会社スリーシェイクにソフトウェアエンジニアとして在籍。技術書の翻訳や書籍の執筆をいくつか手がける。本を作ると、わかることが1つ増えるのと引き換えに、わからな...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/29769 2026/09/28 08:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー