はっきり言おうか、僕は今酔っている。
お気に入りのクラフトビールが手に入ってですね。

酔いなくしてこんな狂ったタイトルのブログが書けるだろうか？
いや、書けない。

エンジニアリングマネージャーとしてのスキルに関しては、何万人もの先人が何千時間とかけて、こんなタイトルのもっと価値あるブログを書き殴っている。

はっきり言おう、こんなブログを読む時間があるなら、トムデマルコの著作でも読むべきだ。

さて、はじめようか。

1. 自分の凡庸さへの理解

神は君を選んじゃいないし、世界は君を中心に回っちゃいない。

エンジニアリングマネージャーがエンジニアの上位職だったりする職場もあるかもしれないけど、基本的に君は無力だ。
自分の得意な領域は、そりゃ君がやったほうが早いだろう。

んなこたわかってるんだよ。

君がやらなきゃいけないのは、今まで君がやってこなかったことだ。
人にお願いし、調整し、やってもらう。
上手く行かないことを、上手くいくようにしていくことに全力を捧げる。

だから基本的に君は上手く行かない。
ほとんどのことで失敗する。

成功しているのなら、それは多分真面目に仕事をしてないからだ。
失敗してからが仕事だ。

さて、やってやろうじゃないか。

2. 問題の構造化

うわー。やだなー。
って思った時は大体問題がでかい。

そんな時は、急がず焦らず、向き合って問題を分割しよう。
確かに、もうやめたいよね。わかる。

お茶でも飲みながらじっくりとドキュメントでも読もう。
すると見えてくるんじゃないかな。
問題と問題の境界が。

難しいことは、ポリアの「いかにして問題をとくか」を読んでくれ

問題に切り込みを入れて、分割し、問題の構造を把握するんだ。
可能なら図をかこう。

テキストエディタだけで戦うな
ホワイトボードやらメモなどを総動員するんだ。

構造さえ把握すれば、なんかわかった気になれる。
あとは実行し、確かめる、確かめる、確かめる！！

3. 並列処理と並行処理

最高のエンジニアが何人かいればプロジェクトは成功すると思っていると思う。
そう、最高のエンジニアがいればね。

はっきり言おうか、最高のエンジニアなんて存在しない。
(って思っておいたほうがいい)
とりあえず、マネーボールでも観にいくのをお勧めする。

さて、ここで言いたいのはそういう話じゃない。

共通の概念は何か。
万能な人を配置するか。
専門領域を持った専門家を配置するか。
同じ仕事を何人かでするか。
別々の仕事を何人かでするか。

時に君はエンジニア組織のOSみたいな仕事をしないといけない。
常に効率は君を追いかけてくる。

コンピュータ科学は効率に関する部分が非常に多い。
コンピュータ科学を学習し、計算論的思考を手に入れた君にとって、効率的に仕事を進めることは容易なはずだ。

4. 全体を把握する能力

なんで全体を見ようとしない？
は？見ようとしないんじゃない。見えないんだ。

そう、全体なんてものは幻想だ。
見ようとしたって見えるものじゃない。
それでも見ようとするんだ。その活動が重要だ。

一緒に働いている異業種の話をきけ。
君が君の組織のエコシステムのどこに配置しているのかよく見てみるべきなんだ。

君がエンジニアでマネージャーなんてのはただの名札だ。
名札に意味なんてない。
大事なのは物事を成功させる力があるかどうかだ。

一つのことを上手くやるためには、時には越境して行かないといけないこともある。

もし君が、君の視点だけに拘っているならば、もし君が君の立場だけに拘っているなら、歯車は上手く噛み合わないかもしれない。

全てを把握するように努力し、必要なことは全てやれ。
上手くいくことが重要で、誰も君がエンジニアリングマネージャーであることなんて気にしてない。

失敗して、誰かのせいにしたいか？
成功して、高笑いしたいか？

どっちか決めるのは君自身だ。

5. 優先順位づけ

思いついた順に思いついたことから手を付けるな。
本当に緊急なのは何か、本当に重要なのは何か。
いつもそれを考え続けたほうがいい。

今は不急不要では外出すら許されない世の中だ。

僕らの意志は本当に弱い。
ふと気づくと、いつもと同じ、やり慣れたタスクを、youtubeでも見ながらやってるんじゃないか。

本能は僕らに語りかける
「このままここにいたら良いじゃないか」
惑わされるな。

僕たちはここにいるべきじゃないし、未知に踏み込むべきだ。
不確実なことから挑み、不確実性を減らしていくべきなんだ。

さあ、よく考えろ。
今何をやるべきで、何をやるべきでないのか。
君のプロジェクトは、君の今日の行いで成否が決まると考えろ。

6. 体制を作る

仕事は結局は実行力だ。
綿密なプランも実行がなければ、あっという間に競合が追い抜いていくだろう。

すでにコードを書かなくなった君にできることはなんだ？

ここまで君は問題を理解し、何をどんな順番でやればいいか、考えてきた。
で？どうする？

実行するのはエンジニアだ。
エンジニアに精神論を求めるな。
粛々と開発を行い、一歩一歩成功に進め。

兵站を考えない戦略なんてあり得ないだろう？
面倒くさいからって、自律した組織ってやつに逃げるなよ。

君もまた、組織の一員だ。君が考え抜ければ、それは組織が自律してるいる証になる。

脳味噌を使え。
どうしたら、不可能を可能に変えられる体制を作れるか。
きっと、君は自分の境界を越えて行かないといけない。

君が1人目としてボーダーを超えるんだ。
兵站を計画しなかった日本軍がどうなったか知ってるかい？

7.思いやり

はっきり言おう、エンジニアリングマネージャーの仕事のほとんどは、不安の解消だ。

開発プロジェクトは、不安をいかにコントロールするかの戦いだ。
君が知っていようが知っていまいが、プロジェクトとは、少なくとも、過去に構築したことのないものを構築することだ。
もしも、君が過去にやったことがあることを、何度も繰り返すなら、それはプロセスというのだ。

僕たちは未知に弱い。
未知は僕たちを、不安という闇に閉じ込める。不安はあっという間に僕らを支配し、プロジェクトの進行を妨げる。

エンジニアリングマネージャである君は、勇気を不絞り、メンバーを勇気づけ、組織し、一筋の光明が見つかるまで、根気よく前に進まなければならない。

いいかい、人間は意志を持っている。僕たちエンジニアリングマネージャーは意志を持った人間とともに、エンジニアリングを行う。

人を道具のように使うなよ。

君にできるのは誠意を持ったお願いと、自分が一番危険で面倒くさい部分を受け持つことだけだ。

エンジニアは、君という人間についてくる。
仕事や金じゃない。わかるかい？

君は君自身が背中を預けられる人間か？
死戦を彷徨った時、君は仲間を励ますことができるかい？

君の仲間にも、家族がいて、各々の生活がある。
体調がいい日もあるし、悪い日もある。
持病を持ってる人もいるし、病気がちな家族を持ってる人もいる。

もしこんなことも理解できないで、うまくいかないことを仲間の誰かのせいにしてるなら、エンジニアリングマネージャーなんてやめてしまえ。