2年前にリリースした「Musubi AI在庫管理」が抱える技術的負債
「技術的負債の解消より機能開発の方が優先度は高い」「経営者やプロダクトマネージャー（PdM）から技術的負債について理解されづらい」「技術的負債の解消に気乗りがしない」……。このように思ったことのある開発者は少なくないだろう。技術的負債を解消しなければと思うものの、銀の弾丸などないというのが現状だ。
2016年に設立されたカケハシは「明日の医療の基盤となる、エコシステムの実現」というビジョンを掲げ、電子薬歴・服薬指導システム「Musubi」、医薬品発注・管理システム「Musubi AI在庫管理」、医薬品二次流通サービス「Pharmarket」、おくすり連絡帳アプリ「Pocket Musubi」、薬局データプラットフォーム「Musubi Insight」という5つのプロダクト・サービスを提供している。
この5つのプロダクト・サービスの中で、湯前氏が技術的負債の解消に取り組む事例として取り上げたのが、Musubi AI在庫管理に携わっているチーム。Musubi AI在庫管理は薬局向けのプロダクトであり、「AIが需要や今後の在庫量を予測し、さらに予測在庫量が安全在庫量を下回るタイミングを予測することで、在庫管理を適正に保つことができるようになる。従来までの人に頼った在庫管理、残薬問題、それに伴う非効率な運送という問題を解消できる」と湯前氏は説明する。
Musubi AI在庫管理はリリースして約2年だが、「まだまだ機能拡張をしていきたいが、開発がうまくいかない状況にあった」と湯前氏は言う。
「機能拡張ができない」課題に対して取り得る手段とは
そこで湯前氏は、PdMやエンジニアにヒアリングを実施。するとPdMからは「以前と比較して機能リリースが遅くなっている気がする」、エンジニアからは「3カ月前に入社したが、こんなにコードを把握できないのは初めて」「機能を追加するとバグを組み込んでしまいそうで、コードを触るのが怖い」という声が上がり、「感覚的に開発効率に課題がありそうということがわかった」（湯前氏）という。
カケハシでは開発リードタイムやレビュー状況の可視化ツール「Findy Team+」を導入しており、確認するとマージまでの平均時間は延びていた。
そんな状況のなか、機能拡張のための時間を確保するにはどうすればよいか。「取り得る手段は3つある」と湯前氏。
第一が追加機能を限りなく削ること。Musubi AI在庫管理は中小規模の薬局経営法人向けのプロダクトとして開発されたものだが、カケハシではエンタープライズ法人向けにも展開していくことを計画している。湯前氏は「エンタープライズ向けに提供するには機能が足りない」として、追加機能を削るのは現実的ではないと判断したという。
第二の手段が開発効率を上げること。第三の手段が人を増やすことである。この2つの手段については「理想的には開発効率を上げてから人を増やすという対処をしていきたい。だが現実には採用や育成に時間がかかるので、同時並行で進めていくことが多いのでは」と湯前氏は指摘する。つまり機能追加の時間を作るカギは、開発効率の向上にあるという。
開発効率は生産性と対で語られることが多い。生産性と一口に言っても、「大きく3つある」と湯前氏は言う。それは「仕事量の生産性」「期待付加価値の生産性」「実現付加価値の生産性」だ。
最終的な目標は実現付加価値の生産性を向上させることだが、それを実現するには、仕事量の生産性の向上が不可欠である。そこで湯前氏は、仕事量の生産性に着目し、開発効率の改善に取り組むことになった。
とはいえ、これまでチームとして開発効率の向上に対して何もしていないわけではなかった。「チームの取り決めとして、20％は改善活動に時間を割くことになっていた」と湯前氏は明かす。だが実際には開発効率に影響が出るぐらい、技術的負債は溜まっていた。
湯前氏はその例として「テストが不十分なので変更が怖い」「テストを拡充するために、そもそものリファクタリングをやりたい」「E2Eが巨大なメソッドになっていて、何をテストしているかわかりづらい」「シンボリックリンクが多用されていて、読解に時間がかかる」などの状況を挙げる。
開発チームが直面した「見積もりバカでかい事件」
カケハシでは技術的負債を解消するために何をやったのか。まず検討したのが100％の時間を使えるようにうまくチームを構成すること。20％の時間では改善できる内容には限界があったからだ。「例えば7人チームであれば、2人が技術的負債に100％取り組み、残りの5人が機能改修に取り組むという方法です」（湯前氏）
だが、このチーム分割の方法は「良くなかった」と湯前氏は振り返る。ドメイン知識に偏りがあるので、一部の人で進めるのには限界があっただけではない。「どこをリファクタリング・リアーキテクチャするかについては、チーム全体で細かなすり合わせが必要になる。チーム分割すると、そのような情報が滞ってしまうことになった」と湯前氏は振り返る。
そもそも技術的負債はチームの課題である。結果的に特定の人が解決するにしても、考え方や解決のやり方などは、チーム全体で取り組むべきものだ。「特定のチームが解決する方針は取りやめました」（湯前氏）
課題はあるのはわかるが、技術的負債にどれだけ時間的リソースを使って取り組むべきかについて、誰も自信を持って言えない状態が続き、意思決定されないまま2カ月が経った頃、「ある事件が起きた」と湯前氏は続ける。
それが「見積もりバカでかい事件」である。見積もりバカでかい事件とは、概算見積もりによる開発期間と、ベロシティから算出した開発期間を比べると、後者が3倍になったという事象だ。
もちろん見積もりは必ずしも正確な期間を算出されるわけではないが、この状況に経営メンバーもプロダクトオーナーもスクラムマスターも頭を抱えてしまった。「こういうことが分かったのは、ちゃんと見積もりをしていたからで、別に悪いことではない。まずは落ち着いて、この課題についてちゃんと向き合っていこうという話をしました」（湯前氏）
開発効率を上げるためには、技術的負債の解消がポイントとなる。エンジニアは「工数さえ確保できればやる」というスタンスだったが、技術的負債に向き合うには、3カ月から半年ぐらいはかかってしまう。それだけの長い時間、技術的負債の解消に工数をかけるのは、20％ルールを策定しているカケハシで、経営者やPdMが技術的負債の解消することの大事さを理解しているとも言える。それでも「納得してもらうのは難しいことだと改めて感じた」と湯前氏は話す。
というのも技術的負債の解消の効果は、定量的に示すことが難しいからだ。だからこそ湯前氏は「技術的負債の解消を提案するエンジニアリングマネージャー（EM）やエンジニアが覚悟を示すことは大事になる」と指摘する。技術的負債の解消に取り組むことは、開発を遅延させることになり、顧客とのコミュニケーションをする経営者やPdMだけが身を削る状態になってしまう。
組織的に取り組む「技術的負債」の解消
そこで湯前氏は、短期間で効果が出やすいが、EMやエンジニアが身を削る必要のある課題解決施策の提案をした。短期間の課題解決施策として開発チームが行ったのが、「開発プロセスの改善」と「会議体の整理」だ。
開発プロセスの改善では、エンジニアがやることと、開発ディレクター（カケハシではスクラムマスターを開発ディレクターと呼んでいる）がやることを図のように分けて整理。「開発ディレクターが開発プロセスへの働きかけを大きくすることで、エンジニアの開発時間を最大限取れるようになり、チームで一丸となって開発に取り組める形にしました」（湯前氏）
もう一つの施策である会議体の整理では、短期的に会議やスクラムイベントの削減を行ったという。チームのコミュニケーションを活性化させる施策は非常に大事だが、短期的に開発時間を確保するため、勉強会や雑談のために確保している時間など、チームのコミュニケーションを期間限定で削減したという。「長期的にはマイナスになってしまうので、あくまで7月末までとし、8月以降は復帰することになっている」（湯前氏）
そのほかにも、スクラムイベントや会議体を削減したことで、「全体で約10％の時間を捻出できた」と湯前氏は語る。
このようにEMやエンジニアが身を削る提案をすることで、中長期的な対策として技術負債の解消を経営層やPdMと議論ができるようになった。「ゴールをどうするのか、何をやるのか、どのくらいの期間とリソースを使うのかなどについて、中長期的な対策のイメージを図に表し、議論をしたことで、理解してもらえたと思います」（湯前氏）
PdMや経営層との話ができ、リソースも確保できた。次に見積もりをすべくエンジニアチーム内での技術的負債解消の方針のすり合わせを行うことにしたが、「なぜやるのか」「何が今課題なのか」「何が理想の状態なのか」という認識がチーム全体で合っていないことが明らかになった。チーム内での認識をすり合わせるためには、1つのホワイトボードを見ながら長めに時間をかけ、深い議論をするのが得策である。だがカケハシの社員の働き方は全員リモートワーク。そこで全国から東京都中央区東銀座にあるオフィスに集まり、オフラインでの議論を行った。「チーム内での認識は大方揃い、あとは進めるだけの段階。今、まさに技術的負債の解消に取り組んでいるところです」（湯前氏）
カケハシではこの取り組みを5月頃から開始。まだ3カ月弱だが、経営層から「少しずつ良くなってきている」という声をかけられたという。
湯前氏は最後に「カケハシでの取り組みが皆さまの参考になれば幸いです」と語り、セッションを締めた。
