見出し画像

マネジメント目線から見た「エンジニアに意識して欲しいこと」

こんにちは。Supershipでインフラエンジニアをしている @kotaです。
去年からプロジェクトマネージャーとしても動くようになり、少し前からは管理職としてグループリーダーになり、数名のエンジニアをマネジメントする立場になりました。

立場が変わって見えてくることが色々あり、そしてそれらは「あー昔の自分はこういうことを求められていたんだろうなー」という内容でした。本記事では、マネジメント目線から見て「エンジニアがどういうことを意識すると円滑にプロジェクトが進むか」をご紹介します。当時自分がどうすべきだったのかを振り返ると共に、同じことで悩んでいる方の助けになれば幸いです。
なお、本記事中の「マネジメント」とは「プロジェクトマネジメント」のことを指しています。

はじめに

「エンジニアに意識してほしいこと9ヶ条」をまとめました。「マネージャーはなんでこんな言っているんだろう?」と思った時に、本記事に参考になる情報があることを願っています。

①自分の立ち位置を把握する

当たり前ですが、マネージャーはプロジェクト全体を見ています。
まずはプロジェクトの概要を把握して自分の立ち位置を確認しましょう。自分がプロジェクトのどこにいるかを意識するだけで、マネージャーとの認識齟齬が減り、作業の品質は向上します。

スクリーンショット 2020-04-05 10.43.54

②関係者がどういう人かを考えてみる

実際のプロジェクトには顧客を含めて多くの人が関わっています。それぞれに思惑があったり、偉い人の一声で決定事項がひっくり返ったりする中で、調整するのがマネージャーの仕事です。
関係者の力量を見極めて、マネージャーと認識を合わせましょう(個人的な意見ですが顧客担当者がイケてるかは特に重要です)

スクリーンショット 2020-04-05 10.54.49

③タスクのゴールを合意する

タスク管理はマネージャーの仕事です。必要なタスクをエンジニアに振っていきます。そしてタスクには必ずその先のゴールがあります。
エンジニアは目先のタスクに集中しがちになりますが、そのタスクのゴールを常に意識し、マネージャーと合意しましょう。また、タスクだけでなく、プロジェクトのゴール/1ヶ月後のゴール/1週間後のゴールを意識すると自身の動き方が明確になります。

スクリーンショット 2020-04-05 10.58.06

④報告内容にQCDを意識する

QCD(Quality/Cost/Delivery)はトレードオフの関係ですが、残念ながら顧客からは全てを求められます。その落とし所を探るのがマネージャーの役割です。
マネージャーと議論できるように可能な限りQCDを定量化しましょう。そうすることでマネージャーが顧客と調整しやすくなります。

スクリーンショット 2020-04-05 11.05.13

⑤自分なりの根拠を持って提案する

タスクには大きく以下の2種類あり、後者の場合、マネージャーは検討結果を聞いて議論したいと考えています。
 ・実行して終わりのタスク
  →仕様の確定している機能の実装や何かの申請など
 ・実現方法を検討しなければいけないタスク
  →パフォーマンス改善やF/Wの選定など

検討結果を報告する時には、自分なりの根拠を持って報告しましょう。マネージャーに決定権はありますが、結論を出すのはエンジニアであるべきです。また、マネージャーは報告に対して質問するので回答を準備しておきましょう(なぜそれを選んだか、他と比べてどう優れているかなど)。

スクリーンショット 2020-04-05 11.08.37

⑥作らずに創る

技術に関して詳しくないマネージャーもいるため、顧客に言われた要件を良く考えずに新機能として実装しようとすることがあります。
新しい機能の追加はスケジュールにも影響するため、実装すれば解決できるとすぐに判断せず、まずは仕組みを変えることで防げないか検討しましょう。

スクリーンショット 2020-04-05 11.20.03

※この言葉は私が前々職で所属していた部署のキャッチフレーズのような言葉です。この言葉の正確な意図は忘れてしまいましたが、私は勝手にこんな感じで解釈しています。

新しい機能を自分で作れば簡単に実現できるが、作ったものには必ずバグがあり、それに対する責任は自分にある。世の中に出回っているもので同様のことを実現できないか、仕組みを変えることでその機能が不要になることはないかをまずは考えることが大切。
新しい機能を作るのではなく、新しい価値を創ろう。

⑦自分の状況をきちんと伝える

マネジメント対象の人が増えると、1人1人の状況をきちんと把握できない場合があります。
自分の状況をきちんと言語化してロジカルに伝えましょう。特にアラートは早めに伝えることが重要です。また、言いにくいかもしれませんが、プライベートが業務に影響しそうな場合も早めの相談が大切です(もちろん内容を伝える必要はありません)

スクリーンショット 2020-04-05 11.21.59

⑧ドキュメントの品質にこだわる

顧客はソースコードよりもドキュメントを見ます。また、作成したドキュメントが顧客内で一人歩きすることもあります。そのため、マネージャーはソースコードよりもドキュメントの品質に拘ります。
ドキュメントを書くのが苦手もしくは嫌いな人もいるかもしれませんが、プログラミングと同じでドキュメンテーションも技術です。正しい知識をつけてさくさくドキュメントを書いていきましょう。

スクリーンショット 2020-04-05 11.23.23

⑨マネージャーを過信しない

マネージャーも人間なので間違えることがあります(マネージャーがポンコツの場合もあります)。
マネージャーに言われたからやるではなく、マネージャーに言われたことは何のためのタスクなのかをきちんと理解してから着手しましょう。さもないと手戻りや作業が無駄になるなどのロスが発生します。

スクリーンショット 2020-04-05 11.25.03

まとめ

マネジメント目線から見たエンジニアに意識して欲しいことを共有しました。目の前のタスクに集中したい気持ちはあると思いますが、まずはプロジェクトの全体を意識することを心がけましょう。

また、マネージャーや顧客と目線を合わせることも大事です。関係者が何を考えているかを常に意識することで、いわゆる「顧客が本当に欲しかったもの」が見えてくる可能性が高まります。

とはいえ、マネージャーも人間なので間違えることもあります。マネージャーが言ったからやるのではなく、なぜこれが必要なのかを意識することを心がけましょう。

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

13

この記事が入っているマガジン

Supership DSS テックマガジン
Supership DSS テックマガジン
  • 22本

とあるエンジニア部署による勉強会で発表したコンテンツをnote記事としてまとめました。

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。