2008年4月12日土曜日

プログラマが仕様を決めるといういばらの道

プログラマが仕様を決めればいい - GoTheDistance
http://d.hatena.ne.jp/gothedistance/20080410/1207832176

工程が分かれてしまっていることの弊害は計り知れなくて色んな問題を引き起こしていると思うのだが、特に思うのが上流工程だけでも下流工程だけでも つまらないんだけど、上流から下流を全部担当するとこれほど面白いものはないということ。ドキュメントだけ作ってチェックするのもつまらなすぎる。他人様 の言われた通りの実装をするだけ、テストをするだけ、というのもつまらなすぎる。でも自分で要件→仕様決定→設計→実装→テストを垂直に行うと、すげー面 白い。色んなことが身につくし、何よりもこれが「システムを作る」ことの醍醐味だと思う。結果としてとても品質の高いシステムができると思う。

だ からプログラマが仕様を決めちゃえばいいんだよ。そのほうがいいに決まってる。マネージャはユーザーの立場に立って要件を抽出しそれを固めていくことに邁 進すればいい。プログラマはその要件を元に「それならこれで出来ます」という仕様を決めて、後は全部自分が実装までやればいい。本来、システム開発は要員 が少ないほうがいいと思う。多すぎるとコミュニケーションコストが高すぎて死ねる。

プログラマ全員が客先言って話を聞くのはきつくない?っていうツッコミ禁止。
どうすればそれが実現できるか?
意外と簡単にできると思う。
どうするのかというと、システムを機能別に分解すると、その機能ごとにお客さんの方でも利用する担当者が見えてくる。そうでなくてもある程度のキーマンは特定できるはずだ。
なので、その担当者とプログラマとが打合せできる場をセッティング市さえすればいい。がんばれSE!経験上、たとえば1画面の仕様を決めるのに、最短でも3回は打合せが必要でなので、まあとんでもない打合せ回数となるだろうけど、プログラマがお客さんのしたいことを把握できるメリットは大きいかもしれない。

システム開発にかかわる会社が多くなると、担当者とプログラマの間に大きな壁があるだろう。それが原因で実現できないケースもあるだろう。
もしそうなったら、実現できない環境ならば、会社をやめちまえ!できる環境にうつっちまえ!


その覚悟を持たずにリーダーから「客先に行って要件聞いてきて!」っていわれても、きっと無理だろう。駄目だろう。今よりもひどいことになるだろう。

まずはそこから。

0 件のコメント:

このガジェットでエラーが発生しました