チームを分けるべきかということに関しては、分けられるなら分けたほうがいい。だいたい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とかに書いてもらうとか。いったかたちで、メンバーに新しい技術のキャッチアップをしてもらって、そこから僕のほうも理解する。それで、今どういう新しいものがあるのかを社内で共有するかたちにしているんですが、藤倉さんとけっこう似ていて、それが使えるかどうかというのはけっこう心配なんですね。ライブラリレベルだったらあまり慎重にはならないですけど、アーキテクトレベルのものと言語レベルのものは、やっぱり採用に関わってくるので、そこはけっこう慎重にしています。Nativeをやめて、KotlinとSwiftの公式のほうで継続的に運営していくので「できないことがでてきたときのコストでかいよね」とか。いうのはメリットやデメリットをメンバー間で話して、最後に僕が決めるという感じでやっています。技術的負債の返済をやりすぎてしまわないために司会者:ありがとうございます。予想外に時間が押してきちゃいまして、すみません。会場の方からご質問を受けられればと思います。ご質問がある方、ぜひ手を挙げていただいてもよろしいですか?質問者2:技術負債を返済できるメンバーが揃っていると、「やりすぎてしまわないか」という懸念が個人的にあって、そうなることはほとんどないと思うんですけど、そうならないためにバランス感覚をどうしているかとか、仕組み化していることがあれば聞きたいなと思います。福村:返済をやりすぎるパターンとかですかね?質問者2:負債返済に時間をかけすぎて、ビジネスのほうも機能追加が進まないとか。「1ヶ月ずっと負債返済していました」みたいなことに陥ったりしないかなとか。福村:それはしっかりマネジメントしないとダメだと思いますね。質問者2:さっきみたいに理屈を付ければ、「なるほどそうね」ってなりがちだと思うんですよね。1ヶ月丸ごとは言い過ぎかもしれないですけど、1週間の中で5パーセントぐらいが丸1日使ってしまう日があったりとか、人によっては起きやすくなってしまうのかなと。福村:プロジェクト管理とか、そっちのほうになってくると思うんですけど、あくまで事業会社の場合は、事業を伸ばすのが目的だと思うので、その技術返済によって事業が伸びているのであれば説明がつきますし、伸びないのにやっているんだったら、そういう話をしてレコメンドをしていかないとダメかなと思います。放置はよくないと思うので、そういうことがわからない人には、それがわかるようにディレクションするのがいいかなと思います。藤倉:あと、「本当は5パーセントぐらいしか使ってほしくなかったのに」というのも、単純に見積もりの話ですよね。「5パーセントと言ったら、5パーセントの見積もり通りにやってよ」という話。それが増えちゃったらそれは「見積もりの精度が低いね」という話しかないので、やっぱりマネジメントと育成ということなのかなと思いますね。そもそもプルリクとかもメドピアさんと一緒ですけど、「なんでこのプルリクを立てているのか」というのは書くようにしていますし、それを見て「それリファクタしすぎでしょ」となったら総ツッコミが入るので、そんなことにはならない。ボコボコにされるって感じですかね。質問者2:はい、ありがとうございます。ありがとうございます。