MoneyForward Meetupレポート「さぁB2Bサービスを爆速で開発しよう」

広報の青木です。

最近マネーフォワードでは、気軽に遊びに来て頂ける場として、MoneyForward Meetupという交流会を開催しております。今回は、B2Bのサービス開発をテーマに開催しました。その様子をご紹介いたします。

MoneyForward Meetup vol.5(B2Bのサービス開発) – connpass

eyecatch

※第6回目は「Ruby on Rails」をテーマに開催予定です。お申し込みはこちらより受付中です。

まずは、当社のビジネス向けサービス『MFクラウドシリーズ』を統括している山田よりご挨拶と乾杯をさせていただきました。山田からもご案内いたしましたが、会を進めるごとに面白さも増しているMoneyForward meetupは今回で第5回目を迎えました。

1

さぁ2ヶ月でB2Bサービスをリリースしてみよう

最初の発表は、『MFクラウド給与』 のプロダクトオーナー渋谷より。

1

これまで『MFクラウド給与』『MFクラウドマイナンバー』をリリースしてきた渋谷からは、『MFクラウド給与』の開発体制についてお話させていただきました。

早い開発速度とメンテナンス性の高さの両立を意識している渋谷は、それらの達成のために実際に”やってきてよかった5つのこと”についてご紹介しました。

1つめは、リリース前確認シートの作成。リリース直前に焦ることがないよう、確認事項を事前にチームメンバーで洗い出し、リスト化しています。リスト化しコードの規約に落としていくことで、Pull Requestが届いた際などにもレビュー時の観点が明確になり、迅速に対応することが出来ています。

2つめは、和英辞書の作成。たとえ正しい英語でも、プロジェクト内で使用する単語を決めることで可読性を高めたり、sub_info などの抽象的な表現を使わないことを意識しています。結果的にレビューコストを削減し、可読性を高めることで、開発スピードの向上にも繋がっています。

3つめは、「もくもく会」の実施。はてなキーワードにも登録されている「もくもく会」ですが、当社での「もくもく会」は、会議室に集まって数時間作業をし、開発をしながら相談、時に議論、共有などを行う時間のことをさしています。『MFクラウド給与』の開発チームではこれを定期的に実施しており、数時間同じ部屋にいることによって悩み相談や情報共有ができ、ひいては会議を減らすことができ、効率化に繋がっています。

4つめはコード規約。確認シート、辞書作成、もくもく会などによって、議論が深まり、設計の認識が一致してきたら、それを規約に落とします。規約の作成は、ドキュメントがほしいというよりは、レビュー時の感情対立を回避するのが目的です。例えば、メソッドやクラス設計など、個人個人で「僕ならこう書かない」というような内容は感情論になりがちで、レビューの指摘などは難しいです。しかし、記述や設計は個人に任せきりになると、チーム内での可読性が下がってしまいます。コード規約を作成しておくことによって、そういった指摘をしやすくしたいと思っています。そのためには、チーム全員で規約を作り上げていくプロセスと納得感を大事にしてます。

5つめは、やらない意思決定を大切にし、やることリストではなく、やることの優先度リストを作ること。システム開発に時間をかけても終わりがくるわけではないので、常に優先順位を意識しています。いつでもやらない意思決定ができる体制をつくっておくことが重要。また、やることだけを意識しすぎると、デスマ(デスマ―チ)に陥りがちです。デスマの怖さはデスマ自体よりも、その際に生み出される負債であり、数年後の開発に影響します。ベンチャーでがむしゃらに一所懸命コードを書くことは大事ですが、きちんと設計し、負債を残さない開発体制を実現する体制が大切だということでした。

これら5つの取組みを大切にしつつ、冒頭でお話した「早い開発速度」と「安定稼働」を意識していくという言葉で締めくくりました。

シン・請求書

つぎは、『MFクラウド請求書』 プロダクトオーナー泉谷よりお話させていただきました。

1

SIerでのエンジニア経験がある泉谷は、2年前にマネーフォワードにジョインし、『MFクラウド会計』の開発を経て、現在は『MFクラウド請求書』のプロダクトオーナーを務めています。『MFクラウド請求書』のサービスと開発体制について紹介いたしました。

本題は、『MFクラウド請求書』の開発体制は非常に少数精鋭であり、開発現場はとてもthin(薄い、以下「thin体制」)であり、全員が主役になれるというお話をさせていただきました。

thin体制の場合、全員が主役となって開発を担うことができます。関係者であればだれでも新機能や改善案の提案が可能であり、個人の意思をサービス開発に反映できます。例えば、エンジニアではなく、デザイナーがPull Requestをあげることもあり、立場やポジションに関係なく、メンバーがプロダクトについて真剣に考え、アクションを起こしています。

また、爆速で意思決定ができることもthin体制のメリットです。メンバーが少ない場合、チームが限りなくフラットになり、ユーザーを第一に考えることができます。何かあればその都度集まって相談をすることができるため、定期的なMTGを設ける必要がほどんどありません。
実際、新機能の開発は、早ければ1週間、遅くとも4週間程度、バグ修正・改善であればほんの1時間ほどで完結しています。

また、様々なツールがthin体制を支えています。非エンジニアとのコミュニケーションではChatWorkを利用し、システム連携においてはSlackを、非エンジニアとのタスク管理はBacklog、エンジニア同士はGitHubを使うなど、使う人が使いやすいツールを使うことで扱うコストを下げています。

しかしながら、ありがたいことにユーザーは増えると、要望が増え、負債も増えていきます。そこで、全力でプロダクトを開発したい人、既存の常識を覆したい人を、挑戦者として募集していますという言葉で締めくくりました。

君の名は。~入社半年の今~

つぎは、『MFクラウド経費』の開発を担当する伊藤よりお話させていただきました。

1

まずは『MFクラウド会計』と『MFクラウド経費』のCMでサービスをご紹介。CMを見たことがあるという方が会場に8割くらいいらっしゃいました。非常にありがたいです。

伊藤は、この4月に新卒でマネーフォワードに入社し、『MFクラウド会計』の開発を経て、現在は『MFクラウド経費』の開発を担当しています。伊藤からはチームの開発体制に関してご紹介させていただきました。

『MFクラウド会計』に関しては、最も開発メンバーが多く会計に強いエンジニア集団であり、メインの取引先である会計事務所からのフィードバックなどもエンジニアが対応することもあるという事例をお話いたしました。また、「丁寧こそ最速」というプロダクトオーナー谷口からの言葉を常に念頭に置き、仕事に取り組んでいるとのこと。

『MFクラウド経費』に関しては、中小企業がメインの取引先であること、チームでは振り返りである夕会ではCSも交えた議論が交わされていること、時おり伊藤自身も商談に同行していることなどをご紹介いたしました。次のパネルディスカッションにも参加したプロダクトオーナー黒田からの「痛い目を見ろ」という言葉が印象に残っているとのことで、新卒であっても逆境や失敗を恐れずにチャレンジングにコミットしています。

当社のものづくりの体制としては、どのプロダクトも少数精鋭、ユーザーの手にふれるところはエンジン化し、可能な限り最速で最高のユーザー体験を届けられるよう随時改善を重ねています。ものづくりの文化においては、CSや営業と一緒にサービス開発、試食会を通してレビューを行っています。

B2Bサービスを担当することになった時「B2Cサービスと比較すると、ユーザー視点という観点が少ないかも?」と思っていた伊藤ですが、入社して半年経った今では、CSや営業の先にいるユーザーの声を反映させながらサービス開発を進めるB2Bサービスは、非常にやりがいがある、という言葉で締めくくりました。

パネルディスカッション

1

後半戦はイベントのページで事前アンケートで頂いた質問や、イベント当日に頂いた質問に応える形のパネルディスカッションを行いました。
ここからは『MFクラウド経費』のプロダクトオーナーである黒田も参加させていただきました。黒田は、マネーフォワードが10人程度の規模であった時代からジョインしているエンジニアで、現在は『MFクラウド経費』のプロダクトオーナーを務めています。

登壇者
* 渋谷 亮 :『MFクラウド給与』担当 (プロダクトオーナー兼エンジニア)
* 泉谷 圭祐:『MFクラウド請求書』担当 (プロダクトオーナー兼エンジニア)
* 黒田 直樹:『MFクラウド経費』担当 (プロダクトオーナー兼エンジニア)
* 伊藤 大介:『MFクラウド経費』担当 (エンジニア)

モデレーター
* 山田 一也 :『MFクラウドシリーズ』統括


B2Bだから意識している点とは?

  • 渋谷:B2Bだから、ということはあまりないが、敢えて挙げるとすれば、安定性はもちろんのこと、僕がいなくてもチームが稼働する状態をつくるというのは意識にしています。また、お客様はサービスに価値を感じてくださっており、会社や組織の内部事情は関係ありません。ですので、チームメンバーには開発に集中してもらえるような環境づくりも意識しています。

給与計算ソフトってとっつきにくくないですか?エンジニアって給与計算、しないですよね(笑)

  • 渋谷:B2Bの場合、コードはあってるけど仕様が違う、テストを書くにも場合分けが100通り以上あるなど辛い時もあります。給与の場合、年齢とか扶養家族などの多様な項目が色々あります。テストでは数百人の従業員データを数年分まわし続けており、例外パターンを見極めたり、そういったことで回避したりしています。

プロダクトオーナーである皆さんがお客様の所に行ったりもしてますが、その辺りはどうですか?

  • 泉谷:僕の場合はお客様先に行くことも多いのですが、そこが良い部分だと感じています。例えば前職のSIerの場合、お客様として接するのは担当の方で、その先にいるユーザーの声を直接聞くことはできないことが多いと思います。現状、取引先や協業先のお客様の意見を意見をダイレクトに聞いてサービス開発に活かせているので、今の環境は非常に良いと思っています。

エンジニアだけど企画が好き、とかどっちの方が好き、とかあります?

  • 泉谷:技術力を高めたいというのはもちろんありますが、開発のみをやっている時は「こういった機能や新しいサービスがあればいいのに」と思うことが多く企画したくなります。しかし実際開発を始めるとうまくいかなくて、、うーん…エンジニアリングも好きですが、考えるほうが好きかもしれませんね(笑)

考えるという観点だと、黒田さんはどうですか?『MFクラウド経費』の場合、黒田さんがほぼひとりで企画されてましたよね。

  • 黒田:当社の場合、マネーフォワードだから提供できるユーザー体験がありますよね。お金に関する課題を解決するサービスを提供し続けたいが、とは言え、経費精算などを億劫に感じてるユーザーにはPFMサービスだけでは価値を提供できてないなっていう課題がありました。そこで『MFクラウド経費』という新しいサービスでその課題を解決しにいったというところです。ただし、リリース時に見誤った部分もあったので、そこは真摯にユーザーと向き合い、リリース後すぐではありましたが、UIの改善なども行い、現在進行形で開発、改善し続けています。

業務アプリケーションは色々シビアですよね。痛い目を見ようって言われてる伊藤くんはどう?勉強方法は?

  • 伊藤:勉強方法に関しては、日々コードレビューをしてもらうことが非常に勉強になっています。独学で勉強するのも良いですが、実践でレビューしてもらうのは最も身になりますね。
  • 黒田:「痛い目を見ろ」という言葉の意図ですが、新卒だからチャレンジしてたくさん失敗もすると思います。ただし、痛い目を見た分だけ経験できる印象に残る出来事みたいな部分を自分の糧にしていってほしいと思っています。

コードレビューはマネーフォワードがすごく大事にしていることのひとつですよね?

  • 渋谷:ロジック的に正しいか、だけではなく、誰が読んでもわかるコードがどうか、など大事にしています。自分のチームに関しては、経緯や背景をコード内のコメントに書くこともありますね。
  • 伊藤:される側としては、なるべく指摘されたことだけやるんじゃなくて、必ず疑問点は聞くことは徹底して意識しています。
  • 泉谷:私は自分でRull Requestを出した時点でレビューを受けるより前に悩んだ末にこう書いた、みたいな背景をコメントに書いています。自分の思考のプロセスを先に伝えておくと、良い解決策の早期発見に繋がることもありますよね。
  • 黒田:同じく事前に理由は書いています。ちょっとした細かいバグ修正だったらちょっとコメントをつけるだけのこともありますし、案件の大小で使い分けはしていますね。

APIに関しては?当社がつくったAPIもありますよね。他の業務サービスと連携することもありますが、他のAPIと連携するときどう?

  • 泉谷:APIは基本的にオープンであるべきだと考えています。エンジニアが使いやすいAPIを意識していて、使う人が使いやすいよう、教科書通りのRESTを意識してつくるようにしています。APIの利用状況を見て思ったのは、JSONって意外と難しいのかなぁと。配列とかが入ると構文が分かりづらいみたいです。
  • 渋谷:『MFクラウド給与』だと他の勤怠サービスと連携することもあります。各サービスによりAPI仕様が異なったりもするのですが、給与の場合は共通化をやりきらず、抽象度をあげすぎないように気をつけています。抽象度をあげて共通設計を行なうとエンジニアは満足しがちですが、カスタマイズ性が下がったり個別最適化がしづらくなったりする場合もあります。

会場からもいくつかのご質問をいただきました。

安定的に短いサイクルでリリースし続けるには?

  • 黒田:Pull Requestを投げる毎に、テストが自動でちゃんとまわってくれるような環境をつくることは意識しています。
  • 泉谷:リリースサイクルが多いってことはテストも多くなりますよね。なので、テストの実行時間を短くするということを意識しています。ただ、そうするとテストコードが汚くなることもあるんですが、『MFクラウド請求書』チームでは実行時間を優先し、スピードを重視しています。
  • 伊藤:僕の場合は、テストを書くのでいっぱいいっぱいです(笑)
  • 渋谷:『MFクラウド給与』の場合は、今のタイミングでコストに見合うテストにフォーカスしようとしています。例えばE2Eテストなどは、画面改善が頻繁な時期にはメンテナンス工数が見合わない場合もあるので、非常に大事な部分以外は、ユニットテストのカバレッジにフォーカスしています。

共通化の種類はどれくらいありますか?

  • 渋谷:サービスが増えましたが、ユーザ基盤は共通です。『MFクラウドサービス』がどの程度増えるのか読めなかったのですが、3つ目のサービスである『MFクラウド給与』の誕生に合わせて、【ユーザ基盤】と【事業所基盤】の2つの共通基盤を作成しました。【ユーザ基盤】は、ログインや課金周りなどユーザにかかる基盤。【事業所基盤】は、MFクラウドに共通する処理です。またその後、【アカウントアグリゲーション】【暗号化】の部分はそれぞれ切り分けています。新サービスの立ち上げ時などは、基盤があることによる開発速度向上のメリットは大きいです。一方で、マウントしているRails Engineへの依存度はあがっていくのでそこは改善しなくてはいけないと思っていて、技術顧問の松田さんに相談もしています。

あっと言う間にシェアを抜きさった印象があります。なぜナンバーワンになれたのでしょう?

  • 山田:ユーザーが求めてるものを真摯に求め続けてきたからだと思います。家計簿で自動化できるなら、確定申告も自動化してほしい、というニーズがあったことや、ニーズがあるなら解決しよう、という意思決定からB2Bサービスも始まっています。BもCも両方やるのは不思議かもしれないが、ユーザーニーズがあったので少数精鋭であっても、課題を解決していこうという結果が今だと思っています。
  • 黒田:アカウントアグリゲーションという基盤となるテクノロジーがあったのが大きかったと思います。このフェーズになると、クラウド会計サービスの参入障壁は非常にあがっていますよね。スタートアップにおいては、会計は追ってこれない状況をつくり出せたことも大きいかと思っています。

セキュリティが重要なサービスですが、そのあたりはいかがでしょうか?

  • 渋谷:創業メンバーに大手企業出身が多いため、入社前は堅苦しいかな、とも思っていました。だけど、そういったバックグラウンドがあるが故にセキュリティ基盤やセキュリティに対するマインドのレベルは高く、しめる部分はしめられていると思います。そういったバランスが取れているので非常に良い所だと思います。

最後に

発表、パネルディスカッションのあとは懇親会へとうつり、今回も多くの方にご参加いただきました。当社のエンジニアメンバーや営業メンバーも参加させていただき、各々サービス開発への想いなどに関して意見交換が交わされていました。

1

1

マネーフォワードでは、世の中を変えることができるB2Bサービスを開発したいエンジニアを大募集しています。

今回のmeetupの記事を読んでご興味を持たれた方は是非お話を聞きに来て下さい。

マネーフォワードでは、様々な職種で一緒に働く仲間を募集しています。
ご応募お待ちしています。

【採用サイト】

Pocket