00:06
3月15日、水曜日ですね。
時刻は朝9時13分になりました。
昨日はホワイトデイというところでお酒を飲んできたんですけど、ワインを飲んできたんですけどね。
2日にならなくてよかったので、今日も頑張っていきたいと思います。
はい、おはようございます。ひめみんのkeethことくぶわはらです。
では本日も朝活を始めていきたいと思います。
昨日一昨日とすみません、完全に朝活をドアスレしてました。
コードを書いているとやっぱり時間を忘れてしまってですね、ついつい熱中してしまうんですけど、
ちょっと今日はちゃんと朝活をやっていきたいと思います。
3日前とかですかね、技術記事をいくつかガーッと読んでたりしてたんですけど、
今回はマネージャーというところで、いわゆるマネージメントをやっている方から
エンジニアに対してのフィードバックというところの話を読んでいこうと思います。
海外の方のこのマネージメント系でエンジニアに対してのブログを書いているって、
僕今まであんまり読んだことなかったので、これ面白そうだなと思ったので見てみたいと思いました。
また日本のマネージャーの方、いわゆるプロジェクトマネージャーの方が
エンジニアに対する思うことと、海外の方ってどれだけギャップがあるのかなっていうのも気になったりしたので、
その辺ももし知れたらなと思っています。
まあ、あいおけはさておけやっていきましょう。
タツヤ長谷川さんですね、おはようございます。ご参加いただきありがとうございます。
今日もダラダラとやっていきたいと思います。
では早速書いてみましょう。
エンジニアとして、またエンジニアのマネージャーとして20年のキャリアを積んだところです。
私は両方の役割についてかなり良い視点を保つことができたと思いたいと。
振り子のように揺れ動くことも何度もありましたけど、
同じ会社でエンジニアとマネージャーを何度も経験したこともあります。
どちらの役割も全く異なる理由で楽しんでいますと。
友人や同僚には、エンジニアとマネージャーの間の緊張感についてよく話しています。
私は複数の帽子をかぶり、ギャップを埋めようとすることができます。
エンジニアはしばしばマネージャーと対立することがあります。
時には不当な理由が発生する場合もありますと。
しかし、私の経験では健全な期待値の不一致もよくあることになりますと。
そのため、上司が期待することを明確かつ直接的に理解することは良いではありません。
最近の会話では、私はマネージャーとしての自覚を持ち、それを実行しようとしましたと。
前置きでは字が時差に聞こえるかもしれませんが、ご容赦ください。
エンジニアに戻ったある時期、マネージャーたちは良いことをする方法の例として私を使い続けていましたと。
私はあまり目立つような重要なプロジェクトに参加していなかったにも関わらずですと。
エンジニアたちは、私が評価されるために何をしているのか聞いてくるのです。
私は結局、マネージャーがエンジニアに期待することの非公式なリストを作成することにしました。
それがいっぱいありますね。
今からガーッと述べていくんですけど、十何個くらいありますね。
2つ目、聴取に合わせてアップデートを調整しましょうということですね。
プロジェクトの近況報告には良いものと悪いものがあります。
どのような詳細が重要であるかというのを学んで、それを記載するようにしましょう。
また、聞かれない限りはどのような内容を省くべきかというのも学びましょう。
03:00
確かにですね、全部全部きれいにクリアに伝えるのも大事かもしれないですけど、時間も奪われたりしますからね。
続いて3つ目です。3つ目はタイムリーなアップデートをしましょうということですね。
毎日更新する必要はありません。しかし1週間も連絡を取らないというのは絶対に避けましょう。
4つ目ですね。4つ目は問題の先取りをしましょうということですね。
プロジェクトで何が問題になるかという予測する方法を出しましょう。
完全に避けることはできないかもしれませんが、見積もりに反映させることはもちろん可能です。
ちょっと現時点で4つ目読んだまででわかりますけど、
基本的にはビジネス観点でのコミュニケーションを学んでくださいという風に集約される気はしますね。
はい、余談でした。じゃあ5つ目いきましょう。
5つ目は信頼に足る見積もりを出しましょう。
見積もりがいつも変わるようでは信頼されません。
なぜ見積もりが変わるのかその原因を探り、先手を打つ方法を身につけましょう。
いや見積もりは変わりますよ。
見積もりってぶっちゃけると単なる未来予想でしかないので、
どこまで見積もりの正確性を出すかって結構難しいですよね。
また見積もる人によって見積もる工数って全然違ったりしますからね。
もちろん自分自身でのエンジニアリングのパフォーマンスとかベロシティーがわかっていて、
自分自身に対しての精度高い見積もりを出せるんだったらわかりますけど、
でもそれは人によって待ちましたので見積もりの話題は結構難しいんですよね。
本当に未来予想でしかないので。
どこまでそこに信頼性を保つかというのは企業の方針によって変わるかもしれないですけどね。
でもなるべくはその信頼に至る見積もりを出せるので、
できればその見積もりの精度を高く持ってもらえるための説得材料まで一緒に考えておくといいんじゃないかなと思ったりはしました。
そのための選定を打つ方法を身に付けておくのも大体いいと思いますね。
続いて言いましょう。6つ目ですね。
6つ目はプロジェクトの真のスコープが何であるかを知りましょう。
ストーリーポイントから離れてプロジェクトが何を達成する必要があるのかを理解します。
目標が明確であれば何がスコープで何がスコープ外なのかというのを交渉するのにも役立ちます。
ちゃんと本質を毎回見ていきましょうということですね。
このプロダクトを作りたいとかこのシステムを作りたいと会社もしくはクライアントが言ってたとしても、
本当にビジネス解決になるものはその本当にプロダクト開発なのかというところはちゃんと本数を問うことは大事だと思いますね。
プロダクトになったとしてもこの機能が本当にユーザーのためのことになっているのかとか、
反則につながっていくのかみたいな1個1個全て本質が何なのかというのを見極めていくのはすごく大事なことだと思ったりしましたね。
その上でこのスコープは今回のプロジェクトの中に入るのか、
いやこれスコープ外にしてもいいんじゃないかみたいなところの交渉材料にするのはいい話だなと思いました。
続いて7つ目ですね。
7つ目はビジネスのタイムラインを理解しましょうということですね。
ステークホルダーがプロジェクトにどれくらいの時間がかかるかというのを予想しているかを確認しましょう。
06:00
あなたが出した見積もりと同じとは限りませんし、大体基本的にはミスマッチャーと思いますね。
続いて8つ目です。
8つ目はチームの改善というのを支援しましょう。
チームを率いているのであれば彼らがスキル不足のために進歩できていないということを認識するようにしましょうと。
あなたのチームはいつも明確に助けると求めてくるわけではありません。
そうだよね、エンジニアとかチームメンバー側からヘルプを出すとは限らないし、
ずっと熱中していたり詰まっていたりすると意外とヘルプを自分から言ってくることが難しいので、
こちらからアクセスするというのも結構大事かもしれないですね。
もしくはヘルプを出しやすいようなチームの関係地づくりだったりとか仕組みづくりをするのもいいかもしれないですね。
例えばうちの会社では、たまに見ましたけど最近は見なくなったんですけど、
例えば17時くらいにスラックで自動的にリマインダーが立ち上がって何か相談とかヘルプある人というのを立ち上がって、
そこにそのチーム内で何か課題とか相談したいことがある人はスレッドに書き込むんですね。
そのスレッドを見てチーム内のメンバーは自由にコメントしたりそのままハドルをつないだりするみたいな、
何時に定期的にヘルプを聞くみたいな仕組みをしているというチームもあったりしましたね。
これ結構面白かったですね。
そういう意味で雑談の場も生まれたりしてコミュニケーション活性化してよかったなと思ったりしますので、参考まで。
では続いて、何個目でしたっけ?もう忘れました。ごめんなさい。
続いては他のエンジニアにやり方を教えましょうということですね。
その方が早いからという理由で自分でやるだけではいけません。
他のエンジニアが成長するために重要なことを学ぶ、そういう機会を作るためにより多くの時間を取ることを許可しましょうと。
この余分な時間を見積もりにもちゃんとしっかり反映させましょうということですね。
ノグハウだったりやり方っていうのを知見を他に共有することでチーム全体の向上とかパフォーマンス改善につながるということですね。
では続いて、設計に協力しましょうということですね。
デザインは重要な詳細レベルを持つことは実はありません。
UXの問題にぶつかったらいろんなチームメンバーと協力して解決策を考えましょう。
Mockを増やせるだけというわけではいけませんと。
自分が作っているものの詳細を把握しましょう。
これもう本当その通りって感じですね。
続きまして、技術的な提案に適切な判断を下すということですね。
システムの能力について何が妥当で何が妥当でないかっていうのを学びましょう。
API呼び出しに10秒かかるならばそれはおそらく修正されるべきでしょう。
べきでしょうというか必ず修正してください。
10秒かかったら遅すぎますね。
まあ例えばの例ですけど。
もしくはウェブブラウザーに100万行読み込むという要件があればいい。
それを恐らく実現不可能です。
そんなデカすぎるソースコードはやばいと思います。
では続いて、他のチームをイライラさせるバグっていうのを修正しましょう。
優先順位がつくのを待つ必要はありません。
もしバグがサポートチームのストレスになっているのであればさっさと直してしまいましょう。
そしてそのバグを直したことを自分の手柄にしましょう。
これいいですね。
自分の手柄っていうのをしっかり自分でアピールするっていうのは実はエンジニア、
特に主語大きいけど日本のエンジニアはそういうムーブをしがちなんですけど、
09:00
ちゃんと自分の成果というかやったことっていうことを認識して主張するときは全然主張していいと思いますね。
振り返り会とかフィードバック会あると思うのでそこでしっかり言うのは大事だと思いました。
他のメンバーの手助けをするためのバグを修正するのは
優先順位があったとしてもなるべく優先して進んでやったほうがいいなと思ったりしますね。
結果的に他のメンバーの環境改善というか、
こういうイライラがなくされるのであれば絶対パフォーマンス上がるはずなんでね。
では続いて、ビジネスを学びましょうということです。
戦略に関するオールハンドやその他の大きな会議では注意を払うようにしましょう。
それはあなたの仕事に影響を与えます。
誰かが説明してくれるのを待つ必要はありません。
では続いて、戦略を学ぶということです。
戦略目標について人に尋ね、自分の仕事との関連性を積極的に引き出しましょう。
で、ラスト。
以上10何個ですかね、読んできましたけど、
やっぱりなんだかんだあれですね、
プロジェクトで動くこととかチームで動くこと、
そしてビジネス観点で意思決定をすることみたいなところにやっぱり集約されましたね。
っていうのがマネージャーがエンジニアに求めるアドバイスだそうですね。
ここを読むだけだと結構日本のマネージャーと言ってることが似てくるなって感じがしましたね。
で、マネージャーって言うけどこれ多分、
本来マネージャーって海外の意味だと役員レベルのことを確かマネージャーって言いますよね。
日本人だと結構プロジェクトのマネージャーのことを言ったりしますけど、
本来のマネージャーは役員だった気がするんで、
確かに経営支店のお話だなっていう気はちょっと聞いて読んでて思いました。
はい、では続けていきましょう。
このリストが全てではもちろんありませんけど、
これを人に話すと大きくうなずいてくれる人がたくさんいます。
上級のようなエンジニアは大抵誰もが一緒に働きたいと思うような人たちでもあります。
まあそうでしょうね。
そんな上級のリストが達成されてるエンジニアがいたらそりゃすぐ雇いたいですね。
このような人たちは称賛されるだけではなく、昇進や昇給にもつながるのです。
このようなことは技術的なスキルの向上とは別の話です。
私はどのレベルのエンジニアでも、
これらのことに集中することで成功を収めることができるというふうに信じています。
もちろん上級者だけでありません。
これらはインパクトを生み出すのに役立つスキルや行動であって、
さらに重要なのはそれに対する評価を得ることになります。
同時にこのリストが人によっては大変なものに思えるかもしれないということは認めたいと思います。
特にキャリアが浅いエンジニアはこれを達成するのは結構難しいと。
なんですけどすぐに達成しなければならないチェックリストとみなすべきでももちろんないですよ。
目標でいいですってことですね。
私はこれらの行動を身につけるのに20年近くの経験を必要としました。
私の目標はこれらの行動を明確に示すことで、
少なくともあなたがこれについて考え、
上司や他の場所から受けたフィードバックと照らし合わせることができるようにすることです。
またこの議事が時間をかけて人々に気づきを与えるための参考資料となれば幸いです。
マネージャーの帽子を脱ぐ前に、このコインの裏側についても話しておきたいと思います。
マネージャーではなくPRエンジニアとしてこの話をしたときも、
人々はこのアドバイスを受けられない、もしくは受けようとしない様々な理由を聞いてきましたと。
そのうちのいくつかは私も共有したいとも言います。
これは誰かを批判したり、おとしめたりするためのものではありません。
12:04
しかし、私は人々がより良い仕事をするために苦労する理由をもっと正直に評価することを推進する一員になりたいと思います。
以下は私が得た回答の一部になります。
これらが現場エンジニアレベルの方のご意見だそうです。
こちらもいくつかあります。
まず一つ目です。
どうすればいいのかわからないというのがまず一つ目です。
スキルを身につける必要があるのに、自分をレベルアップさせる方法を見つけられていない。
上記の過剰書きはそれぞれおそらくブログの記事として詳細を書くことができるでしょう。
これがまず一つ目。
次に二つ目です。
自分ではそう思っていた。
自分を評価したりフィードバックが返ってきたりするのが苦手な人もいますよということですね。
やっぱりベクトルが自分に向いていたりスコープが自分で通してしまっているご意見ですね。
続いて、私はXのためにそれを行うことはできません。
責任転嫁が多い方だと言っていますね。
ダメなプロジェクトマネジャー、リーダーからの矛盾したメッセージが多すぎるとこういうことが多くなるということですね。
四つ目。
伝えようとしても聞いてもらえない。
これつらいですね。
責任との適切な関係作りに結局苦労しているというメンバーもいたりします。
続いて五つ目。
会議なので忙しすぎるという話です。
自分の時間をコントロールできないというふうに感じているというメンバーがいると。
これもよくありますよね。
自分でやらなければ終わらないというふうに思っている人ですね。
技術的な仕事の大きな部分もその方が楽しいからと自分のために噛み砕いたり同僚を信頼しないという人もいたりしますよということですね。
続いて、他に担当することが多すぎると。
優先順位が高すぎて圧倒されます。文脈の切り替えもうまくいかないような人かもしれないということですね。
続いて、それは重要ではないというふうに思っていると。
傲慢で他の人にとって何が重要なのかよく理解しないというメンバーはこういう意見を言うということですね。
ラスト。
それは他の人の仕事だと。
主役になることの意味を理解しないというご意見もあったりすることですね。
なるほどですね。
結構批判的な意見だなという気はしますけど。
主役するのは結局ベクトルが自分に向いていることですね。
いわゆることに向かっていなくて自分に向かっているということですね。
ことにフォーカスを置いて物事を解決する方に向けば、さっき言った意見は大体解決する気が僕はしますね。
もちろん実際現場のメンバーになるといろんな感情が人間だと出てくるので、やりたくないが正直生まれる可能性ももちろんあるんですけど、とはいえですよね。
以上、このような場合ですね。
マネージャーとしての私の目標は、彼らが経験している障害を克服するのをサポートし、最終的に私が見たいと思う行動ができるようにすることです。
エンジニアとして私は期待されることは、威圧的ではなく思い出させてくれるマネージャーを高く評価しています。
私はエンジニアとマネージャーが信頼関係を築き、共に成功するための手助けをすることができるという空想的な考えを今でも持っています。
私は両方の役割から学んだことを共有し、そのギャップを埋めるために最善を尽くしたいと思っていますので、この記事は締められておりました。
15:03
ちょっと短いですけどね、参考になれば幸いですし、結構チェックリストのところですね、僕は本当に共感と納得が多いなというところですね。
しっかり言語化されていたのが僕はありがたいと思いました。
また逆にエンジニア側のフィードバックとか、ご意見というところも、割と共感はありますけど、
こういうことをおっしゃるエンジニアの方っていうのは、たぶんどこかで成長の頭持ちが来ると思います。
何のためのエンジニアリング、何のための技術ということを考えると、その先には必ずビジネスが出てくると思いますね。
そのお仕事という意味ではですね。
というところがあるので、そこを考えるとその先ですね、技術の上に乗っかるというよりか、技術をどこに使うという、
いわゆるチームとかコミュニケーションとか経営みたいなところの話の方向に視野を持っていかなきゃいけないなと思っていますので。
技術は技術でもちろん大事なんですよね。
古いレガシーな技術でやっていたらやりたい問題解決もできませんみたいな正直あるので、
両方ともセットではあるんですけど、技術ばっかりに寄らないで、
ちゃんとチームとしてビジネスとしての視点を持っていくっていうのがやっぱり大事だよねっていうのが、
このマネージャーのおっしゃっていることかなというふうに思っていました。
いかがだったでしょうか。
参考になれば幸いですというところで、
今日の朝活はすいません短いですけど終了したいと思います。
一応30分超えましたので。
はい、改めまして今日は、
さつやはさかわさんとだいちさんですね、
ご参加いただきありがとうございました。
ちょっと今日は、
抽象的というか、
マネジメント系のお話だったので、
明日技術的な記事見つけたら読んでいきたいと思っていますので、
ご参加いただければ幸いです。
はい、じゃあ水曜日中日ですね。
お折り返しですけども、
今日も一日頑張っていけたらなと思います。
それでは終了したいと思います。お疲れ様でした。
