Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
エンジニアのためのマネジメントキャリアパス

マネジメントの基本

上司に何を求めるか

1対1のミーテイング

上司に求めるべきことの第一は、1on1のミーティング。
1on1 のミーティングには目的は二つある。

  • あなたと上司との間に人間的な「つながり」を作ること
  • 要検討事項について上司と一対一で話し合う定期的な場を設けること

フィードバックと指導

上司に求めるべきことの第二は、フィードバックの提供。
フィードバックはぐずぐずとタイミングを見計らったりせず、その場で即与えたほうが効果的。
上司からもらえると助かるフィードバックとしては、例えば下記のようなものがある。

  • 自分の悪い癖や習慣
  • お褒めの言葉
  • あなたが実施するプレゼンの原稿やスライドのチェック
  • あなたが書いたドキュメントのチェック

上司こそがあなたの最強の味方であるべき。
あなたの学習や成長に役立つプロジェクトを見定め、それを担当させてくれる上司だと最高。

トレーニングとキャリアアップ

上司はあなたと会社をつなぐ主なパイプ役として、トレーニングなど、あなたのキャリアアップに効果的なリソース(資源や手段)を見出す責任の一端を担っている。
とはいえ、自分に必要なトレーニングの種類や内容を見極めるのは主としてあなた自信の責任。

また、あなたのキャリアップに上司が直接貢献できるのは、昇進と昇給。
できる上司なら、自分たちの組織がどんな資質やスキルを求めているかを心得ているはず。
また、あなたがそうした資質やスキルを磨けるような助言や指導をしてくれるはず。

管理のされ方

満足のいく形でキャリアを積んでいく上で重要なことは以下の通り。

  • 職場で自分が経験することに対して当事者意識や主体性をもつ
  • 上司との関係づくりにおいても上司任せにしない

自分が何を望んでいるのかをじっくり考える

自分自身が何を望んでいるのか、何を学びたいのか、何が自分を幸せにするのかを考え抜いて明らかにする責任は、ひとえにあなた自身が負っている。
(上司ができるのは、あなたの成長につながる機会を教えるところまで。)

自分に対する責任は自分で負う

上司と話し合いたいことがあれば、1on1 の議題として提案する。
参加したいプロジェクトがあれば、上司に頼む(応援が得られなさそうであれば他をあたる)。
自分の正すべきところ、伸ばすべき能力に関する建設的な助言など、フィードバックは積極的に求める。

上司も人の子

あなたの手で変えられるのは「あなた自身」だけ。
上司へのフィードバックの提供は、部下であるあなたの当然の務めではあるが、上司が進言や忠告に耳を貸さなくても、それを受け止めるしかない。

1on1 では、問題点を報告するのではなく、解決法を提案することを期待されるようになる。
なんらかの問題が生じたら、その解決を上司に求めるのではなく、上司ならどう対処するか、助言を仰いでみるとよい。
(助言を仰ぐというのは相手への敬意と信頼を示す絶好の手法でもある。)

メンタリング

チームの新人に対するメンタリングの意義

メンター とは一般的にチームの新人に一対一で仕事上の指導や助言、精神的なサポート等を行う専任の指南役のこと。

メンターの務め

メンター役は、人を管理する仕事がどういうものなのか、他者への責任を負うことがどんな感じなのかを、あまり責任を負わずに学べる好機。

とはいえ、以下のような最悪の事態が起きるケースもある。

  • 新人や研修生が無能なために指導が徒労に終わり、プログラミングの作業にも支障が出てしまう事態
  • 指南役の指導がまずくて有望な新人や研修生が不満や不快感を抱いたり、短期間で辞めたり他社を選んでしまう事態

インターンのメンタリング

まず準備する必要があるのは期間中インターンにやってもらうプロジェクト。
自分なら 2、3 日で完成できるようなちょっとした機能や要素を見つけ、それをプロジェクトに利用できないか検討してみるのが良い。
また、最初の 2、3 日は可能な限りインターンのそばについていてあげるのが良い。
(まずは一緒に開発環境をインストールして、コードを逐一説明してあげるところから。)

この場面で磨ける能力は以下の通り。

  • 相手の言葉に耳を傾ける傾聴力
  • 相手のするべきこと、出すべき結果を明確に説明する伝達能力
  • 相手の反応を見て適宜調整する適応能力

傾聴

人的管理において基本中の基本とも言えるのが傾聴のスキル。
話を聞くときの注意点:

  • 「自分が次に何を言いたいか」だけを考えていないか?
  • 相手が言葉を口にする際の調子や仕草に気を配れているか?
    • 相手はあなたの目を見つめながら話していますか?
    • 微笑んでいますか?
    • 眉をひそめていますか?
    • ため息をつきながら話していますか?

自分が話をするときの注意点:

  • 複雑なことを告げる際には、必要なら、表現を変えて 2、3 度繰り返す
  • 相手の質問したことがわかりにくいと感じたら、その質問を、表現を変えて相手に返してみる
  • 自分の言葉を相手がきちんと理解した、と納得できるまで、たっぷり時間をとって話し合う

種々のメンタリングの関係を結ぶことになったら、「その関係に対する期待や目標を明確にすること」が大切。

すごい上司、ひどい上司ーアルファギーク

アルファギーク とは最先端の技術に異様に詳しく、ものすごくとんがったコンピュータオタクのこと。
優れたエンジニアでありたいという思いが強く知性と技術力を重んじている。

アルファギークには以下のような気質がある。

  • 自分が知っていることはどの技術者も知っていて当然、と考えている
  • こだわりが異常に強い
  • 非技術系の職種の人たちを見下すことがある

アルファギーク気質を正すチャンスは「メンター役を引き受ける」こと。

メンターの重要な心得

  • 常に好奇心を絶やさずオープンな心で
  • 相手の言葉をよく聞き、相手の言葉で話す
  • 「キャリアの最終的な成否を左右する重要な決め手は人脈である」ということを心得る

テックリード

テックリード とはプロジェクトに携わるエンジニアチームの「技術上のリーダー」のこと。
『Talking with Tech Leads』によると以下の通り定義されている。

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

優秀なテックリードなら必ず知っている、ある奇妙な「コツ」

優秀なテックリードになるためのコツは、「実際のプログラミングの作業からあっさり一歩引き、『技術面での貢献』と『チーム全体のニーズへの対応』のバランスを取る努力を惜しまない」こと。

テックリードの基礎知識

テックリードが最優先しなければならないのは「プロジェクトを推進するため、常に大局的な視点を失わないこと」。

システムアーキテクトとビジネスアナリストとしての役割

システムアーキテクトとビジネスアナリストとしての役割は「プロジェクトを完遂しデリバリを実現するには基幹システムのどこを改変すべきかやどの機能を構築すべきか、を見極める」というもの。

これを首尾よく行うためには、以下の 2 点が大事になる。

  • 対象のシステム全体の構造の十分な把握と複雑なソフトウェアを設計するための方法に関する理解
  • ビジネス要件に対する理解と、そうした要件をソフトウェアに織り込む能力

プロジェクトプランナーとしての役割

プロジェクトプランナーとしての役割は「作業をデリバリ可能な単位に大まかに分割する」というもの。

作業を出来るだけ同時並行で進められるようにする。
そのために、皆が合意できるよう並行作業が可能な部分をうまく抽出することがカギ。

この段階では、チームのメンバーの中でも特に事情に通じている人からアドバイスや情報をもらい、ソフトウェアの影響を受ける箇所を熟知している人からも説明を受けるなど、細部に関する助言を仰ぐ必要がある。
また、この辺で優先順位の検討を始める必要もある。

ソフトウェア開発者兼チームリーダーとしての役割

ソフトウェア開発者兼チームリーダーとしては、自らプログラミングの作業をこなしつつ、メンバーに課題を伝えたり作業を任せたりする任務を果たす。

テックリードになってからもコードを書く仕事は続けるべきだが、やりすぎは禁物。
問題が起きたら、まずはその問題を皆に伝えなくてはいけない。

まとめると、テックリードは、

  • ある作業を自分ひとりで完遂すべき場合とメンバーに任せるべき場合をきちんと心得た上で
  • ソフトウェア開発者としての役割
  • システムアーキテクトとしての役割
  • ビジネスアナリストとしての役割
  • チームリーダーとしての役割の全てを適宜こなさなければならない

経験を積んでいく中でだんだんとバランスを取れるようになる(らしい)。

プロジェクトの管理

アジャイルソフトウェア開発のおかげでプロジェクト管理は不要になった、という訳ではない。
アジャイルなやり方が向いているプロジェクトもあれば、そうでないプロジェクトもある。

(筆者の意見としては)専任のプロジェクトマネージャを雇うのは好ましいこととは思えない。
エンジニアたちがプロジェクトマネージャに頼りすぎるきらいがある、というのが理由。
(本来なら各自が自分の頭を使って将来や現在の仕事を真剣に考える術を身につけなければならない。)

プロジェクト管理は必須であり、それを担当するのがテックリード。
専門性の高いプロジェクトにプロジェクト管理は欠かせない。

プロジェクト管理の実務

プロジェクト管理とは、

最終目的を達成するまでの複雑な過程を分割したのち、同時並行が可能な工程や連続進行が必要な工程を見極めたり、プロジェクトの遅延や頓挫を招きかねない未知の要素を突き止めたりしつつ、各工程をもっとも効率よく実施できると思われる順番に並べていく作業

プロジェクト管理における指針をいくつか紹介すると、下記の通り。

  • 複数の工程に分割する
  • 細部の引っかかりや道の要素にもくじけない
    • 多少行き詰っても、うんざりしても、やめないこと
    • 「もうこれ以上時間をかけても、この部分からこれ以上の価値は引き出せない」と納得が行くまで徹底的に未知の要素と向き合うこと
  • プロジェクトを始動し、調整を加えながら進行させる
  • 立案過程で得られた洞察を生かし、その後の要件の変化に対応する
  • プロジェクトが完了に近づいたら細部の詰めを
    • 「プリモータム」を実施し、リリースする前にリスクを洗い出す
    • 「プリモータム」とは、プロジェクトの完了が間近に迫った時に「この大規模プロジェクトの成果物を公開したら大失敗に終わってしまった」と仮定し、頭の中でその事態を逐一検討してみる、という手法

決断の時ー技術職を貫くか、管理職への道を選ぶか

あなたが望めば針路変更も可能だ、ということを忘れてはならない。
ある時点で管理職についてはみたが、やはり自分には向いていないと判断し、技術畑に戻る人も少なくない。
どちらの道にもメリット、デメリットはあり、どの仕事が一番自分に向いているかを見定めるのはあなた自身である。

すごい上司、ひどい上司ープロセスの何たるかを心得ている上司と、プロセスツァー

プロセスツァー とは、特定のプロセスや手順、手法を崇め奉り、その手法を正しく実践しさえすればチームの抱える難題はもれなく解決できると信じて疑わない人のこと。
プロセスツァーは「自分と違って大抵の人は所定のプロセスに厳密に従うことがあまり得意ではない」という現実を理解していないと、つまづきがち。

『アジャイルソフトウェア開発宣言』にもある通り、

  • プロセスやツールよりも個人と対話を
  • 包括的なドキュメントよりも動くソフトウェアを
  • 契約交渉よりも顧客との協調を
  • 計画に従うことよりも変化への対応を

という点を深く理解していることが大事になる。

チームのコミュニケーションやリーダーシップの不備に起因する問題を、プロセスを拠り所にして解決しようとする際には注意が必要。
プロセスもツールも仕事のやり方も、チームごとに違っていて当然。
いつの間にか「うるさすぎる親方」になってるな、という自覚のあるひとは、プロセスそのものを、もっと守りやすく扱いやすいものに改変できないか検討してみると良い。

優秀なテックリードとは

  • アーキテクチャを把握している
  • チームプレイの大切さを心得ている
  • 技術的な意思決定を主導する
    • 一人で全ての決定を下せる職権を有する、という訳ではない
    • 自分が決断しなければならない事柄と、自分よりも豊富な専門知識を持ち合わせているメンバーに判断を委ねるべき事柄、チーム全体で決断するべき事柄を見極める必要がある
    • どの場合も討議中の事項と、討議の結果とを皆に報告することが大事
  • コミュニケーションの達人である
    • テックリードになると、あなた個人の生産性よりもチーム全体の生産性を重視しなければならなくなる
    • 今こそ書く力、話す力を伸ばす絶好のチャンスだと受け止めると良い

人の管理

管理者になりたての適応期に重点的に取り組むべき課題として「自分なりの管理スタイルを見つけること」が挙げられる。
人の管理で求められる主な仕事は次の 4 つ。

  • 直属の部下との関係の構築
  • 定期的な 1on1 のミーティング
  • キャリアアップや作業の進捗状況、改善領域、功績の報奨などに関するフィードバック
  • 各メンバの研鑽を要する領域の見極めと、その領域の能力の(プロジェクトでの職務遂行や、外部での学習、メンタリングを介しての)強化

直属の上下関係

短期間で良好な関係を築くためのコツは次の通り。

  • 信頼感と親近感の構築を
  • 今後一ヶ月、二ヶ月、三ヶ月の計画を立てさせる
  • 新人研修用のドキュメントを更新させてチームに対する理解を促す
  • 自分の流儀や要望をはっきり伝える
  • 新人からもフィードバックを得る

チームメンバーとのコミュニケーション

1on1 のスケジューリング

1on1 のスケジューリングの標準は「週一」。
こんなに頻繁にやる必要はない、と感じた場合に限り頻度を調整すれば良い。

あなたも部下もオフィスにいる確率を高い日時を選ぶのが吉。
(月金は避ける、部下の仕事の能率が上がりそうな時間帯での実施は避ける、など。)

1on1 にまつわる調整

配慮するべき要素は以下の通り。

  • その部下とは週に何回ぐらい(事前の取り決めなしで)やりとりをしているか
  • その部下にはどの程度のコーチングが必要か
  • その部下があなたにもたらす情報の量は?
  • その部下とあなたの間柄は?
  • チームや会社の(不)安定度は?

1on1 の進め方

進め方は色々ある。が、どの方法が良いかは人によって異なる。

  • TO-DO リスト型
    • 1on1 を始める前に「何について話すか」を決められる
    • キャッチアップ型に比べると冷たい雰囲気になる可能性がある
  • キャッチアップ型
    • TO-DO リスト型よりもフランクに進める形式
    • 不満や愚痴を並べ立てる場にならないよう注意が必要
  • フィードバック型
  • 経過報告型

1on1 の議事録は共有ドキュメントの形で作成し、管理することをオススメする。

すごい上司、ひどい上司ー細かすぎる上司と、任せ上手な上司

細部まで厳しく管理して部下に裁量権を与えない マイクロマネジメント は、どの管理者でも陥りがりな落とし穴。
「オートノミー(自分の職務に対する裁量権がある程度与えられて自主性を発揮できる状態)」は、モチベーションを生む重要な要因。
独創的で才能豊かな部下を、自主性を発揮できない立場に追い込むと、みるみるやる気を失ってしまう。

効率よく仕事を巻かせるためにー実践的アドバイス

「優れたリーダーは任せ上手」。これが大事。

自分がどういった事柄を細かくチェックすべきかを見極める基準は「チームの目標」

以下のような状況であれば、概要のチェックだけで OK。

  • チームがゴールを目指して着実に進んでいる
  • 作業のシステムが安定している
  • プロダクトマネージャーが満足している
  • しかるべき目標が設定されている

チームに明確な計画がないのであれば、定期的にチェックするべきだと思える事項をチームに示し、それを使ってチームに目標と計画を立てさせるのが良い。

その他の実践的アドバイスは以下の通り。

  • チームメンバーに尋ねる前にシステムからの情報収拾を
  • プロジェクトの進行に伴って焦点の当てどころを調整
  • コードやシステムに関する基準を設定する
  • 情報は良きにつけ悪しきにつけオープンな形で共有する

「継続的なフィードバック」の文化をチームに根付かせる

「継続的なフィードバック」とは、一口に言うと、「お褒めの言葉」などの肯定的なフィードバックも修正を命じる訓戒系のフィードバックも全て定期的に共有するという取り組みのこと。
継続的なフィードバックを実践する上で有効な対策は以下の通り。

  • 部下の基本情報を仕入れる
  • 日頃から部下を見守る習慣を
  • 深刻な話題も日常レベルのフィードバックでさらりと
  • コーチング

勤務評価

勤務評価の要約の作成と面談

  • 作業を早めに開始し、時間的余裕を確保する
    • 一時間の突貫工事でしかるべき結果を出せるような作業ではない
    • 皆から集めたフィードバックを、メモを取りながら読み、そうやって得た情報をまずは頭の中で整理し、それから実際に要約を書くと良い
  • 直近の 2、3 ヶ月だけでなく過去 1 年全体に目を向ける
    • 1 年を通して常時記録を取るようにすると、勤務評価の要約が作成しやすくなる
  • 具体例をあげ、皆のフィードバックからの引用も使う
  • 功績や長所の報奨にはたっぷり時間をかける
  • 要改善点を書くときは焦点を絞って
    • 勤務評価を皆から集めるといい加減な内容のものも集まってしまいがち
    • 事前にしっかり検討し、その真偽を確かめて、勤務評価の要約に載せるか否かを判断するべき
  • 部下を驚かせてはならない
  • 評価面談には時間をたっぷりかける

キャリアアップの取り組み

はじめてチームの管理者になった人が必ずやっておくべきなのは、「自分の会社では部下の昇進に関してどのような方針と手続きを取っているかをきちんと把握しておくこと」。
成果をあげれば昇進材料となりそうなプロジェクトを見つけておくのも大事。

ただし、管理者のこの職務は、自分のチームを構成するメンバーのランクが上がるにつれて変わってくる。
一定のランクまで昇進したら、その後も昇進し続けるということはあまりない。
(部下を社内の他部署のリーダーに紹介してメンタリングや支援を要請することは可能かも。自分のチームからはいなくなってしまうかもしれないが、部下は新たな機会や挑戦課題を手にすることができる。)

「ピーターの法則」によると、組織構成員は時の経過とともに出世していくが、自分の能力の極限まで出世し、その瞬間に無能化してしまう。らしい。

チームの管理

優れた管理者になる上で何よりも大切なのは、最強の技術力の持ち主であることではない。
管理者としての成果を上げるためには、チームの人々を後押しすることの方がはるかに重要。

IT スキルの維持

技術系の管理者は、コードを書く作業を「卒業」してしまってからも、技術面の意思決定を主導する責任を負っている。

チームのリーダーとして、経験の浅いエンジニアに止まらず、システムのデザインを担当するアーキテクトや、細部に関する責任を担うシニアレベルの技術者に対してさえ、自分の下した決定には自分で責任をもってもらい、さらに、そうした意思決定が技術的な「嗅覚テスト」に合格したこと、チーム全体や会社全体といった広範なコンテクストとの間でバランスが取れたものであることを確認する責任です。

技術チームで一目置かれる存在になりたいと本気で望むのであれば、「確かな技術力の持ち主」という評価を是非とも皆から勝ち得なければならない。
そういう意味で認めてもらえないと今後苦戦を強いられる。
たとえある会社で管理者の地位を得られても、その後の選択肢が限られてくる。

ボトルネックや作業工程の問題点のありかを素早く察知するためには、ある程度コード書きの作業に従事していることが必要。
(管理者になってもコードを書く作業にこだわる必要があるのは、ココが理由。)
ごく小規模なプログラミング作業の最中に出くわす問題や障害からは、例えば、

  • システムの構築がひどく手間取っている
  • コードのデプロイが遅すぎる
  • 緊急呼び出しの負担が異常に重い

といったことを感じ取ることができるはず。

「実装に最適なルートを見分けられるほどまでシステムの各要素を十分に理解している」というのは、複雑なプロジェクト管理を成功裏にこなすための要件の一つ。
これはテックリードをやっている際に習いおぼえるコツ。

機能不全に陥ったチームの「デバッグ」の基本

チームの「機能不全」とは、例えば以下のような状況を指す。

  • 成果物の引き渡し期日を毎度のように守れない
  • チームのメンバーが惨めな思いをしている
  • メンバーが次々に辞めていく
  • プロダクトマネージャがイライラを募らせている
  • プロダクトマネージャーに対するチームメンバーの不満が膨らんでいる

デリバリにこぎつけられない

製品アップデートのリリース頻度が低いケース(週一回以下)。
リリースの頻度が低いと、リリースに際してのペインポイントに気づきにくくなることがある。

  • リリースに関わるツールの不備
  • 手作業に頼り過ぎのテスト
  • 規模が大きすぎる機能
  • 作業の細分化のコツを心得ていない開発者

こんなチームの管理を引き受けることになったら、こうしたボトルネックを解消するようチームに働きかける必要がある。

厄介な部下への対応

ブリリアントジャーク とは、エンジニアとしては格別に優秀だが、実に嫌なやつのこと。
他にもこういったケースは一般的に扱いにくい。

  • チームに波風を立てる部下
  • マイナスの経験にいつまでもこだわる部下
  • ウワサ話の度が過ぎる部下
  • 「我々 VS 他のみんな」という排他的な思考パターンに陥っている部下

人間関係のゴタゴタはチームの管理者が勇気をもって小さな芽のうちに摘んでしまう必要がある。
(問題の言動を見せたら直ちに注意し、今後は正すように説明する。)

過労による士気の低下

過労によるチームの士気の低下は、根底に対応可能な問題が横たわっているのが普通。

たとえばシステムの不安定性が原因でチームの面々が過労状態に陥っているのであれば、管理者は当面、安定性の向上に注力できるようロードマップを調整するべし。
アラートやダウンタイム、インシデントの回数を測定し削減に努めると良い。
そして、計画立案の段階で、管理者としての職務時間の二割をシステムの「持続可能性」のための作業に確保することを推奨する。

どうしても外せない納期が間近に迫ってチームが過労状態になっている場合は、次の 2 つのツボを押さえておく必要がある。

  • 管理者はチアリーダーたるべし
  • この難局から学び、それを活かして次回はこうした事態の再発を防ぐよう全力を尽くす

協働に関する問題

あなたのチームと、プロダクトチームやデザインチーム、あるいは他の技術チームとの共同作業がうまく行かず、関係者全員が足を引っ張られる形になっているケース。
手っ取り早い応急措置はないが、あなたが改善の意欲を見せるだけでもかなり効果がある。
この問題を解決するのにふさわしい相手方の責任者と必ず定期的に連絡を取り合うこと。
自分の部下たちからも実行可能なフィードバックを集めて、可能性のありそうな改善策を積極的に検討しあうこと。

あなた自身のチームを前にして、相手チームの責任者を批判したりすると、事態がさらに悪化してしまう恐れがある。
どれだけ相手チームの責任者に不満があっても、自分の部下の前ではあくまで前向きに解釈し支持してあげるよう努力するべし。

チーム内での協力関係がはかばかしくない場合には、みんなで一緒にちょっと息抜きをする機会を作れないか考えてみると良い。

盾になる

管理者は、「チームの面々を支援して、成功の鍵となる重要な目標を理解させ、その目標に焦点を絞らせることが大切」。
言い換えると、

  • 自分たちが影響力を行使して変えられる事柄になら焦点を当てられるし当てるべきだ
  • 自分たちに変えられない事柄は無視しよう

時にはストレスの素をあえて部分的にチーム内に入れてしまった方が良い場合もある。
その狙いは、今取り組んでいる対象に関わるコンテクストを理解してもらうこと。
「しかるべきコンテクストの把握」は、どこにどのように注力するべきかについてチームが適切な判断を下すのに役立つ。

あなたはチームのメンバーの親ではない。
チームのメンバーはしかるべき敬意をもって対するべき大人、と心得ること。

チームの意思決定を主導するコツ

管理者に与えられているのは自ら決定を下す権限ではなく、チームによる意思決定を主導する権限にすぎない。
そうした意思決定の結果の良し悪しが管理者の能力の判断材料にされてしまう。

データ重視の文化を根付かせる

チームの管理者であるあなたの上に製品や事業を担当する監督者がいる場合、以下のようなデータを意思決定の材料にすることに慣れてもらう必要がある。

  • 事業や顧客、閲覧者のネット上での行動履歴、潜在需要などに関わるデータ
  • チームの生産性に関するデータ(機能完成までの所要時間など)
  • 品質の測定に関わるデータ(システム障害に対処するために要した時間や、QA で発覚したバグやリリース後に見つかったバグの数など)

顧客に対する共感を深める

優れたリーダーは、自社の顧客にとって何が重要かを理解する努力を欠かさない。
顧客にこそ焦点を当て、時間を割いてそうした顧客への共感を深めることが大切。
(チームのエンジニアたちに「コンテクスト」を伝えるのが成功のカギになるため。)

将来を見据える

管理者は、製品や技術に関しては「今ここ」より二歩先に立って考えていく必要がある。
例えば、プロダクトロードマップに書かれている今後の展開を把握しておくと、テクニカルロードマップをベースにした管理がやりやすくなる。

チームの意思決定やプロジェクトの結果を振り返る

プロジェクトのモチベーションを高めるためにチームが採用した仮説や前提が適切なものであったか、プロジェクトが完了した時点で振り返る反省会を開くこと。
管理者の側でもチームの側でも、これを習慣づければ、自分たちの下した意思決定から常になんらかのことを学べる。

すごい上司、ひどい上司ー「対立を何とか手懐けられる上司」と「対立を避けて通りたがる上司」

対立を解決しようとする際の「べし・べからず集」

  • 「コンセンサスや投票結果にしたがって決定を下す」という方法だけに頼ってはならない
  • 意思決定から個人的要素を排除するための明確なプロセスを確立する
  • 「爆発寸前」の問題に見て見ぬ振りをしてはならない
    • 部下の仕事ぶりに大きな問題があることに気づいたら、その場ですぐその部下に指摘するべき
  • 本当に対処を要する問題だけを取り上げる
    • 「人間関係のちょっとした摩擦」と「チームの効率低下を招くほど深刻な問題」は区別する
  • 他チームへの責任転嫁は禁物
  • 管理者は「優しさ」よりも「親切」を旨とすべし
  • 恐れずに勇気を出して
    • 対立を避けたい気持ちは往往にして恐怖心から生まれる
  • 我が身を振り返る

やりにくい仕事ー「チームの結束を乱す人」への対処

しかるべき成果をあげられるチームを育て上げるのに不可欠な目標の一つが「楽しく気持ちよく共同作業ができるチーム作り」。
管理者が目指すべきは「心理的安全性」。
まずは「やがては心理的安全性が生まれてくるような打ち解けた雰囲気を作り出すこと」から始めると良い。

ブリリアントジャーク

エンジニアとしては非常に優秀だが、ひどく自己中心的で、周囲の人全員に恐れと嫌悪の混じった気持ちを抱かせる人。
「ブリリアントジャーク症候群」を回避する最良の策は「初めからそう言う人は雇わない」。
管理者がチームのためにできる最良の対策は、「好ましくない言動は、断固、公然と拒否する」こと。

秘密主義者

管理者やチームメイト、プロダクトマネージャに隠し事をする人。
具体的には以下のような行動を指す。

  • 自分が企画した素晴らしいプロジェクトを秘密裏に進め、完成したところで披露する
  • チームメイトが手を加えたコードを無断で元の状態に戻してしまう
  • 仲間の作業を横取りして完成させてしまう
  • コードをレビューされるのを嫌がる
  • 大きなプロジェクトのデザインを引き受けておきながらそのレビューを頼まない

往往にして、こうした情報隠しの行動の根本には恐怖心が隠れている。
可能であれば、情報隠しという行動の裏側にどんな理由があるのかを探ってみると良い。

無礼者

管理者やチームメイトに敬意を払おうとしない人。
尊敬できない管理者やチームメイトと一緒に働いていることが謎なので、本当にこのチームで働きたいのかを聞いてみると良い。
答えが「働きたい」であれば、管理者として部下に望むことを明確かつ冷静に返す。
「働きたくない」であれば、他チームへの異動か退社のための手続きを始めれば良い。

管理者が担当するべき、より専門的なプロジェクト管理

技術系の管理者には、チームのスケジュールの立案の支援という職務がある。
部課や全社など、より大きな規模で四半期なり年間なりの計画が立てられる際には、管理者はまた別種の職務を果たさなければならない。
例えば、以下のような見積もり作業。

  • 自分のチームが特定のプロジェクトをこなせるか否か
  • そうしたプロジェクトの所要時間がどの程度か
  • その作業をこなせるレベルのメンバーが揃っているか

チームレベルのプロジェクト管理はテックリードの仕事。
チームの管理者が果たすのはより「上級の」プロジェクト管理の仕事。

チームのプロジェクトの計画立案は、一部分をテックリードに任せるものの、関与は必須。
(管理者が指導や助言を行ったり自分でも一部をこなしたりはする。)
管理者はチームが引き受けるプロジェクトの選択と決定もしなければならない。
作業完遂の所要日数の大まかな見積もりも要請される場合がある。

管理者が担当すべき、より専門的なプロジェクト管理の経験則

アジャイル型管理手法を適用すべき場面はチーム主導で

短期目標の詳細を計画する際には、作業の分割や大まかな見積もりをチームの面々が共同で行うアジャイル型管理が有効。
(テックリードの仕事を横取りしてしまわないよう注意。)

管理者が担うべきなのはより大局的な職務。
作業の進捗状況を週単位ではなく月単位で管理することが求められる。

「一定レベルの生産性が見込める週」は、一四半期、エンジニア一名あたり10週

一年間を週に換算すると52週、一四半期あたりでは 13 週になる。
しかし現実には、それだけの時間を丸々作業に使えるわけではない。
(休暇、会議、レビューなどがあるため。)

チームのメンバー一名が一四半期に主要なプロジェクトに集中的に取り組める時間はせいぜい 10 週と考えること。
一般的には、1Qがもっとも生産性が高く、4Q がもっとも低いと言われている。

「システムの持続可能性維持作業」には二割を

「システムの持続可能性維持作業」とは、具体的には以下のような作業のこと。

  • テスト
  • デバッグ
  • レガシーコードの改善
  • 多言語への移植
  • プラットフォームバージョンの更新

この作業に利用可能時間の二割を充て、これを習慣化すれば、中規模のレガシーコードなら四半期ごとに一部分でもかなり改善できるはず。
こうしてレガシーコードの改善を常時続けていくと、そのシステムでの作業が常にスムーズに運ぶ。
新機能を作成、追加する作業もはかどるはず。

万が一、機能の開発で予想外の遅れがでた場合などに、この二割の時間を急遽振り分けることも可能。
(ただし、システムの老朽化により開発速度が大きく落ち込むことを覚悟の上でやること。)

納期間近での管理者の務めは「ノー」と言うこと

納期を守る唯一の方法は「土壇場で範囲を狭める」こと。
管理者は必要なら上に対しても下に対しても「ノー」と言わなければならない。

即席の見積もりには倍増ルールを適用し、長期的作業の見積もりには立案のための時間を要求する

「倍増ルール」とは、見積もりを頼まれたら、概算し、その結果の倍の数字を提示する、と言うもの。
これは「即席の見積もり」に対して有効なルール。

二週間を超えそうな長期的なプロジェクトの場合、一応倍増ルールで出した数字を提示はするものの、「この数字の妥当性を確認するためには具体的に計画を立てることも必要で、そのための時間が欲しい」と要求するべき。
(長期にわたるプロジェクトの場合、当初の大雑把な見積もりの倍の時間がかかることもある。)

チームメンバーに見積もりを頼むなら厳選して

管理者がプロジェクトに関する見積もりを手当たり次第に命じたりすれば、チームの面々は気を散らされてストレスが溜まってしまう。
管理者には、不確定要素を見据え、それに関してチームにどこまで知らせたら良いのか判断する責任がある。
メッセージを取り次ぐだけの「電話線」にならないよう注意すること。

管理者が見積もりを全部一手に引き受けてやってしまう「ブラックボックス化」も困り物。
チームで新機能や顧客の苦情について話し合うためのルールや手順をあらかじめ決めておき、その枠外のものに関する見積もりは厳選した上でメンバーに依頼すること。

複数チームの管理

いわゆる 技術部長 の職位。
この段階になると、プロダクションコードをあまり(あるいは全く)書いていない状況になる。

プロダクションコードを大量に書いていなくても常に現場の仕事に精通していられるようにするための手段はいくつかある。
例えば、コードレビューを(少なくとも「副レビュアー」として)引き受けるという方法。
これにはプログラミングの腕が鈍るのを予防してくれる効果がある。
チームの大半のメンバーよりも詳細を記憶しているはずなので、今そのシステムを担当しているエンジニアをコードレビューや質問などの形で支援できるはず。

とはいえ、最低でも週に半日はまとまった時間を作り、その一部分を何か創造的な活動に使うことを推奨する。

時間の管理ーなにはともあれ「重要な仕事」に照準を

時間管理のツボは「重要と緊急の違いを見抜く」こと。

緊急ではない 緊急
重要 必須。時間を作る 明らかにやるべきこと
重要ではない 明らかに回避するべきこと ついつい注目しがちな「気の散る要因」

以下のようなことを自問すると良い。

  • 今私がやっていることは、どの程度重要なのだろうか
  • それは「緊急」だから「重要」だと思えるのか
  • 今週私は「緊急」な仕事にどの程度の時間を費やしてきたか
  • 私はこれまで「緊急でない」仕事のために十分な時間を捻出してきただろうか

意思決定と委任

仕事を委任するか自分でやるかの判断は、頻度と複雑さで決める。

頻繁 頻繁でない
単純 委任 自分でやる
複雑 慎重に委任 訓練目的で委任

CTOに聞け 問題の前兆

以下のようなことがおきている場合は怪しい。

  • 日頃、朗らかでよく喋り、仕事熱心なはずの部下が突然、退社時刻きっかりに帰ってしまうようになり、遅刻や早退が増え、会議でも発言せず、皆とおしゃべりを楽しむこともなくなった
  • テックリードが「万事順調に進行中」と言いながら、管理者との 1on1 を度々キャンセルし、最新状況の更新でも滅多に詳細を明かそうとしない
  • チームミーティングに出席しているメンバーにまるで活気がない
  • チームのプロジェクトリストが顧客の気分次第で毎週のように変わる気がする
  • 小規模なチームで、仕事に対する認識がメンバー間で大幅に違っているようだ。エンジニアは自分たちに無関係なシステムに関してはなにも知らないことを認めるにも関わらず、そうしたシステムのことを知りたいと言う好奇心も公平な目も持っていない

やりにくい仕事ー「ノー」にも言い方がある

管理者が「ノー」という相手は、チームの場合も、同レベルの管理者の場合も、上司の場合もある。
誰が相手であっても違った意味での言いにくさがあり、効果的に「ノー」を言うための戦略が必要。

「はい、それでですね」

「はい」と肯定系で受けつつも「限界」と言う形で実情を明示する言い方。
肯定的なノーが言えるようになると、優先度を見据えた現実的な交渉に持ち込める。

ポリシーを決めておく

「ノー」と言わなければいけない相手があなたのチームである場合、あなたから「イエス」を引き出すための要件をメンバーに理解してもらうのが良い。
筋の通ったポリシーを決めておけば、あなたから「イエス」を引き出すために迫られる対策や代償をチームメンバーが事前に把握、検討できる。

私に「イエス」と言わせてみて

疑わしく思える部分について突っ込んだ質問を重ねてみる方法。
一回限りの事項であるために明確なポリシーを決められないような場面で効果を発揮する。
部下が出したアイディアを好奇心を持って検討し、質問を繰り返していくことで、「ノー」と言うべき時には「ノー」と言いやすくなる上に、そのプロセス全体が部下の教育となり得る。

「時間と予算を盾に取る」と「今すぐは無理」

現在の作業負荷をわかりやすく提示して、時間や予算の面で余裕がほとんどないことを納得してもらう。
(こちらが「時間と予算を盾に取る」の言い方。)

相手が出したアイディアに反対ではないが、今それを実行するのは無理、将来考えてみても良い、と匂わせる。
(こちらが「今すぐは無理」の言い方。)
とはいえ約束は守るべきなので、後日きちんと「真剣に考える」ようにすること。

手を組む

「ノー」と言うために部長クラスの同僚と手を組む必要が生じる場合もある。
プロダクトチームにとって有益な形で「ノー」と言うために、あなたが技術部長としての権限を行使してあげる。
もしくは、財務部長に頼み込んで「予算不足」を理由に「ノー」の後押しをしてもらうケースもあり得る。

「ノー」と言うべき場面では、ぐずぐず先延ばしにしたりせず、その場で言うようにすること。

コードの作成以外の IT スキル

『First, Break All the Rules』で、チームの生産性や満足度を予測するのに役立つ質問が挙げられている。

  • 会社から求められている自分の職務絵をきちんと把握しているか
  • 自分の職務を遂行する上で必要な機器やツールを持っているか
  • 毎日最高の仕事ができる機会を得られているか

言い換えると、

  • コードリリースの頻度
  • コードへのチェックインの頻度
  • インシデントの発生頻度

が、そのチームが職務をしっかりわきまえ、その職務を遂行するのに必要なツールを備え、その職務を毎日遂行する時間を有するかを調べる際の重要な指標となる。

直属の開発チームの健全性を見極める

コードリリースの頻度

健全な技術チームであることを示す一番の兆候は「リリース頻度の高さ」。

リリース頻度の低いチームを公平な目で見つめてみると、その要因が見つかるはず。
たとえばこんな感じ。

  • リリースのプロセスが手間取る
  • 自分たちが書いているコードなのに、その品質に対する責任意識がエンジニアたちになく、その方面の仕事は品質保証(QA)チームに任せきりであるため、両チームのやりとりに手間がかかる
  • アップデートのリリースがうまく行かなかった時のコードをロールバックするのに手間取る
  • リリースのプロセスで問題が発生し、これが本番環境でのインシデントの原因となる

技術チームを率いる管理者が忘れてはならないのが、もうコードをあまり書いていない管理者でも、技術面で作業の推進を図る責任は引き続き負っている、ということ。
チームの雰囲気づくりや生産性の維持に有効なのは、

  • メンバーの生産性の向上を図ること
  • 開発速度も成果も上がるよう新しいことに貪欲にチャレンジさせること
  • 仕事をもっと面白くするための時間を捻出できるように支援すること

コードのチェックインの頻度

テストコードを書く機会があまりないエンジニアは作業の細分化に手こずる傾向にある。
テスト駆動の方法を習得してもらうと作業の細分化も上達する(ことが多い)。

インシデントの発生頻度

夜間や週末に頻繁な緊急呼び出しに応じることをチームメンバーに求めると、燃え尽き症候群を引き起こしかねない。
開発者が何日間もインシデントの最小化や予防のための作業にかかりきりでコードが書けないという事態を回避できるよう、リスクを慎重に天秤にかけること。

すごい上司、ひどい上司ーイングループを作りたがる上司と、チームプレイを重んじる上司

イングループ とは、愛着や忠誠心に裏打ちされた所属意識をもつ集団のこと。
イングループを作ってしまうと、以下のような問題に悩まされることになってしまう。

  • リーダーを失うと、脆さが露呈
  • 外部の考えやアイディアには聞く耳持たず
  • 帝国を構築する
  • 柔軟性に欠ける

まずは時間を取って、会社の長所や文化を理解し、文化を上手に活かして成果をあげられるチームを作る方法を模索すること。
その際の秘訣は「欠陥や弱点に焦点を当てるのではなく強みや長所を見極め、それを伸ばしてやること」。

会社全体の目標を基盤に、チーム間で、チームのメンバー間で、全社規模で、強く永続性のある強調関係を構築すると、次のようなチームが育ってくる。

  • リーダーやメンバーが辞めてもすぐに立ち直れるチーム
  • 目標駆動型のチーム
  • 部長クラスの同僚こそが「チーム」
  • 目標達成に役立つ変化なた喜んで受け入れるチーム

無精と短気の効用

プロジェクト管理についてはせっかちと無精を発揮すること。

管理者は、今チームが進めている仕事の効率が悪いと感じたら、すぐに自問してみると良い。

  • 効率が悪いと今私が感じたのはなぜなのか
  • 今我々がやっていることには、どんな価値があるのか
  • その価値を、もっと迅速に提供できないか
  • このプロジェクトを削ってもっとシンプルにして、もっと迅速に完了できないか

また、管理者は帰宅するという(無精の)模範行動を取るべき。
管理者であるあなたがチームの誰よりも遅くまで仕事をしたり、のべつ幕なしにメールを送ったりしたら、部下は残業したり終始メールを送ったりすることが大切なのかと思い込んでしまう。
そうやって部下も残業するようになれば、疲れ果てて作業効率が低下する。
その状態は、エンジニアに求められる緻密な知識労働には特に差し支えることになる。

複数の管理者の管理

スキップレベルミーティング

2 ランク以上離れた部下を管理する上で外せないツボの一つがスキップレベルミーティング。
「各チームの健全度や焦点の絞り方を把握すること」が目的。

部署全体の統率者が、その構成員ひとりひとりと短時間の 1on1 を、例えば四半期に一回の頻度で開く。
この方法の効能は次の通り。

  • 自分の部署の構成員ひとりひとりとの間に、少なくとも表面的な人間関係だけでも築ける
  • 部下がわざわざスケジューリングを依頼してまで尋ねるほどの価値はないと思うような事柄についても、あなたに質問できる機会が生まれる

スキップレベルミーティングで効果的なセリフとしては、以下のようなものがある。

  • 今担当しているプロジェクトで最高だと思う点は?
  • 自分のチームで最近特に素晴らしい働きをしているのは誰ですか?
  • 何か君の直属の上司に関するフィードバックがありますか?うまく行っていることでも、行っていないことでも構いません
  • 今担当している製品にどんな改良ができると思いますか?
  • 我々が見落としているのではないかと思えるチャンスがあったら教えてください
  • うちの部の業務活動は全体的に見てどうだと思いますか?改善、増強、削減できるところがあれば教えてください
  • 我が社の経営戦略で、ピンとこないところはありませんか?
  • 今あなたが持ち味を出しきれていない理由は何でしょうか?
  • この会社で働くことに満足していますか?
  • この会社で働くことに対する満足度を上げるため我々にできることは何でしょうか?

各レベルのメンバーを相手に「スキップレベルランチ」を開くのも良い。

部下である管理者たちに責任を課する

部下になった管理者たちに対して外せない目標は、「管理者たちが各自きちんと自分の職務を果たすことであなたの手間を省き、あなた自身の務めを果たしやすくすること」。

扱いの難しい、よくある状況は色々ある。

  • コロコロ変わるプロダクトロードマップ
  • 道に迷ったテックリード
  • 火消しモードが常態化

最終的にチームを難局から救い出し、前進させる責任は管理者にある。
(管理者はチームの健全性と生産性に関する責任を負っているため。)
あなたは管理者の後ろ盾として解決策の模索や実施を助ける必要がある。

機能不全に陥った組織の「デバッグ」の基本

  • 仮説を立てる
  • データをチェックする
    • 以下のような記録をチェックしてみる
      • チームのチャットやメール
      • タスク管理のチケット
      • リポジトリにあるコードレビューへのチェックインの記録、など
    • 「問題の動かぬ証拠」にはならないが、要対処の領域を指し示している可能性がある
  • チームを観察する
    • ミーティングに出席してみる
      • ミーティングは退屈だと感じるか
      • メンバーはうんざりしているか
      • 一方的に発言ばかりしているような人がいないか
      • チームの全員が出席し、ほとんどずっと皆で管理者やプロダクトリードの話を聞いているだけ、と言う定例会議はないか
    • 「退屈なミーティング」は何らかの兆候であることが多い
  • 質問をする
    • 目標はなにか、なぜ今その目標を掲げているのか、を聞いてみる
    • 「人は自分が従事する作業の目的を理解し納得していなければならない」
  • チームの人間関係をチェックする
  • 支援に乗り出す
  • 常に好奇心を失わない

期日の見積もりと調整

「何でこんなに手間取ってるのか?」と聞かれることはよくある。

作業が予定より大幅に遅れている場合はこの質問をされても仕方がない。
一方で、見積もりの期日を過ぎてもいないのにこう言う質問をぶつけられることもよくある。
(何らかの理由で、見積もりの期日そのものに不満を抱いていたり、そもそも見積もりを命じなかったりした上層部が、まだ何の問題も生じていないのに勝手に焦って聞いてくる、というケース。)

スケジュールの見積もりやその調整の結果を相手に知らせる時には、常に強気の姿勢が必要。
対象のプロジェクトが極めて重要、あるいは所要時間が二週間を超える場合にはこの姿勢は崩してはいけない。
「技術部長はスケジュールの見積もりに関しては強気で押し通すべし」が鉄則。
チームがプロジェクトの内容や時間的尺度に沿った見積もりを行えるよう、そのプロセスに関する交渉をするのも技術部長の務め、と言える。

完璧に正確とは言えない見積もりでも役に立つことは少なくない。
見積もりをすることで、現状では解決のつかない複雑な問題をチームの上位レベルの処理事項にできたりもする。
事前の見積もり作業で、未知の要素を大幅に削減できるケースもある。

「ある程度の見積もりは必要なのだ」と現実を受け入れ、様々な見積もりの手法を試し、自分たちの役に立つものを選ぶこと。
(スプリント単位でプロジェクトを進めていく方が時間を取られずに済む、とも言い切れない。)
見積もり作業そのものはチーム全体で習慣化することを忘れずにやること。

それでもなお「何でこんなに手間取ってるのか?」と聞かれてしまうことはある。
そう言う場合は以下のようなケースが考えられる。

  • 誰かストレスを募らせている人がいる
  • デリバリ可能として提示したスケジュールよりも仕上がりを早めろと誰かに催促されている

そう言う相手には共感を示しつつ、別の角度から力添えをする意思があるところを見せると、「感情的な非難」から「理性的な対応」へと視点を変えてくれるかもしれない。

大事な期日を厳守するためには、チームの管理者やテックリード、事業部門と手を組み、プロジェクトの目標に沿った範囲の削減も恐れずに断行すること。
技術的に「あるといいもの」だけでなく、製品としての機能にも必ず目を向けること。

やりにくい仕事ーロードマップにまつわる不確実性への対処

ロードマップにまつわる不確実性に対処する戦術:

  • 自分の会社の規模や成長段階を考え合わせて、方針転換の可能性を現実的に受け止める
  • たとえ遠大なビジョンを実現できなくても、ある程度の結果を出せるよう、大きなプロジェクトを一連のより小規模な成果物に細分化する方法を検討する
  • 技術プロジェクトを「そのうちきっとやる」と言うなど、チームへの安請け合いは禁物
  • チームのスケジュールの二割は「システムのメンテナンス作業」に割り振る
  • 技術プロジェクトの場合も、本当にはどの程度重要なのかを厳密に検討するべき

技術力の点で時代遅れにならないためには

情報収集のための質問

チームの技術的投資を監督する責任を負っているからといって、管理者自身が調査をする必要はない。
この種の投資に関する的を射た質問を投げかけてチームを牽引するのが良い。

  • 現在どのようなプロジェクトが進行中で、すでにどのような予想外の出来事やボトルネックに遭遇したか
  • チームの面々はシステムの今後についてどう考えているか
  • エンジニアの増員を要請しているのはどのチームか。増員妖精の理由は?
  • 作業の進捗がはかばかしくないのにスループット改善のための増員は不要、としているのはどのチームか
  • なぜ今、特にこのプロジェクトを推奨するのか

明確で詳細な要求を

部長ランクの管理者は、チームのシニアエンジニアを質問ぜめにしなくても明確で詳細な要求ができるよう、自分の組織の技術を十分把握しておく必要がある。

技術的スキルの時流に取り残された管理者は、上層部とチームの間を行ったり来たりする連絡役しか果たせなくなってしまうことがある。
(上からの要請をふるい分けできず、チームに丸ごと伝え、それに対するチームの回答を上に返すだけ。)
これでは何の付加価値ももたらせない管理者に成り下がってしまう。

経験で培った独自の勘を拠り所に

  • コードを読む
  • 自分が疎い領域を選び、その領域に詳しいエンジニアに解説を仰ぐ
  • ポストモーテムに同席する
  • ソフトウェア開発のプロセスに関する業界のトレンドを常に把握する
  • 社外でも技術系の人脈作りを
  • 「学び」は決してやめてはならない

経営幹部

『High Output Management』によると、経営幹部の職務は次の 4 つ。

  • 情報の収集・共有
  • 注意喚起
  • 意思決定
  • ロールモデル

技術担当バイスプレジデント(VPoE)とは?

通常、 VPoE は技術系管理者のランクの最上位にあたる。
VPoE は一般に、人員、プロジェクト、チーム、部課の事情に精通したベテラン中のベテラン管理者であることが期待される。

CTOVPoE の 2 つのポストを設けている会社では、

  • CTO:「より広範な戦略」と「社内での技術部門の位置付け」に焦点
  • VPoE:「アイディアの実現」に焦点

と言う形に役割を分けているのが普通。

VPoE は管理責任も負っている。

  • 開発のロードマップと雇用計画をすり合わせる
  • チームが会社の期待に照らし合わせて納得のいくレベルに成長するためにはどのような展開が必要か、計画を練る
  • 雇用の担当部署と緊密に連携して人材の募集や採用を行う
  • 履歴書によるスクリーニングや面接が順調に運ぶよう監督することもある
  • 既存の優秀な人材の発掘とさらなる教育を行う
  • 人事部との連携による技術管理者の研修・人材開発資源を提供する

などなど、VPoE の職責は広く大きな視野が求められるものと、細部への配慮を要するものとが混在している。
VPoE を外部から新たに雇い入れるのは容易なことではない。
このポストに適任なのは、組織の人間関係や運営体制、作業状況をすばやく把握でき、管理者としても統率者としても高い見識を持ち、周囲の人々の信頼を勝ち取ることのできる人が望ましい。

VPoE はプロダクトチームとも緊密に連携しなければならない。
ロードマップが現実的であるか、事業目標が「技術部門にとって達成可能な目標」の中にきちんと反映されているか、確認しなければならない。

CTO とは?

CTO は技術系の役職ではない。
技術部門のランクの最上位でもなく、エンジニアがそのまま昇進を続けて行き着く先の最終目標でもない。
(実際に業界で CTO を務めている人たちを見回してみると、就任の経緯も職責も千差万別。)

CTO とは、その会社が現在の成長段階で必要としている戦略的技術系幹部。

  • 戦略的:長期的視点に立って考えを巡らし、事業の未来と、それを可能にする要素とを計画する作業を支援する仕事
  • 幹部:戦略的思考の成果を実現、運用可能にする作業を支援する(そのために問題を細分化し、その対策を部下に実行させる)仕事

CTO は会社のためを思い、事業を理解し、技術というレンズを通して事業戦略を立てられるようでなければならない。

事業戦略の決定において自分の影響力を保持するためには、会社や事業に大きな影響を及ぼす問題の解決に人員を割り当てるようにしなければならない。
他の経営幹部は技術部門に関してそれぞれに独自の考えやニーズを持っている。
技術チームが自分たちならではのニーズやアイディアを活かせない単なる実行部隊にされてしまわないよう CTO が守ってあげる必要がある。

CTO は何よりも事業戦略に関わる仕事を最優先すべし。
もしもあなたが、会社が推し進めている事業を第一に考えることができなければーつまり、大部分の人員を効率よく動員してその事業に当たらせるという CTO の究極の責任を進んで引き受けられないのであればー CTO に向いているとは言えない。

優先順位の変更

経営陣からいきなり優先順位の変更が申し渡されることは時としてあるもの。
現場チームの日々のスケジュールから遠く隔たった所にいる首脳陣は、チームが優先度リストにしたがってコツコツと作業を進めている現実を忘れてしまうことがある。

チームが次なる「最優先事項」に取り掛かる前に現在進行中の作業を完遂する必要があると見極めたら、そのことを上層部へ明確に伝えなければならない。
焦点の当てどころを変えてはならない場合にしても、変えるべきではない場合にしても、あなたは上、あるいは下に、それを明確に伝え、あくまでも説得する覚悟が必要。

大事なことで上司に動いて欲しければ、最低三回は説明を繰り返す必要がある。
(これをルール化せよ、ってことじゃなく、そういう傾向があるのが実情、とのこと。)

やりにくい仕事ー悪いニュースを伝える

  • 大きなグループに血の通わないメッセージを一斉送信するのは禁物
  • できる限り個別に話す
  • 言語道断だと思うようなメッセージなら、伝達役を立てても構わない
  • その「悪いニュース」が招きそうな事態を直視する
  • 自分ならどのように告げて欲しいのか、想像してみる

他部門を統率する幹部仲間

部門の枠を超えた協働をそつなくこなすのに必須の要素は 2 つある。

  • 相手の技量に敬意を払う
  • 「根本レベルの信頼」を築く

幹部仲間の専門分野を尊重するべき場面では、しかるべき敬意を表する。
たとえその人の管理の仕方やスキルの応用の仕方に賛同できなくても、あなた自身のチームに直接影響が及ばない状況なら放っておく。

『The Five Dysfunctions of a Team』で「チームの 5 つの機能不全」の一つ目として「信頼の欠如」をあげている。
幹部仲間は組織のために最前を尽くそうと鋭意努力している、と信頼することが大事。

すごい上司、ひどい上司ー恐怖で支配する上司と、信頼を基盤に導く上司

短気なところやトゲトゲした物言いが部下を震え上がらせてしまうことがある。
すると、部下たちは失敗の責任を問われたり人前で批判されたりするのを嫌って、リスクを冒さない方向へ、失敗を隠す方向へと走ってしまうことがある。

恐怖の文化を改めるポイントは以下の通り。

  • 心を通わせる習慣を
  • 謝る
    • 自分の言動が他者に悪影響を及ぼしてしまったことを認める
    • 間違いを犯しても大丈夫だが、人の感情を害したら謝罪が必要だということを皆に教えるロールモデルになること
  • 好奇心を持って
    • 同意し難い状況や事柄を前にした時は素直に質問する
  • 部下を「悪者」にせずに責任を取らせるコツを身につける

トゥルー・ノース

トゥルー・ノース とは、その部門で真に卓越した手腕がどのようなものか、その基準値を自ら示すこと。
技術部門の幹部にとっては、以下のようなことがトゥルー・ノースとして挙げられる。

  • チームに製品をデザインさせ、リリース可能な状態にまで仕上げさせること
  • レビュー、運用、テストにおいて、合意済みの方針を尊重すること
  • 顧客に体験してもらえる状態に達していないと判断した要素は、リリースしないこと
  • 誇りにできるようなソフトウェアやシステムを作り出すこと

意思決定の際に評価基準となる指針を定めて、実際に現場でどう応用するかは技術部門に任せる。
すると、詳細を逐一掘り下げて考える時間的余裕のない状況でも、長年磨き上げてきた勘を働かせて素早い意思決定を行うことができる。

文化の構築

「構造」や「プロセス」といった概念は、スタートアップの企業文化を信奉する人々の目には「無意味」とか「有害」と映ることが多い。
こうした「構造」を疑問視する人を相手に議論する時には、多少攻め手を変えるのが良い。
具体的には、以下の要素を前面に押し出して話を進める。

  • 「構造」そのものではなく「学習」を
  • 「プロセス」そのものではなく「透明性」を

私たちがシステムを構築するのは、構造そのもの、プロセスそのものに価値があるからではなく、成功も失敗もひっくるめて経験から学びたいから。
成功例を共有し、失敗例から得た教訓を色眼鏡を通さずに素直に表現し、共有したいから。
長期的に見て、こうした学習と共有を抜きにしては、組織の安定も規模拡大も望めない。

組織構造を嫌って「無構造」を装う集団には隠れた権力構造が生じがち。
(『The Tyranny of Structurelessness』。)

無構造の集団でもうまく機能しうる状況としては、以下の 4 つがある。

  • タスク指向の集団
  • 比較的均質なメンバーから成る比較的小規模な集団
  • コミュニケーションが密な集団
  • スキルの専門性が低い集団

フルスタックエンジニアを採用し続けていれば、スキルの専門化は進まず、チームの均質性が高まる。
メンバーの立場が横並びになるため、コミュニケーションは円滑に運ぶ。
そして、技術チームは製品部門や創業者の単なる「実行部隊」と化し、極度のタスク指向に陥る。

構造を持たない組織は次のいずれかの状況に陥るのがオチ。らしい。

  • チームの意に反してやがては自律性の低下を招いてしまう諸々の特徴を持つようになる
  • 隠れた階層と権力の力学に振り回されるようになる

構造を持たないチームは技術的な意思決定やプロセスでも壁に突き当たる。
(スパゲッティコードが生じがちなのには相応の理由がある。)

構造とは、我々がいかに規模を拡大し、いかに多角化を図り、複雑な長期の仕事をいかに進めるか、といった仕組みや筋書きにほかならない。

自分の役割の見極め

まずは、あなたが舵取りしている乗り物の大きさを見定めてみること。

  • 社員数
  • 創業からの年数
  • 既存のインフラの規模
  • リスク許容度

会社が成長し、年数を重ねるにつれて、その構造も成長していくもの。
「無構造」がチームにもたらす価値と、「無構造」のせいで望ましい人材を逃すことから生じる損失とを天秤にかける必要がある。

不都合が生じたら、その要因となった現実のあらゆる側面を徹底分析するべし。
なんらかのパターンが見つかれば、それが構造の創出や改善の好機となるはず。

コアバリューの活用

  • 担当部署の文化を定義すること
  • 会社やチームの価値観をプラスの形で体現している社員を褒めることによって、文化を強化する
  • コアバリューを採用面接のプロセスに組み込む

職能の枠を超えたチーム

プロジェクトの成功に必要なあらゆる要因を一つのチームにまとめ上げることで、メンバーが目前のプロジェクトに専念しやすくなり、組織全体のコミュニケーションもはるかに円滑になる。

担当分野を同じくするエンジニアだけからなる技術志向のチームでは、技術力の優劣に目が向きがち。
職能の枠を超えた製品志向のチームではリーダーシップの焦点の当てどころが異なり、対象の製品に関して優れたセンスを発揮できるエンジニアや、機能を迅速かつ効率的にデザインできるエンジニア、他部門とのコミュニケーションに長けたエンジニアがチームリーダーとして頭角を現す傾向にある。

これはどちらの構造が優れている、という話ではない。
「職能の枠を超えた製品志向のチーム」と「担当分野を同じくするエンジニアだけから成る技術志向のチーム」という風に、焦点の当て方が二通りあることを知っておき、環境や状況に即した方を採用すれば良い。

意思決定のプロセスから個人的要素を排除するー実践的アドバイス

コードレビュー

  • コードレビューに期待できる効果をきちんと理解しておく
  • コーディングスタイルの問題には lint プログラムで対処する
  • 未処理分のレビューリクエストには常に目を光らせる

稼働停止の事後検証

  • 犯人を名指しし問い詰めたい気持ちは押しとどめる
    • メンバーが失敗を恐れるようになるだけなのでやめる
  • インシデントを巡る状況を吟味し、経緯や背景を把握する
  • 事後検証の成果は現実的な視点で取捨選択する
    • 事後検証で特定された問題点は全て解消しなければならない、という印象を与えてはならない
    • 間違いなくハイリスクで今後問題を引き起こす可能性が極めて高い課題を一つか二つ選ぶ
    • 現時点ではとりあえず放置しても構わない課題を見極める

アーキテクチャレビュー

チームが必要とみなしそうなシステムとツールの大きな変更はもれなく アーキテクチャレビュー の対象にする。
アーキテクチャレビューの目的は、「大きな変更についての情報を関連グループ内で共有し、そうした変更がもたらしかねないリスクを明確にしておく」こと。
あらかじめ次のような質問を投げかけて、答えを用意しておいてもらうと良い。

  • この新しいシステム・言語を使いこなせる人は、チームに何人いますか
  • この新しいシステム・言語に関わるチームの生産の基準はもう決めましたか
  • この新しいシステム・言語をチームに公表し、メンバーに使用法を習得してもらう訓練のプロセスはどのようなものですか
  • この新しいシステム・言語の使用上の注意点がありますか

アーキテクチャレビューを実施する際の指針は以下の通り。

  • アーキテクチャレビューの対象としてふさわしいのはどのような変更なのかを明確にしておく
  • アーキテクチャレビューの価値はその準備段階にある
  • レビューの担当者はよく考えて選ぶ
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.