案件の炎上とは
この番組は、システム開発25年の株式会社プラムザが、アカスカより開発の現場の今と本音をざっくばらんに話していこうという番組になります。
進行は、私鴨志田と、代表の島田と、今回のゲストも引き続き、株式会社プラムザ執行役員の辰巳さんです。
A級ゲストです。よろしくお願いします。
よろしくお願いします。本日は、いつもと環境が変わりまして、Zoomで録音しているということを試してみているという形になります。
ちょっと初めての試みですので、ちょっと応答のタイミングであったり、音声の問題だったりも、ちょっとどうなるのかというところはあるんですが、ご了承いただければと思います。
そうしましたら、本日、なぜ案件が炎上するのかというタイトルになるんですけども、
案件は、開発をしているとか、補修をしているということを、案件と呼んでいるという認識であってますよね。
そうですね。
炎上というのは、具体的にどういうことを炎上と呼んでいるんですか。
炎上ですね。炎上の経験は誰が一番多いかな。辰巳さんですか?
いやー、しばさんの方が、さすがに出来は、子供と親ぐらいの差があると思うので、しばさんじゃないですか。
ちょっといろいろ僕もありましたけども。
炎上ね。開発をやっていると100%出来はするものですね。これはね。
うちの案件が燃えることもありますが、それもありますが、正直言ってね。
多くは、うちに問い合わせ来るお客さんで、炎上しちゃってるんで、何とかしてくださいというような、そういう相談は結構ありますよね。
で、何だっけ。炎上とはみたいな。
そうですね。炎上っていうのは、どういったことを炎上と呼んでいるのかなっていうのは。
そうですね。普通に納期が遅れるというレベルではなくて、開発をやっていて、納期遅れて、お客さんにこれどうなんでしたっけって質問をすると、お客さんが怒っちゃってですね、全然返事もこないと。
で、やっつけの回答が来てですね、それで作ると全然違うじゃないかみたいな感じで、完全に信頼関係が壊れちゃっていて、開発業者とお客さんの間ですね。
なんでもう、回復の目が立たないっていうような、そういう状況ですかね。
あれですよね。仕様が想定していたものと全然違って出来上がってきている状態だったり、ありえない数のバグが出ちゃったり、それを直す良さはもう念出できないみたいな感じですね。
お金が出なくなってくるんですよね。お客さんが完全に態度高下しちゃってるんで、追加予算の相談もできないみたいな状況ですね。
状況によってはもう裁判起こしてやるぞって。
なるほどですね。そうすると開発とか補修とか、何かトラブルはつきものっていうところで、それがどうすぎていたり、その対応側に不信感を募った結果、信頼関係が壊れるとか、コミュニケーションすらも円滑に取れないようになって、それを炎上という、ちょっといろいろ枠は広いかもしれないですけど、それは炎上っていう感じになるんですかね。
そうですね。単純な農協会とかじゃないっていう、もう関係が最悪になってるっていう状況ですかね。
なるほど。今回のタイトルがなぜ案件が炎上するのかっていう、これは逆説的にだとは思うんですけど、炎上はどうやったら防げるのかとか、とろびにできるのかって言い方が正しいのかわからないんですが、ちょっと納められる。
炎上の原因と予兆
どうしてもトラブルはつきものっていうところの前提の上、そういったところをお伺いできたらなっていうのをちょっと今話を聞いてて思いましたね。
そうですね。こうやったら防げるっていうところの観点でいうと、いろんな炎上のタイプはおっしゃられた通りあるんですけど、一番はやっぱりコミュニケーションで大きな食い違いが起きてしまうところが結構ありますよね。
例えばですけど、そもそも開発者とクライアント、双方あるいは片方の開発に対する熱量がなくて、ちゃんとコミュニケーション取ろうとしない。僕のケースで言うと連絡してもそもそもやっぱり初期段階において返事が返ってこなくて、忙しいのでちょっと時間取れませんと。
ミーティングも週1ぐらいしかできないですね。こちら側から質問した内容に関しては、ごめんなさい、ミーティングの時間になっても見れてませんでした。これが続くとちょっともう初っ端ですけど、結構危険信号になるのかなと思いますね。
予兆はやっぱりあるんですね。
あります。いわゆるとろびにするって話もあったけど、その前のぼやがちょっと出始めると思います。
島田さん的には何か、これぼやぼや来たっぽいなみたいな。
そうですね。うちも営業の段階でお客さんの方に強く言っておかないことが結構あって、結構負担がかかりますよっていうことを開発のときに言わないでやり始めるとお客さんの確保ができていなかったりするので、
待っていればシステムで出来上がるのかなみたいなふうに思っていると、結構大きな間違い。
だからサンキングはよく言うようにしてるんだけど、結構負担はかかりますよって言うようにしてますけど、
本当にお客さんがお客さん対策になってしまって、街の視線になっていると。
質問しても適当なことしか書いてこなかったり、今この段階で一番大事なのはすべての帳表をね、帳表って書類だよね、出したい書類を洗い出すことなんで、
全部漏れなく出してくださいよって言ってるんだけど、全部は出てこなかったりするっていうね。
こんなのがあって、あとはこんな感じのが何十種類かありますみたいな感じで、全部出てこないんで洗い出しきれなかったとかっていうことが結構あると。
それが後々大きな影響を及ぼすことがあるんだよね。
お客側にとって負担があるっていうのをちょっと補足すると、例えばですけど、さっき僕が開発のミーティングするにあたってこういう質問がありますと、
それをクライアント側で咀嚼するにあたって、自分たち窓口の人たちだけでわからないことってやっぱりあったりするので、
それを他の部署に聞いてみたりだとか、こういう機能はこれでいいですかっていう仕様の確認をするにもやっぱり社内で横展開するにあたって、
そういうふうに自分たちでまず理解して、それを共有して、フィードバックもらって、意見まとめてこちらに質問返すっていうのがフローに大体なると思うんですけど、
それがやっぱり結構な時間がかかるわけですよね。場合によっては部署間での関係であったりだとか、そういったこともあるので、
なかなかお伺い立てにくいっていうことも、当然冗長な確認も取るみたいなこともあるので、そういったところが積み重なるっていうのはあると思いますよね。
今話を聞いていて思ったのが、確かに開発会社に依頼するっていうのはプロにお任せするというところでやってくれるだろうっていうのは、
確かに一部そういう認識はありそうだなっていうイメージはつくなっていうのは正直思いまして、
ただ実際のところはある種、一緒の方向を向くといいますか、考えてみれば当然で、
良いシステム作るのに業務内容を知っているわけではないので、それをちゃんと汲み取ったり、
それをシステムに反映するにはどうしたらいいかっていうのを打ち合わせを綿密に重ねる必要があるというのは考えてみれば当然なんですけど、
開発会社にお任せするっていうのも一部理解できるところがあって、そこら辺のこのかも知らぬ中でもあったんですけど、
そのギャップっていうのが炎上につながるんだろうなって今聞いていて思ったところですね。
そうですね、タクシーの運ちゃんと客の関係みたいな感じで即答できるもんじゃないことがね、
さっき達美くんが言っているようにあるからね、他の部署に聞かないとわからないことってあったりするんで、
それを聞かずに会議に来ていただいてしまうと、そこで初めてこういう質問あったんですねって感じで、
じゃあちょっと聞いておきますっていう感じで、また2週間回答が遅れるみたいな。
うちのエンジニアが2週間、完全に2週間止まるわけではないけど、止まってしまうということになるんでね。
炎上案件の原因っていうのが今いろいろ話をお伺いしていく中で、
オフショア開発のリスク
コミュニケーション不足とか最初の認識のすれ違いとかシステム開発っていうものがどういうものか分かっていないっていうところ、
それは当然だと思うんですけど、そういったところから出てくるっていうのが、
それが案件が炎上する理由にはなってくるっていう認識であってますかね。
そのパターンもあるし、ちょっと前回から忘れてたけど、
まともな見積もり書いては取らないんだよねっていう会話だと思うんだけど、
悪い会社の営業が炎上覚悟で安い見積もり書き出してくるっていうのがあるんだよね。
あれは炎上してからなんぼだろうみたいな、そういう業者がいて、
明らかに要件不足とか功力不足がある中で見積もり書きで発注もらっていくんで、
炎上させて次の追加予算を引き出しにいくっていうことをやるんだよね。
そういう段階でこれはもう完全に信頼関係壊れて、
うちとかに何とかしてくださいって言って相談が来ることがあるんだけど、
ああいうパターンは回避しようがないというか。
業者側が炎上を仕掛けてくるパターンですよね。
あるんでね、それね、本当に。
それで言うと、その一例で言うと、オフショアも炎上の要因に僕はなりつつあるから。
当てはまりやすいかなと思っていて。
直近の僕は、逆にうちらで炎上になってしまってるか、
その炎上案件を巻き取るっていう案件も、
オフショアの開発会社に依頼していたクライアントさんがいて、
もうコミュニケーションがニッチもサッチもいらないと。
料金は安くてある程度はいいんだけど、やっぱりそのコミュニケーションがうまくいってないんで、
上がってきたものも全く使い物にならないし、
逆に業者側が質問に全く回答してくれない。
話が通じないっていうことは往々にしてあると思います。
すいません、オフショアって海外の開発会社って認識であってます?
はい、そうです。
例えばですけど、日本ってそこそこの経済大国で給料もそれなりにもらっているエンジニアさん多いですと。
だけれどもベトナムとかフィリピンとかインドとか、
そういった比較的に平均給料が安くて、
かつ同じようなクオリティを持っているエンジニアさんに委託することで、
受注額というか元々の金額をある程度抑えることができるっていうのがオフショア開発っていう意味ですね。
確かに今までのこの話だと、日本人同士でもコミュニケーション難しいのに、
それは海外の方とコミュニケーションがより難易度が上がるのは当然ですよね。
間におそらくオフショアの会社さんは日本語と英語ができる人、
単純な間のPMが入りますよっていうことがあると思うんですけど、
それでも難易度が高いのは変わらない。
それが炎上の一つになりつつあるんじゃないかってことですよね。
そうですね、いわゆるそれがブリッジSEって言われるんですけど、
その人自身がボトルネックだったりするケースもあったり。
やはり英語だとか日本語でコミュニケーションを取れるっていうのは、
会話ができると全然別の話なんですよね。
相手のことを理解できるとか、こちら側を組んだ提案できるとか、
そういった話も含めてコミュニケーションなので、それが全くできないと思います。
志村さんはオフショアの会社についてはどういうお考えなんですか?
オフショアはあまりいい経験がないですね。
うちも外銃のパートナーとして使ってたことあるけどね。
一人すごいできる人がいるんだけど、ちょっと面を離すと別の人が書き始めるんですよね。
ソースとかにコメントが入ったんだけど、それが明らかに違う人になっていて、
クオリティがガクッと下がると。
ちょっとクレーム入れて、これ誰が書いてるの?おかしくない?とか言うと、
また元の人に戻って、しばらくするとまた別の部下が書き始めてっていう。
誰が書いてもいいんだけど、同じクオリティを担保してくれるんだったら、
そういう混ぜ物してくる感じがするんだよね。
初めはいいなと思って安くて、この単価で、このクオリティいいなと思っても、
混ざったものが非常に低クオリティのものが混ぜられてくるっていう。
単価化すると、なんとかしてそういう安いものを混ぜ込もうとするみたいな。
それはどこの国とは言わないですけど、そういう特性たちを。
炎上の原因
オフショアの中でもある程度の低予算でやるけれども、そこがもう圧迫されつつあるから、
それを考慮してある程度単価の低いエンジニアを投入させてるっていうのも全然。
やらせながら教育しようと思ってるんだと思うんだけどね。
気持ちは分かるけど、それちょっと本当にやめてもらいたい。
ちょっと顔下の興味から話がずれてしまったところもあると思うんですけど、
炎上っていうタイトルのところに戻っていこうと思うんですが、
ストレートに辰巳さん、なぜ炎上案件って炎上するんでしょうか。
コミュニケーションのところが積み重なっていって、
お互いにゴールを共有できてないっていうのが一番だと思ってます。
あるいはそこの認識がコミュニケーションによってずれてしまってる。
例えばフェーズ1とフェーズ2、2つのフェーズに分かれて開発しましょうってなったときに、
フェーズの1個目のところで、ここの部分の機能までは抑えましょうっていう風にやってたところが、
その機能をもっとブレイクダウンしたときに、こういう機能も必要だね、
こういう画面が必要だねって話になったときの会話ができてないので、
ここはフェーズ2でやるんじゃない、ここはフェーズ1でいいんじゃないっていうところが起きたりして、
結果的にそれもフェーズ1のうちで収めましょうってなるじゃないですか。
だいたいクライアントの要望って。
そうなってしまうと、結果的にちぐはぐになってしまって、
意図としないバグが出てきてしまったりだとか、全然想定していたものでできないから、
これをフェーズ1のうちで納品しようと思っても使えるようなものじゃないので、
ちょっとそれは研修完了できないよっていう風に言われてしまって、
積もり積もっていって、じゃあこれをやらないと、あれもやらないとってなっていって、
炎上していくっていうのが直近のパターンです。
対策と提案
直近の。
あえて言葉を濁しました。
それを守るにはどういった術があるものなんでしょうか。
一つは本当に軸としたコミュニケーション。
どういうコミュニケーションを取ればいいかって話なんですけど、
本当にテキストだけじゃなくて、密に口頭でもしっかりやり取りしていって、
その口頭でも一体言わないっていうのを防ぐために録音するだとか、
終わった後にすぐ議事録を共有するだとかっていうのもそうですし、
あとはちゃんと僕たちで使っているようなバックログみたいなプロジェクト管理ツールの中に
全て書き起こしていく。
やっぱり見える化していって、
誰が見ても分かるような内容に仕上げていくっていうのは結構重要だと思います。
そこで認識の疎後とか不一致が起きてしまわないっていうのを
一つ一つ積み重ねになるんですけど、
それをやっていくっていうのは、
それだけでも足りないことはあるんですけど、
まず最低限それが必要かなっていうふうに思います。
ありがとうございます。
では島田さん、なぜ案件が援助するのか、
それをどうしたら守れるのかっていうところで
ちょっと意見を聞かせていただければと思います。
そうですね。
さっき言ったみたいな、
開発会社の方がわざとやるパターンは置いといて、
それはもう防ぎようがないんで。
それは置いといて、
普通の開発会社で普通のお客さんで考えるときに
なんで援助するかって、
やっぱり初めの話、
営業に結構問題があって、
うちなんかの場合だと、
営業やってるのがエンジニアに非常に近い人間だから、
やりにくいことは起こりにくいんだけど、
割と営業とエンジニアが分断されてる会社があったりすると、
営業が結構、
これはわざとやろうと思ったわけじゃなくて、
軽く考えて甘く考えたりして、
安受けをしてるとかいうことがあったりするので、
技術的に不可能なことを提案していたりだったり、
そういうことはないようにしなきゃいけないなっていうんで、
うちなんかもよく勉強会とかやって、
ちゃんと技術的な裏が取れるように営業するPMとかも勉強してるけどもさ、
そういうことを知って防いでいくっていうのは、
まず第一つかなっていうふうに思いますね。
確かにプラムザの人ってあれですよね、
技術的にちゃんと理解している人が提案をしているっていうのがありますよね。
そうね、あれをやらないとね、
何だっけ、某有名人の人が安く取ってきて、
俺がやるわけじゃないかって言っていた人いたよね、
自宅開発昔やった某インフルエンサーの。
僕が想定している人と多分しばんさんが想定している人が一致しているのかもわからない。
堀江さんとかね。
なるほど、あの人。
取ってきて、あとはもうエンジニアに任せて、
俺がやるわけじゃないかっていう、
そういうスタンスの社長とか営業マンがいたりするんだけど、
それ完全に炎上が目に見えてるんだよね。
うまくすればすごい利益がドカンと出るかもしれないし、
もしやったらめっちゃ足らないかもしれないっていう、
全く分かっていない当てずっぽうの水盛り描いてるっていう時点で、
炎上の火種をつけまくっている感じだよね。
なるほどですね。
そこら辺、いろんな炎上がありますし、
いろんな守り方もあると思うんですけど、
コミュニケーションとか、
特に最初の営業のところとか、
そういうところが大事になってくるっていうところですかね。
正直になりましょうと。
透明化。
そうなんだよね。
それがお客さんの方にもそれをお願いしないといけなくて、
お客さんにもこちらも正直になって、
透明化してやるんで、
お客さんもぜひそうしてもらいたいっていうのはね、
フェーズ1とフェーズ2で分けるっていう時に、
そういう話だったのになぜかしれないけど、
フェーズ2の機能がどんどんフェーズ1の方に詰め込まれていくみたいな、
そういうことをされると非常に予算が足りなくなってくるし、
もっと言うと構造上の問題もありますよね。
一括受容の従来の形態だと、
それがフェーズ1でどんどんやることが増えていって、
代金回収できなくなって、
我々も首が回らなくなるパターンとかもそれがあるので、
国内ラボ開発でやりましょうっていう提案も一つ、
策としてはありなのかもしれないですよね。
そうですね。
ラボの話だとまた15分くらいかかると思うんで。
これは別の機会ですかね。
じゃあ、今回はここら辺で大丈夫ですかね。
まとまりましたかね。大丈夫ですか?
まとまりました。どうですか?
島本さんまとめてください。
もう出ないよ。
ここはもうMCの鹿児島田さんにまとめていただきます。
じゃあもう終わりますね。
終わりますね。
本日はいかがでしたでしょうか。
楽しんでいただけましたらフォローや評価をお願いします。
またXでも最新情報を随時発信していますので、
よろしくお願いします。
システム開発に関するご相談がございましたら、
公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
