ロコガイド テックブログ

「地域のくらしを、かしこく、たのしく」する、株式会社ロコガイドの社員がいろいろな記事を書いています。

「地域のくらしを、かしこく、たのしく」する、株式会社ロコガイドの社員がいろいろな記事を書いています。

顧客と社内を助ける新チーム立ち上げ話

自己紹介

最近仕事用の椅子で Nychair を買って快適ですエンジニアのiaiaです。

今社内から開発への依頼を引き受けるチームが立ち上がり、そこで活動しているのでその取り組み方について紹介します。

経緯

様々な顧客ニーズに対しての迅速な対応は、顧客満足度を高める重要な要素です。CRE(Customer Reliability Engineering)やカイゼン等のキーワードで、顧客からの信頼を高めるためのチームの重要性が以前から謳われていましたが、ロコガイドでは導入ができていませんでした。しかし、今年に入って顧客信頼性に注力するチームの組成について機運が高まった結果、今に至るまでチームの立ち上げ活動を行っています。

何をやっているか

例えば以下のような開発への依頼に応えています

  • カスタマー様からの機能要望
    • 「クレジットカードに自由記載欄を追加してほしい」
  • カスタマー様の利便性向上
    • 「カスタマー様の誤った退会を防ぐ仕組みの導入をしてほしい」
  • 社内メンバーの業務改善要望
    • 「店舗の住所の緯度経度チェックをもっと簡単にしたい」
  • 技術的な質問・要望
    • 「XXX店のチラシを閲覧したユーザを抽出可能か調べてほしい」
  • 調査依頼
    • 「XXX店のフォロー数が減少傾向なので原因を調査してほしい」
  • バグ修正依頼
    • 「投稿したファイルのファイル名が長いとレイアウトが崩れる」

チーム構成

メインでディレクター 1名、 エンジニア(自分) 1名でやっています。また、これらの取り組みで我々で行ってよいのか判断に困るケースも多々あり、サポートとして幾人かの人にも入ってもらっています。

ミーティング

  • 朝会(毎日15分)
    • 昨日やったこと
    • 今日やること
    • なるべくサクッと喋ってサッと解散してます
  • 夕会(ほぼ毎日30分)
    • 朝会だけだとどうしても浅くなりがちです
    • 今着手しているタスクの細かい進捗共有や、困っていることの相談を行っています
    • 特に話すこと無いよ、という日はスキップ出来るようなフローも作っています
  • ヒアリング(都度30~60分)
    • 依頼の内容が複雑などの場合に行っています
    • 何に困っているのか、どうなっていると良いのか、実際に話を聞きにいきます

依頼方法

専用のSlackチャンネルを作り、Slackワークフローを使って、社内の人から依頼を受け付けられるようにしています。(補足: GitHubのアカウントが社内全員に付与されているわけではないので、直接issueを作ることが出来ないため)

もっと質問内容を細かく厳密にすることもできる(したい)んですが、それによって依頼が難しくなり、そもそも依頼が来ない、という状態になってしまっては本末転倒です。 これくらいの粒度であれば私も読み解きやすく、依頼者もある程度質問しやすいかなと思ってこれに落ち着いています。 記載内容だけで分からない場合は、更に細かくSlackまたはオンラインミーティングでヒアリングしています。

また、このワークフローを実行すると弊社謹製のSlack botに渡されるようになっていて、botからGitHubへissueが起票されます。

オンコール

バグなどで緊急で対応が必要な依頼があると考えています。実際、出社時間前にそのような依頼があり、対応に苦慮したのでオンコールにも対応しました。

これもSlackワークフローによって実行すると、以下のようなメッセージが依頼者に送られます。

ここで、 /okiro_help_engineer を実行するとPagerDutyにリクエストが投げられ、そこから私のスマホで呼び出しが掛かるようになっています。 また、私が対応出来なかった場合には他のエンジニアに順番で呼び出しが掛かるようになっています。

エスカレーション

依頼者が緊急で対応は不要だろうと判断し、通常の依頼として投げる場合もあります。 この手順だと他のエンジニアにその情報が伝わりませんが、私が休みの日や出社時間前などで気づかない場合もあります。 もしこの依頼が緊急対応が必要だった場合に、他のエンジニアになるべく早く周知する必要があります。 (※ 補足: インフラが止まっている、エラー率が非常に高いなどの場合は別で監視体制が十分にあります。 それで捕捉出来ない、人間が見ないと分からないような問題について言及しています)

そのため通常の依頼についても以下のようなエスカレーションフローを取っています。

  • 通常の依頼の場合、issueに必ず escalation ラベルを付与
  • AWS lambdaで10分に1回 JavaScript を実行 挙動は以下
    • escalation ラベルがついたOpenになっているissueを検索
    • そのissueが起票から1時間以上経過している場合に、別のGitHub Repositoryにissueを移動
    • 他のエンジニア(+ディレクター)全員が見ているSlackへそのissueを投稿

このエスカレーションフローの問題は、本当に通常の依頼だった場合に、1時間以内には対応を始めないとエスカレしてしまうことです。 これは私の業務時間内であれば1時間以内にすべて対応着手することでクリアしています。

ただし、現状この仕組みが一度も動いたことがないので、本当に動くかどうか怪しいです。 実際バグっていてエスカレするはずなのに動いてなかったということがありました(本当に通常の依頼だったのでセーフ)。 これは定期的に防災訓練のようなことを行っておくと良いかもしれません。

また、実際には他のエンジニアも我々への依頼をたまに見てくれているようで、自動エスカレの仕組みが必要なほど心配性になる必要はないかもしれません。

気をつけていること

着手について

依頼が来たら即時/即日着手開始し、回答するように心がけています。 これは、上記のエスカレの仕組みによる部分もあるんですが、新しい試みを始めた場合には取り組み方をアピールする必要があると思ってるからです。

このアピールで社内の人に「すぐに対応してくれる！」と期待感を持ってもらい、より依頼をしてもらいやすくしたいと考えています。

ユーザ影響/カスタマー影響

カスタマー様からの要望がカスタマーサポートから依頼される場合がありますが、「カスタマー様には便利だが、ユーザには不便になりうる」というものもあります

このような依頼は我々だけで判断せず、サービス開発のチームと連携し、実装可否を都度判断しています。

依頼内容を深掘りする

ヒアリングをしていると当初の依頼内容からは想像が出来なかった目的が見えてくることがあります。いわゆる「ドリルが欲しいのではなく穴が欲しい」というやつです。

そこから当初の依頼内容とは別で、こういうふうにしたら問題解決になるのでは、などと提案をするよう心がけています。

全部やる

開発メンバー以外からの依頼なのでアプリ、バックエンドどちらで対応が必要なのか分からない依頼もきます。

例えば、調査した結果iOSアプリの対応が必要だということが分かって、それをiOSアプリエンジニアに作業を依頼してしまうと、そちらはすでに別で開発スケジュールがあるので差し込みの依頼になってしまいます。

これでは間に自分が入る意味がないので、依頼が来たものはたとえやったことがない開発でも、すべて自分が全部対応するという心構えでいます。

成果と今後の課題

この活動を始めて約4ヶ月が経過しました。成果として、

  • 業務改善要望の依頼の解消によって、ある部署では業務時間がおよそ1000時間/年間の短縮になった(らしい)
  • サービス開発チームへの差し込み依頼が10件/月程度あったが、これがほぼ0になった
    • 我々を飛び越えての依頼がまだ少し残ってる
  • iOS、Reactなど経験していない技術領域の経験が出来てエンジニアとして成長を感じられる

また、今後の課題として、

  • 蓄積されている改善要望の解消
    • まだ100個くらいある...
  • 依頼解決までのスピードアップ
    • 1人ではスピードに限界が...

に取り組めると良いなぁと思っています。