詳細設計書を書いています。
これができたらプログラムを作ってもらう方に渡して、
補足説明したらプログラムはできあがるはず。
そんなことを考えていたら昔のことを思い出した。
私が別の会社でプログラムをゴリゴリ書いていたころの話だが、
そこでは画面イメージとテーブルと『こんな感じっで』という
説明をもらって私はプログラムを組んでいた。
(それはさすがに言いすぎだが、決して間違ってはいない)
そんな引継ぎではプログラムなんて作れないなどという人も
いるだろうが、当時それが当たり前だと思っていた私はまず
どうやって組むかを考えるよりもシステム全体をつかむ事から
はじめていた。
つまりシステム全体をつかみ、自分が作る部分の前後のデータの
流れをつかみ、そして自分の作る部分が何をする場所なのかを
理解するわけだ。
これはプロジェクトにピンポイントでしか絡まない場合などには
知らなくてもいいような情報なのだが、私にとってはとても仕事を
やりやすくする重要なことだったし、それをやったことによって
システムの問題となりそうな部分も多々みつけたと思っている。
そんな経験があるから私はプログラムを組んでもらう人にはシステム全体を
知ってもらうところからはじめてもらいたいと思っている。
もしプログラムをお願いする側の人で今まで最小限の情報しか
与えていなかったとしたらもう少しバックグラウンドの説明をして
あげてみてはいかがだろうか?
また最小限の情報だけでプログラムを組んでいた人はもう少し
自分の作っているものに興味をもってみてはどうだろうか?
それは今よりも時間を浪費する作業かもしれないがプロジェクトという
単位で見た場合、組織という単位で見た場合良い結果を必ず生み出すだろう。
と私は信じて詳細設計書を書き続ける…
コメント (1)
丁寧すぎる詳細仕様はプログラマの考える力を奪う。
しかし、雑な引継ぎや仕様書はプログラマに自由に想像することを許してしまうために複数のプログラマが参加するプロジェクトでは結果に大きな隔離を生んでしまうことがある。
どちらのやり方でもコツはある。
そして、どちらの場合でも、
あなたが言っているように背景やもっと大きな
システム全体のこと、前後の仕組みに目を向けさせることは
とても重要なことである。
投稿者: sugiyama | 2006年11月 3日 11:52