書籍「エンジニアのためのマネジメントキャリアパス」(Camille Fournier著、武舎 広幸、武舎 るみ訳、及川 卓也まえがき、オライリージャパン発行)を読んだ。

私は一介のジュニアエンジニアで、今はシニアと呼ばれるような能力を身につけることを目指しており、マネジメントのキャリアを主軸に考えているわけではない。ただ、組織に対する視座や解像度が低いと感じることがあり、将来マネジメントのキャリアを拒んでいるわけではないので、気になってこの本を読んでみた。

この本は、いちメンバーから上級のマネジメント職位に、順を追って話が進む。最初は自分自身が管理される側としてどのようにあるべきか、インターンのメンターに関する話題が取り扱われているので、自分のようなものも読んで得るものがあった。後半の高い職位に関する説明は「そういうふうにやっているのね」というのを俯瞰して流し読みしたという感じで、すぐに自分の知識として生かせるようなものではないが、解像度を読む前よりも多少高めるのに役だったと思う。

これ以降は、本を読んで気になったところを、フレーズと共にいくつかピックアップして紹介する。

部下としての心得

第1章「マネジメントの基本」のなかで、マネジメントをするまえに、マネジメントをどうされるべきか、どのような立ち振る舞いが部下に求められているか/マネジメントがしやすいものかが説明されている。

上司に求めることの第1ですが、それは「1対1で行うミーティング(以下「1-1」」です。 p2

上司に求めることの第2は「フィードバックの提供」です。 p4

自分自身が何を望んでいるのか、何を学びたいのか、何が自分を幸せにするのかを考え抜いて明らかにする責任はひとえにあなた自身が負っているのです。 p9

似たような話はあとがきにも書かれている。

人の管理がうまくなりたければ、自分自身を管理できるようにならなければならない。 p279

本を読んだ中で、説明されている職位と自分の職位が最も一致する章だと思うが、自分自身が上長とどのようにやっていくべきかというのを改めて振り返る機会になった。1on1を、自分と上長の双方のより有意義なものにしていくために、自分が望んでいることを明確にし、そのために必要なことと現状を照らし合わせてフィードバックを得たり、それらを考えるための補助を求める、という行為をあらためて整理してやっていきたい。

メンターとしての傾聴

第2章「メンタリング」では、インターンやメンターのメンターとしての務めが書かれている。特に、メンターには傾聴が求められているとして、そのうえで以下のように触れられている。

「傾聴」とは、指導相手が「口にする言葉だけを耳でとらえる行為」ではないこと。 p17

メンターとしての役割を果たす時は(もっと言うと実際それに限らず人とコミュニケーションするときは)、メンティーの些細なしぐさや表情も含めて、相手が何をどのように考えているかを汲み取ってコミュニケーションしていく必要がある。

上記の点を含め、メンターとしてどういうことが求められているかが文章としていくつかの項目で示されていることはとてもありがたい。自分がサポートを受ける立場のときどうであったか、自分がサポートをしたときどうであったか、これからサポートのための準備やサポートをしていく上でどうするべきであるか、というのを見つめ直すことができる。

テックリードに求められるプロジェクト管理のスキル

第3章「テックリード」では、エンジニアチームの技術上のリーダーとしてどのように立ち振る舞うかが説明されている。そのなかの一つの「プロジェクトの管理」についての説明は以下のようなものだ。

プロれジェクト管理に必須である「プロジェクトを分割する作業」には、システムを設計する作業との類似点が多々あるため、プロジェクト管理のスキルを習得するという経験は、人的管理を任されることを望んでいないエンジニアにとっても有意義であるはずです。p38

テックリードが最優勢んしなければならないのは「プロジェクトを推進するための対極的な視点を失わないこと」です。p41

テックリードの果たすべきプロジェクトプランナーとしての役割は「作業をデリバリ可能な単位におおまかに分割する」というものです。p42

企業としてソフトウェアを開発していくには、長いプロジェクトを俯瞰して、ある程度の進め方やスケジュールの算段が必要になる。

普段の開発は、アジャイルやスクラムの枠組みの中で、設計し、作業を見積もり可能な粒度に分割し、見積もって、優先順位順に並べ替え、ベロシティを元にして、現時点でどれくらいかかるかなどがわかるように仕事を進める。

とはいっても、そういう見積もりがすぐにはできないような先の見通しづらいプロジェクトや、年単位のプロジェクトの計画や管理、まだやるとは確実には決まっていない粒度の大きいプロジェクトの検討材料を集めるなどの仕事も必要で、それらは「見積もり」してやるわけにはいかない。

テックリードといわれる職位の人が、そういったことに直面し、それをうまくやる術を仕事の中で身につけていっているということが説明されており、なるほどという気持ちになった。(つまり実際の方法は、本の中には書いていない。本の中で書き切れるような単純なものではないかもしれないのだろう。)

文化の構築

このの最後の章は「文化の構築」となっていて、この章も気になった。 文化を形作る上で、意思決定のプロセスから個人的要素を排除するための具体的な方法に、ポストモーテムやアーキテクチャレビューを挙げており、それらを実践する上でのアドバイスが示されていた。

事後検証の成果は、現実的な視点で取捨選択する p276

問題が起きた時のポストモーテムに対する実践的なアドバイスの一つに、上記の事柄が紹介されている。起こった問題を完璧に解消できればいいが、現実にはそんなに暇ではないし、解決策が無限に時間のかかるような非現実的なものであれば形骸化してしまう。ポストモーテムが血の通ったものとなるために、現実的な視点で、効果的な次のアクションを定めていく必要がある。

アーキテクチャレビューの価値は、その準備段階にある p277

言語やフレームワークストレージシステムやデベロッパーツールなど、システムやツールの大きな変更に対して行うべき「アーキテクチャレビュー」の実施方針のアドバイスとして、準備段階の重要性が求められている。 アーキテクチャレビューに限らず、誰かに説明して納得してもらうために、それを言語化して資料にまとめることは、その行為自体が自身のセルフレビューの一つになりうるし、準備段階が重要であることは納得がいく。

ポストモーテムやアーキテクチャレビューに関する説明を読むことが、自分の会社の類似の事柄について、自分が取り組む上での実践的なコツのほかに、それらが企業においてどのような立ち位置でどうして重要とされているのか、そのしくみが用意されているのかを考えることのヒントとなった。

以上。