エンジニアリングマネージャー初週の具体的行動と成果を客観解説

エンジニアリングマネージャーとしての最初の1週間で成功するための心構え

何年か前のこと、あるスタートアップに入ったんだけど、その時はエンジニアが自分一人しかいなかった気がする。プロジェクトの規模が思っていたよりかなり大きくて、一人で全部やるのはたぶん無理だと途中で感じてきた。そういう流れから、海外にチームを作ってみて、それをまとめる役割もやってみようかと思いついたわけだ。でも、これが思ったより簡単じゃなくて、マネージャーという立場になった最初の頃は色んな壁にぶつかった覚えがある。

プレッシャーも結構あったし、「そろそろ自分の実力を見せないと」という焦りも混じっていたかもしれない。正直なところ、準備万端だと思い込んでいたけど、数日経つうちに現実はもう少し複雑だった。新しくできたチームをちゃんと軌道に乗せるまでには想像以上に時間がかかった印象が残っている。

振り返れば「ああしておけばよかった」と思うこともちらほらあって、この辺りの体験談は他にも同じ立場になる人には少し参考になるかもしれない、と今では考えるようになった。一週間目ぐらいの話だと、大事なポイントはいくつか頭をよぎる。それぞれ具体的ではないけど、自分自身もうまくやれると信じすぎず、むしろ色々手探り状態でも何とかなるという気持ちで始めた方が落ち着いて進められる場合もある。

こういう話、多分似たような状況になる人は意外と多い気もするから、「最初の週」について知っておけば余計な失敗や悩みを減らせる可能性も出てくると思う。

初日のミーティングで失敗しないための準備術

会議にちゃんと準備して臨むことって、まあ、当たり前のようで案外難しいよね。ちょうどマラソンを突然走るよりは、ちょっとストレッチくらいした方がいいかな…みたいな感じ。最初の一週間には、自分のチームだったり、他の管理職や上司とも顔合わせがあるらしい。でも、「何でも全部教えてもらえる」と思って行くと、多分あれこれ抜け落ちる気がするんだ。トレーナーに「今日どういう運動したい？」って逆質問されたら困っちゃうし。

せめて今進んでるプロジェクトとか、その背景ぐらいは自分でざっくり調べておいて、「なんで技術的負債は最後に片付けているのか」とか、そういう話題から入れた方が対話もしやすいと思う。何を知らないかを書き出しておくと後々役立つことも多い。それに会社のシステムとか目標、それからリスクとか製品計画辺り――まあ大体七つ八つくらいある主要テーマ？　それぞれ少しずつ下調べしておいた方が良さそう。文化とか組織図も意外とクセ強かったりするし、ドキュメント抜けてる部分も見つけやすくなるかな。

それから…上司との面談だけど、この人が採用や昇進を決めた張本人というパターンも多いよね。信頼されて任された可能性は高そうだけど、最初の挨拶で土台作りを意識すると、その後わりと楽になる場合もあるみたい。ただ実際どうなるかは、その時々によって違うんじゃないかな…

Comparison Table:

テーマ	ポイント	詳細	提案	影響
職場の雰囲気の変化	コミュニケーションスタイルの調整	冗談から堅い接し方への移行がある時期がある。	行動で示すことが重要。	チームメンバーも自然に適応する。
エンジニアリングマネージャーの役割	信頼関係構築の重要性	一対一のミーティングで個々の悩みを理解する機会を持つ。	定期的なチェックインを実施する。	チーム全体のスキル向上につながる。
技術作業からの離脱感	転換期による戸惑いと不安	コードを書く仕事から離れ、別の責任を担うことになる。	タスクやプロジェクトを他人に引き継ぐ計画を立てる。	チーム全体のパフォーマンスにも影響する可能性あり。
継続的改善プロセス	小さな変化が大きな成果につながる可能性について考える必要あり。	日常業務で発見した改善点を共有する文化を育むことが重要です。	定期的に振り返り、アイデアを書き留める時間を設けるべきです。	全体として効率と品質向上につながるかもしれない。
人間関係づくりとコミュニケーション強化	メンバーとの接点保持が仕事環境改善に寄与する	目標や困難について軽く聞くことで相互理解が深まる	個別面談やグループディスカッションなど様々な形式で交流促進	良好な人間関係はチームワーク向上に寄与。

上司との最初の1on1で絶対に確認すべき5つのポイント

新しい上司との初顔合わせ、いきなり全部決めるのは難しそうだけど、まあ大体こんな感じで進んでいくことが多い。まずは、どうやら彼らが自分に何を期待しているか、そのあたりを曖昧ながらも把握したほうが良さそう。優先順位だって、今すぐ必要とされている仕事とか、ときには後回しになりがちな細かいタスクとか、色々混じっている印象。現状の悩みや困りごとについても、とても明確な場合もあれば、なんとなく気になってる…くらいの話題しか出てこないこともある。

それからコミュニケーションの方法だけど、人によって本当にバラバラで、数十人くらいいるリーダーでもメールでまとめて知りたいタイプもいれば、一部はチャットツール（Slackみたいなの？）で簡単に報告して欲しいという声も聞いたことがあるし、中にはたまに会議室でちゃんと話さないとピンとこない人もいるみたい。頻度についても、「将近一半」くらいは定期的な短時間チェックインを希望する傾向。ただ、それぞれ好みに幅があるので、その都度微調整になる場合が多そう。

成功の評価軸やKPIなんて言葉もちょっと抽象的だったりするけど、「約三成」程度は数字中心、「残り」は定性的なフィードバック重視…みたいな傾向を過去に見た気がする。あと、自分から何か提案できたほうが印象良くなる場面、多かったんじゃないかな。ただし、押し付けっぽくならず少し控えめに切り出すほうがお互いやりやすかった例もちらほら。

リーダー職の場合、お互いの課題や目標って時期によって意外と変わったりするものだから、ときどきペース合わせ直すような感覚でチェックインするとズレにくいかもしれない。その際の連絡手段とか資料形式について、「七十多」のマネージャー経験者談では「事前に確認した方がお互い楽」と言われることもあった。

ちなみに、自分自身内向的だったらそれを隠さず伝えることで相手側にも配慮してもらえる場合がある――これは必須じゃなく状況次第だけど、一応選択肢として覚えておいて損はないと思う。

チームメンバーと信頼関係を築くための再自己紹介法

そういえば、あの打ち合わせで話した内容が全部ちゃんと整理されていたかどうか、時々心配になることもある。何人かはまだ疑問が残っていたみたいだし、全員にもう一回まとめたメッセージを送った方がいいのかもしれない。意外と見落としてしまうポイントも少なくないから、一言添えておくくらいが丁度良さそう。連絡やコラボについて、自分の希望を伝えるのは少し気が引けることもあるけど、お互い無理せず距離感を保つには必要な気がする。

それと、「自己紹介」みたいなもの…会社に入ったばかりだったり、役割が変わったタイミングでは特に、改めて自分を簡単に紹介しておくことで関係性も作りやすくなる場合がある。ただ「こんにちは」と挨拶するだけじゃなくてね。七十人以上いるような大きいチームだと誰が誰かわからなくなることも多いし、なんとなく顔合わせただけで終わってしまうことも…。まあ全部完璧には覚えられないと思うけど、大事なのは何となくでも繋がりを作ろうという姿勢かな。曖昧だけど、それぐらい柔軟に考えておけば困る場面は減りそう。

元同僚との関係をリセットするときの注意点

会話のきっかけになることって、意外とドアを開けるだけだったりする。例えば最初にチームと顔を合わせた時、みんなが何に困っているかとか、どんな作業だと楽しいと思うか聞いてみたり。何か変えたい部分や、「こうしたら良くなるんじゃない？」っていうアイデアや不安なんかも、ぽつぽつ出てくることがある。

まあ、こういう質問って新しく会社に入ったばかりの人だけが必要なのかな、と感じる瞬間もある。でも実は昇進してポジションが変わった時でも、自分のことをもう一回紹介し直すタイミングって大切になってくる気がする。

昔から知っている同僚相手でも、状況や悩みごとはいつのまにか変わっていたりするもの。全部知っているつもりで接すると、ちょっとズレちゃう場合もある。だからこそ「今はどうなの？」くらいの好奇心を持つ方が無難だったという話もちらほら耳にする。

昇進後の関係性は、七十多通りくらい微妙な空気になったりして…。誰もがその変化にすぐ馴染めるとも限らないし、中には少し戸惑う人も出てくるんじゃないかな。力関係みたいなものも多少入り混じったりして、不思議な感覚になることだってあったような気がした。

あれこれ言われても全部正解とは限らないし、その場その場で話題もちょっと飛ぶけど、大体そんな感じだと思う。

コードから離れる覚悟 - 技術的な仕事との向き合い方

なんとなく、職場での雰囲気がちょっと変わったかな、と感じる時期がある。昔は同僚と冗談を言い合っていたけれど、急に少し堅めに接したいなと思うようになることも。そんな時、わざわざ「自分は今から真面目になります」と宣言する必要はないらしい。むしろ行動で示す方が、まわりも自然についてきやすい、と耳にしたことがある。ただ、誰かが妙に抵抗してくる場合には、早めに境界線を引いておくのも悪くないという話だ。

尊重する態度は当たり前として、それでもエンジニアリングマネージャーみたいな立場になると、自分の一言一言が思ったより大きな影響になりやすいらしい。特に技術的な議論とか、ちょっと空気がピリッとしている時なんかね。何をどう伝えるか、意外と注意したほうが良さそう。

それと、一対一のミーティング――あれも忘れる人がたまにいるけど、本当は信頼関係を作る上でけっこう大事だったりする。エンジニア達それぞれの悩みとか、小さな困りごとにも気づける時間だから。

週末近くになって、一通りミーティングをこなしながら色々吸収していると、「もうコードを書く仕事から離れるんだな」とふと思う瞬間がある。手放し難い人も多いみたいだけど、この転換期を経験して初めて実感する人もちらほら見かける。その変化自体は七十回くらい繰り返されている話だけれど、不安とか戸惑いみたいなのは案外よく聞く。でもまあ、最初ほど怖かったわけじゃなくなる例も結構あるし、人によって感じ方はいろいろだろうね。エンジニアリングマネージャーになるっていうのは、大げさじゃなくても仕事内容そのものが以前とはずれていく――そんな認識になることも少なくないようだ。

引き継ぎ作業でチームが混乱しないための具体的な手順

なんとなく、こういう時にはちょっとした寂しさがついて回るものだと思う。新しい日常になじむまで、たぶんそれなりの時間がかかるはず。ただ、それは自分ひとりの問題じゃないってことも頭に入れておいたほうが良さそうだ。技術作業から離れると、チーム全体のスキル的な余裕もまあ多少減る気がする。その分だけ、目の前に現れる課題も増えるという話。

で、どうすればいいか…　まず、自分がやってきたことを誰かに引き継ぐ段取りをつけておく必要が出てくる。あれこれ思い返して、この仕事ならあの人かな～みたいに考えてみたり。実際、その辺はざっくり決めてしまうことも多い。

作業途中だったものとか、終わってないタスクなんかは、一度全体を見直してみても損はないと思う。スケジュールも微調整したほうが無難かもしれない。全部一気に詰め込むより、「まぁこのくらい余裕持とう」と考えた方が結果として落ち着くケースもある。

あと上司への説明…これは多少面倒でも正直に話しておいた方が後々楽になる場合がある。「今こういう状況なので…」とか「少し遅れる可能性があります」と伝えておけば、大きなトラブルにはなりづらい気配。

納期の見直しについては、人によって意見も違うけど、自分たちのペースを守ったほうがおそらく良い方向へ進むことも。それこそ無理に期限通りを目指すより、一息ついて丁寧にやるほうが良質なアウトプットにつながる場面も少なくないようだ。

ま、とりあえずこんな感じで何とかなる場合もあるという話です。

金曜日の振り返りが1年後の成長を決める理由

あまり重要でない仕事は、まあ、ちょっと後回しにした方が無駄な遅れを減らせるかもしれない。それにしても、何が大切かっていうのは時期によって変わるし、みんながバタつく中で誰かが整理して指針を示すと、不思議と少しだけ空気が落ち着くこともある。転換期には多少の混乱は避けられないようだけど、明確な方向性があれば新しいペースも徐々に馴染むんじゃないかな。

一年目のエンジニアリングマネージャーとしては、なんというか見知らぬ土地を歩き回っている感じになることが多い。全部いきなり分かったような気にはならない方がいいとも言われている。金曜日の午後とか、週末前の静かな時間にふと立ち止まって、自分たちの進み具合について考えてみる人もちらほらいた。そうやって引っかかったものや気になったことを拾い上げておくと、不意に同じ問題がまた出てきたときにも慌てずに済む場合もある。

継続的改善――これは過去にも色々語られていて、日本だと数十年前から現場でよく話題になっていたようだ。トヨタでは七十年近く前だったか、その頃から現場の作業員たちが何か小さな改善案でもノートにメモしておいて、それを毎日の「カイゼン」会議みたいなので話し合う風習が根付いていたとも聞いたことがある。ある従業員の話によれば、とある組み立て作業中に使われていたワッシャー部品が実は必要ないんじゃないかと思った…そんな細かな気付きも共有されていたとか。本当に全員そうだったかは定かじゃないけど、小さな積み重ねこそ後々活きるケースも考えられる。

トヨタ式改善手法から学ぶ小さな気づきの積み重ね方

何人かがふとしたノートに書いた小さな気づき、あれがきっかけだったらしい。チームの中で色々試してみた結果、機械を一台減らしても品質にはほとんど影響しなかったとか。ただ、それによって時間も材料もちょっとずつ節約できて、長い目で見れば会社にも結構良いことがあったような印象。驚くほど大きな変化というよりは、地味だけどじわじわ効いてくる感じ。

週末にぼんやり手元のメモ帳でも広げて、この一週間の仕事を振り返ってみるのも悪くないかもしれない。何か大掛かりな改革じゃなくても、自分や周りのみんなの作業を少しだけ楽にする工夫って意外と見つかったりするから。不思議とそういう話題は同僚とも共有したくなるものだし、まあ一緒にやってみてもいいと思う。

例えば、今週何度も繰り返して無駄じゃないかな？と思った作業とか、ちょっと困った場面ではどう対処したっけ…なんて考えてみたり。あと、新しく覚えたいスキルがあるなら、それについて軽く調べてみるとか。「来週何を目指そう？」なんとなくでも目標を書いておけば忘れにくいし、小さいことでいいから「これ変えたら少し楽になるかも？」というアイディアが浮かぶこともある。予定は結局毎回変わるけど、一応ざっくり来週のプランをメモしておけば焦らず始められる気がする。

最初の1週間でやるべきことを5行でまとめてみた

来月のことを考えると、何かしら継続的な改善を意識していくことで、メンバーが少しずつ前向きに変化を模索するような雰囲気がなんとなく生まれるかもしれません。チーム全体が頻繁に成長への糸口を探す感じ、あれです。

最初の週は、とりあえず会社やメンバーについて分かる範囲で学び始めるのが多いみたいです。資料とか新たに増えているものもちらほらあるし、それにもざっと目を通すとか。あと、上司とかチームとの打ち合わせに向けてそれなりに準備した方がよさそうです。聞きたいことを整理したり、会話中は相手の話をちゃんと拾う姿勢も大切という話もよく出ますね。

個人作業から少し離れることへの戸惑いも多少はあるでしょうから、その辺もチームの計画見直しと絡めて柔軟に調整した方が無難だと思われます。何日か経ってから振り返った時、「思ったより知らないこと多かったな」と感じる場面も出てくるんじゃないでしょうか。

それから、人間関係づくりについてですが…やっぱりメンバー一人ひとりと軽くでも接点持っておいたほうがお互い仕事しやすいみたいです。目標とか困っていることとか、どんな働き方が心地いいかなど、本音までは難しいけど少しくらい聞けるタイミングもあります。

コーディング自体にはそこまで毎日手を動かせなくなる場合でも、技術的な方向性とか道筋作りには関わったままになれる可能性は高そうです。あと、詰まりポイントでフォロー入れる役割や、成果物だけじゃなくてチームそのものの成長・進捗を見る立場へ徐々に移行していく流れになる、と言われたりしますね。

ちなみにソフトウェア開発チームリーダーとしてもう少し色々知りたかったら、「デイリープライオリティトラッカー」みたいなツール付きニュースレター紹介しているケースも見た覚えがあります。ただ全部役立つとは限らないので、ご自身で必要そうなところだけ拾えば十分かなと思います。