■

凡ミスを作らないように果てしない労力を費やすよりは、
凡ミスは出た時点でさっくり直せるほうが時間がかからない。

表面上のささいな所に目くじらたてて、
貴重な時間が過ぎ去るのはもったいないことである。
客先に出てしまっているならば別だが、
テストするものも、プログラム作るものも同じ作業場の仲間であるはずだからだ。
身内で喧嘩しててもお客様にいいことなどありゃしない。

プログラマ(PG)ｖｓ監修者(SE)の戦いはいつも両者の視点が違うところから起こる。
　PG：仕様はどれが正解なんじゃ(゜Д゜)ゴルァ!!　
　　　固まらんことには細部なんざ面倒見切れるか(゜Д゜)ボケァ!!
　SE：表面もできてないやつが文句言うな(゜Д゜)ゴルァ!!　
　　　表面さえできてりゃなんとでもいいわけ立てれるんじゃ(゜Д゜)アホァ!!

プログラマにしてみれば。
お客さんの仕様を翻訳した日本語文書(仕様書)を解読しながら作っているわけで、
不明瞭な点はいっぱいのこる。のこってる。
そーゆーもんだ。
だいたい、個別に潰せるほど質問できる環境ならこんなことはそもそも言わない。
だからテスト時に出してもらうと考えてしまうのが世の常というもの。
加えて言うなら、相談してみたら仕様変更になったとかよくある話。
仕様変更時には表面上の動作も変わるのがほぼ必然。
表面上のどーでもいいような動きとかは後回しにするのは当然の行動と言える。
大事なのは「仕様はこれでいいのか？」っというところ。

テストを行う時のSEにしてみれば。
目に見えるところからバグだしするのが通例。
目先で動きがおかしいところがあれば、中身まではやるもんか。
やっても無駄だ。無駄なことはしたくないのが人情というもの。
それにいっぱい出したところで、次回全部が直ってくるはずもなし。
この仕様で作れんPGがアホなんだと思いたくなるが人の常。
大事なのは「表面上の動きと結果」なのだ。

プログラムを組むものとして。
この視点の違いを解しておけば、無駄をできるだけ作らない努力はできる。
仮想敵をそんなSEとしておいてみる。
こうしてみよう。
＜特徴＞
　1.プログラムを作ったことがない。
　2.仕様書から画面動作を想像できてない。
　3.プログラマを下等種と思い込んでいる。

多少特徴的な人物像かもしれないけれども、こーゆーのにでも有効な方法がある。
　(1) なんとかして時間を作ってもらう。
　　　　・仕様確認でも、動作確認でも、理由はとりあえずなんでも可。
　(2) これから見てもらうもんの前提を話す。
　　　　・「まだ出来ていないのですが、動作を教えてください。」
　　　　　「これからキッチリ作っていく前に、意識の擦り合わせをお願いいたします」など
　(3) 画面を見せる。（動作をみせる）
　　　　・仕様書はもちろん用意しておく。
　(4) 絶対にチェックが入るので、その場で調整する。
　　　　・だいたい30秒〜1分以内に動作が変わるなら待ってくれるもんだ。　※←ここ重要
　(5) (3)〜(4)を繰り返す。

最重要注意点はただひとつ。手直しするまでの時間だ。
3分こえちゃうともうだめ。待ってるほうはソースがわからないだけに飽きてくる。
飽きてきたらとどまって居たくないのが人情。
ましてや下位の者に待たせられるなんて行為は耐えがたいと感じるために
とっととどこかへ逃げてしまう。これではミッション失敗となる。
しかし30秒程度なら？
画面動作が見ている間に変化するというのは面白いことである。
ましてや自分の言う通りにモノが出来ていくのである。
そういう気持ちが起こる。だからちょっとくらいならば待つことは苦じゃないと感じるのだ。

こうして作成したものは意識のズレのないものに仕上がる。
それもそのはず、仕様を考えた本人が納得済みのものだからである。
これでゴネれるやつはそうはいない。*1
これにより我々は「確実な動作」を手に入れることができるのである。

両者の意識が一致していれば、視点が違うゆえに起こる戦いは起こりえない。
平穏な日々の恩恵を享受できるのである。
作業スピードも速くなる。
時間の有効活用ができるようになれば、
時間を無為に使うこともできるようになる。
「結果」の二文字の前には多少の融通はまかり通ってしまうのもまた
世の常人の常だからである。

*1:いたらやっつけてもよし。もちろんおいらは責任もちませんが。