orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

技術的負債が生まれる仕組みから技術選定の重要さを知る

f:id:orangeitems:20220326164011j:plain

 

ネットを見ていると、毎日のように新しい技術が発表されたり、その新しい技術を使って実装したぞと言う自慢げなエントリーだったり、を目にするものだが、現場の要素技術を見ると結構、レガシーと言うかありきたりだったりする。

もっと洗練された技術があるのに、とか、ネットのあの手法を使えば楽しいのに、とか思う人も必ずいると思う。趣味レベルではきっと採用しないような保守的な設計のほうが実際の現場では強い。

新しい技術は、過去のレガシーな技術の課題や、現場のあるある的な話をくつがえす夢物語がストーリーとして付属していることも多く、技術者ならもやもやする瞬間である。なぜ、あの先輩はかなり技術に詳しいのに、いつもこの手法なのか。

確かに便利な技術というのは存在するが、もっとも大事なのは、十年単位でメンテナンス可能かどうかという運用設計の部分である。

いろいろなソフトウェアに出会い、使ってきたが、信用できないベンダーは存在する。

ある日保守の打ち切りを発表し、それだけではなく次のバージョンを出さないとも宣言した。

ソフトウェアベンダーは結構買収を繰り返していて、買収した会社のソフトウェア資産を自社の弱かった部分と置き換えるようなことをよくやる。その際、これまでのソフトウェアを捨てるような決断をすることがある。

もしくは、「これはもう使われない機能だから、次のバージョンでは実装しません」なんてことも体験した。いや、それバリバリに使ってたんだけど。保守切れになるわ、更新したら使えなくなるわで、運用は混乱する。

クラウドの世界でもよくある話で、サポート終了すると。ふーんと思っていたら、終了すると同時に使えなくなる。いや、それ運用に組み込んでましたって。こういう風に対応してくださいってレターに書いてあるけど、めちゃ大変な方法が書いてあったりする。

クラウドベンダーは、結構これまでサービス開始と終了を繰り返してきて、そのたびに顧客から総攻撃を受けてきたので、最近はあまりサービス開始を簡単に言わなくなったし、逆にサービス終了も慎重になっているように見受けられる。当たり前だ。使っている人がいるのだから、ビジネス都合で簡単に「やめまーす」じゃないんだ。

難しい要件があって、それを難しい実装をしてがんばって、よし動いた!、で感動して、「すごいでしょ」って記事が出るエモーションはわかるんだが、それって十年後、誰かメンテナンスできるのかい?。難しいよね。わかる。難しいのに解決した、それはすごいかもしれないね。でも、それが運用に入って保守が難しかったり、ソフトウェアやサービスの一部が動かなくなったり、そして作った人が担当者が退職したり。いろんなことが起こる。大変な実装を見るたびに、最近はその達成した美しさより、その後の大変さが脳裏に映る。

人に説明することが難しいことは、とても保守性が低い。構成が複雑であるほど、危険である。要素が独特で実績が少ないと、世間にわかっている人が少ない。そうすると、「誰か助けて」と言ったときに人が集まらない。ベンダーも消失するかもしれない。

それが技術的負債と言われるものである。

いずれ作り直さなければいけないそれ、は、課題となる前に、設計段階で熟考しなければいけない。より単純で、シンプルで、誰でも理解可能なものに限る。スマートでなくたって、冗長であっても、わかりやすいことが後々勝つし、技術選定の段階で勝負が8割決まる厳しい世界だと把握している。

もちろん、ソフトウェアベンダーやクラウドベンダーは、「これこそ今後の標準。10年戦える技術」と喧伝するのだけれど、もう宣伝文句には騙されてはいけない。技術的負債を更に作り出すことがあってはいけないのだ。