「技術的負債は避けるべきか？」もちろんです．

開発 技術的負債 デスマーチ

あーうー．思った以上に「これはヒドイ」．

「技術的負債」という言葉は、この運用コスト最適化の重要性を指摘する上で、とてもキャッチーなフレーズだと考えられます。しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。

初期開発コストと運用コストのバランスを、どのようにとっていけば良いのでしょう？

ここまでなら，言ってることはまあまあ正しい．ここまでは．

同等の機能を提供する「ソフトA」と「ソフトB」を考えてみます。ソフトAは、初期開発工数が6だが、２年目以降の維持工数が毎年4かかるとします。ソフトBは、初期開発工数が10で、維持工数が毎年1かかるとしましょう。ソフトAはPHPファイル１枚に必要な処理をひたすら羅列したクソコード、ソフトBはMVCを念頭にレイヤ分割された、きれいなコードなんてイメージすると、こんな工数感覚になってもおかしくないかと思います。

無茶苦茶おかしい．糞コードなめすぎ．おまえ，今まで本当の糞コードの保守を経験したこと無いだろ．*1


なんで糞コードの維持工数が「定数」なんだよ．糞コードの糞コードたる所以は，維持コストが際限なくねずみ算式に増えていく所にある．ソフトAが糞コードなら，初期開発工数が6だとしても，1年目の維持工数が４，二年目が１６，三年目が６４，4年目が２００，．．．というくらいなら十分考えられるのだ．*2

なら技術的負債をどうすべきかは，言わなくても分かるよね．

しかも

注: 割引率は毎年一定になるとは限らないでしょう。たとえば

なぜか割引率の方が可変の可能性を論じている．


他にもイロイロと落とし穴がある．

  • システムは予想されたより遙かに長く使われることが少なくない．
    • その最たるものが2000年問題だった．
    • 短期で消えていく予定の商品が短期で消えるとは限らない．予想外の商品がヒットした時に，この予定は破綻する．
      そもそも何がヒットしないか分かるなら，逆説的に何がヒットするかもわかるわけで，最初からヒット商品「だけ」作ればいい話．
  • 未来は予測出来ない．
    • 顧客のいう「変更しない予定」ほどあてにならない物は無い．本当に信用できたら，こんなに仕様変更で泣かされてない．
    • 仕様変更，或いはちゃぶ台返しがあれば，保守コストなんていくらでも膨れあがるよ．
    • ユーザーは自分が本当に欲しい物を理解していない．ならば，彼等の描く未来予想図など当たるはずが無かろう．
  • システムの側が変更しなくても，OSや言語処理系，フレームワーク，ライブラリ，或いは人気や利用者数のような環境などの方が変わることがある．
    • IE6依存のシステムがIE7以降で動かなくなるのは有名．
    • たとえば艦これの予想外のヒットでサーバー増強が追いつかなかった．もしスケールできない実装だったなら，そのときの機会損失で失われる利益は計り知れない．
  • パフォーマンス問題は事前の予測が難しいが，もしその問題が発生した時に糞コードだと問題解決できずに，全部作り直しになる恐れがある．
  • 機能追加や仕様変更は避けられても，バグフィックスは避けられない．質の悪い糞コードなら，この問題が頻発し，修正するたびにさらに技術的負債が増えていくことも少なくない．
  • id:qittu プロダクトの寿命が短かったとしても，次のプロダクトをつくるのに以前のプロダクトのコードを元にする，とかいうこともよくあるからな．
  • id:raitu 組込でも他製品コードを流用したりするから技術的負債の抑制は重要。ただ先々使われない、使われるコードの見極めってかなり難しい

注2: ソフトウェアが陳腐化する外的要因は周辺技術の進歩です。その速度は一定であると置くのが妥当ですから、ソフトウェアの保守コストは毎年一定であると考えるのが正しいことになります。「ソフトウェアの保守が時間とともに難しくなる」と感じられるとしても、それは過去の保守投資が過小であった結果だと解釈すれば良い話です。モデルを無駄に複雑化する理由はありません。

追記か？


ソフトウエアが陳腐化は，保守コストへの影響は小さいのでは？陳腐化しようとすまいと，むしろレガシーシステムの方が保守コストは嵩む傾向にある．*3 *4

「ソフトウエアの保守が時間と共に難しくなる」わけではなくて，「技術的負債の蓄積と共に飛躍的に難しくなる」と言うべき．これは感じるとか気のせいじゃなくて，実際に難しくなる．

「保守投資が過小であった結果だと解釈」？言い替えると「排除すべき技術的負債を排除しなかったために，過剰なコスト負担が必要になった」ってことでしょ．なんで「技術的負債を避けるべきである」っていう結論から目をそらすのさ．

モデルを無駄に複雑化する？保守コストを適切に計算し，表現することもできないくせに，今のモデルが適切だとでも言うつもりか．技術的負債の利息が０％固定であるなどという非現実的なモデルを破棄する方が妥当な判断でしょう．*5

以上のように、技術選択における正解は割引率の高低によって大きく左右されます。

要するに「割引率や仕様変更の頻度は未知数なので，技術選択の正解はさっぱりわかりません」ということですね．特にSIビジネスだと顧客側は素人なので，「以前はこれで絶対に変えないって言ってたけど，やっぱり変更する」ということは多くなりがち．故に顧客側から頻発する仕様変更をコントロールする術の無いSIビジネスにおいては，技術的負債をため込まないのがベストプラクティスと言える．*6


トラックバックを送ろうと思ったら，お約束のようになかった．

http://b.hatena.ne.jp/entry/blog.kazuhooku.com/2015/03/blog-post.html

  • id:rryu 技術的負債は複利で増えていく気がするので割引率と相殺されるのではないだろうか。

激しく同意．

  • id:qittu プロダクトの寿命が短かったとしても，次のプロダクトをつくるのに以前のプロダクトのコードを元にする，とかいうこともよくあるからな．
  • id:raitu 組込でも他製品コードを流用したりするから技術的負債の抑制は重要。ただ先々使われない、使われるコードの見極めってかなり難しい
  • id:tzt 「これいけるんとちゃうん？」となったらどんどん新機能がはいったり既存機能が改修されたりで工数1や4どころで済むわけないのでその場合はどうなるのか気になる。
  • id:mapk0y “しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。”/ 個人的にこの前提がほんとうに正しいのかが一番気になってます。

多少は大きくなるが，驚くほどでもない．少なくとも糞コードの保守にかかる莫大な費用と時間に比べれば微々たるもの．

とはいえ必要になるのはそれなりの知識や技術，つまりは高スキルなプログラマーなのだが，これは日本企業に最も欠けている視点でもある．

  • id:bienbienbienbien 感覚の共有はいいにしても、数字の妥当性どこで担保すんのよって課題が世界中で
  • id:haruharu1 見積もり工数すらうまく働いていることが少ないのに、その上から更にアバウトな割引率とかいう気分で工数揺れ動くの、ゆりかごin墓場って感じのスタイル。
  • id:qouroquis 理論的なモデルはそうなんだろうけど、実務を行う上で一番難しいのは割引率をどう見るか、なので……。いくら理屈で考えてもそこが当てずっぽうだと、勘と経験でやってるのと変わらない。
  • id:katzchang かなり乱暴な数字なので、どっちにしろこれで説得されそうになるのは危ない。
  • id:amaliche ソフトウェアの生産性は正しく計測出来ないので上司の説得には使えるかもしれないが現実的にはあまり意味は無いとおもう。

全くです．
そもそもなんで負債を利息０で計算するのさ．その時点で机上の空論．


そして技術的負債の怖さは，利率の上限が二桁％なんて低利率でないこと．

(「Martin Fowler氏の語る“犠牲的アーキテクチャ"」)

耐用年数があって，一定時期ごとの「立て替え」が必用ならば，そのための「積み立て」も必用なのでは．しかし積み立て資金が不足していて壊れたまま使われ続ける不良システムのなんと多いことか．


そもそも積み立てできるくらい健全な財務体質ならば，最初から無計画に負債をため込んだりはしないものです．

  • id:hogshead 会計の類推で考えるならプロダクトを丸ごと負債と資産に計上し、技術的負債は工数算定の不確実性として負債でなく金利としてモデル化し、その先にプロダクトの将来価値と割引率を接合するのが包括的でいいと思ってる
  • id:nekora 金に例えるのは金額に相当する具体的数値がズバット出てくるのがミソで、「品質会計」などは取るべき予想残バグがそうなんだが、Web系の言う「技術的負債」は数字が出なくて何か名前が格好良いだけでフワフワ…。
  • id:matsumoto_r 概ね同意。数字が気になる人がいるみたいだけど、逆にnとか色々文字使って境界はーとか数学ぽく書くと流し読みしそうだからこれでよいと思う。

具体的数値は出ている．

ただし，その数値はおよそ有り得ない仮定の連続と非現実的な数値の羅列で荒唐無稽．*7


ちなみに「技術的負債」はソフトウエアの話でWeb系ではないはず．数値に関してはソフトウエアの生産性は計測できないので，出てきた時の方が危険．詐欺師の方がそういうのは得意なんだよ．

  • id:mizti 無借金経営が常に最善ではないのと同じ観点

下手に借金していた企業は，リーマンショックやバブル崩壊，単にちょっと業績不振があっただけでも借金が返せなくなって倒産したりするけどね．でも未来は予測出来ない．しかも技術を知らないマネージャーは，技術的負債を過小評価しすぎる傾向にあるから．それも3〜5桁くらいドカンと．


Techcrunch「スタートアップでもソフトウェアの品質が優先か？」

http://jp.techcrunch.com/2016/07/25/20160724how-much-does-it-matter-if-your-software-quality-sucks/
追記

もし仮に、人々が真に欲しがっているものを構築できていたとしても、あなたが新しいエンジニアを雇い全てのコードベースを書き直している間に、高品質ソフトウェアを持つ競争相手たちは同じ時間をあなたを打ち負かすために使うことができる。泥沼ソフトウェアの方向転換はあまりにも困難であるため、完全なゼロから書き直した方が、その一部を再利用しようとするよりも優れた選択肢であるという事態にしばしば直面する。言うまでもなく、何百時間もの労力と何千ドルもの資金をこの泥沼の構築に費やしてきた創業者たちは、こんなことは聞きたくもないだろう。

ソフトウェアの品質があなたの成功を決定付ける訳ではない。それは真実だ。しかし、それはあなたの速度を決定付ける。もし競争相手が全くいないなら、速度が遅いことには何の問題もない。しかし、もし全く競争相手がいない世界に住んでいるとあなたが思っているなら、痛みを伴う目覚めが待っている。動きと対応が遅ければ遅いほど、あなたのスタートアップはより早く死んでしまうことがあり得る。

スタートアップにおいても技術的負債は避けるべきものである．ましてや真っ当な企業おや．

レガシーコード改善ガイド

レガシーコード改善ガイド

*1:これが開発経験のないマネージャの問題の一つ．経験がないもんだから見積もりが決定的に間違ってることが多く，しかも指摘されてもそれが理解できない．

*2:そして数年もたたずに，利息さえ払えなくなって「経営破綻」する．
作り直し？利息も払えないのにデスか？

*3:「技術進歩が一定である」という仮定も正しくないだろ．そのときホットな技術は急激に進歩するが，そうでないものは捨て置かれる．たとえばパソコン通信時代とインターネット，LinuxとFreeBSDを比較してみるべし．或いはIE6の様に市場を独占したが故に進歩しなくなった例もある．いやIE6こそが，技術的負債の優れた反面教師かも？

*4:たとえばハードウェアでも，ビデオのベータマックスみたいに生産中止になった機械とか，クラシックカーみたいなものの方が保守コストは高く付くよね．

*5:「保守投資が過小であった結果」のと「技術的負債の利息」と，一体どちらがシンプルで現実的なモデルだろうか．
「天動説でも，惑星の逆行を説明する事は可能だ！（きり）」みたいな感じ．説明は可能だとしても，逆行の説明にもう一つの円運動を導入してまで固執するほど，天動説は美しいモデルだろうか？ http://www.s-yamaga.jp/nanimono/uchu/wakuseinoundo/tendosetsutochidosetsu.htm

*6:「将来もし変更や機能追加が発生したら，高い金額ふっかければいいんじゃね？どうせ逃げられないしね！」という考えもあるにはある．

*7:「仮に毎日英語を8.7時間勉強し，そのうちネイティブとの英会話を1.28時間行い，一日平均12.5個の英単語を覚えるとする．勉強1時間当たりTOEICの点数が，0.25点ずつ上がると仮定すると，XXヶ月後のあなたの得点は○○点になる計算になる．」みたいな話．数字の具体性のまえに，それが妥当な推論であるかを検証しましょう．