« 02.01 このサイトはコンピュータに損害を与える可能性が | ココ | 02.06 やっぱり見積は追い着いてないよな »
2009年2月 2日
画面設計、やめたらどうなる
- [システム開発][Agile開発]画面設計とか外部設計とか、もうやめようよ(ref. masayangの日記（ピスト通勤他)*1
- 失敗事例に学ぶFlexプロジェクトの第一歩(ref. CodeZine)*2
- Re: 画面設計とか外部設計とか、もうやめようよ(ref. ITドカタのWeb巡回日記)*3
最近の話題より。
「画面をどう実現するかを考えて要件分析する」というのは本末転倒。だけど、最初に画面を固めるとそうなりやすいし、結果として工数増加につながるよ、というのを言いたかったのですよ。 *1
Agile派の意見として、masayangさんがいろいろ書かれているのを読んで、何回も読み返してみたんやけどなんか引っかかると言うか、違和感があって…なんでかなぁと思ってたら、
Flex Builderを使うことで、いろいろなデザインがすぐに作れてしまい、また見栄えもよい。すると「いつでも変えられるから」「良い物がすぐにできるから」という理由で要求仕様のハードルが高くなったり、延々と仕様変更が出るなどして、プロジェクト遅延が発生しやすくなってしまう。これは画面仕様が未確定なプロジェクトによくあるという。*2
そう、画面を後から考える、というかフレキシブルに考えようとすると、こういうことになるんだよ。これが、結局はウォーターフォール型であってもAgileであっても、行きつく先としては同じなんじゃなかろうかと。見せれば見せるほど、ユーザーの意識も画面に向くのでなおのこと画面に対する要求は増えるやろうし。だから、画面はある程度決めておかなければいつまで経っても終わらない、なんてことになりやすいんではないかと。「ゴールがなくなった」案件って、発注側にも受注側にも辛いと思うし、やっぱりどこかで妥協する必要があると思われ。
WFだと、開発の後工程にならないと『現行(じゃない)物理モデル(B)』の問題点はだれも指摘できない。だって、それは発注側担当者の妄想の中にしか存在しないから。*3
おそらく、これが一番危険な罠なんだろうな…画面設計以前に。システム開発を何回やかって、慣れてるユーザー企業とかならともかく、初めて発注します、とかで結構規模が大きかったりとかすると悲惨ですよ、まさに。現行の物理モデルもなければ理想とするモデルも規定できないんやから。おまけに現行も理解してないのに理想を言うから余計にイメージが湧かない、作ったものと希望するものが一致しない。
で、コンサルが入ると余計な画面設計書が…というのが*1なんだろうか? 画面設計書なんて要らないと思えばそう発注側に説明すればいいと思うんですが。そうはいかないんでしょうか。ユーザーによって注目するところはまちまちです、それが画面だったり、データ構造だったり。
By ただ at 21:50 カテゴリー ; 仕事関係
« 02.01 このサイトはコンピュータに損害を与える可能性が |
02月の記事
| 02.06 やっぱり見積は追い着いてないよな »
トラックバック
このエントリーのトラックバックURL:
http://pinmarch.sakura.ne.jp/mt/mt-tb.cgi/1367
