SHIBUYAにて「CTOが考える、チームで向き合う技術的負債との付き合い方」が開催されました。メドピア・SansanのCTOが、自社における技術的負債といかにして向き合ってきたか、その経緯と取り組みを語りました。(※当初登壇予定だったアイスタイルCTO竹澤氏は体調不良により欠席)。プレゼンテーション「技術で創る事業成長」に登壇したのは、Sansan株式会社CTOの藤倉成太氏。CTOSansanのミッションとプロダクト藤倉成太氏:よろしくお願いいたします。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の上に乗せてもクラウドネイティブなアーキテクチャにならないんですね。PostgreSQLなんです。PostgreSQLは何が一番いいかって言ったら、僕らはコードからコンパイルしてEC2の上で動かしているんですよね。ブロックサイズとかを調整して、パフォーマンスを最大にしたかったからなんですけど。これが開発当初、12年前にAWSがあってRDSがあったら、もしかしたら違うことになっていたかもしれないし、結果同じだったかもしれないですけど、そういうことってあるので。オンプレだとRDSを選択しないので、「別にソースからビルドしようが、普通にパッケージを落としてこようが大差なくね?」っていうので「速いほうがいいじゃん!」って言って、ビルドのパラメータを変えてゴリゴリチューニングするってことをやっていたんです。返済計画によくある失敗あと、よく質問があるんじゃないかと思うんですけど、「この技術的負債をどうやって返しましょう」と。「どうやって説明したらいいですかね?」みたいなことをたまに聞かれるんですね。実際、僕が自分のメンバーに言われたこともなくはなかったんですけど、「この設計、よくない」って。改善しましょうよ」って言われても、僕「うん」とやっぱり言えないんですよね。「そんなものは趣味じゃん」って思うわけですよ。これは福村さんも仰っていた通り、人によって感じ方が違うわけですよね。同じコードを見ても、他の人が「まあまあ、しょうがないじゃないですか。別に大丈夫ですよ」って言う人もいれば、「これはもう負債でしょ」って言う人がいるわけです。僕はこういうアプローチはよくないなと思っています。エンジニアによる開発って、大切な時間を使ってやる営みなわけなんですけど、これはもう投資行為じゃないですか。「この時間を何に使いますか。どんな価値のある行動に使いますか」という話なので、意味のないところにお金を使ってもらいたくないわけですね。このリターンが、定量的ないし客観的事実......これは定量じゃなくてもいいと思いますけど、それに基づいた目的や結果の測定なんかもできるといいなと思ったりします。先ほども言いましたけど、現在ベストプラクティスで何かを改善したとしても、それはそのまま放っておいたら数年後にはそのまま負債になるので、今お金をかけて将来の負債を作るっていう行為なんですね。その営みに経済的価値があるとは僕は思えないので、「OK」とは言わないですね。前提となるリソースを確保するじゃあそれをどうやって返済するかって話なんですけど、われわれみたいな会社は、もうリソースがないと担保できないんですよ。先ほども言ったように、3人で事業の開発をしていたら負債なんか返せないですよ。