システム開発の問題点
ふて寝するほど話したい。
この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今人本人のザックバランに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、賑やかし役の辰巳です。よろしくお願いします。
よろしくお願いします。
今回のタイトルですが、なぜ大手に頼んだのにバグだらけのシステムが納品されるのかというタイトルになります。
記憶に新しいのは、アクセンチュアと日本通運さんのシステム開発の事故といいますか、損害賠償等起きているというところだったり、少し経路は違うかもしれませんが、以前ですとNHKとIBMの話もあったかなと思います。
すみません、ちょっと記憶が曖昧ではあるんですが、アクセンチュアと日本通運さんのって、一応システムの開発は途中までできてて、確かテストの段階でダメだったみたいな感じでしたっけ、覚えている方。
アクセンチュアとしてはもう開発終わって納品できるよという認識なのに、日通さんとしてはテストも終わってないし、そんなもう作って終えてないでしょっていうのが概ねの流れですかね。
確かにそうだね。
それは結論、どういったところが問題っぽいよねという話になったんでしたっけ、要件定義不足でしたっけ。
当時のエピソード。
ポッドキャストもう一回聞いてもらうという形で。
もう一回聞かないとちょっとごめんなさい、結論どんな感じだったか思い出せないです。
ただ最後の結合テストをアクセンチュアはちゃんとやって通ったよって言ってるんだけど、そんなんじゃダメでしょ、機能がだってそもそも足りてないしみたいな話で、テスト項目が足りてないとかそういうような感じで、これじゃあ業務回らないよみたいな。
それか当初の要件定義の段階から仕様が変更とか追加されたりだとか、そこの時点での認識違いがあったみたいなのもあり得ると思いますね。
大手企業の構造的課題
なるほど、これってそんなにないのか、もしくは大きいものが目立ってるだけなのか、大手あるあるなのかどうなんでしょうかね。
これはですね、大手あるある結構ありますよ。
そうなんですね。
小さいところがトラブルを起こさないかってそんなことないんだけど、大手は大手で特有のトラブルが起きますね。
これは要件定義の不備っていうところになってくるんですかね。
大手の場合は基本的には自分たちの会社の中にプログラムを書く人間ってほとんどいなかったりするんですよね。
なるほど。
それを多重請負構造になっていて、大手が中堅に出し、中堅がちっちゃいところに割り振って作っていくんで、結構要件を書類で通達していく感じになるんですよね。
なるほど。
難しくなってくるというのがまず第一の理由ですよね。
いわゆるIBMとかアクセンチュアとかそこら辺がやるお仕事っていうのは仕事を取ってくるっていうのと、
大枠の流れとかマイルストーンとかをドキュメンテーションに起こすぐらい。
あとそれをもとによろしくみたいな感じでやることが多いですよね。
だから実際のコーディングをする人はその一つじゃないんですよね。
全然いなかったですけどね、社内にはね。
そうすると不備と言いますか、細かいニュアンスまで伝えきらずみたいなところになってきて、そもそも話の詰めが最後までできてないみたいなところになってくるんですかね。
そうですね。基本的に文書で取り交わしているので要件定義っていうのはね。なので詰めが甘かったりすることはありますよね。
なるほど。
特に最近のシステム複雑なんで、そんなに事前に細かいところまで詰められなかったりしますからね。
それはあれですよね。まさにNHKとIBMの間で起こった話で。
要件定義をきっちりしてみて開発を始めていくうちに、その要件定義でも足りないじゃんみたいなことも多分起きていたと思うんで。
大手ほどその要件定義ありきでどうしても動かざるを得ないというか、そこら辺違うことをやってミスしたら損失になりますし、そこら辺を回避したがる傾向があります。
大手さんが常にクライアントからヒアリングしてみたいなこととか基本的に行ってないって感じになるんですかね。最初にまとめて終わりみたいな感じになっちゃってるんですかね。
まとめてなくはないんだけど、そんなに深いところまで理解してなかったりして、でもとりあえず契約が撒ければそれでいいっていう感じになってしますんで。
場合にもよりますけど、契約取れた後に中堅どころの会社のSEが出てきて、さらに要件詰めていくみたいなことがあるんだけど、
初めの契約の時巻いてた要件定義と全く違うじゃないかみたいな話だったりしがちなんで、予算がまとまらないとかね。
やっぱり大手ってすごく大人数でやるので、分業体制だったりだとか、システムの開発も何年間にわたって行うみたいなこともあるので、
当然その移動とか組織改変とかあったりするんで、担当の引き継ぎとか、そこら辺によって認識のずれが生まれちゃったりだとか、
当時の空気感とか温度感とかを理解してない人が残らない、要因には繋がるのかなとか。
最終的に取りまとめる、もちろん会社としては取りまとめるんでしょうけども、往々にして多分開発の現場って全部の流れを把握してるとか、
これはこうと答えられる人がいて、基本的に回るようなイメージはあるんですけど、そういったものが構造的にも不在になりやすいってところですかね。
そうですね。それはありますね。やっぱりどうしても大きな会社だと人事異動はありますんでね。
いろいろと都合があるんで、あっちの案件がちょっと大変なんで引っこ抜かれですね、ベテランの人がですね。
そんなことがあったりすると、こっちに残っているのが全然分かってない人のおかしになったりっていうこともあったりするんで、そういう政治的なことで案件が、チームが骨抜きになっちゃうみたいなことがありますよね。
割り振られてる予算だったりとか、システムの開発案件の緊張状況によって、仕事ができるエースとかって結構振り回されがちで。
そうですね。
とりあえず大丈夫そうだろうと思われたら、そこら辺が引き払われて若手に経験つばせるみたいなのがあり得ると思いますね。
じゃあ、そのある種多重下請け構造と相まって、そこら辺の指揮系統というか、この伝達部分がごちゃごちゃになってきやすいというところですかね。
知識、経験とかそこら辺が分からない人が伝書鳩となっちゃったり、伝わってくる情報がクライアントからくるそのままの情報だったんで、
エンジニアとしてはこれどういうふうに解釈していいのか分からないけれども、聞くのもちょっとそこら辺で大手内部のコミュニケーションでスタックしてしまったりとかボトルネックが発生してしまわないように、
ヨシナにやろうとしたら全然うまくいってないよみたいなことも往々にしてあり得るわけですよね。
モチベーションとコミュニケーションの欠如
基本的に開発会社の都合でちゃんとPMが変わったりすると、申し訳なさすぎてあれだよね。もう一回聞くのを。
そうなんですよね。
なるほどな。
やっぱりドキュメンテーションを確認してもその人の書く書き方とか完全に統一されてるかというとそうでもないでしょうし、
それこそ経験がない人とかが書いたものとかによって差分がどうしても出てくるわけですから、
なかなか逆に大手だからこそ生まれる弊害かもしれないですね。
ニュアンスを含めてそれすべてある種ドキュメントにまとめたり、それを引き継ぐというところは難しいのは往々にして理解ができるところかなと思っているんですが、
そうすると多重下請けの構造とか要件定義とか担当者の交代というんですかね。そこら辺以外ではどういった理由が考えられそうですか。
そうですね。あとはやっぱり形式化しちゃってることが結構あって、当事者のプロジェクトを成功させようみたいな意識が結構強くなくてですね。
自分に割り当てられた仕事を淡々とやればいいみたいな感じでテストとかね、テストに割り当てられた人とかっていうのがそういう意識でやってると、
一応テスト項目は通してるんだけど、よく考えたら絶対おかしいよねみたいなところが抜けちゃうみたいなね。
使いにくいなーみたいな。プルダウンの中に1000件も出るんだけど、これ仕様だよねみたいな。そういうので通しちゃうとかね。
そうですね。よっぽどのことがない限り、いろんな潤沢な予算の案件を複数抱えているので大手さんって、
一つの案件がとんざしようがそこまで影響はないっていうところは多分ありえると思うんで、
それこそ各メンバーとしては、いかに自分がミスなく評価を上げるかっていうところとかにフォーカスしたりとかっていうのもある。
そうすると、おそらくそれこそテストとかする段階であれば経験を積むPMとかに回されてきて、
要件定義せれてここの項目さえ満たされてればOKだろうっていう仕事は確かに思想ですよね。
全体的にね、使いにくいなーっていうのは感じても、それをいちいち言ってたら先進まなかったりしますんでね。
確かにここどうなんですかっていうところのコストといいますか、そこら辺もどんどん重なっていくような感じがしますね。
ここおかしくないですかみたいな。
多重請負になっているので、会社を巻き込んでやれってことなんだよね。
変なヤブヘビを叩いてしまうと、めんどくさいこと言うなお前みたいな。
めちゃめちゃよくわかる。
多重下請け構造っていうところは、主にコミュニケーションの部分だとか、
それこそちょっとイメージがわからないんですけど、モチベーションの管理とかも難しそうですよね。
基本的にさっき言ったみたいに、やる気がですね、このプロジェクトを何としても成功させて、
お客さんの喜んでいる顔を見たいんだみたいな、そういうモチベーションの人があまり実際の作業をしている人はいないわけですね。
システム納品の問題
だいたい会えないし、お客さんに。
なるほど、なるほど。
お客さんから直接言われると、すごい頑張って褒められたいなって思うし、
怒られるとやっべーみたいな、次ちょっと気をつけなきゃって思うんだけど、
そういうのがないので、淡々と言われたことをやってるみたいな感じになりがちですね。
確かにプログラマーさんも要件定義を守れば、
挙げられているところを言葉を守ればみたいな実装になりそうですもんね。
そうですね。
そこもそうですし、やっぱり対偶差がモチベーションの差にダイレクトにつながることもあるのかなと思っていて、
よくTwitterとか現Xとかでもたた取り上げられてますけど、
上流で要件定義を決めるITコンサル年収1200万、末端のプログラマー年収400万みたいな感じで。
一時受けでガッポリ持っていかれちゃうんだよね。
持っていかれちゃうんで。
それでも基本的に大手が良いっていうのは、社内の稟議の通しやすさみたいなところもあるんですかね。
そうですね。基本的には大手の良いところと言えば、やっぱり最後まで責任取るだろうっていうのは間違いなくて、
小さな会社ってやっぱり潰しちゃったりするんで、大手の場合はそういうことはないんでしょうね。
プラムザのプロジェクト管理
で、納期遅れて損害でれば損害賠償もする能力もあるでしょうしね。
要は丸投げできるっていう良さがあるんですよね。
そうそうそうそう。
ちなみにそこ、プラムザではどうなのかっていう話をちょっとしたほうがいいかなと思っていて、
大体その案件の窓口担当というか責任者として事業部長とかが入ってくることが多いですけど、
当然その営業の段階から入って提案もしますし、受注したらPMとして開発のマネジメントしますし、
納品終わってからも保守の担当も全然トータルでしますので、そこら辺の不安関係は一切ないんですよね。
テストとかも自分でしますし、案件によっては環境構築自分でして、
作業上がってきたもの、エンジニアから上がってきたもの、自分でチェックして自分でフィードバック開始、全然やるので。
なるほど。最初の打ち合わせとか要件提言の段階から納品とか保守まで一気通貫して、
担当者は基本的に変わらないというところで、そこら辺をカバーできているというところなんですかね。
はい。揺りかごから墓までということですね。
墓でいいのかな。
じゃあ、揺りかごからどこぐらいまで一緒に。
システムもね、いずれ役目を終えて、いい意味で。
いい意味なのかな。
ずっと保守で面倒見るってことね。
ずっと長くお付き合いさせていただきます。担当も特段何か事情がない限りは変わらずやると思いますし。
そういった形態が一応解決策というところで、以前どこかでIBMとかNHKの話をしたときに、
そもそも一括とかこの構造自体が難しいんじゃないかっていうのは島田さんがおっしゃっていたような記憶があるんですが、
今でも大手の仕事の仕方はこういった形っていうのが現状っていうことなんでしょうかね。
大手はそうですね。そのとき話したのは多分一括請負じゃなくて、
順位任契約で、うちでいう国内ラボ型開発でやっていかないと大きなシステムはこういうものできないよっていう話をしたと思うんですけど、
お客さんも大手だったりするとなかなかそれが通らなくてですね、
やっぱり要件を出してそれをいくらですってちゃんと言ってもらって、
それから契約を踏まえてスタートするっていう方法しかなかなか取締役たちの賛同が得られないっていう、
承認が得られないっていうことでね、そういうふうにどうしてもなってしまうんですよね。
いつまでいくらかかるかはっきりしないような開発はなかなか認められないっていうね。
でもまあ普通に開発チーム、社内で雇って作って作ればいくらかかるかわかんないって当たり前のことだと思うんですけどね。
本当そうですね。SaaSとかだったら定期の価格でできますけど本当に。
そうそう。だからそこは本当に何というか思い込みというか、
ちょっと前までね、サブスクみたいなやつもなかなか認められなかったんだけど、
みんなサブスク当たり前になってくると当たり前のように使った分だけ払うっていうのをやってますから、
いずれ浸透してくると思うんですけどね。
こういったポッドキャストの配信を通して、そこら辺の意識改革というと大げさですけど、
その一助になると嬉しいなと個人的には思っております。
そうですね。
繰り返し言いますけど、大手が別に悪いっていうわけではなくて、
じゃあこういうことが起きる原因は何かっていうちょっと。
そうですね。悪口は言いたいわけじゃないんですけどね。
構造分解をしただけというところはある。いいところも当然ある。
そうですね。
ではうまくフォローしていただいたところで、こんなところでいかがでしょうか。
大丈夫です。
ありがとうございます。
ありがとうございます。
本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価をお願いします。
またXでも最新情報を随時発信していますのでよろしくお願いします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
ありがとうございました。
