暗闇を呪うよりも、ろうそくに火を灯そう

過去24時間で、私の2つ記事、 Why Your Programmer Just Wants To Code（なぜ、あなたのプログラマはコーディングだけをしたがるのか） と A Wake-Up Call For Tech Managers（テックマネージャーへの警鐘） は、Mediumで96,000回以上読まれました。また、 Redditのコメント数も900を超えています 。

思っていたよりも、問題は深刻のようです。

そう、テック企業には悪いマネージャーもいます。そして、私はそうしたマネージャーに辛辣です。プログラマの無関心の責任は、直接的に彼らにあると思っています。

フラストレーションがたまり、何の権利もないと感じながら思考停止に陥っているプログラマを私は助けたい。 上記コメントの 圧倒的 大部分を投稿したのは、これを読んでいるプログラマの皆さんでした。ひどい条件やマネジメントに関して、”もうウンザリ”という具合に。

今日から、これを変えよう

私たちはプログラマとして、こうした状況を諦めてきました。

しかし、何に耐えられて、どのように扱ってもらいたいかをマネージャー（上司）に伝えるべきではないでしょうか。

現実的には、私たちは、たった１人では全てを変えることはできません。ただし、自分が思っている以上に力はあります。

そこで、すぐに実行できて、仕事の環境を大幅に変えられるような方法を以下にご紹介したいと思います。

上司は有能でありたいと考えている、ということを認識する

あなたの上司も、以前はあなたのように開発者だったでしょう。テック企業には、有能な人が無能になるレベルまでは昇進するという ピーターの法則 が当てはまります。

そしてあなたの上司は、上司という役職のトレーニングを恐らくはバリスタほども受けていないかもしれません（ 管理職の76％は、その役職において8時間未満のトレーニングしか受けていない ）。

ゼロの状態から人を管理する方法を知っている人はいないでしょう。 “生まれながらのリーダー”なんて言葉は迷信に過ぎません。

上司たちの多くは、その役職に自分が”適しているか”について不安を感じているはずです。本音を言えば、大部分の人は管理なんかよりも プログラミングを続けたい と思っているかもしれません。

プログラマから管理者への移行は簡単ではありません。そこで、まずは彼らに時間を与えましょう。彼ら自身が変わる必要があります。完ぺきな人なんていませんからね。

私たちが共に、環境を改善できる方法を模索しましょう。

上司自身が悪い環境で働いている（そして、あなたも同じく）

あなたもあなたの上司も、問題のある環境の一部を構成しています。ということは、お互いにそもそも良い環境を作ろうとしていないのかもしれません。つまり、あなたが感じているのと同じ不満を、あなたの上司も感じているということです。

例えば以下について、上司が管理できない環境だとしましょう。

• どのプログラマがどの機能/バグを作業するか
• プログラマの給与
• プログラマの休暇
• 彼らがプログラマにどういった支援を提供できるか
• プログラマの座席位置や使用コンピュータ
• プログラマがいつ、どこでリモート作業できるか
• 使用言語/フレームワーク

通常、これらを決定づけるのは会社や企業文化、そして 環境 です。上記のような状況だと、あなたの上司は大きなフラストレーションを抱えることになります。

人ではなく環境が、あなたの行く手を遮る場合があることを認識する

あなたとあなたの上司は、3つ目に挙げた悪い環境の犠牲者です。 悪いコードと同じように 、悪い環境にも臭いがあります。

悪い環境の臭いについて、以下にいくつか例を挙げてみましょう。

• もし環境がよければもっと職場が改善されるのに、といった声が頻出する
• プロジェクトの価値および成果について好奇心が見られない
• 改善に対して、無力感が漂っている
• ミスをすれば自分たちに叱責が返ってくるという感情がある
• ミス（そして罰）を恐れるあまり、新しいことをやろうとしない
• 変化が必要だという話題ばかりで、アクション自体は少ない
• などなど…

私自身、重苦しい雰囲気の職場で働いてきました。本当に息が詰まって、呼吸さえ困難に感じたくらいです。たまるのはフラストレーションと怒りばかりでした。

リーダーシップは与えられるものではなく、つかむもの

皆さんの周りの人を少し考えてみてください。正式に任命されたわけではない、自然発生的なリーダーと呼べるような人はいますか（管理者は任命されるものですが、リーダーはいつの間にかぽっと現れますよね）？

彼らを注意深く観察してみてください。何が違うのでしょうか？　なぜ彼らはそれをやっていると思いますか？　そしてそれに、他の人はどう反応していますか？

私の初めての職場では、同僚のMilindが他の人とは少し違っていました。後で知ったのは、彼がチームのインフォーマルなリーダーだったということです。

Milindの行動例

• 特定のアプローチが採られた理由について、鍵となる質問を投げかける
• グループとして動く中で彼の無知を認め、上司にコンセプトをより明確に説明するよう依頼する
• 物事を明確にするため積極的に顧客と連絡を取り、要件を交渉する
• ツールについて議論するよりも、本物のソフトウェアを提供することに集中する
• 問題の根本原因を理解することに重きを置く

Milindは、彼の行動によって私たちの職場環境を変え、”ソフトウェア開発”に対する私自身の考え方を変え、そして上司の行動さえも変えました。

彼は私たちに、自分が思っている以上の力が自分たちにあることを教えてくれたのです。必要なのは、餌を待つだけの毎日をやめることです。

真のリーダーシップは与えられるものではなく、つかむものだということ彼は教えてくれました。

時間の経過と共に私の行動は変わり、他の人も同じく変わっていきました。あなたにもできるはずです。

プロセスだけでなく、環境について話をする

最近では、多くのチームがアジャイルプロセスについて議論します。何がうまくいって何がいかなかったのか、それをどう改善できるかなど。もちろん、アジャイルの振り返りはそのためにあります。良いチームは、それについて定期的に話し合い、さらに改善していきます。

最良のチームは、プロセスだけではなく、作業環境についても議論します。

例えば、彼らが議論する環境的な事項は以下のとおりです。

• グループ内で、どのように協力し合うか
• どこまで互いへの信頼を高めるか
• どこまで働きやすい作業環境にするか
• どうすればコミュニケーションを改善できるか
• どうすれば、より簡単に相互サポートし合える環境になるか
• どうすれば、問題のより良い解決者となれるか
• エゴと自己イメージが、グループの働き方にどんな影響をおよぼすか

あなたの環境を題材に議論してみてください。たぶん物事が変わるのを実感できると思います。

なお、これは誰かの承認を得て始める類いのものではありません。また、”ソフトウェア開発環境の改善方法について”といった会議の開催を上司に期待するのもやめましょう。そんな提案を次のチームミーティングでする必要はありません。

大事なのは、とにかく議論を始めることです。

振り返りの中で作業環境の問題を取り上げ、それまでの前提に疑問を投げかける。あなたが話せば話すほど、他の人も巻き込まれていくはずです。

上司との1対1のミーティングを予定する

定期的に上司と1対1で話し合うような機会がない場合は、そのような機会が持てるよう上司に相談してみてください。この話し合いについて、上司が主導権を握る必要はありません。多くの人は上司にミーティングを提案するのをためらいがちですが、私の経験では、むしろ上司は喜んでくれます。

一般的に上司は1対1の話し合いに価値があると思っているはずです。逆に彼らは、部下たちはそう思っていないと考えている節があります。あなたが上司に相談すれば、きっとうまくいくでしょう。

ミーティングが決まったら、事前に簡単なアジェンダを送って準備してください（何を話せばいいか分からない場合、 One-on-One Framework（1対1ミーティング用フレームワーク） を参考にしてみてください）。

アジェンダ例

• 今後のプロジェクトについて議論する
• 上司からのフィードバックを受ける
• 現在のプロジェクトに関して報告する
• 上司にフィードバックを提供する

1対1のミーティングでは、あなたが自分自身と環境を変えようと努力していることを上司に伝えるようにしましょう。より効率的な開発者になり、より効果的なチーム環境を作ろうと考えていること、また優れた開発者にとってスキルが全てではなく、リーダーシップのスキルも磨こうとしていることなどを伝えるといいと思います。

上司たちは、そのことで身構えたりすることはないはずです。あなたは自分の仕事をより良くしていこうと言っているだけで、彼らの仕事を奪うと言っているわけではありませんからね。

上司というものは、自立的なプログラマや自己管理ができるチームを求めています。それがアジャイルですよね？　あなたの努力によって上司は、はるかに働きやすくなるでしょう。

ぜひ試してみて、結果を教えてください。

連絡をいただく場合は、コメントに記入していただくか marcus@marcusblankenship.com までお願いします。