現在の学会、業界本のトレンド、大手企業の人たちや、若い人の意見、ブログなんかをみると、ウィリアムのいたずらが接する、中小下請けの上の人や、現場で作業してる人の感性と、ちょっと違う（いやかなり）という気がしてます。
学会などの感性は、「効率的なソフトウエア開発方法」を議論しています。その一つとして、オブジェクト指向では、ＵＭＬを用いてＭＤＡで。。。とかいう路線の議論とか。。。
そして、オブジェクト指向、アジャイルでの開発論を中心に展開し、「こんなように開発します！！」といって、で、なんか、このケースでは、だめなんじゃない！みたいな意見が出ると「銀の弾丸はない」（でしたっけ？）みたいに言って、お茶を濁す。。。っていうふうに見えてしまいます。
中小企業の現場ではそもそも、「銀の弾丸」どころか、
・結構多くのシステムは、どんな開発方法論を使っても、開発不能である
→ユーザーのいってることが矛盾してるので、論理的に開発できない
・かなり多くのシステムは、開発すると、採算割れする。
→これは、開発会社も、ユーザーも採算割れする
という暗黙の前提があるように思われます。
（以下、次の水平線につづく。水平線の中は、独り言。。きにしないでね！！）
あのさー、いま、１人月６０（万）から７０（万）のご時世なのよ。
（学者の方やＩＰＡのＩＴＳＳを信じている人へ：なんで、ＳＥの値段が１つの値段に決まるのか。。これには、あるからくりがあります。たしかに予算ではＩＴＳＳのように、階級にわけて費用計上することが可能だし、多くやられるのですが、実は、その予算と実際に取れるお金が違うからなんです。そのからくりについては、（この前中堅のＰＭと話してても、知らなかったので）今度書きます。。って、書いていいのか！こんなソフト業界の裏の実態 ^^;)
いままで、１００から８０くらいは、取れてたわけよ、２０００年のことはね。
１００だったとしたら、６０になったら、４割引っすよ。
きのうのＭＤＡの開発だって、３５％の削減でしょ。ほら、まにあわないでしょ。
さらにねえ、６０もくれないところだって、あるわけよ。
できるシステムなんて、限られてくるのに、きまってるじゃん！
で、さらに、
・ものによって、最適な開発方法論が違うことが明らかである
→ＢＲＥＷの開発をするのに、オブジェクト指向を使われても。。。
あれって、Ｃで書くのが普通なわけです。
Ｃで、ＵＭＬでクラス図書かれても。。。なわけですよ。
そして、一番大事なことは！！
やばい案件に手を出さないこと。
やばい案件に手を出すと、すべての利益をふっとばしてしまう（＞＿＜！）
これは、富士通さんが、たしか、言ってましたよね。
なんか、変な案件に手を出して、赤字になったみたいな。。
大手なら、赤字ですみます。中小零細なら、会社がふっとびます！！
フリーなら、自分がつぶれちゃいます！！
なので、中小や現場にとって、一番の利益貢献になることは、作業の効率化ではなく、
・やばい案件を早く見つけること
・まともな案件を、確実にこなせる、最適な開発標準を見つけること
→つまり、まともな案件でも、適切でない開発方法論をもってくると、失敗してしまう
なので、適切な開発方法論をもってきてほしい。
適切な開発方法論が、ものによっては、オブジェクト指向でないことは
ＢＲＥＷより明らか
だと思います。
開発標準をきめて、その開発標準に従ってやらせることは、開発効率っていうこともあるけど、「こうやると、このプロジェクトはできる！」というやり方をきめるためです。そうすることによって、やばい案件でなく、これは、まっとうに仕事をすれば、まっとうにできる案件になるから。
はっきりいってしまうとですねえ、オブジェクト指向にまったく向かない開発に、オブジェクト指向を持ってきてしまうと、それだけで、開発は失敗します。だから、オブジェクト指向で開発標準なんか、作られると困るわけなんですよ。
なんで、自分たちの仕事をこなせる開発標準をだしてきてほしいわけです。
この開発標準は、メンバーによっても代わります。
メンバーによっては、「ここを触らせたくない」っていうので、その部分をパターンにしてしまったりするから（バッチパターンなんかを作るとき、この意図もかなり多い）。
で、その部分をＰＭさんにつくってもらいたいんだけど、プロジェクトマネージャーは、意味が通じないことが多いんだよね。工場の標準化と同じようにかんがえてしまう。
工場の場合、作っているものは、似ています。たとえば、自動車工場で、おばぎをつくったり、お菓子工場で、ピアノをつくることはありません（って、言い切って大丈夫だよな？？たぶん）。
でも、ソフトウエアの場合、Javaで業務系をやっていた部隊が、次、Cやアセンブラで組み込みやファームとかっていう話、あります（最近、言語とか、ＯＳとか選んでられないのよ！）。
この２つの標準化を考えるってことは、自動車とおはぎの標準化を考えるっていうことで、無理っす！
っていうことで、前書きはととのった。
で、前のブログで書いた、「仕様を要素技術に分解し、その技術に対してリスクドリブンで行うという手法を、「こっそり」上司に見つからないようにやる」（一番最後の部分）について、なんだけど、これは、まず、
・やばい案件を早く見つけること
のために、案件が来たら、要素技術に分解してしまって、その部分だけを抜き出して、確認をとってしまう。
で、その要素ができるかどうかを確認し、できそうなら、使える部隊を考慮して、そこの部分をどこまで隠すかを決定して、パターンを作り上げていくという作業をしてます。
くわしくはですね。。。
げ、また、長くなってしまったので、またこんど。。
いつまでたっても、かけないジャン！
アクセス
トータル
ランキング
