こんにちは！
株式会社Libryの開発部にてエンジニアをしている長谷川です。
今回は2回目の記事投稿です。
前回はフロントエンドの方向けにVue3.0の記事を書きましたが、今回はもっと抽象的なお話をしようと思います。
エンジニアではない方々でサービスを抱えている企業に勤めている方にも是非眺めてもらえれば嬉しいです。
今回は「技術的負債」についてお話しようと思います。
皆さんも運用開発を経験しているとこんなことありませんか？
「開発が進むにつれて徐々に障害が出る確率が増えてきた」 「開発初期と今とでリリースされる工数がかなり違いがある（増えてきた）」
これは技術的負債がどんどん蓄積することによって起こっているものです。
開発の「生産性」が落ちてきたと思ったらまずはサービスの「技術的負債」を疑ってみてください。
そもそも技術的負債とは
そもそも技術的負債とはなんでしょうか？
一般には、「早さ」を求めて構築されたシステムの構造的課題が、徐々に蓄積し、債務であるかのように開発速度そのものを遅くしていく現象のこと。
これを技術的負債と言われています。
特にこの言葉を使う目的としては、
エンジニアと非エンジニアのコミュニケーションに使われる言葉
として利用されます。
もう少し、想像しやすく表現すると、
システム開発が徐々に困難になっていく理由は、「ジェンガ」のようなものです。
ゲームの初期段階でのジェンガは、簡単にブロックを抜き出したり、積み上げることができます。
この時はゲームはスピーディーに進んでいきます。
ところが、ゲームをしばらく続けると、バランスを取るのが急激に難しくなっていきます。
これは慎重に抜き差ししないと崩れてしまうためです。
様々な要件の変化によって形作られたジェンガは、徐々に不安定に、積み上げるのが難しく時間がかかるようになります。
これが開発が遅くなる現象とよく似ています。
なぜ技術的負債の言葉があるのか
技術的負債は、「エンジニアと非エンジニアのコミュニケーションに使われる言葉」とお伝えしました。
では、なぜコミュニケーションの言葉として生まれたのでしょうか？
よく、技術会社にある現象なのですが、
開発内部を知らない人からすると開発当時や昔はすぐに開発できたのに、「予想外のタイミングで、予想外の形で」開発が進まなくなるという現象が発生します。
はたからみると、同じくらいの機能開発に見えるのになぜか、3年前より開発スピードが遅い。。
これは、サービス内に「技術的負債」が存在するがために、開発スピードが遅くなってしまっているのです。
結局技術的負債で何を言い表したいのか
技術的負債の負債は、「放ってはいけない」「定期的に返済すべきもの」として負債という言葉を使われています。
それなのに負債を返済できず、どんどん負債が膨らんでしまうと取り返しのつかないことになってしまいます。
これは技術的な負債にも言い表せます。
負債が大きくなるにつれて、開発スピードがどんどん落ちていき、ビジネス側にも影響が出てくるほどの状態になってしまいます。
技術的負債は、開発サイドだけではなく、ビジネス全体、組織全体で対処する必要のある負債なのです。
技術的負債をめぐる議論
技術的負債という言葉は、アメリカのコンピュータ技術者であるウォード・カニンガムによって1992年に提唱された概念です。
彼は経験レポートの中で、次のように語っています。
最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。 危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。 技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる
システムの開発を進めるに連れて引き起こされる開発時間の増大という「現象」を巡って、それらを議論するためのコミュニケーションの言葉として広く使われることになりました。
しかし、「技術的負債」という言葉は、会計上も経営指標においても計上されるわけではない空想上の概念にすぎません。
要は、何をもって測定され、どのような返済手段があるのかといった議論も尽くされることなく、広く用いられるようになりました。
その結果、「技術的負債」という言葉の存在で何かを説明したと思い込む人々や、ソフトウェア開発における経営上の問題について関心を抱かない経営者によって、むしろコミュニケーションを断絶する言葉になってしまっているケースがあるように思います。
まとめ
ここまで技術的負債について話してきましたが、Libry開発部としてもサービスの「技術的負債」を問題捉え、返済を積極的に行っております。
具体的には、4月より、
全体の開発工数の30％を「開発改善タスク」を消化する工数 ※ 30％というのは時期によっては20％に修正するなど見直しがはいる可能性はあります。
を設けました。
エンジニアとしても今後の事業の発展のためにも今年は新機能開発と共に技術的負債の解消にもしっかり努めていきたいと思います。
もし、技術的負債の解消にも興味がある人はお話聞いてみませんか？
是非お待ちしております。