クラウド名刺管理サービス「Sansan」、名刺アプリ「Eight」、さらにリモートワーク時代の新たな柱として誕生したクラウド請求書受領サービス「Bill One」など、ビジネスインフラとして企業を支えるSansan株式会社。今回は同社でCTOを務める藤倉成太氏に、Sansanにおけるエンジニアおよびエンジニアリング、その集合体としての組織のあり方についてお話を伺いました。そして、このインタビューを実施するタイミングで進行中の、次の10年に向けた新しい組織像と実践について詳しく伺ったので、その模様をお届けします。
目次
自身のキャリア形成とマネジメントへの意識
――藤倉さんのこれまでのエンジニアとしてのキャリア、また、その中で得られた経験や考え、それに伴って生まれた価値観・変化などがあれば教えてください。
藤倉成太氏（以下、「藤倉」）：スタートはSIer（株式会社オージス総研）への入社でした。約10年在籍し、製品導入のコンサルティングなどを中心に行い、後半5年は、米国・シリコンバレーへ赴任しました。そのとき現地ベンチャーとの共同開発に関わることでプロダクト開発の現場を体験したのが、自分自身のエンジニアとしての1つの転機でした。
渡米前までは、エンジニアのキャリアを積む中で自分への意識、ベクトルが強く、自分の技術力を上げることに注力していました。しかし、渡米して現地で多くの企業・エンジニアと出会い、刺激を受け、「自分への意識」から「プロダクトへの意識」が高まったのです。
そして2009年、現在のSansan株式会社へ転職しました。Sansanへジョインした大きな理由の1つは、米国で刺激を受けて感じた「プロダクトで世の中にどれだけインパクト出せるか。技術力の武器だけみがいててもインパクト出せないと意味がない。すべては世の中へのインパクトを出すためだと思っている」という考えでした。
当時のSansanはまだ今のような大所帯ではありませんでしたが、現在のSansanの前身である法人向けプロダクトを展開していましたので、そのプロダクトを成功させることに集中し、Sansanのキャリアをスタートしています。
――渡米経験が、プロダクト指向の基礎となったわけですね。
藤倉：はい、エンジニアであれば当然技術力は必須ですし、技術力を上げていくことが武器となります。でも、ただ技術力を上げるだけがエンジニアの資質ではありません。（その技術力を生かして）関わるプロダクトやプロジェクトが成功することが最も大切だと考えるようになりました。
プロダクト指向を前提としたチームビルディング、コロナ禍での変化
――プロダクト指向を持ってSansanに入社したとのこと。その後のキャリア、また、直近では2020年から現在に至るコロナ禍での変化について、マネジメントやチームビルディングの観点からトピックがあれば教えてください。
藤倉：自分が入社した当時、メインプロダクトは法人向けのもの1つ（現Sansan）で、その後、個人向けEightを提供し、長らく2本柱で事業を進めていました。いずれも、Sansanのミッションでもある「出会いからイノベーションを生み出す」を体現するもので、オンライン/オフライン問わず、ビジネスにおける出会いから、イノベーションを後押しするものです。
2020年のコロナ禍は、オンラインコミュニケーションが中心となったわけですが、それによって、オンラインの価値が相対的に高まりました。それは、私たちSansanがこの数年間で培ってきたオンラインコミュニケーションを軸としたプロダクト、その事業領域をどのように活用するかが試される瞬間でもありました。
3本目の柱となる新しいプロダクトBill Oneはそのような状況下で誕生したサービスです。これまでは企業間のつながりや個々人をつなぐ名刺を起点にした出会いを生むプロダクトを提供していた会社が、いきなり請求書を扱ったことで「出会いと関係があるのか？」という疑問をお持ちになった方がいたかもしれません。
しかし、請求書は企業間・個人間・企業/個人間のビジネスにおける出会いから生まれる非常に重要な要素です。私たちのミッションである「出会いからイノベーションを生み出す」を体現する、必然的に生まれたプロダクトでもありました。
このように、想定外の情勢の中、新プロダクトが生まれるように、エンジニアを含め、企業内での横展開ができるという点は、私たちSansanの強みでもあります。
――企業内での横展開という部分について、もう少し詳しく教えていただけますか。
藤倉：組織再編前のSansanは、事業部ごとにエンジニアチームがあり、プロダクトに対するエンジニアチームが構成され、組織化されていました。
そうした、事業やプロダクト単位とは別に、DSOC（Data Strategy & Operation Center）というデータ統括部門も用意しています。私たちの事業の鍵を握る名刺をはじめ、書類、プレスリリース、業績や株価など、さまざまな情報の「データ化」「データ活用」を担っています。Bill One誕生の背景にも、DSOCを中心にデータと向き合った結果があります。
このように、プロダクトの対象や目的、機能は異なる中で、「つながり」の定義をしっかりと行い、データへの向き合い方を共通化していることが、スムーズな横展開へとつながっています。
プロダクトを“深く”理解することが、エンジニアチームにとって重要
――ミッションである「出会いからイノベーションを生み出す」、さらには、その前提となる「つながり」の定義の共通認識を徹底していること、また、それを実現するための組織が、今のSansanのチームとしての技術力を支えているように感じました。
次に、実際の開発現場に対して、藤倉さんご自身が意識していること、ポイントやエピソードがあれば教えてください。
藤倉：エピソードではないですが、まず、私が入社した当時のエンジニアやエンジニアチームの状況について時系列順に変遷をお話しします。
創業当時～スタートアップベンチャーとしての開発体制
まず創業当時です。このころはまだ、開発部のメンバーは私を含め5、6人程度の小さいチームでした。しかし、チームとは言うものの、プロダクトに対する一人ひとりの責任、対応範囲の割合が大きく、言い換えれば個人への依存度が高い開発体制だったと言えます。
加えて、開発プロジェクト一つひとつを見ても、代表の寺田親弘、創業メンバーの常樂諭、もう1名のエンジニアというような、最少人員でのメンバー構成だったため、代表を含めた経営陣が深く関与しながら開発を進める、いわゆるスタートアップベンチャーにありがちな、誤解を恐れずに言えば原始的な状態でした。
プロダクトベースの組織化～プロダクトマネジャーの設置
その後、事業の成長に伴い、エンジニアの採用が進み、20名、30名と拡大していきました。2012年のEightのリリース、2013年に先ほどお話ししたDSOCの前身組織の発足となり、そのタイミングで私が開発部長となりました。現在のSansanのエンジニア組織の原型です。
ようやくチームと言えるようになった中で、最初にやったことの1つが「プロダクトマネジャー」というポジションを作ったことです。皆さん、その役割はご存知かと思いますが、当時はまだプロダクトマネジャーという名称は一般的ではなく、その中で、アメリカの企業を調べたり、ネットで探したりして寺田や常楽、私で考え、決めたポジション名です。
その一番の理由は、組織の拡大に伴い、寺田を中心とした経営陣の深い関わりが（リソース的に）難しくなったこと、一方で、開発を行うエンジニア側もビジネスへの理解は欠かせないこと、その責任とともに経営と開発の橋渡しとなるポジションとして設置することにしました。
初代プロダクトマネジャーには、創業直後からエンジニアとして開発を行い、また、その後CS（カスタマーサポート）を行うなど、市場やユーザへの理解が深く、社歴の長い人間を任命しました。
現在の組織～プロダクトマネジャー、UXデザイナー、エンジニアのチームとして
そして、組織の細かな調整、プロダクトの進化に合わせて、現在の組織へとなります。現在は、エンジニアという括りだけではなく、前述のプロダクトマネジャー、また、プロダクトごとにUXデザイナーのポジションを用意し、開発・運用・改善をしています。
――今のお話を伺って、改めて、藤倉さんご自身が持つ「プロダクト指向」の強い信念を感じます。
藤倉：当時から特別なことをしているつもりはないのですが、プロダクトの成功こそが最重要課題と考えて入社し、その点は、開発部長になっても変わりませんでしたし、今ももちろん変わりません。
あえて言語化するのであれば、私たちのような事業者にとって、「プロダクトのあり姿≒会社の姿」であり、だからこそプロダクトの定義が高度な作業になります。ですから、組織を拡大させるには、プロダクトの定義をしっかりと行い、メンバー全員に浸透させられるかどうかは大事なわけです。
プロセスへの意識～プロジェクトの仕様が最初からすべて決まっていることなどない現実と向き合う
――プロダクトの定義、それを伝えるリーダーとしてのプロダクトマネジャーの存在など、Sansanのエンジニアチームの特徴がわかる組織作りの経緯です。その間、苦労した点や悩んだことはありますか？
藤倉：もちろんあります。前提として、拡大期ではエンジニア一人ひとりが事業の状況を理解することを重要視し、なぜ（この事業・プロジェクトが）立ち上がったのか、何が目的なのか、背景を理解できる・理解する環境を整備しました。
また、現実問題として、プロジェクトが立ち上がる前や立ち上がってすぐの状況で、仕様がすべて決定しているなんてことはありえません。少し曖昧な状態、詳細はこれから詰めていきますというところで立ち上がることがほとんどです。ですから、エンジニアがインプットして意思決定する必要があります。だからこそエンジニア自身が、事業の背景を理解している必要があります。
また、それを実現するために、会議体の設計方法や、決定裁量とエンジニアの巻き込み方などプロダクトマネジャーの判断裁量については、プロダクトマネジャー主導で定義するような設計です。
答えがない中でも、定義をしておかないとプロジェクトの完成度が変わってしまうので、「開発プロセス」は常に意識して開発を進めてもらうようにしていました。
私は開発という工程は投資することと同義と考えています。ですから、プロダクトマネジャーは、投資に対するリターンを最大化することが目的になりますし、そのための投資をしてもらうよう、上長や経営陣を説得する役目を担うわけです。
言葉では簡単に言っていますが、私がプロダクトマネジャーのポジションを設置した当時はまだ今のようにUXといった考え方は浸透していませんでしたし、UXに関連した手法やツールは皆無でした。ですから、プロダクトとして見た場合の、機能とUXのバランスなど、エンジニアとデザイナーの間での共有は難しかったことを覚えていますね。
また、共有をしっかりするためにも、開発プロセスを細かく定義することを心がけていましたし、プロダクトマネジャーにも意識してもらっていました。
チームの能力を最大化させる「影響力」という評価軸
――メンバー間の定義の共有がプロダクトの成功を握る。そのための開発プロセスの細分化・明文化というのは非常に印象的です。開発プロセスの細分化、メンバー間での定義の共有とともに、気になるのがエンジニアの評価軸です。Sansanでは、評価のフレームワークなど具体的な仕組みは用意していますか。
藤倉：昔話で言えば、入社した当時は評価なんてあってなかったものでした。まず、プロダクトを開発し、成功させることが全員の目標であり、目的でした。
その後、私が開発部長になり、評価フレームワークとして設定したのは「技術力」「リーダーシップ」「影響力」の3つの項目です。CTOになった今でも、この3つが基礎となっています。
技術力やリーダーシップはわかりやすい評価かと思います。技術力とは、1つ1つの技術に精通しているかどうか、リーダーシップとは、周囲を巻き込んだり、自分の考えを明確にし、周りに伝えられるかどうかという評価項目です。
3つ目の影響力、これがSansanとしてユニークな評価項目かもしれません。
影響力というと、リーダーシップと同じように、周囲の人間を巻き込んだり、影響を与える側のことと捉えられがちですが、私が考える影響力はそれだけではありません。
よく耳にするエンジニアは口下手というのは、私たちの会社でも少なからずあります。その部分は性格も関わるため、単純な評価には加えません。また、口下手な人はリーダーシップを取って、周囲を引っ張っていくことが苦手かもしれませんが、一方で、フォロワーシップを持っている可能性はありますし、それは支える、他の人の影響力を高める能力とも捉えられます。
他にも、たとえば、依存関係のある機能開発をした場合のコンフリクトを最小限にする意識や考え方、開発方法、さらに全体を見渡したリリース順の意識など、引っ張っていく以外に、必要なことは多々あります。
これらをまとめると、
- フォロワーシップ
- （周りを）支える力
- 他人の影響力を高める力
- 周囲を見渡す力
といったような能力で表せます。
このように、チームとして見た場合に、その人の立場でチームに与える影響力がプラスに働くかどうかを「影響力」の評価項目として定義して使います。
2021年、新しい挑戦～オールSansanとしての開発、その先にある成長
――組織としても事業としても順調に成長し、また、プロダクトの数が増えていく中、今、藤倉さんが考えるSansanのエンジニアチーム、これから目指す姿はどのようなものなのでしょうか。
藤倉：順調とおっしゃっていただきましたが、私自身は満足できていないですし、実際、今も課題が生まれています。
これまでお話ししてきたように、プロダクト指向の考えでチームを作り、ポジションを定義し、開発を進めてきました。その結果、これまで目新しいと言われていたポジションやロールへの理解も、Sansan社内で深まってきたと感じます。
とくに、2020年を区切ってみると、Sansan/Eight/Bill Oneという3つのプロダクトを柱とした事業部制が整備され、各事業部の中に、エンジニアチーム、さらにはマーケター、デザイナーなどが配置され、異なる職域でも同じ事業の傘の下でプロダクト開発を進めてきました。
これは「事業を理解したプロダクト開発」において非常に有効で、また結果にもつながると感じました。しかし、3つの事業部の中に、さまざまな機能、それに伴う小さなプロダクトが生まれ始めたことにより、事業とプロダクトの関係が、1：1ではなく、1：ｎになり始めてきました。加えて、他事業と共有するプロダクトの登場もあり、事業とプロダクトの関係がｍ：ｎという状況になりつつあります。
その結果、プロダクトオーナーを中心としたプロダクト中心の開発の進め方に歪みが出てきたのです。
そこで、考えたのが、これまでの事業別の体制ではない、職能（職域）型の組織です。具体的には、これまで事業部ごとに区切っていたエンジニア組織を、2021年7月から全社横断のエンジニア組織として、再編成しました。
――それは大きな決断ですね。藤倉さんご自身のご決断だけではなく、経営陣や従業員にとっても非常に判断に悩む決定だったかと思いますが。
藤倉：大きな変更ではありますが、課題（前述の事業成長・組織拡大に伴う歪み）そのものは経営陣をはじめ、Sansan全社的に感じており、共通課題として見えてきた状況でしたので、組織編成に対しての抵抗や反対意見はほとんどなかったです。
また、さらに細かなプロダクト型へ落とし込まず、職能型へ再編成することに対しても、私たちのミッションである「出会いからイノベーションを生み出す」、やバリュー、さらに、最近定義した「ビジネスインフラになる」というビジョンが社内的に浸透したことで、ブレることなく動き出すことができました。
まだ、再編しただけで、見えているだけでも、これまでのように事業に基づいた開発プロセスの定義（事業と開発の距離感、事業の状況の理解）や、個々人の責務の範囲、開発そのもの基本スタイルなど、不透明な部分はあります。
その他に顕在化している課題としては、職能型組織にすることにより、各プロダクトの売上・KPI設定などは、これまでとはまったく異なったものになるので、そこで生まれる新しい定義の必要性です。私の立場としても、改めて新しい組織としての職能ラベルや評価軸の準備も必要となります。
ただ、そうした課題があったとしても、これからのSansan、さらなる事業拡大と成長に向けては必要な組織再編であると私は考えています。
スタートはこれからです。ただ、今回の再編によって、これまで「プロダクト指向」で行い、3つのプロダクトの集合体であったSansanが、エンジニアを含めた従業員全体の集合体としてのSansan、オールSansanとして前に進んでいくことになりました。
ミッション、ビジョン、バリューの定義と共通理解、そして、プロダクト指向のもと、柔軟性のある組織として、Sansanの成長を目指していきます。
――ありがとうございました。
（聞き手：株式会社技術評論社 馮富久）
藤倉成太さんに3つの質問
Q1：藤倉さんが考える優秀なITエンジニアが持っている要素
やはり技術が好きであるということは大前提にあると思います。純粋に技術が好きという人、成果を出すための手段として好きな人など、好きの形は人それぞれですが、優秀だと言われるエンジニアはみんな持っていると思います。
それに加えて、プロダクトへの貢献や事業の成果というものを理解していることも重要だと思います。そもそもこう言ったことを理解していなければ、プロジェクトの中で行うべき意思決定が正しくできないはずです。開発で行う判断のうち、事業的な制約を全く受けないものは多くはありません。つまり、事業をしっかりと理解できていなければ、エンジニアとしての正しい判断ができないのです。
Q2：藤倉さんが今注目している、技術、プロダクト、サービス
IaaSやPaaSとも呼ばれるクラウドサービスは全般的に注目しています。クラウドプラットフォームが発達していくことで、システムアーキテクチャの考え方が変わりますし、我々の開発速度も向上します。また、この変化が今後のエンジニアのあり方を決める重要な要素にもなってくると考えています。これまでのソフトウェア技術は発展に伴って下位層の実装を隠し、構造をシンプルにしてきました。今、その領域を最も強く牽引しているのがクラウドプラットフォームだと思っています。
Q3：藤倉さん個人として興味があること、これからの社会との関わり方
Sansanに入社した理由でもありますが、日本のソフトウェアプロダクトが世界で使われるようにしたいという個人的な想いを持っています。その実現をSansanで成し遂げたいですね。そして、今回の組織変更はそのための重要な要素だと考えています。Sansanのエンジニア組織を発展させ、よりよいプロダクト開発をリリースし続けたいと思います。
