ハッタリ駆動型開発（Bluff-driven Development）

世の中にはびこる「糞みたいな上司」。なんでああいう人罪が作られるのか疑問に思うことがあります。 もしかして、そういう人罪を育成する指南書があったりして、なんて考えて、冗談で作ってみました。

---

何に対しても簡単にできると言う

知らない分野など関係ない、いや知らない分野だからこそ短絡的に考えます。 「すぐできるでしょ」、「簡単にできるでしょ」を口癖にしましょう。

とにかく曖昧な指示を出す

どうとでも解釈できるような曖昧な言葉で指示を出しましょう。具体的すぎると、その指示が間違っていた場合に責任を負う可能性が高くなります。 何か言われたら、「自分で考えろ！お前の成長のためだ！」とでも言っておきましょう。

背景や目的は伝えない

これも、曖昧な指示と同じです。背景や目的がそもそも間違っていたら、責任を負う可能性が高くなります。 部下が勝手に解釈してやりました。という逃げ道を作っておきましょう。

過度な縦割りにする

部下が結託して反発してきては困ります。縦割りにしましょう。お互いを敵対視させることで、他人事もしくは、切磋琢磨が生まれます。

工数にバッファは用意しない

部下が提示した工数を承認してはだめです。人はだれでも自分に甘いのです。 基本的には、工数にはバッファを計上しますから、2/3程度に削っておきましょう。

「できません」には叱責する

到底不可能な工数で部下に仕事を投げた場合、中には「できません」と反論する部下も出てくると思いますが、 負けては行けません。「できないはないから！」とナポレオンを引用して精神論に持って行きます。当然、論理で話しても勝てるはずがないので 声を荒げて怒鳴りましょう。大抵の部下は萎縮します。

できなかったら叱責する

できない部下には叱責を与えましょう。チーム会議を開催して、メンバの目の前で怒鳴り散らかすのです。 見せしめにすることで、「あぁ、こんな思いは絶対にしたくない」と思わせ、部下の能力を最大限に引き出しましょう。

プログラミングに精通しているとアピールしておく

昔はバリバリのプログラマーだった、とホラを吹いておきましょう。 プログラマーの尊敬を集めることができます。

専門用語を多用する

エンジニアリングスキルがない場合、エンジニアに舐められないように難しい言葉を多用しましょう。 その内容にエンジニアが同意することが目的ではありません。「聞いたこともないような難しい言葉を知っているな」と、尊敬または萎縮させることを目的としています。 よって、エンジニアが空返事をすれば成功です。

自分で言葉を作ってみる

専門用語の多用の発展形として、自分で作った言葉を使うテクニックも存在します。 これなら、部下がその言葉を知るすべもなく「ああ、○○さんって難しい言葉を知っているんだなあ」と尊敬を集めることができます。

元も子もないことを言っておく

分が悪くなった場合、「俺が言ったことは全部正しい訳じゃないんだぞ！」と怒号をあげましょう。 鵜呑みにしたほうが悪いということにして、責任回避をスマートに行いましょう。

品質は最後に確認

品質を行程で作りこんではいけません。工数がかかってしまいます。 最後に正常系のテストしておけば大丈夫です。責任は部下に取らせましょう。

顧客へのメールは部下に出させる

文責回避のためにもメールは部下に提出させます。ただし、部下がメールを作成した場合でも、必ず目を通して修正しましょう。 勝手なことを書いている部下は必ずいます。修正した文章は当然、部下名義で提出させましょう。

反省会はしない

反省をしてはいけません。自分の非を認めることで上司の評価や賞与が減ってしまいます。

反省を求められたら部下のせいにする

上司に反省を求められても絶対に失態を認めてはいけません。大体は「部下の能力不足」で済ませましょう。

たまに飴を与えておく

部下の不満が募ってきた頃に、爆発しないように飴を与えておきましょう。 適当に褒めてあげて、将来の夢などの、個人的な話を聞き流してあげましょう。