SHIBUYAにて「CTOが考える、チームで向き合う技術的負債との付き合い方」が開催されました。メドピア・SansanのCTOが、自社における技術的負債といかにして向き合ってきたか、その経緯と取り組みを語りました。(※当初登壇予定だったアイスタイルCTO竹澤氏は体調不良により欠席)。公開Q&Aには、メドピア株式会社執行役員のCTO福村彰展氏と、Sansan株式会社CTOの藤倉成太氏が登場。会場からの質問に回答します。CTO技術的負債を返す重要性をどう説明するか司会者:お待たせしました。Q&Aなんですけど、最初に、みなさん申し込みいただいたときに質問をいくつかいただいていたと思うので、そのなかで質問が多かったものを私のほうで5つぐらい取り上げさせていただいております。そのあと、会場のみなさんから質問を募集して、ディスカッションのようなかたちで進められればと思っておりますので、ぜひよろしくお願いします。「技術的負債の返済のストーリーを、関係各所にどうやって説明をすればいいでしょうか?」というご質問が一番多くてですね。それが経営陣に対してであったり、開発組織以外の方々に対して、あとは上司に対して「プロジェクト化させたいんだけど、どうやって説得したらいいんでしょうか?」とか。あとは社内の人に対して説明していくといったときに「どうやって納得させて、ちゃんと効果を示せばいいのか」という質問が多かったです。ちなみにこれを質問してくれた方、いらっしゃいますか?(会場挙手)司会者:え、嘘。あ、いらっしゃいました。ありがとうございます。伺っていければと思います。氏(以下、藤倉):はい。これは僕が先ほどお話ししたなかにもありましたけど、やっぱり事業の成長に必要なものにキチンと引っ掛けて、伝えていくストーリーやシナリオを書いていくことだと思います。逆の言い方をすると、「もしそれで説明がつかないんだったら、それはやるべきじゃないんだ」と僕は思っています。氏(以下、福村):鋭い感じですね。僕の場合は、先ほども申し上げた通り、PHPの独自フレームワークをメンテしていたというところがあったので、やりたくてもできないこと。あとはRailsじゃなくても、当時はPythonとかを並べて検証したんですけど、OSSのフレームワークを採用することで得られるメリットを整理して、そこから説明をした記憶があります。あとは、先ほども言いましたけど、CI回りですね。元CTOが作ってくれた独自フレームワークではテスト回りの機能があまり無かったので、そこが僕らの希望としてはかなりありました。「Rails入れてテスト書きたい!」そんな感じで説明していました。「テストを導入できたら、こんなメリットあるよ!」という感じでいきましたね。何か藤倉さんからご質問とかは......。藤倉:今の福村さんが仰っていたやつは、僕はまさにその通りだなと思ったんですけど。僕が同じような立場だったら、そもそも品質が上がらない......もちろんその状態ってエンジニアのみなさんはがんばってたんでしょうけど、それでもやっぱり障害みたいなものとか、インシデントが発生する。採用を強化しないといけないのに、PHPの独自フレームワークだとそもそも採用ができない。いう経営課題に引っ掛けて説明がつくよねっていう話ですもんね。レベルによって違うと思うんですよね。説明する相手も違いますし、説明する術も違うと思うんですけど、福村さんぐらいのレベルであれば当然経営としての説明をされるでしょうし、現場の方だったらマネージャーとか部長さんに対して、という目線の違いとかがあるんでしょうけど。やって説得してますかっていう質問には答えてないですけどね(笑)。「すればいいじゃん」みたいなことになってしまっているので。以前にいた人が作ってくれたコードを貶すのは違う司会者:もしくは、どなたかご質問いただいたかと思うんですけど、どうですか?質問者1:僕は開発の部長をやっていまして、今まさに成長期で、どちらかと言うと売り上げが上がるような開発をどんどんやっていきたいというところで、事業部から話はあります。いえ、メンバーのモチベーション的には「こんなクソコードをメンテナンスしたくない」という話もあり、そのあたりのバランスをとっている最中なんですけど、やっぱり最終的にはどこかで綺麗にしたい。開発の効率も考えたいし、やっぱり売り上げも上げたいし、メンバーのモチベーションも改善していきたいと。悩んでいる最中であります。そのあたりを本部にうまく説明ができるのかどうか。単純に各メンバーに修正をかければいいやというところで、結局自己満足の部分が、どうしてもお話を聞いててすごく身に染みたので、そのあたりの部分で、経営陣に向けても説明ができる方法がすごく気になりますね。藤倉:今のお話で、僕はSansanという会社で割と社歴が長いほうなんですね。初期のコード、当然僕が入る前のコードもあったのですべてではないですが、自分が関与してきたコードはそれなりの量があって。それはほぼ残ってないですけど、最近ジョインしたメンバーが、12年前のコードを見たら「これ、何でしたっけ?」ってなるじゃないですか。今、仰っていましたけど、以前にいた人が作ってくれたコードを貶すのは、僕は絶対に違うと思っていて。そのサービスプロダクトの礎を作ったのは、絶対にそのコードで、それを「あんたはそのタイミングにいなかったから作ってないじゃん」って思うんですね。そこは、僕はマネージャーとして絶対に言わせないというのはあります。前に進みたいというのは正しいので、そこを敬った状態で、「それを綺麗にさせていくにはどうしたらいいでしょうか」みたいなストーリーのほうが、メンタルとしては良い状態だと思いますけどね。質問者1:ありがとうございます。福村:ちょっとフェーズは違うかもしれないんですけど、僕らの会社では、今もPHPとRubyの両輪なんですけど、Rubyで開発し始めたフェーズは、当然同じような機能で違う会社と連携したいということとか、やっぱり同じようにPHPでコードを書いたほうが圧倒的に速いという状態が、半年から1年はあったんですね。そのタイミングで「じゃあPHPで作らない」というわけにもいかないんですね。そこで売り上げが出るので。それはそれで続けられる時期はあったんですが、Rubyの開発の知見が溜まってきて、けっこう低工数で置き換えられるんじゃないかなというタイミングでRubyに置き換えるというのをメドピアではやりましたね。その機能はそのタイミングで、次の案件からRuby化されてRubyで書かれるっていう......。僕の場合はけっこうタイミングを計って、リソースを確保できそうな体制が取れそうだったらそっちで作って、という感じで舵を切りますね。質問者1:ありがとうございます。技術的負債解消と他の案件とのバランス司会者:ありがとうございます。続きの質問にいきたいと思います。次にあったのが「他の案件とのバランスをどう取りながら進めるべきでしょうか?」。これはちょっと難しいなと思うんですけど、いただいた質問としては、機能改善とか機能追加のチームを作って、技術的負債を解消するチームを作ったりとか、「そもそもチームを分けるべきでしょうか?」ということとか、「負債案件に掛ける工数は全体の中のどれくらいの工数を掛ければよいでしょうか?」とか。さっきの藤倉さんのお話では、いろいろ含めると全体で2、30パーセントぐらいというお話があったかなと思うんですけど、そういうご質問がありました。