採用をがんばるしかないです。「採用をどうやってがんばるか」ということは、いろいろ後で話をするんですけど。採用というのは、事業のスピードを上げるという意味もありますけど、自分たちのソフトウェアの品質を上げるためにも必要な手段だったりするので、自社のエンジニアが自分事としていかに採用に貢献できるかというところを考えられるようにするというのは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なんですけど、それの対談記事みたいなのをここぞとばかりに載せてみたりしています。ご覧いただければなと思います。ありがとうございます。PLAYに関する記事をまとめています。PLAYに関する新着記事が公開された際に、通知を受け取ることができます。