「B2B SaaSエンジニアが語るマネジメント論」米元 智氏×郷田 祥史氏×渋谷 亮氏×戸本 裕太郎氏×曽根田 侑也氏×堀 譲治氏

B2Bサービスを作る上で心がけていること(渋谷 亮氏)

登壇資料:B2Bサービスを作る上で心がけていること

井上:ありがとうございました。続いて、株式会社マネーフォワードの渋谷さん、お願い致します。

渋谷:はい、株式会社マネーフォワードの渋谷と言います。宜しくお願い致します。本日は、私自身と株式会社マネーフォワードについて軽くご紹介させて頂いた後に、「開発者としてやって良かった取り組み」「社内の良いなと思った取り組み」をご紹介させて頂ければと思います。

まず、自己紹介です。渋谷と言います。株式会社マネーフォワードでVPoE(Vice President of Engineering)を務めております。インターネット上では、「ryoff」というIDで活動しております。マネーフォワードに入社する前は、ずっと広告のエンジニアをしていました。最初に登壇された米元さんは私の新卒時代の上司でして、今回はその縁でイベントに呼んで頂いた形です。マネーフォワード入社後は、ずっとB2Bの開発をしています。最初は「クラウド請求書」のエンジニアをしておりまして、その後は、「クラウド給与」「クラウドマイナンバー」の立ち上げをして、基盤やデータベース周りをやっていました。最近は、エンジニア組織全体を見るような立場で仕事をさせて頂いています。

今回は、会社紹介のスライドを1枚だけ用意しました。ご覧の通り、様々な事業に取り組んでいます。弊社には4つの事業ドメインがありまして、下記のスライドの一番左側がB2Bサービスです。弊社のサービスで一番有名なのは「家計簿サービス」だと思いますが、こちらはB2Cサービスです。また、金融機関と連携し、B2B2C事業にも取り組んでいます。さらに、新規事業にも積極的に取り組んでいます。様々な領域で事業を展開している会社です。

では、早速、「開発者としてやって良かった取り組み」を紹介させて頂きます。私自身、「B2Bサービスの特徴って何だろう」ということを良く考えるのですが、当たり前ですが、ビジネス向けであるということ/多くの会社の業務フローに取り込まれるということが特徴なのかなと思っています。また、「サービスが止まると仕事が止まる」「バグが出ると仕事が止まる」「仕様が変わると仕事が止まる」という感じで、サービスの安定稼働が特に求められる領域なのかなと考えています。弊社の中でも、「短距離走ではなく、どちらかといえば、マラソンっぽい開発だよね」ということが言われることがあります。「一瞬、120%頑張ることよりも継続的に80%頑張ることが大事だよね」という言い方もできるかと思います。

なので、新卒でモチベーションが非常に高くて、「帰りたくないです」「死ぬほど働きます」みたいな方がたまにいらっしゃるのですが、そのような方に対しては、「まあまあまあ。落ち着いて」「1〜2年後を見据えながら、もう少しゆっくり働いていこうよ」という話をすることがあります。また、個人で最速で立ち上げることが大切なフェーズは確かにあって、それ自体はまったく否定しないのですが、一方で、「チームに知見を残す」「誰かが辞めてもプロダクト開発が止まらない」ことも非常に大事かなと思います。課題としては、「暗黙知」「立ち上がり」「チームビルディング」「可読性」「メンテナンス性」といったところがキーワードになるのかなと考えています。

個人的にも、このあたりはずっと悩んでいて、私自身、失敗と成功を繰り返し続けているのですが、その中で、いくつかの取り組みをご紹介させて頂きたいと思います。

一つ目ですが、「和英辞典」を作成することに良く取り組みます。例えば、下記のスライドの中で言えば、「苗字」の英訳は「family name」「last name」のどちらでも英語としては間違っていないのですが、プロダクトの中にそれらが混在してしまうと、可読性が著しく低下してしまう。要するに、ワーディングを揃えるということですね。あとは、「略さない」ということも凄く重要です。

このような用語集を社内のWiki内に置いて、同じような単語については、「ワーディングを揃えようよ」ということを全員に意識づけています。また、コードを書く時間よりも読む時間のほうが長いことも踏まえ、「可読性を向上させて、属人性を排除していこうよ」という目的で、色々と取り組んでいました。

2つ目ですが、「もくもく会」のようなことをしていました。他部署の方には大変申し訳ないのですが、会議室を半日確保して、エンジニアとデザイナーが集まって、みんなで開発をします。お互いに話をしたりすることは基本的にはないです。ずっと自分で開発しているだけなのですが、「あれ、ここってどうなってる?」という風に、わからないことがあれば、目の前の人がその場で答えてくれるような環境を用意することは、実は重要かと思います。

3つ目ですが、「やる意思決定」よりも「やらない意思決定」を重視しています。これはニュージーランドに移住したプログラマーの方のブログから拝借してきたフレーズなのですが、そのプログラマーの上司は、「長時間仕事をしたところで、仕事が終わるなんてありえない」「問題解決するたびに、次の問題が見つかる」「常に苦渋の決断をしながら、優先順位をつける」「システム開発のような知的労働は、いくら時間をかけたところで終わらない」と主張していまして、様々な気づきを得ることができます。

実際、リリースまで1ヶ月で、ちょうど1ヶ月分のタスク量の状況があった場合、「あ、オンスケでいけるじゃん」という話になりがちなのですが、多くの場合、そうはいきません。「エンバグ」「デグレ」「仕様変更」「仕様漏れ」等が発生し、「10の仕事を終えれば、新たに3の仕事が生まれる」ことが通常です。

このあたりについては、昔、エンジニアブログに書いたことがありまして、興味があれば、見て頂ければと思います。それでは、ここからは「社内の良いなと思った取り組み」をご紹介していければと思います。

1つ目ですが、これも「暗黙知」を減らすことにつながる話なのですが、弊社では、「社内用語集」が数多くあります。具体的には、会社本体の「社内用語集」に加え、「プロダクト用語集」「業界用語集」「新卒今さら聞けない用語集」等があります。また、私が取り組んでいることで言えば、「歴史オリエン」というものがあります。例えば、「聞けば一瞬で分かるけど、聞かない限り、一生、謎が解けない設計や仕様」というのは、多かれ少なかれ、どの会社でも存在すると思います。これについては、古株のメンバーが「懺悔の気持ち」とともに、「これからどうしていきたいか」をしっかり伝えていく必要があると思っています。

せっかくなので、この場で一つ事例をご紹介させて頂きます。マネーフォワードは今はRailsで動いていますが、昔、 PHPで動いていた時代があります。どういうことかと言うと、起業当初、PHPベースでSNSを作ろうとしていた時期があり、「PHPっぽいコード」や「PHPっぽいテーブル」が残っています。これに遭遇すると、多くの場合、「なんじゃこれ」となるのですが、弊社のエンジニアであれば、誰もが一度は通る道かと思います。あとは、「歴史オリエン」で言えば、「昔、こういうことがあって、こういう意思決定が正しいと思って実行したけど、今から見ると、正直間違っているよね」というような開発の経緯の説明については、古株のメンバーだからこそできる側面があります。こういった開発の経緯を「すまん」という気持ちを示しながら、誠実に説明していくことが重要だと考えています。

あとは、最近、「良いな」と思っているのが、「パルスサーベイ」と「オンボーディングフィードバック」です。これは、毎日の「体重測定」のようなものです。全社的なサーベイについては、半年に1回の頻度で行っているのですが、パルスサーベイとは、「この会社を知り合いに紹介したいと思うか」等の質問を通じて、より短いスパンで、皆さんの会社への「想い」を集めていく仕組みです。2年前の課題と今の課題では性質がまったく異なりますし、組織の規模・フェーズ・文化が変われば、それに応じて、課題も変わります。「今の課題」に気づくためには、短いスパンで、組織について把握する必要があり、これは非常に良い取り組みだなと思いました。

また、こちらは、クックパッドさんのデータベースドキュメント管理システム「dmemo」です。簡単に言えば、「データベースwiki」のようなものです。新しく入社された方から、「ER図はないんですか?」と言われることがありますが、個人的な意見ではあるのですが、ER図というのは一度作ると、メンテナンスがめちゃくちゃ大変で、心が折れるタイミングが基本的には訪れるものだと考えていまして、弊社では、この「dmemo」を数年前から活用させて頂いています。

最後になりますが、「未来の組織図会議」を3ヶ月に1回の頻度で行っています。組織が大きくなって、「3年後に事業計画上はこうなる」ということが明確になると、その売上をつくり出すプロダクトの大きさやそのプロダクトの大きさを支える組織体制について考えます。もちろん、完璧には把握できないものの、とりあえずマッピングします。マッピングした上で、「30人のエンジニアを統括できるマネージャーって社内から生まれてくるの?」「生まれてこないなら、採用しないといけないけど、採用できるの?」「採用するための社内の給与レンジって市場と整合しているの」といったことをチェックしていきます。

具体的には、社内のエンジニアのグレード等を見ながら、「この人はきっとここまで伸びてくれるはず」という風に、各メンバー毎の期待値をベースに考えながら、次の半期の役割を考えていきます。

私からは以上になります。今回は、「良い取り組み」について紹介させて頂きましたが、失敗についても、数多く経験しています。そのあたりについては、懇親会で色々とお話できればと思います。本日は、有難う御座いました。