ITの役割：生産性と可用性

ITマネージャーとして、私たちは二種類の全く異なるタイプの技術専門職を扱う必要に迫られています。この二種類の専門家を隔てるのは、性格の違いや仕事スタイルではなく、職務の本質そのものです。この二種類の職務の固有のニーズを理解することは、技術職を効果的に管理する上で欠かせませんが、ITデパートメントでこの二種類の職務に内在する微妙な差異を真に理解し評価する時間を取っているところは少ないです。

最初のタイプは最もよく理解されており、私はこれを「エンジニア」と呼ぶことにします。このエンジニアリングの役割は、ソフトウェア開発者やデザイナー、アーキテクト、システムエンジニア、ネットワークエンジニアなど、あらゆる種類の新しいシステムを創造的に設計または実装することを主な機能とする人など、膨大な数の職務を包含しています。「エンジニア」という言葉は広義的なものですが、比較的意味のある表現です。

二番目の技術職の役割は、一般的に「サポート」の役割と呼ぶことができます。サポートの職種には、ヘルプデスク、システム管理、デスクトップサポート、ネットワーク監視、コマンドセンターなどが含まれます。サポート専門家をエンジニアリング専門家と区別するのは、新しい設計や実装を伴う創造的なプロセスを担当するのではなく、既存のシステムとともに働き、それが適切に稼働し、問題が発生した際には迅速に修正されることを保証する点です。

現実の世界では、どちらか一方のカテゴリーにだけ完全に属する人は実際にはほとんどいないことは言うまでもありませんが、ITのほぼすべての職務はどちらか一方に非常に重点を置いています。ほとんどすべての役割が、どちらかの役割に極めて偏っていると考えて差し支えないでしょう。一つのポジションがこれら二つの役割に均等に分割されることは非常にまれです。

この役割の識別が重要となるのは、技術スタッフをどのように測定し管理するかを知る上でです。エンジニアの測定と管理は、高いレベルから見るとかなりよく理解されています。生産性の概念は、エンジニアリングの役割にとって非常にシンプルで意味のあるものです。エンジニアリングの人材やチームを管理する目標は、その役割がクリエイティブなデザインや実装をできる限り多く生み出せるよう促し、環境を整えることです。もちろん品質の概念も存在しますが、記述された関数の数、生成されたデプロイメントパッケージの数、設計したネットワークの規模など、比較的具体的な言葉でエンジニアリングの役割について概ね考えることができます。メトリクスは曖昧なものですが、正確に測定できないにしても、エンジニアにとっての効率が何を意味するかについて少なくとも大まかなイメージは持てます。

サポートの役割にはこれと同じ概念は当てはまりません。確かに「クローズしたチケット数」のような人工的なメトリクスを使ってサポートの役割の生産性を測定することもできますが、それは非常に誤解を招きます。一つのチケットは些細なものかもしれませんし、次のチケットは大規模な調査を要するものかもしれません。長期間チケットがない状態が続き、その後に一度に多くのチケットが届いて同時に対処できないこともあります。生産性は散発的で持続不可能であり、最終的には測定することに全く意味がない可能性があります。

エンジニアリングのポジションは、大規模なプロジェクトでは数ヶ月から数年にわたる長い期間にわたって効果的に成果を生み出すことでその役割を果たします。したがって、エンジニアリングのポジションの目標は、持続可能な生産性を促進する環境を提供することです。エンジニアが短縮または代替された時間で働いたり、定期的に休暇を取ったりすることで、しばしば生産性が向上することはよく知られています。これは生産性を高めるだけでなく、成果の品質を大幅に向上させることが多いです。

サポートのポジションは、必要なときに「そこにいる」ことで価値を発揮します。サポート担当者が最大効率で仕事をしようとしている場合、サポートチームの対応を待つサポートの問題バックログが常に存在し、多くの人がサポートを待ってキューを形成しなければならないことを自然に意味します。常にキューが存在することは、サポート担当者がライブ案件を解決するのではなく継続的にスタックから作業を取り出していること、つまり高優先度案件を無視するか、定期的に割り込まれていることも意味します。これは継続的なコンテキストスイッチを引き起こし、キューを効率的に処理する能力を著しく低下させます。そのキューの存在意義自体が、そもそも人工的な生産性の見た目を作り出すためのものだったのです。

サポートの役割は「イベント駆動型」です。この用語が好きなのは、ほぼすべてのサポート専門家が働くモードを最も正確に表現していると思うからです。電話、インスタントメッセージ、メール、チケットによって生成されるイベントが、サポート担当者をアイドル状態から行動状態へ、場合によっては低優先度の作業から高優先度の作業への移行を開始するものです。どちらにせよ、イベントはサポート専門家にとっての「コンテキストスイッチ」を表します。イベントがなければ、サポート専門家がすることは何もありません。「イベント」がチケットキューやメールのバックログとして表れる場合でも、やはりイベントの一形態です。

真に効率的なサポートデスクを持つには、イベントプロセスの慎重な管理が必要です。終わることのないサポート案件のキューはサポート専門家を疲弊させ、スタッフが高優先度の案件を待つ「アイドル」状態にあることを意味しなくなります。このため、高優先度の案件が適切なタイミングで対処されないか、進行中の案件が放置されることになります。

サポートスタッフのイベント駆動型の性質を理解することは、これらのチームの管理にどのようにアプローチするかを理解するために重要です。簡単な答えはなく、サポートスタッフのメトリクスはエンジニアリングスタッフのものよりもさらに意味をなさないことが多いため、極めて注意して使用する必要がありますが、サポートの役割に共感することで、サポートマネージャーとしての役割がサポートチームメンバーを支援し促進するという大きな絵の中でどのように位置づけられるかが見え始めます。

私の経験上最も重要な概念は、サポートチームへの割り込みの良い流れを提供することです。サポートチームはメールや電話など、複数のサポートチャネルを同時に扱っていることがよくあります。イベントを制限し、適切なチャネルにファネルすることが重要です。

電話の問題点は、受信者がアイドル状態であるか、企業史上最も重大な本番障害に対応中であるかに関わらず、即座のコンテキストスイッチを要求する積極的なツールだということです。電話をかけている人は、自分の即座のニーズが、サポート担当者が現在サポートしている人のニーズよりも重要だと推測しています。電話は、それが使われるどこでもこの問題を引き起こします。

最後にピザ屋でカウンターで注文した時のことを思い出してください。あなたは一人ひとりが対応されるのを辛抱強く列に並んで待ちました。正しいことをしたのです。列の先頭に来ました。注文を始めたその時、電話が鳴りました。注文を受けていた人は、あなたがそこに立っているにも関わらず「保留」にして電話を取り、注文を受け、電話を切ってあなたに戻りました。これが示しているのは、「うるさい輪」である電話をかけた人が、実際にレストランにいる人よりも重要だということです。多くのサポートデスクでも同じことが起きています。進行中の作業が、グループラインや直接サポート担当者への電話によって中断されます。これは最良の場合は非効率であり、最悪の場合には非常に重要な問題のクリティカルなサポートプロセスを混乱させることになります。

ITプロをどのように管理するかを考えるとき、その役割の目的を考えてください。エンジニアの目標は生産性です。サポート専門家の目標は可用性です。