foolish::log

@takochuu のブログです。

エンジニアリングマネージャーが考えるべき「戦略・戦術・作戦・兵站」

こんばんちは、たこちゅーです。
今回は良い記事を見つけたので記事に触れつつ、自分の戦略論などについて書いてみたいと思います。

t-and-p.hatenablog.com

見つけた記事はこちらなのですが、「会社で利用している技術要素と自分の経験が全く重なっていないことを転職のブロッカーとしないことを決断をした」というのは結構ハードシングスだよな。と思った。
自分も転職活動をしていた時は、VPoEのオファーやEMのオファーはそこそこの数貰っていたので気持ちはとてもわかるが、やはり「一緒に働いたことがないエンジニアに指導される」というのは指導される側のエンジニアとしては納得感を持ちづらい部分はあると思う。

しかも、マネージメントというものは結局相手の納得感を獲得してはじめてやりたいことができるという職業なので、「マネージャーのやっていることは安心してみていられる」という状態の担保や「あいつは技術以外で自分ができないことをちゃんとやってくれる」と思われるのはとても大事だと思っている。あと、自分のチームを理不尽から守ったりクソみたいな戦略から守ることは大事な役割だ。
自分は「相談したらすぐ返答を返してくれる」ことや「課題を見つけたら殺すまで離さずやるかやらないか決断する」ということを念頭に置いて振る舞っていた。あとみんなでお酒を飲んだりすること。
納得感が醸成できないエグゼクティブやマネジメントが入ってくると「あのおっさんわけわかんねーから無視しようぜ」だったり「何でそれする必要があるんですか?訳がわからんのですが」ということになったりする。
権限を持たない上でのマネジメントとしての動き方はトヨタの中村健也さんがとても優秀だったらしいが、本が見当たらないので読んでみたい。
中村健也 - Wikipedia


ただ、前職からマネジメントをやっていて感じることとしてはエンジニア出身のマネージャーはどうしても技術をどうする、というレイヤに囚われて「技術を改善した結果、プロダクトがどうなるのか」という部分に接続していない事があるなということは感じる。
それは必ずしも悪いことではないが、たとえばエグゼクティブや経営というレイヤで考える事は「技術を利用してどのように会社を市場で成長させるか」ということがメインになるべきだと思う。

そんな状態に自分がなっていた時に良く読んでたのが、UEIの清水さんのこのブログ(魚拓)なんだがとても示唆に富んでいる。
megalodon.jp

マネジメントとして大事なポイントは「戦略(Strategy)、作戦(Operation)、戦術(Tactics)」という形でマクロからミクロに視点が落ちていくということがまず一つ。そして「どう足掻いても戦略や作戦のミスは現場で取り戻すことはできない」ということが2つめ。これをマネジメントする人間はきちんと捉えておく必要がある。
クソみたいな戦略の上で何をやってもうまくいくことはないということだ。

別の視点から戦略が把握できていないことの例を上げると「コードが汚いのでリファクタリングしたい」という現場からの要望があったとする。
だが、該当のコードは「ここ5年は触れられないであろうししっかりと動作している。かつ疎結合である」という場合、経営目線では「何でそれ今やるんだっけ?」ということになる。新卒が大体「やりたいことができない」とか言ってくるのは大体これだ。会社のやるべきことの芯を食っていないから弾かれる。
ただ、これは大きい会社になればなるほど「どんな戦略で会社が動くのか」というのは抽象的になりメンバーが理解することは難しくなるため、ある程度仕方がない事だ。

それをマネジメントとして防ぐためには、これからやることがどういう意味を持つのか、それがどのように会社の成功につながるのかというのを徹底的に考え、言語化することで会社が持つ戦略に対して、現場が担当する戦術を接続させるというのがCEO以外のミドルマネジメントに必要だ。
そしてこれは体感的な話にはなるがエンジニア出身のマネジメント層が苦手な分野なのではないかと思っている。
記事中ではつまり「労働者として卓越していたが故に、経営というより困難な仕事からの逃げ場としての労働に走ることをやめられない」という言葉で表現されている通りのことは見たことがある。
普段コードを書いてスケーラビリティを表現することに長けているはずのエンジニアが、マネジメント領域において母語を使っても「それがなぜそうであるべきなのか」を説明できている事がそれほど多くないのは結構驚くべき状態だと思う。

f:id:takochu27:20210703115736p:plain
この図が出てくる部分で語られていることだが、会社の大部分は兵站で構成されている。
もちろんエンジニアも兵站の一部だし、その上司であるマネージャーは「限られた戦力で最大限の成果を発揮するためには現状の兵站をどのように配分し、調達するのか」というのは使命の一つになるし、それができないマネジメントは兵站たるエンジニアを幸せにすることは不可能だと思っている。だってやっていることが会社にインパクトを与えたのか言語化して説明することができないからだ。

ではどのように兵站管理を行えばいいのか、という部分ついてはやはり王道がある。
では王道とは何か、といえば「プロジェクトマネジメント」になるはずだと考えている。
例えばPMBOKCCPMクリティカルチェーンマネジメントについては上記の目的を実践することに対して大きな助けになるはずだと感じる。
アジャイル開発、などもその手法の一つだ。
A Guide to the Project Management Body of Knowledge (PMBOK® Guide)–Sixth Edition (JAPANESE) | | プロジェクト管理 | Kindleストア | Amazon
アジャイルCCPM: プロジェクトのマネジメントを少し変えて組織全体のパフォーマンスを大きくのばす | 宇治川浩一 | プロジェクト管理 | Kindleストア | Amazon
ザ・ゴール | エリヤフ ゴールドラット, 三本木 亮, 稲垣 公夫 | 英米の小説・文芸 | Kindleストア | Amazon
Amazon.co.jp: アジャイルサムライ

ここまで書いてきて「じゃあお前はどんな状況でもこういうことができるの?」と言われるともちろんそんなことはないのだけれど、兵站管理自体はそれこそシンプルな話ではないので全ての状況にフィットする方法論を持っているわけではないが、いくつかは学んできたなとは思う。

ここまで書いてきて結局何が言いたいのか、ということは「全てのマネージャーはきちんと部下を幸せにしてやろうな」ということと「マネージャーとして部下を幸せにするためには方法論が必要だと思うよ」ってことです。

こういう面倒臭い話をできる友達を募集していますので @takochuu までDMくださいw
アディオス!