ゲスの極みエンジニア。
エンジニアにはゲスが多い。というか、ゲスだらけだ。右を見ても左を見ても、上司も部下も、先輩も後輩も、みんなゲス、ゲス、ゲス！
どこもかしこもゲスだらけ。なんだこの状態は。これぞゲスの極みというものではなかろうか？
■だれがゲスだって？
もちろん、ここでいうゲスとは下衆のことではない。まぁ、中には下衆なエンジニアもいるかも知れないが、そういう人をここで告発しようというわけではない。
guess、つまり推測とか推察とかいう意味の英語だ。もう少しシチュエーションをわかりやすく限定すると、「自分勝手な思い込みで判断して行動してしまうこと」と思っていただきたい。そんな困った行動の多いエンジニアを、ここでは「ゲスなエンジニア」と定義してみる。
そういう意味で振り返ってみると、あなたにも思い当たるフシが山ほどあるのではないだろうか？
■どうしてゲスなんて言い始めたんだ？
実は先日、たまたま最近出版されたばかりの『外資系コンサルが実践する資料作成の基本』という本をぱらぱらとめくっていたら、最初の章の図の中になんの前触れもなくカタカナで「ゲス」と書いてあるのを発見してしまった。その言葉が目に入った途端、今回のコラムのタイトルが思い浮かんで頭から離れなくなってしまったというわけだ。
この本はタイトルの通り、資料作成に関する様々なティップスが書かれている。コンサルの人が書いたものなので、ここで想定しているのはプレゼン資料なのだが、資料作成の心構えやOffice製品での資料作成時のティップスなど、エンジニアにとっても有益な内容は多い。
■ゲスなエンジニアと言われないために
われわれが日々目にする資料にも、ウンザリするほどたくさんのゲスが存在する。ゲスなエンジニアが作成したゲスな資料だ。そのゲスがプロジェクトの終盤で発覚して大きな手戻りを引き起こすこともある。仕様バグというものの大半は、このゲスによって引き起こされているのではないだろうか。
そもそも資料を作成する目的というのは、必要な情報を過不足なく伝えてゲスを避けることのはずだ。その大切な役割をもった資料にゲスが紛れ込むのはなぜだろうか。
その原因は、レビューが足りないか、レビュアーが不適切かのどちらかだ。それがすべてとは言わないが、かなりのパーセンテージを占めていることは間違いない。だからこのような困ったゲスを排除するためには、適切なタイミングで適切な人のレビューを受けることが必要となる。地道にレビューを繰り返し、フィードバックし、ゲスをなくしていくのだ。
上で紹介した本では、資料作成を「スケルトン」「ドラフト」「フィックス」というフェーズに分けて、それぞれのフェーズでレビューをしっかりやることの大切さを強調している。特にスケルトン段階、つまり資料をどのように組み立てるかを考える段階でのレビューというのは、見当違いな方向に突っ走ってしまうのを早い段階で発見して軌道修正するために非常に有効なものだ。
ゲスからの脱却への第一歩として、まずはこのようにレビューを充実させることを考えてみてはいかがだろうか。