おてつたびの改善チームの取り組み
初めまして!ぶりぼんこと、橋本龍之介と申します。
株式会社おてつたびというスタートアップに2021年6月に入社し、フルスタックエンジニアとして働いています。主にフロントエンド領域を開拓しており、React や TypeScript が最も得意です。また、最近ではPdM業やユーザーの問い合わせ対応もやっています。
おてつたびの開発チームは2022年7月の会社として第5期目より、グロースチームと改善チームという2つのチームに分かれることになりました。
グロースチームは主に新機能の仮説検証を行うこと目的にしており、改善チームは既存の課題や作り込みができていない機能・画面の改善を進めることを目的にしています。
本記事では、私が主導で進めさせてもらっている、改善チームについてお話しします。
そもそも何をやっているのか、どういう課題に直面しているのか、直面する課題をどうやって乗り越えようとしているのか、といったお話をいたします。
おてつたびの改善チームとは?
改善チームを端的にいうと、目の前のお客様の不便を解決するためにあると言えます。つまり、我々が正しい判断をして正しい実装をしなければ、お客様は苦しみ続け、最終的には離脱してしまいます。
実際にやっていることは、以下の通りです。
お問い合わせなどから上がった課題から、機能追加・修正をすること
ビジネスサイドの各チームと連携して、機能追加すること
内部品質の改善(リファクタリング)
データの提供やその準備
正直、かなりカバーする領域が広いです!笑
おてつたびはこれから会社を伸ばそうとしているベンチャーですので、エンジニアが十分にいるわけではありません。取捨選択をしながらタスクを進めています。
改善チームの進める上で心がけていること
改善チームを進める上で私が心がけていることを集約すると、2点になります。
1つ目は各チームの話を徹底的に聞くこと、2つ目は課題とその背後にある事実を確実に捉えることです。
1つ目に関してですが、各チームとはつまり、エンドユーザーに相対するビジネスサイドのチームです。彼らはお客様から多くの要望を聞き、時にはプロダクトに対するお叱りを受けながら、日々の業務を遂行しています。
お客様からの声を直接聞くことが難しい中で、彼らの声に耳を傾けることは非常に重要だと考えます。なぜなら、お客様の代弁者だからです。
だからこそ、まずは彼らの話を徹底的に聞きましたし、何か対応して欲しいということがあれば、すぐに時間をとって聞くようにしました。
その取り組みが功を奏したのか、特に事業者が何に困っているのかは、セールスチームからの情報である程度理解することができました。
また、おてつたびはBtoCのマッチングプラットフォームでもあるので、登場人物としてユーザーもいます。
実はというほどでもないですが、ユーザーに関してはエンジニア自身がお問い合わせ対応をすることで、一次情報を取りにいける状態になっています。
お問い合わせ対応の取り組みに関しては、こちらの記事でお話ししているので、お時間がある時にご覧いただけると嬉しいです!
とは言うものの、ユーザーのことを一番理解して鋭い発言をしてくれるのは、ユーザーチームです。セールスチームと同様、ユーザーチームに対しても、積極的にかつスピーディーに顔を出して、情報を取りに行くようにしていました。
2つ目の課題とその背後にある事実を確実に捉えることに関してですが、口で言うほど実行するのは簡単ではありません。1つ目の取り組みにより情報を取りにいけても、最終的な判断が今のベストがどうかは別問題です。
そのため、目の前にある事象や結果だけに捉われず、その事象が起きた課題を考え、さらに課題がなぜ起きたのかを捉えるということを常に意識しました。
方法論だけに捉われて、漠然とした良いUI・良いUXを追い求めていると、ユーザーが欲しかったものとは違うものがリリースされる可能性があります。すごく良いデザインを作れなくても、課題を捉えた上でのUI・UXであれば、ユーザーにものすごく刺さります。
課題とその背後にある事実を捉えることができたかどうかは、リリース後の定性・定量データを観測することで、効果検証ができます。
一方で、改善チームが発足してまだ3ヶ月ですので、目に見えるデータがまだまだ積み上がっていません。
この取り組みの成果は、またしばらくしてから別の記事で、お話しできればと思います。
改善チームの現在の課題と乗り越え方
おてつたびのプロダクトは、まだまだ多くの課題があり、開発すべきことが山ほどありますが、1つの大きな課題に直面しています。
それは、改善するためのスピードが上がらないということです。
エンジニア個々人のレベルもそうですが、スピードの上がらない最も大きな要因は、「技術負債」です。どの会社のどのフェーズでも直面する問題だと思います。
ソースコード自体の可読性が悪いため実装に時間がかかったり、ディレクトリ設計がバラバラなため目的のコードに辿り着けなかったり、クラスやコンポーネント間の依存関係や責務が適切に管理されていないためデグレーションが起きたりと、様々な問題を生み出しています。
技術負債という大きな課題に立ち向かうために、内部品質改善のためのプロジェクトを立ち上げました。
基本的なスコープは、既存のUI・UXを保ったままソースコードをリプレイスすること、つまりリファクタリングを行うことです。
ただ、リファクタリングすることは、将来におけるコスト削減につながっても、現在における利益創出とコスト削減にはつながりません。
そのため、最も重要な画面や機能を6点に絞り込んで、リファクタリングと同時にUI・UXを変えてしまおうという決断もしています。
簡単に内部品質改善のためのプロジェクトに関してお伝えしましたので、このプロジェクトがどうなったのかは、またいつかのタイミングでお話ししようと思います。
終わりに
どの会社も人が足りないのは常ですが、おてつたびでも人が足りていません。
内部品質の改善もしたいですが、ビジネスサイドの要望を叶えるための改善施策も行いたいと強く思っています。
本記事をご覧になって少しでも興味を持っていただいた方は、Meetyなどもやっているので、お気軽にご連絡ください!
一緒に働きたいという話だけではなく、取り組み内容に関してもお話しできれば嬉しいです。
この記事が気に入ったらサポートをしてみませんか?