　今晩は履歴書とかいう摩訶不思議なモノを書く必要に迫られ、作業はなし。代わりにといってはなんだが、今回はちょっと「仕事の仕方」というモノに関するオイラの発見を語ってみたい。今までオイラは公務員として建設業界で研究8年、行政1年、そこから転職してIT業界で数年間プログラマをしてきた。そしてその過程でなにげに「オブジェクト指向ワーキング」こそ、仕事を効率よく片付けるための手法だと気づいたのである。

　一般にオブジェクト指向プログラミングというと、すぐに「飛行機も自動車も乗り物でぇ」みたいな、大変に誤解を招きやすく、むしろ概念をわかりにくくしてしまうような、スットボケた例えが横行している。しかし、ソコソコのRuby使いであると自負しているオイラに言わせれば、オブジェクト指向は「コードの擬人化」に他ならないと考えている。

　オブジェクト(=インスタンス)は労働者なのである。よってオブジェクトの型枠であるクラスは労働者の職業だといえよう。例えば「巡査クラス」とか「プログラマクラス」ということになる。メソッドはその労働者の能力だ。巡査クラスのメソッドは「聞き込みメソッド」とか「パトロールメソッド」だ。そしてプロパティはその能力遂行のために必要な情報。聞き込みメソッドに必要なのは「事件概要」と「地図」ということにでもなろうか。上記のように例えると、継承も簡単だ。巡査は聞き込みしかできないが、刑事は巡査の仕事に加えて犯人を推測できる能力、つまり「犯人推測メソッド」を持たせた職業だと考えると、これが継承となる。

　こうやって擬人化をすると、上司が部下を1)採用し、2)資料を渡し、3)仕事をさせるのは、メインプログラムが1)インスタンスを生成し、2)プロパティを設定し、3)メソッドを呼び出す、という状況とピッタリと一致するのだ。

　そして、双方の状況が一致することは、逆方向の分析も可能ということである。つまりクラス設計や効率的な処理の方法は、実際の職場の労働方法にフィードバックできる可能性があるのである。

　オブジェクト指向なプログラムをうまく書くコツとしては「クラスは単機能のほうがいい」「インスタンスは狭いスコープの中で使い捨てるといい」「インスタンス間の通信はないほうがいい」あたりの項目が挙がるだろうか。しかし、これをそのまま職場の労働方法に当てはめると恐ろしいコトになる。「部下はそれしかできないヤツのが使いやすい」「プロジェクトが終わったら解雇したほうがいい」「部下間の交流はないほうがいい」。こ、こりゃドライだ……。

　しかしながら、ある意味、これは真理なのかもしれない。事実、正社員を育てるコトを考えず、積極的に派遣社員を活用している昨今の会社の就労形態は、極めてコレに近いといえよう。この事実から、労働方法としてもオブジェクト指向が効率的であることは、証明されたようなモノである。

　ただ、そういった社員の非人間的な扱いの是非はともかく「インスタンス間の通信はないほうがいい」という事実を「会議はないほうがいい」に振り替えて考えると、これも真理を突いているコトがわかる。ホントは「たったひとりの労働者」が「まるごとひとつのプロジェクト」を回すのが効率がいいのである。なぜなら労働者間の連絡や調整、つまり会議の必要が一切なくなるからだ。しかしながらひとりの労働者の労働量は知れているので、しかたなく多人数でプロジェクトを回すのである。こう考えると「会議とは本来ムダなもの」というコトが明らかになる。これにより「会議に多くの時間を費やす上司は無能である」という証明まで導かれてしまうのだ。あな、恐ろしや、オブジェクト指向。

　では有能な上司の条件を「インスタンス間の通信はないほうがいい」から導き出すと、プロジェクトのタスクを「極力関連の薄い複数の仕事に割って個々に割り付けられる能力がある」というコトになるだろうか。これはまさにオブジェクト指向プログラミングの特徴である「カプセル化」の応用であろう。

　またオイラの経験だが、なにかと「一緒に作業しよう」と持ちかけてくる人は無能な人が多いと感じている。一緒に作業をするということは、すなわち会議を増やすということである。無能な人は責任の分担をあいまいにしたがる、つまり上述のカプセル化の逆だ。有能な人は上司に「共同で作業しろ」といわれても、早い段階で仕事をスパッと割るハズだ。

　有用なメソッドを持たないクラスは使いづらく、クラスを効率的に使わないメインプログラムには無駄が多い……オブジェクト指向は、まさに会社組織の縮図である。なむさん。

　おぉっと、早くもOLIMEXから昨日の注文に対する返事のメールが来た!!　ドリル数500超の$3.3以外は追加料金なしで一発OK!!　あとは、添付されたpdfの書式を印刷、内容を埋めてFAXするだけだッ!!　ヤッホーィ!!

[ツッコミを入れる]