システム開発においてプログラミング作業は、いかに細かなことに気づいて漏れがないように論理的に表現するかといったことが求められます。
それは、本当に細かな緻密な作業でもあります。
そこでSEとしてプログラムに詳しくないと思い込んでいる人や、SEとしての仕事はプログラムとは関係ないと思いこんでいる人が陥る罠があるのです。
それはプログラミングの詳細な部分については、プログラマに「お任せ」するべきであり、自分がいちいち口を挟んではいけないと思っていることです。
いけないとは思っていなくても、自らのの多忙にかまけてお任せになってしまうのであれば、結果は同じです。
しかし、こういった仕事のやり方には、プロジェクトチームに新参者やキャリアが豊富でない技術者が参加しているときには、大きな問題がはらんでいます。
そうは言っても、「ドキュメントは詳細に作られるはずだ」「ドキュメントさえ正確に細かく記述されていれば問題ないはずだ」という意見があるかもしれません。
ところがプログラムの詳細設計、特に画面周りの詳細設計については、ドキュメントに書いて表そうとすると、ボリュームがどんどん増えるのに従って、読みこなせない代物に成長していくことが
分かるはずです。
そこでSEは、ありとあらゆる知恵を絞り、定型のドキュメントだけでなく、どうしたらプログラマ同士やSE、テスターを含めてチーム全員の意識を統一させるかを考えることに専念することになります。
たとえ同じ内容を理解していても、人は、文章にすると全く違う表現でものを書くのです。
ここに、「ドキュメントに”愛”があるかどうか」が実は重要だと私は思っているのです。
「愛があるか」それは見ればすぐ分かります。
例えば、「リストボックスの一覧からグループもしくは1行をクリック指定して選択した行を、別のリストボックスに移す処理」があるとします。
左のボックスには、対象となる全ての一覧が表示されています。
ここからグループもしくは1行指定すると、その指定された箇所だけが右のリストボックスに移ります。
仕様書には、「”→”のボタンを押した場合に右に表示される」と書いてあります。
さて、この仕様から質問が生まれます。
(1)右に移した情報は、左のリストボックスから消すべきか
(2)右に移す場合に同じものがダブって右に表示されてよいのか
(3)画面の登録ボタンを押した場合に、どのようなチェックをするのか
こういったプログラミングにおける画面の詳細な動き、例えば、
・どんなイベントをどこで感知して、どんなチェックをどの場所にコーディングするのか
・どんなメッセージが表示されるのか
といったものは、実は仕様書では別々のページに書かれるものであり、また、SEによっては、くどくどと何か所にも同じことを書く人がいたり、必要最小限なことだけを書いて、「あとは想像しろ」とばかりに質問を待つ人がいたりするのです。
実は、どちらの場合も、プログラマはそのドキュメントを読みこなすのに余分な時間がかかり、悩むものなのです。
もちろん、プログラマが経験者であれば問題なく、「質問と確認」といった作業を行うことで、SEが考えていることを理解することが可能です。
ところが、先に述べたような、新参者やキャリアが豊富でない技術者は、こういった作業ができなかったり、気付かなかったりすることが多いのです。
そこで、SEは、ルールに従ったドキュメントを書くべきであり、ルールに従いながらも、もう一つ踏み込んで細かな意思の疎通をとことん行うべきなのです。
実は、プログラミングや単体テストの生産性というものは、SEの詳細設計とその引き継ぎ方法にもヒントがあるのだと考えているのです。
Vol.00155