はじめに
筆者は2022年から、大規模な自社開発プロダクトのAPIに関する技術面でのサポートを行うチームへフルコミットしてきました。また、それ以前も自社開発のプロダクトのサポートや、小規模な業務アプリの保守・運用も経験しました。
それを踏まえて、技術サポートチームを組織・運営していくにあたって重要と思われるポイントについてまとめてみたいと思います。
なお、本ページでは、他律的なチーム（マニュアルや既存の方法を続けたり、積み上げていくべきなチーム）については記述しません。
なぜサポートチームを作るのか
そもそも、サポートチームを作るからには解決したい課題を明確にする必要があります。
例えば、小規模な企業において、既存案件のサポートにリソースがかかっているゆえに、稼げる案件を回すための社内リソースが逼迫しているとか、大規模な企業において、汎用性の高いAPIを提供する上で、提供先が多いゆえに各企業ごとのビジネスロジックにフィットしない部分が大量に発生し、ディレクションにリソースがかかることが事業のボトルネックになっているといったことは想像しやすいかと思います。
このような課題が明確になっていない場合、次のような問題が発生するでしょう。
- 「人」の問題
- 「品質」の問題
- 「データ・技術資産」の問題
- 「コスト」の問題
そのため、チーム作成の理由を明確にする必要があります。
そのための問いとしては、「我々がいなかったら、だれがどう困るか、困らないのか」ということを、対会社、対コンシューマ（どのように生活が変わるのか？など）に対して発生させていくことが一つの方法だと思います。
「人」の問題
漠然とした課題設定でサポートチームを組織した場合、人の設計が甘いほど会社やマネージャーはメンバーに対して期待する成果や行動を明確化できません。
曖昧な評価項目や、会社の利益に関係が低いゴール設定を行ってしまうと、被評価者のエンゲージメントが下がります。オーナーシップがあり、達成動機が高い人ほど大きく早く下がってしまいます。
なぜなら、成果が出しづらいためです。
どういうことかというと、まず、曖昧な評価項目がセットされた場合、自分の行動や成果がプラスに働いているのかそれともマイナスなのか、中間なのかがハッキリしないゆえに、どう修正したら良いかが分からないためです。その上で、利益に結びつく成果が出しにくい場合、評価値を上げる合理性がないゆえアップする可能性は低くなります。
そうなってくると、「自分なりに頑張ってみたけど、評価されなかった。でも、どうすればよいかわからない」という閉塞感を抱えることになります。
それらが成果が出しにくい理由になります。実際には、ここに「仲良し人事」などの発生も加わり、閉塞感どころか納得感もない評価を抱え続けることになるかもしれません。
例えば、大企業において、自社サービスの汎用APIを提供しているとして、そのAPIのテクニカルサポートをするとします。そこでサポートに対応した件数や関わったプロジェクト数をKPIにしてしまうと、そもそも営業や顧客の技術力など、外部要因によって大きく結果が変わってしまいます。さらに、経験年数が多いと他のメンバーとの経験格差があるため、結果的に年功序列のような評価となってしまう可能性が高まります。
よって、「なぜ」チームを作るのかという点について、合理性のある課題設定をした上で、メジャラブルな目標設定をすることが重要です。
例えば、APIを通した自社システム利用増加によって見込める売上を母数とし、見込みの顧客数をどれくらいの”割合”分導入成功に導いたのか、といった”パーセンテージ”を利用したKPIの設定をするといったことが挙げられます。その上で、学びのドキュメンテーションや会社のカルチャーに基づいた行動特性がいかに見られたかを評価の軸もいれることで、直接的な貢献と将来も含めた間接的な期待貢献値の両方を図れるため、経験格差があっても活躍できる途中参加者ができるでしょう。
「品質」の問題
漠然とした課題設定でサポートチームを組織した場合、品質設定が甘いほど、肝心なときにサービスが使えなくなります。
なぜなら、適切なリソース配分ができないためです。
API等が利用できなかった場合に、顧客がどのような機会損失を計上してしまうのか、といったダウンサイドのリスクから、どの部分を手厚くしないといけないのかを見積もらないと、すべてに全力を出すこととなり、リソースが厳しい中小企業や小さなチームであればあるほど、トラブルは多く、大きくなってしまうでしょう。
ただ、何より恐ろしいのは、そもそも問題が発生していることに気づかないことです。
問題が発生したタイミングではすでに遅く、賠償問題に発生してしまったら、もう取り返しがつかなくなってしまいます。
そのため、適切なトリアージができるように指針を明確にしましょう。例えば、
- コンシューマ or 顧客に不利益が発生したものは当日中に対応する
- 対応完了に時間がかかる場合には、フォーマットに基づいてエスカレーションする
- 再現性があるバグはチケット管理ツールでトラッキングし、毎週チェックポイントを設けて期限を更新し、完了まで管理する
- 一過性の問題やバグによるビジネス面のリスクが受容できる場合には対応しない
などです。
また、そのような指針が設計できるように、このサービスが動かなくなったらだれにどういう問題が発生するのかを事前に検討しておくことが重要です。
ヌケモレを防ぐために、チームづくりの最初にインセプションデッキ等の方法を用いるといったことが一つの解決策としてあるかと思います。（やるやら・リスク・トレードオフなどのトピックが特に参考になるかと思います）
参考：インセプションデッキ | Agile Studio https://www.agile-studio.jp/post/apm-inception-deck
「データ・技術資産」の問題
漠然とした課題設定でサポートチームを組織した場合、まとまりがないタスクの取り方となってしまうがゆえに、必要なデータや技術資産がいつまでも構築されません。
なぜなら、発生する問題はバラバラなので、分類しない限りはバラバラなタスクが発生するためです。
ビジネスに関する問題なのか、テクニカルに関する問題なのか、両方あるいは分類し難い問題なのか、一過性の問題なのか、再現性のある問題なのか・・・など、軸を持って分類して受けるべきタスクを判断しないと、APIテクニカルサポートチームなのに、すべてエンジニアへ問題を丸投げしてしまって、顧客の開発環境の問題かもしれないものを対応させ、それが無駄になったり二度手間になったりして逆にいないほうがよかった、みたいなことになるかもしれません。
「人」の設計と不可分ですが、どのようなデータ・技術資産・その他ナレッジをためて行くべきなのか？どういった問題は別チームへ任せるべきなのか？我々のチームがなかったら他のどのチームがどう困るのか？困らないのか？といった点を検討しておく必要があります。
「コスト」の問題
ここまで上げた他の3点と不可分ですが、それらが曖昧であればあるほど、余計なリソースが発生します。
必要なときに必要な人員が不足します。
もっと恐ろしいのは、今、充足しているのかすら判断がつかず、やみくもに採用を続けてしまい、その採用コストや育成コスト・管理コストが無駄に掛かってしまうことです。
よって、「人」「品質」「データ・技術資産」の設計をもとにして、将来的にどのような問い合わせがきたら、どのような領域に、どのような速度で応答すべきなのかを算出し、それに見合うだけの人員をなるべく一定に保つようにすることを継続的に行うことが重要だと思います。
おわりに
4点を明確にすれば、メンバーが自己判断で会社が期待する方向へ進み続けていくことがしやすいのではないかと思います。
すべての業種・規模の会社に当てはまるものではないかもしれませんが、チームづくりの参考となれば幸いです。
