IT 運用チームのメンバーは、システムを稼働状態に維持するために懸命に働き、多くの場合、ユーザーにシームレスなフロントエンド・エクスペリエンスを提供するために、舞台裏で終業後も解決策を探しています。しかし、スーパーヒーローであっても、時には休息が必要です。 

オンラインの記事を次から次へと読みながら苦労して暗号化ポリシーを修正したことがある場合や、組織のクラウドへの大規模な移行の概念実証をまとめるためのガイダンスが必要な場合は、Red Hat テクニカルアカウントマネージャー (TAM) がその解決策の一部を担うことができるかもしれません。 

あるいは、あなたはトラブルシューティングのエキスパートであり、監査ログのエキスパートであり、そのスーパーヒーロースキルを活かして、より多くの企業の業務管理を支援したいと考えているかもしれません。少し前に、TAM の業務について話してくれるテクニカルアカウントマネージャー (TAM) を探しているという投稿を Reddit で読みました (投稿者は Red Hat への応募を検討している人でした)。この記事では、Red Hat TAM の 1 日をご紹介します。

テクニカルアカウントマネージャーとは

テクニカルアカウントマネージャーという職の業務は、会社によって異なるかもしれません。Red Hat の TAM は専門の製品エキスパートで、IT 組織と協力しながらデプロイを成功に導くよう戦略的な計画を練り、最適なパフォーマンスと成長の実現を支援します。 

TAM は Red Hat のカスタマーサクセスという組織の一部で、プロアクティブにアドバイスとガイダンスを提供して、潜在的な問題が発生する前に特定して対処できるよう支援します。問題が発生すると、TAM が問題に責任を持って対応し、最適なリソースに可能な限り速やかに解決に当たらせ、お客様のビジネスの中断を最小限に抑えます。

TAM の業務について

TAM として働く場合、サービスはサブスクリプションの一部として提供されます。IT 部門に在籍している人は数多くいますが、ある分野にマニアックなまでに極めていること (「ナードであること」) が実際に会社の利益につながるような役職について聞くのは、これが最初かもしれません。この点だけでもなかなか魅力的です。

TAM の中でも担当が分かれており、私は Platform TAM です。たとえば、Cloud TAM は主に Red Hat OpenStack Platform などの製品を扱い、Middleware TAM はミドルウェアが対象です。 

Platform TAM の私はある意味何でも屋で、コア OS のほか、Red Hat Satellite や Red Hat Virtualization などのケースにも対応します。最近では、コンテナ (OpenShift ではなく OS 上で動くもの) や Ansible なども Platform TAM の担当範囲に含まれています。私は、Red Hat Storage (Ceph ベース) を使用しているある企業の Storage TAM でもあります。

Red Hat TAM はグローバルカスタマーサクセス (カスタマーエクスペリエンス & エンゲージメント組織に所属) の一部です。Red Hat のサポート組織と緊密に連携しており、多くの場合、サポート関連の問題に対処しています。つまり、ある程度のサポートケースを担当することになります。そこに引っ掛かりを感じるなら、この仕事は向いていません。

ただし、ケースワークは担当している 4 - 6 社のアカウントのものであることがほとんどです。入社すると、戦略的アカウントが割り当てられます。私は現在、いくつかの業種の 5 つの会社のアカウントを担当しています。うち 2 社は熟練の Satellite 6 ユーザー、もう 1 社もまもなくそうなりそうで、すべての会社が何らかの形で Red Hat Enterprise Linux (RHEL) 6 - 8 を使用しています。ほとんどの会社がコンテナ利用を開始したか、検討中です。

お客様がサブスクリプションにより大きな価値を見出せるよう支援

TAM として最も重要な仕事は、こうしたお客様に Red Hat サブスクリプションのより大きな価値を見出していただけるよう支援することです。求人広告の一節みたいですが、実際にそうなのです。お客様の環境について学び、あちらのナードやマネージャーと関係を築き、インストールと設定の方法についてアドバイスを提供し (場合によっては不適切な設定を修正することもあります)、トレーニングセッションを提供し、年に数回相手先を訪問します。新型コロナウイルス感染症 (COVID-19) の感染拡大防止のため、実際の訪問は控えていますが、解禁されたときにまたお客様と直接お会いできることを楽しみにしています。

その時は、グッズを配ったり、ケースを入れている人たちと顔を合わせたりする予定です。このすべてを通じて、私はお客様のところで問題が起きたときにそれを修正するのではなく、問題が発生するのを避けられるような関係づくりを心がけています。コンピュータは人類を敵視していますから (「I'll be back」で有名なあの映画シリーズでそう描写されています)、これは継続的な課題です。

Red Hat は、スウォーミング (swarming) アプローチでサポートを行っています。自分で問題を解決する方法がわからない場合は、他の Red Hat ナードに声をかければすぐに手を差し伸べてくれます。私が Satellite にかなり習熟したので、他の TAM はお客様が Satellite に問題を抱えているときには私に相談してきますから、そのときは手伝います。誰かが IdM で困っている場合は、誰に相談すればよいかすぐに分かります。

Figure 1.

私のホームオフィスの (やや散らかった) 作業机。ノートパソコンでは Fedora 34 が実行されており、右側のサーバーは RHEL 8 と多数の VM を実行しているラボシステム (Igor) です。

TAM になるために認定は必要か

TAM は、すでに Red Hat 認定エンジニア (RHCE) であるか、専門分野について適切な認定を取得していることが求められます。TAM はテクニカル・エンジニアリング・リソースとして宣伝されているため、認定は重要です。 

RHCE をまだ持っていなくて、それでも採用されたなら、それで問題ありません。つまり、あなたはナードとしての格が高く、認定資格を比較的短期間で取得できるだろうと判断されたということです。認定資格は別として、Red Hat では大勢の優秀な人たちに囲まれて仕事ができますから、自然といろいろなことを学べます。

TAM の典型的な 1 日 (と普段とは違う 1 日)とはどのようなものか

普段とは違う 1 日とは、家にいない日です。通常、これは次のいずれかが発生していることを意味します。

  1. オンサイトレビュー/ランチ/トレーニングのためにお客様を訪問している (または帰る途中)

  2. オフサイトのイベントで講演している (好きなことの 1 つです)

  3. ニューヨークのオフィス (月例のユーザーグループミーティングまたは何となく) か、地域のコワーキングスペースにいる1 - 2 時間程度の範囲に Red Hat の従業員がかなりいるので、月に 1 回集まっておしゃべり/ランチ/大騒ぎをしています。

ケースの管理

誰かに私のアカウントをカバーしてもらったり、ケースが処理されていることを確認するために特別な注意を払う必要がある日もあります。

ほとんどの 1 日は、子供たちが学校に行き、ペットの犬たちが私の目鼻をなめ取ろうとしてくるのをいなした後、私がのろのろと 1 階に降りてくるところから始まります。VPN にログインし、IRC を起動して E メールをチェックします。夜の間にケースの登録や更新が行われていることがあるので、それらを確認します。また、バグの修正や新機能の追加も管理しているので、Bugzilla にアクセスして自分のアカウントに関連するエントリを確認することも重要です。

ケースワークを扱うとお話しましたが、必ずしもすべてのケースを個人的に扱うわけではありません。Red Hat には第一線で作業するサポートエンジニアの素晴らしい部隊がいて、具体的な作業のほとんどは彼らが行います。Satellite の問題が発生しているお客様があったら、通常は自分でケースを担当しますが、どうにもならなくなった場合は、他の人に引き渡すか、助けを求めます。 

全体的に見て、私の最も重要な仕事の 1 つは、お客様が登録したケースが必要な対応を (私がやるか他の人が対応するかはともかく) 確実に受けるようにすることです。この視点を持つことで、根本的な問題の傾向も把握できます。これにより、お客様にトレーニングを推奨したり、TAM の業務の範囲内であれば自分自身でトレーニングを実施したりすることができます。

お客様との定例会議

5 社のお客様すべてと、定期会議を持つ時間を設定しています。ほとんどは 2 週に 1 度ですが、Ceph のお客様からは、デプロイに合わせて毎週 1 回にしてほしいと依頼されています。このような TAM 会議では、現在オープンになっているケース、Red Hat がリリースした、あるいは近日公開予定の更新、最近のセキュリティパッチ (通常はわかったらすぐにメールでも通知しています)、その他の今後の予定 (Web セミナー、Red Hat Summit、ブログ投稿など) をカバーするアジェンダを用意します。 

また、ミーティングではお客様の現在のプロジェクトとニーズについて検討する時間も取っており、そこで付加価値を生み出そうと努めています。彼らは、私が Red Hat の人間であることだけでなく、私が長年にわたり彼らの側でサポートを提供しているということも頼りにしてくれます。そのため、私は企業で IT を担当するのがどういうことかについても少しはわかります。

予定された会議以外にも、お客様はいくつかの方法で私に連絡します。ケースを作成する、私に E メールを送信する、または単純に電話する、などです。Red Hat への連絡窓口が一元化されていることが、お客様にとって大きな意味を持つこともあります。

関わり続ける

お客様と話をしていないときは、いくつかの IRC チャネルをチェックします。TAM 向け、テクノロジー分野別など、さまざまなチャンネルがあります。私が回答できる質問があれば、すぐに返信します。IRC は私たちのソーシャルな「遊び場」でもあります。そのため、チャンネルではナード同士の楽しいやりとりもたくさんあります。

直接の役職以外では、いくつかのサイドプロジェクトに携わっています。ブログ、リモートワークと従業員エンゲージメントに関する運営委員会、TAM の社内サポートのためのリソースに関するプロジェクトなどです。これらの作業にはかなりの時間がかかることがあります。特に、新しく書き上げたブログ記事に満足できていない場合などは大変です。そんなときにはボリュームを大きめにして Pandora で音楽をかけると、筆が進むこともあります。

人脈を作ることは極めて重要で、キャリアの原動力にもなるテーマです。Red Hat は、何をすべきかの指示を必要とする人々のための場所ではありません。ほとんどの TAM はリモートワークで作業しているので、誰かに監視されなくても実際に業務を遂行できることは必要です。 

TAM として成長するには、日常業務以外で何かにかかわることが大切です。たとえば、私は 2016 年の後半に TAM ブログプロジェクトに関わるようになり、その結果 cgroups に関するマルチパートシリーズが生まれました。

この cgroup シリーズは、私が実際に TAM の Web セミナー (お客様向けに月に 1 回開催) と Red Hat Convergence イベントで行ったプレゼンテーションに基づいています。私はこれらのイベントで講演するのが大好きなので、講演の持ち回りチームになっています。

毎日新しいことを学ぶチャンスの多い仕事です。

私の業務対応時間は午前 9 時から午後 5 時までで、通常はそのとおりに仕事をしています。勤務時間外に何かをしているとしたら、それは自分がやりたいからです (たとえば、執筆をしたり、ラボシステムをいじってナード的なものを深堀りしたりするなど)。基本的に、真夜中のお客様対応は私の仕事ではありません。そのような場合の対応はプロダクションサポートが行います。

TAM になりたいと思ったら

正直なところ、TAM は私が今まで就いた中で最高の仕事です。多くのことを同時進行で扱わなくてはならないため、いつも少し慌ただしいですが、同僚は素晴らしく、親切で、お客様は私の努力を高く評価してくれていると感じます。コンピュータがもたらす問題に、いつでも勝った気分でいられるわけではありませんが、私たちは力を合わせて闘い続けています。

現在オンラインで開催中の Red Hat Convergence イベントでは TAM と交流できます。Red Hat Convergence は招待制の無料イベントで、技術畑のユーザーが Red Hat 製品の知識を深め、オープンソース・テクノロジーを適用してビジネス目標を達成する新たな方法を見出す機会を提供します。最新情報については、Red Hat Convergence のページをご覧ください。

興味を持った方は、いつでも Red Hat Jobs から応募できます。最後はダース・ベイダー調で締めましょう。「さあ、ダークサイドに来るのだ... クッキーがあるから!」


About the author

Marc Richter (RHCE) is a Principal Technical Account Manager (TAM) in the US Northeast region. Prior to coming to Red Hat in 2015, Richter spent 10 years as a Linux administrator and engineer at Merck. He has been a Linux user since the late 1990s and a computer nerd since his first encounter with the Apple 2 in 1978. His focus at Red Hat is RHEL Platform, especially around performance and systems management.

Read full bio