00:04
この番組は、システム開発25年の株式会社プラムザが赤坂より、開発の現場の今と本音をザックバラに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、今回ゲストは株式会社プラムザ執行役員の辰巳さんです。
3回目ですが、よろしくお願いします。 連続です。よろしくお願いします。
はい、というわけで、今回は…いきなり入っちゃっていいですかね?
今回の、毎度、内容を島田さんに考えていただいて…
えー、「情シス、仕事すな」というところで… 酷いですね、そんな。相変わらず尖ってますね。
どうなんですかね? 僕にはよくわからないんですけども。
そもそも、「情シス」っていうのはどういった… これは役職になるんですかね?
部署名かな。 一般的には情報システム部っていうやつですね。
大体どこの会社も、大きな会社になると情報システム部っていうのがあって、独立した部署があるんだよね。
そこにエンジニアたちがいると。
じゃあ、内部で開発してるみたいな感じなんですか?
そうね、開発してるところもあるけど、大体はやってないんだよ。
うち等の窓口になって、僕らに仕事を依頼してきたり、支持してきたりする場所ですよね。
じゃあ開発するための内部の取りまとめ場所ってことですね。
そうそう。
初め、お客さんから仕事が出るじゃない?
そういう時って情シスの人ってあんまり出てこなくて。
例えば人事部とか、村部とか、営業部とかっていうところが、こんなシステム作ってもらいたいっていうことで仕事出してくるんだけど、
じゃあうちがこういうシステム作りましょうって言って、見積もり書いて、通ったぐらいの時に見積もり、これいいですねって言って、仕事が決まりそうな時ぐらいに出てくるのが情シスなんだよね。
最初から出てこないのは何でなんですかね。あんまりそこの分野じゃないからね。
あれ何でですかね。
出てくる時、最初から出てくる時もあるし、現場担当者から2番目の情シスが出てくるっていうケースも。
そうね。
じゃあそこで、仕事すなと言ってるところなんですけど、そこで何かしら問題が。
あれはもう普段から痛い目を見てる瀧さんどうですか。
そうですね。いいケースもあれば悪いケースもあって、悪いケースの話を多分してると思うんですけど、
03:02
例えばですけど、そのままさっき島田さんが言ったように提案を出して、現場の担当者ベースでこれいいねってなるじゃないですか。
じゃあ次の決済というか、精査する人として情シスが出てきます。
それをチャブ台返しみたいな感じで、いやそれここおかしくないんですかみたいな。
これちょっと足りてないんじゃないですかみたいなことを言って、覆してくると。
で、最悪のケース、失注してしまうということがありますね。
まあまあありますね。
まあまあありますよ。
大体かけされるパターンとしては相当流れです。
システム開発を外注するにあたってのおめつ契約と言いますか、チェックする係。
前々回か前回かあったと思うんですけど、見積もりとか結構適当なところもあるから、
それをちゃんと内部で見ようという情シスがそこでひっくり返すということもあり得るというところ。
見積もりとお金のポコッと言うよりもですね、大体は提案内容ですね。
技術的な部分。
特にセキュリティ周りは結構厳しくて、例えば営業の部署からの仕事で、
営業の報告とかが外出先からもできるようにしたいとか、
売上の実績が外からも自宅からも見れるようにしたいとかっていうことを言われて、
だったらうちのシステムとしてはインターネットで接続できるような、
社内にあるんじゃなくて、AWSとか外部のサーバーにおいて、
どっかで見れるようにしましょうよっていう提案するじゃないですか。
そうすると営業の人はいいですねって、それを本当に求めたんですよみたいな感じで、
じゃあやりましょうってなった時に情シスの人が出てきて、
そんな情報を外部のサーバーに置くなんてダメだみたいな。
うちのシステムは昔からオンプレミスっていって、
社内のサーバーに置くことが昔からなってますからみたいな。
いろいろとセキュリティのレギュレーションがあるんで、
ダメですよ。そもそもダメですよ。
無理無理無理ってなってしまって、もうゴアさんになっちゃうみたいなね。
要は理想論を現場の人が語る部分で、
情シスの人が現実的な路線を行きたがるって感じですね。
あとは多分ですけど、そういうふうにシステムとか作って運用が始まって、
何か起きちゃったら、責任は情シスが取らなきゃいけなくなるから、
そこでリスクヘッジを取りたがる。
割と現場の声に応えようっていうところで、
プラムザとして提案とかするけども、
割とそんなリスクを犯さないっていうところを
情シスが止めてくるっていう。
そもそもですけど、やっぱり情シスの人たちの
06:02
社内での評価基準っていうのが、
営業の人とかだったら単純に成果を上げたり売り上げを上げたり、
受注件数を増やしたりしたらいいじゃないですか。
情シスっていかにミスなく、障害を起こさず、
平時の運用を続けられるかっていうところがあるんで、
そういうのを避けたがる傾向があります。
そもそもそんな新しいことをしてほしくないんですかね、
情シスの人たち。
そういうのを目標にしてないかね。
安全に、つつがなく仕事をしていただきたいというのが
情シスなんだけど、やっぱり社長とかは全然そうじゃなかったりするんで、
拡大していきたいとか、売り上げ上げていきたいとか、
コストカットしていきたいっていうのと、結構バッティングするんだよね。
ある種、そういう仕事でもあるっていうかね、
それとは別の、何でしょうか、
原理が働いてそうなっちゃってるんですかね、どうなんですかね。
そういうこともやっていかなきゃいけないのかもしれないけど、
そこをちゃんとね、会社が何を求めてるのかっていうのを分かって、
適当なところでバランスを取ってくれないと、
うちとしてはすごくやりにくいんですね。
そういう明らかに、いい情シスさんと悪い情シスさんが、
っていう話があったと思うんですけど、
悪い情シスさんが出てきたときには、どう対応してるものなんですか。
どうしてますね、これ。
ある程度はね、合わせてやりますけどね、
情シスさんが作ってるチェックシートみたいなのがあって、
ものすごい分厚いし、内容的に10年前の話じゃないかみたいな、
っていうのもあったりするんで、
そういうのでも合わせて対応してはいるんだけどね。
でも無駄だなと思いながらやってますんでね。
比較的歴史のある規模の大きい会社さんとかだと、
そういうことが起こりがちかもしれないですね。
そもそも情シス部門だけじゃなくて、
情シスの子会社みたいなのがあったりするんで。
アウトソーシングしてるとこもあって。
で、彼らはうちらの提案とかを見て、
ダメなしするのが仕事なんで、
いいっすね、割といいっすね、それやりましょうよとか言ったら、
存在価値はなくなるんで。
まあでも、情シスには仕事してほしくないと。
それが仕事でもありますし、
うまくいい意味で我々ベンダーを使って、
開発を成功に導いてほしいっていうのが、
我々の願いでありますよね。
そういうところも全然いるので、
僕が担当してる情シスさんもすごく良くしていただいて、
ちゃんと技術のことも分かってるし、
僕らとの信頼関係もしっかり構築しに来てくれるタイプの人なんで、
09:00
僕との相性の問題もあると思うんですけど。
そういうところだったら、僕らがこのぐらいの提案で、
こういう工数がかかります。
じゃあOKです、やりましょうみたいな感じで、
2つ返事してくれたりするケース全然あったりするので、
理想的ではありますよね。
辰巳さん的にはこういう情シスさんだとやりやすいみたいな、
じゃあ3箇条みたいなものをあげるとしたら。
1個目は柔軟な発想を持ってる人で、
そうですね。
2つ目がコミュニケーションをちゃんと取ってくれる人。
3つ目は何でしょうね、あんまり出てこないですけど。
コミュニケーション取りやすくて、
かつある種保身に走るような方ではなく、
柔軟に対応しようとするような方でやりやすい。
一緒に並走伴走してくれるタイプですよね。
それなりにリスクをちゃんと取ってくれて、
お互いにリスクを分散して、
1つのことに取り組みをしてくれるような人だといいですね。
島田さんもそんな感じになる?
そうですね。
保身の人は多いですよね。
言葉を選びながら言わなきゃいけないんですけど、
大体開発会社ではない会社に情シスというのがあるんですよね。
事業会社ですよね。
そういうところにいるエンジニアさんというのは、
開発会社から流れていった方が多くて、
なんとかそこで生きていかなきゃいけないと。
目立ちたい、存在価値をアピールしたいのと、
あと保身だよね。
それが2つ大きな行動の指針になっちゃってる人がいるんで、
そういう人はなかなか辛いですね。
会議中とかでも鋭いツッコミを入れる。
他の相手方のメンバーの中で、
これってどうなんですか?みたいなことを言うことによって、
この人、やっぱ分かってるんだ、みたいな感じで、
思われたいっていう。
思惑として。
突っ込もうと思えばいくらでも突っ込めるんで。
セキュリティとか。
いくらでも言おうと思えば。
そういう情シスさんの時、できるだけ寄り添うっていうことだったんですけど、
これはそもそも情シスっていう仕組みが微妙なんですか?
それを解決する方法みたいなのってあるんですかね?
それは人によるってところになっちゃうんですかね?
会社の方針にもよる。
社長の考え方もよると思うんだよね。
あんまり分かってない社長さんだと、
情シスなのは言いたい放題になられていて、
12:00
完全にマウント取られてることがあるんだよね。
情シスな人がこのシステムを作るかどうかを決める。
最終決定は情シスが決めるみたいなことがあるんで、
情シスはそういうパターンの時は仕事をしないでいただきたいと。
さっき言ったように、いい方がいらっしゃると思うんで、
そういう人はどんどん一緒に手を携えあってやっていきたいと思うんだけどね。
ちょっとずれちゃうかもしれないですけど、話したうちに気になったんですけど、
おそらく情シスを内部に持つってなった時に、
その人をどうやって選ぶかって結構大事なんじゃないか。
考え方ってあったと思うんですけど、
そういう時に島田さんからこういう人いいんじゃないかとか、
辰巳さんがここら辺は抑えといた方がいいとか、
例えばですけど、そういうのがあれば聞いてる方に参考になるかなとか
なんとなく思ったんですけど、何か思いつきます?
完全に無茶振りですけど。
情シスを作ろうと思ったことはないんだけどね。
こういう人がいいとかっていうよりは、
あなたの仕事はシステムを安全にすることはもちろんなんだけど、
会社のために役立つっていう方向で考える仕事なので、
安全に安全にっていうことばっかり考えればいいんじゃないんだよってことを
言っておく必要があるかなって思うね。
そもそも情シスを持つにということは、
事業会社が多いって言ってたじゃないですか。
そうすると開発のことは分かってないけど、
必要だからチェック役が欲しいってことじゃないですか。
それって別に外注すれば良くないですか?
してるところもある。情シス代行みたいな。
うちもやりたいんですよ。レンタル情シスみたいなね。
いいんじゃないですか。話を聞いてたら、
別に内部である必要は全くなくて、
むしろ外部の方が信頼性が上がったり、中立的だったりするんじゃないかって思いました。
あとは僕今思ったのが、
外注も一つの案だと思いますし、
情シスが良く機能するためには、
そもそもの原因が評価基準的な問題もあると思ってて、
そこをちゃんとベンダーを上手く使って、
システムの開発を成功に導いたりだとか、
っていうことを評価基準にしていくといいんじゃないかなと思います。
多少のミスとか目つぶって、
トータルでプラスになったかどうか、
会社の業績とか業務効率に良い影響を与えたかっていうのを
判断できるような基準にすればいいんじゃないかなって思います。
確かに。どう思います?
15:01
それはいいですよね。
昔だけどあるメーカーにいて、
大きな上場のメーカーがあったけど、
そういうとこも行った時はあるんだけど、
サーバールーム入れてもらって、
うちのシステム入れるって話だったけど、
何も口出してこなかったんだよね。
だけどしっかり後ろで見ていて、
何をやるのかしっかり見てると2人でがかりですね。
あれは非常にやりやすかったね。
ちゃんと何をこれからやるか言ってくださいって言われていて、
じゃあ次はこれをやりますって感じで作業をして、
それをちゃんとチェックして、
自由にやらせてくれると。
だけど全然違うことやって、
そうなったら何やってんすかってツッコミ入ってくるみたいな。
でもそれは理にかなってるやり方だったなと思いますね。
それ聞いて思ったのが、
そういうふうに悪いこと、
変な仕事をしてしまう情シスの人の特徴として、
多分あんまり開発のこと知らないから、
怖くて行っちゃうんじゃないかなと思って。
分かってたらね。
分かってたら、
これそういうことだから問題ないねって判断できると思うんですよ。
結構それなりに開発の会社とか、
自社でサービスをエンジニアを抱えてやってるようなところの出身で、
かつ柔軟な思考ができる人だったら、
話を聞いたらそれが良いか悪いかって多分判断できると思う。
我々が良い提案をしてさえすれば、
多分情シスの人ってそこを否定してこないと思う。
だから僕さっき言って評価基準と、
担当者個人単位での知識っていうところが重要なんじゃないか。
確かにそもそも知識がなければ、
さっき言った島田さんのチェック方式と言いますか、
それがおかしいとかそれまで見守ってられるみたいなところが、
そもそもできないですね。
できないからね。
何やってるか分からないみたいなね。
何やってるか分からないと不安じゃないですかね人間って。
そんなところですかね。
結構常識というだけでなく、
例えば人を雇うとか、
人を外求するっていうところにあたっても結構、
参考になる話だったなと個人的に思いました。
ではこんなところで、本日はいかがでしたでしょうか。
楽しんでいただけましたらフォローや評価をお願いします。
またXでも最新情報を随時発信していますので、
よろしくお願いします。
システム開発に関するご相談がございましたら、
公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
