受託システム開発の原価計算には「個別原価計算」を用い、
作業高は完成までは「仕掛」完成して売上げると「売上原価」となると書いた。
システム開発においては、同じ要件定義であっても
見積もり時に想定していた性能要件や、機能要件の実現に手間取り、
手戻りや仕損が発生し、原価高をもたらすことは多い。
これは要件定義がいい加減だとか、原価見積もりがいい加減だとかではない。
個別の受託システムにおけるソフトウェア開発の宿命と言ってもいい。
いくらきちんと要件定義をしようが、慎重に見積もりを行おうが、
完全に避けることは絶対にできない。
機能であれば安全率を加味することはできる。
例えば、ある機能の処理量について、
絶対に50人は超えないので、
どんなに多くても日に50人分処理できればよい、
との要求であっても、
正直に50人分しか処理しないソフトを組む人間はいない。
実行上のタイムラグがあるし、処理ロジック(論理方式)を考えると、
たとえぴったり50であっても+アルファは用意していないと
処理できないこともあるし、
お客様が言う「絶対」程、怪しいものは無いから、
ふつうは倍は見ておくものだ。
それでも(内部処理は違うのだが、わかりやすいように書くと)
倍だと100と3ケタになる。
99ならほとんど倍だが、もしも万が一、100になったらあふれてしまうので、
管理上は3ケタまで大丈夫にしておこう、なんて冗長性を持ちせるのが普通。
(冗長の取り方はケースによって違う、これはあくまで例)
これは機能的には冗長性を持たせて設計のは常識だよ、と言っているにすぎない。
開発手法そのものの安全率なんてものは無いのだ。
例えば、担当者が死んだらどうする、
死なないまでも大けがをしたら、
親が死んで急に家業を継ぐことになった、
家族が急病になって、、、、
急に仕事ができなくなる可能性は0ではない。
だからと言って、
あらかじめ同等の能力を持った替りを用意しておくか。
そりゃ、替りが用意できるレベルの人間もいる。
できる人間ほど替りがいないし、
できる人間の替りができるほどの「できる人間」を
交代要員としておくほどの余裕があるはずがない。
イチローが怪我した場合に備えて、
もう一人イチローを控えに置いておくようなものだ。
もしもう一人イチローがいたら、ためらいなくライトに走らせるでしょうし、
イチロー、イチローの1、2番コンビを組ませるでしょう。
(もう一人のイチローは3番でしょ、と言った突っ込みは無しね)
この例はめったには無いが、絶対ないことではない。
突然死、借金に追われて逃げる、自動車事故で入院、
喧嘩でけが、プレッシャーからノイローゼ、
いずれもあり得るし私の周りでもあったことだ。
重要な人物であればある程プレッシャーも大きいし、空いた穴は大きい。
運よく人的には替りが充当出きても、その代役として機能するには
時間がかかる。
造りかけのプログラムを捨てざるを得ないこともある。
このほか実際にはよくあるのが、性能が出ないこと。
性能設計は難しいのよね。
目標0.4秒、とはSuicaやPasmoの処理速度だが、
応答速度最大1秒、なんて性能目標を掲げたができない、とかね。
それも1秒が2秒とか3秒とかではなく、
10分とか1時間とか、ありえないような数字になったりする。
これがいくら努力しても1割しか縮まらないこともあるし、
一気に1/10、1/100になることもあるから、性能向上は難しい。
これも小手先の手直しではよくならず、作り直しになることはよくある。
完成品が所定の目標を達成していなければ作り直しってことは、
土木工事でも建設工事でもあり得ることだが、
完成するまでダメかどうかわからないものは少ないだろう。
ソフトの場合は完成していてもだめなものを作ってしまったかどうか
わからないことさえあるのだ。
ソフト開発の場合は、ともかく「仕損」とは切っても切れない。
仕損は不良品だが、およそ工業製品とは思えないほどのレベルで発生する。
ながながと書いたが、ソフト開発はいろいろな点で不良仕掛、仕損が発生し、
作番が一気に大赤字に転落することは日常茶飯事であるとだけ言っておこう。
最後に、ある笑い話を。
アメリカの会社が日本のメーカーに部品を発注した。
不良品の比率、つまり、不良率を非常に厳しく設定し、
納期も厳しいものだった。
納期も間近になったころ、日本のメーカーから緊急の連絡が入った。
製品が完成し、納品できるようになったと言うものだ。
しかし、その最後に次のような文が入っていた。
いまだに不良品用の設計図が届いておりません。
大至急お送りください。
***
「プレSE奔走す」 ISBN4-434-07543-8 1200円
セブンアンドワイ
楽天ブックス
その他オンライン書店で。
紀伊国屋(新宿)、ジュンク堂(池袋)には店頭在庫もあります
作業高は完成までは「仕掛」完成して売上げると「売上原価」となると書いた。
システム開発においては、同じ要件定義であっても
見積もり時に想定していた性能要件や、機能要件の実現に手間取り、
手戻りや仕損が発生し、原価高をもたらすことは多い。
これは要件定義がいい加減だとか、原価見積もりがいい加減だとかではない。
個別の受託システムにおけるソフトウェア開発の宿命と言ってもいい。
いくらきちんと要件定義をしようが、慎重に見積もりを行おうが、
完全に避けることは絶対にできない。
機能であれば安全率を加味することはできる。
例えば、ある機能の処理量について、
絶対に50人は超えないので、
どんなに多くても日に50人分処理できればよい、
との要求であっても、
正直に50人分しか処理しないソフトを組む人間はいない。
実行上のタイムラグがあるし、処理ロジック(論理方式)を考えると、
たとえぴったり50であっても+アルファは用意していないと
処理できないこともあるし、
お客様が言う「絶対」程、怪しいものは無いから、
ふつうは倍は見ておくものだ。
それでも(内部処理は違うのだが、わかりやすいように書くと)
倍だと100と3ケタになる。
99ならほとんど倍だが、もしも万が一、100になったらあふれてしまうので、
管理上は3ケタまで大丈夫にしておこう、なんて冗長性を持ちせるのが普通。
(冗長の取り方はケースによって違う、これはあくまで例)
これは機能的には冗長性を持たせて設計のは常識だよ、と言っているにすぎない。
開発手法そのものの安全率なんてものは無いのだ。
例えば、担当者が死んだらどうする、
死なないまでも大けがをしたら、
親が死んで急に家業を継ぐことになった、
家族が急病になって、、、、
急に仕事ができなくなる可能性は0ではない。
だからと言って、
あらかじめ同等の能力を持った替りを用意しておくか。
そりゃ、替りが用意できるレベルの人間もいる。
できる人間ほど替りがいないし、
できる人間の替りができるほどの「できる人間」を
交代要員としておくほどの余裕があるはずがない。
イチローが怪我した場合に備えて、
もう一人イチローを控えに置いておくようなものだ。
もしもう一人イチローがいたら、ためらいなくライトに走らせるでしょうし、
イチロー、イチローの1、2番コンビを組ませるでしょう。
(もう一人のイチローは3番でしょ、と言った突っ込みは無しね)
この例はめったには無いが、絶対ないことではない。
突然死、借金に追われて逃げる、自動車事故で入院、
喧嘩でけが、プレッシャーからノイローゼ、
いずれもあり得るし私の周りでもあったことだ。
重要な人物であればある程プレッシャーも大きいし、空いた穴は大きい。
運よく人的には替りが充当出きても、その代役として機能するには
時間がかかる。
造りかけのプログラムを捨てざるを得ないこともある。
このほか実際にはよくあるのが、性能が出ないこと。
性能設計は難しいのよね。
目標0.4秒、とはSuicaやPasmoの処理速度だが、
応答速度最大1秒、なんて性能目標を掲げたができない、とかね。
それも1秒が2秒とか3秒とかではなく、
10分とか1時間とか、ありえないような数字になったりする。
これがいくら努力しても1割しか縮まらないこともあるし、
一気に1/10、1/100になることもあるから、性能向上は難しい。
これも小手先の手直しではよくならず、作り直しになることはよくある。
完成品が所定の目標を達成していなければ作り直しってことは、
土木工事でも建設工事でもあり得ることだが、
完成するまでダメかどうかわからないものは少ないだろう。
ソフトの場合は完成していてもだめなものを作ってしまったかどうか
わからないことさえあるのだ。
ソフト開発の場合は、ともかく「仕損」とは切っても切れない。
仕損は不良品だが、およそ工業製品とは思えないほどのレベルで発生する。
ながながと書いたが、ソフト開発はいろいろな点で不良仕掛、仕損が発生し、
作番が一気に大赤字に転落することは日常茶飯事であるとだけ言っておこう。
最後に、ある笑い話を。
アメリカの会社が日本のメーカーに部品を発注した。
不良品の比率、つまり、不良率を非常に厳しく設定し、
納期も厳しいものだった。
納期も間近になったころ、日本のメーカーから緊急の連絡が入った。
製品が完成し、納品できるようになったと言うものだ。
しかし、その最後に次のような文が入っていた。
いまだに不良品用の設計図が届いておりません。
大至急お送りください。
***
「プレSE奔走す」 ISBN4-434-07543-8 1200円
セブンアンドワイ
楽天ブックス
その他オンライン書店で。
紀伊国屋(新宿)、ジュンク堂(池袋)には店頭在庫もあります
※コメント投稿者のブログIDはブログ作成者のみに通知されます