SansanCTOが語る、事業成長と共に考える技術的負債の“返済計画”

Sansanのミッションとプロダクト

藤倉成太氏：よろしくお願いいたします。Sansan株式会社でCTOをしています、藤倉と申します。

自己紹介ですけど、別にあまり深く読んでいただく必要はないかなと思いますので、適当に流してください。

これもちょっと会社のミッションに触れておこうかなと思って用意しただけなんですけど、ちなみにSansanという会社を知っている方ってどれくらいいらっしゃいます？

（会場挙手）

ありがとうございます。たぶん98パーセントぐらいかなと。

（会場笑）

先ほど福村さん（福村彰展氏）にも言っていただきましたけど、昨日無事に上場を果たしました。と言っても何も変わらないですけどね。こんな感じです。

あとは、ご存知の方が多いということでちょっと安心しましたが、われわれは、メインのところでは名刺を中心としたプロダクトを、法人向けと個人向けで2つやっています。

また、この1～2年ぐらいで新規事業に関しても取り組みを始めていまして、実際にもうローンチしたプロダクトもいくつかあります。それはここでは説明はしていないですけど、「そんなものも取り組みを始めましたよ」と、そんな感じです。

ここから本題にいっちゃうんですけど……福村さんのプレゼンを見て「なるほど。会社の体制とかをちゃんと説明しないと、言ってることがわからないな」と思ったんですけど、そんなものはこの場で気が付いても時すでに遅しですよね。スライドを作ってないので、口頭でお話します。

会社全体では480人ぐらいの社員がいます。そのなかで「エンジニア」という肩書というか役割を担ってくれているのが、だいたい150人ぐらいですかね。それに加えて、R＆Dの研究員とか、UI/UXのデザイナー、プロダクトマネージャー、いわゆるモノづくりに関係する人を入れると、だいたい200人弱、180人ぐらいになるような組織です。

SansanにはSansan事業部、EightにはEight事業部というのがあって、それぞれに開発チームがあります。法人向けはたぶん開発部だけで120人ぐらいいるのでかなり大きな所帯になっています。Eightの開発チームは40～50人ぐらいですかね。けっこう大きさな差があります。

技術的負債とは何か？

そういう背景のなかで、「技術的負債とは何か？」というお話をしていきたいと思いますが、なんとですね。Wikipediaから持ってきたんですね。

（会場笑）

そりゃこうなりますよね。しかも、（福村氏の発表の）後じゃないですか。不利ですよね。もうこれはみなさん先ほどご覧になっていただいたので、いいかなと思います。

僕はSansanという会社で、いわゆる自社サービスの会社でプロダクトの開発をしているので、この立場からでしか書けないんですね。もしかしたら、ご参加いただいた方の中には、例えばSIとか、そういう事業者の中でやっていらっしゃる方とか、その他いろいろいらっしゃるのかなと思うんですが、僕はこういう経験しかないので、申し訳ないですけど、こういうものを中心に話をさせてもらいます。

先ほどの福村さんの話はTIPSとか細かい具体的な方法論とかだったので、聞いていて「ああ、なるほど。これは有用な情報だな」と、「全然、自分のとは違うわ」と思ったんですけど、違う観点でお話をするので、いいかなと思います。

考え方やフェーズごとでどんな対応をしてきたかとか、そんな話をしたいなと思っています。

Wikipediaの話にちょっと戻りますけど、（スライドを指して）ここに書いてある「行き当たりばったりなソフトウェアアーキテクチャ。余裕のないソフトウェア開発が引き起こす」って、けっこう狭義の意味というか、狭いんですよね。

もう少し広い意味にすると、例えば時間の経過によって発生するものというか。今日この場でとてもモダンなコードを書いたとて、5年後には「負債だ」としか言われないんですよ。「絶対それはそうだ」と僕は思っているんですね。

なので、「時間の経過とともに既存のコードが少し古くなってきて、直さないといけないよね」という話だって、もちろんそれは技術的負債ですし、福村さんが今取り組まれていると仰っていたライブラリとか言語とかフレームワークのバージョンアップって、これも別に放っておいたら「負債だ！」って言われるわけじゃないですか。

そういうのはここでは説明されていないんですけど、たぶんそういう広い意味での負債はあるなと思っています。

サービス事業における技術的負債

それで、ここで言っている「開発チームの能力」というのは、やっぱり一番大きいところとして出てくるかなと思っています。これは、もう開発初期は人数が少なくて、例えばわれわれみたいなサービスプロバイダが3人のチームで開発をしていましたと。そういったときに、技術的負債がないコードを書くなんて不可能なんですよ。それはもうしょうがないですよね。だって能力はそれが限界なので。

それはそれでいいかなと思っているんですけど。そんなこともあったり、人数が3人で出せるアイディアと、30人で出せるアイディアって違うので、そういう意味での人数による限界値というのがあるかなと思います。

あとは、われわれみたいな業種や業界だったらある話かなと思うんですけど、今の時間を手に入れるために、あえて負債を良しとするケースもあるんですね。僕のなかでは、こういう系のものは負債というか借入と言いますか。ちょっと前借りするとか、そんな感じだと思っているんですけど。

新しい事業を立ち上げる時って、そもそもその事業がうまくいくかなんてわからないわけですよ。明日「事業やめやめ！」って言われるかもしれないなかで、そんな丁寧なコードを書いている場合じゃないんですよね。死ぬか生きるかみたいな話なので。

そういう意味では「今は速く作らなきゃいけないけど、追って直しましょう」「直しやすいコードにはしておきましょう」みたいなかたちでの技術的負債っていうのは、発生要因としてあるのかなと思います。

あと（スライドの）3つ目。先ほど申し上げた通りですけど、「時間経過による負債化」かなと思います。これは開発技術、言語、フレームワーク、いろんなものがどんどん出てきますし、とくにうちの法人向けのSansanは、サービス開発当初はオンプレだったんですよ。今は90パーセントぐらいがAWSで、10パーセントぐらいはAzureを使っていたりします。

なので、オンプレに最適化された設計、アーキテクチャって、AWSの上に乗せてもクラウドネイティブなアーキテクチャにならないんですね。これは、最初からAWSで開発していたら違ったのかもしれないですけど、今法人向けのSansanってバックエンドのデータベースが PostgreSQLなんです。PostgreSQLは何が一番いいかって言ったら、僕らはコードからコンパイルしてEC2の上で動かしているんですよね。ブロックサイズとかを調整して、パフォーマンスを最大にしたかったからなんですけど。

もしこれが開発当初、12年前にAWSがあってRDSがあったら、もしかしたら違うことになっていたかもしれないし、結果同じだったかもしれないですけど、そういうことってあるので。

ただ、オンプレだとRDSを選択しないので、「別にソースからビルドしようが、普通にパッケージを落としてこようが大差なくね？」っていうので「速いほうがいいじゃん！」って言って、ビルドのパラメータを変えてゴリゴリチューニングするってことをやっていたんです。

返済計画によくある失敗

あと、よく質問があるんじゃないかと思うんですけど、「この技術的負債をどうやって返しましょう」と。「どうやって説明したらいいですかね？」みたいなことをたまに聞かれるんですね。

実際、僕が自分のメンバーに言われたこともなくはなかったんですけど、「この設計、よくない」って。「開発効率悪くないですか？　改善しましょうよ」って言われても、僕「うん」とやっぱり言えないんですよね。だって妥当性がないから。「そんなものは趣味じゃん」って思うわけですよ。

これは福村さんも仰っていた通り、人によって感じ方が違うわけですよね。同じコードを見ても、他の人が「まあまあ、しょうがないじゃないですか。別に大丈夫ですよ」って言う人もいれば、「これはもう負債でしょ」って言う人がいるわけです。

なので、僕はこういうアプローチはよくないなと思っています。やっぱりエンジニアによる開発って、大切な時間を使ってやる営みなわけなんですけど、これはもう投資行為じゃないですか。「この時間を何に使いますか。どんな価値のある行動に使いますか」という話なので、意味のないところにお金を使ってもらいたくないわけですね。

なので、このリターンが、定量的ないし客観的事実……これは定量じゃなくてもいいと思いますけど、それに基づいた目的や結果の測定なんかもできるといいなと思ったりします。

先ほども言いましたけど、現在ベストプラクティスで何かを改善したとしても、それはそのまま放っておいたら数年後にはそのまま負債になるので、今お金をかけて将来の負債を作るっていう行為なんですね。その営みに経済的価値があるとは僕は思えないので、「OK」とは言わないですね。

前提となるリソースを確保する

じゃあそれをどうやって返済するかって話なんですけど、われわれみたいな会社は、もうリソースがないと担保できないんですよ。先ほども言ったように、3人で事業の開発をしていたら負債なんか返せないですよ。絶対返せないです。無理です。なので、採用をがんばるしかないです。

「採用をどうやってがんばるか」ということは、いろいろ後で話をするんですけど。ただ、採用というのは、事業のスピードを上げるという意味もありますけど、自分たちのソフトウェアの品質を上げるためにも必要な手段だったりするので、自社のエンジニアが自分事としていかに採用に貢献できるかというところを考えられるようにするというのは1つ重要かなと思います。

面接の担当とかもしますけど、リファラル採用ですね。前職の同僚で非常に優秀なエンジニアを紹介するとか、もしくは人事部主催でやっている採用イベントに積極的に貢献するとか、そういうのは重要だなと思ったりします。

ただ、採用をがんばっても、早々に技術的負債って改修できないんですよ。なぜなら、人が増えていくということは、事業が成長しているということなので、やらなきゃいけないこと、バックログの成長速度のほうが速いんですよ。なので、やらなきゃいけないことがずっと積まれているという話になるので、チームを大きくしながら、みなさんでもやられているような社内外の勉強会などを通じて、まずは地力をつけておくというのが初期の頃には必要なのかなと思います。

成長期の返済計画

その後、事業が成長する軌道に乗ってくると、事業の成長に必要だからというところにアラインした返済計画を立てていくのがいいかなと思います。

実際われわれもやりましたけど、例えばユーザーがこのぐらい増加する推移になっています。これが近い将来の1年間を予測するとだいたいこうなりますと。こうなったときに、データ量がこうなっているので、パフォーマンスが絶対出ませんということがわかってたら、そのデータベースのチューニングに合わせて、データベースの足回りのところを全部綺麗にしておくとか。事業を成長させるためには「これがあったら無理です」というところに引っ掛けていくっていうのは必要かなと思います。

これでも全部は引っ掛からないと思います。事業成長によって全然関係ない負債とかがあるので、それは改善しきれないんですけど、まずは特定の機能に特化したかたちでやっていくのがいいんじゃないかなと思います。

これも成長期の話なんですけど、性能やセキュリティの要件ってどんどん上がっていくんですね。最初はお客様も少ないですし、セキュリティも、どスタートアップとベンチャーのプロダクトってそこまでは言われなかったりするんです。ただ、大きくなっていくにつれてお客様に求められてくるレベルも上がってくるので、やっぱり事業を進めるためには絶対に必要なやるべきプロジェクトという定義ができると思うんですね。それにしっかりと合わせていってあげるということは重要かなと思っています。

拡大期の返済計画

続きまして、ここからですね。プロダクトが成長して、さらにここから加速していくぞという瞬間が来るわけですね。そのときにやっと開発工数の一定量を技術的負債の返済に充てられるようになってきます。

これはわれわれのケースなんですけど、開発チームが大きくなってきて、これまで技術的な負債を良しとしながら作りこむとか、事業の成長にフックできたものだけを直すとか、要するに事業にコミットしてきたチームだからこそある種の信頼貯金が貯まっていて、会社組織からも「そんなに君たちがこれをやるべきということであれば、それはやるべきだよね」と言えるようなところまでがんばる必要があるんじゃないかなと思っています。

さらに事業は右肩上がりに成長していくので、そこに合わせて一定の開発工数をまずは技術的負債の返済に充てるのがいいかなと思います。

この頃になるとチームも大きくなってきているので、それこそ「辞めたくなる」みたいな話もありましたけど、初期の頃って、社内のエンジニアのエンゲージメントというか、会社に対する愛着とかコミットメントといったものは、どベンチャーに入るぐらいの人ですから「人生捧げます！」みたいな人が多いわけですよ。ただ、一定の規模になってくると、そういう人ばかりが集まらないわけで、そうでない人も心地よく社内で開発の生産性を上げてもらうことをして、モチベーションを上げる。

エンジニアを1人採用するのにかかるコストって、めちゃくちゃかかるんです。それを考えたら、「この工数を払ったほうが安いじゃん」みたいな話も当然成立するわけで、そういう感じで向上をしていったりしますね。

あとは、離職率の低下や外部露出による技術ブランドの向上とかに引っ掛けています。ちなみに、僕らはいくつかのパターンで技術的負債の返済をしていますけど、前半で話したことって、プロジェクトの中で回していくんですね。

一方で、これはプロジェクトというよりも、ちょっとした隙間時間とか、1週間に1日分だけ使うとか、そんなことを今もやっているんですけど、だいたい全体の工数の5パーセントぐらいですね。5パーセントでもけっこうそれなりで、エンジニアが150人ぐらいいるので、150人の5パーセントってけっこうなボリュームになるんですけど、それぐらいの感じでいいと思います。20パーセントとか30パーセントも使う必要はないかなと思いますね。

経営判断によるリアーキテクチャ

あと、これはタイミングはあまり関係ないですけど、経営判断によるリアーキテクチャがあるかなと思っています。

先ほどのメドピアさんの例でいうと、たぶん「Railsに置き換える」とかはまさにこれに相当するんだろうなと思うんですね。これはもう事業の成長の話なので、エンジニア職にはあまり当てはまらないというか、現場主導ではなかなか話を持っていけないし、福村さんだから判断できたことなんだろうなと思うので、そういう経営がいる会社はいいよねという話なんですけど、そんなことはあるとは思います。

ということで、ついこの間たまたま私のCTO仲間に「Sansanって技術的負債の返済に全部でどのぐらい工数をかけてるの？」ということを聞かれて答えたんですけど、例えば「プロジェクトベースで技術的負債を一緒に返しちゃおう」というのがたぶん全体工数の7、8パーセントぐらい。各プロジェクトのそのぐらいの工数がこれに引っ掛けていると思います。

なので、実はちゃっかり新規開発のなかで回してるというのがそのぐらいあります。先ほど言ったこういうやつ（「組織的返済計画」のスライド）が5パーセントぐらいですかね。

あとは、うちの場合だと、基盤チームやアーキテクトチームみたいなところができて、そこはもう本当にアーキテクチャレベルで直さなきゃいけないもの。とくに、セキュリティとか性能とかは、今後要求レベルがガンガン上がっていくのがわかっているので、それを専任で直していくとか、レベルを上げていくというチームがあります。そこは人数比で考えるとだいたい全体の5パーセントから10パーセントなので、たぶん僕らは技術的負債の返済にトータルでは常時15～20パーセントぐらい時間を使っていることになるんだと思います。

この内訳はけっこういろいろあって、「説明の仕方もぜんぜん違うよね」「事業の状態によっても変わるよね」とか必ずあると思います。なので、そういう考え方というか、一定ロジカルに考えれば、あまり説明がつかないことってないですし、逆にそう考えても説明がつかないものって、たぶんやるべきじゃないんですよ。意味がないはず。そこはこういう考え方をしてもいいんじゃないかなと思います。

私も採用をがんばりたいので、宣伝をします。当社のテックブログですね。僕は編集長をやっているんですけど、このPVをいかに伸ばすか。この半年で3倍にしないといけないというのが僕のミッションなので……みなさん今このQRを撮るチャンスですよ。

（会場笑）

これを撮って、応募していただくといいかなと思います。昨日の上場にあわせてきっと訪問してくれる方がいるんじゃないかと思ってですね。（スライド内の写真を指して）僕とうちのVPoEなんですけど、それの対談記事みたいなのをここぞとばかりに載せてみたりしています。ぜひご覧いただければなと思います。

はい、以上です。ありがとうございます。

（会場拍手）