本質を探る方法としても使えるDevSupport

こんにちは、Quipperのwebエンジニアを担当している @motorollerscalatron です(※1)。

今回は、題目の通り、DevSupportという業務についてお話させて下さい。

Quipperのwebチームでの問い合わせ対応については、2年前に@wozakiさんが「Developerの問い合わせ対応との関わり方」という形ですでに書かれています。今回は、特に

新しいメンバーが増えてどう対応しているか
対応の記録をどう蓄積して次に役立てるのか
蓄積されたノウハウをどうやって共有するか

に焦点を絞って書きたいと思います。

新しいメンバーを迎えて

現状：2018年下期のDevSupport業務

私が仕事をしているWeb ToCチーム(※2) では、サービス運用上で発生する問い合わせや不具合により、技術的解決が必要となってDevが対応作業をするような業務を DevSupport と、呼んで取り扱っています。一括して扱うので、トリガーの種類にも、色々あります。

連携システムからのアラートメール
Slack経由でのwebチームへの問い合わせ（webエンジニアチームへのメンション）
オペレーション側が何かの操作中に気がついたユーザー側の異常（△△の画面が見えない）
ユーザーからの問い合わせ（××をしているはずなのに、反映されない）
Sentry, New Relicなどのメトリクスツール上での異常値検知...etc

定型的なものから、パターンにあてはめにくいものまで様々です。

この業務は、週ごとに担当者を交代して行なっています。専用の担当者を設けることも考えてはいましたが、ノウハウ共有とリソース配分を考慮して、現在はチーム全員で分担する形となっています。

アプローチは2年前のものと基本的に変わってはいませんが、もう1度簡単に振り返ります。

チームが1週間でローテーション制で担当
1つ1つの対応案件は、特定リポジトリ化のGitHub issueとして管理（サポートIssue）
issueには特定の識別用のラベルを貼ることでDevSupport業務対応であることを示す
サポートIssueは、Devでも、CSでも、ビジネスでも立てられる
問題の切り分け後は、障害の報告やメトリクスツールが残してくれたログ情報などをもとに障害箇所を特定し、データ対応を行う

新メンバーへの知識の伝播

自分の入社に前後して、新規加入メンバーが短期間でToCチームにjoinしました。新規加入メンバーとSupport経験済のメンバーとの比率が、半々程度になったのもあり、 経験者がメイン担当者のサポートにつく ようにしていました。最初はチュートリアル的に、ペアプロの要領で、同じスクリーンを見ながら、実際にissueの掘り下げ、slackでの関係者との会話、実際の作業や対応のコマンド実行を、一緒に行なっていきます。

パターン的に発生するような問い合わせについては、専用の対応手順を示すwikiが立ち上がっていることもあるので、そういったものも共有してもらい、issueはslackに実際の実行した内容を順次記録するようにします。このとき、２回目、３回目となるにつれてだんだん慣れてはくるのですが、完全にマニュアル化されている作業でも、あえてslackで他の人に見えるような形で作業を残していきました。

対応を記録していく様子。下にはさらに個々の対応を記録しています

前の記事で @ohbarye さんが書いている “Working Out Loud” にもあったような、詰まっていようと進んでいようと客観化する上で、そのときわからない状態のものを共有します。すると、そういう考えを持たなかった時には、

できないのは、自分にスキルがないのが問題で、それは自分で別に時間をとってどこかでやらないと

としか考えられなかったのが

今の作業マニュアルは○○の業務知識の前提がない人には、暗黙知かもしれない　→　手順に○○のURLか、補足説明をつけ足すべきではないだろうか
調べてみたら、今の作業手順は、部内で標準で使っていた××がなくなったので、現実にそぐわなくなっている　→　手順書を書き換えよう
やっぱり皆わかりにくいと思っている部分だった　→　他のルーチン的なDevSupportタスクとは少し差別化するべきか、もう一度チームと相談してみよう

のようにサイクルとして、改善を取り込んでいけるような形になりました。

私自身は、昔から、人に困った状態を共有するのが苦手です。最初のうちは特に、キャッチアップするのは自分の側で、なるべく自分周囲の邪魔をしたくない（客観的に聞かせたいときには「工数をとりたくない」、とも表現したりする）と思って億劫になってしまったりしていました。ですが、チームの中でもそういった形で様々な人が取り組んで難しくなるところをその度に共有して、対応コマンドなり、作業マニュアルなりを客観化された目を通して改善していければ、そこを気にする必要はない、と言われて、少し楽になりました。

数ヶ月経つと

そんなこんなで、年末には、システムのアラートとエラーコードの組み合わせなどでフローチャート的に診断・対応できる部分は、ようやく独力でできるようになってきました。

ひと通り作業に慣れたことになり、今月からは、今まで新メンバーにサポートをつけて回していたローテーションも、原則一人で担当していくことが決まりました。オンボーディングの時点でいち早く新しい人を引き上げていく形で共同作業をしたからこそ、今この形で不安なく適応できた、と思っています。

対応記録の蓄積から根本問題の解決へ

前に述べたように、一つ一つの対応案件は、GitHub issueで記録していきます。 Quipper社内では全員GitHubを使用しているので、共通の認識がとれ、文言やラベルでも検索ができて便利です。

「サポート業務」として切り出していく（一つ一つissueにしていく）と、色々と蓄積されていきますが、その中でも、段々と手順が定式化できるような業務が出てきます。人の判断が途中で必要のないものはそういったものはいずれは自動化をしたほうがいいですが、リソースに限りがあると他の業務を優先したり、タイミングは難しいこともあります。

　一次対応: ユーザーへの不利益がないような状態に戻す処置。
　恒久対応: エラーを回避したり、自動解決できるようなコード改修を行う。

（人の手を介せずに完結する）システム的な改善策を入れるか、手動オペレーションでのりきるようにするかは、毎回議論します。現状とリソースのバランスを見ます（※3）。

問題が起きた時、たいていの場合、コンテキストは色々なところに散らばっていて本質がどこにあるのかは確信が持てないことが多いです。issueには記録していくのですが、必要な情報が全てつながるのは、いくつかステップを踏むことが多いです。キャッチされたエラーが特定できたとしても、次は、コード、その中のエラーハンドリング、フレームワークの設定、インフラ側の設定……、どこまでもつながっている可能性があります。それを紐解いていく事後分析をするにも、必ずしも事象の因果関係が明確になるような形で情報が揃うには、時間がかかることもしばしばです。

そういった中、A) 最初の段階ではある程度手探りな期間として運用していき、B) 問題の本質をとらえられた時点でそこで一切の対応をおこなう、というのが流れだとすれば、A)の期間を限りなく短くできれば良いように思えます。

ですが、A)の期間にも中で起こっていることの副次的な仕組みの理解、など、手作業部分にも、必ずしも百害あって一利なしとは言い切れない部分があります。大きな問題であったり作業の複雑さや依存関係によっては、さらに対応を分割して計画することもあります（このような場合はチェックボックスなどで）

切り出された作業タスクというよりは、継続的な改善および問題解決という視点でサポート業務を続けている、という視点もあります。

根本問題になかなかたどりつけなったり、途中で別の問題が絡んでくる、という部分もありますが、解決できたときには人知れぬ喜びがあるのも、また事実です…！

蓄積されたノウハウの共有

いくつかの例として対応し対応方法が確立しかけたところで、専用のWikiにまとめていきます。前項で述べたようなissueがうまく蓄積してラベルづけがされていれば、たいていは検索できてしまうのですが、一元的に問題をディレクトリとして階層的に並べていき、新しいケースが発生した時点でそのツリーに書き足していく、ようなやり方をとっています。

JOBエラー対応：
 
 - Job a
   - Code 11
   - Code 12
   - Code …
 - Job b
   - X Exception
   - Y Exception
 - Job c
 
 
CS問い合わせ対応：
 - ○○画面が見えない
 - ××画面が見えない

Wikiの目次例。

これは手作業でDevSupport業務対応するためのものなので、自動化やコード改善が行われた時点で不要となる可能性もあります。しかしながら専用のWikiがあることで、

最初にどこを見るべきか、というポインターを共有できる
何か既知の問題で、何が既知の問題でないのか
対応にどの程度の工数がかかるか

などを一見できるような資料としても使います。

おわりに

以上、Web ToCチームでのDevSupport業務について、簡単に紹介しました。 Supportという言葉がつくと何か補佐的だったり開発者の本業でなかったりするように聞こえると思われる方もいらっしゃるかもしれませんが、プロダクトについて改善への関心を持つ、という視点のもと、私はこの業務ができることに大きな学びがあると感じています。チーム構成や扱っている製品の種類などの環境要素もあり、この業務への具体的な取り組み方が日々変わっていくにつれ、新たなる課題とそれに対する新しい知見が出てくるかもしれません。

もう一つ、こちらは宣伝となりますが、来たる2月8日（金）に渋谷TECH PLAY SHIBUYAにて、弊社プロダクトチームのメンバーからの開発事例トーク＆MeetUpのイベントが開催されます。ふるってご参加下さい！

（詳細は以下をご覧ください） https://techplay.jp/event/715007

(注釈)

※1 （初めてHNを共有するとたいていきかれてしまうので、予め）私の名前の切れ目はrとsの間にあります。

※2 Web Developmentチームの中に、BtoBtoC向けサービスのチームと、ToC向けサービスのチームがあるイメージです。

※3 少し職種定義が違うのですが、改善に踏み込む敷居を決めるのに、たとえばGoogleのSREならば、繰り返しの手作業となるような対応は多くとも50%でキャップして残りはシステム的な改善に充てる、といったふうに指標値を決めて決定するようなやり方もあるでしょう。TOCチームでは、パラメーターの選定を含めてまだ最善を模索中です。