雑談からの導入
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、賑やかし役の辰巳です。よろしくお願いします。
この直前の会議で決まったことですが、雑談を冒頭に入れてみないかということになったんですが、どうお雑談、皆さん、最近のトピックとか。
むしろ雑談しかできないです。
辰巳さんの雑談に期待していいんですかね。
今10月の半ばなんですけど、3連休で福島と山形に旅行行ってきて。たまたま山形に行ったら、その日花火大会でめちゃめちゃよかったですね。
山形の花火大会で有名なのってありました?
いや今年いて、去年から始まった花火大会があって。
米沢戦国花火大会。
旧米沢藩って植杉家とか伊達家とかいろんな侍がいた場所なんです。ゆかりの地なんです。
それにちなんだ花火大会をやったんですけど、結構雨降って大変だったみたいな。
なるほど。
それでも結婚されて花火はすっきりでしたね。
今年は皆さん見ました?夏も終わりましたが。
本当に。
俺はもう最近は全然見に行かないね。
混むばっかりじゃない?
まあそうですね。遠くからちょっと見れたら見るかなぐらいな感じになっちゃいますよね。
10年くらい前はやってたら必ず見に行ってた。夏には一回は行ってたけどね。
それはお子さんの関係とか?
そうそう。でも大変なんだよね。遠いでもないしさ。
そうですね。屋台で食うにしてもそこら辺のスーパーで買ってから行った方が早いとかなっちゃいますからね。
だから雨だし寒いしで途中で帰りました。良かったですけどね。
秋だしね、もうね。
本当に。雨降ると東北は冬です。ダウン来ていい気持ちだね。
じゃあこんなところで入ってみますか。
システムの寿命について
いいと思います。こういうことです。
ちょっと継続してみますか。では今回のタイトルから読み上げさせていただきます。
導入したシステムは10年以上使えるのか?というテーマになります。
これどうですかね。現状だと確かに肌間隔10年以上は長いよなっていうところを思ったりするんですが、
昔とかこういうのはザラだったりするんですか?島津さんどうですかね。
昔のMS-DOSとかで作られたシステムとかってやたら長い期だったけどね。
技術進歩はゆっくりだったんで、割と本屋さんとかの検索システムとか、
コマンドを入れてくださいみたいなゼロイチ2みたいなやつで、1エンターみたいな感じで検索みたいな。
そんなのが木の国屋とかにもあったけども、ああいうのは結構長く使えたと思うんだよね。
今はなかなか10年同じ形で動くっていうのはなかなか厳しいという感じですかね。
辰巳さんいかがでしょうか。
前も言ったかもしれないですけど、システムのサイクル的には大体7年ぐらいと言われていて、
10年持つともう何でしょうね。人間で言うともう90歳ぐらい。
何かしらの形で延命処置をしないともう使うことすら厳しいというものはあり得ると思いますね。
なるほど。昔はアップデートというか技術の進化が遅かったということですけど、
近年はやっぱり早くなってきているというか、使うフレームワークですね。
例えばLaravel（ララベル）とかもアップデートも入ってくるしということも踏まえて、長くて7年だろうという感じなんですかね。
大体そういうふうに考えてもらっていいと思いますし、あとはシステムは生き物なので、
使ってくると想定以上にデータ量とかログファイルが溜まったりとかして、動きとかもやっぱり遅くなったりする時もあるんです。
特にやっぱりインターネットに公開されている状態なんですね。
なので、適宜リファクタリングといって、さっきおっしゃったようにLaravel（ララベル）のバージョンを新しくしたりだとか、
最近でいうとよくAWSがRDSのバージョンをアップデートしてくださいと。
しないと有料のサポートに変えますよって言って、
AWSのサーバー、データベース用のサーバーの費用が倍になってしまって事件が起きたりするので、
そういった意味でも強制的に、なかば強制的な感じで、
適宜アップデート、バージョンアップっていうのはしていかないと、どこかで詰まっていっちゃうって言われると思うんですね。
古いシステムの課題
なるほど。
AWSのあれ、ひどいよね。
うちが悪者みたいだって、お客さんに一生懸命説明しなきゃいけないみたいなね。
そうですよ、本当に。
仕方ないとはいえ、そこをもう少しね、そんなもう一気に費用が倍になっちゃうって、そんなことあり得ますかって話になる。
じゃあ使うのよって話になるかもしれないですけど。
なるほど。それ踏まえて、それでもできる限り長く使っていきたい、10年以上使っていきたいっていう要望があった時には、
先ほど辰巳さんがチラッと言っていましたが、うまくリファクタリングとかそこら辺を適宜していけばなんとかっていう感じになるんですかね。
島田さんいかがでしょうか。
そうですね。
つい最近もね、10年以上使ってるシステム、昔打ち入れたシステムなんだけど、それをずっと保守サポートも入っていただかなくてですね、
直してもらいたいっていうふうなことを相談されたんですけど、やっぱり古いので、どうしても10年ぐらい経ってるともうエンジニアがいないんですよね、その技術のね。
なるほど。
そこのお客さんの場合はコンプレ、社内にサーバー立てて使ってたんで、セキュリティ的には問題ないかもしれないけど、
あれがね、言語とかブラウザのセキュリティの考え方が変わったりするんで、昔やってたことができなくなっちゃうんだよね。
なるほど。単純に技術のアップデートとかそういうところではなく、コードとかその仕様自体がそもそも人が追いつかないみたいな、置いてかれるっていうところもあるんですね。
人が置いてかれてるのか、いや向こうが置いてかれてると思うよな。
システムが置いてかれてる、技術のアップデートは人間はできるけれども、システムは放っといたら何もできない。
人間の方だけどんどん進化しちゃってて、それが良いのか悪いのかわからないけど、やれる人はいないっていうね。
将来的にあれですかね、AIが勝手にそれを検知してリファクターしてテストして、もしかしたら将来あれやるかもしれないですね。
そうですね。
微妙ですか。まだまだ先の話だと思う。
お金がかかるからね。サーバーとかね、特にオンプレのサーバーとかって壊れるんで、そういうのはどうするのかって話もあるしね。
壊れる前に作り直してサーバーをまた新しくしましょうとかって言ったらどんどんどんどんお金がかかるんで。
そういう提案は多分中小の社長さんはなかなか言い上がるんだよなと思いますけどね。
なるほど。そんな形で負債が積み上がってしまったケース、長年使っていてこんな不具合出てきたみたいなケースとかってあったりします。
辰巳さんいかがですか。
僕が見てたやつはそれこそプラムザが創業以来ずっと付き合ってたお客さんで、本当に長いことシステムを作っていて、
一回大きなリプレイスをしてバージョン2みたいな感じでやってましたけど、それもやっぱり古くなってしまって。
システムの導入と保守の重要性
そもそもLaravel（ララベル）に関して言うと、Rubyとよく比較されるんですけど、Laravel（ララベル）って結構頻繁にフレームワークが新しくなっていくんですよね。
RubyだったらRuby on Railsが大体使われることが多くて、他にも一応あるんですけど。
Laravel（ララベル）だったら昔はCakePHPとかZendフレームワークとかいろいろあって、今はLaravel（ララベル）が主流だと思うんですけど、
1個2個前ぐらいの世代のずっとフレームワークとかが使われていて、それはPHPとしてはバージョン古いから、
想定していたコマンドが通らないみたいなことも全然ありますし、コマンドが通らないっていうのもなかなか説明がこれ難しいので、
これを使うのがちょっと悩みなものですけど。要はそれこそエンジニアがアサインされても、
ジュニアクラスの若手だと昔から使われている技術とかをキャッチアップするのもすごい時間がかかって、
フィットしないということも当然ありましたし、環境構築も本当にすごい時間がかかっちゃうみたいなこともあったりしますし、
実際それで保守運用をやっている中でも本当に原因不明のエラーが出てきてしまって、
それを流れに使っていることによって起因するバグとかも考え可能性としては全然あり得るレベルで起きてきていて、
どうしたもんかというところで最終的に他社さんで安くできる、かつリファクターもある程度するという話で、
他社さんに切り替えされましたけれども、果たしてそれが本当にうまくいっているのか、私は分かりやすいということも全然ありました。
なるほど、それを聞くとやはり技術負債が溜まっていくのはなかなか大変そうだな。
リスキーだと思います。かつやっぱりそこに目を向けたがらないんですよね、クライアントさん。どうしてもお金かかる。
かつそれがより良くなる機能の回収とか、機能が追加されるとか、もっとUIがリッチになるとか、そういう話だったらいいんですけど、
ならないことが防衛策だけでしかない。そこにお金を使いたがらない。ただやっぱりシステムって資産になるけれども、
なかなかお金はかかるし、それで本当に業務が効率化されるのかみたいな議論も結構常々されていると思うので、
なかなか経営者としては決断が難しいです。
定期的なメンテナンスの必要性
なるほど、しばらく使っていくには結論としてはどうしていったらいいんですかね。
たつめさんが言った通りですね、頻繁にアップデートしていくしかないんですよね、こまめにね。
言語だけじゃなくてね、フレームワークとかあとライブラリとかもどんどんバージョンアップしていって互換性がなくなっていったりするんで、
一つバージョンアップして、とりあえず無視しておこうかと思っているうちに他のもバージョンアップしていって、
三つ一つ溜まっていくと一緒にアップデートしようと思ってもなかなか難しかったりするんでね。
一個ならすぐパッチが当てられるんだけどってこともあるので、やっぱり保守をちゃんと結んで頻繁に見ていくっていうのが正解ではありますね、どうしてもね。
なるほど、延命のために定期的にメンテナンスしていくことが基本的に必須みたいな。
メンテナンスしつつ定期的にリファクターはやっぱり必要ですね。
大規模修繕か、みたいなものがあると思うんですけど、あれはやっぱり必要なんですよね。
なるほど、これ最初の作るときとか計画する段階でここは抑えておくべきみたいなことってあるんですか?
それはだから補修をしながら何をやっていくかって話をするのと、あと何年くらいしたらリファクター、完全に言語をね、見た目を変えるんじゃなくて中身の言語はアップデートしましょうみたいなね。
っていう話はしておいた方がいいですよね。
なるほど、長年経験がプラムザではあるので分かるところはあると思うんですけど、これ定期的なメンテナンスとか保守っていうのは必須、大事っていうのは当然として、最初の段階で保守とか更新っていうのを見据えて提案していかないと後々大変なことになるんだなっていうふうに改めて思ったっていうところですかね。
そんなところでどうですか、プラムザはそれも含めて最初に丁寧に話して提案しますよっていうところかなと思いますが、いかがでしょうか。
そうですね。
はい。
いつもこのまとめが難しいですね。
では、今回こんなところで終わろうと思います。
本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価をお願いします。
また、Xでも最新情報を随時発信していますのでよろしくお願いします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
