システムの引き継ぎニーズ
不丁寧するほど話したい、この番組はシステム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、賑やかし役の辰巳です。よろしくお願いします。
よろしくお願いします。
さて今回のタイトルですが、長年社内で作ってきたシステムがあるけど、今後はそれをプロに任せたいというご要望よ、というタイトルになります。
これは正直このタイトル、島田さんに挙げてきていただいたタイトルになるんですけども、ざっくり概要をお伺いしてもよろしいでしょうか。
そうですね。これをですね、また今回取り上げたのはですね、こういう要望が非常に多いんですよね。
直接問い合わせしてくるお客さんもいますし、マチューサイトのほうからもですね、こういうご要望がたくさん上がってるんですよね。
簡単に言うと、ずっとね、社内でね、できる人がいたんでやってきたと。20年と逆を使ってるシステムもあったりして。
だけどもさすがに作ってきた人も年がだんだん高齢になってきて、その人だけに任せていくわけにはいかないので、プロにそういうシステムのことはお任せして、専門は専門でね、業者にアウトソースしたいみたいな、そういう要望が結構あるんですよね。
なるほど。長年、社内の社員さんとかが作ってきたものを引き継いで回収および保守等をしていくっていう案件の場合の話ってことですね。
業務における理解不足
そうね。回収またはゼロから作り直してほしい。機能はそのままにして、別のプラットフォームだったらそれでもいいので、作り直してほしいとかっていうのも含めてですね。
結構いますよね。社内で1人だけめっちゃエンジニア出身でコードかける社員さんがたまたまいて、私システム作れますって言って、出来上がったシステムを長年使われ続けていて、ありがとうございましたって退宿するタイミングで、誰もメンテできないみたいな。
あるね。
あるあるね。
タイトルにご要望という含みがあるわけなんですが、これは結構大変なことが多いというニュアンスになるんですかね。どうなんでしょうか。
大変ですね。大変は大変で、うちとしてはやる気は満々なんですが、お客さんの方が割と簡単に考えられることが多くて、そこのギャップが問題になることが多いですね。
なるほど。確かに出来上がっているというより、実際使っているシステムですもんね。作ってきて使っているシステムを引き継ぐのに何をそんなに大変なんだ、みたいな認識の底があるという感じなんですね。
素人が作ったもので簡単でしょ、みたいなプロがやると。みたいな意識が社長さんにあったりするんで、非常に苦しいことがありますね。
そうですね。そもそもそれを引き継いで回収していく、運用していく、作り変えていくにしても、ソースコードさえ読めればなんとかならなくもないところはあるんですが、やっぱりそれも結構難解であったりとか、
ドキュメントとかを見ても、明らかに自身で微暴録的に書かれている感じで、他者が読む前提で作られていなかったりとか。
確かにそれはありそうですよね。引き継ぐとか誰が見ても分かりやすいような形で残されてはいないというところですね。
そうですね。周りの人は分からないし、とりあえず書くけど、まあいっかぐらいな感じになっていると思うんですよね。
それが悪いとは言わないですけれども、当然。
悪いとは言わないんでね。やっぱりその社内で通用すればいいし、分かんなかったらその人が教えてあげればいいんで、
そういう例えば10人くらいの会社だったりすると、もう多分それがベストプラクティスですね。
現場からあがってきた要望があったらすぐ分かったら直してあげるとかつって、作ってしまって2日とかで作っちゃって、
後からその機能を使いたい人にはその人が教えてあげると、こうやって使うんだよみたいなね。
ここの欄でプラスを押すとこうなるんだよみたいな。初めて見ると分からないんだよね。
そうですね。
新規作成はプラスボタンなんだよみたいなね。
そこは本当に特殊な仕様であったり、技術的な部分が促進性によって作られているものが多くて、
これどうしようかみたいなのが結構起こり得るのかなっていう感じですね。
こちらとしてはそういうお客さんからの相談を受けると、業務理解から入っていくわけなんですが、
基本的に社内で作られたシステムの、社内のエンジニアさんっていうのは業務理解が半端じゃないんだよね。
もっと言えば既存の業務は分かっていつつ、将来ここあるべきまでも分かっちゃってるんで、めちゃくちゃ詳しいわけだよね、その業務にね。
すごいニッチな便利機能とかがそこに組み込まれてるんで、なかなか想像つかない、こちらとしてはね。
そうすると社内で開発していると業務の理解が当然進んでいるので、
そういった軽いところに手が届くようなニッチなことも結構作られている。
反面、それが引き継ぎだったり分かりやすいようにはできていないというところもある種、罠みたいなところがあるってところなんですかね。
トラブルの原因
さらにそこにシステムの画面とか見た感じでは察せない特殊な運用とかもしてたりするんですよね。
あとね、本人は全然特殊なことやってると思ってないかもしれないけど、それすごく特殊なんだよって見たことが結構あったりするんですよね。
さっき言ったみたいな、ここの入力欄でプラスを押すと新規登録になるとかっていうのを、
昔、自分で実際やった案件でインターネットエクスプローラーだけで動くような機能があって、
その欄に行くと日本語入力システムのIMEがオフになるんだよね。
プラスって押すとプラスキーで反応して新規登録画面に飛ぶみたいな動きになってて、
当然気づかないわけだよね。
お客さんが電話するときに、私はクロムで見てたりして、クロムで動くんで、
そこまでお客さんが言ってくれなかったりして、言われなきゃ気づかないからね。
プラス押しても多分クロムだと動かなかったと思うんだけど、そうするとそういう機能ないんだろうというふうに思ってしまうのはしょうがないよね。
そうですね。お客さん自体も分かってないこと多そうですもんね。
そうそう。とにかくこの環境の中で動けばいいだけなんで、他の会社に売るわけではないので、
動いたらもうそれ以上調べないですからね。これが汎用的な機能なのかどうかっていうのはね。
確かにもっと身近に考えてみると、自分が取っているメモとか絶対見せられないですもんね。
自分さえ分かればいい。
そう、自分さえ分かればってなっちゃってたり、あとそれこそ全然余談なんですけど、
確定申告の帳簿とかをスプシとかで自分で作ったのとかで使っていたりとかするときに、
項目の追加とか全然分かりやすいところにしないじゃないですか。ここに突っ込めばいいみたいな。
自分が分かっていればいいみたいな。確かにそれを考えるとそれが業務システムになってるっていうのは結構恐ろしいですよね。
それが実際に発注いただいて、じゃあやっていきますってなったタイミングで、
そこのギャップがある状態で進めるといろいろとトラブルの元になりやすいですよね。
今まで結構俺は大変だったなーみたいなそういうシステムってあったりします?どうでしょう?
いや、たくさんあるよ。たくさんある。いろいろ言いにくいところもあるんだけども、
うちはね、これ見落としたなとか大変だったなって思ってもやりきるけども、
とても無理っていう会社も多いと思うんでね。これ無理ですって見落としましたみたいな。
それもある種揉めそうですよね。やるって言ったじゃんっていうところじゃないですかね。
揉めるよね。だから基本的に全部が全部じゃないけども、
社内システムの引き継ぎの課題
お客さんとしては一括の受け入れの時って、なるべく簡単だと思ってもらいたいと業者にね。
っていう動機があるわけですよ。
それはそうですね。自分たちのシステムが難しいだろうとまず思うことはないでしょ?
思うことはないし、いろいろ核的なのがあるんだよっていうこともちょっと黙っておいて、
見積もりをさせて仕事は決まってからね、ポロポロと言い出そうかなみたいな。
そういう動機はどうしてもあるじゃないですか。
確かに最初に出してもらった見積もり、多少動くことを許容するにしても、
最初こう言ったのにそんなかけ離れるみたいなところは確かにお客さんとの時にも
言いやすいのかもしれないですよね。
そうなんだよね。だから社内システムってちょっとね、
たくさん社内システムの引き継ぎみたいな相談を受けるけども、ちょっとやっぱり警戒しますよね。
こちらとしてはね。
そんな時、島田さんはどういう切り口で進めていくんですか?
そうですね。最近はあれですよね。
例えば1カ月は難しいなというふうにちょっと思ってるね。
うちで言うとラボ。
国内ラボ型っていうのを準委任契約でやっていけば、
そこはお客さんも言い忘れていたところがあれば、
後から言ってもらっても別に構わないわけだからね。
そうですね。
何度となくこのポッドキャストでラボ型の話をさせていただいていますが、
改めてこのラボ型だと何でこの引き継ぎの時に便利なのかということを
ちょっと島田さんお伺いしてもよいですかね。
1カ月契約では基本的に三つ文を書く時に何をやりますっていう、
要件定義って言うんだけど、
それを約束をして何をやりますリストだったらいくらっていう
三つ文字を書きますよね。
そこがそもそもの問題というか、
こういう隠れた機能がたくさんあるようなシステムを作る時は
絶対後でいざこざになりがちなんですよね。
要件定義、最初に出す時とか三つ文で書く時に調べきれない、
わからないっていうことを往々にしてあるってところですね。
そうです。さっきも言ったみたいにお客さんとしては
なるべく簡単だと勘違いしてもらいたいっていうのがあるんで、
要件定義もよく見ないんでね。
なんか簡単に書いてるわみたいな、しめしめみたいな感じになってしまうんで。
だけど国内ラボ型開発って言うとね、
Azureとかね、順位任契約でやると動いた分だけ請求させてもらうんで、
後からすごい機能が見つかったらそれが当然コストかかっていくんで、
そこは問題ないという感じですね。
そこの相手もお互いに真剣になれます。
嘘を偽り、透明感を持って。
確かにその最初の段階で隠しておこうみたいなところは
少なくともなくなりそうですよね。あんまり意味がないと言いますと。
隠しても意味がないからね。
ラボ型開発の利点
一括受け型だと開発者側の心理としても、
できるだけコストを抑えてやってやろうという気味にもなってしまう。
そうすると無理です、無理ですって恥じいちゃったり。
それがトラブルの左になりやすいかもしれないですよね。
業務システムって少なくとも5年、7年、下手したら10年使っていくようなもんなんで、
作った業者と仲が悪くなるっていうのはあまり良いことじゃないと思うんですよね。
そうですね。
確かにこういった引き継ぎのシステムだと、
ラボ型だと同じ方向は向きやすいというのが明確に分かりやすかったかなという印象ですが、
何か他補足ありますでしょうか。いかがでしょうか。
先ほどの話で自分もメモが続かなくて、
メモ書きの字は誰も読めないので、
落としても安心という、どこかに混ぜてきても安心というのがありますとだけ付け加えておきたい。
以上です。
ありがとうございます。
パスワードの流出等は前回の配信を聞いていただけると、
もろもろ面白いところが対応策と分かると思います。
という部分なところを付け加えたところで本日は終わりたいと思います。
本日はいかがでしたでしょうか。
楽しんでいただけましたらフォローや評価をお願いします。
また、Xでも最新情報を随時発信していますので、よろしくお願いします。
システム開発に関するご相談がございましたら、
公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
