システムと遅延

遅延が直感に反して示される場所 休暇シーズン中に1、2週間家（そして国）を離れるのは、私の典型的な自由時間の過ごし方（YouTube、Lobste.rs、HackerNews、BlueSkyに費やしすぎている）から抜け出して、何か別のことを試すのに最適な時期です。最近の休暇では、ビットマップフォントを作るためのグリッド用紙と、2冊の本を持って行きました。1冊目は、チェコを舞台にした「Fallout」風のMMOゲームのインスピレーションを得るためのチェコのポストアポカリプス小説、2冊目は、職場で勧められ（そして会社の教育予算で購入した）、「システム思考」という、数ヶ月間本棚で埃をかぶっていた本でした。この3つの目標すべてを達成できたことを発表できることを嬉しく思います。ビットマップフォントを作成し（カーニングとアクセントはまだですが）、ポストアポカリプス小説を読み終え（まあまあでした）、システムの本も読み終えました！ 『Thinking in Systems』は、ソースとシンク、ストックとフロー、フィードバックループ、そしてそれらから（多くの場合）ボトムアップで現れるシステムというフレームワークとビジュアル言語を紹介しています。これらはすべて数学モデルや微分方程式と大まかに対応していますが、本書ではそれらの詳細には踏み込まず、例の実際の数式は付録にのみ記載されています。 遅延は奇妙です この本全体の見どころだと私が思う、本当にクールな章が1つありました。それは遅延に関するものです。継続的な例（上記の画像を参照）は、車のディーラーのマネージャーが、販売台数の10倍の在庫を常に維持することを目指して、駐車場にある車の在庫を管理しているというものです。顧客の需要が増加すると、彼女はギャップを埋めるために、より多くの車を発注し始めます。 遅延のないシステム 理想的な世界では遅延はありません。彼女は需要の増加を即座に認識し、現在の在庫と理想的な在庫との乖離を認識し、すぐに車を追加で注文し、車は即座に到着します。また、この例では時間の粒度は日単位なので、1日の終わりに30台の車が売れたことを認識し、30台の車を発注し、翌朝それらが到着すると想像してください。 まず、遅延の影響を受けないモデルの定数をいくつか見てみましょう。顧客の需要は1日あたり20台で始まりますが、その後1日あたり22台に増加し、特定の日には70台の急増があります。売上は min(顧客需要, 在庫) です。これは以下のすべての例で顧客需要と等しくなります。なぜなら、十分な車が用意されているからです。しかし、需要が十分に速く高くなった場合、在庫切れになる可能性があると想像できます。マネージャーは、売上 × 10 として望ましい在庫を計算します。単純すぎるかもしれませんが、これは例です。過去N日間の売上を平均化し、それに基づいて望ましい在庫を決定することも考えられます。これにより、システムにさらに別の遅延が導入されますが、このブログ投稿では、私が説明したいことには触れないため省略しました。 では、遅延のないモデルはどのように振る舞うのでしょうか？ちなみに、私は本を読みながらElmでモンテカルロシミュレーターを自分で書きました。このブログ投稿の例の疑似コード数式がリストされています。しかし、スプレッドシートでも十分ですし、これらの微分方程式モデルを扱う他のツールもあります。さらに、JSライブラリを基にした無料のグラフィカルWebアプリには、私がここで示しているのと同じ例の1つが紹介されています。この本は影響力があるのでしょう。 このモデルには遅延はありませんが、ランダムな顧客需要の急増に過剰反応して、売れるのに永遠にかかる車を買いすぎてしまうという問題があります。そして、より重要なのは、これは非現実的であるということです。現実世界では、すべてに多少の遅延があります。注文の処理には時間がかかり、車がディーラーの駐車場に到着するのにも時間がかかります。 これを配送遅延と呼びます。それは悪い遅延のように思えますが、遅延は常に悪いとは限りません。マネージャーがランダムな急増に過剰反応したくないと考えていると想像してください。彼女は、通常1日あたり約20台しか注文しないのに、急増のために550台も注文しました！代わりに、彼女は差額の半分、または3分の1などを注文するだけで、望ましい在庫にゆっくりと到達したいと考えるかもしれません。もし翌日状況が正常に戻れば、過剰反応することなく、波にずっとスムーズに乗ることができるでしょう。この除数を応答遅延と呼びます。 遅延のあるシステム これらの2つの遅延を考慮してモデルを実行し、結果を見てみましょう。 配送遅延：5日（私が注文してから車が駐車場に到着するまで） 応答遅延除数：2（乖離が30台の場合、今日は15台しか注文しません。） 何が起こったのか？ すべて正しくやっていると思っていたのに、応答遅延は良いことだと思っていました。まあ、それは良いことです。しかし、2つの遅延の組み合わせがシステムを発振させてしまいました！顧客の需要がその後一定に保たれたとしても、システムは決して安定しません。マネージャーは、車を注文しすぎ、最初の注文が到着する前に次の数日間さらに注文し続けるという、ひどいサイクルに陥っています。注文が到着し始めると、彼女は今度は車が多すぎると感じ、在庫が理想的なレベルに戻るのを待つ間、それ以上注文しないようになります。しかし、その後、さらに車の販売が進むと、在庫は再び理想を下回り、彼女は再びサイクルを開始します。 これらの発振が避けられない数学的な理由を知りたいです。これらのモデルと微分方程式に関する、より数学的な本がおそらくそれを説明してくれるでしょう。今のところ、遅延によって引き起こされる発振を事実として受け止めましょう。 短い遅延：確かに解決策か？ 遅延が私たちをこの混乱に陥れたので、できる限りそれらを最小限に抑えるべきだと考えるかもしれません。フィードバックループを短くするなど。しかし、覚えておいてください、私たちはランダムな急増に対してより回復力があるように応答遅延を導入しました。いずれにせよ、試して何が起こるか見てみましょう。 配送遅延：5日（この遅延は早めることができません） 応答遅延除数：1（できるだけ速く：一日の終わりに不足している正確な金額を購入します。） うーん。ご覧のとおり、速くしようとしたことが事態を悪化させました。在庫の車は今、より大きく発振しています。220台程度にしたいのに、132台から518台まで急増しています。急増後に一度に1160台もの車を保有する必要があることは言うまでもありません！これは遅延のないシナリオよりもさらに悪いです！希望はありますか？ 長い遅延：落ち着け、君。 何が起こるかを見るために、より忍耐強いマネージャーをシミュレーションしてみましょう。つまり、より長い期間をかけて補充を行うマネージャーです。応答遅延除数を大きくして6にしてみましょう。一日の終わりに30台の乖離が見られた場合、10台や15台、30台ではなく、5台だけ注文することにします。 配送遅延：5日（まだ制御不能） 応答遅延除数：6（より遅い応答！より長い遅延！） すごい！発振は消え、安定しました！ 結論 これは私が読んだときに非常に直感に反するものでした。遅延は直感的には最小限に抑えたいもののように思えます。しかしここでは、遅延を短くすると状況が悪化し、長くすると予測可能で無駄が少なくなりました。本の後半でドンベラ・メドウズは短いフィードバックループに言及していますが、盲目的に適用できる明確なルールはありません。あなたのシステムをモデル化し、さまざまなパラメータを試して、それがどのように振る舞うかを見てください。多くのマネージャーやリーダーは、研究者が提供するレバーを手に取り、全速力で、間違った方向に回します。正しい方向がわかっていると思っているかもしれませんが、もしかしたら、両方の方向でシステムがどのように振る舞うかについての洞察を得て、直感ではなくデータに基づいて行動してみてはいかがでしょうか。 P.S. この例のトイシミュレーターで自由に遊んでみてください。コードはGithubにあります。 <前の投稿LLMスペクトラムと責任あるLLMの使用アーカイブブルースカイGithub