初めて部下になる新人ITエンジニアのためのマネジメントのされ方
この記事は何？
学生バイトやインターン生、1年目の社会人など、初めて上司にマネジメントされる立場になったITエンジニア向けに、マネジメントされる上での心得をまとめました。
ITエンジニアらしく、組織における「知識の所在」「責任」「不確実性」をキーワードに、「誰が何を知っているのか」「誰が何に責任を負うべきか」という観点で、マネージャーと部下の役割の違いを整理しています。
前回の記事↓
なぜ「マネジメントのされ方」が必要なのか？
マネージャーは、簡単に言えば、あなたの努力が、あなた個人にとっても組織全体にとっても嬉しい結果につながるようにする役割を担っています。あなたが車のエンジンだとするならば、マネージャーはその車のハンドルのような存在です。
一方で、あなたがマネージャーに対して正しい情報提供を行わなかった場合、マネージャーはハンドルを切り間違えることがあります。場合によっては、あなたのチームは、正しくない情報を与えられたマネージャーと共に、誰も幸せにならない方向へと全速力で突き進んでいくことになります。実際、目標設定が間違っていていくら努力しても絶対に良い結果につながらないプロジェクトに遭遇することは、ITエンジニアとして仕事をしていればさして珍しいことではありません。
マネージャーが正しくハンドルを操作し、皆が望むゴールへ向かうためには、「管理される側」からも適切な情報を提供していくことが不可欠です。"不幸な結末"を避けるためにも、適切な「マネジメントのされ方」を身につけましょう！
1. 「順調かどうか」を常に可視化せよ
PMに話しかけてもいいタイミング pic.twitter.com/iSvyTNnxqW
— のなと@もちねこ (@Nonato_Note) April 20, 2022
原則
状況の変化に合わせて、"計画"を見直すのが上司の責任
"計画"の見直しのために必要な情報(進捗状況、残りの作業の見積もり、今起きているトラブルの報告)を提供するのが部下の責任
解説
現場はいつもトラブルに見舞われています。想定外のバグ、主力メンバーの急病、仕様の検討漏れ、などなど。マネージャーは、さまざまな不確実性と闘いながら、チーム内のリソース（予算やメンバーの工数）を何に配分するかを決定し、チームに与えられた目標の達成に結果責任を持つ役割です。
それゆえ、マネージャーは何かトラブルが起きた時は、できるだけ早く情報を知りたいと思っています。早く分かっていれば、人を増やしたり、お客さんと交渉してタスクの優先度を付け直したり、手が打てるからです。
しばしば、新人エンジニアは周囲の期待に応えようとして、本来よりも短い見積もり期間を述べたり、できないことを「できます！」と約束してしまったりします（本当は誰もそんなことをあなたに期待していないのですが！）
しかし、これはマネージャーの"計画"を破綻させます。あなたが正しい報告をマネージャーに上げないのであれば、マネージャはあなたの仕事の進捗を管理する意欲を失い、「期間内に仕事を間に合わせる責任」をすべてあなたに押しつけるでしょう。"計画"を見直すために必要な情報が、全てあなたの元でせき止められているのですから。そして、締め切り間際になってから、元の"計画"通りにあなたの仕事が進んでいないことが発覚すれば、マネージャーにできることはもうあなたを激しく叱責することだけです。ですから、これは絶対にやってはいけない「マネジメントのされ方」です。逆に、計画の見直しに必要な情報をマネージャーに与え続ければ、マネージャーはあなたが現実的に実行可能な計画を引き直し、あなたをデスマーチから守ってくれるはずです。
自力で解決できない可能性があるトラブルが起きた時は、すぐにアラートを挙げましょう。この時点では自力で解決できる可能性が残っているとしても、早めにアラートを挙げるべきです。この点について述べた筆者の別の記事を紹介しておきます。
期限内に終わらない可能性があるならば、マネージャーにアラートを挙げましょう。「どうやって対処するか」は最悪考えなくても構いません。それはマネージャーが考えることです。
ここであなたに求められているのは、"コミットメント"、すなわち、いつまでに終わらせるというアツい意志表明ではありません。あなたがやることは、"見積り"、すなわち、締め切りまでに終わらない可能性が何%くらいあるのかという冷静かつ客観的な分析です。"見積り"と"コミットメント"はよく混同されますが、区別すべきです。また、この点もよく勘違いされますが、見積りとは確率（確率分布）で表されるべきものです。プログラミングタスクにはさまざまな不確実性があります。あなたは、不確実なことは不確実であると正直に報告しなければいけません。例えば、デザインが上がってきていない段階で、HTMLのコーディング時間を正しく見積もることは不可能です。プログラミングタスクには「やってみないと分からない」ことがたくさんあります。「この見積もりがどの程度不確実な見積もりなのか」「あとどんな情報があれば、間に合う/間に合わないを正確に判断できるか」を正しく報告することが大事です。
書籍「ソフトウェア見積り 人月の暗黙知を解き明かす」の第1章をさらっと読むだけでも、"見積り", "計画", "コミットメント"の区別を理解できます。マネージャーは"計画"に責任を持ちますが、作業者は"見積り"に責任を持ちます。ほとんどの場合、残りの作業の"見積り"に必要な情報を全て持っているのは作業者だけです。この責任分担を理解してください。
とにかく大事なのは、「順調かそうでないか」がマネージャーから常に見える状態にすることです。理想を言えば、あなたの頭がパトランプになっていて、順調ならば青信号、リスクがあれば黄色信号、問題が起きたら赤信号になれば楽なのですが！ 現実にはそうではないので、定期的に言葉で伝えることが必要です。例えば、週報などで定期的に「今週やったこと」「来週やる予定のこと」を伝えると良いでしょう。マネージャーはそれを見れば順調かそうでないかを判断してくれるはずです。
2. あなたのwill（やりたいこと）を言語化せよ
原則
部下のwillに合わせて、必要な経験やリソースを用意するのは上司の責任
自分が何を望んでいるのかを言語化し、上司に伝えるのは部下の責任
解説
マネージャーの最も基本的な仕事の一つは、部下のwill（意志、やりたいこと）と組織のニーズをすり合わせること。そして、すり合わせた結果を部下の目標やタスクとして落とし込むことです。優れたマネージャーであれば、常に部下のwillに対してアンテナを張っており、部下のwillと組織のニーズが噛み合う場所を常に探しています。
マネージャーは、メンバーの将来に責任を持ち、メンバーが成長する上で必要な経験やリソースを用意する役割を担っています。しかし、この役割をちゃんと果たすには、「一人一人のメンバーは、仕事を通じて何を求めているのか？」という知識が必要になります。
あなたにとって「価値のあること」はなんでしょう？ 人と話しているのが好き、コードをリファクタしてる瞬間が楽しい、仕事は大変でもいいからお金をいっぱい稼ぎたい、最新技術を追いかけたい、など様々でしょう。
マネージャーにとって、それぞれの部下がどんな「成長」を望んでいるのかは、なかなか見えにくいものです。昨今の情勢だと、口では「ITエンジニアになりたい」と言っている人であっても、実際に何を望んでいるのか、どの程度の意欲なのかは判断が難しく、マネージャー側も「この人にどの程度投資していいのか？」と悩んでしまうのが実情でしょう。あなたの望みが不確実な状態では、マネージャー側も思い切った応援はできないのです。
組織のニーズは何か、このチームにはどんなタスクがあるのか、といったことはマネージャーの知識範囲ですが、「あなたが何を望んでいるのか？」だけは、マネージャーには知ることができません。あなたの望みは、あなたが言語化する必要があるのです。もちろん、良いマネージャーは、言語化をサポートしてくれますが、あくまでサポートできるだけです。
マネージャーは、望みが不明確な部下よりも、望みを明確に意志表明している部下に成長の機会を渡すことを好みます。例えば、「インフラエンジニアになりたい」と意志表明している部下がいるならば、その部下にインフラ系のタスクを優先して渡すでしょう。これは「早く年収600万もらえるようになりたいです！」というような望みであっても同様です。マネージャーは、どんなスキルを身につければ昇進でき、年収が上がるかについてアドバイスを与えますし、その意欲が（その道の困難さに負けない程度には）本物だと判断できれば、より難しいタスクをどんどん渡します。
あなたの望みを明確化すること。それをあなたのマネージャーに伝えることは、望みを叶える上で非常に影響力のある一手であると覚えておいてください。「求めよ、されば与えられん」というわけです。
3. 作業する前に、アウトプットのイメージを擦り合わせよ
原則
タスクや目標を部下に伝えるのは上司の責任
伝達を"サポートする責任"は部下側にもある
解説
システムエンジニアリングとは、何か特定のコンセプトや目的を与えられ、具体的なコードやシステムに落とし込んでいく作業だと言えます（図↓）。上司は、大まかな方針を決め、作業をあなたに依頼します。あなたは指示を元に、具体的なコードに落とし込んでいくのです。
エンジニア組織にとって「伝達の不確実性」は永遠の課題です。本来、組織の上から下へと指示が伝わるにつれて、不確実性は減っていくべきです。しかし、実際には、上司から部下に伝達される時、大なり小なりコミュニケーションの齟齬が起き、新たな不確実性が発生します。この不確実性はタスクの抜け漏れや仕様漏れとなって、スケジュールを逼迫させます。
上司からタスクの伝達を受けている時、あなたと上司は「伝達の不確実性」という共通の敵と戦っていることを理解してください。あなたと上司は、手を取り合い、ITエンジニアを長年苦しめてきたこの強大な敵に挑むのです。
「あなたが依頼内容を理解できたかどうか」は、あなた以外には判断できない、という点を肝に命じてください。わかっていないのに「わかった」と言ってはいけません。仮にアウトプットイメージがズレていた場合、あなたはそれを作るためにかけた膨大な時間を無駄にすることになります。
認識ズレを防ぐためには、お互いに目に見える形にするのが有効です。依頼内容をもういちど自分で言語化し、上司に再説明するなどして、お互いに理解が一致しているかどうかを確認するといいでしょう。その場でアウトプットの一部を簡単に作ってみるのも有効です。コードをその場で数行書いてみたり、ホワイトボードに完成図のスケッチを描くのもいいでしょう。追加の依頼や修正などが多く、どこまでやったのかわからなくなる場合は、お互いの目に見えるところにチェックボックス付きの箇条書きにして管理するのもオススメです。
4.チームの改善のため、意見を述べよ
原則
チームの課題解決のために、リソース（メンバーの工数・お金）の投下を意志決定をするのは上司の責任
自分しか知らないチームの課題や事実を書き留めたり、現場の視点から提案を出したりするのは部下の責任
解説
まだ新人のうちから、組織の課題を指摘したり、改善の提案をすることは、おこがましく思えることでしょう。実際、メンバーがパフォーマンスを発揮できるように環境を整えることは、部下ではなく、マネージャーの責任であるべきです。マネージャーは、リソース（メンバーの工数を含む）の使い方を意思決定する権限を持つ代わりに、結果責任を持ちます。一方、部下は結果責任を持たない代わりに、リソース配分について意志決定の権限も持ちません。あなたは、どれだけ組織に課題を感じていたとしても、その解決のための意思決定の権限を持たないのです（「会社が潰れても責任が取れるぜ！」というなら別ですが。）
とはいえ、マネージャーであっても、チームの中で起きていることをすべて把握できているとは限りません。あなたがずっと課題に思っていることがいつまで経っても改善されないのは、マネージャーが単にその課題の存在を知らないか、問題だと思っていないからかもしれません。
リソースを割く意思決定はマネージャーがやるべきですが、逆に言えば、「意志決定」以外のことであれば、マネージャー以外がやっても全く構わないのです。課題の調査、情報収集、提案の整理などなど、マネージャーでなくてもできることはさまざまあります。
新人であってもハードルが低く、かつ最もやるべきなのは「課題を挙げる」ことです。これは他の人に解決を要望するという意味ではなく、「解決すべきかどうかは置いておいて、少なくともこんな課題がこのチームにあるよね」と皆の目に見えるところに書く、ということです。私はよく「机の上に並べる」という表現をします。
組織の中に、課題をまとめておくリストのようなものがあれば、あなたが感じている課題を気軽に、かつこまめに記入するべきです。課題の優先度づけや、解決策の考案は、必ずしもあなたがやらなくても構いません。それはマネージャーの責任範囲です。
大事なことは、「事実」と「価値判断」を分けることです。あなたしか知らない事実や知識があるなら、例えば「あの人が近くにいるとどうも緊張して仕事しづらい」というような話題であっても、あなたは可能な範囲で（例えばマネージャーにだけでも）共有するべきです。だってあなたしか知らないのですから！ そのような事実が誰にも知らされないままにマネジメントをしようとすると、チームの誰も望まないような大事故につながりかねません。
とはいえ、課題を知らされたからといって、マネージャーは必ずしもそれに対処する責務を負っていないことも理解してください。「マネージャーに課題を共有したのに、何も対応してくれなかった。せっかく勇気を出して伝えたのに意味がなかった・・・」とは思わないで！ あなただけが知っている事実を共有した時点で、あなたはチームに対して十分な貢献をしたのです。
5. 上司にフィードバックせよ
原則
あなたにとって良い上司となれるように努力するのが上司の責任
良い上司になれるよう、上司を"サポートする責任"は部下側にもある
解説
上司は仕事としてマネージャーをやっているのですから、良いマネージャーになるのは上司の職務範囲です。とはいえ、このチームの中で社員としてやっていけるよう、他のチームメンバーがあなたをサポートしてくれているのと同じくらいには、あなたも上司が「あなたにとって良い上司」になれるようにサポートしてあげるべきです。
上司も人の子なので、自分の課題に自分で気づくのは難しいことがあります。その課題を解決するかどうかの判断は上司に任せられるべきですが、「そこに課題（＝コミュニケーションのズレ）がありますよ」と伝えるまでは、あなたがやってあげるべき範囲でしょう。
例えば筆者の場合、自分自身が褒められるのがあまり好きではないため、部下に対してもあまり表立って「褒める」振る舞いをやらない傾向がありました。しかし、ある部下から不満の声をもらってから改めるようになりました。その部下は、職場の仲間からの声かけや感謝をもらうことでモチベーションが高まるタイプだったので、筆者の対応がそっけなく見えたようです。
人によってマネジメントに求めるものは違いますが、上司はしばしば「自分がされて嬉しいマネジメント」をしてしまう傾向にあります（別に悪気はないんです！）。マネジメントされる側からもちゃんと指摘してあげることで、お互いに良い関係を築くことができます。これは上司と部下の関係に限らず、あらゆる人間関係に言えることかもしれません。
とはいえ、上司に対してフィードバックするのはハードルが高い、という声もあるでしょう。そんな時はいわゆる「Iメッセージ」として表現するといいかもしれません。私を主語にして表現するのです。先の例で言えば、「〇〇さんは声かけが少ない」と相手を主語にするのではなく、「私はもう少し細かく声をかけてもらえる方が嬉しいです」と私を主語にして表現すると、上司の気分を損ねにくくなります。
この記事の限界
この記事は、上司が十分に成熟したマネージャーであり、あなたが十分なマネジメントが受けられることを前提に書いています。ですが、実際には上司がマネージャーとして未成熟であり、上記の責任区分を十分に果たせないケースもあるでしょう。その場合は、上司とコミュニケーションを取り、上司の能力に合わせて責任分担を見直すことが必要かもしれません。その場合は、この記事の原則の部分を上司に読ませて、上司の認識とどこまで一致しているのか、部下側に期待することは何かを確認すると良いかもしれません。その場合でも、あなたは上司に幻滅するだけで終わりにせず、上司の中の頼れる部分をきちんと認識しておくべきです。未成熟な上司であっても、あなたにとっては貴重なサポート源ですし、できる限りの活用の手立てを練っておくべきです。
また、この記事はあくまで部下側がアルバイトや社会人1年目であることを想定しています。もう少し部下の年次が高い場合、部下に求められる責任範囲がこの記事で述べているよりはもっと広くなることは注意しておいてください。例えば、アルバイトやインターン生であれば、タスクへのコミットメントはさほど要求されませんが、2-3年目以上の社員であれば、それなりに要求されるはずです。リソースが足りていない職場であれば、アルバイトであってもかなりの責任を要求されるかもしれません（良いことではないですけどね！）
「どの程度willを尊重してもらえるか？」「事実と価値判断をどの程度区別できるか？」といった点は、組織風土によってもかなり異なることは注意しておいてください。ITエンジニア業界は人手不足な上に流動性が非常に激しいこともあり、優秀なエンジニアを組織に留めておくためなら、かなりwillを尊重する傾向にあります。一方で、終身雇用がいまだに守られている企業の場合、部下のwillを尊重するメリットをそこまで感じていないかもしれません（本当は長期間雇用する企業こそ、部下の成長に投資するメリットが大きいはずなのですが・・・）。また、ITエンジニアは事実と価値判断を分離することに慣れている人が多いですが、世の中には事実と価値判断の分離が苦手な人も数多くいます。
この記事が気に入ったらサポートをしてみませんか？