チケットは運用を不必要に悪化させる

ITの運用は、いつの時代も難しいものです。やるべきことが多すぎるし、時間も足りません。頻繁に中断され、労力のレベルが高いことは明らかに救いようがありません。さらに経営陣からは、「なぜ時間がかかるのか」「なぜ故障が多いのか」「なぜコストがかかるのか」というプレッシャーが絶え間なく襲ってきます。このような状況を改善するために、私たちは何度も新しいツールに賭けてきました。新しいプラットフォーム（仮想化、クラウド、コンテナ、Kubernetesなど）や新しいおオートメーションツール（Ansible、Terraform、Pulumiなど）を繰り返し使ってきたのです。それぞれに利点がありますが、平均的なエンジニアにとって、運用にかかるストレスや過負荷が根本的に変わったといえるでしょうか。また、企業は過去20年間、ITILやCOBITのような管理フレームワークを惜しみなく使ってきました。ここでも、平均的なエンジニアは、状況が良くなったといえるでしょうか、それとも悪くなったと言うのでしょうか。このような中で、ほとんど疑問視されることのない常識があります。それは、チケットを使って運用業務を管理することです。チケットは、運用組織で最もよく使われる作業管理ツールになっています。必要なものがあったら？チケットをオープンしてください。誰かがあなたに、何かをリクエストしようとしたら？あなたのキューにチケットが表示されます。チケットドリブンの働き方はとても一般的なため、組織全体へのチケットキューの追加について再考する人はあまりいません。しかし、もし私たちがチケットについて誤解していたとしたらどうでしょう。もし、チケットの列が、目に見えないところに隠れている、運営上の重要なトラブルの原因だとしたらどうでしょう？チケットキューが、しばしば利益よりも害を及ぼしていることを検証してみましょう。

チケットの何が問題なのか？

それは、キュー（待ち行列）

チケット単体では、単なる記録なので比較的無害です。問題は、そのチケットをどこに置くかということです。チケットはチケットキュー（待ち行列）に入れられますが問題はそこから始まるのです。キューは遅延、リスク、変動性、オーバーヘッドを増やし、品質、モチベーションを下げます。これは私的な意見ではありません。待ち行列のコストは、物理的な製造や製品開発など、他のさまざまな分野での広範な研究から得られたものです。待ち行列理論は、その学術的な研究領域として尊重されています。この記事の続きで、私は「チケット」と「キュー」を多少入れ替えて使うことにします。ただ、問題を起こすのはキューの列の部分であることは知っておいてください。

チケットはコミュニケーションの問題を増加させる

チケットキューでの通信を強いられると、必ず中断やミスコミュニケーションが発生します。チケットに関するあらゆる問題を考えてみると、リクエストが誤解される。リクエストを読む人がコンテキストを欠いているか、異なるコンテキストで作業している、あるいはリクエストする側が間違ったリクエストをしたり、リクエストの意味を理解していない、さらにはリクエストがキューに残っている間に、リクエストのパラメータが（どちらの当事者も知らないうちに）変更されていたり、もはや有効でなくなっていたりする、などといった事象が挙げられます。

チケットはフィードバックと学習を遅らせる

リーン開発からDevOps、リーンスタートアップまで、ほとんど全ての現代の経営哲学は、組織はすぐに学習するというコンセプトに基づいています。分析と意思決定が素早く行われるように、全てのフィードバックのループをより厳しくしているのです。

しかし、Scott Prugh が言うように、「キューは学習しない」のです。キューは、遅延を発生させ、各リクエストのコンテキストをはぎ取ってしまい、フィードバックループに対立します。チケットドリブンのリクエストキューがまん延していると、学習する組織になるのは難しいでしょう。

チケットはボトルネックを助長する

チケットキューを利用したチームの働き方は、ボトルネックを助長する性質があります。まず、チケットキューは、キャパシティーのミスマッチがある場合によく使用されます。例えばチケットキューは、専門家チーム（例：ネットワーク、データベース、セキュリティー）のリクエストをバッファリングするためによく使用されます。そしてこの専門家チームは、リクエストに対して人数が少ないことが多いです。リクエストを送るチームは、キューに要求を「詰め込む」ため、キューの長さと応答時間を増加させます。キューはフィードバックを遅らせるため、リクエスターはしばしば容量の不一致に気付かず（あるいは気にせず）、キューに詰め込み続けます。このような行動は、キューの長さと応答時間の両方を増加させ、ボトルネックを悪化させるのです。さらに、キューが長くなると、キューの処理に責任を持つチームは、本能的に、自分たちのキャパを守るために内向きになります。この自然な反応は、キューの背後にいるチームの最適化につながりますが、多くの場合、組織全体を犠牲にすることになります。例えばファイアウォールチームが緊急でない変更は月曜日と木曜日にしか行わないとした場合、そのチームの作業負荷を最適化するのに役立つとしても、組織の他の部分には遅延が発生します。

チケットはサイロ化した仕事のやり方を増やす

チケットキューは、チームがサイロ化し、分離した状態で作業を続けてしまうためのバッファーとして機能します。チームがバラバラになればなるほど、チームはサイロ化した専門家の労働力のプールのようになってしまうのです。このようなスペシャリストへのリクエストは、チケットキューを通じて行われ、リクエストは半手動、または手動によって一度だけ実現されるため、変動性が高く、優先順位や状況を把握するのが難しくなります。ボトルネックへの対応と同様、管理職はチームの生産量を守ることに重きを置きます（組織全体のニーズには目を向けません）。サイロの影響が強まれば強まるほど、断絶、ミス、遅れが生じます。チケットキューは、このような負のスパイラルを助長するのです。

チケットは組織を「スノーフレーク」にする

チケットキューのデフォルトであるFIFO （First In, First Out）の性質は、一回限りの処理を促します。あるチケットがキューの先頭に来ると、チケットキューで作業している人たちは行動を始め、限られた時間の中でできるだけ多くのコンテキストを集めようとし、自分たちの視点で正しいことを行い、次のチケットに移ります。このように、１つのリクエストから別のリクエストに飛び移り、それぞれが一見バラバラなコンテキストを持つという仕事の進め方は、「スノーフレーク」（snowflake）を引き起こす主な原因でます。「スノーフレーク」とは、技術的には正しく（完璧ですらあっても）、再現性のない一過性のものを表す言葉です。手動で更新されたサーバーは、スノーフレークの典型的な例といえるでしょう。手動で更新したサーバーは、雪の結晶の典型的な例といえます。動作している状態にすることはできるかもしれませんが、おそらく、フリート内の他のサーバーとはわずかに異なります（そして多くの場合、検出できない形になっています）。スノーフレークにかかるコストは、最初は、わずかなものに思えるかもしれません。しかし環境が大きくなるにつれて、そのコストは急速に膨れ上がって高くなり、一見すると難解な状態を作り出してしまうのです。 Keith Chambersによるこの指摘が有名です。「小さな予期せぬ変化が原因で大きなインシデントとなり、数時間から数日間チームの生産性が失われる『吹雪の日』を経験した企業はどれだけあるだろうか？」

チケットは価値の流れを見えなくする

リーン開発、アジャイル、DevOpsの動きの多くは、価値の提供のために必要がある作業の体系的なビュー（このエンドツーエンドの体系的なビューは、しばしば「バリューストリーム（value stream、価値の流れと呼ばれる）の構築のために、障壁を破壊することにありました。全ての知識労働においてコンテキストが重要であるため、各作業がより広いシステムのどこに位置付けられるか、の理解がとても重要なのです。透明性を提供し、コンテキスト構築のために行われた全作業の後、一連の個々のチケットに分解することは、価値の流れを不明瞭にし、コンテキストを散乱させます。しかし実際、仕事をどんどん小さな単位に分解することは、チケットシステムのベストプラクティスとしてよく見受けられます。

チケットは管理のオーバーヘッドになる

チケットキューは、ただ現れて、ただ処理するだけではありません。誰かがキューをセットアップし、ルールを定義しなければなりません（ルールはそのルール内、もしくはルールに沿った形を学ぶ、というオーバーヘッドを追加してしまうことが多いです）。誰かがチケットシステムそのものを維持しなければなりません。優先順位、衝突、ポリシーの問題も継続的に管理する必要があります（多くの場合、高価なプロジェクト管理オーバーレイを使用します）。これらの作業にはコストがかかり、他の付加価値の高い作業に費やせる時間と労力を割いてしまいます。

チケットは何のためにあるのですか？

誤解を恐れずにいえば、チケットは悪いものばかりではありません。ただ、チケットを使いすぎたり、間違った理由で使われたりしているだけです。私の意見では、チケットシステムは例外（例えば、バグや改善リクエストの記録）を提起するのに有効です。また、承認作業が避けられない場合に、人と人のコミュニケーションを記録するためのチケットシステム使用には、いくつかのメリットがあります。チケットキューは、各リクエストが細かく、分断されている場合にも有効です（例：従来のカスタマーヘルプデスクや、チケット販売の興行など）。しかし同時に、これらのリクエストのほとんどは、セルフサービスオートメーションの有力な候補となります。企業のソフトウェアベースのサービスを提供し、運用するために必要な複雑な知識作業に関しては、チケットキューはよくてもコストがかかり、最悪の場合破壊的であるという証拠が明確にあるようです。

チケットキューをできるだけなくすにはどうしたらいいか？

より多くの組織がチケットドリブンののリクエストキューがもたらす有害な副作用に気付くにつれ、キューからできるだけ多くの仕事を取り除く、という基本的なパターンが現れていくと私は予想しています。

可能な限り引き継ぎを回避するための作業設計の見直し先進的な考えを持つ企業は、「サービスオーナーシップ」や「プロダクトアラインドチーム」と呼ばれる、ライフサイクルのできるだけ多くを（他のチームに仕事を引き継ぐことなく）処理できるチーム作りに注力しています。引き継ぎをなくせば、当然ながらチケットキューは不要になります。
セルフサービスのオートメーションにより、チケットキューをなくすチケットキューをなくすことができない場合の優れた代替案は、そのキューをセルフサービスに置き換えることです。セルフサービス自動化により、業務活動の定義と実行の両方を、従来の組織の境界を越えて委任できます。チケットキューをプルベースセルフサービスインターフェースに置き換えることで、待ち時間がなくなり、フィードバックループの短縮やコンテキスト中断の回避、コストのかかる労力の省略につながります。残る数少ないチケットキューは、真に期待されるものや一回限りのものです。

今こそ行動を起こす時

今こそ、業界として、チケットキューの常識を疑うべき時です。チケットにはその役割がありますが、使いすぎによって皆に不利益を与えてきました。PagerDutyではもっと簡単に物事を達成するためのよい方法を、ユーザーの皆さんと共に探し、実現していきます。ぜひ、あなたもご参加ください。

PagerDuty Process Automationの詳細については、弊社にお問い合わせください。

カテゴリー：インテグレーション＆ガイド

新着情報

カテゴリ

BLOGチケットは運用を不必要に悪化させる