"BOKU"のITな日常

還暦越えの文系システムエンジニアの”BOKU”は新しいことが大好きです。

適度に出来の悪いプログラムの方が高いお金が取れる不思議な世界

普通は優れたものは高価で、出来の悪いものはそれなりの値段でしか売れないものなのですが、なぜかシステム開発の世界では時々逆転現象が発生していたという話です。

f:id:arakan_no_boku:20190420124810j:plain

 

「人月」という見積もり方法

 

プログラムで構成するシステムだって「無形固定資産」であり、「製造成果物」であるわけですから、できあがった「モノ」の出来栄えで価値判断するのが本来だと、個人的には思います。

だから。

  • 作るのに、どのくらいの時間と手間がかかったか?
  • プログラムコードの量がどのくらいあるのか?

など、本来なら関係ありません。

そのシステムを使うことでユーザがどんな利益を得るのか?とか、それがユーザにとってどのくらい魅力があるモノになっているのかで、対価としての「価格」が決まるのが本来でしょう。

でも。

残念なことに、システムの適正価格などというモノサシは存在しません。

システムを鑑定して値決めできるような鑑定士的な職業人もいません。

だから、「人月」・・ようするに「人数×働いた時間(月数換算)」で見積もって、価格を決めるという市場経済をあざ笑うような習慣で、ビジネスが行われています。

 

プログラマの能力差は考慮されない

 

自分も沢山のプログラマと仕事してますから、個人の能力差がとんでもないのは知ってます。

下の記事によると、ブラウザの原型「モザイク」を開発したMarc Andreessenさんなどは、「5人の優れたプログラマーは、1,000人の平凡なプログラマーよりも完全に優れています」と言っているそうです。

hbr.org

まあ実際。

あるプログラマが1月以上かけても完成させられず「無理です」と逆切れされたプログラムを、別の優秀な人間に渡したら、一から作っても3日ほどで完成させて、かつ、出来も良かった・・なんて話はゴロゴロしていますから、上記の話もあながちオーバーじゃないかもなと思ってしまいます。

本来なら。

お客さんに売る際に、前者の出来の悪いプログラマの成果物より、後者の優秀なプログラマの成果物がはるか高額で取引されないとおかしいわけです。

プログラムという成果物の価値としては・・ですね。

ところが、実際には「前者」の方が高く売りやすいというか・・お客側に対価の根拠を説明しやすいという妙な事がおきてしまいます。 

なんせ「人月」で対価が決まる世界ですから。

適度に出来が悪いプログラムの方が「お金になる」なんてことがおきても、不思議ではないということなのですね。

 

無駄になるかもしれない「設計書」をあえて作る

 

ウォーターフォール型のフレームを使ったシステム開発プロジェクトに参加すると、上流工程・下流工程というものがあります。

上流工程の人(まるで上流階級のようで個人的に好きではないですが)が「設計書」なるものを作り、下流工程の人(下々の者みたいに聞こえていやなんですが)がプログラムコードを書いたり、テストをします。

概ね、「上流工程」の人の方がコストが高く威張っていて、「下流工程」の人は部下のように扱われることが多いです。

もちろん「設計」は重要ですし、「設計書」は必要です。

ユーザ(お客様)と直接話をしている人間が「お客様の意図や機能のあるべき姿」をアウトラインとして明確にしてくれている「設計書」がないと、プログラムを作れませんし、保守フェーズとかでも非常に手間がかかります。

ところが、この「設計書」の中にも不思議なものがあります。 

例えば・・。

疑似プログラムコードのような細かすぎる設計書とか。

だいたい、同じことを重複して書くことを避けるべきだというのは、プログラミングの常識です。

それは設計書の段階においても同じことです。

設計書に細かく書きすぎると、プログラムコードの条件とかをちょっと変更するだけで、設計書まで修正しないといけなくなりますからね。

なのに。

納品物の決め事として、細かすぎる記述を要求される「設計書」があったりします。

もうほとんど、日本語を英語に直せばプログラムコードじゃないか・・みたいなレベルで書かれたものなんて、上記の理屈でいえば非効率の極みです。

しかも。

それを、「自分はプログラマではない」と公言する上流工程の人が書いてたりします。当然。

後で、別の人間がプログラムコードに落とそうとすると、色々不備な点が多くて、それに対する問い合わせや修正依頼などが大量に発生します。

繰り返しになりますが、個人的には「無駄以外の何物でもない」ように見えてました。

でも。

これも「人月」という世界の中では「単価の高い上流工程の人が時間をかけて納品物を作る」ことで、顧客に提示する価格をあげる理由になり、営業的にはとても価値のあるものになるみたいなのですね。

そう。

技術者から見て不要であっても、複雑で難しそうに見える詳細な設計書もまた「お金になる」のです。

 

適正価格を評価する方法がないから仕方ないのかな

 

とはいえです。

多少割り切れなくとも「お金になる」ことは、とても重要です。 

単に技術者目線で効率的な開発という観点からは、首をかしげる部分も多い「人月」の世界ですが、これは適正な価格をお客さんに理解してもらうための「涙ぐましい努力の賜物」であることも確かなわけですし。

考えてもみてください。

優秀な開発者にはコストがかかります。

例えば、超優秀な開発者が年俸1億円、普通の開発者は500万円くらいとします。

年俸は20倍の差がありますが、前に参照したMarc Andreessenの言うとおりだとすると能力的には200倍くらい差がある可能性もあるわけなので、別に不当ではありません。

でも。

納品物にお金を払う側は、そんな事情など知りませんし、その技術力の価値を見積もる「適正価格の基準」をもっているわけではありません。

だとしたら目に見える努力(ようするにかけた時間)や納品物の物理的な量で判断するしかなくなるのは当然です。

だから、同じ機能を、普通の人達が半年かけて作るのと、優秀な開発者が10日ほどで作っていた場合に、前者には気持ちよくお金をはらうのに、後者の場合は「ぼったくりだ!安くしろ!」ということを責めることはできません。

後者の方が圧倒的に出来がよかったとしても・・です。

そもそも、そういう技術的価値を評価する基準を誰ももっていないわけですから。

そういう相手に対して「システムの品質」とか「価格の妥当性」を納得してもらうには、「目に見えるもの」を提示するしかなくて、そのための手段としたら「人月」の考え方は、すごくわかりやすいです。

 

行動経済学では常識なのか

 

これは、システム開発の話だけではありません。

どうも、日本人というのは「技術にお金を払うのには抵抗があり、目に見える努力にお金を払うのは抵抗がない」ものらしいのですね。

行動経済学という学問では常識らしいです。 

 この本にのっている例によると。

人はマッサージのような技術にもお金を払いたがりません。

たとえば上級技術者が的確に5分で的確にあなたの疲れをいやしてくれたとします。

一方、初心者が不器用にでも賢明に30分かけて疲れをもみほぐしてくれたとします。

そうした場合、初心者の方に満足感をもつ人が多いのです。

人は技術ではなく、努力に満足感を得る傾向があります。

ここにマッサージ屋が時間制になっている理由があります。

本来ならば症状に応じて施術内容も時間も違ってしかるべきなのです。 

 とのこと。

なんか・・読んでいて、思わずうなづいてしまう感じです。

マッサージ屋が時間制になっている理由と同じように、システム開発も、お客さんに努力している姿や、沢山のドキュメントという形を見せないといけない。

お金を払ってもらえないから・・・。

こう考えると、この例とシステム開発の例は、まったく同じことなんですね。

きっと、「腕の良いマッサージ師」さんも内心では、割り切れない思いをもっているんだろうな・・。

技術屋って意味では一緒だもんな・・などと想像してしまったりもします。 

うーーーん。

世の中、なかなかグレーですよね。

まあ、人間そのものが、そういう生き物だからなんでしょうけど。

ではでは。