m_pixyさんのブログ、「PM見習いの読書日記」の、「その作業にかかる時間」
を読んでいて思ったこと。
揚げ足取り的なツッコミなのですが。。。
（あ）「その仕様書を作るのには１ＫＳあたり○○時間でやれますか？」と聞いてしまう理由と、
（い）設計段階での工数がひとつ前のプロジェクトの２，３倍かかってる理由と、
（う）その前のプロジェクトで設計工程起因のバグを出しまくってお客さんに迷惑かけて
いる理由って、普通、おなじと思っちゃうんですけど。。
あ、ついでにいうと、
（え）EclipseやIDEAでコード書くような感覚で仕様書を書けるツールない理由も
（お）ExcelやWordに書いてあるだけの仕様書より、ExcelやWordに書いてあるだけの仕様書より，ソースコードのほうが，はるかに有益の情報を知る事が出来る人がいるのに、ExcelやWordで仕様書を書く理由も、
全部、おなじことだと思ってるんですけど。。。(@_@!)
はじめの件。
要するに、「設計工程起因のバグ」が出る理由は、たいていこんなかんじじゃない？？
（１）ヒアリングを体系的にやってない
→これは、論外。ふつう、やってるよね。
まさか、客先にいって、「さあ、どういう風にシステム作りましょう？
って、営業みたいに単純に聞く人はいないよね。
この辺の、意識あわせ。。する？しなくていいよね！
（２）ヒアリングから資源関連への落とし込みが出来る、体系的テクニックを持っていない
→こいつも、論外。普通、（本に書いてあるのは、いい加減だけど）
佐藤正美さんのセミナーなんかでは、教えてくれるから、
（さらに実際には、アレンジしないといけないけど）
まあ、できてるよね。これも、いいよねえ。
（３）客が言っていることを、真に受けている。客が、うそを言いうる
（っていうか、たいていうそだ）ことをわかっていない。
→こいつも、いいよねえ。。説明いらないよねえ。。
客がヒアリングでいうことは、たいてい、いい加減だ。
つーか、人間って、たいていいいかげんだ。
（４）客がうそを言っている場合、その矛盾を見抜くテクニックがない。。。
→こういうやつは、救えない。一生、客に踊らされる。
仕事を変えるか、テクニック身に付けないと、どんなに働いても、
たぶん、仕事が出来ずにつぶされる。
（５）客が言っている正しいラインから、資源への結びつきをつける、業務パターンを構築する能力が「ない」人が、ＳＥになっている。
→ＳＥかえたほうがいい。じゃないと、システムできない。
（６）その業務パターンから、仕様書のフリーフォーマット欄に書くパターンと、プログラム・テストが、自分の頭の仲で結びついていない。
→つーか、あのExcelのフリーフォーマット欄を、本気で、フリーフォーマットに
使うやつがいるのよ！！
お、おい！それで、理解できるわけないだろう。。。
で、たいてい、設計でミスるのは、（４）、（５）、（６）の能力に欠ける場合だと思う。客に言われたことを、なにもかんがえずに、システムにしようとしたり、仕様書に落としてしまう場合。
仕様書には、明確な書き方があって、それは、ソースコードとだいたい結びついている。だから、「仕様書のフリーフォーマットに書くパターンなになにのばあい、プログラム１ＫＳあたり、どれだけ」というのは、いえる。
ところが、この仕様書への落とし込み方がわからないと、客が言ったことに振り回される。
客は思いつきでいうから、話がぶれる。アジャイルで開発するとき、この客の話の「ブレ」を見抜かないと、客に振り回される（っていうことは、アジャイルの本に書いてない気がする。。つまり、客のうそや、夢、本心でないところの見分け方、おばかな客のあしらい方など。。。あんまり、本に書いてないよね。。）
で、振り回されると、設計段階での工数が、普通より、何倍もかかる。
つまり、設計起因のバグが多いのとか、逆に、工数が伸びるのって、
・ヒアリングから、客のうそをみぬき、
・本筋のラインから、ビジネスのパターンに落とし込んで、
・必要な仕様書に展開し、
・その仕様書から、ソース、テストを作っていく
流れが、わかってない場合が、結構あるとおもう。
で、これがわかっている人が、「短期納品、大量生産」できるんだけど、これを出来る能力がない人が、みようみまねでやると、「１ＫＳあたり○○時間」っていう質問になるのよ。。。
ということで、（あ）から（う）が、上記の理由だということは説明した。
のこり、（お）について。
プロジェクトによって、プログラムの書き方が違います（フレームワークを作る、共通部分の開発の人の好みとか。。）。
でも、Excelの仕様書は、それらの違いがあっても、だいたい、おなじになるから。
Excel仕様書のフリーフォーマット欄の書き方は、大体同じに出来て、そこから、各プロジェクトごとの書き方にあったプログラムに自動生成できる。
それに、そもそもプロジェクトが大きくなってしまいと、Javaでやるとは限らないし(今日はウィリアムのいたずら、VC++の日だし）。。。
つまり、（え）の、そういうツールがないのは、上記の「ビジネスのパターンに落とし込んで、必要な仕様書に展開し、その仕様書から、ソース、テストを作っていく」流れがわかる人にとっては、仕様書で書いても、プログラムで書いても同じなのよ。
なので、自動生成しやすいExcelで書いて、パターン変更があったとき、その自動生成プログラムを修正するという手を使うためだと思う。
つまり、問題は、「ビジネスのパターンに落とし込んで、必要な仕様書に展開し、その仕様書から、ソース、テストを作っていく」流れっていうのがある。
そんな、仕様書のフリーフォーマット欄の使い方とプログラムの手抜きの実態とかを、書こうと思ってるんだけど。。。最近、ウィリアムのいたずら、個人的に忙しいのよ。
それに、今日はＶＣ＋＋の日だし（明日もかなあ。。）
別にＶＣ＋＋で説明してもいいんだけど。。きっと、見てる人って、Javaだよなあ。。
つーことで、この「仕様書のフリーフォーマット欄の使い方とプログラムの対応」は、後日になるのであった（つーか、そもそも、そんなこと書いていいのかなあ。。あれって、どっこの本にも書いてないってことは、世間では、企業機密なの？？）。
さ、ブログなんか書いてないで、おしごとおしごと。
アクセス
トータル
ランキング
