vetteです。
HAMAI Kyoichi <k-hamai@....com> さんの
"[XP-jp:03067] Re: 生産量 (was CMM と XP)" (at 2002/01/22 18:32:36)について
> ２．根拠
> 「ソフトウェアの規模があらわすものは、生産量でなくむしろコストである」
> ということの根拠は、以下の３点です。
このあたりは３でコメントします。
> 一円のお金も生み出さずコストとなるだけなので、製造業における生産性改善
> 手法は売れる分しか＊製造しない＊、流通業における生産性改善手法は売れる
> 分しか＊仕入れない＊のを基本にしています。トヨタのカンバン方式、
> コンビニの小口配送、どちらもそうです。『ザゴール』で取り上げられている
> TOCやTOCから発展したSCMも例外ではありません。
「余計な在庫をもたない」のは経費削減・身軽にして多品種対応しやすくする
など経営上の効果はあるのですが、これって「生産性改善」って
いうのですか？たしかに改善はされてますが。
ベルトコンベアに対するセル方式・一人屋台方式にしても
仕掛品を減らして無駄な在庫を削減することを目指していますが、
最小単位での生産ペースを落とさないのが前提ですよね。
20000台/月という大きな単位での生産はしないけど200台/日が達成できるなら
需要があったときも生産は追いつくという見込みがあるから、
余計に在庫しなくても大丈夫という決断ができるわけで。
あ、これべつに反論でもなんでもないですが。
> ３．これまでの問題点
> 「ソフトウェアの規模が生産量をあらわす」という誤解は以下のような弊害を
> 生んでいると私は考えます。
>
> ・開発コストの増大。開発期間の増大。
> ・欠陥の増大。
> ・保守性の低下。保守工数の増大。
> ・ソフトウェア再の阻害。
> ・リファクタリングの阻害。
> ・技術者のモラールの低下。
> ・生産性低下。
>
> 規模が必要以上に膨れあがることは、開発コスト、開発期間の増大に
> つながります。また、規模が大きくなれば、潜在的な欠陥も増加します。
> 保守性も低下し、欠陥の増大と相まって保守工数の増大を招きます。
>
> 生産量は大きい方が望ましいので、「ソフトウェアの規模が生産量をあらわす」
> という誤解は、「ソフトウェアの規模は大きい方が良い」という誤解に
> つながります。これは、ソフトウェアの開発規模を減少させるような、
> ソフトウェア再利用やリファクタリングが実施されることを阻害します。
> また、コンパクトでシンプルなソフトウェアを開発するような技術者は評価
> されず、そうした技術者のモラールの低下につながります。
これらはむしろ濱井さんの誤解かと思います。誤解かどうかは重要で
ないのですが。
「望ましい結果」についてあまり価値観のちがいはないとおもっているのですが、
誰を犯人にするかというところが違っているんだと思います。
以下は、現在の規模ベースの生産性の向上を図るという思想？
と実際の状況に対する私の認識です。
・開発するものが増えると手間が増えるので原価がかかる。
同じものを開発するのに前より手間を減らしたい。
手間が減れば同じ原価（または期間）でもっとたくさんのことが出来る。
または開発期間を短縮できるので、Time to Market な
ビジネスが可能になる（はずというかめざす）
・開発するものが増えるとコストが増えるから
ソフト開発費もあがりますよ、とはいいますが、
「だったら無駄に大きくしたらたくさんもらえる」とは
考えていません。
まあ10年ほどまえなら
「ソース1step単位で支払いを決める」といわれたから
「じゃあ改行回数増やそう。NOPな処理を増やそう」
っていうネタがありましたが、それは発注側がバカというか
2次・３次外注をろくにケアせずに買い叩く管理者がやって
いることで、まともなところではやりません。
それでもそういうひとがのさばる理由になってしまうという
としても、そういうひとは何やっても同じようなことをすると
思います。「これがおれたちの価値だ！お前が口を挟むな！」とか。
・同じことをするための手間を省くのは大事ですが
規模を減らせるのも当然大事です。
もちろん手間といっても始終無駄を省こうと目を光らせてる
とかいうわけじゃないですが。
濱井さんの想定では
「規模が減るともらえる額が減るから、減らすのに反対する」
ということだとおもいます。
これは一面ではあっていますが、そうでない面もあります。
減らすのを嫌がる点については、当て込んでいた開発案件が
減ったら仕事が減るわけなので、仕事をもらうほうとしては困りますね。
また、ソースコードレベルでも、ある対応が要らなくなったら
作業が減るので困ります。困るけど本当にいらないなら仕方ないですね。
規模が減ったほうがいいのは、以下のようなこと。
コード行数や機能ブロックあたりの欠陥とそれに起因する障害が
一定数あるとすると、行数が減ったほうがバグが減らせることになります。
規模が大きいとスケジュール的に苦しい。金もらえればいいってもんじゃない。
当たり前ながら、1000行書かないと作れないより50行で作れたほうが
楽だし、別のことやる時間が増えるし。
同じ機能があるなら使わせてもらいたがるのが普通で、
バグが枯れてそうな物を利用したほうがよい。
自分で書かなくても機能を実現できる。
たとえば、目下問題もないのにprintf()を一から書き直して
お金を請求する人がいたらバカでしょ。
いるとしたら、規模さえあれば余計な仕事でも金がもらえると
思っている人ではなく、自分が作ったもの既存のものと置き換える
だけの値打ちがあると勘違いしてる様なひと。
したがって下記の心配事は目指しているのとは反対で
むしろこれらを避けるための活動をしているのです。
（「大きいことはいいことだ」という前提ではありません）
> ・開発コストの増大。開発期間の増大。
> ・欠陥の増大。
> ・保守性の低下。保守工数の増大。
> ・ソフトウェア再の阻害。
XPやリファクタリングという言葉が出る以前から
保守性をあげようとか再利用性高めようとか、
パッケージを買ってきたらちょこっと触ってシステムが作れるから
導入とメンテのコストが期待できるとか、
アプリケーションフレームワークを採用して新規開発量を
減らせるとか、こっちの言語・環境のほうがステップ数が少なく
エレガントに実装できるとか、そういう話は延々と続いてますよね。
それって「どうでもいい規模や作業を減らしたくて」
「実現できる機能を増やしたい」というものですが、
それって同じ機能を実現するための手間・コスト・原価を
減らそうとしてたわけですよね。
うまく行ってないないのも多いですが :-)
> ・リファクタリングの阻害。
単純に「規模あたりの開発速度」で考えると、機能が増えないのに
ソースを触ってるだけだったりソース行数が減る作業、ないし機能も
減らしてしまう作業は、「規模が減るので（成果が悪く見えて）困る」
からと「邪魔される」ことを懸念されてるんですよね。
ただ、わたしの経験では「無駄なコード」「冗長なダブりコード」を
削除する作業を規模が減ってしまうと理由で止められたことはないし
むしろ奨励されています。
バグ原因もへらせるわけだし、将来の修正のしやすさ（コスト減）にも
つながるわけですから。
「するな」といわれるケースは、出荷直前とか、クリティカルなバグ修正
時など、安全性に不安があるときぐらいですか。
自動テストなどである程度安全性を確認できればいいのですが、
検証しきれない（自信がない）ときなどは「リファクタリングすべき
でないとき」なのでしょうね。
そのソフトに将来がないときもあまりきれいにする労力はかけないですね。
修正作業という投資をしても回収する機会がないですから。
規模計測や生産性の計測という意味では、リファクタリングは測りにくい
かと思います。ただし「有効に効果を評価する方法が確立してない」という
意味ですが。
たとえば、頻繁に同じ関数のリファクタリングをやっていたとしたら、
いくらリファクタリングがすぐ済むとかテストも速いといっても、
作戦が間違ってるんじゃないの、と思いますよね。リファクタリング
したつもりがうまく出来てない。だから士気があっても無駄に作業が
増えてしまう。
1000行のソースを200行削って100行作りこみました。
最終的には900行になったので、達成できたステップ数は -100です。
でもこう考えてみます（注：あくまで私と私の周辺の考えです）
「コストとしては 300行の作業に対する原価が発生している」
「もともとのソースがもっと最適にかかれていれば今回200行削る
作業をしなくて済んだ。つまり 800行に100行追加するだけで
済んだ。」
「今回は300行分の手間が掛かったけど作ったのは100だけでした。。
200行削ることになったのは元が悪かったことの負債だね。」
（なお、顧客に請求する額のベースとしてその300行 or 100 or
-100行 をそのまま転嫁することは通常ありえません）
なお、リファクタリングに限らず仕様変更や開発中の紆余曲折
などで削ったり張ったりになるのは一定範囲内で見込んでいるので
実際は細かい行数でカリカリしませんが。
細かい針のぶれにいちいち反応しても仕方ないので。
> ・技術者のモラールの低下。
これは何に起因するモラルを意識しているのかよくわかりませんが。
無駄を減らしてプログラムを小さくきれいにするという意欲を
そがれるというようなことでしょうか。
それとか「努力しなくていいから冗長に作っとけ」といわれるとか???
これはかなりの部分上長の素質に問題があるような。。
「ソフトはユーザにとっての価値が重要です」でも「規模が大きけりゃ
いいってもなじゃないだろ」でも啓蒙の苦労は変わらないような^＾;
補足的感想：
今回の主張に際しての濱井さんのポジションとしては
・「"生産性"をあげる」より「"生産的"な仕事を目指せ」といいたいのか？
・ソフト開発側ではなく発注側のポジションで
「ソフト屋は意味の無い数値で請求するな。自分の不手際を転嫁するな」
といいたいのかしら。
そのために「規模ベースは間違い」という主張をしているという印象を受けます。
逆にあまり受注側で開発とか見積もりとかされたことは無いのでは？
という印象もあります。
危惧されるのはわかるのですが現場の雰囲気が通じてない気がしたので。
（あくまで受注して開発する側の、ってことですけどね。）
----------------------------------------------------------
MORIOKA Toru 森岡"vette"徹
E-mail:vette@....jp