組織一丸で実践する、技術的負債の解消に向けたカケハシの取り組み

【A-5】20%ルールに頼らない: 技術的負債を解消する組織的な取り組み

　技術的負債を解消しなければまずいと思いながらも、機能開発が優先されてしまい、開発効率が下がっている──。こんな状況に陥っている開発現場は少なくない。医薬局業務のパフォーマンス向上や薬品発注・管理の最適化のためのソリューションなど、医療の基盤となるプロダクトを提供している創業7年目のカケハシでも、技術的負債が蓄積。それらをどういう方法で解消しようと考えているのか。現在進行形で技術的負債の解消に取り組んでいる施策を、VP of Engineeringの湯前慶大氏が紹介した。

2年前にリリースした「Musubi AI在庫管理」が抱える技術的負債

　「技術的負債の解消より機能開発の方が優先度は高い」「経営者やプロダクトマネージャー（PdM）から技術的負債について理解されづらい」「技術的負債の解消に気乗りがしない」……。このように思ったことのある開発者は少なくないだろう。技術的負債を解消しなければと思うものの、銀の弾丸などないというのが現状だ。

　2016年に設立されたカケハシは「明日の医療の基盤となる、エコシステムの実現」というビジョンを掲げ、電子薬歴・服薬指導システム「Musubi」、医薬品発注・管理システム「Musubi AI在庫管理」、医薬品二次流通サービス「Pharmarket」、おくすり連絡帳アプリ「Pocket Musubi」、薬局データプラットフォーム「Musubi Insight」という5つのプロダクト・サービスを提供している。

　この5つのプロダクト・サービスの中で、湯前氏が技術的負債の解消に取り組む事例として取り上げたのが、Musubi AI在庫管理に携わっているチーム。Musubi AI在庫管理は薬局向けのプロダクトであり、「AIが需要や今後の在庫量を予測し、さらに予測在庫量が安全在庫量を下回るタイミングを予測することで、在庫管理を適正に保つことができるようになる。従来までの人に頼った在庫管理、残薬問題、それに伴う非効率な運送という問題を解消できる」と湯前氏は説明する。

Musubi AI在庫管理で解決できる3つの問題

　Musubi AI在庫管理はリリースして約2年だが、「まだまだ機能拡張をしていきたいが、開発がうまくいかない状況にあった」と湯前氏は言う。

「機能拡張ができない」課題に対して取り得る手段とは

　そこで湯前氏は、PdMやエンジニアにヒアリングを実施。するとPdMからは「以前と比較して機能リリースが遅くなっている気がする」、エンジニアからは「3カ月前に入社したが、こんなにコードを把握できないのは初めて」「機能を追加するとバグを組み込んでしまいそうで、コードを触るのが怖い」という声が上がり、「感覚的に開発効率に課題がありそうということがわかった」（湯前氏）という。

株式会社カケハシ Pharma Division／VP of Engineering 湯前慶大氏

　カケハシでは開発リードタイムやレビュー状況の可視化ツール「Findy Team+」を導入しており、確認するとマージまでの平均時間は延びていた。

　そんな状況のなか、機能拡張のための時間を確保するにはどうすればよいか。「取り得る手段は3つある」と湯前氏。

　第一が追加機能を限りなく削ること。Musubi AI在庫管理は中小規模の薬局経営法人向けのプロダクトとして開発されたものだが、カケハシではエンタープライズ法人向けにも展開していくことを計画している。湯前氏は「エンタープライズ向けに提供するには機能が足りない」として、追加機能を削るのは現実的ではないと判断したという。

　第二の手段が開発効率を上げること。第三の手段が人を増やすことである。この2つの手段については「理想的には開発効率を上げてから人を増やすという対処をしていきたい。だが現実には採用や育成に時間がかかるので、同時並行で進めていくことが多いのでは」と湯前氏は指摘する。つまり機能追加の時間を作るカギは、開発効率の向上にあるという。

　開発効率は生産性と対で語られることが多い。生産性と一口に言っても、「大きく3つある」と湯前氏は言う。それは「仕事量の生産性」「期待付加価値の生産性」「実現付加価値の生産性」だ。

生産性とは

　最終的な目標は実現付加価値の生産性を向上させることだが、それを実現するには、仕事量の生産性の向上が不可欠である。そこで湯前氏は、仕事量の生産性に着目し、開発効率の改善に取り組むことになった。

　とはいえ、これまでチームとして開発効率の向上に対して何もしていないわけではなかった。「チームの取り決めとして、20％は改善活動に時間を割くことになっていた」と湯前氏は明かす。だが実際には開発効率に影響が出るぐらい、技術的負債は溜まっていた。

　湯前氏はその例として「テストが不十分なので変更が怖い」「テストを拡充するために、そもそものリファクタリングをやりたい」「E2Eが巨大なメソッドになっていて、何をテストしているかわかりづらい」「シンボリックリンクが多用されていて、読解に時間がかかる」などの状況を挙げる。