2014年11月26日
デベロッパからマネージャへの転向
(2014-04-15)by Stephen Haunts
本記事は、原著者の許諾のもとに翻訳・掲載しております。
デベロッパなら誰しも、自分の将来を決断すべき時が来ます。このままデベロッパ、またはシニアデベロッパのキャリアに留まってコードに専念するか、チームの管理を担うリードデベロッパや開発マネージャといった管理職の世界に飛び込むかの選択です。
ディルバート:プログラマからスーパーバイザへ
私自身も2011年に同じような決断をしました。ある大手インターネット銀行のシニアデベロッパだった私は、直属の部下はいなかったものの、数人をメンタリングしていました。当時私は、大学生に職場を世話して1年間のトレーニングを提供するアカデミーのプログラムに携わっていました。最初はメンターを担っていたのですが、最終的には、通常のシニアデベロッパの職と並行しつつ、そのアカデミーの管理を任されるようになりました。厳密な意味で、私が複数の人たちを直接管理したのは、この時が初めてで、私はその仕事を心から楽しみました。その後、私は消費者金融会社のリードデベロッパという現在のキャリアに移行しました(この記事を執筆している現在から2週間後には新たな職に就きます)。今の職務にも多少のコーディングは含まれますが(以前とは比較にならない程度です)、私の主な仕事は、専門が多岐にわたるソフトウェア開発チームを指導することです。
先に述べた経験は私にとって非常に有意義なものでしたし、私はコーディングと同じくらいリーダーとしての役割が気に入っています。しかし、誰にでも同じことが言えるわけではありません。新しい組織で開発マネージャとして歩み始めようとするこの機会に、私は自分の経験を踏まえ、デベロッパからマネージャへの転向について書くことを思い立ちました。この記事がキャリアの分かれ道に立っている人たちの助けになれば幸いです。
適性を見極めよう
チーム管理の仕事は誰にでも向いているわけではありません。キャリアの転換は厳しいものになる可能性があります。ですから、リーダー職については慎重に考えるべきです。自分がその世界に飛び込みたいと思う理由をよく検証しましょう。もし給与アップだけが目的だとしたら、先に言っておきますが、残念な結果になるでしょう。確かに給与は上がるでしょうが、それでどれくらいの期間やる気を持続できるでしょうか。そう長くはもたないはずです。
キャリアの選択:デベロッパからマネージャへ
リーダーを目指す理由は、チームメンバーの能力を伸ばし、仕事の成果を上げる強いチーム作りをサポートしたいという動機に基づくべきです。結局のところ、チームを指揮する意義は、成果を出すことにあります。もし結果を出せなかったら、どんなにチームの能力が優れ、ソフトウェアの開発に長けていても、リーダーとしては失格です。リーダーの仕事は、あらゆる最新のテクニックとプロセスを駆使して、技術的に優れたバランスのよいチームを作り上げることです。マネージャになれば、デベロッパの頃とは相反するような決断を下さなければならない局面もあるでしょう。マネージャは、違った視点で物事を捉える必要があるからです。
メンターやコーチを確保しよう
マネージャになりたての頃は、サポートが必要です。傲慢なプライドは捨て置いて、メンターを見つけましょう。メンターは自分の上司でもいいですし、社内の他の誰かでも構いません。かしこまる必要はないので、週に一度コーヒーでも飲みながら、1時間ほど自分の仕事の状況について話し、アドバイスを請いましょう。すぐに何かを決断する必要があって、他の人の意見を参考にしたい場合もあるはずです。私の前職でのメンターは開発マネージャ兼、私の上司でしたが、彼は定期的に私の話を聞き、アドバイスをくれました。
メンターとコーチ
私がメンターのアドバイスを必要とした例を1つ挙げるなら、あるデベロッパに成績不振者向けの業績管理計画を実施し、正式な懲戒手続きを開始しなくてはならなかった時です。最終的にデベロッパを解雇に追い込むかもしれない決断を迫られたのは、その時が初めてでした。メンターのアドバイスなしでは決して対応できなかったと思います。
リーダーシップトレーニングを受けよう
マネージャやスーパーバイザを務めるなら、受けられるトレーニングは全て受けましょう。ほとんどの大手企業では社内でトレーニングコースを提供していますが、もしそのようなコースがない場合は、外部のコースを検討してください。私は、これまでデベロッパ向けのクラス制のトレーニングを有意義だと感じたことはありません。それはデベロッパにとって最適な学習法だとは言えないでしょう。しかし、リーダーシップやソフトスキルのトレーニングなら、クラス制は大変価値があります。というのも、リーダーシップとは人と関わることに他ならないからです。メンタリングやコーチング、対立事項の解決、クリティカル・シンキング、タイムマネジメント、評価、目標設定などのコースの受講をお勧めします。運がよければ、正式なリーダーシップトレーニング・プログラムに参加して、360度評価やフィードバックを受けることもできるでしょう。また、今紹介したようなトレーニングに関連する書籍を読むのもお勧めです。
チームメンバーをよく理解しよう
マネージャの頼みの綱はチームメンバーですから、マネージャは社交的でなければなりません。チームメンバーの失敗は、リーダーの失敗です。チームを成功に導く唯一の方法は、メンバーをよく知ることです。メンバーたちはどんなキャリア目標を持っているのか? メンバーには現在どれくらいの能力があるのか? また、能力の格差はどれくらいか? チームメンバーを定期的に1対1で面談し、彼らの仕事の状況や抱えている問題、メンバーに対する自分の期待、そしてメンバーがリーダーに期待すべきことなどについて話し合う機会を持ちましょう。チームメンバーを深く知れば知るほど、効果的なサポートができます。
マネージャにとって社交的であることは重要です。もし、部屋の隅で1人静かにコードを書くのが好きなタイプのプログラマなら、リーダーの役割はそれほど楽しめないでしょう。
十人十色のチームメンバーに接するには、それぞれの人や状況に応じて、 全般的および個別のリーダーシップスタイル をうまく使い分ける必要があります。
メンバーを解雇する覚悟を持とう
マネージャという仕事は、時に痛みを伴います。チームのメンバーが与えられた役割を果たさず、他のメンバーの足を引っ張るということもあるかもしれません。そんな時、最初にしなくてはならないのは、なぜその問題が起きたのかを探ることです。結果、そのメンバーが能力的に不可能な役割を与えられ助けを必要としているのだとしたら、それに対処すれば問題は解決します。しかし、そのメンバーが単に仕事を放棄していて、マネージャの努力によってもその状況の改善が見込めないという場合には、解雇という厳しい判断が求められる場合もあります。そのメンバーが組織にとって重大な不正を働いているなら、判断はさほど難しくはありません。即刻、懲戒解雇を通告すればよいのです。しかし、そのメンバーの行いが個人の態度の問題である場合は、会社が定める解雇手続きをきちんと踏んでいく必要があります。これは関係者全員にとって手間も時間もかかる手続きである上、当然ながら楽しいものではありません。しかし、これもマネージャの職務なのです。とはいえ一人で行う必要はありません。こんな時こそメンターに相談するべきですし、また人事部にも進捗を報告しながら、手続きが正しく行われているか確認するようにしましょう。
あなたはクビです!
私自身も過去に忠告されたことなのですが、マネージャはいつでも、メンバーを解雇する覚悟を持っている必要があります。もしあなたが採用も担当するマネージャである場合、自身の友人や知人を採用したいと考えることがあるかもしれません。彼らがその役割に対する適性を持った人物なら、そういった採用もありでしょう。しかし何か問題が起きてしまい、その人物に懲戒を加えたり、あるいは解雇したりしなければならない状況に陥ったら、あなたはどうしますか? 長年の友人、長年の同僚を相手に、そのような判断を下せますか? もしその覚悟がないのなら、友人、知人の採用は避けるべきです。
きちんと機能するチームを作るには、メンバーひとりひとりの個性のバランスを取ることも大事です。人間性に問題のあるメンバーや仲間の足を引っ張るようなメンバーがいるなら、対応が必要です。解雇は最終手段であるべきですが、不平不満が絶えず声高に文句を言うようなメンバーは、やがて他のメンバーの態度にも影響を及ぼすようになります。最終的にはチーム全体が機能しなくなり、マネージャは多大な問題を抱えることになるでしょう。
賢くタイムマネジメントをしよう
マネージャは、あらゆる方面へ引っ張りだこになるものです。チームの動きやメンバーの成長具合を注意深く観察するとともに、ステークホルダーマネジメントやその他の事柄にも気を配っていなければなりません。スケジュール帳は常に埋まっている状態でしょう。だからこそ、出席すべきミーティングを見極めるなどの賢いタイムマネジメントを行うことが大切なのです。予定されている全てのミーティングに出席する必要は、きっとないはずです。自分の出席が不可欠なのか、誰か他の人を代わりに出席させることはできないか、そういったこともよく考えてみるべきでしょう。
テクニカルスキルを常に最新の状態にしておこう
管理職に就くと、ポジションによってはコーディングを行う頻度が以前と比べて少なくなることもあるでしょう。私がリードデベロッパとして大きなチームをまとめていた時は、メインのプロジェクトのコーディングは行いませんでした。私には他にも負っている責任があり、自分がプロジェクトのボトルネックになってしまうようなことは避けたかったからです。管理職に就いたらコーディングを一切やめるべきだと言っているのではありません。自分でテクニカルスキルを常に最新の状態にしておくべきだということです。私は何通りかの方法で、それを実践していました。例えば、チームの通常のプロジェクトとは別に、納期を設けずにいくつかの作業に取り組んでいました。それはログ監視ツールの開発やPCI DSSにおけるトークナイゼーションの研究などです。また、コーディングが好きなので、いくつかの個人的なプロジェクトにも着手しました。
学び続けよう
コーディングスキルをさび付かせないために、私は SafePad と Text Shredder というオープンソースツールを開発しました。最近では、他の誰かのためではなく自分のためにコードを書くことが多く、以前とは異なる視点からコーディングの楽しさを再認識できています。また、多くの本を読むべきだと思っています。私は片道1時間の通勤時間を利用して、電車の中で読書をしています。Safari Books Onlineの購読は本当にお勧めです。これを購読していれば、技術書やリーダーシップに関する本が読み放題になりますからね。
チームの力になろう
前にも書きましたが、チームメンバーが仕事で成果を出せるように、メンバーの力になり成長の手助けをする必要があります。つまり、いわゆる”Shit Umbrella(雑音から守る傘)”になるのです。私自身、上位の管理者からチームを守るために多くの時間を使いがちです。チームを必死になって守ることは必ずしも悪いことではありませんが、真の目的は、作業を止めてしまうような不必要な情報によって、チームが行き詰まらないようにすることです。ただし、そのような情報をチームに隠せと言っているわけではありません。それどころか透明性も重要だと考えています。しかし、時にはチームメンバーが巻き込まれる必要のない事柄も存在するので、傘の例えを使ったのです。マネージャが傘の役割を担っていることを必ずしもチームメンバーが知る必要はありません。うまくやれば、彼らはそのことに気づきもしないでしょう。しかし、傘の役割は非常に大切です。
また、チームに割り当てられる仕事は、まずマネージャのところに来ます。そのため、メンバーが今現在どんな仕事に取り組んでいるのか、そしてどのくらいの余力があるのかを知っておく必要があります。可能な限り、能力以上の稼働をチームに課すのは避けましょう。燃え尽きてしまうかもしれません。そうなってしまうと非生産的です。もちろん、ビジネス上、負荷をかけざるを得ない時もあります。私の経験から言うと、例えば、チームがやらなければならなかったコンプライアンスの仕事がその例に当たるでしょう。完全に能力以上の負荷がかかっていましたが、やらなかった時のペナルティが非常に厳しいものだったので、やらざるを得ませんでした。
気持ちを切り替えよう
ソフトウェア開発からマネジメント側に行くかどうかを決める時に、最も難しいのは気持ちを切り替えることです。つまり、1日中コードを書いているポジションからコードを全く書かないポジションに移れますかという質問です。答えがノーなら、がっかりすることになるのでマネージャになるのはやめましょう。答えがイエスなら、やってみればいいのです。ただし、即決はやめてください。考える時間を取りましょう。
コードを書かないポジションが苦にならないからといって、キャリアを簡単に転換できるというわけではありません。私も前職から離れるのは非常に難しいことでした。時間がかかります。言うなれば、お酒やドラッグを断つようなものです。マネージャの立場になったら、発生するあらゆる技術的な問題に対して、チームを手助けしたいという衝動を抑えなければなりません。どんな時でも手出しをしないというわけではなく、過干渉は避けるべきだという意味で言っています。デベロッパは技術的な問題を解決するために雇われた人たちです。マネージャがいつも手出しをしてしまったら、口うるさい上司という印象を与えてしまうでしょう。そうはなりたくありませんよね。
準備はいいですか?
この記事が、ソフトウェア開発からマネジメント側に転換するかどうかを決める時期にいる人たちの参考になることを願っています。私からのアドバイスは、実際にキャリアを転換する前によく考えるということです。マネージャになる決断をし、その仕事をうまくやれるとしましょう。その場合、チームの成果が出た時には大きなやりがいを感じます。しかしストレスの溜まる仕事でもあり、最終的にはチームに対しての責任を負わなければなりません。チームが失敗すれば、それは自分の失敗であり、その責任を取るのも自分なのです。
もしデベロッパからマネージャへの転換を経験した方がいましたら、ご自分の経験を以下のコメント欄から私に教えてください。もし今まさにキャリアの転換を考えていて、既にそのプロセスを終えた誰かと話したいと思う方がいましたら、コメント欄か このブログのトップページにあるコンタクトフォーム からご連絡ください。
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
- Twitter: @yosuke_furukawa
- Github: yosuke-furukawa