まえがき
ビットキーアドベントカレンダー6日目です。
2019年02月01日に株式会社ビットキーに入社しました、
Workspace & Experience Product Circle所属の@kodai_setoが担当します。
新規製品を世の中にローンチした直後の保守体制についてお話します。
目次
- 自己紹介
- はじめに
- dev前衛とは
- なぜこの体制？
- 保守ではない
- メリット
- デメリット
- 気をつけていたこと
- 学び
- おわりに
自己紹介
簡単に自己紹介させてください。
2022年12月現在 6年目のWebエンジニアです。
簡単な経歴では下記の通りです。
~大学まで
英語教員志望
卒業後 ~ 2019年
英語が苦手だったため教員になることを断念し、
新卒でWebエンジニアとして入社。主に製品のプロトタイプであるモック開発を行う。
2019年 2月~
株式会社ビットキーに入社。
Webエンジニアとして、いくつかのプロダクト開発、リリースに携わる。
はじめに
本記事を読むにあたって、ビットキーの製品の特徴について紹介させてください。
テクノロジーの力で、あらゆるものを安全で便利で気持ちよく「つなげる」
というビットキーのミッションを達成するために、SW領域とスマートロックをはじめとするハードウェアデバイスとを組み合わせたサービスを提供しています。
そのため、ビットキーにはSW領域だけでなく、デバイスのFWを実装、保守するチームがあります。
プロダクトのリリース当初、複数領域にまたがるという特徴から、
不具合等が発生した場合にSW領域で発生している問題なのかFW領域で発生している問題なのかを切り分けする必要があり、課題解決が非常に難しくなっている原因の一つでもありました。
dev前衛とは
さて本題です。
何の話やらと思った方多いと思いますが、
「dev前衛」とは、ビットキー独自のワードです。
私が初めて開発に携わったプロダクトがリリースされたばかりで、
まだまだ改善点が多かった時代に採用された、
開発チームがCX ※1 と一緒に顧客先へと出向くという体制のことを弊社において「dev前衛」と呼んでいました。
顧客先で発生した問題、要望を直に収集し、一つのslack チャンネルに対して集約します。
それにより複数のチームが一つのチャンネルでコミュニケーションをとることができ、
極限まで改善スピードを上げようという目論見があります。
※1 「Customer Experience」の略称。
主に顧客体験の改善、向上を目指しているチーム。
ビットキーにおいて、最も顧客との接点が多く、製品の導入も担当。
なぜこの体制？
上述の通り、当時私が携わっていたプロダクトはリリース初期で、
恥ずかしながら不具合や、機能不足による顧客要望が頻発していた時期でした。
具体的には下記の問題がありました。
- 開発黎明期で仕様変更が多く、社内展開するプロセスが固まってなかったため、CX、開発チーム間で機能の認識齟齬が発生
- 顧客、CX、開発チームとコミュニケーションパスが増えることによって、開発チームが顧客要望を誤認、意味のない機能の開発が発生
- CX→開発のエスカレーションフローが整ってなかったためコミュニケーションコストが増大
- SW領域だけでなくFW領域も関係するプロダクトのため、片方のチームだけじゃ解決できない課題が多い。別チームだったためコミュニケーションコストも高い
結果、導入担当であったCXが疲弊。
プロダクトの改善も思うように進まなかったため、
それならいっそ開発も一緒に顧客先へ出向き、実際の課題を現地でみたほうがいいという話になったためでした。
dev前衛という言葉には、まだまだプロダクトはリリースしたばかりだから保守的にならず積極的に改善していこう、という気持ちが込められています。
実際にこの体制によって、プロダクトは劇的に改善されていき、dev前衛という言葉は広くビットキーに浸透していきました。
メリット
改善スピードが早い
- 顧客の要望を直に聞き、開発に取り掛かることができたため改善スピードが早い。
- リリース直後で展開不十分な製品仕様をその場で解説することができる。
- 訪問時、新しく出した機能について直接フィードバックをもらえる。
dev前衛という体制により非常にサイクルが早い開発を行うことができました。
開発チームが直接顧客課題をヒアリングしているので、
顧客ヒアリング → 本質的な課題の分析 → 修正方針の検討 → 修正リリースまでのサイクルが早く、次の日やその週のうちに修正を行うこともできました。
コミュニケーションコストの低下
- 困ったらdev前衛へ連絡しよう、の共通認識でCXから開発へのコミュニケーションコスト低下
- SW、FWが1チームで、異なる領域での情報共有がスムーズ
- ビットキー全てのプロダクト情報がdev前衛に集約
今までであれば、
CX → SWチーム → FWチーム → SWチーム → CX
といった複数回コミュニケーションが発生するケースなどもありましたが、
この体制によって、CXがdev前衛に問い合わせをしたら即集合するようになりました。
結果、CXが誰に問い合わせすればいいか悩む必要もなくなり3チームでコミュニケーションを回す必要も無くなったので、
コミュニケーションコストが非常に低下しました。
また、
顧客先で問題が発生していることを自分達が身をもって体験しており、
かつCXがどのように疲弊しているかも体験していたためか、
CXから問い合わせが上げられてから開発が反応するまでが非常に早くなったと思います。
顧客が製品を利用しているところを見れる
- 本当にお客様が製品を使っていることが実感できる
- お客様が何のためにプロダクトを導入したかがわかる
- 厳しい言葉をいただくこともあるが、期待の言葉をかけられることもある
自分達のプロダクトが、顧客にどのように使われているかをみる機会ってあまりないと思います。
直接みることによって、
実感を持てたのはプロダクト開発していく上で非常にプラスだったと考えています。
デメリット
めっちゃ緊張する
- 名刺の渡し方難しい
- 敬語って難しい
私ごとで大変恐縮ですが、
当時、名刺の渡し方も受け取り方も非常におぼつかなかったため何回も練習しました。
お客様先で一番緊張したのは、名刺渡す時でした。
気をつけていたこと
dev前衛という体制の中で、開発はかなり自由に動き回ることができましたが、
オーバーコミットしてしまわないかというリスクが常にありました。
特に、影響範囲が大きい機能などについては、
修正はできても検証が間に合わない、なんてことも起きかねないため、
迷ったら一度持ち帰る、というのは徹底していたように思います。
また、そこについてはCXが力強く開発をサポートしてくれました。
学び
dev前衛という体制は私にとって多くの学びを与えてくれたと感じています。
特に、
顧客がいろいろな思いをもってプロダクトを使ってくれているということを
直に感じることができたのはとても大きかったし
リリース初期でプロダクトに不具合が多いと、
開発チームだけでなくCXにも大きく負担がかかってしまう
というのを実感値として学べたのは非常に良い経験でした。
もちろん、
顧客先に行って解決する、というのが最適解かどうかはわかりませんが、
開発チームが顧客先に行くことによって、顧客が抱えている問題だけでなく、
他のチームの助けになることもあると知れたのは非常に大きい学びだったかなと思っています。
今後も是非この経験を忘れずに、
ビットキープロダクトの品質をもっともっとよくしていければ良いと思っています。
おわりに
今回は、
他の記事とは毛色が違う話な気もしますが、
私が体験した中で面白かった経験をピックアップして、つらつらと書かせていただきました。
初めて外部に発信するということで、読みづらい文章になってしまったかもしれませんが、
読んでいただきありがとうございました。
7日目の株式会社ビットキー Advent Calendar 2022は、 Workspace & Experience Product Circle所属の@momoko_yshr さんが担当します。