作業分担の誤解
ふてはなDM、この番組は全国の悩める若きビジネスマンに向けて、私島守が本音で語る直球メッセージをお送りします。
はい、えっとですね、さっきからですね、くしゃみが連発していまして、花粉症がですね、非常に出てますけども、出る年と出ない年なんですよね。今年は出ますね。
去年おととしはね、あまり出なかったんですけどね。ひどい時はですね、もう本当にくしゃみが入って、会議とかやってる場じゃないみたいなね、ことになって、今もちょっと鼻声かもしれないですけども、ご了承いただけたらと思います。
今日はですね、またXで見かけたですね、ポストに対してですね、お話ししたいと思います。
テーマは、「20日の作業が20人いれば1日で終わるわけねえだろ?」というやつですね。
これは坊主さんというですね、この人、ネタの投稿ばっかりしてる人なんですけども、その人が書いていたお題に対して、現場のSEとかですね、プログラマーの人たちが出してきたような、あるあるですね。
それをちょっと面白かったので、その話をちょっとしてみたいと思います。
最優秀賞ですね、そっちからいきますか、順番にですね。
最優秀賞は、そのさっき言った20日の作業が20人いれば1日で終わるわけねえだろっていうやつですね。
これは、それはそうだろうと皆さん思うと思うんですけども、意外とですね、開発現場ではそういうことを発想するお客様とかですね、営業はそれに乗っかってですね、強く発想するので、現場はちょっと疲弊するんですけども。
人月とか人日って言葉をあまりピンとこないかもしれないんですけども、基本的に1人の人間が1日でこなせる作業量っていうのは1人日って言うんですよね。
1ヶ月でこなせる作業量を1人月って言うんですけど、それがね、20人日って言ったら、約1ヶ月ぐらい。
1ヶ月ぐらいですけど、それをですね、20人エンジニア集めるとですね、1日で終わるんじゃないかみたいなね。
見積もり書を見るとそんな風な計算になってるということが結構あるんですよね。
これはだいたいどういう状況でそうなるかっていうとですね、初めまともな見積もり書くんですよね。
例えば、これ人日ちょっと現実的じゃないですけども、例えばですね、10人の人間を集めてですね、10ヶ月でシステムを組みましょうと言ったら100人月ですよね。
100人月。で、ただですね、それをですね、お客様の都合でですね、納期半分にしろって言われるんですよね。
そうするとですね、お金を下げずにですね、しかも予算はそれ以上ダメだからなって言われてですね、お金を増やさずにですね、納期を圧縮するということになるとですね、
逆算的にですね、人がそこで投入する人数が変わってくるわけですね。
100人月だったら納期を半分にするということは5ヶ月でやらなきゃいけないってことになりますんで、集める人間が20人になるということですよね。
そういうことをして長時で合わせて見積もり通してしまうと、お客さんも半年でできるんだな、5ヶ月でできるんだなと、半分の後期でできるんだなっていう話になり、
営業の人もですね、はい頑張りますみたいな感じになって、ただ現場のマネージャーはですね、そんなことやったってできるわけないだろうみたいなね。
どうしてもこう、作業分担のコストと結合するコストとですね、進捗管理するコストみたいな色々ありますからね、
人が多くなればなるほど管理コストって上がってくるということがあるので、そういう計算にはならないんですけども、往々にしてありがちなんですよね。
人間はですね、基本的に減っていけば限界はあるんですけども、少なければ少ないほどですね、効率的に回っていくんですよね。
逆に言うとですね、100人月の仕事なんていうのはですね、優秀な人ですね。優秀な人5人ぐらいだったらですね、
本来だと20人月ですかね、20ヶ月かかるんですけども、それが10ヶ月で終わるかもしれない。
だからやっぱりあれをですね、作業を細かく分担してですね、テストして結合するみたいな作業が一番無駄なんで、
4人だったら全員が作業の細部に理解するってことができるんで、それであればですね、ストンキョーなものを作ってこないっていうことがありますよね。
だから本当にミニマムのですね、人間でやっていくっていうのが一番効率的です。これはもう間違いないですね。
顧客との関係
一方でですね、SESみたいな会社があるじゃないですか、開発会社と言いながらですね、人材破棄みたいなことをやっている会社っていうのは、
このですね、20人のエンジニアの中に押し込みたいんですよ。
出来のあまり良くないエンジニアをですね、そこに押し込んで、仕事させないと。あんまり仕事させないで数合わせだけさせるっていうみたいなね。
これが非常に美味しいようでして、それを狙ってるんですよね。20人集めても働いてるのは8人だけみたいなね、ことになって、
あとは長寿合わせにためにいるみたいなね。そういうことをするとボロが出ないし、お金はちゃんともらえるし、いいですよねっていうことですよね。
そういうところにあてがわれたエンジニアっていうのはですね、かなり悲惨で、全然経験にもならないし、暇だし、というふうには思いますけどね。
一つのことでこんなに長く話していると、全然終わらないので次に行きますね。
次、勤奨ですね。勤奨は、発注側にシステム詳しい人がいるとかなり面倒っていうやつですね。
これはまあわかりますね。大きな声で言えないんですけど、ちょっとわかるのはわかりますね。
お客さんの方はシステムに詳しい人間いるんで、多分開発進めやすいでしょうっていうことをおっしゃっていただけるんですけども、
実際はそんなことはあまりなくてですね、基本的には生病法、十五の素みたいなことはありますけども、
本当にですね、しっかり開発がしてやって、何十年やって、リタイアしてユーザー企業に入った方がいるっていうのは結構心強いですね。
かなり本気でやったことがあるんであれば、データの移行とかですね、テーブル設計とかそれに手伝っていただけるかもしれないんですけども、
レビューとかもね、的確なものができると思うんですけども、やったことなくてですね、できるつもりになっているっていう方がですね、
お客さんなのでこちらもなかなか言いにくいんですけど、だいたい現実的じゃなかったりですね、
普通はそういうことはしないとかですね、将来を見通すとそうはしない方がいいとかっていろいろあるんですよね。
非常にやりにくかったりしますね。
コンサルの重要性
お客さんによってはものすごいやってて、ものすごいちゃんとしたプロとして開発をやってて、
ユーザー企業に入って、ちゃんと分かってますという方、これは別に非常にありがたいですね。
それから詳しいんだけど、実際はね、プロの方たちは仕事の仕方が多分違うと思うんで、
その辺はお任せしますって言ってくれるのも助かりますが、ガンガン言ってくるっていうね、いうのが非常に苦しいですね。
お客さんの中にですね、我々開発するときに入っていくときですね、お客さんの方の方でちょっとわからないんで、
外部のコンサルを入れますっていう、これ私は普段からコンサル入れた方がいいって言ってるんですけども、
エンジニアリングの課題
そのまま選んだコンサルがですね、変な人だとこれがですね、また本当にすっちゃかめっちゃかにされますんで、これが困りますね。
昔ですね、入って仕事したらですね、なんかお客さんが東大の大学院かなんかの、まだ学生なんですけども、コンサルとして連れて行きましてですね、
こちらのですね、テーブル設計とかがガンガン思いっきり言ってくるんですよね。
どうすればいいんですかって言ったら、すごいなんか見たこともないような設計を考えてきてですね、これどうやって使うんですか?
ここなんであの冗長になってるんですか?とかですね、理屈はないんですよ。
現場でやった方が経験がないんで、そんなのありましてですね、困りましたね、あれは。
はい、次ですね。
それから入賞はシステムエンジニアにネット環境の設定を丸投げするのは、コミュニコを扱ってるからという理由でピザ屋にラーメンを作らせるようなものってことですね。
コミュニコを使ってるからって言って、ピザ屋はピザのことしかわかんないし、ラーメンはラーメンのことしかわかんないって言おってるんですよね。
これあの意外とですね、社内のですね、情報システムの新人とかがですね、いろいろとこう便利に使われそうになるっていうことでありますね。
基本的にきっとIT詳しいっていう人は何でも詳しいんだろうと思ってると思うんですけど、全然そんなことないんですよっていうことですね。
私なんかはそうですね、本当にガリガリプログラムを書く人間ではないので、広く厚く知ってるつもりですが、あとうちのCTOなんかもですね、広く厚く、あの人はちょっと頭がおかしいんで広く深く知ってますけども、
普通はですね、コーディングする人はですね、コードのことしかわからなかったり、ネットワークのことはですね、非常に無頓着でっていうこともあったりしますね。
エンダーベースの細かいサービスとかの設定とかもよくわかってなかったりしますし、逆にそっちが強い人はコーディング自体はあんまりやったことないとかですね、いうことはありますよね。
最近思うのはですね、これも10年くらい言われてることですけど、最近特にですね、このUI UXについては本当にそう思っていて、エンジニアだからといってですね、UIに強い人ってそんなにいないんですよね。
デザイナーでですね、UI UXに強いっていう人はいるんですけど、これがですね、ちゃんとデータベースの定義に沿ってですね、やろうとしていることに沿ってですね、ちゃんとUX考えられているかというと意外とそんなこともなくてですね、きれいなんだけど使ってみると非常に使いにくいとかですね、
いまいち過剰だったりですね、面積が大きすぎると、こんなことはですね、粗末な機能なんだけど、やたらと面積が大きいとかですね、そういうことがあったりしますのでね、その辺はやっぱり総合プロデュースするようなプロダクトマネージャーみたいな人が多分かなり力のある人が入って、総合にですね、コーディングするエンジニアとですね、
UI UXのデザイナーとですね、よく話をして決めていかないと変なものが出来上がるよという気はしますね。
最近はですね、特にAIに関する知識なんかもですね、あって、それも職人技術のですね、エンジニアとかって割と無頓着だったりするんですよね。AIとかなんか出来るらしいけど試したことないとかっていうこともあって、あるいはですね、ツール的にちょこちょこっと使ってもらってるみたいなね、使ってるとかいうことがあったりしますけども、全面的には全然信用してないとかね。
そんな使い方だったりしますけども、そうですね、基本的に職人技術の人ってツールコロコロ変えないですからね。
一回これもう硬く決まるとですね、それをしっかりと使い続けて案件ごとにですね、開発環境を育てていくというふうにあんなことしますんで、AIに関わってたらとんでもないっていう人もいますのでですね、全然知らなかったり、AIの最新の事情を知らなかったりすることもありますね。
はい、そんなところですね。今日もまたちょっと長くなりましたけども、今日のお話は以上になります。いかがでしたでしょうか。ご意見・ご感想・ご質問等ありましたら、Xボタンを押してください。それではまた来週の木曜日、このチャンネルでお会いしましょう。
