14
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

LITALICOAdvent Calendar 2022

Day 19

技術的負債への向き合い方(お気持ち編)

Last updated at Posted at 2022-12-20

この記事は『LITALICO Advent Calendar 2022』 19日目の記事です。

はじめまして、LITALICOの@joy04dと申します。
寒さが苦手で布団に包まりながら仕事していたり、続編が絶望視されていたゲームの新作が10年ぶりに発表されてテンションが上がったりして日々を過ごしています(=ω=)

我が家では親族交流の一環として、子供の写真や動画を親族各々の様々な環境から集め、また配信(オンラインからオフラインまで)するシステムを運用しているのですが、そろそろ年末だしこれも見直すか、と考えたところでふとその気持ちをまとめてみたくなったので、この記事を書いてみました。
(このシステムについても、そのうち機会あれば記事にしてみたいと思います)

前置き長くなりましたが、この記事ではシステム開発に携わるものなら誰にとっても身近であり、また切っても切れないテーマである技術的負債について少し語ってみたいと思います。

弊社AdventCalendarでも様々な記事が上がってますので、こちらも良ければ是非御覧くださいm(_ _)m

技術的負債と何か

技術的負債(Technical Debt)とは、wikiの創案者・開発者であり、アジャイルソフトウェア開発宣言の提唱者の1人でもある Ward Cunningham 氏によって生み出された概念です。

その概念の広さと腹落ち感から、様々な形で引用され、また理解されている言葉ですが、元々の捉え方としては、ドメイン知識とその複雑性への向き合い方であり、コードの保守性のようなテーマは薄かったと思われます。

  • 理解が不完全な状態でも、まずはソフトウェアを世に出し、その中でドメイン知識を深めよう、得られた知識や理解を常にプログラムに反映し続ければ、構造はシンプルで実態を反映したものになり、開発はスムーズに。
  • これを怠るのは借金を返済しないようなもので、プログラムから知識や理解はどんどん失われて実態と乖離し、利子のように複雑性が増して手がつけられなくなるぞ。

というような話と理解しています。ここから負債がもたらす結果として

  • 5日で終わる開発が10日かかるようになった、
  • 不具合の発生頻度が増えた
  • 関わる人のモチベーションが下がった、採用が難しくなった

などの現象面と、 負債という言葉の印象から、コードの保守性やシステムの老朽化、さらにはスピード優先で品質を犠牲に(借金)すれば一気に前に進めるのでは、というような話まで概念が広がったのだと思われます。

このテーマの難しいところは、放置した時にもたらす結果はネガティブだという共通認識がありながら、それを定量的に表すことが困難で、またそれぞれの置かれている状況で因子も重さもバラバラだというところではないでしょうか。
諸々研究されている分野でもありますし、そのうちAIがベストプラクティスを教えてくれる時代が来るのではないかと思いますが、現時点では最後は関わる人の意思ひとつで立ち向かうしかない問題かと思います。

議論様々なテーマではありますが、そんな中で今回は自分の向き合い方を気持ちベースで書いてみたいと思います(=ω=)

技術的負債への向き合い方

1. 感謝と祈りを

まずは日々お世話になっているシステムに感謝の念を送ります🙏

手がかかり悩みのタネになることも多く、どうしてもネガティブな気持ちを持ってしまいますが、そんな中でも頑張ってくれているシステムです。
道の先もわからない中、100km走ってくれればそれで良いつもりで作られた車が、今1000kmも10000kmも走ってくれているようなものです。

今走ってくれているシステムにも、これまで関わってくれた人にも感謝を持って向き合いましょう。

2. 日々のお手入れ

次は日々のお手入れをできることからやっていきます。
車で言うならオイル交換や掃除ですね。

定期的に時間が取れると良いと思います。
形骸化してしまったエラー通知の整理や、依存するライブラリのアップデートなど、手を付けやすく影響が少ないところから少しずつ触っていきましょう。

3. 整理整頓

段々キレイになってきたら、次は整理整頓します。
今のシステムは、当初想定していた走行距離や積載量を超えた性能を発揮しており、そのために様々な形で改造されているかと思います。
その中で、今となっては既に意味を失ったパーツがあったり、同じ機能を持ったパーツがあったりもするはずです。

次を考える上で出来る限り軽量化し、コンパクトにしていきましょう。
APIからService、テーブルなどを整理していけると良いと思います。
(と簡単に書いてますが、ここが既存理解も含めて一番大変なところかと思います。出来る範囲で頑張りましょう(=ω=)

4. 次の目標

整理整頓が一段落ついたら、目指す目標を定めましょう。
これまで走ってきてくれたシステムのおかげで、今は道の状況もライバルの情報も、その中での自身の強みや求められている性能も、走り出す前に比べて段違いに理解が深まっているかと思います。
最高速度、燃費、積載量、悪路走破性など、次の目標に向かって重視する性能を決めてみましょう。

また置かれているシステムや組織の状況によっては、先にこちらをまとめて向き合う時間を確保する必要がある場合も多いかと思います。
その場合はこちらを2番に行っていきましょう。

5. 改造タイム

ワクワクの改造タイムです。
次世代の夢と希望を乗せて、システムをアップグレードしましょう。

走りながら大改造を行ったり、組織全体を巻き込んだ大規模PJになることも多いですが、ここは腕の見せどころ。
また、CTOやアーキテクトと呼ばれる方々は4や5の専門家であることも多いです、こちらも存分に巻き込んでいきましょう。

6. 1に戻る

ここまで進めたら、また最初に戻って繰り返しです。
変化と複雑性への向き合いは終わることがありません、楽しんで行きましょう(=ω=)

最後に

技術的負債について、想いベースで語らせていただきました。
ご笑覧いただければ幸いです。

これからの年末年始にかけて、是非日々向き合っているシステムに対しても、今年もありがとう・来年もよろしく、という想いを送ってみてください。
ここまでありがとうございましたm(_ _)m

14
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
14
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?