orangeitems’s diary

クラウドではたらくエンジニアの日々の感想です。

技術的負債を補う言葉について考えてみる。運用的負債というのはどうだろうか。

f:id:orangeitems:20180323121204j:plain

技術的負債という言葉では伝わらない概念

一人のシステムエンジニアとして良い問題提起だと思ったので取り上げたいと思います。 hachi.hatenablog.com

きっかけはエンジニア内で技術的負債というのをesaにまとめてたときに、これをどうやってやっていけるのかなと思ってた。チームで仕事をしている以上、エンジニアだけではどうにもできない部分は確実にある。
(中略)「技術」という単語が出るとどうしても「エンジニアだけのお仕事」という感じになってしまう。その時は他施策より優先度が下がることが多い気がする。

スポンサーリンク

 

技術的負債とは何か

まず、技術的負債という言葉を明確に理解する必要があります。

技術的負債(英: Technical debt)とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である[1]。「設計上の負債(design debt)」とも言う。

1992年ウォード・カニンガムが、技術的な複雑さと債務の比較を経験報告で初めて行った。

最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる[2]。

技術的負債 - Wikipedia

抽象的には理解できるのですが、もっと具体的にどんなことを示すのかを表現している記事を探しました。

技術負債の種類

さて技術的負債と言っても、コーディングのレベルだけではなく様々な種類があります。
ちょっと私が思いつく限りまとめてみますと、

・コーディングのレベル(実装方法)の負債
・負荷が考えられていない実装による制約などの負債
・バージョンアップすべき言語やライブラリ、OSの放置による負債
・トレンドが変わって乗り換える必要が出てきた場合の負債
・共有不足で実装内容のブラックボックス化による負債

あたりがあるのではないかと思います。

技術的負債とどうやって戦うか - Qiita

技術的負債について、イメージはつかめました。

 

考察

私はインフラエンジニアでありソフトウェア開発や本番リリース後の修正には携わっていません。システムエンジニア(SE)というと大多数がソフトウェア開発寄りなので、この記事で言うところの「エンジニアだけではどうにもできない部分」の業務に近いところにいます。会社でもSE扱いされていなかったりします。広くはSEなんですがね。

次に、SEがどうにもならないところというのは、インフラ基盤などの非機能要件もそうですし、そのソフトウェアのビジネスを動かしている運営や企画も関わっていたりすると思います。どうして、その機能を作らねばならないのか。ビジネスなので非エンジニアが企画したりしますが戦略が無く合理的ではなかったり、以前の戦略と180度違ったりして実装しにくい、企画から指示されるリリース時期が短すぎていつも品質が悪い、などということがあると思います。長いサービスであればあるほどそういった負債が大きくなっていきそうです。

技術的負債というと、言葉の定義の通り、ソフトウェア開発におけるシステムエンジニアリングばかりが強調されるものの、SEからすると、「なんでそういう決定になんねん」「その仕様やと運用メンバーにしわ寄せが行くやん」「そういう非機能要件で設計されてないから変更すると大変になるんちゃうん」といったことも、負債になろうと思います。わけのわからないことに対応することで負債がどんどん増えていき、運用に不具合を生じさせる一因になっていきます。

いわゆるインフラの世界でも、かなりの技術革新が起こっていて、クラウドもIaaS(基盤)の部分だけではなく、PaaSやコンテナ化などいろいろな新技術が出ていながら、昔ながらのアーキテクチャで四苦八苦しているシステムはごまんとあります。開発エンジニアからすると何でうちの会社はこんな古い基盤でコーディングしないといけないんだ・・とかあります。OSが古いとか機械の減価償却が終わってないとか、もしくはインフラで幅を利かせている社員がクラウド嫌いだからとか、まあそういった「負債」もありますね。

このような、サービス全体の負債をどう呼ぶかですが、私は運用的負債、という言葉がしっくりきます。かつ、技術的負債の代替というよりは、横にいるような補完するようなイメージです。運用とするとインフラのような非機能要件や、ビジネス上の理由も含まれてきますし、運用に関わるソフトウェア開発の部分も含めていけばいいのではないかと思います。一方で、技術的負債は運用的負債に対して独立して考えてもいいのではないかと思います。

とりあえず、「チームで仕事をしている以上、エンジニアだけではどうにもできない部分は確実にある。」という一文には非常に共感をおぼえましたので記事を書かせていただきました。確かにありますし、技術的負債ばかり注目していても全体としてはうまく改善しないと思います。