プログラミングファーストの問題点

開発

経済学関係ではトンデモの汚名を着せられているdankogaiだが、さすがに本業についてはわかってらっしゃる。

実は私自身、この言葉が生まれる前から実践してきたのだけど、一つけったいな問題点があるので、それを指摘しておく。

それが何かというと、

客がそれを安易だと勘違いして、安価だと思いやすい

こと。

404 Blog Not Found:プログラミングファースト開発のアキレス腱

プロトタイプ開発もそうだけど、目に見える部分だけを高速に開発すると、すでにできあがったのだと勘違いして本当の開発部分に金を払ってくれなくなる傾向にある。

特にACCESSとか得意なお客だと、なんでACCESSで数日あれば作れるものが数百万もするのか、とか本気で言い出すので困ってしまう。だったら発注しなくていいから自分でACCESSで作ってください、とか言いたくなってくる（余談だが過去の経験から言うと、先方担当者が技術者として有能な場合、プロジェクトはむしろ失敗に向かうことが多い。なぜかと言えば、業務的価値よりも技術的価値に自然と重きを置くため、本人以外には何らメリットのないところにお金をかけてしまいがちだからだ）。

システム開発の難しさとは言うものの、実際に難しいのはシステムを開発するところではないのがミソ。今の時代、純粋にシステム開発で失敗することなんてめったにない。

最近、これが一番良いのではないかと思っているのは、小規模ウォーターフォールによる継続的開発。プロジェクトを一番成功確率が高まる1000万円〜3000万円、三ヶ月から半年の単位に分割し、緊急度が高く、既存システムへの影響度が低いところから順次開発していく。契約もその単位で行う。要件が上記範囲に収まらないとか要件が決まらない場合は分割するなどして次単位の開発に送る。なお、フェイズが予定通りに終わらない場合は次のフェイズに進めないことを明言しておく。違約金の支払いをしてでも次フェイズに進ませないことが重要。

また、画面辺りの金額などで金額のルールを明示することも重要。せっかくJUASが画面辺りの一般的な工数を算出してくれたのだから、それに乗っかるのもよい。

しかしながら、問題はPMにお鉢が回ってきたときにはすでにプロジェクトの概略が決められてしまっていることなんだよな。最終的には双方損するはずなのに変更できないのは辛いね(w