「負債がまったくないのは、新しいことに取り組もうとしてないことだ」　後回しにしない技術負債の返し方

更新されていないバージョン、直したい実装…技術的負債にはいろいろある

秋葉誠一氏：よろしくお願いします。「技術的負債を返し続ける取り組み ~ あなたのPHPのバージョンいくつですか？ ~」を発表します。

まず簡単に自己紹介です。名前は秋葉といいます。好きな技術はもちろんPHPです。会社は株式会社ROXXっていうところで「back check」というリファレンスチェックのサービスを開発しています。

趣味はスノーボードとかサバイバルゲームなんですが、アロハシャツ集めるのも趣味で、本当は沖縄に行きたかったんですが、行けなかったのでお気に入りのアロハシャツを着て、今日は気分だけでも沖縄で、テンションを上げていこうと思います。

まず「あなたのPHPは？」ということで、みなさんお使いのPHP、バージョンはいくつでしょうか？　弊社の「back check」は、PHP8を使っています。きちんと7.2からバージョンを上げて、現在は8を使っています。

みなさんご存じでしょうか。PHPのサポート期限ですが、7.2に関してはもうすでに終わっています。7.3に関しても、今年で終了です。あと半年ぐらいしかないです。きちんとバージョンアップはできていますか？

ではバージョンアップをする予定はきちんとありますか？　PHP以外にも更新されていないライブラリやフレームワークがありませんか？　直したい実装はありませんか？　その他もろもろの技術的負債と言われるものに苦しんでいませんか？

技術的負債という言葉を今出しました。『アジャイルサムライ』という本からの引用で、説明を簡単にすると、「手抜き、ハック、重複などなど、開発速度と期日の名の下に、私たちは数々の狼藉をコードベースにコミットしている。技術的負債とは、そうした狼藉が時間と共に積み重なったものだ。

君のコードは、常に何かしらの負債を抱えている。負債がまったくないというのは、新しいことや、これまでとは違うことに取り組もうとしてないってことだ。かつては楽しくて気軽でシンプルだった作業が、辛く困難で複雑なものになって初めて、人は自らが技術的負債を抱えすぎてしまったことに気づくんだ。」

僕は「負債がまったくないというのは新しいことや、これまでとは違うことに取り組もうとしてないってことだ」の部分が個人的にはすごく好きです。技術的負債と言われるものは、さっき述べたほかにもいろいろあると思っています。

例えば更新されない古いバージョンの言語、フレームワーク、ライブラリを使い続ける。サポートされていないものを使い続けてるのも一種の負債かなと思っています。

あと、現実と実装が乖離しているのも負債かなと思います。コードを更新する時に無駄なコストがかかったり、伝えにくい機能ができてしまったり。

ほかにも、非推奨機能を使った実装ですね。言語、フレームワーク、ライブラリの非推奨機能を使うと、バージョンアップの時にすごく苦しみます。あの時は最高だと思った設計、みなさんもあると思います。これがベストだろうと思っても半年経過したら「うーん、ちょっとやめときゃよかったなあ」というのも往々にしてあると思います。

あとですね、過去の自分をしばきたいコード。1年前のコードを見ると「なんで俺こんなコード書いたんだ」みたいなのもけっこうあると思います。僕は非常にあります。いつか直すと思っているあのバグ。いつかは来ません。

技術的負債の説明で、先ほど僕がすごくいいなって思っている一節を紹介しました。「負債がまったくないというのは、新しいことや、これまでとは違うことに取り組もうとしてないってことだ」ということは、プロダクトが生き続ける限りは負債を負い続けるということなんです。負債を負うということは、返済する必要があるということです。我々エンジニアはいつも負債を負いながら、開発を続けるという非常に悲しい職業でございます。

技術課題リファインメントのステップ

こちらの課題に対して弊社の「back check」の開発チームが行っている技術課題リファインメントを紹介したいと思います。

前提条件ですが、「back check」はスクラム開発で開発を行っていて、継続的な開発であることと、スクラムに則った開発であることです。スプリントベロシティがきちんと計測できているかが、活用できる前提条件です。

これが達成できていなくても、ある程度Tipsは使えると思うので、「スクラムじゃないわ」とか言って「ちょっと聞くのやめる」ではなくて、最後まで聞いてもらえると幸いです。

その前に、簡単にリファインメントの説明をします。長いので全部は読まないんですが、実装に入る前にチームでその実装に対して透明度を上げていったり、不明の部分を洗い出したり、チケットを小さくしてより詳細にしていったり、優先順位をつけてどれを先にやったほうがいいのかを決めていったりという、スプリントのいわゆるセレモニーの中の一環の作業です。

これはスクラムの手法なんですが、これを転用して技術課題を解消していこうという取り組みが技術課題リファインメントです。

まず、技術課題リファインメントの「STEP1」は、課題を見つけましょう。自分たちのコード、課題は良くも悪くもいっぱいあると思います。良くないコードを見つけた時とか、なにかバージョンアップの情報があった時とか、DBを正規化したいなとか思った時に、まず自分で手をつけるのではなく、見つけた課題を技術課題バックログというかたちで起票します。ポイントとしては、新機能のバックログとは別に専用のバックログを作ります。

「STEP2」は、技術課題リファインメントです。リファインメントしましょう。内容の詳細化、分割、優先順位を決めて見積もりをしましょう。この時に、一定の誰か、例えば起票した人とかがやるのではなくて、誰がやってもいいように、きちんとここでみんなにこういう課題がありましたと共有します。

優先順位を決めるのは、個人的にすごく大事だと思っています。チームとして今何を大切にしたいか。言語のバージョンアップを上げることに注力するのか、ほかのことに注力するのか、UIを直すことに注力するのか。チームとして何を大切にするかを、きちんと合意形成して決めていくことが大事だと思います。

「STEP3」は実施ですね。スプリントのプランニングの際に、ベロシティポイントを一定の割合で技術課題に割り当てます。ベロシティポイントを簡単に説明すると、ステアのワンスプリントで行うチームが提供できる価値のポイントです。だいたいこれぐらいはできるよねという要領ですね。その中で、一定の割合で技術課題をこれだけやろうとポイントを割り当てます。

ここで大事なのが、新規開発とは別軸の優先順位です。新規開発は、もちろん事業をやるうえで必ず起こりますし、優先順位は高いものが多いと思います。その中で、技術課題はどうしても優先順位が下がっていくので、別軸で優先順位を決めることが大切です。

先ほども言ったんですが、「起票した人間がやる」ではなくて、やる人は誰でもいいんです。「一定の人がやる」ではなく、技術をチーム内に広めていくために誰でもできる状況になるのが理想です。

弊社の場合、だいたいベロシティの10パーセントを割り当てています。プラス、手が空いたら優先的にやるかたちで技術課題を解消しています。

次ですね、これは大事です。繰り返しましょう。継続して習慣化することが大事です。1回だけでは何も変わりません。何回も何回も繰り返していくことで、やっと成果が見えてくる。そういうものだと思います。プロダクトが開発され続ける限りは、負債は溜まっていきます。継続的に、早い段階での負債の返済を僕はおすすめします。

技術課題リファインメントの利点とまとめ

技術課題リファインメントの利点をいくつかお話しします。新規の開発とは別軸の優先順位をつけることによって、後回しが避けられます。負債を可視化して、誰でも見える状況にして、みんなで優先順位をつけられます。

誰か特定の人がいつもやっている、この人がいつもバージョンアップしてくれている、ライブラリを更新してくれているという状況を避けられます。その人がいなくなっても、きちんとみんなで回していくことが重要です。

「いつかやる」というあいまいなものではなくて、仕組みでカバーするのがエンジニアの本質として最も大事なものだと思います。

時間もそろそろなので、まとめていきたいと思います。

継続的に開発するうえで、技術的負債は必ず発生します。それは受け入れる必要があると個人的には思います。負債は早い段階で返済しないと、どんどんつらくなります。まず、負債を可視化することが重要です。新機能の開発とは別軸の優先順位をつけましょう。負債の返済を開発のサイクルに組み込んで習慣化します。あとは継続あるのみで続けていきましょう。

PHPのバージョンを上げるのは、あなたかもしれません。みなさん、がんばってやっていきましょう。

最後に、弊社はROXX開発メンバーを今すごく募集しています。気になる方がいれば、私にDMでもいいですし、「Speaker Deck」に開発の採用資料があるので検索してみてください。

本当は沖縄に行きたかったんですが行けなかったので、来年はリベンジしたいです。ご清聴ありがとうございました。