【書評】「エンジニア向けマネジメントのバイブル本」新卒から経営層まで全エンジニアにオススメ

コンニチハ、千葉です。

コンピュータ技術専門のO'Reillyから、めずらしくマネジメントの本が出版されています。「エンジニアのためのマネジメントキャリアパス」 そして、なんと表紙が動物ではありません。衝撃です。気になりますよね？これは読むしかないですよね？読んだので書評をお届けします。 IT業界の管理職に求められるスキルを解説する本となります。

新卒(上司からの管理のされ方)、現在マネジメント(テックリードから経営まで)やられてる方、逆にマネジメントではなくプロフェッショナルを目指してる方含め、すべての方に読んでいただきたい本です。 この本は、インターンのメンターから、テックリード、課長、部長、経営層までをカバーしていて、ステージによってどんなスキルが必要かがわかる本です。それぞれのステージで質問票(診断表)がまとまってるので、できてる・できてないなどの振り返りにも使えます。質問票だけ読むだけでも、かなり役立つと思います。

はじめに

マネジメントって難しいですよね。マネジメントの対象が、ヒト(個人、チーム、組織、文化)・モノ・カネがあり、そしてそれは全て生きています。生き物です。なので、組織、会社によっても個性があります。この場合はこれというパターンがある程度あると思いますが、必ず柔軟なチューニングが必要になります。正解がありません。そう、ふわっとしているし、悩みが多いですし、私も毎日悩んで、悩みがない日なんてありませんし、常に悩んでいますし悩みまくりです。ということで、こんな悩みの方にオススメです。

• 上司にやたらマネジメントやらない？言われるけど、マネジメントの仕事が何かよくわからない(たぶんあなたは才能の持ち主です)
• 上司が何やってるか知りたい、よくわからない、助けたい(たぶんあなたは才能の持ち主です)
• マネジメントをふわっと自力でやっている
• マネジメントステージによって、どのスキルが必要なのか知りたい
• 今の自分がどのステージのマネジメントを担当しているか知りたい
• 次のステージのマネジメントスキルがどのようなものか知りたい

悩み多いんですが、私はこの仕事はすごく楽しいですし、エキサイティングです。マネジメントに必要なのはビジョンと情熱と覚悟と行動力なんじゃないかなと最近思います。お客様にもっといいサービス提供したい、メンバーのキャリアのサポートしたいなどなど。

ということで、私なりの視点も混ぜつつ、書評をお届けします。

書籍情報

著者、翻訳

著者：Camille Fournier 翻訳：武舎 広幸、武舎 るみ　訳 まえがき：及川 卓也

目次

• 1章　マネジメントの基本
• 2章　メンタリング
• 3章　テックリード
• 4章　人の管理
• 5章　チームの管理
• 6章　複数チームの管理
• 7章　複数の管理者の管理
• 8章　経営幹部
• 9章　文化の構築
• 10章　まとめ

1章　マネジメントの基本

「できる上司」がどういうものか、ご存知ですか。

あなたの「できる上司」のイメージはどんなものでしょうか？会社に入社すると、必ず上司がいるはずです。師匠と呼べる人、または反面教師の場合もあるかもしれません。現在上司がいる方(とくに新卒)向けの章で「上司に何を求めると良いか」という内容が書かれています。 上司は1on1、フィードバックと指導、トレーニングとキャリアアップなどを行う人。仕事面において頼れる相談役なのかもしれませんね。

2章　メンタリング

エンジニアの多くは非公式な形で「人の管理」を初めて体験します

まずマネジメントの最初のステップ、メンタリングについて書かれています。インターン、新卒、新入社員などへ仕事上のサポートや、精神的なサポートを行う機会があると思います。メンターになった場合どうすればいいか、心得、またどんなスキルが必要かが記載されています。聴講スキル、伝達スキル、調整スキルなどなど。また、気をつけないといけないポイントも書かれています。恐怖のカルチャーを生まないようにするにはどうすればよいかです。過去に私もやってしまったことがあり、とてつもなく反省しています。うまくいかなかったしマジでよくない。メンタリングやる方は是非読んで欲しいです。

3章　テックリード

テックリードとはプロジェクトに携わるエンジニアチームの「技術上のリーダー」のことです。

業界共通の定義がないので、組織ごとに職責、役割が変わってくると思いますが、複雑な機能をコード化できるだけではなく、プロジェクト管理やチームの代表としての役割も求められます。技術チームのリーダーと考えて良いでしょう。そして、筆者が明文化したテックリードの定義が載っており、とても参考になると思います。会社によってチューニングすべきだと思うので、あくまで参考としてください。

一文で表現した場合の定義も載っていました。

[テックリードとは](ソフトウェアの)開発チームに対する責任を担い、最低でも自身の職務時間の3割はチームと共にコードを書く作業に充てているリーダーのこと。

具体的に何やるの？についての詳細は本を読んでいただきたいですが、技術の仕事とチームリードのバランス感覚が問われる職責かなと思います。技術だけやるのではなく、チームリードだけやるのではなく。

優秀なテックリードとして重要な事項も書かれています。アーキテクチャの理解からチームプレイの大切さを理解していること、技術的な意思決定、コミュニケーション力が必要などです。

4章　人の管理

管理者になりたての適応期間に重点的に取り組むべき課題として「自分なりの管理スタイルを見つけること」

管理職になったとして、それはゴールではなく、管理の入門レベルに到達したと理解するべきと書かれています。みんなで面を食らいましょう。 管理職になりたてのあなたは、「自分なりの管理スタイルを見つけましょう」と書かれています。 じゃどんなスタイルがあるんだよ？となりますが、メンバーとの信頼関係の構築、コミュニケーションを取りやすくする工夫、1on1のやり方が記載されています。一番チームやメンバーのことを考える人がなるべきかなと私は思います。どういうチームであるべきか、メンバーが何をしたいのか、将来何になりたいのかを把握、また勤務評価をどう行うべきか。 日本ではあまりないと思いますが、成績不振になった場合の解雇の場面でどう立ち振る舞うかというところまでカバーされています。

会社は人で運営されており、人の成長が会社の成長にもつながる、人の成長は人生をサポートすることにもつながると思っています。とてもやりがいがあり、重要な仕事だと私は思います。

5章　チームの管理

「チーム全体の責任を負う管理者」になり、メンバーからの職務内容とはガラリと変わります。

この章ではエンジニアとしての現場の仕事もある程度こなしつつチーム全体を率いてくのに必要な心構えやコツを紹介していきます。

ITスキルの維持をどうするか、チームワークを乱すメンバーをどうするか、メンバーのモチベーション、チーム意思決定のコツなどが書かれています。 (例えばITスキルがない上司とかいやですよね)

管理者はやることがたくさんありますが、チームの存在意義を定義し、課題の把握と、将来の課題が顕著化する前に未然に防いだり、一年先まで見通して計画する必要があります。それに対するコツが書かれています。

6章　複数チームの管理

「あなたはもう(プロダクション)コードをあまり(あるいはまったく)書いていない」という状況です。

だんだん難度がハードモードになります。もはや、直接自分でチームを見ることができなくなってくる規模です。毎日コードを書いている場合ではありません。自部署に限らず、他部署との打ち合わせも増えてきます。打ち合わせばっかりです。ただし、現場感覚を失わないようにする必要があり、そのコツが書いてあります。また、現場の詳細を把握できてない状態で、障害サポートすると邪魔になりかねません。何も知らないのに入ってきて、説明だけにおわれるってのはよくあることだと思います。これはやってはいけません。みたいなことが書いてあります。

また、時間管理手法や、チーム状況の計測方法、権限の委譲もどんどんやっていかないとパンクしてしまいますので、どう考えると良いかのポイントが書いてあります。

7章　複数の管理者の管理

各チームの「健康度」に目を光らせ、各チームの目標設定を支援します。

部下の数が増え、チーム数が増え、自分が今まで経験していない専門分野もスコープに入ってきます。 このレベルまでくると、答えが手の届くところにはありません。管理者としての「成長点」であり、難しい局面となります。

私には実務としてまだ想像ができませんが、以下が解説されています。

• 2ランク以上離れた部下から情報を得るコツ
• 直属の管理者たちに責任を課するコツ
• 新任の管理者、ベテランの監視者を管理するコツ
• 管理者を新たに雇い入れるコツ
• 組織の「機能不全状態」の根を突き止めるコツ
• チーム技術戦略を調整するコツ

私が特に参考になったのが、「管理者を新たに雇い入れるコツ」です。どのような採用基準にするか、採用したはいいもののメンバーに受け入れられないのでは？という不安がありました。ここでは「文化」という基準が書いてあり、とても参考になりました。

8章　経営幹部

経営幹部の日々の職務内容は会社によって大きく異なります。

だんだんと、具体的な定義が難しくなってきます。スタートアップから中小企業、大企業それぞれのフェーズ、業種によってそれぞれやることが変わってきます。が、技術系の幹部が必ず考えるべき内容について書かれています。

• 情報の収集・共有
• 注意喚起
• 意思決定
• ロールモデル(つまり会社の顔であり、みんなが暗黙的に真似る)

また、幹部の役割の一部として以下があげられています。

• R&D
• 技術戦略・ビジョナリー
• 組織化
• 執行
• 技術部門の対外的な「顔」
• 社内の技術インフラとその運用

また、曖昧になりがちな技術バイスプレジデントとCTOの違いについても言及しています。 その中でも私が気をつけたいなと思ったのは、どんどん現場から離れていくので、一言の重みが変わってくるというところです。「これは優先順位かえる」の一言で、現場の人間がたくさん動きます。一生懸命やっていたことが、いきなりなくなったり、こっちやったりと、現場への影響がどんどん大きくなります。どんな判断をしても、必ず裏で動く現場があり、その責任を持っているということは忘れてはいけないなと思いました。

9章　文化の構築

技術系の幹部になると担う職責のひとつが「担当部署の文化の構築」

私が所属するAWS事業本部は、初期のチームメンバーと社長、本部長が作ってきた文化で、それをエンジニアが理解し実践している状況だと思います。エンジニアが楽しくアウトプットし、いらないストレスがない、そして成果に集中できる環境です。 しかし、何もしなくてもずっと続くものではありません。文化からそれそうになることもあります。そのとき社長とか本部長は、そっと出てきて、嫌味なく、かっこいい背中を見せて去っていきます。 (褒めたので何かくださいw)

構成員が、意識しなくても自然に仕事をこなせる、そんな行動原理や行動様式が組織にあれば、それこそがその組織の「文化」である。

フレデリック・ラルー

文化をポリシーとして明文化したり、キャリアラダーを作るためのコツがまとめられています。

10章　まとめ

メンター役から様々な管理者、経営幹部までの職務において、必要なことが「好奇心」と書かれていたのが印象的でした。 それは自分自身のエゴと距離を置くコツだそうです。

最後に

全エンジニアにオススメしたい本です。さぁ、一緒に本を手にとって、私と一緒に悩みましょう！！必ず人生において、いいことがおこるはず！！