00:05
はい、おはようございます。今日も瞬殺エンジニアの加門です。 今日のテーマはですね、システム開発が失敗するよというお話に引き続いて、引き続いてというのは前回がそれなんだったんですけど、今日はですね、じゃあなんでその開発が失敗するのかというところをですね、ちょっと簡単に見ていきたいなと思っております。
今回ピックアップするものはですね、全てではなくてですね、代表的なものになりますので、これらにですね、引っかかっていないのかというところはですね、改めてチェックしていただくことによってシステム開発の失敗リスクというのを抑えることができますので、ぜひね、簡単にチェックしていただければなと思っております。
この番組は、今日も瞬殺エンジニアの加門川業務法律課とITニュースを語るチャンネルです。本題の前にですね、一つお知らせです。 Excelスプレッドシートの業務に何時間もかかっているよという方だったりとか、転記入力で大変な思いをしているよという方はですね、ぜひ私までご連絡ください。
その大事な時間というのを有効活用できる、そんな仕事環境というのをですね、提供できますので、ぜひね、私までご連絡ください。さあ、本題に入っていこうかなと思うんですけれども、システム開発というとですね、どうしても技術のお話が多いのかなと思っております。
難しいプログラミングを書くから大変なんだとかですね、ITに詳しくないと進められないんだというふうな、そういうふうな印象を持っている方が多いのかなと思うんですね。
確かにですね、技術的な難しさというものもありますが、どちらかというと技術的なものというよりかは、人と人との認識のずれだったりとか企画段階での問題によって失敗というのは起きます。
なので、なんていうんですか、戦は始まる前から決まっているみたいなね、勝負は始まる前から決まってるんだ、みたいなことを言っている方いらっしゃるじゃないですか。
それってやっぱり準備が重要なんだよということの現れなんですけれども、それがシステム開発でも同じようなことが言えますよということになります。
前回の放送ではですね、4人いらっしゃるよという話をしました。システム開発においてですね、4人の重要な人間がいると、まずユーザーですと、PM、プロジェクトマネージャー、これは企画をする人ですね。
ユーザーは実際にシステムを触る人ですね。例えばLINEを使っている僕たちからしたら、LINEのユーザーは僕らというふうになります。
じゃあ次はですね、SEですね。システムエンジニア。これはプロジェクトマネージャーの企画を形にするものですね。設計書に形にしますよと。
03:09
で、プログラマー。SEが作ったですね、設計書をもとに実際に形にしますよということになります。
まあなので、こういった4人がですね、うまい具合に噛み合っているのかというところがポイントになります。
で、この4人がうまいこと噛み合っていないというケースで失敗が多いということになります。
では、今回ね、この失敗、典型的な失敗の3つの事例をお伝えしていこうと思っております。
まず1つ目がですね、ビジネス側が要望を盛り込みすぎて、後よろっつってエンジニアに放置するというケースでございます。
これはですね、ビジネス側というのはユーザーとPMのこの2人なんですけれども、この2人がですね、あれも欲しい、これも欲しい、これもそれもこれもこれもこれもこれもこれもこれもこれも実現してちょんまげっつって全部渡すというのがこの典型的なパターンなんですが、
これはですね、その要望が本当に必要なのかとか、優先順位はどうなのかとか、業務の中でどう使うのかとか、
あとは社長が言っていることはこうだけど現場ではこうみたいな、そうですね、何がいいかな、社長は全部見たいよと言ってるんだけど、でも社長じゃない現場はですね、全部別にいらんけどみたいなっていう場合、
じゃあそれって全部出す必要性ってありますか、社長って月に1回しか見ませんけどみたいなね、そういうふうなケースがありますので、そこら辺はじゃあどうしていきますかっていうふうな話になります。
でもそういう調整ができない状態だった場合、協力体制がない場合ですね、あれもこれもあれもこれもつって、あとよろしくダーンつって、えーみたいになって結局ですね、開発ができませんみたいなことになります。
で、いざですね、じゃああれもこれもあれもこれもって言うから、形にしましょうかって言って形にしたらですね、実際にユーザーからですね、こういうふうには言うんですね、これ別に使いませんけど、何ですかこれみたいな反応が来るんですよ、いやいや言うだやんみたいな感じなんですけどね。
なので要望をこう言いたいぐらいバーって言ってるのと、実際に業務で使えるシステムなのとはイコールではないということになります。
06:01
で、ここが重要なんですね。要望はいっぱい出せるんでしょうけど、それが実際に使えるかどうかはまた別問題ですよということになります。
何を作るのかではなくて、なぜ必要なのか、誰がどう使うのか、そこまでですね含めて擦り合わせするということが土台になってくるかなと思います。
で、2つ目はですね、プロジェクトマネージャー側の思い込みになるわけですね。
これはユーザーに十分なヒアリングをせずに、自分現場やってたしみたいな感じで、まあまあこんな感じちゃうのみたいな感じのですね、自分の経験と勘で企画を作ってしまうケースですね。
そうするとですね、あの業務フローとか仕事の流れとかですね、十分に確認が取れないまま企画を作り、で、開発をスタートして開発が終わってリリース。
じゃあユーザー使ってくださいってなってくるんですね。
はい、ここで問題です。ユーザーに十分ヒアリングしなかった場合、ユーザーから何が出ますか?
これ使いにくいんですけどどうしたらいいですか?ってくるんですよ。
今の業務にあっていないケースが結構あるんですね。
過去はABCという順番で仕事をしてたけど、今はですね、ABCでFまであるとかですね。
そういう風にですね、あとはなんかBがなくなってましたよとかね、そういう風なケースもあるわけです。
PMとしては良かれと思って作ってたっていう風なケースが結構あるんですね。
現場の人に確認すると現場の人の時間がですね、取られてしまいますから、その現場の人に遠慮をしたりとか、
自分昔やってたし、その昔やってたやつをそのまま形にすればいいよねっていう風に良かれと思って作ってるケースが結構あるので、
この現場のね、実情というのをつかめていないというところが問題になるのかなと思います。
3つ目はですね、エンジニア側の問題なんですね。
これよくあるんですね、私としても。
どういう風なケースなのかというとですね、エンジニアは経験を積めば積むほどですね、いろんな案件の経験を積むことがあります。
そうするとですね、過去の定石というものがそのエンジニアの中にあるわけですね。
過去こういう風なケースがあった場合はこういうことになっていたっていう経験則ですね。
この経験則のままですね、思い込んでしまって開発をしてしまう。
それがその会社によってはですね、実は違っていたっていう場合ですね。
その場合ですね、リリースしてしまうとですね、ユーザーとかPMがですね、本当に求めていたことなのかっていうところとずれてしまうということになりますので、
09:06
必ずですね、そこの確認というのは必要になります。
経験則というのは非常に重要なものになります。
経験則があるからですね、プロとしてやっていけるわけでございますので、
その経験則というのはあくまでも開発する前に提案をするというところ、この確認というところが必要なんだろうというふうに考えています。
またもう一つあるところとしてはですね、要件定義から基本設計というふうなものがあるんですね。
ここに落とし込む過程においてですね、ちゃんとですね、ビジネスゴールっていうそのビジネス側、
例えばユーザーがこういうふうにしてほしいですよというところをですね、ちゃんと目的意識だったりとかゴール設定とかですね、やっていなかった場合はですね、どうなるのかというとですね、
なんとエンジニアが良かれと思って、こっちの方が開発しやすいし報酬性も高いからこうした方がいいよねって言ってやっちゃうわけなんですね。
そうするとどうなるのかというと、最初のユーザーが求めていた内容とプログラマー、エンジニアが作ってきた内容と全然違うものが出来上がってくるということになります。
なのでちゃんとビジネス側もですね、エンジニアにここはこうなんですよ、こういうふうな目的でこういうふうなことをやってるんですよということを100%提示しておかなければならないということになります。
はい、ということでね、今回は簡単に3つお伝えさせていただきました。
1つ目はですね、ちょっとまとめになるんですが、ビジネス側が要望を盛り込みすぎるっていうところですね。
あとよろって言っちゃうっていうところ。
これ、要望ね、矛盾してた場合とかあるわけですよね。
そうすると、Aさんの要望は叶えたのにBさんの要望は叶えていませんって言ったら、なんで俺の要望は叶えてくれないのっていうふうに不満が出るんですよね。
なので盛り込みすぎ問題はね、出してくるのは全然いいんですね。
出さないと話にならないので、ただあとよろっていうのは良くないっていうところですね。
2つ目はですね、プロジェクトマネージャーの思い込みですね。
これはどうしてもその現場ユーザーとかユーザーのことをですね、知らないまんまですね、進めてしまうから、機上の空論で作ってしまうよという形になります。
なのでちゃんとユーザーのことを理解しましょう。
少し迷惑がかかったとしてもですね、それは短時間なので、大規模にいろんなところに迷惑がかかるわけではないので、ちゃんと確認しましょうねというところですね。
3つ目はエンジニア側なんですけれども、ここはですね、経験則を信じ込まないというところと、ビジネス側とですね、ちゃんとコミュニケーションをとってですね、ゴール設定というのをちゃんと見極めるってところが重要だろうというふうに考えております。
12:13
はい、ということでね、今日も最後まで聞いていただきましてありがとうございます。
この他にもですね、実はもう少しね、詳しくお伝えすることができますので、それはね、次回お話ししようかなと思っております。
本日の内容がですね、面白かったな、ためになったな、気づきが得られたなという方はですね、ぜひいいね、フォロー、コメントにシェアをよろしくお願いいたします。
最後に3つお伝えさせていただきます。
1つ目はですね、Excelスプレッドシートの業務をもっと楽したいなという方はですね、ぜひ私までデータをください。
2つ目はですね、アンクスミスというバンドプロデューサーでやっております。
SpotifyとかAmazonミュージック、YouTubeミュージックにAppleミュージックなので配信中でございます。
概要欄に各リンクを掲載しておきますので、よろしければ聞いていってください。
3つ目はですね、楽曲作成の募集をしております。
自身がですね、ビジネスやサービスに合った楽曲を作ってほしいなという方はですね、ぜひぜひデータをください。
現在4名様限定で無料でご提供させていただいております。
はい、ということでね、今日の放送はここまでとなります。また次回の放送でお会いしましょう。
カモンでした。バイバイ。
