技術負債の意味
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、賑やかし役の辰巳です。よろしくお願いいたします。よろしくお願いします。
さて本日のタイトルなんですが、リリース直後からそれを始まっている、技術負債の恐ろしさというタイトルになっております。
まず気になるのは技術負債という言葉ですね。一般的にはあまり馴染みがないのかもしれませんが、辰巳さん、技術負債、なかなか言いにくくて噛み噛みなんですが、技術負債の方ってどういったことになるんでしょうか。
技術負債、僕はちゃんと言えてますね。
入れないかもしれない。
要は例えばですけど、私たちPHPのフレームワークでLaravel（ララベル）というフレームワークを使ったりするんですけど、それのバージョンが年が経つにつれアップデートされていくんですね。
例えばバージョン7使ってましたと、ただ数年経つとバージョン8が出てきて、9が出てきて、そこのサポートが追いつかなくなるという現象が発生するんですよね。
そうなった時に、それを使い続けることによるリスクが増えていくっていうのが一般的な技術負債ですね。
いろんな側面から語られることが多いんですけど、一般的なのがそういったものかな。
サポートが追いつかなくなるというのは、バージョンアップによって変わったものに基本的に合わせていく必要があるっていうことですかね。
iPhoneとかでもそうじゃないですか、古いOSとかアプリのバージョンを使い続けたら不具合が起きると思うんですけど、あれはシステムにおいても起きる。
たまにアプリのゲームとかでも、この端末には対応してませんとか、このOSには対応してませんとかありますもんね。
PCとかって数年帯で変えたりするじゃないですか。
それと同じような感じで、システムのほうもアップデート順次していかないといけないんですね。
それがたまっていくことを技術負債というふうに。
契約と保守の関係
なるほどですね。それは基本的にシステムの開発をするとき、最初にお客さんに説明するものなんですか。
それとも集中の事実というか、そういったところになってくるんですか。どうなんでしょう。
これはそうですね、それを伝えてもお客さんとしてはピンとこないというのが多分一つあると思いますが、
基本的には言うことは往々にしてあると思います。
例えばですけど、開発の流れとしてお見積りして発注してもらって開発してもらって納品するというサイクルがあるんですけど、
そこで終わってるという認識する人が多い。そこから保守が始まって技術負債との戦いが始まるわけなんですよね。
なるほどですね。それ一般的には保守の範囲内ということになるんですか。
それとも新たに説明してディファクタリング、技術負債というものを解消していく必要があるのかどうなんでしょうか。
結論は契約の内容次第になってきますね。
なるほどですね。
契約内でそこら辺もやるというのであれば別途それに応じた予算を多分いただくことが多いですし、
ミニマムな保守の契約の内容であったらディファクタリング、これ水質ありますねって出てきたタイミングで別途お見積りすることもある。
事例と影響
なるほどですね。結構これはいろんな事例がありそうだなという気がしていますが、
島田さんこんな技術負債に主にまつわる事例があったよみたいな話を伺いしてもよろしいでしょうか。
そうですね。過去にいろんなケースがありますけど、さっき辰巳さんが言い淀んでましたけど、なかなかこれ言いにくいんですよね、開発会社としてはね。
それで言わなくて、後々トラブルになったってケースもあるんで、あんまり新しいやつは言いにくいんだけど、
10年以上前のケースで言うと、一番最初にそこの会社さんのメーカーのシステムを、業務システムなんだけど、それをASPっていうマイクロソフトの技術で作ったことがあるんですよね。
今で言うとデガシーASPとかっていう言葉があって、本当に古いマイクロソフトが一番初めに出したような言語だったんだよね。
それで作りましたと。それを使っていくと、うちの会社もだんだん技術者をマイクロソフト系からLinux系に変えていったっていう経緯があって、5年たち8年たちってなっていったときに、お客さんがいろいろと修正してほしいとかいうことがあったときに、なかなか対応できなくなってきたんですよね。
もちろんうちも対応できる人がいないって正直に言ったりしてたんですけど、じゃあ全部作り直した方がいいのかって言うから、そうなんですよねって技術が古くて主流じゃないんでって話をして、作り直そうという提案をしたんですけど、
さすがに作ったときと同じぐらいの予算を必要になったりして、そのシステムがですね。それで社長さん難色を示されまして、そこからリバークタイミングって作り変えるまでに3年ぐらいかかりましたね。
なるほどですね。これ一般的にはシステムの寿命、もちろん業界とかものによると思うんですけど、だいたいどのぐらいなものなんですか?
基本的には税法的には5年とか7年とかって言うんだけど、ユーザー企業さんの社長さんとかの立場に立つとやっぱり10年とか使っていこうっていう気はありますよね、普通に。
なるほど。10年でも持たないっていうのが一般的ですよね。どうなんでしょうか?
技術で10年持つ技術はほとんどないですね。
古い技術から新しい技術はどんどん時代によって変わっていくっていうところはあると思うんですが、そこら辺のお客様に理解してもらうためにはどういったことをするべきなんでしょうかね。
もちろん一つは最初にすべて説明してしまうっていうことがあると思うんですけど、関わっていく中で徐々に伝えていくとかそういった形になるものなんですかね。どうでしょうか?
結局これ、いわゆるマンションの建て替えみたいな話とよく似てるんだけど、マンションって分譲マンションね。購入すると30年後に建て替えますみたいな計画を立てて積み立てていくんですよね、建て替えのためのお金を。
ただそれは決めてるんだよね、ルールをね。言わなきゃいけないっていう風に決まってるんですよ。でもこのソフトウェアのシステムの方は決まってないので、我々業者は言いにくいんですよね。
確かに。契約決まる最初になかなか言いづらい話ですよね。
そうそう。10年後にこれ全部作り直しになりますよと。だから積み立てておいてくださいっていうのはなかなか言いづらいんですよね。
言った瞬間他の業者になんだよみたいな。他の業者そんなの言ってなかったかな、こっちにしようかなみたいな風になってしまうので、言いにくいんですよ。多分言ってる業者ないんじゃないですかね。
他の事例とかってあったりします?
他の事例もですね、それは学習ソフトの開発会社でWindows版のアプリ、インストールするタイプのアプリで作ってたんですけど、それも古い言語で作られていて、
もうデータのメンテナンスとかも大変なんで、ウェブアプリにしましょうよっていう提案を何度もしたんですけど、なかなか通らなくて、ウェブにするんだったらお宅じゃなくて他のとこにお願いするって言ってのじかえられたってケースもありますね。
なるほどですね。理解を得られずにも離れてしまうっていうケースもあるってところですよね。
ありますね。やっぱり印象が悪いですよね。今までちゃんとやったのに急にドカッとお金を要求されて。お客さんとしてはそんなにメリットがないわけですよ。今まで使えたわけだからね。
そうですね。仮にそのまま強行的に使うってなると、いつか使えなくなるっていうのがアウトラインと言いますか、それ終わりと言いますか、そういったことにはなるんですよね、これって最終的には。
最終的に全く使えなくなるっていうことになるまでは時間かかると思いますけど、徐々に徐々に蝕まれていくんじゃないか。
ところどころ不具合が出たりとか。
それもやっぱり技術的に変えられないよね。修正ができない。
システムって一つの言語で作られてるわけじゃなくて、いろんなミドルウェアって言うんですけど、別のソフトも絡んで使われたりするんですよね。
技術負債の影響
あと外部のサービスとかも連動して動いたりするんで、この間起きたのはメールを送信する機能だけをSendGridっていう別のサービスを使ってやってたんですけど、
そのSendGridっていうところが、もうこのセキュリティの通信仕様はダメですよって急に、急にではないですけど前々からアラートが上がってたんですけど、
もうこれ一切、今後は一切やりませんと。その通信仕様は受け付けませんって言われてしまったら、突然メールが止まると。
そういうことが他にもいろいろと起きてくるんですよね。最終的には使えなくなるっていう感じですね。
なるほど。ありがとうございます。避けるためにはシステム開発会社側としてどういう努力をすべきなんでしょうか。辰巳さんお伺いしてもよろしいでしょうか。
双方でちゃんとそこの温度感を一致させるっていうのは重要です。そこの上で我々として伝えたいこととしては、
業務システムってあることによって、当然その業務効率化はなかった時と比べると向上すると思うんですよね。
それが当たり前になってくると、そこからさらに向上させようとかっていう、徐々に思わなくなってくるというか、安定稼働してしまうと。
そこでリファクターっていう話が出てくると、えーってなってしまうんですけど、やっぱりシステムに関しては常に育てていくものというか、
投資対象というふうに見ていただいて、あくまでもそのコストばかりに目が行ってしまうかもしれないんですけれども、
そこはここから難しいですけど、お金はどうしてもかかってしまうということをうまく、我々もちゃんと透明感を持って伝えていきますので、
なんとかご理解いただきたいなという気持ちがあるという感じですかね。半分僕の希望的観測もこもってますけど。
ちょっと流れとは違うかもしれないんですが、島田さんも避けるためにはこうしたらいいとか、こうしてきたっていうところを聞きたいなと思ったんですが、いいですか?
そうですね。保守の中で随時、だんだん3年とか5年とか経つうちに言っていかなきゃいけないと。5年じゃもう遅いんですよね。
やっぱりお金ちょっと用意しておかなきゃいけないので、そういう意味では3年ぐらい経ったぐらいから1月ぐらいまでに、
このシステムには違うと思うんですけど、このシステムはエンドユーザーさんに使ってもらっているやつだったり、お金が絡むようなシステムなので、
セキュリティリスク上がっていくというまず必要みたいな感じで、徐々に警告を出していくということが必要かなと思いますね。それしかないんじゃないですかね。
なるほど。補修とか関わっていく中で徐々に伝えていく。こういうことがありますっていうのを伝えていって、理解していってもらうっていうところがやっぱり必要になってくるっていうところですかね。
そうですね。
100日後に死ぬワニじゃないですけど、10年後に止まるシステムということで。
そうですね。
なるほどですね。これでもなかなか周知しづらいですし、おそらくオンページとかにあんまり落ちてない、検索とかにも出てこない情報なんじゃないかなと思うんですが、
システムの延命と対策
これはこういったポッドキャストとかそういったこととか、保守の中でということはもちろんそうだと思うんですけど、何とか伝えていって理解していただきたい部分ではありますよね。
たぶんこれを聞いているリスナーの皆さんって自身で使われている業務システムがあって、それが寿命を迎えそうだと、リファクタリングの提案をベンダーからされているということも全然あり得るかなと思うんですけど、
それが適正価格かどうかわからなかったら一旦弊社にご相談いただくっていうのもありかもしれないですね。こういうやり方もできないですかみたいなこともあると思う。
とりあえず延命っていうのは割とできたりするので、とりあえず延命は結局さっきのメールの配信の部分なんかはリファクタリングはしてなくて、延命しただけですね。
本当に日誌もサッチもいかないっていうときは全部書き直す必要がありますんでね。
その辺の判断も専門家じゃないとつかない部分っていうところですかね。
それはそうですね。
ありがとうございます。
技術負債っていうものは間違いなくあるっていうことを含め、今現状を使っているシステムとかがどうなっているのか、それを延命すべきなのかできるのか、
全く作り変えるべきなのか等を含めなかなか判断等難しいと思いますので、ぜひ気軽にプラムザの方にお問い合わせいただければと思います。
こんな感じでよろしいでしょうか。
ありがとうございます。
本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価をお願いします。
またXでも最新情報を随時発信していますのでよろしくお願いします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
