T

ホーア式、人事、仕事

最近ずっと勉強しているホーア式について考えてみた。

(俺が知ってる)ホーア式:

precondition { execute } post-condition

前提条件(precondition)があって、何か実行(execute)すると結果(post-condition)になる。

ロジックとして考えると、面白いことがいくつかある。例えばexecuteで例外や無限ループが発生すると、ロジックとしてはこの式はTRUEになる。なので、実際の業務とかプログラムのテストで使う場合はタイムアウトや例外発生時についても記述しておかないといけない。あと、preconditionがそもそも成立しない場合も、この式自体がスルーされるのでやっぱり結果はTRUEだ。ちょっとややこしいが、これをプログラムのif文だと思えば、そもそもif(precondition)が成立していなければこのif文の中身が実行されることはないので、式が存在しないに等しくなるからだ。

こういったことを踏まえて、ユニットテストが可能なプログラムの作成とホーア式にあてはめたテストによるプログラムのテストを実行できるようにする、というのが目下の俺自身のテーマでもある。いや、真面目な話。

で。

高校のとき、初めて教室に入ったら、壁に「ホーレンソー」とか書いてあった。報告と連絡と相談の頭を取って繋げてホーレンソー。これが大事なことだ、という。まるで密告でも奨励するかのような標語に非常に違和感を覚えたのだが、プログラミングの仕事をするようになって開発会社で働いているとやたらとこの言葉を耳にする。それから、PlanとDoとCheckの頭文字を並べたPDCという一昔前の携帯電話みたいな用語もあって、これもミーティングなんかでしょっちゅう聞かされる。PDCというのは、計画を立案して、実行して、その結果を計測するという意味のようだが、仕事の進め方はとにかくPDCでやるべきであり、その結果をもってその人の業務の評価が上がったり下がったりするというもの。この手のシステムで人事評価を下している会社はたくさんあるだろう。

でも、プログラミングの世界では、ホーア式のチェックやPDCが人事評価に繋がるというのは明らかにおかしい。

PDCは、ホーア式と基本的によく似ている。preconditionがあって、計画を立案して、そいつを実行して、post-conditionをチェックする。

plan { do } check

全部動詞が入っているのでちょっと違うが、まあ要するに業務の計画と実績はplanがあってdoしてみてcheckによって評価して、それがTRUEであればあんたは頑張ったと給料を払って、FALSEであれば何をやっとんじゃこのボケどこでそんなボンクラ頭を拾ってきた、とどやしつける。これが人事評価と呼ばれる拷問だ。

でも、プログラミングの世界でこれをやるのは明らかにおかしい。だって、プログラムを作ったら、普通はまずテストをするはずだ。そこで結果が間違っていたらどうする?直すでしょ。部下が組んだプログラムがホーア式でFALSEの状態のまま納品されていたらみんな怒るかもしれないけど、ブラックボックステストあるいは単体テストでこの状態であれば、とっとと直してくれというだけだ。

なぜなら、プログラミングの世界では、この時点での目標はprecondition { execute } post-conditionがTRUEになることであって、これを実行して真偽を確認するのは、単純にコードを書いたりテストをしたりするのと同じで、開発の中のひとつのプロセスに過ぎないからだ。その意味では、プログラムはこの時点ではまだ完成していない。テストは完成に至るためのプロセスの一つであり、それ以上でも以下でもない。そして、最終的な目標は、仕様の通りにプログラムが動くようにすることなのであって、これまたそれ以上でも以下でもない。それに、往々にして最初の設計や仕様がプログラムを作っていくにつれて現実にそぐわないものであることが判明するなんて日常茶飯事で、それをどうにかこうにか改良するプロセスは開発につきものだ。だから、最適化したりここを直したりそこを直したりといった作業が発生し、それがプログラミングの日常になっている。

ところが、いわゆる会社の業務というやつは、結局ここで例外だのエラーだのが発生することはすなわち担当者の誤りであって、部門あるいは全社的な最終目標を達成することよりも毎週ミーティングで提出させられるPDCの結果報告で点数を稼いでおくことの方が人事評価的には重視されるケースが多い。いうなれば、単体テストで×がついた項目があればそれだけで上司やら同僚やらに非難されてしまうのだ。プログラマにとっては理解しかねることだが、普通の会社ではこれが当たり前のようになっている。決算前に業績を積み上げるために価格を下げるような売り方がまかり通ってしまうのは、この短期的なPDCサイクルの中で評価を上げるためであり、それが長期的に見れば決算期以外の時期の買い控えを招くことになっても、個々の営業担当にとってみれば知ったこっちゃないというのと同じだ。

これは明らかにおかしい。作ったプログラムの中に単体テストで動かない箇所が見つかった場合にはプログラマにペナルティを課すなんてナンセンスだろう。動かない箇所を見つけるためのプロセスがテストなのだから、ペナルティを課すのでは目的が違う。もしそんなことになったら、プログラマは誰もテストに自分のプログラムを提出しない。工期が切迫していようがなんだろうがとにかくどこまでも自分でテストして、問題がありそうな箇所があればなんとか隠蔽するかもしれない。

ところが、プログラミングの世界を離れると、実際にこの手の隠蔽工作は会社の中では頻繁に行われていて、チェックの不備を突いたマジックであろうがなんだろうがとにかく数字合わせが出来れば問題なし、ということになるケースが非常に多い。なぜなら、それは営業にとってペナルティを逃れる手腕の一つであり、管理職にとって上司に怒鳴りつけられるのを回避するための処世術だからだ。チェックは仕事のプロセスの一部ではなくて、どちらかといえば検閲や取締り、ガサ入れに近い。

0.49999999999 { 四捨五入 } 0

Posted by on 7月 12, 2007 in Work

コメントを残す