Findy Team+ Lab

NEW

イベントレポート

創業期から考えたい、プロダクト価値をアップデートし続けるための文化投資

創業期から考えたい、プロダクト価値をアップデートし続けるための文化投資

2024年11月15日、ファインディ株式会社が主催するイベント「開発生産性Kaigi スタートアップが目指す、開発と事業成長の接続〜価値創造への挑戦〜」が開催されました。

本記事では、株式会社ナレッジワークでCTOを務める川中 真耶さんと、株式会社ログラスで執行役員CTOを務める伊藤 博志さんによるディスカッション「創業期から考えたい、プロダクト価値をアップデートし続けるための文化投資」の内容をお届けします。

このセッションでは、ファインディ株式会社 SREチームリーダーの下司 宜治がファシリテーターを務め、「なぜ事業視点を持つべきなのか? 事業視点を持てている状態とは?」、「組織拡大期においても事業視点を落とさないための文化醸成とは?」という2つのテーマを中心にお話しいただきました。

■登壇者プロフィール

川中 真耶(@mayahjp)
株式会社ナレッジワーク CTO

東京大学大学院情報理工学系研究科コンピュータ科学専攻修士課程修了。日本IBM東京基礎研究所研究員やGoogleソフトウェアエンジニアなどを経て株式会社ナレッジワークを共同創業。CTO of the year 2022 ファイナリスト。「王様達のヴァイキング」(週刊ビッグコミックスピリッツ)技術監修。

伊藤 博志(@itohiro73)
株式会社ログラス 執行役員CTO

ゴールドマン・サックスのテクノロジー部に新卒入社後、同社の基幹システム開発に従事。その後、VP/Senior Engineerとしてプラットフォーム開発に携わり、同社発のJavaのOSSであるEclipse Collectionsのコミッター兼プロジェクトリードやOpenJDKへのコントリビュートを行うなど、OSS戦略を牽引。スタートアップ2社を経て、READYFORに入社し、執行役員VPoEに就任。同社のエンジニア組織の10名から30名規模への成長、決済基盤の刷新や、技術的負債の返済、新規プロダクト開発を牽引。2022年10月に株式会社ログラスの開発部へエンジニアとして入社。エンジニアリングマネージャー、VPoE、開発本部長/事業執行役員VPoEを経て、2024年11月より執行役員CTOに就任。

■モデレータープロフィール

下司 宜治(@gessy0129)
ファインディ株式会社 SRE チームリーダー

新卒でヤフーに入社。2、3度の転職を経ながらサーバーサイドやSRE領域を担当。アンドパッドでは、VPoEとして採用・組織作り・技術的負債の改善からSRE、CRE、QA領域などプラットフォーム部分を担当。2024年4月にファインディへジョイン。ファインディでは入社後よりSREなどのプラットフォーム領域を担当している。

目次

ナレッジワークとログラス、両社が展開する事業と開発体制

――このセッションでは、「創業期から考えたい、プロダクト価値をアップデートし続けるための文化投資」と題して、お話を伺っていきたいと思います。まずは、お二人の自己紹介からお願いします。

川中:ナレッジワークでCTOをしている川中 真耶です。簡単な経歴としては、ずっとコンピュータ畑で生きてきて、IBMやGoogleなどでソフトウェアエンジニアをしていました。その後、4年半前にナレッジワークという会社を共同創業しました。よろしくお願いします。

伊藤:ログラスでCTOをしている伊藤 博志と申します。私は新卒で外資系金融の会社にエンジニアとして入社し、そこで12年くらい働きました。その後、スタートアップの世界に入っておよそ7年が経ちます。ログラスには2年ほど前に入社し、エンジニアからエンジニアリングマネージャー、VPoE、CTOと駆け抜けてまいりました。本日はよろしくお願いします。

――私はファインディでプロダクト開発のSREをしている下司と申します。よろしくお願いします。では続いて、まずはナレッジワークの川中さんから会社紹介もお願いします。

川中:簡単に説明させていただきますと、ナレッジワークはイネーブルメントによって「できなかったことができるようになる」ことを目指している会社です。今は創業4年半で、主にセールス領域でのセールスイネーブルメントを扱っています。

開発体制についても簡単にお話しすると、いわゆるストリームアラインドチームが、図の上側にある5つのグループで、Knowledge Growth DevやKnowledge Satisfaction Devといったグループが、それぞれプロダクトをつくっています。それに対して、コンプリケイテッドシステムやプラットフォーム、イネーブリングチームなどが下から支える構造になっています。

人数としては全社で120人くらい、そのうちエンジニアが40~50人くらいです。1チームあたりの人数は、図の上側のプロダクトをつくっているチームは5~7人くらい、下側のチームは2~4人くらいで構成されていることが多く、兼務を減らしていく方向で役割を分けています。 knowledgework_loglass_eventreport_2024/12/16_middle_h2-1-1

――続いて、ログラスの伊藤さんからも会社紹介をお願いします。

伊藤:ログラスは、「良い景気を作ろう。」という壮大なミッションを掲げています。いろんな企業が元気よく、事業を良くしていって企業価値を上げ、働いてる人たちの給与が上がって消費が増え、他の会社にも波及していく。そういった世界を目指しています。その第一歩として、まずは経営管理という領域を良くしていくため、クラウド経営管理システム「Loglassシリーズ」を提供しております。

開発体制としては、ナレッジワークさんとざっくり同じで、プロダクト開発に注力するチーム群と、イネーブリング&プラットフォームと呼んでいる基盤寄りのチームが存在しています。人数的にも近く、我々もエンジニアが40人くらいで、プロダクトマネージャーとデザイナーを合わせると50人ちょっと、全社では180人くらいという規模感です。

また、テックバリューとして掲げているのは、「顧客への本質的な価値提供」、「学びと適応」、「技術的卓越性の追求と還元」。これは創業期から大切にしている価値観を言語化してつくったもので、この3つをいかに高い基準でやっていくかということを大事にしています。 knowledgework_loglass_eventreport_2024/12/16_middle_h2-1-2

事業視点を持つことのメリット、持たないことのデメリット

――それでは、本題に入っていければと思います。1つ目のテーマは、「なぜ事業視点を持つべきなのか? 事業視点を持てている状態とは?」です。まず初めに、事業視点を持つメリットからお聞きしたいと思います。

川中:まず事業視点とは何かというところですが、事業がどのように進んでいくかが見えている状態だとしましょう。僕らエンジニアは、単に開発をするだけではなく、やはり意味のあるものをつくることが重要ですよね。その意味のあるものをつくるには、事業がどう構成されているのかを知ることが重要です。なので、事業視点というのは、価値のあるものを開発するために必要であると考えています。

伊藤:事業視点というと、いろいろなレイヤーがあると思っています。例えば、売り上げとそれに対するコストがあって、中長期的に我々がどんな事業計画でどう売り上げをつくっていくのかという数値的な部分。そして、それをプロダクトでどうやって実現していくのかという、価値の部分があると思います。

この両方を持てたらいいとは思いますが、エンジニアにとって数値的な部分は少し遠い。なので、どちらかというと生み出していく価値の部分、そこを解像度高く理解することによって、自分たちが今何をつくるべきかというところに、よりコミットしていけると思っています。

――逆に、事業視点を持たないことによるデメリットというと、どんなものがあると考えられるでしょうか?

伊藤:事業視点を持たないということは、降ってきたものをやるという形になってしまうのではないかと思っていて、それは社内受託のような不幸な構造を生み出します。かつ、事業視点、つまり最終ゴール的なものを見ずに降ってきたものをつくっていると、それが本当に価値につながるのかどうか、自信がないものをつくることになる。結局、それに価値がなかったとなれば、手戻りも大きくなります。

そのうえで、例えばビジネスサイドとプロダクトサイドの確執みたいなものも起こりうると思っていて、やっぱりそういう不幸な世界はない方がいいですよね。

――事業視点を持つことで、ビジネスサイドとプロダクトサイドの確執が起きにくくなるという実感はありますか?

伊藤:そうですね。ビジネスサイドもプロダクトサイドも、同じ目標に対して協働して、同じオーナーシップを持って一緒につくっていれば、どっちがどうだという話にはならないのかなと。同じゴールを実現するために、どう一緒にやっていくのか、それぞれにどう背中を預けてやっていくのかという方向性に向かっていけると考えています。

――川中さんからも、事業視点を持たないことによるデメリットについていかがでしょうか?

川中:普通に考えればメリットの裏返しなのですが、もう少し深く考えて、事業視点を持っている人と持っていない人の差を考えてみましょう。例えば、上位レイヤーの人は事業視点を持っていて、メンバーレイヤーの人は事業視点を持っていないことが比較的多いと思うんですよ。何が違うのかと考えると、動かしていい変数がどこまでなのかを、どれだけ理解しているかに違いがあると思っているんです。

先ほど伊藤さんのお話にもありましたが、所与の条件を与えられて、それをやるだけになってしまうというのは、結構ありがちです。ですが、上位レイヤーの人たちは、例えば「これは後で変えることができるな」とか、「これは営業の人に言っておけば何とかしてくれるから、この条件は変えられるな」とか、そういったことを考えられるんですね。

それはナレッジワークのなかでも感じていて、どこまで動かしていいかどうかがわかると、その結果として良いものがつくれる。つくっているものに対して手綱を握ることができるというか、自分のやりたいようにプロダクトを少し変えていく、といったことができると思っています。そのメリットがなくなってしまうことが、デメリットだと言えると思います。

あとは、運用でカバーというとエンジニアに怒られますが、CSに頑張ってもらって開発工数を落とすとか、あるいは逆に開発することでCSの工数を下げるとか。それってレバーのようなもので、僕らが動かせるはずなのに、動かしてはいけないと思いがちだと思うんです。これも事業視点が見えていないとできないところかなと思っています。

――「ここはCSに頑張ってもらおう」というのは、他の部署やチームとしっかり連携して、同じ目標に向かっていないとできないことですよね。全社で同じ目標に向かうためには、事業視点を持つべきだという話にもつながってきそうな気がします。

川中:そうですね。その通りだと思います。

「事業視点を持っている」とは、どのような状態なのか?

――事業視点を持った方が、圧倒的にメリットが多いということがわかってきました。ただ、「事業視点を持っている状態」とはいったい何なのか、明確に表現するのはなかなか難しいと感じます。お二人は、どういう状態だと思われますか?

川中:ものすごく難しいです。これが答えだというものが上手く見つかっていないなかで話していますが、自分では「未来予測ができること」と考えています。例えば、この1年くらいでこういうことが起こりそうで、僕らはこんなことを展開していこうとしている。だから、ここを変えていこうと、エンジニアリングにも反映していく。そういう状態が事業視点を持っていることだと、今日は定義したいと思います。

社内ではエスパーという単語を使っているんですけど、「これはこうなると思うから、こうした方がいいよ」と言っておくと、まあまあ当たっているというのがあって。エスパー力は人によって、特に上位レイヤーと下位レイヤーでかなり違いがあると思います。上位レイヤーの人はいろいろな情報を仕入れているので、上手く表現できないけれど、こうなるだろうというのがわかっている、という感じですね。

伊藤:ログラスには全社の目標があり、それが事業視点の最上位だと思いますが、そこからブレークダウンしたプロダクト組織としての直近のゴールがあります。我々はOKRを用いているので、そのプロダクトの価値を実現していくためにどうするかを、各チームのOKRにブレークダウンしています。そのなかで一人ひとりが、上位の目標からのつながりをちゃんと理解して、自分の目の前のことに向かっているかどうかが大きいと思っています。

先ほど川中さんがレバーと表現されていましたが、上位概念を理解しているからこそ、目の前の我々のゴールに対してどこまでレバーを引いていいのか、というオーナーシップを持てる。ちゃんと事業につながっているという確信を持ちながら、自信を持ってレバーを引いたりブレーキを踏んだりできる状態が事業視点を持てている状態かなと。とはいえ、我々も完璧にできているわけではなく、永遠のチャレンジなのかなと思いますね。

――両社ともに複数の事業を展開されていますよね。すべての事業をしっかり理解しているべきなのか、担当する1つの事業だけ深く理解していればいいのか。そういったところはどのように考えられていますか?

伊藤:1~2年くらい前のログラスに立ち戻ると、まだシングルプロダクトだった時期があって、そのとき我々はストリームアラインドチームではなく、フィーチャーチームだったんですね。「Loglass」というプロダクトを実現するための機能群が3つあって、それぞれに対してスクラムチームが存在していました。

その時点では、各機能にまだまだ成長の余地があったので、そこにフォーカスするだけで価値が生まれるフェーズだったんですね。なので、各スクラムチーム内では、その機能に対してはエキスパートとして深く知っているけれど、横のチームの話になると、あまりよくわからないという状態でした。

そこから1つ新規プロダクトが生まれて、今はさらに新規事業も生まれ始めているフェーズなのですが、先ほどお話しした3つの機能群はかなり熟してきて、みんなが全部を理解しなければならないフェーズに入ってきました。

なので今は、エンジニアとプロダクトマネージャーとデザイナーを合わせた15人くらいの大きなワンチームで、スクラムではなくFASTという新しい取り組みをしています。FASTは、全員が1つのゴールに対して自分の持ち場をつくっていくやり方なので、みんながちゃんと全体像を理解する必要があり、難易度が上がったフェーズに入ってきたなと思っています。

――かなり難易度が高そうな取り組みですが、苦戦したことなどはありますか?

伊藤:この取り組みを始めたのは2ヶ月くらい前なのですが、最初はみんなFASTというやり方自体がわからない状態なので、右も左もわからず混乱が起きていました。今は徐々にナレッジシェアリングをしながら、みんなで課題感も理解しつつ、ちょっとずつ良くなってきています。

――複数の事業への理解というところについて、川中さんはいかがでしょうか?

川中:ログラスさんと同じように、僕たちも変化してきた部分があります。もともとはエンジニア1チームで、とりあえず全部を知っておかなければいけない状態から始まりました。その後、プロダクトがどんどん大きくなるに従って、全部を知ることが無理になってきたので、「ここだけは知っておこう」という状態をつくるようにしたんです。

なので、プロダクト単位でチームが分かれていて、そのエキスパートであるという形になっています。みんな1つのエキスパートではあってほしいですが、力がある人はいくつかのエキスパートになって複数の事業を見て、つなげてものを考えることができるようになっています。自分のできる範囲までやってもらう、というのが今の状態ですね。

両社がこれまでに投資してきた、文化醸成のための取り組み

――続いてのテーマは、「組織拡大期においても事業視点を落とさないための文化醸成とは?」です。文化醸成のために、これまでどのような投資をされてきたのかをお聞きしたいと思いますが、まずは川中さんいかがでしょうか?

川中:これは組織と開発の2つに分けてお話ししたいと思います。まず組織のところでは、意義発信を一番大事にしていて、僕らが何のために今この事業をやっているのか、ということを継続的に発信し続けています。

僕らは毎クォーター3日かけて、クォータリーセッションというものをやっています。その3日間では、「会社はこういうところに向かっていきます」という内容から、各グループどこに向かっていくのかを自分たちで考える。その次に、個人としてどこに向かっていくのかを考える。結構ヘビーなんですが、そういう時間を取っています。

そして、開発のところでは、生産性が高い状態を維持して良いサイクルをつくる取り組みを、初期からやってきています。具体的には、レビューを早くするとか、ちゃんとドキュメントを残すとかですね。Day1からDesign Docを書いたり、コードレビューをしたりしてきていて、1時間以内に何%以上返すといった裏目標を持って数値をトラックしたりもしていました。

――毎クォーター3日間のセッションが、すごく気になります。ただ話を聞くだけでなく、しっかりと自分たちで考えなければならないセッションということですよね。

川中:これは全社の全員でやっているので、ものすごく投資しています。ある人はこれを福利厚生だと言っていました。言い過ぎかなという気もしますが、でもそれくらい時間をかけてやってもペイするだろうという経営判断があってのことですね。

僕らのポリシーには「Build Your Company」というのがあって、日本語では「会社はみんなでつくる作品である」とあります。逆に言うと、自分でつくらなきゃいけないんですよ。だから、どういう会社であってほしいかを自分で定義して、そうなるように自分で動いていく。そういう文化が奨励されています。

――文化醸成のための取り組みについて、伊藤さんいかがでしょうか?

伊藤:全社的な取り組みと開発組織での取り組み、両方お話ししようと思います。まず全社での取り組みで、事業視点を持つにあたって最もインパクトが大きかったと思うのが、ウィンセッション。毎週金曜日の夕方に全社員が集まって、その1週間で出した成果を共有し合うという取り組みです。

全社員なので、それぞれの領域でどういう成果が出たのかを共有します。例えばセールスであれば、こういうお客様にこういう受注が出ましたとか、プロダクトであれば、こういう機能がようやく出せますとか、コーポレートであれば、こんなVCの方に投資いただけることになりましたとか。それを通して、会社全体がどう動いているのかを肌感として理解できる、すごくいい取り組みだと思っています。

開発組織での取り組みは、ものすごくたくさんやっているんですが、端的に言うと冒頭でお話しした3つのテックバリューに沿った取り組みをしています。

それぞれ例を出すと、「顧客への本質的な価値提供」のところでは、セールスの人たちが商談している動画を鑑賞する、商談動画鑑賞会をしています。お客様の一次情報、生の声をエンジニア、プロダクトマネージャー、デザイナーが直接取り入れて、「こういうペインを持っているから、我々はこういうことをやっていくんだ」と理解していくようにしています。

「学びと適応」のところでは、下司さんが前職でやられていた10分勉強会を、2年半くらい前からずっと続けています。プロダクトチームにいる55人が、毎日あいうえお順で発表していくことで、常に新しい知見を入れ、かつそれをアウトプットするというサイクルをひたすら繰り返しています。あとは、ペアプロや輪読会なども行っています。

最後の「技術的卓越性の追求と還元」のところでは、創業期からドメイン駆動設計をやってきていたり、毎週ライブラリアップデートするという狂気的なことをずっとやってきていたりします。ライブラリアップデートは最近2週に1回に減ったんですけど、これによってシステムを最新の状態に保つようにしています。

「もっと早くやっておけばよかった」文化醸成の施策は?

――次が、最後の質問になります。両社ともに組織が大きくなってきていると思うのですが、そうしたなかで「これをもっと早くやっておけばよかった」と思う文化醸成の施策はありますか?

伊藤:いろいろありますが、先ほどIVRyの高柳さんのセッションで、事業数値を見る会をされているとお話しされていて、それがすごくいいなと思ったんですね。我々も全社で事業数値をシェアしていますが、開発チームでその事業数値を見て、それがどういうことなのかを自分たちで語ったりはしていません。

そこまでできると、冒頭でお話ししたような、事業数値と生み出す価値をどうつなげるのかといったところに、よりオーナーシップを持っていけそうだと思ったので、これは真似させてもらいたいなと思いました。

川中:いくつかある後悔の1つをお話しすると、僕はナレッジワークが成長していくスピードを見誤っていて、今毎年人が2倍くらいになっているんですね。2倍になっているということは、入社1年未満の人が半分くらいいるわけです。その人たちが全部のことを知っているかというと当然そうではなくて、1つの事業に追いつくのが精一杯なんですね。

なので、もっと早く複数の事業を見るということを、力がある人に限らず、強制的にやっておくべきだったなと後悔しています。現状は、全部をつなげることができる人が限られていて、そういう人に負荷が集中してしまっているので、そこがつらいですね。

――今はメンバーに対して、複数の事業を見ていくための施策を行っているのでしょうか?

川中:そうですね。例えばエンジニアのなかでは、ちょっと名前が変なんですがドメインモデル勉強会というものをやっています。「このドメインはこうなっています」という内容を、中の人がみんなの前で話して、質問を受けるということを隔週でやっているんですね。

すべて録画してあり、入社した人はそれをいくつか見ることになっていて、そのドメインや事業について知れるようになっています。この取り組みは半年くらい前から始めていて、今はエンジニア主導でPdMやデザイナーも参加してもらっていました。本当はBizの人も呼べるといいのですが、深い話をすることが多いので今は絞っています。

――まだまだお話を伺いたいところですが、お時間となりましたので、最後にお二人からお知らせをお願いします。

川中:月並みですが、仲間を募集しています。ナレッジワークは昨年45億円を調達して、3年で10個のプロダクトをつくっていくと掲げているのですが、3年で10個つくるためにはやはり人が必要です。

成熟してきているプロダクトから、これからつくるぞというプロダクトまで、たくさんありますので、好きなフェーズのものに携わることができます。すごく良い仲間が多いので、鍛えられたいという人はぜひご応募いただけたらと思います。よろしくお願いします。

伊藤:メッセージングがほとんど似たような感じでとても恐縮なんですが、我々も今年シリーズBで70億円を調達して、2年で10個のプロダクトをつくるぞという声掛けをしています。正直、今の組織ケイパビリティでは2年に10個のプロダクトをつくるのは非常にチャレンジングなので、全力で採用したいと思っています。

その一部として、海外開発拠点の立ち上げもやろうとしていますので、グローバルな開発体制で働いてみたい人も積極的に募集しております。そういったチャレンジをしてみたい方は、ぜひご応募ください。よろしくお願いします。

――それでは、以上で本セッションを終わりたいと思います。川中さん、伊藤さん、本日はありがとうございました。

関連記事

NEW

強いチームと開発生産性

強いチームと開発生産性

イベントレポート

NEW

プロダクト戦略徹底討論!プロダクト/事業特性でみる、戦略・組織・プロダクト基盤設計とは

プロダクト戦略徹底討論!プロダクト/事業特性でみる、戦略・組織・プロダクト基盤設計とは

イベントレポート

NEW

グローバル開発チームの開発生産性

グローバル開発チームの開発生産性

イベントレポート
エンジニアのキャリアプランニングについて【株式会社hokan】# 開発生産性LT Week

エンジニアのキャリアプランニングについて【株式会社hokan】# 開発生産性LT Week

イベントレポート

エンジニアリング組織の
パフォーマンスを最大化

Findy Team+はGitHubやJiraなど
エンジニア向けツールを解析することで、
エンジニアリング組織の生産性を可視化するサービスです。