見出し画像

エンジニアリングマネジメントをしながら心がけていること

この記事は、Engineering Manager vol.2 Advent Calendar 2018 12日目の記事です。

私は今エンジニア15人くらいの開発会社でコードを書いたりエンジニアリングマネジメントをしたりしています。
サービスの会社ではなく、お客様の開発をお手伝いする、受託開発をメイン業務にしている会社です(ただ仕様通りにコードを書くだけではなく、仕様を相談したりプロジェクトのすすめ方を含め一緒に考えてたり、エンジニアリングにまつわる様々な問題を一緒に解決する、お客様のエンジニアリングパートナーとして価値を届けることをしています)。

出発はプロジェクトマネジメントだったと思うのですが、プロジェクトを進めていく上でエンジニアのメンタリングや組織面の問題解決というのは切り離せなくて、そうこうしているうちに、自分が直接関わっているプロジェクト以外のことも見るようになって、いろいろな人の様子を見ていると評価にも関わるようになって、どうも自分がやっていることはプロジェクトマネジメントだけではないなと思っていたところに「エンジニアリングマネジメント」という言葉を聞いて、ようやく自分の立ち位置を理解したような気持ちでした。

まえがきが長くなりましたが、今日は日々エンジニアリングマネジメントとプロジェクトマネジメントが交わった仕事している中、心がけていることをいくつか紹介したいと思います。

話す
問題を一人で抱え込んでしまった、というのが後々大問題につながることはよくあるので話してもらえる関係づくりを心がけています。なんでもない話のできない相手に深刻な話はできないと思っているので、普段から休憩時間にちょっと声をかけたりしながら少しずつ話せる話題を増やしています。
また、週1のKPTを含んだふりかえりのときに、ほんの少し案件と直結しないプライベートなことを混ぜると、ちょっとした交流になります。最近興味を持っている分野の技術から体調まで様々な話が出るので、チームメンバーについて知ったり知ってもらったりするのにとてももいい時間だなと思っています。
一時期社員間のつながりが希薄に感じていた時期があったので、その時は月1回複数人集めて今自身がどんな仕事をしているか自分が考えていることを自分の言葉で語ってもらう会をしていました(もちろん業務時間内で)。私でなくていいから誰か困った時に話せる相手が見つかればいいなという狙いでやっていましたが、今はそういう会持たなくても雑談で最近どうよって話ができているようなので心配のない状態になりました。

聞く
聞いたほうがよいなという思うタイミングがあって、こちらから声をかけたり、相談を受けたり、そういう時は会議室で対面というよりも、ご飯を一緒に食べながら聞きます。自社の人だけでなく、ときに社外の人の話も聞きます。結論はこちらから出さず、言語化の手伝いや、心の整理、感情に適切な名前をつけていくサポートをするだけでも話し始める前と後で全然顔つきが変わってくる人もいます。そんな時はいつも、教職についている学生時代の先輩に「学校教育大変じゃないですか」と聞いたときに返ってきた「(生徒は)話し足りてないね。話を聞くだけで8割解決するよ」という言葉を思い出します。昨年からは1on1を始めてみました。今までやってきたこととはまた違った切り口で難しさを感じつつ、継続することで効果の出てくるものだと思っています。

結論を言う
仕事をする中で議論したあと、なんとなく合意を形成されてそうな時があります。そういうときこそ「では○○ということですすめていきましょう」と結論を言うようにしています。特にissueなどで非同期にやりとりしたあとは流れを全部読まないと最後どうなったことかわからないし、余計な思考のリソースが必要になってきます。自分の思い込みかも?といった不安を持つ人もいるし、その傾向は当事者でなくなるにつれて顕著になります。だから、結論=方針を伝えながら進むことは安心感に繋がると感じていて、ちょっとくどいかなと思う時もあるけどそこははっきりさせて進むようにしています。

セレクトメイドとオーダメイドで作る
チームや組織の数だけ「やりやすい」があるので、チームビルディングは毎回オーダーメイドだと思っています。
いろいろな手法を知っていればそれらを組み合わせられるので、知ってる手数は多い方がいいし、試したことがあるとなお強い。全部は適応できなくても一部使える、エッセンスは使える、意外なところで使える場合もあるから面白いです。あと断然ゼロから考えるよりも早いです。
だからよくやるのは知っている手法を組み合わせたセレトメイドでとにかくはじめ、走り出してからよりチームに合うように調整してオーダーメイドにしていくことです。アプリケーション作るときも、この要件を満たすためには何を使ったらいいか、自分が造形の深い言語やフレームワークは何か、最近の技術動向などいろいろ考えて組み立てるのと近い気がしています。

楽にならないか考える
開発は毎日続くものだから手間だとやってられません。面倒なことはどれだけ大事だってわかってても続かないですよね。だからこそうまく回るよう仕組みを整えていく中で、そもそも必要か、違うことで同じ結果を得られないか、仕組みもリファクタする必要があると思います。
ものによっては開発チームだけでなく他の人も関係するようなこともあるし、そういう場合はどちらかだけでなく、両方楽になる、関わる人それぞれにとっての「よい状態」を探すようにしています。
この時「自分」も楽になることを含めるのが大事だと思います。マネージャーだけ大変、マネージャーだけが知っているといった歪な形にしておくと、急に何かあったときもそうですが、休みくらいきままに取れないとストレス溜まります。よく疲れてしまったマネージャーの話を聞きますが、すり減らないように自分のこともいたわっておきたいです。踏ん張らないといけないときもありますしね。
楽できないか考えますが、考えることまで楽するとしっぺ返しを喰らいますね。一気に負債になる。

見直す
楽にならないか考えると近いのですが、プロジェクトは生き物で、組織も生き物で、絶えず変化をしています。その時々に適切な試みがあるので、一度仕組みを決めたから安泰とはなれないことが多いです。だから仕組みは大掛かりでない方が柔軟にその時々に即したものにしていけます。個人的にメンバーが変わったりメンバーの増減があった時が見直しタイミングだと感じています。

答えは内側にしかない
セレクトメイドの話と近いけれど、今自分の抱えているエンジニアリングマネジメントの問題を、本を読んだり誰かの話を聞いたりして知った方法そのまま適応することで解決、というのはまずできないです。自分の悩みと同じに思えたとしてもそれはその人、そのチーム、その会社の問題であり、その個別の問題に対する解決方法だったからです。いろいろな場に行ってしみじみ思ったのですが、私の会社自体が結構立ち位置特殊で(規模が小さい、サービスを持っていない、スタートアップでもない)自分とまったく同じようなケースにまず出会わないんですよね。それでも本を読んだり、経験を聞いて様々な方法を知っていると活かせる部分が出てくる部分があるので、インプットし続けたほうがいいと思っています(今回のAdvent Calendarほんとありがたいです)。
メソッドやメソッドの使い方を知っている方が速くコードが書けるのと近いかもしれません。

誰がやってもいい
マネジメントというのは開発のための役割の一つだと考えています。フロントを開発する人もいれば、バックエンドを開発する人もいて、マネジメントする人もいる。そんな役割の一つだと考えています。これは私がプロジェクトをやっていく上でエンジニアリングマネジメントも必要だろうなと思ってやりはじめたからかもしれません。しかし、マネジメントをするからって全部一人でやらないといけないわけではなく、手におえないことは他の人にお願いすればいいし、マネジメントを担っている人がコード書いてもいい。チームなんだからどれも全部一人でやらなくていい。むしろ一人でやってはいけないし、やれるわけないくらいに思うのがバランスが取れそうです。任せることは任せたらいいし、育てることも忘れてはいけない。必要以上に住み分けなくていいと思います。やらなくてもせめてお互いのことを知っているのは大事だと思います。開発現場のわかるマネージャーがいいという話もありますが、マネジメントがわかる現場というのもうまく回るんじゃないかなと感じています。

目指す先
言葉を選ばずに言うと自分が不要になるような状態かなと思っています。自分がいなくても「うまく」回る仕組みにするにはどうしたらいいか考えながら日々過ごしています(いなくてもどうにかなるものの、いるからスムーズな部分は多少あるんだと思っています)。エンジニアリングは何かを解決することで、マネジメントもその役割の一つである以上不要になる=解決できたかなと考えています。また不要になれば次のことに取り組めるのでわくわくします。だから自分がいるから大丈夫ではなく、いなくても大丈夫を目指しています。NO属人化。

健康維持
役割上決断しないといけないことや、意見を述べないといけないシーンが多くなってくるので、これは体力が落ちている時は難しいものだと感じています。疲れていると伝えないといけないことを後回しにしたくなることも…。なので適度に運動して、睡眠をよく取ることを意識的にやっています。ストレスとの付き合い方も覚えました。

気楽にいく
肩の力が入りすぎると視野も狭くなって悪循環に陥っていきます。あと余裕のない人には相談もし辛い。表面上だけでなく内面も余裕を持てるようにしたいと心がけています。うまくいかなくても命まで取られることもないし、思い描いていた状態じゃなくてもいい状態というのは存在するし、予想と外れたとしても悲観しすぎない。最終的にいい状態(気持ちよく利益を生み出せる状態)になればいい。そんな風に思っていたほうが道は開けていくと信じています。何事もなく平穏無事に過ぎていってほしいのだけど、何かしら起きるし、起きないとそれは起きないのじゃなくて見落としているだけだと思います。最初から何か起きるものと思っていたほうがよっぽど気楽です。
一生懸命になるとつい忘れてしまうので「気楽にいく」最後にこれを書いて締めたいと思います。

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
4
「なんかいい感じにする」係。RubyやRails使ってコードを書く傍らエンジニアリングマネジメント活動中。ひとり広報も兼任。ときどき技術イベントスタッフとノベルティ職人。株式会社万葉所属。
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。