- エンジニアリングマネージャー
- Webエンジニア
- カスタマーサポート
- 他60件の職種
- 開発
-
ビジネス
- エンジニアリングマネージャー
- プロダクトマネージャー
- プロダクトマネージャー
- サステナビリティ
- 広報
- カルチャー推進・浸透
- 知財戦略立案・推進・発明発掘
- リスクマネジメント統括本部
- AML/CFTコンプライアンス
- AML・金融犯罪対策Ops
- 金融コンプライアンス
- ビジネス採用担当
- 経営企画(予実・IR)
- HRBP
- 法務
- 債権管理/MFK
- 法人営業
- インサイドセールス
- フィールドセールス
- インサイドセールス SDR
- インサイドセールス企画
- オンラインセールス
- SaaS営業、MFBC
- インサイドセールス MFBC
- セールス MFBC
- マーケティングリサーチャー
- マーケター
- データマーケター
- BtoBマーケティングリーダー
- CRMスペシャリスト
- イベントマーケター
- その他
MFクラウド会計・確定申告を担当しているエンジニアの谷口です。
マネーフォワードでは、すべてのサービスがユーザーファーストにて開発されています。
今回のエンジニアブログでは、マネーフォワードのサービスの1つであるMFクラウド会計・確定申告において、ユーザーの声がどのような流れでサービスに反映しているのかを紹介します。
1. ユーザーの声の収集
まず、google spredsheetにユーザーの声を集めます。
営業チームやCSチームがユーザーからの意見や問合せを頂いた際や、開発メンバー(開発メンバー1人1人もユーザーです)が実際に触っていて閃いた時に、ユーザーの声として書き込んでいます。
このユーザのご意見台帳は、相当カオスになります。
大切なこと
敷居の低さ
最終的に開発につなげていくことを考えると、「現状どうなっていて」「期待した状況は何で」「どのように解決してほしい」という情報があると良いのですが、そこまで求めると意見が集まりにくくなります。
そこで、「ここをもっとイイ感じにして欲しい」「なんか遅い」といった具体性に欠けていたり、解が見えない意見でもどんどん記入できる雰囲気が大事です。
そこから先はモノづくりのプロが責任をもってくみ取ります。
一体感
サービスへの意見をいろいろな部署の人が書き込んでいくことで、エンジニアだけでなく会社全体でサービスを作っているんだ!という一体感につながります。
2. ユーザーの声の整理
ユーザーの声を開発チームが
1. やる
2. 将来的にやる
3. やらない
4. 要検討
の4分類に分けていきます。
要望の中で、解決すべき課題とその解決方法が見出せないものは、一旦「4.要検討」に分類されます。
これを検討をして1.2.3のいずれかに分類しなおします。
大切なこと
目的と手段を分離しながら整理していくことが大事です。
例えば「このボタンをもっと大きくしてほしい」というような要望があったとして、それをそのまま開発してもユーザーに満足してもらえるとは限りません。
ユーザーの目的が「一連のアクションを迷わずに完了したい」ということであれば、本当はボタンそのものをなくすことが解決する手段かもしれません。
3. 開発計画への反映
ユーザーの声を整理したら次は解決計画にそれを転記していきます。
開発計画には機能別にやるべきことがまとまっていて、それぞれの優先順位付けがされています。
この記事では、ユーザーの声がサービスに反映されるまでの流れを紹介するものなので省略しますが、開発計画には
「ユーザーからは意見が上がってきていないがマネーフォワードとして開発すべき機能」
が既にたくさん記入されています。
4. 開発
実際に開発に着手する直前の段階になると、trelloというチケット管理ツールに開発計画からチケットが転記されます。
trelloは任意のリストの中にチケットを登録していくことができるようになっていて、MFクラウド会計では以下のようなリストを作成しています。
次やる
各開発者が次に実装に着手するチケットがここに登録されます。着手中
各開発者が現在実装に着手しているチケットがここに移動します。実装済
各開発者が「俺はこれで完成したと思っている、みんなに自慢したい」
と思ったらチケットがここに移動します。試食会済
「試食会」とは、実装済の機能を社内で実際に使ってみて、あーだこーだ言い合いあう場で、とても盛り上がります。(出来上がった機能を自慢したい!という気持ちは、しばしばココで打ち砕かれます)
試食会が終わるとチケットがここに移動します。
試食会参加者は以下の人々です。
■ プロダクトオーナー
■ その機能に実務面で詳しい人
■ その機能にコード面で詳しい人
■ その他試食したい人
機能FIX済
試食会でのフィードバックを反映していることを確認できたらチケットがここに移動します。コードレビュー済
機能が固まったら最終コードレビューをします。
状況に応じてもっと早い段階でプレコードレビューを行うこともあります。品質レビュー済
コードレビューの結果積極的にコードを書き直すので
「機能FIX済」の段階では動いていた機能が動かなくなっていることが稀にあります。
そのため、この段階で最終的に品質を担保するためのレビューを行います。
なお、自動テストはmodelのrspecと、重要な帳票類にはseleniumでend to endテストを書いています。ガイド準備済
小さな機能ではやらないのですが、新機能に関してはMFクラウド会計 使い方のガイドを作成しています。
5. リリース
上記4までの工程が終わると、いよいよ機能が世の中にリリースされます。
ユーザーにお知らせのメールを出して完了です。
マネーフォワードのMFクラウド会計・確定申告開発フロー、如何でしょうか。
このようなステップを経て、ユーザーの声が反映されています。書き出してみるとステップが多いようですが、早い場合は当日中にリリースされることもしばしば。
機会を見て、実装フェーズの開発フローも紹介したいと思います。
最後に
マネーフォワードでは、ユーザーファーストで爆速&高品質開発がしたいエンジニアを大募集しています!
みなさまのご応募お待ちしております!