なんだか笑えない
http://d.hatena.ne.jp/JavaBlack/20081231/p1
「現場のSE, PGが考えるデスマる条件とは」
自分の立場で1つ1つ確認してみた．ほぼ当てはまるんですけどｗ
思うことをつらつらと書いてみる．
- ウォーターフォール・・・○
- 自分が見聞きした限りで，これ以外の進め方をしているSIプロジェクトを知らない．*1顧客フォーマットの開発計画書もこれが前提になっていて，要件定義，外部設計，内部設計，製造，テスト，移行，稼動って欄があって，それぞれに上長決裁欄にハンコが押されると，お金が入ってくる仕組み．だから戻りは“ありえない”という前提で物事が進む．でも現実はそれとは乖離しているからデスマる．
- 反復型開発とかウォーターフォール以外の開発プロセスでSIを行っているプロジェクトって，契約面では顧客とどう合意をとっているのだろう？機能とか要件単位（TracとかRedmineのチケット単位？）とか？自分ところの状況で言えば，顧客は機能単位とかの価格が高価なのか安価なのかなんて判断できないから，結局「これだけの予算を用意したから，その枠内であの機能とこの機能は必須で，これもつけてね」なんて感じで要求してきて，あとはそれと開発側の思惑とのせめぎ合い，なんてことばっかりで，他の開発モデルでやらせてくれっていってもコスト面で他社と比較できないから無理です，って言われるのが関の山なんですよね．顧客は予算内にやりたいことを盛り込んでできるだけ低コストに，ということが全てだから．その後の拡張性や保守性なんてのは二の次．
- 低スキル - 大人数開発・・・○
- 人数×単価が売り上げというビジネスモデルなところは，すべからくこれは当てはまると思うんですよね．ってことはSIという業態≒デスマ？低スキルな人は，1人月どころかマイナスに作用する*2人もいる．そういう人を派遣している下請け会社は，自社に篭らせても金食い虫になるだけなので，なんとかうまいことどこかに潜り込ませて1円でも稼いでくれば御の字，と思っている．元請けは設計・実装のスキルを磨くことよりも，そういう人を何とか上手く使って結果を出すことを求められる．こう見ると，最初から失敗するのは目に見えている気がする．
- 人月単価・・・○
- 上に同じ．
- 多重下請け構造・・・○
- 上に同じ．
- 時代遅れのスキル・・・○
- 年功序列・・・○
- 技術スキルだけなら，正直言って若い人の方が何倍も高いと思う．けれども，「業務知識」という言葉を盾に，経験年数を積まないと「業務知識」なんて付かないから，経験が豊富＝年功が高い人が上，「業務知識」を知らない単に実装する人が下，という階層構造を上の人が作り上げる．そこに安住するためにね．でも，「業務知識」なんてのは若い人でもやらせれば理解するし，やらせないとわかるはずもない．大体，そんな何年もやらないと理解できないようなことだったら，ユーザ側の若手も業務が理解できないということか？実際に業務こなしているのってユーザの若手じゃないのか？一番難しいのは，そういう業務を実装レベルまで落とし込むのが難しいのであって，結局は“上”の人がそこに安住するために作り出している構造に過ぎない．
- 「設計工程」と「プログラミング工程」（製造工程）を分割する・・・○
- これも上に同じ．で，いつも違和感を感じるのは，コーディング作業を「製造工程」と呼ぶところ．どこのプロジェクトもそうなのかな？
- 「上流工程」という名目で時間と資金を浪費・・・○
- これも上に同じ．「上流工程」が完璧になされないと下流で手戻りが発生するから，と世間話や与太話が半分以上を占めるミーティングを何度も行って時間を浪費する．「上流工程」ができる人は単価も高いから資金も浪費する．
- PMBOKやITSSが幅をきかす・・・○
- PMOなんてのが最近立ち上がったらしく，やたらと管理資料を作らされる．JavaコードのSTEP数を算出しろなんて依頼も日常茶飯事．
- 技術者の意見より管理職や営業の意見が優先される・・・○
- お金を動かしているのは我々だ，と思っているのだろうと．
- コン猿が大きな顔をする・・・○
- 最近某社が入ってきて，勢力拡大している．やたらとPowerPointで資料を作っている．彼らは見せ方が上手いので，顧客も乗せられて大分お気に入りのよう．
- 実現可能性も分からないまま無理難題をふっかける顧客・・・○
- それを実現するのがあんたらの仕事でしょ？くらい思っているのだろうとつくづく思う．
- しかもそれを断らない担当者・・・△
- これは自分の身を守るためにも心掛けていることではあるけれど，プロジェクトメンバーが満足しているほどかどうかというとわからないので，自戒したい．
- 鉄筋減らしてコストダウン・・・○
- 予算枠が決まってるから・・・云々．
- 機能が際限なく追加される・・・○
- 予算の権限がユーザではなくシステム部が持ってたりすると，ザラだ．
- 意味もなく頻繁に仕様変更・・・○
- 監督省庁の監査が入ったから，絶対に変更しないとダメ，とかザラだ．
- しかも納期と予算はそのまま・・・○
- 業務改善命令で期日は決まってるから納期は延ばせない，年度予算もこれだけしかないからこの枠内でなんとかしてくれ，とかザラだ．
- さらに人を追加する・・・○
- 管理職の人は人追加すれば終わると本当に思っている．
