開発チームが直面した「見積もりバカでかい事件」
カケハシでは技術的負債を解消するために何をやったのか。まず検討したのが100％の時間を使えるようにうまくチームを構成すること。20％の時間では改善できる内容には限界があったからだ。「例えば7人チームであれば、2人が技術的負債に100％取り組み、残りの5人が機能改修に取り組むという方法です」（湯前氏）
だが、このチーム分割の方法は「良くなかった」と湯前氏は振り返る。ドメイン知識に偏りがあるので、一部の人で進めるのには限界があっただけではない。「どこをリファクタリング・リアーキテクチャするかについては、チーム全体で細かなすり合わせが必要になる。チーム分割すると、そのような情報が滞ってしまうことになった」と湯前氏は振り返る。
そもそも技術的負債はチームの課題である。結果的に特定の人が解決するにしても、考え方や解決のやり方などは、チーム全体で取り組むべきものだ。「特定のチームが解決する方針は取りやめました」（湯前氏）
課題はあるのはわかるが、技術的負債にどれだけ時間的リソースを使って取り組むべきかについて、誰も自信を持って言えない状態が続き、意思決定されないまま2カ月が経った頃、「ある事件が起きた」と湯前氏は続ける。
それが「見積もりバカでかい事件」である。見積もりバカでかい事件とは、概算見積もりによる開発期間と、ベロシティから算出した開発期間を比べると、後者が3倍になったという事象だ。
もちろん見積もりは必ずしも正確な期間を算出されるわけではないが、この状況に経営メンバーもプロダクトオーナーもスクラムマスターも頭を抱えてしまった。「こういうことが分かったのは、ちゃんと見積もりをしていたからで、別に悪いことではない。まずは落ち着いて、この課題についてちゃんと向き合っていこうという話をしました」（湯前氏）
開発効率を上げるためには、技術的負債の解消がポイントとなる。エンジニアは「工数さえ確保できればやる」というスタンスだったが、技術的負債に向き合うには、3カ月から半年ぐらいはかかってしまう。それだけの長い時間、技術的負債の解消に工数をかけるのは、20％ルールを策定しているカケハシで、経営者やPdMが技術的負債の解消することの大事さを理解しているとも言える。それでも「納得してもらうのは難しいことだと改めて感じた」と湯前氏は話す。
というのも技術的負債の解消の効果は、定量的に示すことが難しいからだ。だからこそ湯前氏は「技術的負債の解消を提案するエンジニアリングマネージャー（EM）やエンジニアが覚悟を示すことは大事になる」と指摘する。技術的負債の解消に取り組むことは、開発を遅延させることになり、顧客とのコミュニケーションをする経営者やPdMだけが身を削る状態になってしまう。
