トイルとは？
SRE業務に必須の運用自動化への具体策を解説

「トイル（Toil）」とは、直訳すると「骨折り仕事」「労苦」などの意味を持つ単語です。同じく「骨折り仕事」「労苦」の意味を持つ単語として、「モイル（Moil）」がありますが、こちらは多少ニュアンスが異なり、主に泥まみれ、油まみれになるような激しい肉体労働によるものを指します。また、「痕跡」などを意味する「トレイル（Trail）」はまったく別の単語です。

トイルは普通の文章の中でも使用されますが、Google社が自社システムを効率的に運用する技術である「SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）」を解説する中でトイルを明確に定義したことで、主にSREの分野でよく使用されるようになりました。具体的には、Google社のブログ「SRE サイトリライアビリティエンジニアリング ――Googleの信頼性を支えるエンジニアリングチーム」の「5章 トイルの撲滅」の中で定義されており、その定義を日本語に訳すと、「手動で、反復して行われ、自動化が可能で、戦術的で、長期的な価値を欠いており、サービスが成長するにつれて直線的に増加する、制作業務に伴って発生する業務」となります。

以下に、各要素について簡単に説明します。

• 「手動」は、手作業で行うことを指します。タスクを自動化するスクリプトを手作業で実行するなどの業務も含まれます。
• 「反復」は、同じ業務を何度も繰り返し行う業務を指します。対処方法を改良するなど、業務内容が変化、進化している場合の業務は含まれません。
• 「自動化可能」は、スクリプトなどにより自動化が可能な業務を指します。人間の判断が不可欠な業務は自動化が困難であるため含まれません。
• 「戦術的」は、突発的に発生する業務を指します。中長期的な目標を達成するために行う「戦略的」な業務ではなく、すぐに対処する必要があるような短期決戦的な業務を指します。
• 「長期的な価値なし」は、完了後もシステムの状態が変化しない業務を指します。完了後、システムが恒久的に改善した場合には含まれません。
• 「サービス成長に伴い増加」は、ユーザー数の増加など、サービスの拡大に伴い増加する業務を指します。

これらの要素のうち、1つ以上に合致する業務はトイルである可能性が高いと言えます。近年、SREは開発（Development）と運用（Operations）とを連携させた「DevOps（デブオプス）」を実現し、システム運用業務を効率化する具体的な手段としても注目されています。トイルの削減は、SREにとっても大きな課題となっています。

SRE（サイト信頼性エンジニアリング）によれば、システム運用業務は主に「ソフトウェアエンジニアリング」「システムエンジニアリング」「管理業務」の3つに分類することができます。

「ソフトウェアエンジニアリング」は、コードの追加・修正およびそれに関連した仕様書やドキュメントの制作を行う作業です。運用管理業務の自動化スクリプトの作成、自社サービスへの新機能の追加などが含まれます。「システムエンジニアリング」は、新システムの構築、既存システムの構成変更などを行う業務です。監視システムの導入・更新、自社サーバーの設定変更なども含まれます。「管理業務」は、システム運用には直接結びつかない「ソフトウェアエンジニアリング」および「システムエンジニアリング」以外の業務環境を管理する業務を指します。採用面接、会議への参加、従業員教育、それらに付随した事務作業などが含まれます。

そして、これら3つの分類に含まれない業務が「トイル」となります。具体的には、自社のサービス提供に使用しているシステム、いわゆる本番システムの動作を継続するために繰り返し行っている業務が該当します。定期的なログ解析やバックアップに伴うスクリプトの手動実行、さほど重要でない機能をリリースするためのコード作成、季節変動などによる定期的なシステムの設定変更・確認、入退社に伴うアカウント管理などの事例です。

中でも特に問題の大きいトイルが、前述の「戦術的」要素を含む、突発的に発生する割り込み業務です。輻輳やサーバーの容量不足などに伴い発報した監視アラートへの対応、ユーザーや他部署からの問い合わせを解決する「オンコール対応」などが含まれます。対応中はそれまで携わっていた業務を一時中断する必要があることに加え、並行して他業務を進行することも困難な状態となります。また、こうした業務は「手動」や「長期的な価値なし」「サービス成長に伴い増加する」などの要素を内包していることが多く、また自動化も困難であるため非常に厄介な存在と言えるでしょう。

先に紹介したGoogle社のブログ「SRE サイトリライアビリティエンジニアリング ――Googleの信頼性を支えるエンジニアリングチーム」では、トイルにより生じる弊害として、キャリアの停滞、士気低下、業務改善進行の鈍化などが上げられています。トイルの処理に忙殺されていてはコーディングスキルの向上などキャリア形成には結びつきませんし、士気が低下しヒューマンエラーも増加する危険性があるでしょう。燃え尽き症候群を発症し退職するといった、最悪の事態を招く危険性すらあります。また、トイルの処理に忙殺されることで自動化など業務改善に費やす時間が少なくなり、業務改善の進行が鈍化するというデメリットもあります。

そこで、Google社では、システム運用管理担当者がトイルに費やす時間を、システム運用業務全体の50%未満に抑えるという目標を設けました。逆に言えば、各担当者は50%以上の時間をサービス機能追加などの開発業務やトイル削減に費やされるべきであるということです。トイルを削減すれば、開発業務に伴うスキルアップの機会の増加や士気向上による定着率向上、自動化などによる運用負荷の軽減などのメリットが期待できます。また、ヒューマンエラーの削減にも寄与することでしょう。まずはトイルを削減する必要性について、システム運用担当者全員が意識を共有する必要があります。

それでは、トイルを削減するには具体的にどのような手順を踏めば良いのでしょうか。4つのステップに分けて説明します。

1. トイルの洗い出し、把握
   まずはシステム運用管理担当間でミーティングやアンケートなどの方法を利用して、トイルの情報を収集します。部署内だけでなく、運用データの照会や提供など、他部署から繰り返し依頼される業務も残さず洗い出しましょう。
2. トイルの定量的測定、見える化
   続いて業務に費やした時間など、客観的な指標を利用して各トイルを定量的に測定し、見える化します。ただし、トイルの定量的測定、見える化自体がトイルになってしまっては意味がありません。表計算ソフトなどを利用して手作業で集計するなどの手間は避け、労務管理ツールの活用など、各ツールの活用も視野に入れましょう。
3. 改善策の立案（自動化、半自動化）
   続いて各トイルに優先順位を付け、改善策を立案します。後の効果測定に活用できるよう、改善策には必ず目標値も設定しておきましょう。具体的には、発生頻度を減らす、負荷を分散させる、業務自体を廃止するなどが考えられます。削減効果の大きいもの、頻度の高いものから完全策を検討しましょう。例えば、これまで1人が終日担当していたオンコール業務を部内4人の当番制とすることで、1人当たりの負担を25%に平準化することができます。
4. 効果測定
   トイルは一度削減すれば終わりというものではありません。冒頭でもお伝えした通り、トイルはサービスの成長に伴い増加するという性質を持つため、PDCAサイクルを用いて繰り返し改善を図る必要があります。
   トイルの削減効果を測定しつつ、定期的にさらなるトイル削減を図りましょう。

既にトイルにより運用管理部門が疲弊している、自社のトイルを削減するためのノウハウに不安があるという場合には、外部サービスの活用やアウトソーシングの導入を考慮することも有力な選択肢となり得ます。例えばNTTドコモビジネスの「X Managed®（クロスマネージド）」は、ICTの監視、運用、保守をフルアウトソースできる24時間365日のマネージメントサービスです。また、要件整理、設計（基本／詳細）、運用設計から導入・運用までのベストプラクティスをセミオーダータイプで一体提供するため、効果的なトイルの削減を行うことも可能です。NTTドコモビジネスの「X Managed®（クロスマネージド）」は、1,000件以上の導入実績により蓄積されたノウハウを生かし、1,000名を超えるSE体制を整えてお客さまにベストプラクティスを提供します。

今回は、システム運用業務の効率化を阻害し、本来の運用業務を圧迫する存在である「トイル」について解説しました。Google社が提唱するSREにより効率的なシステム運用を実現するには、トイルを削減し、全体業務の50%に抑える必要があります。トイルの削減にはスキルアップの機会増加、士気向上による定着率向上、ヒューマンエラーの削減、自動化などによる運用負荷軽減などさまざまなメリットがあります。今回紹介したステップを参考に、自社のシステム運用業務においてトイルの削減を検討してみてはいかがでしょうか。

【関連記事】

• IT運用アウトソーシングの最新動向と企業選定のポイント