【イベントレポート】ウォンテッドリー×カミナシ×Tebiki＿プロダクト急成長の裏側～ソフトウェアエンジニアのあり方～
こんにちは！Tebiki採用担当の重田です。
今回は2023年1月17日(火)に開催された第4回TebikiTalk、「プロダクト急成長の裏側〜ソフトウェアエンジニアのあり方〜」のイベントレポートを皆さまにお届けします。
本イベントは各社5分のプレゼンののち、トークセッションがメインのイベントです。
本ブログではトークセッションで盛り上がった話題をピックアップし皆さまにお届けいたします✨
登壇者紹介
▼ウォンテッドリー株式会社 大坪 新平
(Engineering Manager )
2018年新卒入社でインフラチームに配属後、推薦基盤開発チームに手を上げ異動。 その後、夢であったエンジニアの生産性を向上させていくDeveloper eXperienceのチームを立ち上げ、現在は Engineering Manager。プライベートでは新卒時代から未踏事業にチャレンジし、2019年に未踏スーパークリエータに認定。
▼株式会社カミナシ 鈴木 健太郎
(ソフトウェアエンジニア)
2008年に株式会社LIFULLに入社。Webアプリケーション/API開発、技術組織長、ネイティブアプリ開発など様々な業務に従事。その後、社内ソリューションアーキテクトとしてAWS移行やコスト最適化、クラウド利用統制（CCoE）などを牽引。 2022年に株式会社カミナシにシニアソフトウェアエンジニアとして入社。プロダクト開発をメインにクラウドを正しく使うための改善・仕組み化を行っている。
▼Tebiki株式会社 二瓶 駿
(Product Enginner)
新卒でSIerに入社。受託開発に従事する予定が、ローンチしたての自社プロダクトの開発に従事することに。フロントエンドチームのリーダとして開発に従事しつつ、機能の企画などにも着手。2022年よりTebiki社へJoin。 現在はProduct Enginnerリーダーとして、「価値あるプロダクトづくり」に取り組んでいる。
▼＜モデレーター＞Tebiki株式会社 渋谷 和暁
(CTO)
2018年にTebiki社を共同創業。技術選定から採用まで、デスクレスワーカーが抱えるすべての課題を解決するプロダクトづくりのために何でもやっています。
ー自社プロダクトの成長を支えているエンジニアが集合し、プロダクト成長期におけるソフトウェアエンジニアのあり方についてトークセッションメインでお届けします！
エンジニアリングの改善活動、誰が何をやる？
ーTebiki社の発表の中で、ソロプロ→ペアプロへの移行についてご紹介がありましたが、移行は大変でしたか？というご質問がきております！二瓶さん、いかがでしょうか？
二瓶：幸い、チームメンバーからの反対意見もなく、移行開始の抵抗はなかったです。ただ、ソロプロの方が開発の総量が多いのでは？という疑問が出てきました。その際に生産性の定義とその価値観をすり合わせていくというか、理論と直感のずれを合わせていくのが難しかったです。解決方法としては、スプリントの振り返りの中で、チームで課題を共有し、会話し、解決するようなアクションを決めていきました。違和感を共有し、話をする中で納得感が生まれる場合や、仕組化で解決するなどを経て、定着に至りました。
ーなるほど。エンジニアリングの改善活動について他のお二人にもお聞きしていきたいと思います。大坪さん、ウォンテッドリーではいかがでしょうか？
大坪：2面あると思っています。組織的な面としては、より良い開発体制を考えるトップダウンの部分。もう一つは技術的な面として、好ましい開発スタイルを提案していくボトムアップの部分です。こちらの取り組み方としては、まずは1つのチームで取り組んでみて、上手くいった場合はそれを評価して広げていこう、という形をとっています。
ー実際に上手くいったことを発信した時、社内ではどれぐらい受け入れてくれてくれましたか?
大坪：2面それぞれ変わってきますが、技術的な面ではエンジニアは素直なので、嫌なものは嫌という場合もあります。その時は、押し付けずに一歩引いて利用が進んでいるかをデータドリブンで解決するのが根幹にある戦略だと思っています。
ーおお〜。実際にその戦略の成功率はどれぐらいですか？
大坪：半々ですね。実際は技術的なことより広告的な効果が大きかったりすることもあるんです。社内基盤も結局は社員というユーザーが使ってくれないと意味がないので、毎週こんな機能がでたよと発信する方がユーザー数が増えて浸透していくといった、戦略的なものより結果論として効果が出る場合がある。それはプロダクト開発と同様実際に試してみないとわからないところもあるので、トップダウンでこれが正解、というよりも上手くいくものが正解という考えも持ちつつ進めています。。
ーカミナシの鈴木さんはどうですか？エンジニアリング的な改善活動としてどのように取り組まれていますか？
鈴木：大坪さんと同様、組織と技術の側面があると思います。組織面はトップダウンが多く、技術の導入や改善はボトムアップが多い。将来に向けて残したい設計などはDesign Docを書いて、その設計の検討経緯を最適解へのエビデンスとして残しています。
「技術選択」未来はどこまで見据えるべきか
ー技術選択は未来を見据えて考えますが、今考えると選択ミスしたな～という失敗談はありますか？
鈴木：具体的な失敗談ではないのですが、例えばオープンソースのライブラリを使用していて、それのメンテナンスがあまりされていない状況に対して我々がどうするべきか、他のライブラリに移行するのか自分たちでメンテナンスするのかというなディスカッションは頻繁にしています。
ーなるほど。Tebikiの二瓶さんは技術選択をされたことはありますか？
二瓶：直近だとVueのバージョン3対応をきっかけに、選定しているフロントエンド技術の見直しをするかたちで取り組みました。
ー今後の意思決定も考えつつ選びましたか？
二瓶：正直、あまり考えられていなかったですね。当時はアップデートを最短で終わらせることがゴールだったこともあり、今後の諸々を見据えることより、ゴールに対して最短距離はどこかを考えていました。あとは、選定後の未来を見据えられるほど深い知識や経験を持っている人が、当時チームにいなかったことも理由の一つですかね...とはいえ、持てる知識の範囲で見極めながら進めていたと思います。
ー大坪さんの発表の中で、今後の組織や意思決定などに影響を与えていく話をしていましたが、それはどこまでのスパンで考えていて、トレンドが変わる中で技術選定はどう考えていますか？
大坪：ケースバイケースのため、一概には言えません。。ケースの分け方は”導入コスト”と”乗り換えコスト”です。1つの技術を導入した時にどれぐらい長期まで影響を及ぼすのか、別のものが正解だと後から分かったときの乗り換えコストは？といった視点です。リファクタリングのコストが大きいか、という言い方でもいいかもしれません。
ーなるほどです。ちなみにその点で失敗談はありますか？
大坪：ありますね(笑)。例えばGraphQLで失敗しています。この導入をしたとき、スキーマが付いてほしい、いろんなコードが自動で生成されてほしい等の思いがあったのですが、その前提にはドメインのモデリングがしっかりしていなくてはならないという点があります。そのドメインのモデリングをしっかりやる課題意識が抜けていたことが失敗です。これがなかったために、何か開発するたびににBFF の実装をいじることになっていて「あれ、分離とは？」となりました。最近コストをかけてドメインがうまくモデリングされる組織的な力学の設計とともに入れ直しました。なので、技術選定も大事ですがそれをどのような運用と力学で使っていくのか、という観点も非常に重要です。
ーそこで言うと、例えばモデリング頑張ろうぜ！となった時に全員がその意識がないと失敗すると考えていて、そのカルチャーやメンタリティはどこで調整されていますか？採用とかでしょうか？
大坪：もちろん採用、評価制度などもありますが、あえて狭い領域の話をすると技術が絡んできます。ある技術を導入するにしても、どのような行動をしたいか、そこにはどんな技術や仕組みが必要なのかを考えることがエンジニアリングだと考えています。先程の例では Protocol Buffers のレビューを厳格にする仕組みと、その定義から GraphQLの Object を生成する仕組みによって、「モデリングをしっかりと行うという力学」を組織に浸透させるというアプローチを取りました。
ーありがとうございます。では続いて鈴木さんに！カミナシはバリューを大事にしていますが、バリューの体現をどう担保していますか？
鈴木：評価制度でバリューの体現を評価できる仕組みはある前提ですが、その他の担保で言うと、今はまだ会社の規模が小さいので全社員が集まるオフサイトでのワークショップなどで担保しています。エンジニア組織でいうと、ちょうど来月ぐらいからエンジニア組織だけのオフサイトがスタートするので、その中でビジョンやバリューを浸透させていく予定です。
ーなるほど。では、最後にTebikiはどうやってバリューを浸透させ、体現していますか？
二瓶：Tebikiも、まだまだ規模が小さい会社です。その中でもカルチャーを浸透させる機会として、エンジニアの中では、バリューに基づいた開発ルールを取り入れることで自然とバリューと行動が伴うようにしています。あとはプロダクトの仕様について関わる場合「ユーザーの行動がすべて」という弊社バリューに基づいて会話を進めています。
ドメインモデルの認識を合わせるためには
ー ドメインモデルの認識を合わせるためには。ちなみにカミナシさんはドメイン設計している？
鈴木：完全にDDDに沿った設計になっているとは言い切れないですね。
ー今後考えていく動きはありますか？
鈴木：そうですね、技術レベルアップを目的とした輪読会などのイベントや施策がエンジニアの横のつながりやボトムアップで生まれてきています。その一環で、DDDについてのスキルアップを通じ、それらをアプリケーションの設計に生かしていく動きはあると思います。
ーなるほど、二瓶さんはドメインモデルは考えますか？
二瓶：現在開発中の新機能においては、ドメインエキスパートとドメインモデル図を作りながら開発を進めることにチャレンジしています。
ーそこで難しいと感じたり、辛いところはありますか？
二瓶：辛いわけではありませんが、やっていく中で非同期的コミュニケーションで進めていくのは辛いだろうな、ということはわかりました。エンジニアがモデルを作ってみて、ドメインエキスパートにレビューを出す、みたいな形ではなく、ミーティングという形で進めるのが大事だと実感しています。とはいえ、皆の時間を無限に使ってしまうので、いい感じの所で個人作業との折り合いをつけるのも大事ですね。
ーそうですよね。そこで言うと、ウォンテッドリーのシステムは大きいのでこの辺りの課題はもっと難しいと思います。認識合わせのために工夫していることはありますか？
大坪：仰る通り難しく、倒しづらい課題だと感じています。一つはコメントを書くことを意識していて、この(DBの)カラムが何の意味があるかわからないこと必ずコメントを書いたり、プロダクトの機能改善をする時にこれってなんだっけ、となった場合はすぐに集まって共通認識を持つシンクアップを丁寧にやる。もちろんたまにわからないのにコメントが残っていない時があるので、そこが課題でもあります。
ーなるほど。コメントに残す重要性がとても伝わりました！カミナシさんはコメント書いておけばよかったと思うことはありますか？
鈴木：ありますね。ただ、コメントが書いてあるものの意図が分からないことがあるので、その時は直接人に聞いています。こうしたケースもあってカイゼンが進んでおり、今はコードを見ただけで意図がわかる実装を心掛けています。
ーちなみにコメントはプルリクエスト(プルリク)とコード上どちらに書いていますか？
鈴木：カミナシの場合、アプリケーション寄りの場所にコメントが書かれていることが多い気がしますね。
ーそうなんですね！そしたらプルリクはあまり追わないですか？
鈴木：そこで言うとケースバイケースですね(笑)。挙がった課題に応じてプルリクかソースコードかを見ています。
ーなるほど！システム規模が大きい分ウォンテッドリーはプルリクが多そうです。
大坪：そうですね、確かに量は多いです。ただ掘り起こすときにコミットから追いやすく元のissueも見つかります。創業期は例外でちょっと厳しいですが、基本的にはwhy・whatは紐づいていることが多いので追うことが出来ます。
ー全体に対してどれぐらいDesign Doc書かれていますか？
大坪：明確にDesign Docとして書かれているのは全体の60％ぐらいです。ただ、課題が明確に書かれているものも含めれば9割ぐらいあると思います。初期からあるモノリスのような一番理解が難しいものにこそ書かれていない、というような問題はありますが(笑)。
ーおお！！ちなみにカミナシさんはいかがですか？
鈴木：Design Docをきちんと始めたのは昨年ぐらいからですね。現状のシステムにおいて意思のない設計が見受けられる部分があり、今後作っていくものに関しては「将来にそういった設計に対する不透明さを残してはいけない」という課題感があり、動き始めた段階です。当時はCTOの原トリが発案し、全体に広まりました。
ーなるほど、わりとトップダウンで決まったんですね！ちなみにTebikiでは？
二瓶：要所要所や、個人での活動の中では書かれることがありますが、組織全体で「Design Docを書こう！」という活動はできていないのが正直なところです。ペアプロ、モブプロによって認識合わせに対する課題がある程度解消されているから、というのもあるかと思います。とはいえ、組織のスケールに備えて今後に備えて作っていきたいです。
最後に
最後までご覧いただきありがとうございました！
少しでもエンジニアという仕事に興味を持っていただけたら嬉しいです。
ウォンテッドリー株式会社、株式会社カミナシ、Tebiki株式会社は一緒に働く仲間を募集しています！
ぜひ、採用ページよりご応募お待ちしております。
ウォンテッドリー株式会社 | 募集 https://wantedlyinc.com/ja/careers/jobs
採用情報 | 株式会社カミナシ https://careers.kaminashi.jp/
Tebiki, Inc. | Tebiki株式会社 | 採用情報