シェア
はてブ
エンジニアとして、どのようなキャリアを選択するか。
多くのエンジニアが思い悩むこのテーマに、わかりやすい解はありません。各人がさまざまな指標に基づき、試行錯誤しながら十人十色の道を歩んでいます。選んだキャリアにエンジニアの価値観や信念が表れるともいえるでしょう。
株式会社LegalForce*（以下、LegalForce）取締役CTOの時武佑太さんは、自身のキャリアにおいて大きな決断をした人物です。2016年に新卒入社したメガベンチャーの株式会社ディー・エヌ・エー（以下、DeNA）を2年目で辞め、当時はまだ黎明期のベンチャーであったLegalForceに1人目のエンジニアとして飛び込みました。
この勇気ある決断の裏には、時武さんのどのような意志があったのでしょうか。そして、組織の成長に伴い彼がCTOとして学んできたこととは。時武さんの歩んできた道のりについてお話を伺いました。
- … 株式会社LegalForceはリーガルテック領域に特化したサービス開発を行うベンチャー企業。AIによる契約書レビュー支援サービス「LegalForce」やクラウド契約書レビュー管理システム「Marshall」を提供している。
自身の基礎を築いたDeNAでの経験
──まずは前職であるDeNA時代について伺わせてください。DeNAへの入社を決めたのはどのような理由からでしょうか？
時武：エンジニアとして幅広い経験を積めそうだと思ったからです。DeNAは多種多様なサービスを開発・運用していますから、フロントエンドからバックエンド、インフラまで様々な技術を扱えますし、Web、スマホアプリなど携わることのできるプラットフォームも多岐にわたります。それに、社内のエンジニアもスキルの高い方々ばかり。そういった環境に身を置くことで、エンジニアとして成長できると考えました。
──DeNAで習得したスキルのなかで、後のLegalForceでの業務に活きたものはありますか？
時武：まずは、小規模なチームでの開発スタイルを学べたことです。私が所属していたのはヘルスケア事業部という部署で、あるスマホアプリを小規模なチームで開発していました。チームのエンジニアの人数は3〜4名くらいで、プロダクトオーナーやビジネスサイドとの距離も近かったです。
ビジネス側ではどのような施策を実施しているのか、プロダクトオーナーがどのような意図で開発方針を決めているのかなどを間近で知ることができました。それらをふまえて、エンジニアも柔軟に開発方針を決めていたのです。この規模のチームでプロダクトを開発した経験は、後にLegalForceの1人目のエンジニアとして働くうえでとても役立ちました。
それから、自分の健康状態をいかに良好に保ち続けるかにも意識が向くようになりました。ヘルスケア事業部は健康の維持や増進のための事業を扱っているということもあり、部署内には健康に気をつかっている人が多かったです。
特に大きな影響を受けたのは、私の同期だった健康オタクのメンバー。ヘルスケアについての知識をたくさん教えてもらったことで、健康的に仕事をしていくことの重要性を痛感できました。私はもともと夜更かしをするなど生活リズムが崩れがちだったのですが、そうした生活スタイルも徐々に改善していきましたね。
──例えば、どのように生活を改善されたのでしょうか？
時武：電車ではなく自転車で通勤をしたり、土日は筋トレやスポーツをして意識的に体を動かしたり。それからコンビニなどで食品を買う際にも、栄養表示を確認してタンパク質や炭水化物の量などをチェックしています。筋トレや食事制限に一番打ち込んでいた頃と比べると緩くなりましたが、それでも自分のコンディション管理にはかなり気をつけていますね。
──エンジニアが長く健全に働き続けるために、身体的なコンディションを整えるのは大切だと思われますか？
時武：そうですね。ベンチャー企業で働いたりマネージャーなどの役割を務めたりする場合、どうしても仕事はハードワークになりがちです。だからこそ、いかにして健康を維持し続けながら働くかが重要になってきます。よく“心身ともに健康”と言われますが、メンタルとフィジカルは別々のものではなく、両方が紐づいている。フィジカルを改善することでメンタルも改善し、充実した状態で仕事ができると思います。
技術以外の柱を身につけるため、ベンチャーに飛び込んだ
──DeNAからLegalForceに転職されたのはなぜですか？
時武：所属していたチームで1年半ほど仕事をして、そろそろ別のチームに移ってみようと思っていました。ですが、諸事情があり希望していた部署に行けなくなってしまったのです。その頃から転職も視野に入れるようになり、どうせ移るならば創業間もないベンチャーが良いと考えていました。
──なぜ、創業間もないベンチャーを候補に？
時武：技術“以外”の柱を身につけるためです。DeNAで働き続ければ、間違いなく技術力は伸びていたと思います。ですが、世の中には各領域のスペシャリストといえるエンジニアたちがいて、技術1本でやっていくならばそういった人々と競争していかなければなりません。それが自分にできるのか、不安な気持ちが生じていました。
それよりも、組織のマネジメントや経営に携わり、技術以外のスキルを身につけてマルチプレイヤーになる方が将来的な自分の価値は高まるのではないかと考えたのです。その目標を達成するならば、体制や組織がすでに出来上がっている企業よりも、イチから全てを構築していける黎明期ベンチャーの方が良い。そんなタイミングで、偶然にも複数のベンチャー企業からお声がけいただき、そのなかの1つがLegalForceでした。
──LegalForceを選んだ決め手は何でしたか？
時武：候補のなかには、LegalForceのように創業したばかりの企業もあれば、もう少し成長して社員が数十名くらいの企業もありました。ですが、すでに一定数の社員がいる企業は、先ほどの“イチから”という条件に当てはまりません。それならば、DeNAで純粋に技術力を磨く方が経験としてはコスパが良いと考えました。
LegalForceを選んだのにはいくつかの理由があります。まずは、私が1人目のエンジニアだったため、自分自身で何もかも切り拓く経験が積めると思ったこと。そして、弁護士と働くことに興味を持ったことです。LegalForceは弁護士が創業した企業で、いまも社内には複数の弁護士が在籍しています。エンジニアが普通に仕事していても、おそらく絶対に関わらない職種。そういった方々と働けるのは貴重な機会だと感じました。
また、私がLegalForceに参画した2017年時点では、リーガルテック*という領域が日本にほとんど浸透しておらず、未知の領域にチャレンジする面白さがありました。もしも今後、LegalForceで一定の成果を出して別の企業に転職する際にも、テクノロジーが浸透していない領域に挑戦する場合には、LegalForceで培った経験をきっと活かせます。こういったさまざまな理由からLegalForceを選びました。そして入社後すぐ、CTOという肩書きで働くようになりました。
- … 法律（リーガル）と技術（テクノロジー）を組み合わせた造語。法律業務を支援するテクノロジーのこと。
Must haveとNice to haveの境界線を見極める
──企業としての黎明期、少人数でプロダクトのMVP（Minimum Viable Product）を開発されていた頃に大変だったことはありますか？
時武：私が入社してから3か月ほどでMVPが完成したのですが、納得のいくプロダクトになっておらず、コンセプトを変えて完全に作り直すことになりました。あれはなかなか堪えましたね。
──なぜ、初期のMVP開発に失敗してしまったのでしょうか？
時武：当時、社内にいたメンバーたちが、ユーザーにとって本当に必要な機能は何なのかという視点を持たないまま、開発を進めてしまったことです。自分もプロダクトマネジメント的なスキルを持ち合わせていなかったですし、創業メンバーである弁護士たちもテクノロジーで何ができるのかを模索している状況でした。結果としてユーザーのニーズに沿わないプロダクトが完成してしまったのだと思います。ユーザーが本当に必要なものを探り当てることの重要性がUX領域ではよく語られますが、それを実感しましたね。
──初期に開発してボツになったプロダクト案と現在の「LegalForce」とでは、どのような違いがありますか？
時武：契約書のレビューを支援するというコンセプトはどちらも一緒ですが、アプローチが異なります。初期に開発していたものは、契約書レビューの過程で生じる、相手方の企業や社内の法務部内でのコミュニケーションを効率化するというコンセプトでした。一方、現在の「LegalForce」はレビュー業務そのものを自動化するというコンセプトになっています。本質は同じですがアプローチが異なる。ユーザーの求めるものは、レビュー業務そのものの自動化であることに気づいたからこそ、現在のプロダクトの方向性になりました。
──創業間もないベンチャー企業は、エンジニアの人的リソースや金銭的リソースが限られています。その状況下で的確にプロダクトのコンセプトを定め、実装すべき機能を選定するために役立つ考え方はあるでしょうか？
時武：機能を選定するうえでは、強い言葉を使いますが、その機能がないと（事業として）死ぬのかを考えることが重要です。プロダクトマネジメントにおいては、Must haveとNice to haveという用語がよく用いられます。Must haveとは、その機能がなければプロダクトとして成立しないようなもの。Nice to haveとは、あれば望ましいがなくてもプロダクトとしては成立するものです。
ベンチャー企業の初期フェーズにおいては、Must haveでなければ開発しないという方針を徹底しなければなりません。これを開発に携わる全員が念頭に置いておかなければ、いつの間にかNice to haveは紛れ込んでしまう。Must haveとNice to haveの境界線を見定めること自体が、極めて難しい作業ですから。
──境界線を見極めるために、日常的に取り組んでいることはありますか？
時武：何より大切なのは、利用者の声を聞くことです。継続的にユーザーインタビューをしていますし、社内の弁護士にも「LegalForce」を利用してもらい感想をヒアリングし続けています。プロダクトの性質上、エンジニアがドッグフーディング*することは難しいですから、社内に（想定ユーザーである）弁護士がいることはとても大きい。体制として非常に恵まれていると思いますね。
- … 社員が自社サービスを日常的に利用し、サービスの課題や改善点、強みなどを発見すること。
より良いエンジニア組織を生み出すために
──サービス開発をやり直したこと以外に、組織の黎明期における反省点はありますか？
時武：メンバーとのコミュニケーション量を増やしたほうが良かったと思います。もちろん、開発を進めるうえで必要なコミュニケーションはとっていたのですが、カジュアルコミュニケーションの量が非常に少なかったです。個々のエンジニアが独立的に働いているような雰囲気でした。もう少し上手にチームビルディングできていれば、先ほど述べたような作ったプロダクトが水の泡になるような事態も、ある程度は軽減できたかもしれません。
──コロナ禍によってリモートワークの導入が進んだことにより、組織内のカジュアルコミュニケーションをどう増やすか悩まれている企業が増えています。時武さんが心がけている、コミュニケーション頻度を上げるための工夫はありますか？
時武：フルリモートワークだった頃は、毎日夕方6時に2名ずつ自己紹介するコーナーを設けたり、業務時間内にシャッフルでグループを組んで30分くらい雑談をする時間を設けたりといった工夫をしていました。それから、自分が家でコーヒーをドリップする配信をして、コーヒー好きなメンバーに視聴してもらい配信内で雑談する試みもしていましたね。
最近は水曜と金曜を出社日にしているのですが、メンバーとすれ違った際には声をかけるように意識しています。それから普段実施している1on1ミーティングでも、仕事に関する話だけではなく、当たり障りのない範囲でプライベートな話もしてみるとか。業務の場だけでは見えない、そのメンバーの人となりが見えてきます。
──エンジニア組織の人数が徐々に増えるにつれ、体制構築やチームビルディング、権限移譲などに注力されてきたと思います。今後、同じようにマネジメント業務を経験されるであろう読者に対して、アドバイスはありますか？
時武：私と同じように若くして創業間もないベンチャーに飛び込んだ場合、メンバーをマネジメントする経験が浅い、そもそもマネジメントをしたことがないといった方も多いはずです。その場合、いきなり大勢のメンバーのマネジメントを試みても破綻してしまう。最初はなるべく片手で数えられるくらいの人数を見ることから始めると、気持ちの面でも楽ですし、組織運営においてどのような課題が出てくるかのケーススタディもしやすいです。
それから、組織の人数が少ない段階から、将来のマネージャー候補となるメンバーを見つけておくことが必要です。それは、今いるメンバーのなかからでもいいですし、外部から採用する形でもいい。組織が大きくなる前に候補者を見つけ、早い段階でその方に権限移譲しておくことで、自分自身の負荷を軽減できます。
業務と真剣に向き合い、見えるものが変わった
──現在、LegalForceのエンジニア組織はどのようなチームになってきていますか？
時武：当社のエンジニア組織は製品開発チームと研究開発チームに分かれているのですが、面白いことに両チームの雰囲気は少し違います。製品開発チームは特定のプロダクトを5〜10名ほどで担当していく形なので、チームワークが強い組織になっているなと思います。誰かが困っていれば、他の誰かがカバーに入る。スポーツでいえば野球やサッカーのようなイメージでしょうか。一方で研究開発チームは、各要素技術を用いるAPIを2〜3名ほどのチームで開発していくので、少数精鋭という雰囲気があります。スポーツでいえばテニスのダブルスのようなイメージですね。
──いわば業務の特性が、チームの雰囲気にも影響しているわけですね。LegalForceにおいてチームプレイ的な雰囲気を醸成できたのは、なぜだと思われますか？
時武：基本的に、開発に関する情報を常にオープンにする文化を大切にしてきました。例えば、可能な限りSlackのオープンチャンネルでやり取りするとか、ドキュメントは誰でも閲覧できる場所に置いておくとか、情報が欲しければ誰でも取りにいけるようにしています。
LegalForceには自走力のあるエンジニアが多いので、どういった開発が社内で行われているか、各エンジニアが何に携わっているのかなどを自発的にキャッチアップしてくれる。だからこそチームとしての一体感を醸成できたのかなと思います。
──組織として理想的な形ですね。
時武：とはいえ、エンジニア組織の規模が大きくなってきたことで、さすがに個々の情報がどこに置かれているかがわかりにくくなってきました。それに、人数が増えるにつれて企業が目指す方向性や事業の理念を全メンバーに伝える難易度も高くなってきたと思います。
現在はそうした課題を改善するためのプロジェクトを進めている最中です。施策の例を挙げると、情報を掲載する媒体を統一したり、全社的なミッションを制定したり。メンバーみんなに同じ方向を向いてもらいながら、会社が目指しているものや社内で起きていることを把握してもらいたい。それをふまえて、自分ならばどのようにコミットメントできるのかを考えてもらえたら嬉しいです。
それが上手くワークするまで時間はかかると思いますが、企業の今後のためにも絶対に実現していきたいです。それから、単純にまだまだ人が足りていないですから、事業として数年後のプランを実現するため、メンバーを採用していくための施策や情報発信を今後も頑張っていきたいと思います。
──LegalForceの今後が楽しみですね。最後に、時武さんのキャリアを振り返り、自分がこの道を選んだからこそ得られた知見について伺えればと思います。
時武：立場が人をつくるという言葉がありますが、CTOを3年間担ってきたことで本当にそうだと実感しています。LegalForceに入った当初はまだ一介のエンジニアという気分が抜けておらず、さまざまな失敗をしました。しかし、徐々に経営者としての自覚が出てきたといいますか。開発組織が大きくなるにつれて、CTOとしてどうやって組織全体のアウトプットを最大化できるかを考えるようになっていったのです。
エンジニアとして良いキャリアを築きたいと考えている方々はたくさんいらっしゃると思うのですが、私から何かアドバイスできることがあるならば、チャンスを得たら全力でコミットしていくこと。それから、覚悟を決めることが大切だとお伝えしたいです。私自身もCTOの業務と真剣に向き合うようになってから、見えるものが全く変わってきました。
それから、このポジションを経験してみて痛感するのは、エンジニアであろうとも、仕事として技術を扱っている限りはビジネス的な観点が必須であること。もちろん技術研鑽を続けることは大前提ですが、そこにプラスアルファして積極的にビジネスのことを理解しようとする姿勢、ビジネスサイドと連携をとっていく姿勢は重要になってくると思いますね。
