しげる

イベント情報

まとめ

PMの自分が如何にユーザーの声をエンジニアの共通言語へ変えたか
- ユーザーの声をしっかり聞く→メンバーに細かく伝える→開発に大きく任せる
- MVPは絞りすぎない。ユーザーに本当に届けたい価値ってなんだっけ？って考える
マネーフォワードクラウド確定申告フルリニューアルの裏側
- それぞれのドメインで、開発ルールが違う
  - e-Taxドリブン開発
経費精算のさらなる自動化を推進するマイクロサービス開発
- マイクロサービスは機能レベルで分割する

しげる

PMの自分が如何にユーザーの声をエンジニアの共通言語へ変えたか

=== 途中から参戦 ===

結論と過程は細かく共有する
- 作りたいものを明確にする

チームへの伝え方

ユーザーの行動を整理
ユーザーストーリーマップ
- MVPを絞りすぎない
- ユーザーに本当に届けいたいものってなにか考える

バックログから先は開発チームに任せる

技術選定とかスケジュールとか

まとめ

仮説からお客さんの価値をとにかく探す
- アイデアに固執せず、ひたむきに事実に向き合っていく
- 集めたアイデアを鮮度が落ちないうちに行動やストーリに落とし込み、まだ見ぬお客さんの価値をとにかく探す
なぜ今この価値を提供するべきなのかを、さまざまな手段を通して伝える
- お客さんの価値にチームが向き合い、プロダクトを作れるようなサイクルを作る
- そのためにチームへの対談を尽くそう

しげる

マネーフォワードクラウド確定申告フルリニューアルの裏側

サービスについて

確定申告できるアプリ

目的

ユーザーが不便だと思っていることを解消する
ユーザーが便利だと思える機能を提供する

フルリニューアル

UIの刷新
最低限の入力で最適に自動計算が可能に
スマホで申告情報の入力が可能に
会計簿の情報を確定申告に活用できるように

フルリニューアル前

マネーフォワードクラウド会計/確定申告はレガシーで巨大なアプリケーション
- 全体像を理解するのに時間がかかる
- 巨大なのでCIがとても長い
- 毎年更新されるので、年分による分岐がある

フルリニューアル後

確定申告をマイクロサービス化
- DBも完全に分割
- 必要な情報はAPIで取得する
バックエンドはe-Taxドリブン開発を取り入れた
フロントエンドはNext.jsを採用し、SSRを利用

e-Taxとは

国が用意している電子申告サービス
仕様書に基づいたxmlを作成して、e-Taxソフトに取り組めば電子申告できる

e-Taxドリブン開発

データの形式、構造や入力値の制限を全てe-Taxの仕様書に基づいて設計・実装する
- 帳票を表すmodelの名前はe-Taxの仕様書で定義されているIDにする
- 帳票を表すIDのバージョンを対応する
- e-Taxのxmlタグ名がそのままテーブルのカラム名にする

しげる

経費精算のさらなる自動化を推進するマイクロサービス開発

自己紹介

社内プロダクトのバックエンド開発
社内の横断的な課題解決

チーム紹介

CTO室マイクロサービス推進部
- 技術的負債の解消
- 新規マイクロサービスの開発
- Go/AWS/k8s

プロダクト紹介

クラウド経費
- 自動で領収書データを取得
  → 手入力不要
  → 入力ミスがなくなる

アカウントアグリゲーションの課題

そもそもAPI連携できない
複雑な承認フロー
- サービスの領収書は手入力で明細を作るしかない

そんなところをメール取り込み

メールの本文・添付ファイルを解析して明細を記録する
- UberEats, menuなど
  → 面倒なデータ入力がなくなる
メールから自動でPDF化して、自動で明細入力できる

アーキテクチャな話

概要
- メール解析の責務を分ける
- 既存の仕組みに依存せず開発を進められる
- 技術スタックもチームに委ねられている
- サービス間を疎結合にする
パフォーマンス
- メール分類や解析は非同期処理にする
スケーラビリティ
- 他のサービスに影響を与えないような設計
モデル設計
- サービスにより項目が異なるので、柔軟に設計できるDynamoDBを採用
セキュリティ
- 暗号キーはメールごとに分ける
- 暗号化方式の変更にも対応

開発時の課題

メールの取り扱い
- メールの形式が変わる
- 解析対象の選定
  - シンプルな構成が少ない
  - サービス特定仕様
- メール重複
- データ整合性・再処理

今後

対応サービス・プロダクトの充実
あらゆるメールを対象にする
- 機械学習による解析の活用
メーラーAPIを活用したの動的なデータ収集

しげる

Q&A

認識齟齬をなくして開発に取り組まれているのはすごいなぁと思います。
そんな取り組みをしていても結果が期待と違ったというケースはありますか？
成功したというのはどう判断しているのでしょうか？

開発と期待値がずれないようにする→ズレることはあるが、温度感を合わせていく
機能として改善するなら数値を追うとかゴールを設定しておく
数値をどう活用するかを大切にしている

マイクロサービス化をする際にどういう単位でサービスを分けるか考えるのが結構難しい認識なのですが、どういった単位で分けることを意識されたのでしょうか？例えば機能ごとに分けている感じでしょうか？

機能単位で切り出すことが多い。PDF出力の機能を切り出した。

e-Taxドリブン開発やフロントエンド/バックエンドの技術選定はどのような観点で選定されましたか？

リッチなUIを提供できるかでNextを使った
Rubyエンジニアが多いからRubyを使った

極端なアイデア、例えばどういうものがありました？

AIで紙を無くす。紙を切ったりとか

E-Taxの仕様通りの名称を使用すると、開発時に名称から何の金額かわからなくて辛くなりませんでしたか？

辛いです。コメントを多く書いています。
テーブルのカラムはわからないので、e-Taxの仕様書を読みまくる。

「価値のある仮説」か、そうではないか、最初の提案でどうやって見分けているのですか？

最初の段階ではわからないので、現場に行って相談する。
2,3時間でも聞く。わかないものはわからないので、見分けられるように情報を集める
使いづらいは、わかるけど、使いやすいは個人によるので判断しずらい

e-Taxドリブン開発、他のサービス開発に応用するならどういうところを真似すると良さそうですか？

国の仕様に準拠したサービスを作るときは生かせそう。
年末調整とかも利用できそう。

「特定サービスが他サービスに影響を与えないような設計」がめちゃくちゃ気になる。
どういう設計してスケーラビリティを確保してるんだろ

DockerImageベースで分かれている
分類と解析するところに分かれている。
中で情報を持っているので、止まっているサービスもわかるようになっている。

e-Taxドリブン開発を行う上で、新たに何か課題がわかったことありますか？

特定のIDが肥大化しちゃった

「メール取り込みの本文、添付ファイルの解析」で、何か既存のライブラリやロジックを活用したものありますか？

特殊なことはしていない。
メールの解析 → Go queryを利用して、中のHTMLを解析している。

メールの形式の変更をどう検知してどう変更する体制にしていますか？

メールを解析した後に必須項目があるかをvalidateしている。