博士

やあ、ロボ子。今日のITニュースは、プロジェクトと運用負荷のバランスについてじゃ。

ロボ子

博士、こんにちは。運用負荷のバランス、重要ですよね。SREでは運用に50%の時間を割くことが推奨されているんですね。

博士

そうじゃ、ロボ子。チームはチケット処理やオンコール対応に慣れていないといけないが、担当者の負担を減らして、創造的なタスクに時間を使えるようにする必要があるぞ。

ロボ子

なるほど。記事では、1日にプロジェクトか割り込みのどちらか一方に集中し、オンコールの場合はプロジェクトを行わない方が良いとありますね。

博士

コンテキストスイッチはコストがかかるからの。頻繁に中断されるとプロジェクトが遅れたり、品質が落ちたりするぞ。

ロボ子

確かにそうですね。集中力が途切れてしまいます。チームのオンコールと割り込み対応は、担当者に集中させるように構成するべき、と。

博士

その通りじゃ。そして、担当者の負担が大きい場合は、人員を増やすのが一番。負荷分散のためにチーム全体にランダムに割り当てるのは逆効果じゃぞ。

ロボ子

運用負荷には、ページ、チケット、継続的な責任など、様々な形があるんですね。ページ管理にはオンコール担当者を配置し、チケットはオンコール担当者、二次担当者、または専任担当者が処理する、と。

博士

そうじゃ。割り込みの処理方法は、割り込みのSLA、バックログ数、重要度、頻度、担当者の数によって変わってくる。割り込み対応は、人間のコストと生産性のコストを考慮する必要があるぞ。

ロボ子

人間は機械ではないので、集中状態（フロー）を意識して、割り込みを減らす必要があるんですね。フロー状態は生産性や創造性を高めますが、中断により損なわれる可能性がある、と。

博士

チームマネージャーは、チームの割り込み管理方法を改善して、担当者が集中できる環境を整える必要があるのじゃ。コンテキストスイッチを最小限に抑え、プロジェクトと割り込み対応の時間を分けるのが重要じゃ。

ロボ子

割り込みが多すぎる場合は、担当者を増やす。オンコール担当者はオンコールに専念し、プロジェクトはエスカレーションする。チケットはランダムに割り当てず、担当者を決める。役割を定義し、担当者が交代できるようにする。割り込み担当者でない人が割り込みに対応するのは避ける…

博士

よく覚えておるの。チケットの根本原因を分析して、解決策を見つけるのも大事じゃ。顧客へのサービスレベルを設定し、顧客に協力を求める。ポリシーを活用して、割り込み対応を効率化するのじゃ。

ロボ子

不要なコンポーネントの廃止も検討する、とありますね。顧客からの要求には、合理的な範囲で対応する、と。

博士

その通りじゃ。つまり、エンジニアはスーパーマンではないからの。適切な負荷分散と集中できる環境が大事じゃぞ。…ところでロボ子、もし私がスーパーマンだったら、一番最初に何をしたい？

ロボ子

そうですね…博士なら、まず世界中のITシステムを最適化して、全てのバグを消し去るのではないでしょうか？

博士

ふむ、それも良いが…私はまず、世界中の美味しいお菓子を全部食べ尽くしたいのじゃ！