技術的負債を返す重要性をどう説明するか
司会者：お待たせしました。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パーセントぐらいというお話があったかなと思うんですけど、そういうご質問がありました。ちょっとどうでしょう、福村さん。
福村：そうですね。チームを分けるべきかということに関しては、分けられるなら分けたほうがいい。ただ、だいたい5人とか、そういう感じだと分けられないですよね。なので、分けられるなら分けたほうがいいですが、メドピアも20人超えたぐらいで分けている感じなので、分けられるなら分けたほうがいいです。でもベース的には分けられないほうが多いんじゃないかなと。
技術的負債の案件に掛ける工数は、僕、さっきからPHPからRubyへの置き換えを技術的負債の返済みたいに言ってるんですけど、Rubyで書かれているコードも日々負債化している部分はあると思っていて、ただそのあたりは「じゃあ2割」とかそういう感じでは決めていないんです。
活動において、例えば先ほどのモブプロとかは、隔週で1.5時間とか2時間とか確保しちゃう。そこでリファクタリングをかける。2時間で足りなかったら、今度は3時間でやってみるとか。そういうかたちで負債解消に関してはバランスを取っています。
「開発案件とのバランス」ですよね。やっぱり売り上げとか今後のレバレッジとかをけっこう見ちゃうんですよね。「今これがんばったら、後で楽になるじゃん」というときはけっこう優先度を上げたりしますし、「このタイミングでPHPの同じような案件をRuby化しておかないと、どんどんPHPが量産されちゃう」みたいなときは高めたりとか。
司会者：その判断は福村さんが行っているんですか？ 「今はこっちに力をかけるべきか」みたいな最終判断は。
福村：最終判断は、部長と僕と、あとはリードエンジニアで判断していますね。
司会者：ありがとうございます。ちなみにこの質問「気になっていたよ」という方、いらっしゃいますか？
（会場挙手）
司会者：あれ？ 多かったんですけどね。分かりました！ ありがとうございます。
技術選定はどうやっている？
司会者：「技術選定はどうやって行なっていますか？ 知り合いのCTOの方に相談しているなどあれば、ぜひ教えていただきたいです」というご質問がありました。技術選定について気になっていたという方、いらっしゃいますか？
（会場挙手）
司会者：おおー。今度はいました。ありがとうございます。いかがですかね。
藤倉：これ難しいですね。ちなみに言うと、その「知り合いのCTOに相談して決めていることがあれば」みたいなのは、まったくないです。
これどうやって答えるんだろうな。難しいですけど、既に開発されているというか、運用しながら新規に開発して成長しているようなプロダクトに関しては、ある程度基盤があるので、技術選定と言ったらライブラリの選定とかじゃないですか。そういうのは現場が勝手にやっています。なので僕は、1ミリも関与していないです。
新規とかだと、スクラッチで何か作らないといけないというのは、やっぱりそこでインパクトが決まっていくので、そこは一定の関与はしていたりします。
そのときにどうやって選定していくかは、けっこういろいろなパラメータがあるので一概に言いにくいですけど、「1つの技術として今後伸びていく可能性が極めて高い」とか、「今はもてはやされてるけど、すぐ終わるから知らない」とか、そういうのは僕の感覚も含めて言ったりもします。
あとは、下心としては「このフレームワークを使っておけば採用強いな」とかはもちろんありますし、単純にうちは社内でAWSもGCPもAzureも使ってるんです。というのは、この3つは無くなることは、まずないと思っていますし、それぞれ強みが違いますので、「ちょっとここで手を出しておきたいな」とか、技術的な選択肢を増やしておきたい。社内でも指摘をしておきたいとか。
一概には言えないんですけど、福村さんは何かセオリーというかメソッドを教えていただけると……。
福村：そういうメソッドはあまりないですけど、僕も知り合いのCTOに相談はしないです。ただ、うちのメンバーにはすごい相談をします。
こういうイベントもそうですけど、会社としてメンバーにいっぱい行ってもらうということはしています。なぜかと言うと、例えばこの間AWSサミットがありましたけど、AWSの最新情報とか、けっこう僕のほうでキャッチアップしきれないんですね。
だけど、普段から触ってて、そういうところで発表があると「おもしろい機能があったよ！」っていうキャッチアップをしてもらうので、レポート必須みたいなかたちにはしていないですけど、「行ってきたらインプットした分を僕にアウトプットしてよ」みたいな感じで、社内でesaとかに書いてもらうとか。
そういったかたちで、メンバーに新しい技術のキャッチアップをしてもらって、そこから僕のほうも理解する。それで、今どういう新しいものがあるのかを社内で共有するかたちにしているんですが、藤倉さんとけっこう似ていて、それが使えるかどうかというのはけっこう心配なんですね。
なので、ライブラリレベルだったらあまり慎重にはならないですけど、アーキテクトレベルのものと言語レベルのものは、やっぱり採用に関わってくるので、そこはけっこう慎重にしています。
最近だとVue.jsを入れたりとかTypeScriptを入れたりとか、そういうところは進めていたりするんですけど、過去だと、React Nativeを入れたいって言ったときにメンバーとけっこう話し合って、React Nativeをやめて、KotlinとSwiftの公式のほうで継続的に運営していくので「できないことがでてきたときのコストでかいよね」とか。そういうのはメリットやデメリットをメンバー間で話して、最後に僕が決めるという感じでやっています。
技術的負債の返済をやりすぎてしまわないために
司会者：ありがとうございます。ちょっと予想外に時間が押してきちゃいまして、すみません。会場の方からご質問を受けられればと思います。ご質問がある方、ぜひ手を挙げていただいてもよろしいですか？
質問者2：技術負債を返済できるメンバーが揃っていると、「やりすぎてしまわないか」という懸念が個人的にあって、そうなることはほとんどないと思うんですけど、そうならないためにバランス感覚をどうしているかとか、仕組み化していることがあれば聞きたいなと思います。
福村：返済をやりすぎるパターンとかですかね？
質問者2：負債返済に時間をかけすぎて、ビジネスのほうも機能追加が進まないとか。「1ヶ月ずっと負債返済していました」みたいなことに陥ったりしないかなとか。
福村：それはしっかりマネジメントしないとダメだと思いますね。
質問者2：さっきみたいに理屈を付ければ、「なるほどそうね」ってなりがちだと思うんですよね。1ヶ月丸ごとは言い過ぎかもしれないですけど、1週間の中で5パーセントぐらいが丸1日使ってしまう日があったりとか、人によっては起きやすくなってしまうのかなと。
福村：プロジェクト管理とか、そっちのほうになってくると思うんですけど、あくまで事業会社の場合は、事業を伸ばすのが目的だと思うので、その技術返済によって事業が伸びているのであれば説明がつきますし、伸びないのにやっているんだったら、そういう話をしてレコメンドをしていかないとダメかなと思います。放置はよくないと思うので、そういうことがわからない人には、それがわかるようにディレクションするのがいいかなと思います。
藤倉：あと、「本当は5パーセントぐらいしか使ってほしくなかったのに」というのも、単純に見積もりの話ですよね。「5パーセントと言ったら、5パーセントの見積もり通りにやってよ」という話。それが増えちゃったらそれは「見積もりの精度が低いね」という話しかないので、やっぱりマネジメントと育成ということなのかなと思いますね。
そもそもプルリクとかもメドピアさんと一緒ですけど、「なんでこのプルリクを立てているのか」というのは書くようにしていますし、それを見て「それリファクタしすぎでしょ」となったら総ツッコミが入るので、そんなことにはならない。ボコボコにされるって感じですかね。
質問者2：はい、ありがとうございます。
におうコードへの対処
司会者：大丈夫ですか？ ありがとうございます。他にご質問ある方。お伺いします。
質問者3：私が新しくチームにジョインしたときに、いわゆる「におうコード」だった場合、どう立ち振る舞えばよいのでしょうか？ また、私はフリーランスでやっておりまして、任期が短いことが多く、過去に、前任のエンジニアが「ビジネスのスピードを上げるためにテストコードを書いている時間がない」と経営陣に対して説明をしていて、その方が辞めるときに私が入って、前任者がこう言っていたというかたちで経営陣を説得できなかったことがあります。
藤倉さんと福村さんは、けっこう長い社歴があったということでしたけども、とくに福村さんの場合は途中でCTOになられたという経緯がありまして、PHPの独自フレームワークって聞いたらきな臭いにおいしかしないんですけど、例えばそれはMojaviとかCakeとか、Zend Frameworkではなくて、あえて独自にしたというメリットを前任者が説明していたはずであって、ある意味新任であった福村さんが経営陣に対してどう説明したのかが気になります。
福村：そうですね。言語の選定に関しては、とくにいちゃもんを付けられなかったというか。ただ、「なんでOSSのフレームワークに置き換えるの？」という説明は、すごくしたんですね。なので、どう説明すればいいですかね。テストが不要だって、なんかそういう……。
質問者3：「前任者はこう言っていて、それ以上にわれわれのビジネススピードに貢献してくれたんだけど、なんでお前はテストの工数を取るんだ」と。
福村：なるほど。そういう意味では、負債がけっこう爆発し始めていたという後押しがあって、テストが大事だということは、そこまで苦労せずに納得してくれた感じですね。
質問者3：なるほど。そのあたりを含めてエンジニア文化だと思うんですけど、お二人を目の前にして言うのもあれなんですが、エンジニア文化がない組織に入ってしまったらさっさと逃げろということでしょうか。
福村：いや、エンジニア文化を作っていくっていうのもおもしろいと思います。
（会場笑）
事業を優先するか、負債の返済を優先するか
質問者3：既にお二方はお作りになられているってことでしょうか？
福村：（藤倉氏に向けて）……そうですよね？（笑）
藤倉：たぶん、うちの会社はエンジニアが自主的にいろんなことを議論しながら、自分たちのことを考えて意思決定しながら進むというものになっていて、いわゆるエンジニア文化みたいなものだとは思うんですけど、僕はそれを作ろうと思ったこともなければ、作ったつもりもなくてですね。
僕はあくまでも「事業に貢献するために何をどう考えるかちゃんとロジカルに説明しなさい」としか言ってないんですね。なので、わからないんですけど、例えば今仰っていたように、前任の方が「事業のスピードに追い付くためにはテストコードを書けないです」と、言われたときに、もし前任者の方よりも自分のほうがスキルが高くて同じ時間でテストコードが書けるんだったら書けばいいと思うんですよね。要するに、求められてる事業スピードはそのレベルでも大丈夫ということなので。
ただ、自分のスキルレベルが前任者と同等かそれ以下だ。もしくは、もっともっと事業スピードを上げてくれっていう要請があるんだったら、たぶん僕はテストコードを書かないです。だってそれが事業の要求だから。
ただ、そんなことをしていたらどこかで不具合とか致命的なバグであったりとか出てくるわけですよ。それは「事業を優先したらこうなりましたけど、何か？」って言います。
質問者3：はい、私もそう言います。
（会場笑）
藤倉：僕はそれが大正解だと思いますよ。そのときに経営として「なるほど。事業スピードを優先するとこうなるんだね。じゃあテストコードみたいなものを書こうね」と意思決定をするのか、「出たら直したらいいじゃん」と言うのであれば、僕はそのまま突っ走れるし、別に僕はそこに不快感も違和感も何もないタイプですね。事業を成功させるためにはそれが必要ってことなので。
質問者3：自分はメンバーのメンタルヘルスが崩れるのが見ていられなくなって辞めました。
藤倉：だからそれはあれなんでしょうね。先ほど福村さんが仰っていたように、そもそも事業会社であれば事業を伸ばすのが最優先であって、それが不健全なことじゃないんですよ。むしろ、それよりも何か別のことを優先させることのほうが不健全なので、メンタルのモデルがたぶん間違っているんでしょうね。
それは、事業体とそこにいらっしゃるメンバーが大切にしたいことがアンマッチだったという話なので、文化を作りたいと仰っていたように、まずは文化を作るところから始めないといけないんだろうなとは思ったりしますね。
質問者3：そうなってくると、経営陣の目指すところと従業員が目指すところは絶対と言っていいほどマッチしないと思っていて、結局そのあたりの人間の組織とはどうあるべきなのかという話に結局行き着くのかなと思います。すみません。ちょっと長くなりましたね。
司会者：すみません。このあとの懇親会で……。ラスト、もう1問会場からいただいて、懇親会の準備に移らせていただきますが、もし質問がある方がいれば。
技術的負債の良い積み上げ方
質問者4：はい。返済の話ばっかりだったんですけど、技術的負債は積み上がるものだという前提のもとで、自分の書いたコードが良いコードだったとしても5年後にはクソコードになっちゃうよねと場合に、技術的負債の良い積み上げ方。どう積んでいくと後で返済しやすいかみたいなところで、気を付けていたこととか。
あるいは、こういうふうに技術的負債を積んでおけば後で解消しやすいよねみたいな。そういう気を付けているところがあれば教えていただきたいなと思います。
福村：そうですね。うちの場合は、けっこう僕がいろんなコードを残しちゃっているので、その不平不満を僕が受け止める。
（会場笑）
福村：そういうところですかね。はい。
質問者4：ありがとうございます。
福村：けっこう「なんでこうなってるの？」みたいな感じで言われたら、やっぱり当時の状況とかがあるんですけど、突っぱねる感じではないんですけど、説明は簡素にして、「これからの話をしよう」っていう感じで……。
（会場笑）
福村：未来志向型で。
質問者4：なるほど。
福村：結果、今僕がそのプロジェクトを牽引しているんですけど、そういう感じでやるのがいいんですかね。はい。
藤倉：基本的に僕は、個人的には持論としてドキュメントを残すみたなことは好きではなくて、すべてがソースコードのアーキテクチャで表現されているという世界が好きなんですね。ソースコードレベルで、致し方無いこの実装を、例えば周辺コードと同じマナーでやることに違和感はあるが、1ヶ所だけ別の方式にすることのほうが圧倒的に違和感があるのであれば「それに倣っておきます」って1行コメントが書いてあれば、後から見た人はたぶん納得できると思うんですね。
ただ、アーキテクチャレベルになると、なかなかソースコードだけでは解読できなかったり、将来のアーキテクチャのロードマップってさすがにドキュメントにしないと難しいので、そういうアーキテクチャドキュメントとかは残していいのかなと思います。
それこそメンバーの方のモチベーションとかエンゲージメントとかでいくと、将来のロードマップが引かれていれば、ちょっと安心できるじゃないですか。この暗闇がずっと続くのか、ちょっとしたら光が見えてくるのか、というのはあるので、アーキテクチャで言えるところで言えば、ここで切ってこれぐらいのタイミングでここまでを置き換えていこうというのは書いたりすることはありますかね。
なので、将来の計画と今の負債を意図的に積み上げるんだったら、返済計画も一緒にセットにしてプルリクにも書くとか、そういうことはしたりしますかね。
質問者4：ありがとうございます。
司会者：ありがとうございます！ たぶんみなさんまだまだ質問したいことがあるとは思うのですが、いったんこちらでセッションを終わりとさせていただきます。
お二人に拍手をお願いします。
（会場拍手）
