マネージャーじゃないけどマネジメントについて悩むことが増え、そしてロールモデルをみつけた
中堅エンジニアのリチャードです。私はマネージャーではなく、過去に部下を持ったこともがないのですが、近年はマネジメントについてよく悩むようになりました。よく悩んでいたところ最近出会ったPodcastやブログを通して考えを整理するきっかけができたので、それを紹介します。
この記事中でいうマネジメント力は「人や組織に働きかけて成果を出す能力」と考えています。反対に技術力はエンジニアとして、主に「コンピュータを扱って成果を出す能力」を指しています。
考え方の変遷
多くの血気盛んなエンジニアがそうであるように、若い頃は私もソフトウェア開発の技術力一本で勝負したいと強く思っていました。コンピュータは人間よりもはるかに大きな計算力を持つので、それを駆使して成果を出すのがカッコイイと思っていましたし、優れたソースコードを書くと同時に企業の利益に貢献するエンジニア個人が偉いのだと思っていました。
そのため組織全体や会社全体を考えるような概念には疎く、企業が掲げるミッション・ビジョンのような大きなことをいう人たちを、うさんくさいと思ってバカにしていました。それより目の前のサービスの品質を上げて利益を出す方が先だろうと。今では昔の自分の姿勢を反省しています、ごめんなさい。
考え方が変わり始めたのは30歳前後くらいからです。一番のきっかけは自分の能力では技術力一本で勝負できないと悟ったからですね。自らの技術力の伸びしろを悟るのは、つらいですが多くの経験豊富な技術者によくある話ではないでしょうか。
さらにマネージャーではないものの様々な活動に関わり、企業理念の社内浸透政策、エンジニア組織づくり、エンジニア採用、技術広報、さらに社外技術コミュニティへの参加を通じて、技術力だけではない様々な能力を要求され、周りの人の協力を得て仕事を前に進める必要性を強く感じたことも、考えを変えた理由です。段々と個人の「技術力」と組織の「マネジメント」が二項対立ではなくて、組み合わせて成果を発揮するものだとわかってきました。
最近ではGoogle re:workを頻繁に読み返してエンジニア採用業務の参考にしたり、ビジネスプロセスの教科書のような本から、業務改善の手法とコミュニケーションを学んでいます。よりソフトウェア開発に近い領域のマネジメントでも、あらためてアジャイル開発やスクラム開発、プロダクトマネジメントといった領域を学び直し、それらの領域に実際の仕事の範囲が広がりつつあります。
対立構造を捉え直す
すっかり考え方をあらためた最近になって出会ったのが、Podcastのfukabori.fmでした。その回は「エンジニア組織論」の著者としても有名な広木大地さんが参加され「やってほしい仕事を伝える対象がコンピュータであっても人であっても同列に見る」という面白い視点が紹介されています。
(20:20からの内容を要約) ソフトウェアは一度書いたら動き続けて、スケールして、コモディティ化していくので、今はバイト100人よりEC2インスタンス100台動かす方がリーズナブルな時代になりました。バイトリーダーやバイトマニュアルを書ける人が求められていたように、今はソフトウェアを書ける人が求められているのですが、ソフトウェアを書く能力に希少価値が高いので特別な能力だと思われてしまっているんですね。でもソフトウェアを動かすのも組織を動かすのも、情報処理装置として統一してとらえられるんじゃないかなと思っています。
(32:45からの内容を要約) 最初コンピュータは科学技術計算、ロケットの弾道計算みたいなものが得意で、徐々に基幹システム、WebシステムやSaaSと、具体的な仕事から抽象的な仕事ができるようになっていきました。コンピュータが具体的なルーティン作業を置き換えていったら、人間にはどんどん抽象的な仕事をするようになんですね。だから、かつて部長職や課長職がいろんな部署と折衝していた役割を、今では一般社員が入社した直後から求められるようになっている感覚です。
コンピュータに指示を出しすためのソースコードを書くという能力と、人にやってほしいことを伝えて協調しあう能力の組み合わせ。両方を時期や環境によってバランスを変えて戦っていけばよいのだ、と気づいてからはすっきりした気分になりました。
ちなみに、別の話として聞いた「パフォーマンスが高い個人ほど、他人からの協力が必要不可欠」という話にも非常に納得して「個人パフォーマンスの高い人たちの典型であるスポーツ選手も、周りの協力が必要不可欠だなー。」と思ったのですが、残念ながらどのポッドキャストか忘れてしまいました。fukabori.fmだったかな…？
そして先日タイムラインに流れてきた、Japan Node.js Association代表の古川陽介さんのスライド。「個人で成果を出す」と「組織を運営し成果を出す」ことの境界はハッキリしておらず、古川さんはどちらも行っていることを紹介しています。
この後しゃべる資料です。（アップロード中） #ECStudy https://t.co/sCkqMOsEju
— Yosuke Furukawa (@yosuke_furukawa) January 19, 2021
一方でmizchiさんのように自分の技術力で押し切るストロングスタイルもあります。
ちょっと経験つんだ人によくある「なんだかんだで最後は組織だよね。組織の問題をみつけてコミットするのが一番」っていうエンジニアにだけはなりたくないと思っており、全ての問題を僕個人のパフォーマンスで殴り倒す所存です
— OSSタダ乗りおじさん (@mizchi) August 1, 2019
ただmizchiさんに関しては、個人の技術力だけで押し切れる能力があるのは疑いようがないですが、実際にそうしているのではなく、人や組織に働きかけて成果を出す能力も高いと予想しています。mizchiさん本人とお話ししたことがないので、想像なんですけどね。
フリーランス時代、インターネットの人格で客が選別されすぎて、仕事に支障が出ていたかもしれない。トラブルを未然に防止できていたかもしれない。
— OSSタダ乗りおじさん (@mizchi) April 12, 2020
技術力とマネジメント力の高度な融合の極致Russ Cox氏
「2軸での勝負」という考えにたどり着いたときに、それをとんでもないレベルで両方持っている人の業績を見てしまいました。Goを始め数々の技術領域で輝くスーパースター中のスーパースター、Russ Cox氏です。最近私がGoに入門したので、Go Modulesを調べていたのですが、Cox氏の貢献の凄さに、大げさではなく本当に声をあげて驚きました。
Goコミュニティでは、ライブラリのバージョン管理にセマンティック・バージョニングがベスト・プラクティスだという合意はあったのですが、バージョン管理ツールの実装としては複数に分かれ、統一された解決策が長年ありませんでした。
Cox氏はRustのCargoなどを念入りに調査し、セマンティック・インポート・バージョンニングという解決のカギとなるアイデアを発見しただけでなく、そのまま最小バージョン選択アルゴリズムを導き出してしまいました。もはやコンピュータ・サイエンスの研究論文か！という内容ですし(Cox氏は当然ながらPh.Dです)、長年Goコミュニティが悩んできた問題を解決する技術力は、世界最高と言って間違いないでしょう。
問題の解法を発見したのみならず、次はコミュニティを説得したうえでGo公式としてModulesを導入する道筋を作らなくてはなりません。とくにセマンティック・インポート・バージョンニングというアイデアは一部コミュニティからの反発が予想されるアイデアでした。Cox氏は自身のブログやGo公式ブログを通じて、自身ですら数年間にわたって悩んだ問題解決までの流れを丁寧な文章で説明し、なぜこの突飛にも思えるアイデアが論理的帰結なのかを説明しました。
A year ago I strongly believed that whether to include version numbers in import paths was largely a matter of taste, and I was skeptical that having them was particularly elegant. But the decision turns out to be a matter not of taste but of logic: import compatibility and semantic versioning together require semantic import versioning. When I realized this, the logical necessity surprised me. The Go Blog - A Proposal for Package Versioning in Go
とくに私が「美しい」とすら感じたのは、以下の記述です。ライブラリのバージョン選択問題を以下の4つのオペレーションの意味に帰着させたところに、ドメインの本質的問題をえぐりだす力を感じます。
The version selection problem therefore is to define the meaning of, and to give algorithms implementing, these four operations on build lists:
- Construct the current build list.
- Upgrade all modules to their latest versions.
- Upgrade one module to a specific newer version.
- Downgrade one module to a specific older version.
Goコミュニティのエンジニアたちは、それぞれ大なり小なり日々ライブラリのバージョン選択問題に向き合っていて、その課題は細かいところまで目を向ければ人それぞれ千差万別です。そして、それぞれのGoエンジニアにとっては「自分が直面するバージョン選択問題の詳細こそが最大の関心事」なのですが、それらから本質をえぐり出し、コミュニティのメンバーに「これは自分の問題に対する解決策だ！」と納得してもらうための文章になっています。
さらにブログでの発表だけでなくGitHubのIssuesなど様々な場所でGoコミュニティと対話し、GoエンジニアたちのGo Modulesへの理解を促していき、ついにGo Modulesはコミュニティから受け入れられ、公式に取り入れられたのです。
「Cox氏の技術力はわかるが、コミュニティの説得はマネジメント力より文章力ではないのか？」と思うかもしれません。しかし、Cox氏の対話の相手は物理的な距離が離れ、数万人かもしくはそれ以上かもしれない世界中のGoエンジニアです。コミュニティがどんな反応をするか、そして反応にどう答えるか？10人やそこらの社内部署とはわけが違う、コミュニティという巨大組織をまとめて導いたことを考えると、そこに働く力学を踏まえてマネジメント力を駆使したと私は捉えています。そして、リモート組織をまとめ上げるマネジメント力には、文字コミュニケーションを行う文章力が必要不可欠な要素として含まれます。
あるいは「それはCox氏が圧倒的に優れた技術力と実績で、世界中のエンジニアからすでに尊敬されていたからうまくいった」という人もいるでしょう。はい、そのとおりだと思います。技術力とマネジメント力を分けて考えなければ、技術力で組織をマネージする、マネジメント力を使って自分の技術的アイデアを組織に浸透させる、という相乗効果を考えられます。むしろそれはエンジニアによるマネジメントの理想形の一つではないでしょうか。技術的に正しい解法であっても、腕力で押し切るような進め方ではなかったことが、Cox氏のマネジメント力の高さの証明です。
わかった
さすがに世界トップのRuss Cox氏を目指すのはムリな話ですし、古川氏もはるか遠くにいる存在です。しかし「技術もマネジメントもやっていく」という延長線のずっとずっと先に、エンジニアとしてのロールモデルが見つかりました。
ここから先は「技術力がイマイチでも、組織で成果を出せばOK」みたいな簡単な話ではなく、片方を捨てるなら一軸の勝負しかできない、少ない武器で戦わなければいけないという厳しい選択の話になります。もちろん、どちらか片方をとる選択もあるでしょう。
私の場合は、一度自分の技術力の限界を知ったわけですが、だからと言って技術力という武器をまるっと投げ捨てるのはなんの得にもなりません。技術分野を絞れば私でも十分戦えるでしょうし、今後何年もソフトウェア開発の技術分野は拡大をつづけると予想できるので、いつか自分に向いた分野が流行る未来が来るでしょう。
せっかくだから「技術とマネジメントの総合力勝負なら絶対勝つし、どちらか片方の勝負でもほとんどの人間に負けない」くらいの意気込みでのぞみたいですね。