アイロベックスメールマガジン　携帯版

システム開発においてプログラミング作業は、いかに細かなことに気づいて漏れがないように論理的に表現するかといったことが求められます。

それは、本当に細かな緻密な作業でもあります。

そこでSEとしてプログラムに詳しくないと思い込んでいる人や、SEとしての仕事はプログラムとは関係ないと思いこんでいる人が陥る罠があるのです。

それはプログラミングの詳細な部分については、プログラマに「お任せ」するべきであり、自分がいちいち口を挟んではいけないと思っていることです。

いけないとは思っていなくても、自らのの多忙にかまけてお任せになってしまうのであれば、結果は同じです。

しかし、こういった仕事のやり方には、プロジェクトチームに新参者やキャリアが豊富でない技術者が参加しているときには、大きな問題がはらんでいます。

そうは言っても、「ドキュメントは詳細に作られるはずだ」「ドキュメントさえ正確に細かく記述されていれば問題ないはずだ」という意見があるかもしれません。

ところがプログラムの詳細設計、特に画面周りの詳細設計については、ドキュメントに書いて表そうとすると、ボリュームがどんどん増えるのに従って、読みこなせない代物に成長していくことが
分かるはずです。

そこでSEは、ありとあらゆる知恵を絞り、定型のドキュメントだけでなく、どうしたらプログラマ同士やSE、テスターを含めてチーム全員の意識を統一させるかを考えることに専念することになります。

たとえ同じ内容を理解していても、人は、文章にすると全く違う表現でものを書くのです。

ここに、「ドキュメントに”愛”があるかどうか」が実は重要だと私は思っているのです。

「愛があるか」それは見ればすぐ分かります。

例えば、「リストボックスの一覧からグループもしくは1行をクリック指定して選択した行を、別のリストボックスに移す処理」があるとします。

左のボックスには、対象となる全ての一覧が表示されています。

ここからグループもしくは1行指定すると、その指定された箇所だけが右のリストボックスに移ります。

仕様書には、「”→”のボタンを押した場合に右に表示される」と書いてあります。

さて、この仕様から質問が生まれます。

(1)右に移した情報は、左のリストボックスから消すべきか

(2)右に移す場合に同じものがダブって右に表示されてよいのか

(3)画面の登録ボタンを押した場合に、どのようなチェックをするのか

こういったプログラミングにおける画面の詳細な動き、例えば、

・どんなイベントをどこで感知して、どんなチェックをどの場所にコーディングするのか

・どんなメッセージが表示されるのか

といったものは、実は仕様書では別々のページに書かれるものであり、また、SEによっては、くどくどと何か所にも同じことを書く人がいたり、必要最小限なことだけを書いて、「あとは想像しろ」とばかりに質問を待つ人がいたりするのです。

実は、どちらの場合も、プログラマはそのドキュメントを読みこなすのに余分な時間がかかり、悩むものなのです。

もちろん、プログラマが経験者であれば問題なく、「質問と確認」といった作業を行うことで、SEが考えていることを理解することが可能です。

ところが、先に述べたような、新参者やキャリアが豊富でない技術者は、こういった作業ができなかったり、気付かなかったりすることが多いのです。

そこで、SEは、ルールに従ったドキュメントを書くべきであり、ルールに従いながらも、もう一つ踏み込んで細かな意思の疎通をとことん行うべきなのです。

実は、プログラミングや単体テストの生産性というものは、SEの詳細設計とその引き継ぎ方法にもヒントがあるのだと考えているのです。

目指せバグ“ゼロ”！ということで、「bug-zero」という名前の、プログラム検収管理のツールを配っています。フリーですので是非、お使いください。

http://www.ilovex.co.jp/info/freeSoft/kenshu.html

さて、当社がバグゼロを宣言して長いのですが、それでもバグは無くなりません。
最近では、わたしの視点は、プログラマにではなくてシステムエンジニアに当たっています。

それは、ある考えに至ったからなのです。
「プログラマは生産性が良い人ほどバグが少ない」というものです。

昔の言葉でいいかえて、「コードが短い人ほどバグが少ない」でもいいと思います。

では、プログラマの生産性は、何が決めるのでしょうか。

プログラマの個人の技術、性格といった、プログラマの能力で決まると思っていないでしょうか。

一般的には、そう思われているようです。

しかし、そこは亀の甲より歳の功。
そうでは無いと言えるんです。（きっぱり）
その証拠には、出来るシステムエンジニアが率いているチームでは、
プログラムの生産性が高いのです。

システムエンジニアの仕事のやり方だけでもプログラマの生産性を上げ、バグを少なくすることができるのです。

それは、詳細設計のドキュメントとその引き継ぎ方法、つまりレビューにコツがあるのです。

プログラムを引き継ぐときに、プログラマがドキュメントを読む前にまず全体像をイメージできるような引き継ぎをするのです。

そして次に、プログラマが陥りやすい罠をどこまで予測して、フォローしてあげられるのかということなのです。

イメージの為には、具体的な例にそったストーリーが大事です。

「営業が会社に戻ってから報告するためのプログラムです。
毎日、営業先から疲れて帰って来てから、今日一日を思い出して、報告書を入力するのです。

少しでも早く、忘れないうちに入力したいんです。
帰宅する直前なので時間もあまりないですしね。

だから、操作性が良いことや、入力したものが途中で消えてしまったりしないことが非常に重要です。

本当に急いでいるときには、詳細は後で入力する場合もあります。
中途のままで登録することもできたほうがいいのです。
そこで「仮登録」と「本登録」という機能に分かれています」

このような現場で使う状況がわかるようなストーリーがいいでしょう。

次に、プログラマが陥りやすい罠というのは、以下のようなことがあります。

1）実際には1,000に一つも無いような余分なことを考えて、それに対処するようなコーディングをすることに時間を費やしてしまう。

2）既に似たような画面、機能を他のプロジェクト等で他人が作っていることを知らずに一人で全部作ってしまう。

3）前回やったシステムが頭に焼きついていて、今回も同じだと決めつけてしまう。

4）今回の仕事は、今までの仕事と違うと信じていて、システムエンジニアが指示したことを自分で曲解し、勝手な思いこみによって、意図と異なる方法で実現しようとしてしまう。

1）と 2）は、システムエンジニアが、細部まで気を配って情報を余すところなく伝える必要があります。

先に述べたように、システムエンジニア自身で、プログラマがどう考えるかまで含めてきちんと細かな絵とストーリーを描いておく必要があるのです。

次に、3）と 4）は、バランスの悪い話ですが、これは、経験が少ないプログラマには本当に良くある話なのです。

そこで、経験が少ないプログラマに引き継ぐ場合には、プログラマの直属の先輩なり上司を含めて引き継ぎを行うことも大事なポイントとなるのです。

先輩であれば、彼らを、性格や技術力を含めて理解し、うまく指導してくれるはずです。

ドキュメントをいかに正確にわかりやすく書くかだけでなくシステムエンジニアとしてどれだけプログラマを見守ってあげられるのか、これが、生産性を上げ、バグゼロを実現する道でもあるのです。

当社ではシステム開発を専門で行っているわけですが、専門が故に、「思い込み」や「先入観」といったもので頭が束縛されてしまっていることがあります。

例えば、「こうあるべき論」とか「理想の形」といったものがあります。

しかし、「それは本当に理想の形なんだろうか？」ということについて、今までどこまで熟考したことが、あるいは、されたことがあるんだろうかと疑ってみることも必要です。

設計手法やチームビルディングでは、大きな理想・目的といったものも必要ですが、細かなことを1つずつチェックし、最適化していくことも役に立つのだと信じています。

では、今回から数回にわたっての課題は「番号」です。

コードと読み替えてもOKです。

コードといえば、わたくし自身、若いときに「取引先コード」で失敗した経験があります。

とにかくその当時は、業務をシステム化するのが初めてといったお客様が多かったのですが、販売管理を発注して下さったお客様から、「得意先コード」をどうナンバリングしたらいいのかといった相談を受けたわけです。

当時、わたしの頭の中にある「コード」とは、あくまでも、「一意のためのもの」にしか過ぎませんでした。

例えば、「頭1桁の"1"は得意先分類、といったような意味を持たせてしまうと、いつかはコード体系が破たんする」という考えが先にきてしまいました。

「得意先分類」や「●●区分」は、得意先コードの体系中に含まれてはいけないと信じきっていました。

得意先管理表を印刷する場合は、金額の多い順や名前順に印刷する方法もあることですし、「得意先分類別」といったような形で印刷すればいいからと考えたのです。

「コードに意味を持たせる必要はありません。適当に付けて下さい」

SEからそんな冷たいことを言われたお客様は、一生懸命考えて取引先グループごとに分けて、「100000～は、このグループ」といったように付けていったようでした。

もちろん得意先コードがシステムの裏側でだけ役に立つのであれば、そういったアドバイスも有効だったでしょう。

しかし当時は、売上伝票を入力するのに、得意先コードを、「得意先名」ではなく「コード」で入力することが必須でした。

名前で照会する画面を作るほど、システム開発の生産性は高くなく、お客様の予算の中ではコード入力、コード範囲指定での印刷が通常だったのです。

そこで、手書きした売上伝票に得意先コードを記入してから、画面入力をする必要がありました。

現場で使ってみれば、毎日毎日、番号チェックをして記入していくので、番号を暗記してしまうお客様がいらっしゃいます。

そうです、頻繁に売上がある「上得意先様」です。

そこで、上得意先の番号をきちんと分かりやすい番号に決めていくといったことも考えられます。

最初に私が考えたように、「コードに意味付けをしたら破たんしてしまう」というものだとしても、コードに振る番号に意味を持たせることは、実際には、とても重要でした。

なぜなら、意味づけされているコードは覚えやすく、また、コード表からの検索も一瞬でできるからなのです。

特に、一覧表や元帳といった帳票系では、得意先分類や区分の次の、第2ソートキーとなるのが「得意先コード」ですから、それも考えるべきでした。

5年後、10年後に取引先が増えて、コードの意味づけが破たんするかもしれないからといって、最初につけるコードが何でも良いわけではなかったのです。

現場の担当者に対する思いやりに欠けていた自分を思い出すたびに、情けない申し訳ない気持ちになるのです。