このブログは、Damon Edwardsが執筆した人気ブログのアップデート版です。
私たちの業界では、必要だけれども会社を前進させない仕事に対して、いつもローカライズされた表現を使っていました。SREの流行では、このような仕事を“Toil”（=骨折り仕事）と呼んでいます。
“Toil”という概念は、私たちの時間を奪い、社員のエンジニアとしての能力を発揮させず、会社を前進させない仕事を特定し、それを抑制するための公平な枠組みを提供することで、統一された力を発揮します。
なぜ“Toil”が問題なのか
残念ながら、「時間が足りない、やることが多すぎる」というのが、運用組織におけるデフォルトの労働条件です。新機能の導入、インシデントへの対応、サポート依頼、技術的負債の返済など、計画的な仕事と非計画的な仕事が無限に存在するのです。
1日の時間が限られている中で、自分が取り組んでいることが実際に効果を発揮するためには、どうすればよいのでしょうか。
チームや組織全体が、付加価値の高い仕事を最大限に生かし、そうでない仕事を排除するには、どうすればよいのでしょうか。結局のところ、組織とチームの決定が仕事の大部分を左右するのです。
エンジニア組織の価値と社員の人間力を最大化するためには、「間違った」労働を特定し、それを抑制し、「正しい」労働を最大化するための客観的なフレームワークが必要です。“Toil”とは何かを理解し、その量を抑制することは、会社に経済的利益をもたらし、仲間のエンジニアの労働生活を向上させます。
Toilの定義とは？
“Toil”という言葉を最初に広めたのはGoogleで、SREの動きもあり、その後、IT運用に押し出されるようになりました。
SREとは、一言でいえば、ソフトウェアエンジニアリングの手法と新しい考え方をIT運用に導入し、高い信頼性と拡張性を持つシステムを構築することです。Googleが「Site Reliability Engineering」という本を出版して以来、SREというトピックへの関心は急上昇しています。
この本の中で、Vivek Rauは、「Toilとは、生産サービスの運営に関連する作業のうち、手動で、反復的に、自動化可能で、戦術的で、永続的な価値を持たず、サービスの成長に伴い直線的に拡大する傾向のあるものである」という優れた定義を明らかにしています。
これらの属性が多ければ多いほど、自信を持ってその仕事を“Toil"に分類できるでしょう。しかし、仕事が "Toil "に分類されたからといって、その仕事が取るに足らないものであったり、不必要であったりするわけではありません。それどころか、ほとんどの組織は、”Toil”がなければ止まってしまうでしょう。
“No Toil”という目標は、理屈ではよいことでしょう。しかし、現実には、“No Toil”という目標は、ビジネスでは達成できないものです。技術組織は常に流動的であり、新しい開発（期待されるもの、予期されないもの）は、ほとんどの場合、 “Toil”を引き起こします。顧客に価値を提供するために必要な仕事だからといって、それが常に付加価値のある仕事であるとは限りません。労力は時に必要かもしれないが、永続的な価値（＝顧客による価値認識の変化）を付加するものではないのです。長期的には、 “Toil”の必要性を除去していきたいものです。
最善策は、 “Toil”の削減と、組織全体で“Toil”を管理可能なレベルに維持することです。手間は、分かっていても自動化する時間や予算がない場合にも発生します（半手動の導入、スキーマ更新/ロールバック、ストレージクォーターの変更、ネットワーク変更、ユーザー追加、容量追加、DNS変更、サービスフェイルオーバーなど）。また、予期せぬ事態が発生した場合、手動での介入を必要とするインシデントが発生します（例：再起動、診断、パフォーマンスチェック、構成設定の変更）。
“Toil”の代わりに人がすべきことは何か？
エンジニアが付加価値のない作業に時間を費やす代わりに、付加価値のあるエンジニアリング作業にできるだけ多くの時間を費やせるようにしましょう。
また、Vivek Rauの分かりやすい定義から引用すると、エンジニアリングワークは、人間の判断を必要とし、永続的な価値を持ち、他者に活用される創造的で革新的な仕事と定義できます。
”Toil”に対してエンジニア仕事の比率が高い組織で働くと、誰もが目標に向かって泳いでいるように感じられます。”Toil”に対してエンジニア仕事が低い組織で働くと、よくても立ち泳ぎか、悪いと沈んでいくような感覚になります。
高いレベルの”Toil”は有害である
”Toil”は、少しであれば無害に思えるかもしれません。しかし、”Toil”は放っておくとすぐ蓄積し、個人と組織両者にとって有害なレベルになってしまいます。
高レベルの”Toil”が個人にもたらすものは、以下のとおりです。
- 不満がたまり、達成感が欠如する
- 燃え尽き症候群
- ミスが増え、修正に時間がかかり、手戻りが発生する
- 新しいスキルを身につける時間がない
- キャリアの停滞（付加価値の高いプロジェクトを提供する機会がないため、キャリアに傷がつく）
高レベルの”Toil”が組織にもたらすものは、以下のとおりです。
- チームの余裕の不足
- 過剰な運用サポートコスト
- 戦略的イニシアティブが進まない（「みんな忙しいのに、何もできない」症候群）
- 優秀な人材の維持ができない（組織の機能が知られると、優秀な人材を獲得できない）
“Toil”の最も危険な点は、それを解消するためにエンジニアリングワークを必要とすることです。
工数を削減するためには、手作業の必要性を自動化するための自動化機能を構築するか、そもそも手作業の必要性を軽減するためにシステムを強化するためのエンジニアリング時間が必要です。
“Toil”を削減するために必要なエンジニアリング作業は、一般的に、外部オートメーション（サービス外部のスクリプトや自動化ツール）の作成、内部自動化（サービスの一部として提供される自動化）の作成、または保守介入を必要としないようにサービスを強化することのいずれかです。
“Toil”は、将来の“Toil”を防ぐためのエンジニアリング作業に必要な時間を食いつぶします。注意を怠ってしまうと、組織内の“Toil”のレベルは、それを阻止するのに必要な能力を組織が持てないところまで上昇する可能性があるのです。Technical Debt（技術的負債）のメタファーを用いると、これは 「エンジニアリングの破産」といえるでしょう。
SREの働き方とそれに伴うメリットは、チームにエンジニアリングワークのための十分な余裕があるかどうかにかかっています。この余裕の要件が、“Toil”がSREの中心的なコンセプトである理由です。もし、“Toil”がエンジニアリング業務の余裕を食いつぶしてしまったら、SREモデルは成り立ちません。”Toil”に永遠に埋もれているSREは、SREではありません。新しい肩書きを持った、従来の長い間苦しんできたシステム管理者に過ぎないのです。
PagerDutyが“Toil”を気にする理由
私たちの大きな目標のひとつは、運用担当者のワークライフを改善することです。“Toil”を削減し、エンジニアリングの時間を最大化することは、まさにその通りです。
ユーザーは、“Toil”を削減するためにPagerDuty Process AutomationとRundeckをどのように使用しているかを示してくれました。
その利点は、以下の通りです。
- 手順の標準化により、バラツキやミスを減らして労力を軽減すること。
- これまで多くの“Toil”を必要とした作業を自動化することで、“Toil”を軽減するエンジニアリング作業を容易にすること
- セルフサービスを可能にし、他者が運用作業を自分でできるようにすることで、あるチームが他のチームのために運用するのを阻止すること
PagerDuty Runbook Automationについてのお問い合わせがあればこちらまでご連絡ください。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
カテゴリー ：インテグレーション＆ガイド
