「技術的問合せ」に対応するチームの運用
この記事はコインチェック株式会社（以下、コインチェック）のアドベントカレンダー17日目（シリーズ2）の記事です。
概要
エンジニア(ソフトウェア開発者)は、業種にかかわらず社内外から技術的な問合せを受けることがあるかと思います。
自分たちが運用するサービスに対する責任説明を果たすべく真摯な対応をしたいところですが、その頻度があまりに多いと開発効率の低下といった悪影響を及ぼします。
Coincheckは暗号資産を取り扱う金融サービスという性質上、このような問合せの頻度が体感上非常に高く、事業の早い段階からその対応にリソースを割いてきました。
本稿では、私が入社した2017年ごろから現在に至るまでに発生した課題とその対策をまとめてみました。
問合せの種類
「技術的問合せ」というとサービスの仕様に関する質問をイメージされることが多いかと思いますが、質問元とその質問内容は多岐にわたります。
お客様
暗号資産の売買・送受金等に関してお客様から不明点や不満があった場合に、弊社は問合せを受けて確認・回答します。
基本的にはカスタマーサポート部門が応対しますが、技術的に不明な点があった場合は、エンジニアが確認します。
取引所での売買について、意図せずキャンセル扱いとなったが、何故なのか
システムトレードをするにあたって〜をしたいが、現在のAPIで実現可能か
相続のためにイレギュラーなログイン・出金をしたい
警察・税務署等
マネーロンダリング対策・犯罪収益移転防止・徴税等により、警察機関や税務署からの依頼を受けて対応を行うことがあります。
マネーロンダリングの疑いのある特定の口座について情報を提供してほしい
未納税のお客様の資産を取り押さえるために口座凍結を行いたい
金融庁・日本暗号資産取引業協会(JVCEA)等
JVCEA等の協会の運営のために、各社サービスの利用状況や通貨別の取引状況を報告・共有します。
JVCEAの規則によって定められた特定通貨の参考価格を提供してほしい
内閣府令によって定められた帳票を作成・管理してほしい
通貨発行体・連携他サービス等
新規通貨の上場や他社サービスとの連携により、特定通貨や機能の統計情報を提供することがあります。
IEOでの通貨上場後の通貨の取引高、レート推移を集計してほしい
確定申告補助サービスに対応するために、取引履歴に特定情報を追加してほしい
社内外の監査
社のガバナンス・コンプライアンス維持のために、定期的に社内外の監査を実施しています。
コインチェックではお客様の資産をお預かりする性質上、その資産を管理・監視するサービスについて技術的説明が求められます。
顧客資産を保護するための分別管理がシステム上どのように行われているのか説明してほしい
取引所で注文を出してから約定するまでの間の計算過程を説明してほしい
社内の対外窓口部署
上記の問合せは原則的にカスタマーサポート・財務・法務・マーケター等の社内の他部署が窓口となるため、
彼ら自身が自社サービスの解像度を上げ、単独で回答するために、社内管理画面(以下、Admin)の開発を求められます。
新規に追加されたサービス(たとえばNFT取引)に対して、お客様に対して単独で説明できるように、取引の詳細がわかるAdmin画面を開発してほしい
新規のお客様が増加し本人確認(KYC)の審査が滞っているため、効率的に行うためのAdmin画面の改修をしたい
マーケティングのためにサービスの利用状況の統計をとりたいが、データベース上の情報の関連性や集計条件が不明なため、一緒に考えてほしい
問題
このように問合せの種類が多く頻度も高いため、対応するのがだんだんと難しくなってきてしまいました。
リソースの不足
回答までに非常に時間がかかってしまったり、重要度の低い問合せは回答されずにうやむやになってしまう
対応品質が不安定
メンバーの知見が集約されていないため、担当者によって回答や集計結果が違ってしまう
類似の質問に対して対応するために、すでに回答が出ていることを再調査してしまう
オンボーディングのコスト
対応するために、技術・金融・暗号資産のそれぞれの知識が必要なため、新規メンバーが担当できる領域を広げていくのに時間がかかる
開発効率の低下
新規サービスの開発に時間を避けない
問合せの原因となっている根本的な課題を(開発により)解消できない
メンバーのモチベーションの低下
人によって仕事のやりがいは違ってきますが、やはりサービスの開発に携わったり、自分の技術を活かせる業務をしたい
対策
こういった課題を解消すべく、コインチェックでは問合せを効率的に対応するための継続的な改善を行ってきました。
具体的な施策をいくつかご紹介します。
課題の管理
スタートアップ色がまだ濃かった頃、チームという枠組みはあるものの、エンジニアは個人が別々のプロジェクトを担当する形式でした。
問合せについても同様で「詳しそうな人に聞く」という状況だったため、事業の拡大につれて管理しきれなくなってきます。
このような状況のため、まずは問合せをタスクとして管理・追跡できるようにしました。
ツールはTrelloを使い、カンバン形式でステータスを管理する
問合せに対応する際には過去のタスクを検索し、前例があればその内容を説明する
タスクにはラベルを設定し、問合せ元や内容を分類する
チームの分離
課題管理によって対応のヌケモレは防げるようになりましたが、
いつまでもタスクが増えていって問合せを捌ききれないことが視覚化されたことで明らかになります。
そもそも問合せが来なくていいように不具合の修正やAdminの開発を行いたいのにその時間がない...という状況になってしまったため、開発チームと問合せチームを分けて運用するようにしました。
問合せは社内の各部署から、Slackの規定のチャンネルで行うようにしてもらう
各メンバーは依頼を受けたらまずは起票し、あとで担当者をアサインし、特定個人に負荷が集中しないよう調整する
人員の確保
問合せチームが集中して引き受けることで全社的な開発ベロシティは向上したものの、
問合せの件数は依然として多く、回答に時間を要する状況が続いていました。
絶対的な人員数が不足していたため、ここでチームの拡大に向けて動きます。
RubyおよびRailsの経験
数億件規模のテーブルがある大規模RDBの運用経験
金融システムの知見(取引所の仕組み、会計、法規等)
暗号資産に関する知見(ブロックチェーンの送受金等)
こういった要件で募集を行いました。金融サービスかつRuby、というのがかなり珍しいので全てを満たす人はなかなかいませんでしたが、メンバーのスキルの組み合わせによってチーム全体として要件を満たせる方針で採用を行い、結果として技術と業務理解度の両面を底上げすることができました。
ナレッジの構築
類似の問合せを効率よく捌くためには前例を見る必要があり、
これまでは前例のタスクを検索することで対応していましたが、
より体系的に管理できるように、チームとしてナレッジベースを運用するようになりました。
ツールはConfluenceを使い、カテゴリ別にツリー状に管理する
過去に複数回あった問合せは記事にして、調査・対応方法や注意点を書いていく
問合せ以外にも、自社のデータベースの構造やシステムの挙動についても仕様書化していく
コマンドの管理
問合せに対応する際に、システム用のコードとは別に、ワンライナー(コマンド)を書くことがよくあります。
サービスの利用状況などのマクロな集計
特定の口座に対するステータス変更
などが該当し、ここまではタスクやナレッジに記録していました。
問合せを重ねるたびに修正が発生し、同一の作業に対して複数のバージョンが生まれてしまったため、
こういったコマンドもGithubで管理するようになりました。
専用のリポジトリを用意して集約する
システム用のコードと同様にPull Requestによってのみ改変し、レビューを受ける
システム用のコードと同様に規定のコーディング規約によって品質を保つ
アサインメントの強化
これまでの施策によって問合せの対応が効率化されましたが、
今度は根本的に問合せが来ないようにする(問合せチームに聞かなくてもよくなる)ための施策を進めようとします。
根本解決の時間の捻出のために、より効率的なアサインを模索しました。
問合せチームの中でも「当番」を数名設ける
当番となった人は問合せの受付・一次回答を行い、即答できるものはその場で返す
時間を要するタスクは起票し、原則的に当番が対応する
一定数の問合せが滞留したり、緊急で回答する必要がある場合は他メンバーも加わる
当番になっていないメンバーは、問合せを根本的に減らすための開発タスクを担当する
根本的な課題解決
ここまでの施策によってメンバーが時間を割けるようになったため、開発を進めていくことになります。
定期的に実行する必要のあった集計作業をスケジューラに組み込み、自動的に集計・提出されるようにする
特定オペレーション用のAdmin画面を作成して、コーポレート部門が単独でデータの修正を行えるようにする
特定情報の閲覧用のAdmin画面を作成して、カスタマーサポートや他部門が業務上必要な情報にアクセスできるようにする
考察
施策を重ねたことによって問合せの件数は低減し、速度と品質を保つことができるようになりました。
コインチェックの問合せチームは現状安定していて、困難な時期をいったん乗り切れたように感じますが、さらに次のステージに進みつつあります。
黎明期のコインチェックのような小規模な事業であれば効率化のために問合せ専門のチームの存在はやむ無しでしたが、今後事業の拡大につれてCoincheckの機能の数と複雑度は増していき、1つのチームがその全てを把握するのが難しくなってくるためです。
弊社では近年事業部制を導入したことで取引所・販売所・入出金、といった各機能を担当する部門が独立して運用する組織体制にシフトしており、本稿で取り上げた問合せの対応についても、各部門が自身の管理するシステムについて担当する形に戻しつつあります。
ここまでお話しておきながら「問合せ専門のチーム」というのは将来的には役目を終えそうなのですが、これまでに得た、問合せに向き合うための知見は担当チームが別れた後も活かしていけそうに思えます。
より体系化させてフレームワーク的に運用できるようにすることで、全ての部門が生産性を維持できるようにしていけたらと思っています。また進捗ありましたら記事にしたいと思います。