共通コードベースで技術のサイロ化を防ぐ。ex-Googleの創業メンバーによって醸成された開発組織の独自性とカルチャー - Tech Lead Senior Architect 岩見 / Software Engineering Manager 早坂

フライウィールでは、「データは人々が持つ価値を最大化する新しいエネルギー」であると考え、さまざまなソリューションを提供し、お客様の価値の最大化に貢献しています。フライウィールの高い技術力を支えるエンジニアが、日頃どういった考え方、姿勢で業務を遂行しているか、カルチャーがどのように浸透しているか、データソリューション部の早坂智行（写真・右）と岩見宏明（写真・左）に、話を聞きました。

信頼のおける仲間とともに、「データ」で人の持つ価値を最大化する

—フライウィールに入社したきっかけや決め手

早坂：私のキャリアの1社目は株式会社ACCESSという会社で、電子書籍のプラットフォームを作っていました。そこから転職して、2社目に入社したのがGoogleです。GoogleではGoogle Playのカスタマーサポート部分のシステムや、Google MapsのiOSアプリを作っていました。

Googleで5年ほど勤めましたが、30歳を過ぎた頃、「次のチャレンジをするなら今だ」と感じるようになり、転職を意識し始めました。当時、何か新しいことをしたいと思っていたときに、Googleで同僚や上司だった人たちが「おもしろそうなことをやるぞ」と聞いて興味を持ったのが、フライウィールでした。

Googleはすでにグローバル展開しており、人数も多い環境でしたが、フライウィールなら日本国内にフォーカスして少人数でより責任のある環境で仕事ができる。かつ、信頼できる仲間とともに働けるということで、2018年7月に、創業間もないフライウィールに入社しました。

岩見：私も前職はGoogleでした。新卒で入社して以来7年ほど、Google PlayやGoogle Mapsなど、何年かごと定期的に異なるプロジェクトに参画。サーバーや、データを処理するためのパイプラインを書いたり、WebのフロントエンドやAndroidアプリに携わってきました。実は当時、早坂さんや現フライウィールCTOの波村さんとは同じチーム、同じく現社長の横山さんとは隣のチームだったこともあったんです。

Googleでは技術的にもいろんなことをして楽しかったんですが、7年経過した頃に、「やりたいことはそれなりにできたな」という実感があって、新しい環境にチャレンジしたくなりました。

転職ではなく、Google社内で自分の置かれた環境を変えることも視野に入れていたんですが、早坂さんや横山さんのように気心や文化が知れた人たちと一緒に仕事ができる点にメリットを感じて、フライウィールへの入社を決めました。いち企業のスタートアップのフェーズから関われるのも良いチャンスだと思いましたし、大量のデータを処理するノウハウを持つこの会社で、インフラ的な部分に携わりたいという技術的な要素も決め手になりましたね。

プロジェクト間でのエンジニアの流動性を高めるため技術セットを統一

—所属する開発部門について

岩見：フライウィールの開発組織は2つあって、1つはプロダクトを作っているチーム。もう1つが、それぞれのお客様のニーズに沿ったソリューションを提供する、データソリューション部。私と早坂さんは後者のチームに所属しています。

早坂：データソリューション部が特に注力しているのは、お客様が持つさまざまなデータをどう活用するか、また、それを使えるように準備をするお手伝いです。例えば、お客様の環境でデータを整備して、データプラットフォームを作ったり、どんなデータで何ができるかのご提案をしたりといったことですね。お客様からいただくデータにあわせて弊社のプロダクトを導入したり、カスタマイズしたソリューションをご提供したりします。

岩見：そうですね。お客様の話を聞いて、基盤を構築してデータ活用の土台を用意し、分析をしたり、予測をしたりしています。

それぞれのお客様ごとにプロジェクトはわかれていますが、全体に共通するようなプロジェクトの進め方や技術的な困りごとなどは、チーム内で適宜情報交換をしながら業務に取り組んでいます。

—開発を進めるチーム構成やプロセスについて

岩見：私たちが所属するデータソリューション部は、エンジニアリングチームとデータサイエンスチーム、それから営業などビジネス寄りのチームが統合してできています。

私自身は現在、技術サポートとしてプリセールスに入ることが多く、契約に至る前の段階でお客様のお困りごとを詳しく聞いて、それに対してどういうアプローチをして解決に導くか、提案をしています。

そうした提案をして契約に至ったら、プロジェクトの体制を組んでいきます。データサイエンティストが必要なのか、ソフトウェアエンジニアが必要なのか。ソフトウェアエンジニアの中でもデータ処理に長けたメンバーが必要か。スキルセットや会社の状況などと照らし合わせながら、メンバーをアサインしてチームを発足します。

早坂：実際のチームとしては、PMとテックリードを含むエンジニア数人という形です。開発はいわゆるスクラムを組んで、2週間でスプリントを切って進めていくパターンが多いですね。どんどんコードを書いて、お互いにレビューをし合って開発に取り組んでいます。

岩見：ただ、お客様によってはいわゆるウォーターフォール的な開発手順を求められる場合もあります。フライウィールとしてはプロジェクトを成功に導くために、お客様がお持ちのデータを実際に見て、試して、フィードバックをして、次にどういうステップを踏むべきか、アダプティブに考えていく必要があると思っていますが、業界が違えばプロジェクトの考え方が異なる場合もあるので、そうした場合はできるだけ折り合いをつけるようにはしています。

プロジェクトによって毛色は異なりますが、エンジニア同士お互いにフィードバックしやすい環境を保ち、お客様の課題解決に対してより良いアプローチが取れるようにしたいという意識があるので、できるだけ開発スタイルは社内で統一したい思いがあります。

その一環として、フライウィールでは使用する技術セットはできるだけ統一するようにしています。例えば社内で使っている言語は、Python、Kotlin、TypeScriptなど3つほどに絞っていますし、一定のパターンで使うライブラリやフレームワークは全員がほぼ同じものを使うようにしています。これはフライウィールの開発組織の独自性ではないかと思いますね。

—開発組織の独自性

岩見：例えば、基本的な開発スタイルとして、共通のコードベースを使っているところは他社と違うところだと思っています。当社の特徴として、モノレポ（monorepo）という共通のところでコードを書いて、ソフトウェアを作っているので、いろんなプロダクトや技術スタックの使い方がそこにすべて集約されている。お互いのコードが見えていて、かつ、再利用しやすい状態を維持しているんです。後に似たような開発をするときに、あらかじめプロダクトとして作られたものでなくても転用しやすいんですよね。

これは、メンバーの流動性を高く保つためです。プロジェクトのフェーズによっては人数を増減する必要があります。新たな知見が必要だから別のロールの人をアサインしたり、運用フェーズに入ったら人を減らしたりといった場合ですね。他にも、流動性を高めることで、組織として凝り固まったり、人的なリスクの発生を回避したりすることにつながります。こうした流動性を高めようと思ったら、技術的な知見や開発プロセス、文化がサイロ化しないよう心がける必要があるんです。

ビッグテック出身者が多いからこそ根付いたカルチャー

—フライウィール開発組織のカルチャー

岩見：お互いアドホックに相談しやすい雰囲気がありますね。例えば、どういうアプローチでプロジェクトに取り組んでいくか、どんなやり方がお客様には有効なのかを考えるフェーズでは、必要に応じてお互いに相談することがよくあります。困難なプロジェクトほどお互いによく相談し合うので、プロジェクトを超えて皆に内容が周知されている状態になります。

早坂：そうですね。エンジニア同士、フラットな関係でお互い積極的に発言しますね。最近入社した新卒の社員からも、どんどん素晴らしいツッコミをいただいています。役職関係なく、言いたいことを言い合って議論が生まれ、その中から一番よい意見を選んで方針を決めていこうとする意識があります。

—開発組織内でのバリュー浸透のための取り組み

早坂：フライウィールには、全部で5つのバリューがあります。「Believe in Data」「One for All , All for One Goal」、「Respect Open Communications and Feedback」「Focus on impact and decide what you do not do」「Move fast, and break things」です。

例えばその中の「Respect Open Communications and Feedback」は、まさにフラットな組織であることを表すものだと思っています。お互いの気持ちを汲み取りながら、オープンにコミュニケーションをしてフィードバックをし、どうしたらより良くしていけるかと正直に話し合おうとする姿勢ですね。「One for All , All for One Goal」にしても、個々人が皆のために、お互いを思いやって取り組む組織の表れです。

フライウィールでは、こうしたバリューを体現している人に対して感謝を贈り合う、「Shoutout（賞賛コメント）」という仕組みを設けています。例えば、「One for All , All for One Goal」に当たる取り組みをしてくれた人に、「あなたがいなければこの会議を乗り切れませんでした」「レビューしてくださったおかげで業務に携わる人たちの時間が短縮できました」といったように、Slackや口頭でお互いに具体的に褒め合います。

それを見た別のメンバーが「あの取り組みは素晴らしいから自分もできるようになろう」とあらためて思うことができれば、全体の底上げになります。こうした仕組みを取り入れて、バリューをさらに強化していきたいと思っています。

岩見：バリューを体現した取り組みでいうと、月に1度おこなわれる「TGIF（Thank Got It’s Friday）」もそうですよね。創業当初から取り組んでいるカルチャーイベントの1つで、月に1度、金曜日の夕方にTGIFを開いてメンバー同士が交流しています。新入社員の自己紹介や、先ほどのShoutoutを贈られた取り組みの事例の共有、コミュニケーションを活性化するためのゲームといった企画をボランタリーのチームが企画しています。

他にも、エンジニアのナレッジ共有や情報発信の場として取り組んでいるのが、週1度開催されるTech Talkです。持ち回りで担当者を決めて、水曜日の昼時に30分ほど、カジュアルな場でナレッジの発表などをしています。Tech Talkで共有される内容は、業務に関係のある話だけでなく、最近知った技術に関するトピックの紹介なども含まれます。

早坂： 1on1もカルチャーの1つですね。

岩見：そうですね。Weekly 1on1といって、上司やマネージャーとメンバーが週に1回1on1ミーティングをする制度があるんですが、それとは別に皆が好きなタイミングで、好きな頻度で1on1でコミュニケーションする文化があります。

相手も、上司やマネージャー、エンジニア同士でなくても、別部署の人やプロダクトマネージャーなど組織をまたいでもいい。話したい人と自由に話すことができます。1on1の内容も、最近どんなことをしているのか、そのチームの困りごとは何かなど、さまざまですね。

私も実際にビジネス部署の人とアドホックに1on1を設定して、最近よく聞くお客様の課題や、どうすればより良い価値を提供できるかなど、いろんなテーマでざっくりとお互いにコミュニケーションを取り合うなどしています。

早坂：こうしたカルチャーが根づいた背景として、当社はGoogle出身者が多いことが挙げられると思います。もともとGoogleにあった文化を、当社に合うようにカスタマイズして輸入して根づいていったんだと思いますね。

フライウィールは非常にエンジニアリング・スピリッツの強い会社です。「単に作って終わり」ではなく、技術的合理性があるか否かに関して常に疑問を抱きながら、一番良い方法は何か作りながら考え、探求するような組織です。当社ではビッグテックでの開発経験を持つメンバーが多いため、大きなシステムを設計する際には長期的な視点を持って、最も合理的な選択が何かを考慮し、技術的な意思決定を行うよう意識しています。

例えば、業務面でいうと、単にお客様の要求に応じて仕様を実装するのではなく、「お客様のおおもとの課題は何か」をきちんと咀嚼する。技術的に高度な課題がある場合は、そもそもお客様自身も何がしたいのかよくわからないケースがあるんです。そういう状況を相互に認識した上でまずは作ってみてまたその次のステップを考えていく、というアジャイルの考え方を上手に使いながら、お客様自身でも紐解けない課題を一緒に解決していきます。

技術的な観点に目を向けると、私が統括するチームは二十数名なんですが、そのうち片手で足りるほどの人数で大規模なシステムを運営しています。それは、設計の段階でどうすれば少人数で運用・保守できるかを考え抜いているからできることです。その場しのぎの解決を目指すのではなく、問題を継続的に解決するために必要な柔軟性をどこまで持たせるかを考えていますね。一方で、柔軟性だけを追求しても結論が出ないため、そのバランスをどう取るかが重要です。当社のエンジニアは、このような視点や意思決定に長けている人が多いと思います。こうした長期の運用性を考えたうえでの技術的な意思決定とオペレーション設計がある点は、フライウィールならではの性質と言えるでしょう。