いがぴょんさんのブログに、「規模が小さめのソフトウェアは第三次産業、規模が大きめのソフトウェアは第二次産業 (?)」というのがありました。
この、大規模開発の場合、製造業（第二次産業）とおなじようである（あるいは、同じように出来ないか）という考えは、９０年代、「ソフトウェアファクトリー」という考え方で、はやりました。
でも、いまは、その考えだと、うまくいかないと思います。
理由は２点
（１）製造業とおなじようにやるためには、すくなくとも、機械の動き方は、「動かす前に」わかっていないといけない。そうしないと、生産計画が立てられない。
ところが、いまのソフトは、マニュアルどおりにうごかない。
ひどいのなんか、ＢＲＥＷのカメラなんかにかんしては、ＫＤＤＩのマニュアルで、２とおりの動き方をしめし、どっちになるかは、自分で調べてね(^^;)
おいおい。。
で、そのとおりに動けばいいけど、さらに、端末（ケータイ）によって、びみょーに動きが違う。なので、一概に仕様をきって、いっぺんにやらせることが出来ない。
（２）製造業の場合、途中で、仕様変更が起こることがまれである。
（あったとしても、想定の範囲内である）
システム開発の場合、ユーザーの都合で仕様変更が起こるし、さらに、もっとひといのは、設計ミスっていうより、連絡ミスっていうより、意識があってなかったので、インターフェース変更というのが、日常茶飯事におこる。それも、「ありえねーだろ、そんなのはじめに気づけよ！」という、大規模仕様変更が。
もちろん、製造業においても、昔のベルトコンベアーのように、同じ作業を繰り返し行うという方法でなく、セル生産方式が取り入れられ、生産ラインにおいて、単一の仕事をさせるのではなく、ある程度まとまった仕事をさせ、多能工化させていることや、それにより、敏速な仕様変更が可能になったことくらいは、理解してます。
でも、それでもなおですねえ。。。ソフトウエアのマニュアルのいい加減さ、仕様変更の度合いのひどさは、製造業とは、違うと思います。
そこで、現在では、大規模開発の場合、上記の２点の対策として
（１）プロトタイプの段階で、ＴＤＤの開発のように、ある程度自由度をもたせて、開発させ、リスク部分のやり方を明確にする。
（２）仕様変更が起こっても迅速に対応できるよう、抽象的なプログラムの作成（プロパティファイルにり、自由度をあげるなど）と、自動生成によるプログラム作成の迅速化を行う
ようになったと思います。
小規模開発においては、これらの手法を行うまでもなく、ふつーに、開発しても、ＴＤＤで開発しても、ＸＰで開発しても、ある程度、うまくいきます。
そういう意味では、小規模のほうが、自由度は大きいと思います。
まとめると、昔は、大規模開発の場合、昔の製造業のように、標準化をきめて、ばーんと流せばよかった。
でも、今は、製造業ですら、その方法で行き詰まり、セル生産方式に変わってきたように、ソフトでも、標準化をきめて、バーンとというやり方は、うまくいかなくなってきた（理由は、上に示した２つ）。
なんで、今の大規模開発は、さらに、シビアになっていて、リスク要因部分を切り出し、そこをプロトタイプとしてＴＤＤっぽいかんじで開発し、開発部隊を動かす段階になる前に、方式が標準を作成し、方式完了後、バーンとなげる。っていうかんじだと思います（っていうのは、わたしのまわりだけ？）。
で、その際、どこで、どのタイミングで、そのＴＤＤ風要素を、どこまで取り入れるかで、組織がまとまんなくなっちゃうので、結構、マネージメントが大変つーかんじだと思います。
つまり、規模によって、開発方法がぜんぜん違うことはたしかにそうなんですけど、
小規模の場合、リスクも限定的だし、意識あわせも限定的なので、どのような開発方法でもとれる（別に小規模で、ソフトウェアファクトリー的な作り方をしても、問題はない）。
でも、大規模になると、リスクを限定「しないといけないし」、意識あわせも、シビアに「しないといけないので」、マネージャーの力量と、まわりのスタッフレベルと作業量を考えると、方法論は限定「せざるをえない」。
しかし、その限定されたソフトウェア開発方法は、単純な、製造業をパクってきたような標準化したソフト開発ですまないから、むずかしい。
そこで、マネージャーの、「相当な」力量が問われる（っていうか、本当は、「これやばいかも！って気づく勘だとおもうけどね）。
つーかんじなのかなあ。。。
アクセス
トータル
ランキング
