はじめに
筆者は大規模な自社開発プロダクトのAPIサポートチームから、小規模な業務アプリの保守・運用を色々と経験してきました。
それを踏まえて、技術サポートチームを組織・運営していくにあたって重要と思われるポイントについて振り返ってまとめてみたいと思います。
その上で、なるべく自律的なチームの作り方、という点にフォーカスして記述します
また、あまり大きなチームへの参画経験がないので、小さいチームを想定して書きます。
何を解決するチームにするか
まずはどんな課題を解決するチームにするかを考えます。
サポートチームを作るからには解決したい課題を明確にする必要があります。
「我々がいなかったら、だれがどう困るか、困らないのか」ということを、対会社、対コンシューマ（どのように生活が変わるのか？など）に対して考えていくのがよいでしょう。
そうしていくと、例えば、
- 小規模な企業において、
- 既存案件のサポートにリソースがかかっている
- ゆえに、稼げる案件を回すための社内リソースが逼迫している
- 大規模な企業において、
- 汎用性の高いAPIを外部へ提供する上で、提供先が多い
- ゆえに、各企業ごとのビジネスロジックにフィットしない部分が大量に発生し、ディレクションにリソースがかかる
- それが、事業のボトルネックになっている
といったことが出てくるかなと思います。
どんなチーム運営をするか
さて、チームを作って経験がある人を集めれば、ある程度いい感じになるでしょう。
ただ、運営方針を決めておかなければ、なかなか良い感じに回り続けるのは難しいことです。
というのも、「自律的な」「小規模」テクニカルサポートチームを作っていこうとすると、次のような問題が発生するのです。
- 「個人評価」の問題
- 「品質」の問題
- 「データ・技術資産」の問題
- 「コスト」の問題
そのため、それぞれの問題に対応できるような運営方法を考えておく必要があります。
「個人評価」の問題
せっかくチームができても、人が抜けてしまっては成り立たなくなります。
なんで抜けるんでしょうか？
抜ける人に話を聞いてみると、自律的な人ほど、個人の評価に納得がいかないというのはよくあることのようです。そのため、適切な評価が受けやすいように工夫をしておくことは重要です。
工夫とは、ゴール設定の明確化です。
ゴール設定ミスった例
曖昧な評価項目や、会社の利益に関係が低いゴール設定を行ってしまうと、被評価者のエンゲージメントが下がります。自律的で、達成動機が高い人ほど大きく早く下がってしまいます。
なぜなら、成果が出しづらいためです。
例えば、こんな感じです。
- 曖昧な評価項目がセットされた場合、自分の行動や成果がプラスに働いているのかそれともマイナスなのか、中間なのかがハッキリしないゆえに、どう修正したら良いかが分からない
- 利益に結びつく成果が出しにくい場合、評価値を上げる合理性がないゆえ、アップする可能性は低くなると考える
自律的に動く人ほど、自分から方向性を定めに行きがちなので、それが悪い方向に作用するとその様になってしまいがちです。周囲からは、そんなに短い期間で思いつめなくても・・・とギョッとするかもしれませんが（そういう場を結構多く見ました）。
ゴール設定例
なので、例えば、次のようにパーセンテージを利用したKPIの設定をするといったことがよいと考えます。数値にしないところがポイントです
- 見込みの顧客数をどれくらいの「割合」分導入成功に導いたのか
間接貢献も評価できるゴール設定について
担当したプロジェクトを通して得た学びのドキュメンテーションや、会社のカルチャーに基づいた行動特性がいかに見られたかを評価の軸もいれることで、直接的な貢献と将来も含めた間接的な期待貢献値の両方を図れるため、経験格差があっても評価に値する新入社員・途中参加者が表れるでしょう。
「品質」の問題
漠然とした課題設定でサポートチームを組織した場合、品質設定が甘いほど、肝心なときにサービスが使えなくなります。
なぜなら、適切なリソース配分ができないためです。
ただ、よくあるのが「発生ベースで対応する」パターンです。
なんか起きたら考える場合
発生ベースで対応する=なんか起きたら考える→すべてに全力、になるケースがあります。
API等が利用できなかった場合に、顧客がどのような機会損失を計上してしまうのか、といったダウンサイドのリスクから、どの部分を手厚くしないといけないのかを見積もらないと、すべてに全力を出すこととなり、リソースが厳しい中小企業や小さなチームであればあるほど、トラブルは多く、大きくなってしまうでしょう。
それから、何より恐ろしいのは、そもそも問題が発生していることに気づかないことです。
問題が発生したタイミングではすでに遅く、賠償問題に発生してしまったら、もう取り返しがつかなくなってしまいます。
これ起きたらヤバくね、を考えておく
ではどうするか。
適切なトリアージができるように指針を明確にしましょう。例えば以下です。
| 問題の種類 | 優先度 | 対応期限 | エスカレーション基準 | 備考 |
|---|---|---|---|---|
| コンシューマ影響あり | 高 | 当日中 | 直ちに対応不可時 | 顧客への不利益を最小限に抑える |
| 企業顧客からの問い合わせ | 中 | 2営業日以内 | 問題解決に時間がかかる場合 | 迅速なコミュニケーションを保つ |
| 再現性のあるバグ | 中 | 1週間以内 | 進捗がない場合 | 定期的なチェックポイント設定 |
| 一過性の問題 | 低 | 対応しない | 重大なビジネス影響がある場合 | リソースの効率的な配分 |
また、そのような指針が設計できるように、このサービスが動かなくなったらだれにどういう問題が発生するのかを事前に検討しておくことが重要です。
ヌケモレを防ぐために、チームづくりの最初にインセプションデッキ等の方法を用いるといったことが一つの解決策としてあるかと思います。（やるやら・リスク・トレードオフなどのトピックが特に参考になるかと思います）
- 参考：インセプションデッキ | Agile Studio https://www.agile-studio.jp/post/apm-inception-deck
「データ・技術資産」の問題
Aさんはフロントエンドに詳しくて、Bさんは小売ドメインに詳しい、Cさんはアプリログの便利クエリをいっぱい持ってる、とか、だんだんナレッジが溜まっていきますよね。
でも、その溜まり方は望ましい形なのでしたっけ？
漠然とした課題設定でサポートチームを組織した場合、まとまりがないタスクの取り方となってしまうがゆえに、必要なデータや技術資産がいつまでも構築されません。
なぜなら、発生する問題はバラバラなので、分類しない限りはバラバラなタスクが発生するためです。
- ビジネスに関する問題なのか
- テクニカルに関する問題なのか
- 両方あるいは分類し難い問題なのか
- 一過性の問題なのか
- 再現性のある問題なのか・・・
軸を持って分類して受けるべきタスクを判断しないと、APIテクニカルサポートチームなのに、すべてエンジニアへ問題を丸投げしてしまって、顧客の開発環境の問題かもしれないものを対応させ、それが無駄になったり二度手間になったりして逆にいないほうがよかった、みたいなことになるかもしれません。
「人」の設計と不可分ですが、どのようなデータ・技術資産・その他ナレッジをためて行くべきなのか？どういった問題は別チームへ任せるべきなのか？我々のチームがなかったら他のどのチームがどう困るのか？困らないのか？といった点を検討しておく必要があります。
スキルマップの作成
スキルマップを作って、今だれがどんなスキルを持っているかなど、可視化をしておくのは有効かと思います。
チーム外で連携する方も含め、なるべく関係者全員分を入れることがおすすめです。
それがあると、チームとして今は他チームに頼っているけど、それをチーム内へ持ってきたいね、などあるべきをチームで考えることができます。
そのような情報があれば、自律的なメンバーが多い場合には勝手に方向性を考えて動いてくれることも期待できます。
例：
「コスト」の問題
ここまで上げた他の3点と不可分ですが、それらが曖昧であればあるほど、余計なリソースが発生します。
必要なときに必要な人員が不足します。
もっと恐ろしいのは、今、充足しているのかすら判断がつかず、やみくもに採用を続けてしまい、その採用コストや育成コスト・管理コストが無駄に掛かってしまうことです。
よって、「個人評価」「品質」「データ・技術資産」の設計をもとにして、将来的にどのような問い合わせがきたら、どのような領域に、どのような速度で応答すべきなのかを算出し、それに見合うだけの人員をなるべく一定に保つようにすることを継続的に行うことが重要だと思います。
プロセスとスキルマップの作成
業務プロセスの整理に加えて、スキルマップとかを作って、今どの領域をカバーする人が足りないとか（余っているとか）、可視化をしておくのは有効かと思います。
それらの対応付けがあれば、人員の募集をかけないといけないとか、SaaSを契約すればOKだとか、打ち手の検討がしやすくなるでしょう。
まとめ
それぞれのセクションで述べたことのまとめです
| 観点 | 工夫 |
|---|---|
| 個人評価 | - 明確なゴール設定 - パーセンテージを利用したKPIの設定 - 学びのドキュメンテーションや行動特性を評価の軸に含める |
| 品質 | - 適切なトリアージの指針設定 - 問題発生時の対応プロセスの明確化 |
| データ・技術資産 | - スキルマップの作成 - タスクの分類と適切な割り当て - ナレッジの共有と文書化 |
| コスト | - 「人」「品質」「データ・技術資産」に基づくリソース計画 - 必要な人員の算出と保持 - 業務プロセスの整理とスキルマップの活用 |
おわりに
4点を明確にすれば、メンバーが自己判断で会社が期待する方向へ進み続けていくことがしやすいのではないかと思います。
ただ、あくまで筆者が特に重要と思ったポイントというだけですので、実際にはもっとたくさんのポイントがあるでしょう。
すべての業種・規模の会社に当てはまるものではないかもしれませんが、チームづくりの参考となれば幸いです。