(旧ブログから移行しました。)
はじめに
私は社会人4年目のWebエンジニアです。1-3年目は独立系SIerで過ごし、2019年2月よりアドテク系の事業会社にてエンジニアをしています。
思い返せば、1社目で「マネジメントされていた」という記憶があまりありません。 もちろん「タスクのデッドラインはいつです」的な話や、半期に一度ある評価面談は経験してきました。しかしながらもっとこう、「人間的な」マネジメントというか「ソフトな面」でのマネジメントはあまりされてこなかった気がします。
それは会社として進める人材育成が「いちエンジニアとして」ではなく、「組織の役に立つエンジニアとして」という側面が強かったからなのかもしれません。
もちろん、組織の役に立つ人材であることは必須ですが、これは個々のエンジニアとしての個性を生かした上であることが望ましいと考えています。
転職先では幸運なことに、ぼくの目指したいキャリアを親身になって考えてくださった上で目指すべきキャリアパスを描けていると感じています。
それは、会社の雰囲気的な面でもマネジメント的な面でも感じています。
オライリー社「エンジニアのためのキャリアパス テックリードからCTOまでマネジメントスキル向上ガイド」を読んで気づいたことを述べていこうと思います。
以下、2つのモチベーションを持ってこの本を読みました。
- 将来マネジメントする立場になった時に心得ておくべきことを学ぶ
- うまくマネジメントされる人間になる
自分がマネジメントする立場になった時に備えるのはもちろんですが、マネジメントする側の視点をマネジメントされている今、汲み取ることができればより強いチームになることができるのではないかという思いが強いです。 私は技術・ビジネス・マネジメント全ての方面で未熟です。継続的な努力はもちろん不可欠ですが、いい意味で「うまくマネジメントされる」こともまた、自分の成長を促進されるのではないかと思うようになりました。 「伸ばしてもらう」「いいところを見つけてもらう」「課題や苦手分野を教えてもらう」にはどうしたらいいかを考えることが今後、「うまくマネジメントする」ことに生かされるのではないかという思いで読み進めました。 今回は、新任の管理者向けに書かれた1-4章と、組織文化育成について書かれた9章を読ませていただきました。 今まで自分になかった観点や、今後のエンジニアライフの教訓となるものについて、過去の経験を交えながら述べていきます。
言葉の定義
本書で取り上げられている用語の定義を簡単に。
- テックリード
プロジェクトに携わるエンジニアチームの「技術的なリーダー」。技術的なプロジェクトのリーダー役を果たしより大きなスケールで自身の専門知識を駆使してちーむ全体の向上を図るという立場にある アーキテクチャ決定やビジネスアナリストを担当するだけでなく、プロジェクトマネジメントも行うと本書では定義づけられています。
技術に長けた知見を有しているのみでなく、チームプレイを心得ていること、コミュニケーション能力に長けていること が優秀なテックリードの条件と言ったところでしょうか。 - マネージャ
テックリードの上に位置するいわば、プロダクトマネージャを指すように述べられています。
管理者
1人でも2人でも、エンジニアを抱えることになったらそれは管理者と定義されています。管理対象に大小があるということです。
どう管理されたいか
考えること自体が初めてで新鮮でした。
自分の仕事の進め方を省みるきっかけ
自分の性格
時間を忘れて没頭してしまう性格と思っています。
加えて、変に几帳面で、順序立てて一個ずつクリアしようとする性格です。
「できなかったら時間をかけたらいいじゃん」という発想に至ってしまうことが多いです。
タスクの途中
とあるタスクをこなしている最中に、だらだら調べ物をしたり、技術ブログを読み漁ったり「なんともいえない時間」があることを思い出しました。
また、「仕上げること」に壁を感じてしまい、別の作業に退避することがままあります。(このエントリの作成中に3記事下書きに避難しています)
以上の2つの課題によって、一つのことにかかる時間の見積もりが測れないままタスクを完了させてしまう事態に陥ってしまいます。よくない現象ですね。
そしてそもそも、タスクの工数が見積もれるように作業の分解ができているのか、という発想に至りました。
完了日の提示
達成できないようなこと、ギリギリ間に合うか？ということを「明日までにできます！」と宣言してしまいがちです。
「期日を聞かれる」ということつまり「誰かがその成果物をみる・待っている」という観点が不足してしていました。
管理者が望むことは、「早く成果物を出す」よりも「期日通りの成果物を出す」ことなんだと思い知らされました。
上司が話してくださった「期待値コントロール」というワードが印象に残っています。評価制度には多かれ少なかれ「他人からの印象」反映されます。
「明日出す」といったことを明後日出したら「１日遅れだな」と思う一方、「明後日出す」といって「明後日出したら」「期日通りだな」と後者の印象が良いのは一目瞭然。
そんなことに気づかず、「早くやります！」と主張していました。
宣言したことを達成できないのは自分にとってもヘルシーではありません。
「ギリギリの期限だけど間に合うように力をつけよう」という発想を「まずは遅すぎない範囲で期限を設定し、成功体験を多く経験し、徐々に期限を前倒しできるように力をつけよう」という発想に変えようと思うようになりました。
幸いなことに、今の環境は自分で期限を設定させてもらえることが圧倒的に多いです。今のうちに自己マネジメントの術を得られるようにしていきます。
自分が描いていたロールモデル
以前のエントリ、新卒入社したSIerを3年で退職しましたで「理想のエンジニア像」を以下のようにあげていました。
シンプルでわかりやすいアウトプットができる 新しいことに常にチャレンジする ビジネスで力を発揮できる
果たしてこれがテックリードと呼ばれる存在なのか、マネージャと呼ばれる存在なのか。どちらかといえばテックリード的な立ち位置が近いのかと思います。
しかしながら、転職して3ヶ月たち、自分の足りないところだったり自分のなるべき像に若干の変化が見られるようになりました。
自分は技術でトップに位置する人ではないのかなと思うようになりました。
もちろん技術的に高くありたいと常に思っているのですが、コミュニケーション的な面の方が自分の良さを発揮できるのではないかという思いからです。
テックリードでありたいのか、マネージャでありたいのか、はたまたセールスエンジニアでありたいのか、今は断定せずとも、この先をより一層考えながら過ごす必要があると強く思うようになりました。
困ったことがあったらいつでも相談してくれという方針をオープンドアポリシーと呼ぶそうです。
もとからウマが合う社員はより相談にきやすくなるけど、ウマが合わない社員とは余計に疎遠になってしまうということが指摘されていました。
思い返すと、前の会社でまさに「いつでも相談していいんだよ」という環境にいました。実際には相談しづらいし、「わかんないところある？」って聞かれて初めて"相談したいことの言語化を試みる"ようになった気がします。
新人の頃は、どういう時に質問していいか困ったものです。事前に「こういうケースの場合は相談する」「何分考えてわかんなかったら、何パターン試してわからなかったら相談する」と取り決めをすることで楽になったことを思い出しました。
定期的な1 on 1の重要さ
定期的な1 on 1は「相談したいことを思い浮かべる」「相談したいことを言語化」する絶好の機会になります。「話すことがないから無駄な時間」なんてことは決してないとぼくは思います。
話すことを考えること自体に大きな効果があるからです。
また、仕事という枠組みにとらわれないパーソナルな面が分かるとぼくは仕事がしやすくなると感じています。意外にも仕事以外の話題の方が、その人の人間性は見えてくるものですね。
"自分の成功を内面的に肯定できず、成功が自分の実力によるものではないと思い込む、自己評価が異常に低い状態" をインボスター症候群と呼ぶ。
「できたけどこんなん誰にでもできるよな」と、自分の成果を喜べないことがよくありました。もしかしたら本当に誰でもできるレベルなのかもしれないけど、自分のやってきたことを素直に喜べないのもヘルシーじゃないなと。
できることを高度化させることももちろん目指すけど、簡単なことでもより多くの学びや気づきを得られる状態にまず持っていこうと思うようになりました。
成功の過程にある達成目標を明確にすることで、成功体験を多く手に入れることが成長のタネになるということ。これには頷くしかありません。
中学校の国語、井上ひさし著「握手」での「困難は分割せよ」というルロイ修道士の言葉を思い出しました。
上司も自分と同じ人間であること
自分と同じように、調子が出ない時もあればだれにも邪魔されたくない時もある。饒舌な時もあれば、何やってもうまく行く時もある。逆もまた然り。
うっかり口を滑らせてしまってバツが悪い思いをする時もある。失敗しちゃったなって思う時もある。
上司もうまくいっていないから、自分もうまくいかなくていいというのでは決してありません。
自分と同じ人間であると思うだけで、肩の力が抜けて幾分かリラックスした気持ちになりました。
有能な上司
有能な上司 ≠ 友人のようにウマが合う上司, エンジニアとして尊敬できる人
ではないということ。自分・チームとの関係を「職務遂行」を軸に構築できる人。
問題解決の手法を上司に求める = 相手への敬意と信頼を示す
これは管理者になった時に、自分への信頼度合いの尺度の一つにしたいなと思います。
技術的な学習は都度行ってきましたが、マネジメントに関する本を読んだのは初めてでした。
「管理者になったらこうすべき」という以前に、「管理者はここを見ている」というマネジメントされる側の観点を得ることができました。その観点を持つことで、「現在の自分のタスクの進め方」を省みる機会を得ることができました。
至極小さな一歩ですが、よきエンジニアの管理者への道を一歩踏み出せたと思います。
幸いなことにごく小さなチームですが、マネジメント的なこともさせてもらっていますし、個人の仕事も裁量権を持ってやらせてもらっています。
良い仕事をするために、良い管理は欠かせません。また、管理はチームだけではなく個人に対しても有効です（少なくともぼくに管理は必要です）。
どう管理されたいかという観点を持つことが自分にとって新鮮でした。そこから掘り下げて、どのように進めればよいのか改善策が幾つも見つかりました。
うまくいかないなと思うことばかりですが、現状打破の糸口がつかめました。
ただ単純にうまくいかないように自分で仕向けちゃってることが多かったり。
この本を紹介してくださった上司にお礼申し上げます。
「この本で書かれたこと実践されているんだな」とクスリときてしまうことが何度もありました。それだけ「よくしていこう！」って思ってくださってるんだとありがたく思います。
ともあれ、エンジニアっておもしろいですね。
参考
エンジニアのためのマネジメントキャリアパス―テックリードからCTOまでマネジメントスキル向上ガイド