気づきを得た開発、得ない開発(リーダ編)

■リーダとは責任ある仕事
小さなプロジェクトのリーダであっても、課長部長のような役職であっても、あるいは経営に関わるような役員であっても、誰かを引っ張らなければならない人はみんなリーダです。
それぞれ立場も違えば仕事も違いますが、共通する事は、リーダには「責任」が伴うという事です。
人を導くからには、その人達が目的地につけるようにするための責任があるのです。
ですが、その「責任」とは一体なんなのでしょうか。

■リーダのすべき事
リーダは、その立場に自然になるわけではありません。
その人自身の努力はもちろん、周りの評価があり、リーダに任命する権限のある人がよしとした時、初めてその人はリーダになります。
リーダになると「権限」が与えられ、役職により大小はありますが、自分の意思を反映できる権利が与えられます。
その権限の大きさと比例し、関わるプロジェクトも大きくなっていきます。
大きなプロジェクトであればあるほど、関わる人の数や金額が大きくなりますし、時には付き合いのある会社への影響など、多くの事を考えなければいけなくなります。
また自分の意思が反映できるということは、あるいは誰かの意思に反したことをさせてしまう可能性があるわけですから、それをどのようにフォローしていくかも大切です。
例えば政治的な理由で納期/金額/仕様を変更したりすると、不満は高まる一方です。
そういった時には「いいからやりなさい」「出来るよう工夫しなさい」と頭ごなしに言うのではなく、ちゃんと事情を説明し、正しく評価してあげる事が重要です。
そしてプロジェクトの進捗を随時把握・理解する事も当然ですし、自分が社長でもない限りは上司に報告する必要があるでしょう。
上司からは、自分が納得いかない叱責をされるかもしれませんし、賛美の言葉を頂けるかもしれません。
その結果をモチベーションが上がるようにメンバにフィードバックし、また次につなげていく、それがリーダの仕事です。
当然これ以外にもメンタルケア的なことも必要でしょうし、プライベートでも相談にのることがあるでしょう。
これだけの事をしなければならないからこそ、リーダというものに対して権限が与えられますし、しかるべき対価があるのです。

■ありがちな迷い道
ですが、必ずしもそうはいかないのがIT業界のお約束です。
多くの方が経験されていると思いますが、上司から明らかにメリットがない仕事の進め方をゴリ押しされた経験があるでしょう。
私も幾つか経験がありますので、例をあげてみましょう。
何かプロジェクトでミスをしてしまった場、振り返りを行い改善策を考える「ミスゼロ運動」という物があります
本来であれば、プロジェクト実施中に気づいた効率改善や、ミスから学んだ問題のある作業フロー見直しを行う作業です。
しかし、悪意もなく、技術的にも回避ができないような本当の「うっかりミス」に対して「なぜそのようなミスをしてしまったのか」「その解決方法」などを追求が始まってしまう事があります。
そうなると、そのミスに対するチェックシートを作成し、上司への報告・承認を義務付ける、そんな作業を新たに作り出してしまう事になります。
チェックシートを作成したとしても、今度はそのチェックに同じようなうっかりミスが発生してしまうかもしれません。
しかも毎回チェックを行わなければならなくなりますから、工数は膨れますし、上司が捕まらない事もあるでしょう。
更にいえば、上司が確認したところで本質的には何も改善できないため、むしろ次の問題を発生させるという悪循環が誕生します。
生産性は皆無で、その瞬間は「このような対策をしました」と言い逃れする材料になりますが、継続して行うには無駄もよいところですね。

他にも、上司に対して過剰な説明を求められる事もよくあります。
上司がそのまた上司に説明するための資料を作成したところ「(さらにその上司である)役員の方はこれじゃ資料が読めない」という理由で修正を命じられ、時間がないからという理由で項目を削減、挙句の果てには作った資料を見た役員から「これ、つまりはどういうこと?」という質問で返されるという始末です。
だったら最初から口頭で良くない? と思った事もしばしばです。

これらは全て「何か対応しなければ」という強迫観念の解消や「何かしら対応しました」という既成事実作成のために行う「儀式」です。
「より良い物を作るため」の権限が「自分の責任を回避するため」にすり替わったわけですね。
そしてこれらの最も性質が悪いのが「自分は正しい」と思ってやっている事にあるのです。
「なんで部下はこれくらいの事がわからないのか」「俺はこうやってきたのに」「感覚だけで物をいうな」そんな感情が沸き起こってきてしまうのです。
しかもそれが誤りである事を指摘されると、自分の過去が否定されたような気持ちになってしまい、どうしても受け入れることができなくなるというおまけ付きです。
この負の循環から抜け出すには、自分で気づくしかないのです。
ですから、例えば「何でお前は○○が出来ないんだ!」と部下を叱責するときは「何で○○が出来るように教えられないんだ!」と自分を叱責してみてください。
「あの時の自分は○○が出来なかった」と過去の自分を振りかってみるのもいいでしょう。
まずは自分を知ることが全てのスタートだと認識してください。

■「責任」と「権限」は切り離すな
さて、本題に戻ります。
このような問題が発生するのはなぜなのでしょう。
それは「責任」と「権限」が一対であること、そして何に対して「責任」をとるのかを忘れてしまう事にあります。

リーダに与えられた権限は、それを行使し、何かしらの利益を生み出すために与えられるものであり、役職に対し無条件に与えられる物ではありません。
そして利益とは、一つ一つの案件ごとに結果を見るような短期的なものであってはいけませんし、金銭的な利益ばかり見てもいけません。
人の成長も大きな利益ですから、金銭的な部分のみ評価をしてしまったり、短期的な評価をしてしまっては、マイナス評価を恐れ何もできなくなってしまいます。
5年10年先をみて、最終的にプラスとなるかどうかが大切です。
案件が赤字となるような場合でも、それがきっかけで新しい技術を身につける事ができたかもしれませんし、次の案件獲得に繋がるかもしれません。
そういった判断ができ、そのために為すべきことを為すその時、初めて「権限」が意味を持つのです。

そして責任とは、関連する全ての事柄に対してとらなくてはいけません。
後輩の育成、会社の利益、協力会社との結束強化など、それら全てを意識し、実践しなければならないのです。
そのために、自身が考え、あるときは情報のハブとなり、上司として指導し、またある時は部下から学ぶ、そんな姿勢が必要です。
利益が出なかったから上司に叱責される、そんな些末な自分への評価に対して「責任」を感じてはいけません。

人を育て、組織を守り、利益も出す。
時には叱責し、時には褒めて、反抗される事もあれば、尊敬もされる。
こんな状況、身近にありますよね。
そう、つまりリーダは「家族を支える父親」でなくてはならないのです。

時々は「自分のような人間を上司/同僚/部下としてもった場合、どのような評価を下すか」という第三者視点を持ち、改善を心がけてみてください。
ひょっとしたら「うわっ…私の評価、低すぎ…?」なんて事もあるかもしれませんよ。

プロフィール
平野 裕介(ひらの ゆうすけ)

Web開発が本職でしたが、今はAndroidの企画関連が仕事に。また、日本Androidの会という、Androidの開発者を中心としたコミュニティにも参画しています。基本的にモチベーションドリブンで開発をします。モチベーションは品質にも直結するという考えから、したくない事はできるだけしない、というスタンスで仕事をしています。そんな私でもなんとかなっている、という指標になれればと思っています。




この記事のタグ:


関連する記事

プロフィール
平野 裕介(ひらの ゆうすけ)

Web開発が本職でしたが、今はAndroidの企画関連が仕事に。また、日本Androidの会という、Androidの開発者を中心としたコミュニティにも参画しています。基本的にモチベーションドリブンで開発をします。モチベーションは品質にも直結するという考えから、したくない事はできるだけしない、というスタンスで仕事をしています。そんな私でもなんとかなっている、という指標になれればと思っています。