「お客様と未来を描く戦略＆技術伴走 — CM エンタープライズサービス TAM 支援 2つのユースケース」

https://events.classmethod.jp/study-club/connpass-402011/

記事の中の”私”が登壇の方となります。

伴走支援は「人手を足すこと」ではない——少人数チームで大規模なお客様を支えるには

人数は少ない。でも、仕事は小さくない

ある大型ゲームプロジェクトのリリース支援で、コアチームはわずか2人でした。もう一方は、組織が複雑でプロダクトラインも多い大型小売企業。コスト、運用、ガバナンスの3本の軸を同時に走らせる必要がありました。従来の「人材派遣」的な発想で見れば、どちらも人手が足りないように見えます。しかし実際にやってみると、人数の少なさそのものよりも、チームが力を正しい場所に置けているかどうかのほうがはるかに重要でした。

私は Classmethod で Enterprise Service を担当しています。入社前は SIer と AWS でお客様支援をしており、「システムに詳しい担当者を1人張り付ける」やり方を数多く見てきました。このやり方は反応が速い半面、気づけば「お客様の手が1本増えた」だけで終わり、「お客様に新しい能力が増えた」にはならないことが少なくありません。だから私が話したい伴走支援は、人手を足すことではありません。お客様と同じ船に乗り、進む方向を一緒に確かめ、推進力を保ち、最後はお客様自身が船を目的地まで運転できるようにする。そういう支援です。

まず、私が考える3つの役割から説明します。AIの話は最後に置きます。3つの役割すべてに関わるからです。

伴走支援の3つの顔——コンパス、フロー、触媒

伴走支援と聞いて多くの人が思い浮かべるのは、「お客様のシステムを深く理解し、問題を先回りして見つけ、主体的に支援する」というイメージでしょう。間違いではありませんが、少し抽象的です。私はよく3つの比喩で説明します。

1つ目はコンパスです。お客様の船は目的地がすでに決まっていて、乗組員も優秀です。ただ、進む方向を一緒に見てくれる人が船に必要です。伴走支援は行き先を代わりに決めることではなく、お客様が取捨選択するときに、方向をはっきりさせることです。

2つ目はフローです。船が前に進むには、方向だけでは足りません。動力をしかるべき場所へ滞りなく伝える必要があります。組織に置き換えれば、情報、意思決定、実行の間の「流れ」を詰まらせないことです。これは車や船のオイル、エンジンのメンテナンスに似ています。普段は見えないけれど、走り続けられるかどうかを左右します。

3つ目は触媒です。お客様にはもともと力があります。伴走支援は外から何かを注ぎ込むのではなく、その力を引き出し、より十分に反応させることです。

この3つは3つの役割に対応しますが、実際のプロジェクトでは同じ小さなチームが場面に応じて役割を切り替えています。

チームの組み方——人を送るのではなく、船に乗る

基本構成は、担当営業と運用エンジニア、必要に応じてソリューションエンジニアです。契約内容によっては専任の小チームになったり、数人がお客様の船に並んで乗ったり、場合によっては一緒に乗り込んだりします。

ここで大事なのは「何人送ったか」ではなく、「お客様の船がそれで安定して進んだか」です。専任チームでも、チケットを待つだけなら人数が増えても派遣と変わりません。逆に2〜3人のチームでも、重要な局面で判断し、手を動かし、責任を持てれば、人数以上の規模を支えられます。

次の2社は、ちょうど対照的な形をしていました。

事例1：ゲーム会社の「時間軸」——局面に合わせて重心を移す

1社目はゲーム企業です。大型バージョンのリリースが控え、時期は明確、セキュリティ要件も高い。リリース後には最適化も必要です。お客様自身の理想は高く、最終的には自分たちで運用できるようになりたい。ただ、リリースで何が起きるのか、自分たちのチームで受け止められるのかについては、不安を抱えていました。

そこで2人の専任チームを置きました。営業1人、エンジニア1人です。リリース前は、お客様の不安を具体的な技術課題に分解し、1つずつ解消していきました。リリース当日はチームが現場に立ち会い、リリース前後は「何か起きてから見る」のではなく、2時間に1回は主要なメトリクスを確認し、異常があればすぐにチケットを起票して後方のサポートチームにつなぐ。地味なやり方ですが、これによってリリースは「運に左右される一瞬」から、観測と切り戻しとエスカレーションの経路があるプロセスに変わりました。

安定した後、チームの重心は動き始めます。まずリリースの安定、次に最適化、そしてセキュリティ強化、最後にコスト最適化。ここで重要なのは、目標を最初に固定して機械的に実行したわけではないことです。お客様が最初に思い描いていたことは多く、基準も高い。実際に走り始めてから、私たちは途中の「中継地点」を何度も調整しました。まずここを守る、次にこれをやる、という具合に。最初に見えていた目標は残ったまま、そこへ至る道筋が描き直されたのです。

今では、お客様は何かあれば契約上のチケットフローを待つのではなく、まず私たちに相談し、壁打ちをしてくれます。この関係は、人数を積み上げて作れるものではありません。

事例2：大型小売の「空間軸」——途切れた流れをつなぐ

2社目は大型の小売企業です。プロダクトラインが多く、それぞれに担当者がいて、組織は複雑。ツールも複雑で、互いに分断されています。よくあるのは、誰かが問題に気づいても、それを推進できる議題に整理する人がおらず、そのまま止まってしまう状況です。

お客様側には AWS に詳しいベテランの責任者がいて、最終的にはチームが自走することを望んでいました。私たちが設計した支援は、コスト、運用、ガバナンスの3軸です。

なぜ3つなのか。コスト削減だけを行えば、どれだけ成果が出ても一度きりで終わります。削減を続けていくには、運用支援とガバナンス強化を同時に進め、プロセスが自ら回る仕組みを作る必要があります。コストは入口ですが、入口は終点ではありません。

3本の柱は横並びではありません。上に戦略、下に現場の運用エンジニアがいますが、立ち位置は異なります。戦略側は現場に降りていけること、運用側は全体を見上げられることが求められます。コストの具体策としては、計算リソースの Compute Savings Plans のような割引の設計や、データ転送の割引の整理。さらに可視化を行い、日次で取得したデータから「この量なら過剰な確保のリスクがなく、より有利なコミットメントを買える」と分析し、データを購買の根拠に変えていきます。運用エンジニアは日々動かし、ずれがあれば戦略側にフィードバックする。戦略側は計画と期待効果を示し、また現場で検証する。両者がボールを投げ合うのであって、それぞれが別々にやるのではありません。

結果として2つの数字が出ました。およそ1か月で、それまで溜まっていたタスクを片付けたこと。そして、コスト削減の幅が当初の目標を上回ったことです。コストの可視化は後に日次のコスト削減リストへと育ち、ガバナンス上の難所もサービスプロセスに整理されていきました。

2つの形、3つの共通点

2社のチームの形は異なります。ゲーム会社は時間軸の支援です。最小規模の専任チームが、リリース、安定、最適化、セキュリティ、コストという局面に合わせて重心を移していく。小売企業は空間軸の支援です。多層の組織、複数のプロダクトラインを、より広くカバーし、階層ごとの問題をつなぐ必要があります。

ただ、根っこの部分には3つの共通点があります。

1つ目は、提案を相手の言葉で語ることです。こちらで用意したメニューを押し付けるのではなく、お客様がすでに口にした不安を、お客様が判断できる案に翻訳する。お客様が「これは自分が心配していたことだ」と感じて初めて、話は前に進みます。

2つ目は、中立の立場で判断材料を出すことです。「私たちが良いと思うから」ではなく、「これがデータで、これが取捨選択で、これがリスクです」と示す。伴走支援の価値の多くは、判断の根拠をお客様の目の前に並べるところにあります。

3つ目は、戦略と計画を実行まで落とし込むことです。スライドだけの支援は組織の奥まで届きません。逆に手を動かすだけの支援は、お客様の仕事を代わりにやるだけになります。両方を同じチームに置き、互いが見える状態にする必要があります。

伴走支援の本当の難しさ

このやり方に難しさがないわけではありません。

よく起きるのは、私たちに一番近いお客様のチームは理解が早いのに、組織の奥の層が追いつかないという問題です。下に行くほど、「あなたたちの言うことは正しいけれど、こちらでは動けない」という壁にぶつかります。ここで理屈を並べても仕方がありません。具体的なユースケースを1つ選び、まず成果を出して、その成果に人を説得してもらう。だから私は、いきなり全社改革を語るよりも、結果が見える小さな切り口から始めるほうが好きです。

もう1つは、お客様が本当に学んでしまったとき、伴走チームの価値はどこにあるのかという問いです。私の答えは、「私たちにしかできないこと」ではなく、観察力、経験、調達力、そして最後まで届ける責任です。ツールやプロセスは学べても、組織には常に新しい変化と新しい取捨選択があり、一緒に判断する人が必要です。伴走支援の終点は、お客様が私たちがいないと困る状態ではなく、お客様が自分で歩けるようになり、それでも重要な分岐点では相談に来てくれる状態です。

生成AIの位置——武器づくりを速め、最後に届けるのは人

最後にAIの話です。このセッションの本当の主役は、AIツールと人でした。AIは「ツールをいくつか増やす」ことではなく、伴走支援の枠組みの中に組み込み、コンパス、フロー、触媒の効果を増幅させるために使います。

私たちのやり方は、1つの循環にまとめられます。まず人が鮮度の高い情報を集める。お客様の現場の変化、組織の動き、技術の更新。次にAIでその情報を「武器」に変えるスピードを上げる。分析、提案、成果物。アウトプットは速く。ただし最後の一手は必ず人がやる。お客様が理解し、受け入れ、自分で次に進められる形に変える。お客様が受け入れれば信頼が生まれ、新しい機会が現れ、また次の循環に入る。

もっと率直に言えば、AIは武器づくりを速くしてくれます。しかし、その武器をどうお客様の手に渡し、どうすれば「自分のこと」だと感じてもらえるかは、人にしかできません。速さはAIがくれますが、間合いは人が決めるのです。

終点は、お客様自身が走り出すこと

最初の問いに戻ります。なぜ少人数で大規模な案件を支えられるのか。

一人ひとりが強いからではありません。チームが力を正しい場所に置いているからです。方向、流れ、触媒。戦略と実行を分けない。お客様の局面に合わせて重心を動かす。伴走支援の最終的な成果物は、報告書でもツールでもなく、お客様自身が走り出せる組織です。

人数が少ないことは、むしろ、このことを考え抜くための制約なのだと思います。