読者の方から激励のお便りをいただきました。嬉しいものですね。
その時に、「何かご要望は？」とお聞きしたら、このタイトルがご注文でした。
お題いただきました。・・です。
SEの促成栽培については、このメルマガを書き始めた頃からの、私自身の課題です。
これを語るために、「何が出来たらSEなのか？」ということを、初心に戻って考えようと思いました。
SEの定義は、プログラムを組み合わせて、業務の仕組みを作る人である。
では、「プログラムが得意な人がいいのか」というと、この業界では、何十年も前から、そう思われてきましたが、「そうとも言えない」と私は思っています。
ただ、プログラマに指示をしたり、報告を受けたりすることが作業になりますから、プログラマが「どのようなことを考えているのか」を知り、プログラマの癖を理解していることが、望ましいことになります。
優秀なプログラマは、「もし、例外的なデータが入ってきたらどうなるのか？」「もし、プログラムが起動しているところで電源が落ちたら？」といった、1％の確立でしかありえないようなことでも、「絶対にないこと」でない限り、そのリスクを想定して、プログラムを作るのです。
それが、優秀といわれる所以です。
ですから、彼らの不安を解消してくれるSEが、プログラマにとって、一番頼りになるのです。
例えば、文字型の項目「税フラグ」というものがあるとします。
この「税フラグ」を使用する場合、プログラムには、
1の場合は・・・・。
2の場合は・・・・。
というように、処理を記述します。
仕様書には、この1と2の場合についてのみ、記述されていたとしても、プログラマは、0のとき、NULLのときなど、全てのデータパターンにおいて、正しく動くプログラムを作らなければいけないのです。
NULLである場合が存在するのか、といったことも含めて、そのシステムで発生するデータパターンを、きちんと説明することが非常に重要です。
実際、プログラマにしてみれば、データパターンだけでなく、
・プログラムで用いるレコード件数が、何件を想定しているのか。
・レスポンス（応答時間）はどのくらいまで待つことを許されるのか。
など、説明がなければ、分からないことばかりなのです。
このような一つ一つの背景を、きちんと説明しておかなければ、プログラマに、余分なコーディングをさせることとなり、生産性の悪さにも繋がります。
プログラマが理解していれば、作成をする前から、対処していたものを、説明が足らなかったばかりに、作り終えてから修正しなければいけない、ということさえ、引き起こしてしまうこともあるのです。
ですから、SEは、プログラマからの質問がなくても、また、「仕様書を読んでから質問します」などと言われても、無理やりにでも、
1．誰が、いつ、どこで、そのプログラムを使用するのか。
2．そのプログラムが、システムの中でどのような役目をするのか。
3．データの中身について、どんなパターンが考えられるのか。
逆に、どんなパターンは考えなくてよいのか。
4．データの件数と、求められるレスポンス。
を、丁寧に説明するべきなのです。
そういった意味では、優秀なプログラマは、SEが教えてくれなくても、これらのことを突っ込んで聞くものです。
だから、若手SEは、キャリアのある（優秀な）プログラマと、仕事をするのが良いと思うのです。
●ポイント
SEは、プログラマの不安を解消し、一番最適な技術やアイデアを引き出すために、そのシステムの情報を、正しく伝える責任があります。
プログラムの設計については、プログラマに正確な情報を提供し、お互いの役割を果たせるような、コミュニケーションをとる義務があります。
Vol.00134