リニューアルの基本情報
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をザックバランに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、賑やかし役の辰巳です。よろしくお願いします。
さて、今回のタイトルなんですが、業務システムをゼロから作るのとリニューアルするのではどちらが安いのかというタイトルになります。
まずリニューアルといっても結構幅広いと思うんですけど、基本的にリニューアルってどういった形になってくるんでしょうかって、ちょっとざっくりした質問になるんですけど、辰巳さんお伺いしてもよろしいでしょうか。
そうですね。以前お話ししたパッケージとかフルスクラッチで作ったシステムが大体対象になることになると思うんですけど、
そういった既に運用している実態のあるシステムとかサービスとかがあって、それを何かしらの形で、それをベースに作り直すっていうのが基本的な考えであっている。
なるほど。その場合って結構リニューアルといっても小さいものから大きいものまでありそうっていう感じなんですかね。
ありますよ。本当にサイズ感だったり、どういう温度感でリプレイスするみたいなのが結構お客さんによってまちまちだと思いますね。
なるほど。そうすると物によってはかなりほぼ全面回収といいますか。
そうですね。特に現行のシステムが長寿のシステムとかだとよく起きがちですね。結構大規模リニューアル。
長寿のシステムというのはどういったものですか。
例えばシステムの寿命って、原価消却の期間とかいろんな考え方とかもあると思うんですけど、大体5年から7年ぐらいからそろそろちょっと考えた方がいいかもっていう感じなんですよね。
それがもう10年とか使ってるシステムとかあるわけですよ。それを言い方を選ばずそれを無視して、あまり予算がかけられなくてというところもあると思うんですけど。
そういうものになってくると本当にもう画面もね、何でしょう、僕の世代しかわからないかもしれないですけど、あの全略プロフィールみたいなUIになってたりとかするわけですよ。
全略プロフィール?
これちょっとわからん。
もう少しわかりやすくと、HTMLとCSSだけでも作ったようなシステムみたいなのもあるわけですよ。
なるほど。まあちょっと具体的に名前出すとあれかもしれないですけど、阿部寛さんのホームページに。
それに近いレベルのシステム。まあそれはちょっと極端な例かもしれないですけど、それぐらいのものがあったりするんですよね。
この他の僕が2年ぐらい前にやった案件とかだったら、全然現役で動いているけれども、ララベルとかPHPとかプログラミング言語のバージョンをリファクタリングしてあげていきたいみたいなものも一応リプレイスに入りますよね。
で、UIはほぼほぼ変えずに、若干使いにくいところを修正だけしてみたいなことも全然あります。
話を聞いてちょっと思い出したんですけども、リニューアルにはおそらく、例えばPHPとかのバージョンアップ対応とか、そこら辺もリニューアルに含まれてくるっていうところですかね。
それはリファクタリングだけに留まることが。
なるほど。
本当にコンセプトからちょっと考え直して、今度はこういうことをやりたいだとか、もういらないのでなくしたいだとか、ちょっと画面が使いにくいので設計から考え直したい。
ところからリニューアルっていうふうに考えると思うんで、シンプルにバージョンを上げるとかっていうのはリファクタリングなのかな。
ありがとうございます。島田さん、このリニューアルについて大体そんな認識であってそうですかね。どうでしょう。
そうですね、見た目変えないで言語だけバージョンアップするとかっていうのはリファクタリングっていう話ですかね、どっちかっていうとね。
多分今日の話はそういう系の話じゃなくて、見た目からガラッと変えたいとか、あるいはもうデータベースの構造も全部変えたいとかいうことも考えていくのがリニューアルですかね。
リニューアルとゼロから作るのはどちらが安いのかというところだと思うんですが、やはりイメージとしてはリニューアルの方が安く済みそうだなって思うんですが、タイトルから察するにそういうわけではなさそうだっていうところはあるんですが、その辺実際どうなんでしょうか。
リニューアルの課題とコスト
これを島田さんお伺いしてもよろしいですか。リニューアルの方が安く済むものなんでしょうかね。
そうですね。よく建築のテレビ番組であるじゃないですか。
ビフォーアフターみたいな。
ビフォーアフターか。ああいうのも元々の使いにくい間取りとかをプロの今時の設計師が見て、壁とかガンガンぶっ壊して作っていくみたいな。
そうするとお値段1500万とかね。でもすごい素敵になるみたいなのがあるじゃないですか。
ああいうイメージだとやっぱり完全に作り替えるよりはリニューアル、あるいはリフォームした方が安いっていうイメージがあると思うんですけども、システムの場合は多分そういうことはないんですよね。
基本的には前任の前のシステムの作ったシステムエンジニアとかプログラマーの意図を組みながら作っていくっていうのは結構大変なんですよね。
そこがコストがちょっと増えるところですね。
いわゆる解析作業ってやつですよね。
解析してね。データベースの構造を生かすのであれば今までのデータベースと整合を取りながら作っていかなきゃいけないんで、
全ての意味を一回解析して分かった上でそれに新しい思想を組み立てていくんで結構前の設計者の思想に引っ張られますからね。
なるほど。以前、島田さんのブログで良いソースってのは分かりやすいソース、誰が見ても分かりやすいソースだっていう風に書けみたいなこと言われたみたいなことは今ちょっと思い出したんですけど、
そういう風に書いてあるソースコードだけでとは限らないっていうことも往々にしてあるってことなんですかね。
そうですね。分かりにくいことは往々にしてありますね。
すごい綺麗にシンプルで腕の立つ人がシンプルに書いてるものって割と真似しやすいんですけど、そうでもない人がコテコテコテコテ書いたのを真似するのは非常に難しいんですよね。
そういった場合だとリニューアルある種しやすいっていうか、リフォームでいうならある種土台が見えやすいみたいなところになってくるのかなと思うんですけど、実際それはやってみるまで分からないものなんですかね。
ソースコードとかデータベースの設計書とか見れればある程度、あとは現行の画面にログインしていろいろ触ってみたいとかできたらある程度イメージつくと思うんですよね。
ただその中には非協力的な前任の方がソースコードを開示してくれなかったりしたとか、本当に親切な方だと打ち合わせとかもさせていただいたりとかも全然あると思うんですけど、そういうこともなかなか起きにくいっていうのが現状ですよ。
仕事がなくなるわけですから。
そうするとやはりリニューアルといってもコストがかさんでしまう場合も大にしてありそうだなというふうに思うんですけども、こういった場合はゼロから作った方が作り直した方が早いみたいな場合だとどういったパターンがあったりするんですか。
基本的にもうやりたいことが全然変わってきていて、データベースの定義自体を大きく変えなきゃいけないと不合理、それを引き継いでいくのは不合理っていうときはかなり全面的に変えていく必要があると思うんですよね。
あと今辰巳さんが言ったみたいにね、前の開発会社がすごく非協力的であったりして、あと意味がわからない。ステータスが1から9まであるんだけど、それの意味が全然わからない。その人のインマイヘッドになってて、仕様がこちらでは想像もつかないみたいなね。
よくあるんですね。2つのステータスの組み合わせで挙動が変わるとかっていうときに、何の仕様もまとまってなくてですね、その人だけの頭の中に仕様があってわからないということがあって、どこがどう影響するのかわからないみたいなね。
そういうときはもうゼロから作って、新しい思想できちんとドキュメントをまとめながら普通に作っていって、前のシステムからデータを移動してっていうのを不整合がないようにしていくみたいな風にして、きれいにしましょうと。
わかんないものはわかんないで、とりあえず置いといて、後からうまく動かないところがあったら修正していくみたいなね。
新しいワールドは新しいワールドでもきちんと整合しているという状態にしておくのがきれい。せっかくリニューアルするんだったらそうあった方がいいんですけどね。
ゼロからの構築の選択肢
データベースの形はそのままにして、見た目だけモダンにしていこうって話もあるからね。それも一つのリニューアルなんだよね。
お客さんから見ると全然変わったっていう風に見えるかもしれないけど、実際は中身はあんまり変わってないみたいなこともあって。
そういう風に見た目だけ変えるって言うんであればデータの移行も必要ないし、前のシステムのデータベースの意味全部わかってるって前提でなきゃそれは無理なんですけどね。
わかってるんであれば表側だけ全面リニューアルするっていうのは別にできますよね。
そうですね。リニューアルにも簡単に言うとちょっと直すっていうところから結構重たいリニューアルあるっていうところまで含めてリニューアルがあると思ってるんですが、
今の話の内容的にはそうなのかなと思ってるんですが、やはりお客様の目線で考えると結局ゼロから作った方が良いのか、このままリニューアルした方が良いのか、
結局コスト的にどうなのっていうところが単純に聞きたいところなのかなって思うんですが、そこら辺の線引きはやっぱりもちろんプロジェクトごとによるっていうことが大前提だと思うんですけど、
わかりやすい判断軸みたいなものとかってあったりするんですか、こういったパターンだったらリニューアルは避けてゼロから作り直した方が良いとか、
そういったところがちょっとでも指針があると助かるなと思うんですが、辰巳さんいかがでしょうか。
まあでもさっきの話の通り前任の会社が協力的であるっていうのとか、あとはいきなり提供っていうのは難しいかもしれないですけど、
仕様書なりデータベースの定義書とかソースコードとかを一度お見せいただければある程度判断できるかなとは思いますね。
そこがないとちょっと逆に判断が多分できない気がしますね。
辰巳さんいかがでしょうか。
そうですね。何でリニューアルするかっていう、そもそもの目的ですよね。
古めかしい、例えばユーザー向けのサイトでもう古めかしいというのを、これちょっとシステムの信頼度的にちょっとまずいんじゃないかみたいな時に、
モダンなUIにしようみたいな、そういう話であれば結構簡単だったりするんだよね。
UIだけを直すのであれば比較的簡単なリニューアルで済むと。
業務システムの限界と必要性
ただ複雑な業務システムとかでもうこれまでカスタマイズをですね、機能の修正をつぎはぎつぎはぎでやってきて、もうですね、
うちが作ったシステムでもですね、もう限界みたいなのがあるじゃないですか。
雪だるまがどんどん積み上がっていっていて、もうハウルの動く城みたいなのがガタピシ言ってると。
ちょっと修正するとどこに影響するかわかんないみたいな。
辰巳さんがさっき言った10年とかじゃなくて15年とかね、使ってるようなシステムあったりするんで、そういうのはもう限界なので、
仕様書を張ろうってなるからほうがですね、ちょっともう全面的に始めから作り直したほうがいいんじゃないかと、新しい思想でね、っていうのはありますよね。
なるほど。
他のこの自社サービスとかでも大体そのもっと短い期間で大幅にUI UXを刷新したりとかリブランディングとかしたりするんで、
なかなかだと思います。それを1行のシステムが15年使うなんて。
そうね。でも辰巳さんが初めに、うち来て初めにやったやつなんかそれぐらい使ってるんじゃないかね。
そうですね。なかなかでしたね。
そこら辺の判別するために最初ヒアリングっていうのはもちろん重要になってくると思うんですけど、
実際進めてみないとわからなかったみたいな、ある種の失敗事例みたいなものとかってあったりするんですか。
これは結果的にゼロから作ったほうが簡単だったなみたいなこととかってあったりします?
それもたくさんありますよ。
なるほど。
昔から考えたらたくさんありますね。
やっぱりお客さんとしては今のやつを使ってもらいたいって言ってくるし、予算を取れないんでできるだけ活かして、
ちょっとした修正でできないかっていう相談を受けますんでね。
それに応えようと思ってやるとですね、割と大変だったみたいなね。
割とっていうかすごく大変だったっていうことが結構ありますよね。
なるほど。
パッケージからフルスクラッチとかフルスクラッチとかパッケージに行こうっていうのは結構大変な印象がありますね。
これは個人的な感覚かもしれないですね。
パッケージからフルスクラッチは難しいと思いますよ。
パッケージはパッケージで汎用的にものすごい機能が考えられて集約されてるんで、それをゼロから作るのは大変ですからね。
なんかそのデータベースの汎用カラムみたいなのが大量にあってですね。
ああ、はいはいはい。あれはきついですね。
データベースのカラムの名前から用途が全く推測できないんですよね。
フィールド1、フィールド2とかって名前になっててですね。
何かの仕様書とかないと何使ってるか分からないんだけど、その仕様書がないみたいなことがあるんで。
なるほど。
じゃあ最初のヒアリングの段階で、やっぱりどうしても詰めきれないみたいなことってあったりするんですか?どうでしょうか?
そうですね。基本的にリニューアルの時はですね、うちが作ったものだったらともかくとしまして、他社さんが作ったものについては現行のシステムを見せてもらうっていうことになるじゃないですか。
まあよくあるのはですね、お客さんとしてはなるべくこのシステム簡単だって思ってもらいたいっていうのがあるんですよね。
そうすると見積もりが下がるような気がするという。
まあイメージとしては分かりやすいですね。あるものを活かすならみたいな。
そうそうそうそう。もう4LDKのマンションじゃなくてこれは2DKなんですよみたいな感じで、こじんまりとしたもんですよっていう感じで説明されるんですけど。
それで解析していくとですね、解析して頑張って探しますけど隠れた扉がたくさんあると。奥にたくさん部屋があるってことがあるんですよね。
そういうことになって後からですね、見積もりの時に説明されてないんですけどみたいなことになってトラブルになっていくっていうことが結構ありますよね。
最初で要件詰められればそれに越したことはないが、そうはいかない場合が先ほどもリニューアルのまま進めて失敗したというところもあったと思うんですけど。
そういった失敗もあるので、基本的にはよく見えないものがありそうだなというときには結果としてコストもかさんでしまうので、ラボ型とかで対応していくのが良いという感じになるんでしょうか。
そうですね。結局そこで当初聞いてなかった機能がたくさんあるんですけどって言って、そうですかって言ってすぐ予算が取れるので全く問題ないんですけど、普通はそういうことにならなくてですね。
お客さんの方はリニューアルできるって言ってたじゃないですかって話になって、結構その時点で信頼環境が壊れていってしまうということはありますんで、信頼環境が壊れるとなかなかプロジェクトってうまくいかないんですよね。
なのでラボ型、うちでやってる国内ラボ型開発とか、準委任系でやっていくのが一番良いかなと思いますけどね、複雑なシステムのときはね。
ありがとうございます。
リニューアルのリスクと提案
辰巳さんから最後、何かあったりしますでしょうか。そろそろまとめに入ろうと思うんですが。
国内ラボ型であれば、本当に透明性だったりだとか、やった分だけお金が発生するっていうところになるので、お客さん側としても、
準委任じゃなかったら真剣じゃないかってそうじゃないかもしれないですけど、より真剣に考えて、お金が発生するから無駄のないようにしっかりやっていきましょうっていう社内の統制にもつながると思う。
まず小さく進めていくっていう意味でも、そこら辺は非常にお勧めなのかなと思いました。
ありがとうございます。
そうですね。ゼロから作るのか、リニューアルした方が安いのかっていうところは、もちろんプロジェクトとか内容によるっていうところは大前提になると思うんですが、
そこら辺最初で分かるようによくヒアリングをさせていただくんですけども、それでも見えない場合は、ラボ型の提案とかもするかもしれないというところと、
そこら辺の目利きとか判断というのはなかなかやはり難しいと思いますので、ぜひプラムザに気軽にお問い合わせいただければと思います。
最後までかみかみでしたが、本日はここら辺で終わろうと思います。
こんな感じで。
良いでしょうか。
大丈夫です。
本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価お願いします。
またXでも最新情報を随時発信していますので、よろしくお願いします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
