ハッタリ駆動型開発(Bluff-driven Development)
世の中にはびこる「糞みたいな上司」。なんでああいう人罪が作られるのか疑問に思うことがあります。 もしかして、そういう人罪を育成する指南書があったりして、なんて考えて、冗談で作ってみました。
何に対しても簡単にできると言う
知らない分野など関係ない、いや知らない分野だからこそ短絡的に考えます。 「すぐできるでしょ」、「簡単にできるでしょ」を口癖にしましょう。
とにかく曖昧な指示を出す
どうとでも解釈できるような曖昧な言葉で指示を出しましょう。具体的すぎると、その指示が間違っていた場合に責任を負う可能性が高くなります。 何か言われたら、「自分で考えろ!お前の成長のためだ!」とでも言っておきましょう。
背景や目的は伝えない
これも、曖昧な指示と同じです。背景や目的がそもそも間違っていたら、責任を負う可能性が高くなります。 部下が勝手に解釈してやりました。という逃げ道を作っておきましょう。
過度な縦割りにする
部下が結託して反発してきては困ります。縦割りにしましょう。お互いを敵対視させることで、他人事もしくは、切磋琢磨が生まれます。
工数にバッファは用意しない
部下が提示した工数を承認してはだめです。人はだれでも自分に甘いのです。 基本的には、工数にはバッファを計上しますから、2/3程度に削っておきましょう。
「できません」には叱責する
到底不可能な工数で部下に仕事を投げた場合、中には「できません」と反論する部下も出てくると思いますが、 負けては行けません。「できないはないから!」とナポレオンを引用して精神論に持って行きます。当然、論理で話しても勝てるはずがないので 声を荒げて怒鳴りましょう。大抵の部下は萎縮します。
できなかったら叱責する
できない部下には叱責を与えましょう。チーム会議を開催して、メンバの目の前で怒鳴り散らかすのです。 見せしめにすることで、「あぁ、こんな思いは絶対にしたくない」と思わせ、部下の能力を最大限に引き出しましょう。
プログラミングに精通しているとアピールしておく
昔はバリバリのプログラマーだった、とホラを吹いておきましょう。 プログラマーの尊敬を集めることができます。
専門用語を多用する
エンジニアリングスキルがない場合、エンジニアに舐められないように難しい言葉を多用しましょう。 その内容にエンジニアが同意することが目的ではありません。「聞いたこともないような難しい言葉を知っているな」と、尊敬または萎縮させることを目的としています。 よって、エンジニアが空返事をすれば成功です。
自分で言葉を作ってみる
専門用語の多用の発展形として、自分で作った言葉を使うテクニックも存在します。 これなら、部下がその言葉を知るすべもなく「ああ、○○さんって難しい言葉を知っているんだなあ」と尊敬を集めることができます。
元も子もないことを言っておく
分が悪くなった場合、「俺が言ったことは全部正しい訳じゃないんだぞ!」と怒号をあげましょう。 鵜呑みにしたほうが悪いということにして、責任回避をスマートに行いましょう。
品質は最後に確認
品質を行程で作りこんではいけません。工数がかかってしまいます。 最後に正常系のテストしておけば大丈夫です。責任は部下に取らせましょう。
顧客へのメールは部下に出させる
文責回避のためにもメールは部下に提出させます。ただし、部下がメールを作成した場合でも、必ず目を通して修正しましょう。 勝手なことを書いている部下は必ずいます。修正した文章は当然、部下名義で提出させましょう。
反省会はしない
反省をしてはいけません。自分の非を認めることで上司の評価や賞与が減ってしまいます。
反省を求められたら部下のせいにする
上司に反省を求められても絶対に失態を認めてはいけません。大体は「部下の能力不足」で済ませましょう。
たまに飴を与えておく
部下の不満が募ってきた頃に、爆発しないように飴を与えておきましょう。 適当に褒めてあげて、将来の夢などの、個人的な話を聞き流してあげましょう。