みなさんこんにちは。株式会社Belong採用責任者の吉川と申します。

Belongは、「大切な人に誇れる、次なる価値を届けよう。」というミッションを掲げ、中古スマホのエコシステムを構築すべくtoB/toC向けにサービスを展開しています。

今回は、ゴールドマンサックス・Googleでエンジニアとして経験を積んだ後、BelongにCTOとしてジョインした福井さんにインタビューをしました。

現在のBelongの開発組織カルチャーや、今後の展望などじっくり語ってもらいましたので、ぜひご覧ください。

学生時代からの思い・組織づくり・そしてCOO清水との深い縁でBelongへ

--福井さんのご経歴を簡単に教えていただけますでしょうか？

学生時代は情報工学を専攻していたこともありIT業界に興味をもち、新卒でゴールドマンサックスにソフトウェアエンジニアとして入社しました。最初の数年はデリバティブという金融商品のトランザクション管理や規制対応のレポーティングなど、業務システムを担当しました。

その後、部署異動を希望して、社内クラウドシステムの開発に1年ほど携わりました。異動した理由は、金融のドメイン知識×テクノロジーを用いた開発も面白いのですが、このときはミドルウェアやプラットフォームを作るといった、より純粋な技術領域を深堀りしたいと考えたからです。

その後、さらにクラウドに深く関わりたいと考えGoogleの Google Cloud Platform (GCP) 担当のテクニカルソリューションエンジニアチームに転職しました。Googleでは、GCPを利用する企業に対してサービスの障害対応や活用方法の提案を行い、また業務自動化のための社内ツール開発なども行いました。このとき、クラウドプロバイダ側視点でクラウドプラットフォームに関わることで、各プロダクトの仕組みや運用に内側から触れる事ができ、利用のベストプラクティスや問題の起きやすいパターン、サポートとの関わり方なども学べ、とことんクラウドの知見を深めることができました。

そこから、Belong創業者のひとりである清水に声をかけられたこともあり、BelongにCTOとしてジョインしています。

--Googleから、スタートアップであるBelongへの転職にはどのような背景があったのでしょうか？

一つは、主体者としてものづくりに携わりたいという想いからです。Googleでは、思っていた通りクラウドの知見を深めることができましたし、世界トップレベルのエンジニアが集まる環境は刺激的でした。ただ、サポートという立ち位置での価値提供になるため、培った技術力を活かし自分の手でプロダクトを作り上げたいという思いが芽生えてきました。

二つ目は、学生時代から起業や組織の立ち上げに興味を持ってたからです。

Belong創業者のひとりである清水とは長い付き合いで、清水がシリコンバレーに駐在していた時、一緒にゴルフをしながら、起業のアイディアを話したりもしていました。

その後、清水から声がかかり、Google入社から2年過ぎる頃にBelongへの入社を決めました。エンジニア組織を1から作り上げられる経験は貴重だと考え飛び込みました。

世界トップクラスのエンジニアが集うゴールドマンサックスで学んだ多くのこと

--ゴールドマンサックスではどのようなことを学びましたか？

特に、ゴールドマンサックス時代の上司から学んだことは今でも大切にしています。彼は当時ロンドンにいるベテランエンジニアでした。技術力も高く、ピープルマネジメントにも秀でており、非常に尊敬していました。そんな彼が何気なくいった一言が強烈に印象に残っています。

「Do right things, Do things right」

方法論よりもまずは解決すべき問題を正しく見極めること。そうでなければ意味がなく、望ましい効果も得られない。同時に問題を正しい方法で解決せよ

つまり、「正しいことを正しくやる」ということです。それは本当に正しいのか？を問い続け、問題を明確にした上で正しいアプローチを行うことが大切であるという教えです。そのために、当時の上司は徹底的に「automation（自動化）」にこだわっていたのです。これは「同じことを何度も手作業で繰り返さないように。エンジニアリングで解決せよ」ということです。

↑当時ニューヨークで仲間と撮った写真です。

ゴールドマンサックスとGoogleの文化を融合したBelongの組織

--これまでの経験はBelongの組織にどのように活かされていますか？

ゴールドマンサックス、Googleと双方エンジニアチームをグローバルに持っていながら組織の運営方針や雰囲気がかなり違う組織を経験し、得た学びをベースに組織の方針を考えています。具体的には意思決定におけるトップダウン・ボトムアップのバランスに気をつけています。

トップダウンで意思決定がされると動きは早くなる利点がありますが、メンバーはやらされている感が強くなります。逆にボトムアップの場合、自身の意見が取り入れられたりして各メンバーのモチベーションが高まりますが、合意形成に時間がかかります。

前述した「正しいことを正しくやる」は根本にある考え方です。このとき「何が正しいのか」という基準が必要ですが根本のルールづくりはどちらかというとトップダウンになります。

ビジョンを提示し、課題・目的を明確にした上で、必要な考慮すべき要素を共有します。

とはいえ、私がすべて正しい判断ができるわけではないですし、押し付けになってもメンバーに共感してもらうことはできません。

そのため、意思決定においては、必ずフィードバックを得ることを意識しており、そこから得られる「納得感」を大事にしています。

例えば技術選定の際は、複数の選択肢を並べた上でPros/Consを示した上で、他のメンバーからフィードバックを得るようにしています。これは、私がメンバーに対して提案する際も、メンバーからの提案の際も同じです。「なぜこの選択肢を選んだのか」が明確になることで、全員が納得した上で物事を前に進めることができます。

メンバーからも自由に提案できる体制があり、Pros/Consを示しフィードバックをもらうというフローを実施すれば、意見を出してもらうことは大歓迎です。出してもらった意見が有用であれば、取り入れない理由はありません。

また、全ての提案において全体の合意必須にしてしまうと窮屈になりかねないと思っており、開発内容によって棲み分けています。

具体的には、3段階に分類しています。

• Strategic tire
• Experimental
• COSS

「Strategic tire」は、事業に直結するコアな開発を指します。この場合は、コードレビューやPros/Consを必ず実施し安定稼働するように務めます。

「Experimental」は、個々人が自由に開発できる内容です。事業には直結しない開発のため、メンバーそれぞれが興味のある技術や身につけたい技術を試す場として、社内の開発環境を使って自発的に実施しています。

「COSS」は、Company OSS の略で上記2つの中間に位置するものとなります。変更自体が直接サービスの挙動に影響しないライブラリ系や、日常的に社内のみで使われ事業運営に直接関係ないサービスがこれに当たります。、COSS では製作者をメンテナーとしてある程度個人の裁量に任せますが、アウトプットの影響範囲によっては内容をドキュメントに一度落とし込みボトムアップで提案し議論します。

一例として、社内で実施されているPros/Consの例をご紹介させていただきます。

規制で縛りすぎてもエンジニアとしては楽しくないと思っています。とはいえ、自由すぎても物事は決まらず事業スピードが鈍化してしまいます。どうしても、事業目線が強くなりがちですが、エンジニアがいきいきと開発に向き合える体制は守っていきたいと考えています。

--他に社内で行われている取り組みはありますか？

エンジニア同士でコミュニケーションをとる機会は多く設けています。知識をシェアすることでチーム力を高めたいと考えています。知識が特定の人に偏ってしまうと属人性が高くなり、強い組織は作れないと考えています。これも、ゴールドマンサックス時代の上司の教えが活かされています。具体的には、4つ会話の場を設けています。

• アーキテクチャレビュー会（業務直結）
• Eng Speciality Session
• エンジニア全体会
• Tech Talk　(金曜16：30から)

--コミュニケーションの場が多いのですね。具体的な内容を教えてください。

「アーキテクチャレビュー会」は、他の会社様でもやられていることが多いと思いますが、業務直結でプロダクトのレビューを実施する時間です。

「Eng Speciality Session」は、プロダクトが”異なり”、専門領域が”同じ”エンジニアが集まり技術の共有や相談をする時間です。イメージとしては、「プロダクトA」を担当するバックエンドのメンバーと「プロダクトB」を担当するバックエンドのメンバーが集まる感じです。（フロントエンド・SREなども同じく）。知識レベルが偏らないように、視野を広げてインプットをする場として実施しています。

「エンジニア全体会」は、毎週すべてのエンジニアが集まり全社的な連絡やエンジニア用の情報共有を行います。この会では毎週ファシリテーターを順番で担当し、「アイスブレイクを必ずいれる」ことにしています。アイスブレイクは社員それぞれのことをもっと知ることができるようなトピックにしていますが、先週はパンケーキとワッフルどちらが好きかという話題で盛り上がっていました（笑）。ファシリテーターをそれぞれが行う狙いとしては、全員にファシリテーションを経験してもらい、プロジェクトでの機会が少ない人にもビジネスマンとしての基礎力を固めて欲しいという想いがあります。

「Tech Talk」は、メンバーが技術についての議題を用意し自由にプレゼンや漫談をするカジュアルな場です。この会は金曜日の16：30〜17：00で行っていますが、 Google の TGIF を意識し（TGIFの意味は「Thanks God, It's Friday」といって、和訳すると「神様ありがとう、今日は金曜だ！」という意味です。いわゆる「華金」というやつです)、週の終わりにカジュアルな雰囲気でエンジニアみんなで集まり技術の話をする形にしています。

技術好きが多いチームなのでニッチな話題も多く、和やかな雰囲気で楽しんでいますね。

↑社内での一コマです。

「ヒーローはいらない」チームで戦う

--福井さんは、今後どのようなエンジニアチームを作っていきたいですか？

チームで問題解決ができる組織にしていきたいです。それぞれの人が専門分野をもち、各自で補い合ってチームとして問題解決をする。これは、社内のEngineering Wikiにも書いており、メンバーに向けて共有しています。

↓BelongのEngineering Wikiです。

つまりは、大活躍する1人のヒーローがいる組織ではなく、メンバーひとりひとりの強みをつなぎ合わせることで、大きな問題を解決していくような組織を目指しています。

個人的な願望としては、私よりも詳しい分野をもつメンバーが増えてほしいですね。（もちろん自分自身も勉強し続けることが前提ですが）

--チーム力にこだわっているんですね。福井さんはどんなCTOになりたいですか？

私が目指すCTOとは、技術に強いだけとか、素晴らしいキャリアや実績ではなく、組織の生産性を向上させ続けられるような存在です。(勿論、技術も大好きなので、そこはメンバーに負けないようにしたいです。笑)　

Belongにジョインする前から組織作りには興味があり、グローバルで成功している企業の組織運用を自分ならどうするという目で見てきた私だからこそ、できることがあると思っています。

そのために、開発組織を牽引するリーダーとして「ビジョンを提示し目指すべき方向に導いていきたい」と思っています。

最後に

現在、事業拡大に向けてエンジニアチームで積極採用中です。

当社のサービスと技術的な取り組みについてはこちらのブログをご覧ください。（にこスマを取り巻くテクノロジー）

もし興味を持っていただけましたら、ぜひカジュアルにお話しをしましょう。