技術的負債の定義と要因
株式会社株区スタイルの後藤秀典です。
この番組では、エンジニアリングチームで起きている問題について、
技術、組織、ビジネスといった複数の観点で深掘りし、
問題の正体やアプローチしていきます。
今回のテーマは、技術的負債という概念は必要なのか、です。
皆さん、聞いていらっしゃる方、技術的負債と日々向き合っている、
来られたかなと思っておりますが、
そもそもこの技術的負債という概念、考え方って必要なんですかね、
というところを今日はお話ししてみたいと思っています。
エンジニアリングマネージャーの問題集。
本日は技術的負債という、エンジニアの皆さん、ものすごく日常的に
格闘しているんじゃないかなというワードに関して、
僕の考えというか、というものを話していきたいと思います。
はじめにまず、この技術的負債とは何かというところから話していきます。
Wikipedia に一応定義があるので、一部抜粋すると、
次のような文章で書かれております。
時間がかかる、より良いアプローチを使用する代わりに、
今すぐ簡単な、もしくは限定的な解決策を選択することで生じる、
追加の手直しの暗黙のコストを反映したものである、という説明がされています。
なんとなくこれ、ちょっと古めの定義かなというか、
最初こういう定義で登場したのかなという理解で、
何かを実装する時に、良いアプローチと、あんまり良くないアプローチとかがあって、
あんまり良くないアプローチっていうのは、後々手がかかるよね、
っていう後々手がかかることを技術的不採というふうに呼び始めた、というのが最初かなと思っています。
そこから派生して、今となっては、厳密にこの定義に沿うものだけが、
技術的不採と呼んでいるのではなくて、
もっと割と広い範囲のソフトウェアに生じる様々なことを、
技術的不採と呼んでいるのかなと、それが一般的認識になっているのかなと思っていますが、
とはいえ、どういうものが技術的不採になっていくのか、
っていうところを改めて、いくつかの例で考えてみたいと思うんですけれども、
僕の考えで、技術的不採を一言で言い換えるとしたら、
これだよねっていうのがあって、それは何かというと、
メンテナンスのしづらさの度合い、これかなと思っています。
もしかすると、他の観点をお持ちの方もいらっしゃると思うんですが、
僕的には、メンテナンスのしづらさ、イコール技術的不採かなっていうところですね。
とはいえ、メンテナンスのしづらさっていうものも色々な尺度、観点があるし、
それを生み出すものっていうのも様々なものがあります。
オーソドックスにソフトウェア設計観点っていうんですかね、
技術的不採が語られるのって多くの場合、ソフトウェア設計のよしよしみたいなところがあるので、
そこから話し始めると、やっぱりソフトウェア設計の原則だったり、
プラクティスみたいなものに沿ってるかどうか。
これも度合いっていうか色々あるんですけれども、
あまりにこのソフトウェア設計のプラクティス原則に沿ってないものは、
やはり一定のメンテナンスしづらさみたいなものが生じるとは思います。
なので、このソフトウェア設計のプラクティスとか原則に沿ってるかどうかってところですね。
これって色んな設計原則、プラクティスがあったりだとか、
あとはちょっと違う枠組みかもしれないんですけれども、
アーキテクチャーみたいなものもこの話に入るのかなと思うので、
フレームワークが提供してるアーキテクチャーだったりだとか、
もしくはソフトウェアが扱ってるドメイン固有の構造というかアーキテクチャーというか、
そういうものもあると思いますので、
そういうものがそもそもなかったりだとかあっても、
その業界一般に認知されてるような構造から外れているだとか、
そういったことがあるとメンテナンスしづらさみたいなものを生むのかなと思っています。
この辺がまず一番オーソドックスな話なので、
競技の技術的不細っていうともうこの辺だけなのかなとは思うんですよね。
ソフトウェア設計のよしよしだけ。
ただもう少し他の要因でもこの技術的不細というか、
僕の言葉で言うとメンテナンスのしづらさが生じるものがあると思っていて、
ここはですね、賛同される方がどれくらいいるかわかんないんですが、
特に最近のソフトウェア開発ではこの辺りが要因としては大きいと思っているものがあって、
まず取り上げるのは人の認知というか脳の特徴っていうんですかね。
最近言われたりするのがやっぱり認知の負荷が大きすぎるものってどうしても扱いづらいので、
認知の負荷をできるだけ下げるようなソフトウェアの設計だったりだとか、
メンテナンスのしづらさと認知の負荷
チームの構造だったりだとか、そういうものを設計していきましょうというところがあったりします。
人間の脳で同時に扱えるような物事の大きさというんですかね、複雑度合いというんですかね。
そういうのが限られているので、そのサイズに合わせていきましょうみたいな話がいろんなところからされていたりします。
人間の認知みたいなものの特徴を考えると、
まず人間ってすごく忘れやすい生き物なのかなと思っています。
これは人によって程度が違うところがあるんですけれども、
やっぱり一定何か忘れていくし、
あとは一度扱ったものを完璧にずっと記憶し続けているというか、
脳にずっとフレッシュな状態で置いておくっていうことってなかなかできる人ってそんなにいないと思うんですよ。
ここから何が言えるかというと、
例えば僕がすごくある問題に対して、
これがベストのいろんなソフトウェア設計の原則にものっとりつつ、
いろんな考慮を施したいい設計だというような形でソースコードを書いたとしましょう、あるとき。
その時は僕としてもすごくメンテナンスしやすくて、
ちょっとしたリクエストがあっても瞬時に対応できる、これは素晴らしいみたいなものができたとします。
でも一旦そのプロジェクトが終わって、別のプロジェクトを3ヶ月やった後に、
急遽またすごくよくできた設計のプロジェクトの中程度ぐらいの変更依頼が発生したとします。
元のソフトウェアは何も触ってないし、何ならものすごく良い状態。
メンテナンスめちゃくちゃしやすいという状態だったはずが、
3ヶ月僕が別のプロジェクトにプルで取り組んだことによって、
脳の中にある状態っていうんですかね、
記憶の状態っていうのはほぼほぼ失われていて、
またゼロから認知というか理解というかいうところを立ち上げないといけないです。
何か思い出さないといけないですよね。
3ヶ月ぐらいだともしかすると100%元の状態を蘇らせることができるかもしれませんけれども、
半年だったらどうかとかそういう程度問題が出てきますね。
100%再現することもなかなか難しかったりもするんですよね。
その時のいろいろなロジカルに言うソフトウェアの構造のモデルの認識だけじゃなくて、
その時にたまたま自分が暗黙的に持っていたソフトウェアに対する感覚みたいな、
言語化できない何かだったりだとか、
そういうものが一定影響してその時のスナップショットとしての
設計のアウトプットみたいなのが出るのかなと思っているので、
そこまで含めて3ヶ月後、6ヶ月後に再び自分の脳の中に構築できるかというと、
ソースコードと人間の関係による技術的負債
なかなかやっぱりできなくて、
3ヶ月後、6ヶ月後に現実的に起こることっていうのは、
あれなんでこの時こんな書き方してるんだろう、
良くないなみたいに思っちゃうだとか、
そういうことの方が普通だと思うんですよ。
これはもう皆さんよくあることかなと思います。
なので、今の話から何が言えるかというと、
ある時、ある一時点でものすごく良い状態、
メンテナンスしやすい状態だとして作られたものも、
単に時間が経過するだけで何の変更も加えていないのに、
若干メンテナンスしづらさみたいなものが生まれてくると。
これはソースコード自体は何も変わってないんです。
何も変わってないのにメンテナンスしづらさ的なものが、
ソースコードと人間との間、どっちかというと人間の内側に
それが現れるっていうことだと思うんですよね。
ここら辺がこの技術的不採というか、
この概念の厄介なところかと思っています。
ソースコードそのものの客観的な状態だけであれば、
まだ物事は分かりやすいんですけれども、
それを扱う人間の方の状態みたいなことも影響して、
メンテナンスしづらさ的なものが生まれるというところですよね。
ここはさらにもっと話が広がるかなと思っているんですが、
ここまで考えないとソースコードをメンテナンスしやすい状態、
スピーディーに変更し続けられる状態というのを実現できないと思うので、
この辺まで僕は話のスコープとして今話しています。
もう少し人間じゃない側の話というのもあって、
ソフトウェアって何というのかな、
動く環境とか使っているライブラリとかいろんなものがありますと、
そういったものもソフトウェアでできていて、
かつハードウェアも含めてなんですけれども、
「技術的不細」という概念の問題
変化のスピードが年々早くなっていますと、
iPhoneであれば毎年新しいものが出たりだとか、
そんな感じでどんどん環境が変わっていきます。
なので完全に環境が固定された状態で動き続けるソフトウェアって、
そういう世界もあります。
ものすごく何十年も動き続けなければいけないような
ハードウェアとソフトウェアみたいな環境を扱っている方もいらっしゃるでしょう。
でも多くのITのビジネスというか、
多くの方が扱っているところってそういうところじゃないのかなと思っていて、
やっぱりいろんなものが毎年毎月毎月ぐらいのペースで変化していきますと。
そうするとこれもさっき話した人間の脳と似たような話になるんですけれども、
ソフトウェアそのものは何も変更していないんだけれども、
3ヶ月6ヶ月すると理解しづらいというより、
メンテナンスしづらいというよりは動かなくなるとか、
そういうことが発生するんですよね。
何か変更依頼があってもまず動かない部分というか、
バージョンアップとかをしないといけない部分っていうのがあって、
それに伴って変更するってことになるので、
トータルで見ると変更の作業量が増えるっていうのは
イコールメンテナンスしづらいっていう特徴を生み出すというところもあったりします。
なので人間側の側面もあれば、
ソフトウェアを動かしている取り巻く環境っていうんですかね。
そっち側の側面でもソフトウェアの変化は一切ないのに、
メンテナンスのしづらさがどんどん生じてくるというのが、
ある種今我々が扱っているソフトウェアの常識として存在する状況なのかなと思うんですよね。
まずそういうものがちょっとコンテキスト広げすぎかもしれないんですけれども、
いわゆる技術的不細、僕の言葉で言うとメンテナンスしづらい状況なのかなと思っています。
ここから発展して、僕が今回話したいことに移っていくんですけれども、
この技術的不細っていう言葉ですね、若干ちょっと僕発音しづらいんですけど、
この不細という言葉って、もうあんまり何ていうのかな、
今僕がいろいろ話した事態ですね、
ソフトウェア開発で発生する物事というか、メンテナンスしづらくなった状態って、
技術的不細みたいな概念を使わなくても説明できるというか、
むしろ技術的不細っていう言葉を使うことによって、
良くない状態が生じてしまうんじゃないかというふうにも思っています。
で、この良くなさそうなことをいくつか僕の観点でお話しするんですが、
まず先ほどの話から繋がる部分でもあるんですけれども、
技術的不細のようなメンテナンスしづらさみたいなものって、
ソフトウェアの中の特定のこの部分はメンテナンスがしづらくて、
他の部分はメンテナンスしやすいですっていう、
二項対立的な白黒みたいな状態ではないと僕は思っているんですよ。
ある瞬間瞬間で見たら、ここがメンテナンスしづらい、
それ以外はメンテナンスしやすいって言えるかもしれません。
さっき僕が話したように、時間が経つと、
メンテナンスしやすかったところすらメンテナンスしづらくなったりするわけですね。
っていうふうに、この白黒がはっきりしない物事だと思うんですよ。
このメンテナンスしやすいかしづらいかっていうところは。
っていうところから技術的不細って、
なんとなく元々借金みたいな概念のところから来てると思うんですよね。
それはもう借金なのか借金じゃないのかって、
イエスカーの白黒がはっきりする世界から来てるメタファーなので、
なんとなくその白黒はっきりした概念っていうのを、
ソフトウェア開発の中に技術的不細っていう概念が、
余計に取り込んでしまうんじゃないのかなと思うわけです。
なのでここは不細です、ここは不細ではないっていうような、
そのラベリングっていうか、
二個対立的な物事の見方っていうのが、
僕としては適切ではないと思っているので、
その意味であまりこの言葉は使わない方がいいんじゃないのかなっていうのが一つあります。
それからですね、そもそもの不細っていう名前の与え方っていうんですかね。
確かマーティン・ファウラーがつけたのかなと思うんですが、
ある種わかりやすさはあります。
なんかこう、良くないものっていうのの代表例として、
不細っていう別の世界の物事を持ち込んで説明した、
メタファーなんですよね。
元々の世界で、お金の世界の方で使われてた不細っていう物事の本質とはあんまり関係ないです。
このエンジニアリングの世界で言っている技術的不細っていうのは、
なんとなくこの雰囲気として似てるから、
説明しやすいから使われてるっていうのはメタファーですよね。
どうもですね、この不細っていう言葉自体が、
僕の考えている、僕の認識しているようなメンテナンスしづらさをうまく説明しないだったりだとか、
もしくはバッドケースとしては、
なんなら全然逆に認識されるというか、全く通じないというかね、
そういうことも引き起こす概念だったりするかなと思っていまして、
例えば一つ顕著な例をまずお話しすると、
この不細って会社を経営してる人とかであれば、
もちろん無借金経営っていう会社もありますが、
多くの会社は銀行だとかそういうところからお金を借り入れをして、
一定の利子を払いながら、それを元でにしながらビジネスを伸ばしていくということをします。
技術的不細の説明の欠点
で、この不細、そのお金の方ですよ。
この不細って悪いもんなんですかっていうと、
経営者とか別にそれ悪いもんだと思ってないはずなんですよ。
もちろん一定なんかその抱えている不細とそれにかかる利子とかですね、
それを上回るような事業成長を作っていくということにはコミットしなければならないし、
それがないとちゃんと不細返せないし、不細を借り入れた意味がないということになっちゃうんですが、
それでもやっぱりビジネスのスピードを上げるだとかいう局面では、
この不細というかお金を調達してくるということが非常に重要になってくるので、
それ自体が悪いものっていうことにならないんですよね。
むしろ不細、調達、何らかの形で調達ですね、借り入れという形でお金を調達してきて、
ビジネスを伸ばすということが何ならCEOとかCFOとかの重要な役割の一つでもあったりするんです。
なので、そういう人たちにソフトウェアの中に不細があるんです、
これが悪いんです、これ無くさなきゃいけないんですという風に説明しても
ニュートン年という感じになると思うんですよ。
これは実際僕の前職とかでもあった話ですね。
なので、ソフトウェアのエンジニア側の観点で立ったときに、
ソフトウェアの現在の状態、何が問題なのかということを説明するときに、
不細があるんです、みたいな一言ではおそらく経営者とかには話が通じないですね。
それは経営者がITのことを分かっていないとか、そういうレベルではなくて、
そもそも不細というメタファーが良くないんです。
それに加えて、不細だからダメっていうのって、
ある種、思考停止している状態ですよね。
不細だからダメなんです、ではなくて、別の言葉で何がダメなのかっていうのを
ダメというかあまり良くない状態ですということを説明できるべきだと思うんですよ。
それは頻繁に変更するモジュールだとかがあって、
そこが何か当初の設計意図としては何でしょうね。
仮に縦割りのような設計をしたとして、
でも変更要求は横に横断するような変更要求が多いから、
いつも縦に割ったところを横断していっぱい変更しなくちゃいけないんだと。
だからこの設計は今となっては結構手間がかかる設計になっています。
だからこれ直したほうがいいです、みたいな説明ってできるわけですよね。
それを何かこれが技術的不細ですみたいなのって、
やっぱり中身をちゃんと具体として説明できていないし、
何なら問題を捉えられていないかもしれないので、
そういう意味でもこの不細というメタファーは良くないのかなと。
技術的不細の過剰評価
特に外側のステークホルダーと会話するときに
あまり良くない道具になりがちなのかなというところもあったりします。
それ以外にもエンジニアの界隈でありがちだなというのは、
この技術的不細に限らないんですけれども、
昔の有名な人というか、そういう人が提唱したこの概念、
技術的不細で言えばメタファーなんですけれども、
これを有難がりすぎるというか、
だから技術的不細というのがソフトウェア開発の一つの
心理のように思っちゃう傾向があるのかなと思っていて、
つまりそこからどういう行動を僕が観測しているかというと、
技術的不細というもの、ソフトウェアの側に生じる問題ですね。
これは会計の概念を理解すればもっとよく理解できるとか、
そういうふうに思っている方もいらっしゃるようにも見受けられて、
技術的負債の概念に対する疑問
そこは単なるメタファーなので全然関係がないんですよね。
会計のことを理解しても、会計のことは分かるようになるけれども、
ソフトウェアの側で生じるメンテナンスのしづらさに
まつわるエトセトラみたいなところって何にもつながらないですよ。
何回か前のネガティブケイパビリティのところでもお話ししたんですが、
理解したいっていうか、正解が欲しいみたいな欲求って、
エンジニアに限らず誰でも持っているし、
エンジニアって割とそこを強く持っているのかなって
僕自身の体験からもあるんですけれども、
そういうのがちょっとこじれちゃって、
この技術的不採を理解したいみたいに、
ある種空回りしてしまうこととかがあるのかなと思っていて、
そういうのって僕はもう無駄だと思うんですよ。
やめたほうがいいと思うんですよ。
そういうことじゃないし、何ならもうこの技術的不採という言葉を使わずに、
どういう問題なんですかっていう具体のところにフォーカスして、
いろいろなものを見つめたほうが圧倒的に生産的だと思うので、
そうしたほうがいいなと思っています。
なので、いろいろ害がある言葉かなっていうのが僕の今主張したいことですね。
最後にまとめのような感じで僕が言いたいのは、
技術的負債の代わりに使うべき言葉
この技術的不採っていう言葉はもう使うのをやめましょうと言いたいです。
この言葉を使わなくてもソフトウェアそのものだったり、
ソフトウェア開発っていうエンジニアの活動ですね、
そこで生じている問題っていうのは基本的には説明可能だと思っています。
むしろその技術的不採という言葉を使わずに説明したほうが、
自分たちの解像度も高まるし、これに関わっている経営だとか、
その周りのステックホルダーにもより説明しやすくなると思っています。
なので、その意味でもまず使わないほうがいいと思っていますし、
あと最初のほうで説明したように、
不採不採みたいな感じで騒ぐこと自体もやめたほうがいいと思っていて、
当たり前のようにメンテナンスしづらさって、
ソフトウェア開発をやっていると発生してくるんですよね。
最初のほうに僕が話したように、
3ヶ月、6ヶ月経つとメンテナンスしづらくなっちゃってると。
それが当たり前なんですよ、ソフトウェアの世界って。
なので、そういうのは不採みたいな悪みたいに決めつけるんじゃなくて、
もうソフトウェアって自然とそうなるもんです。
なので、それを前提にしながら自分たちの日々のソフトウェア開発の中で、
何をしていけばいいのか、
メンテナンスしづらいところはちょこちょこ直しましょうだとか、
できるだけノータッチで忘れてしまうみたいなことを減らすように、
常にちょこちょこいろんなところを騒ぎましょうだとか、
そういった技術的不採と決めつけないことによって、
よりポジティブにメンテナンスしづらさが生じる事態に対して、
対処していくことができるんじゃないのかなと思っているので、
繰り返しになっちゃいますけれども、
もうこの技術的不採という言葉を使わずに、
ソフトウェア開発の一部なんです。
当たり前のことなんですっていう風にして、
日々より良いエンジニアリングをしていくということが、
今回の私からの提案になります。
というわけで、今回の技術的不採について、
自分の考えみたいなものを話しました。
こんな感じで当たり前になっちゃっている概念だとか、
言葉というものも、
時間が経つと使えなくなってくるなったりだとか、
そういうものってあると思うんですよね。
そういうものに関して素朴な疑問を持つことって、
全然悪いことではないと思うので、
私自身も改めて自分の理解の中をいろいろ点検するというか、
この概念って今であれば本当に同じように言えるんだっけとか、
そういう問い直しっていうんですかね。
みたいなことを改めていろいろやっていきたいなとも思っています。
さて、この番組では感想や質問、リクエストなどお待ちしております。
番組詳細欄にあるリンクよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。
EMはアルファベット、問題集は漢字でお願いします。
そしてApple PodcastやSpotifyのPodcastではレビューもできますので、
こちらにも感想を書いてもらえるとうれしいです。
お相手は株式会社株区スタイルCOO兼CTOの後藤秀典でした。
