みんなが忙しいと、
プロジェクトは早く終わる?

toku345

はじめに

日々感じていることを、なんとか目に見える形にしたくて、ChatGPTと一緒にシミュレーターを作りました。

忙しさとプロジェクトの進み方について、一緒に考えるきっかけになればと思っています。

今回のシミュレーターは、数学的な厳密さや、現実との一致を検証したものではありません。実際のチームの結果を予測するものでもありません。

予定が埋まっていると、急な依頼はどうなる?

それぞれのプロジェクトで、予定が埋まっている。
そこへ、別のプロジェクトから相談や結合確認、レビューの依頼が。

今すぐ対応する

その間、自分の作業を中断する

対応している間、手元の作業はいったん止まる。

後で対応する

相手の作業が返答待ちになることも

こちらの対応が必要な部分は、返答があるまで進められない。

急な依頼を受け止める余裕を、手術室の例で考える

急な手術を、どこで受け止める?

同じ4室・4チーム、同じ手術。各室に担当チームを固定して比べます。

A:全4室で混在

4室に予定手術を入れる

急患は、次に空く部屋と担当チームが受け入れる。

B:緊急用の1室を確保

予定は3室・3チームへ

緊急対応には、専用の1室・1チームを確保する。

手術室シミュレーター

変えるのは、部屋・チームの割り当てと予約時刻。別室との医師・スタッフの兼務は扱いません。

開発の話に戻って、仕事の進め方を考える

手が空いたとき、どうする?

実装・レビュー・検証。ひとつのプロジェクトに、複数人が関わる。

方針A:各自の予定を埋める

手が空いたら、次のプロジェクトへ

担当作業が終わったら、次の案件に着手する。
誰も手が空かないように、同時進行の件数を増やす。

方針B:チームの同時進行数を絞る

進行中のプロジェクトを支える

例えば、チームで進める案件を最大3件に絞る。
手が空いた人は、サポートや突発的な依頼に対応する。

チーム開発シミュレーター

実演では、Aは1件に1人で実装、Bは最大3件・1件に最大2人で実装。
両方ともレビューを優先し、2人なら実装が2倍進む仮定です。

みんなが忙しい。
それで、プロジェクトは進んでいる?

自分の作業が終わっても、プロジェクトが終わるとは限りません。

実装
→
レビュー
待ち
→
レビュー
→
検証待ち
→
検証
→
完了

次の仕事を始める前に、
進行中のプロジェクトを前に進められないか。

レビューを返す。困っている人を手伝う。急な相談を受け止める。

補足 / 研究の出典と、モデルの前提

何に基づき、どこまで言えるか

2014年:運用変更の前後比較

17室のうち3室を予定外手術用に変更。予定手術の時間外手術時間が26%減少。

緊急度分類・予約ルールも同時に変更。専用室だけの効果とは判断できない。

2013年:緊急専用室の導入前後

緊急手術の割り込みによる予定手術の中止や、予定手術室の時間超過が減少。

今回の手術室シミュレーター

説明用の架空モデル。論文のデータや結果を再現したものではない。

数値は実際の病院の予測・人員配置には使えない。

医療の事例を開発の正解にはしない。協力すれば必ず早くなる、届く数が増える、とも言えない。

補足 / 代われない専門ロールがいるとき

分担できないチームでは、どこで待つか

もう一つの架空モデル

デザイン・サーバー・iOS・Android・検証の5ロール。互いに代われない状態で、突発依頼が入る。

見るのは、中断した作業と、次の工程へ進めない機能。

肩代わりできなくても

誰でも相手の作業を代われる、という話ではない。

自分たちの仕事は、どこで待っているだろう?

ロール別シミュレーター

突発依頼の有無で、待ちが出る場所を見る。

制作クレジット

企画・構成・制作:toku345

制作に使ったAI

GPT 6

アウトライン・下書き作成、シミュレーター作成、仕上げ

Sakana AI Fugu Ultra V2

下書きからドラフトへの仕上げ

1 / 0:00–0:10(10秒) - 名乗って次へ。「みんな忙しいのに、仕事は待っている」を考えるLT。 【準備】 - 手術室・チーム開発のタブを開き、操作を確認する。実演は各約45秒。 - 通しリハーサルは未実施。時間は計画値:説明・実演4分5秒+余裕25秒、質疑は別枠で約3分。

2 / 0:10–0:25(15秒) - 日々の実感を、モデルを使って一緒に考える。 - 研究の紹介と自作モデルの結果は区別する。詳しい前提は補足1へ。

3 / 0:25–1:00(35秒) - 急な依頼に対応すると自分が中断、後に回すと相手が待つこともある。 - 「私も手が空くと、つい新しいプロジェクトに着手してしまいます」。 - つなぎ:「急な依頼を受け止める余裕を、手術室の例で見てみます」。

4 / 1:00–2:15(75秒、実演は約45秒) - 研究紹介:予定外手術用の部屋と予約ルールなどの見直しで、予定手術の時間外手術時間が減った報告。実演は論文の再現ではなく架空モデル。 - 「再生」→ 最初の急患到着で手動で「一時停止」。担当チームは対応中、次の予定手術へ進めない。 - 「再生」→ 予定のずれを見て「最後まで」。Aの予定からずれた帯と、Bの緊急用の室4を比べる。 - 要点:同じ仕事量でも、急な仕事の受け皿で予定のずれ方が変わる。 - つなぎ:「次は開発で、同時に進める件数と人の集め方を変えます」。 【準備・代替】 - 予定24件・急患3件・日中にランダム・予定どおり60分で「最初から」。再生操作とA・Bの帯を表示。 - 開けない場合:カードで2つの割り当てを紹介して次へ。 【メモ(本編では話さない)】 - 300日の集計・負荷グラフ・数値の読み上げは省略。研究の詳細は補足1へ。 - 予約時刻も異なるため、開始遅れの差を患者の待ち時間短縮とは言えない。 - Bの開始遅れ0は、予定手術に割り込みも時間のばらつきもない前提による。

5 / 2:15–3:30(75秒、実演は約45秒) - 比べるのは同時進行数と実装への人の集め方。両方レビュー優先、2人なら実装が2倍進む仮定。 - 「通常運転」・Bの上限3件・20日間で「再生」。20日で自動停止。 - 途中の施策と完了した施策を左右で見比べてもらい、締めへ。 【準備・代替】 - 上記条件で「最初から」。条件設定と「詳しい指標と前提を見る」は閉じる。 - 開けない場合:カードで2つの進め方を紹介して次へ。 【メモ(本編では話さない)】 - 上限1件・8件の追加実演、詳細指標、件数の読み上げは省略。 - 件数制限と人の集め方を同時に変えており、単独の効果とは言えない。 - 協力の調整コストや切り替え損失は含まない。サポート・突発対応全般の効果も検証していない。

6 / 3:30–4:05(35秒) - つなぎ:「現実では、2人でやれば2倍進むとは限りません。それでも、自分たちの仕事の進め方を考えるきっかけにはなりそうです」。 - 自分の作業が終わっても、プロジェクトが終わるとは限らない。 - 「次の仕事を始める前に、進行中のプロジェクトを前に進められないか」で締める。行動例は読み上げず画面に残す。 - このページで質疑へ。出典・前提は補足1、専門ロールは補足2。回答後はここに戻る。 【メモ(本編では話さない)】 - Bや協力が常に正解とはしない。 - 流れ図は工程の一例。幅は時間や割合を表さない。

補足1 / 出典・モデルの前提を聞かれたら開く。 - 26%は予定手術の時間外手術時間。スタッフ全体の残業時間や燃え尽きの指標ではない。 - 専用室だけの効果は判断できず、自作モデルは論文の再現でもない。 - 回答後は締めのページへ戻る。

補足2 / 「専門ロールで分担できない」と聞かれたら開く。 - 肩代わりできなくても、どこで仕事が待つかを見る。通常はスライドだけで説明。 - 実演する場合:20日時点で突発依頼の「発生なし」と各ロールに発生する設定を比べる。 - 回答後は締めのページへ戻る。 【メモ(本編では話さない)】 - 切り替え損失・レビュー・手戻りは含まない。完了数の優劣を示す例には使わない。 - 「対応可能な通常機能」には作業中も含む。純粋な待ち件数ではない。 - 中断・待ちの印を見るなら突発対応の発生中へ。20日時点では対応済み。

本編には含めない。質疑中は6枚目の問いを表示する。