最近、ひがやすをさんや弾さんがプログラミングファーストについて言及されているわけですが、ホントその通りだと思います。
社内SEなんてやってると、ユーザーとSIerの間に入って業界の慣習だとかIT専門用語だとかをそれぞれに分かるように通訳して、仕様をまとめるお手伝いなんかするわけですが、正直に言ってこの段階では双方(&自分も)よく解かってないなりに進めてる部分って大いにあるんですよね。
で、いざ動くモノができて始めて「ああしたかった」「こうしたかった」「ココは違う」なんて意見がユーザーから(ようやく)出てくるわけです。特に「ココは違う」なんてのは最悪で、ユーザーに「仕様通りに作っただけ。あなたも仕様書に同意したでしょ」なんて言ってもムダだし、そもそも直さないことには業務に使えないと言うし・・・orz
とにかく動くモノを見せてもらって、動作をユーザーに確認させながらスパイラルに開発してもらうのが1番なのは解ってるんですけど、SIerさんにはSIerさんの会社の都合があるし、ウチの経営層も「先ずは仕様書ありき」とか言ってるし・・・なかなか。ねぇ。
で、ここに来てITベンダーやSIerのソフトウエア開発に対して、新しい会計基準である「工事進行基準」が適用されるって話になってきて、2009年4月以降は
- 要件定義、設計、開発、テストの各工程を一括で契約する。
- 要件定義が終わらないまま、開発作業に着手する。
- 契約の変更・追加なしに、開発途中の大幅な仕様変更を実施する。
- サーバーやネットワーク機器といったハードウェアとソフトウェア開発を一体で契約する。
ような受発注が(原則的に)出来なくなるんだそうです。でまぁ、今後は分割契約が標準になっていくだろうって話なんですよね。
「工事進行基準」を適用する目的は、曖昧さを排除とプロジェクト品質の向上だそうですけど、これってITベンダーやSIer側から見ての話ですよね。ユーザーが欲しいのは「曖昧さの排除」でも「質の高いプロジェクト」でもなくて「使えるシステム」なんですけどねぇ。
しかも分割契約になったところで開発会社を途中で変えるなんてあり得ないわけです。だってA社が作った仕様書をB社に持ち込んでも開発出来るかどうか解らないわけですよ。だって業界標準の書式なんて無いんですから(もちろん、開発手法、開発手順とかも会社ごとに違うと思われます)。
発注する側にしても分割契約になると、全体でいくらかかるのか解らないわけですよ(まぁ、内々にこの金額でおさめましょう的な話はするにしても)。どうやって合い見積もり取るよ?みたいな。
もちろん経営層が気にするのは「そのシステムがいくらで作れるのか」だから、とりあえず要件定義に100万出しておいて、その後の開発費用が高すぎるようなら要件定義の100万はドブに捨てる。なんてありえないわけですよ。他社に依頼することにしてもその会社として必要な情報は集め直さないといけないので、要件定義の費用が膨らむことになるし・・・。
そう考えると、内製するのが1番じゃないの?とか思うわけです。社内の事も業務の事も業界の事もSIerよりは解ってるし、プログラミングファーストでスパイラルな開発も好き放題だし、人件費も開発費に比べれば安いはず。
そうじゃなきゃ、パッケージソフトを買ってきて業務をソフトに合わせた方が幸せになれそうな予感。
参照リンク
・ひがやすを blog:プログラミングファースト開発の必要性
・404 Blog Not Found:プログラミングファースト開発のアキレス腱
・ITpro:IT業界に激震走る!