”緊急度を上げない”ことが、エンジニア組織のマネジメントの要諦

--

みなさんこんにちは。
チャットボット開発のスタートアップで、エンジニア兼VPoEをやっている福本です。

本日もエンジニア組織におけるマネジメントについて、思ったことを書いていきたいと思います。

世の中には「マネジメントとは何ぞや」みたいな話が溢れていますが、「その正体って何なんだっけ?」というところについて少しだけ考えてみました。

緊急度と重要度

よくあるマトリクス図(文言は個人的にアレンジ)

すごく今更ですが、”緊急度”と”重要度”は、課題やタスクを分類して「今やるべきこと」を見極め、効率よく仕事を進めるやり方です。

とはいえ、明確にプロット(分類)作業を行う人は少なく、何となく脳内でタスクやプロジェクトをプロットしている方が多いのではないでしょうか。

さて、そもそもなぜこんな面倒くさいことを意識しなければならないのかというと、「産業革命以降、仕事が複雑なものになったから」というのが僕の仮説です。

工業、特に単純な製造工程がその中心であった時代は「一日で●●を☓個作る」というのが労働者の仕事であり、階級によって管理する側される側という構造が明確でした。仕事の進みは完成品をひと目見れば把握できるし、仕事の始まりも終わりも誰が見てもわかります。

しかし近代、特に情報革命以降の仕事は複雑さを極め、「何を持って終わりとするか」「うまく進んでいるか」は非常に分かりづらくなりました。

さらに、ソフトウェア産業の時代では、”アジャイル”という言葉に代表されるように「そもそも終わりがない」仕事や、”DevOps”が表すように複数チームの成果レベルでの連携を要する仕事が多くなりました。

このような従来の産業構造の変化が、”緊急度”と”重要度”という単純な2次元での情報整理を難しいものにしていると言えるのではないでしょうか。

なぜ緊急度を上げてはいけないのか

さて、なぜ緊急度を上げてはいけないのかという本題についてですが、「同じ課題に対するアウトプットの精度が落ち、その場しのぎの対応しかできないから」というのが答えです(当たり前ですね)。

それぞれの緊急度が上がった状態

イメージとしては、「明日の大きな会議のアジェンダを急に作らなければならなくなった」とか「大事なエンジニアが”辞める”と言い出して、とりあえず引き止めろ」みたいな状態です。

緊急度を上げないとは

緊急度を上げないイメージ

緊急度を上げないとは、常に「逆算」および「先読み」して、すべてコントロールしている状態です。完璧に計画し準備できている、と言い換えてもいいでしょう。

常に余裕を持っている状態なので、会議の準備もできているし、エンジニアが辞めると言っても、既に次のエンジニアが決まっている…などという以上に、とても良いことがあります。

すべてを左上に叩きこむことができる

ここからが持論なのですが、緊急度を上げないことで右下の領域の一部を「自動化・仕組み化する」というタスクが生まれ、それが左上にプロットされるようになるのではないでしょうか。

それにより「右下のタスクがある程度減少し、さらに右上のタスクの緊急度を下げに掛かれる」という効果があるのではないかと考えています。仕事ではとにかく左上に集中すれば良いのですから、仕事の進め方としてこれほどラクなことはありません。

前提

「緊急度を上げないこと=良いこと」であるための前提として、「しっかりと思考・議論すれば精度の高いアウトプットが出る組織である」ということがあります。

そのため、「そもそも思考を停止しているメンバーが多い」とか「建設的な議論が起きない」という環境に陥っているチームでは、緊急度を下げたところで特に良いことはありません。ちょっとゆっくりできるだけで、結果は変わらないですからね。

緊急度を上げないために

じゃあどうしたらいいんだ、というところで以前のブログを再掲します。エンジニアリングマネージャーは組織のあらゆる事象において、緊急度を上げないために色々な手を打ちます。

記事に飛ぶのが面倒な方のために、図を再掲しておきます。

エンジニアリングマネージャー(VPoE)の仕事をシンプルに表現しました

緊急度を上げないようにする取り組みについては、以下のようなイメージです。相変わらず、やるべきことはたくさんありますね…

・1on1でモチベーションを把握し、ハレーションを防ぐ
・事業の成長や退職を予測して採用計画を立て、進める
・採用コストを下げるため、技術広報で認知度を高める
・組織サイズ増大を見て、必要そうな施策/制度を議論する
・技術広報に困らないようメンバーからネタを仕入れる

偉そうにブログを書いておきながら、僕自身まだ全然実行できてません。
(先読みするの難しい…)

なぜかというと、先読みするのに必要なものが”経験”なのか”論理的思考”なのか、はたまた他にあるのか、その答えがよく分かっていないからです。

この辺は、熟練されたエンジニアリングマネージャーの方とお会いできればぜひ話してみたいと思っています(個人的には「経営層と同じ考えができているか」ではないかと感じてますが、ちょっとイエスマンすぎて賛同しづらい…)。

--

--

福本 晃之 | Teruhisa Fukumoto

Web Developer at Smartround.inc / Computer Science Student at Teikyo Univ / Kotlin(ktor), TypeScript(Vue), Ruby(Rails), Terraform, Python etc...