SIer / SES / ソシャゲ / B2B Webサービス、と多種多様な企業でプロジェクトやチームのリード/マネジメントをやらせてもらってきたが、マネジメントの成否は「どんな準備をしてきたか？」でだいたい決まる、という考えに辿り着きつつあるので、フィードバックを期待してみつつShout it out loudしてみる。考えを纏めるキッカケを与えてくれたこちらの記事に感謝です。

※「自社Webサービスを開発・運営しているエンジニア組織で、新機能開発や修正などのチーム/プロジェクトを率いるマネージャー」を想定した話です。

個人的に大事にしていること

僕は「状況に応じて」とか「臨機応変に」といった言葉はマネージメントのお仕事では極力意識して口にしないようにしている。それらを完全否定するわけではないし、突発的・想定外な出来事に対処する為に急な判断で乗り切らなければいけない場面も当然ある。あるんだけど、それは「あくまで突発的・想定外な出来事が起こってしまった時の話」であって、マネジメントにおいて臨機応変というのは本当に最後の手段というか、臨機応変を頻繁に必要としている時点で、既にマネジメントが何処かで道を誤ってしまっている事を示しているような気がしている。

新規事業という突発事案多めの組織でマネージメントをやらせてもらった経験もあるけど、臨機応変が連続した結果自分の失敗に気付いたという経験が昔も含めてこれまでに2回はあった。その失敗経験からマネジメントも技術、感覚だけに頼らない準備と実践（特に準備）が超重要 と考えるようになった。

PMLCに基づいたフェーズ分類

僕は新しいプロジェクトが走り始める/走りそうな話が出てくる　というタイミングで、まずそのプロジェクトを以下のようなフェーズに分類するようにしている。
　1. 立ち上がり（INITIATION）
　2. 計画（PLANNING）
　3. 日々のお仕事とチーム運営（EXECUTION）
　4. リリース/クロージング（CLOSURE）
この4フェーズ分類は「PMLC (Project Management Life Cycle) Model」から拝借している。タイトルにスタートダッシュと書いたが、この4フェーズに当てはめると「1. 立ち上がり（INITIATION）」がスタートダッシュを決めるべきフェーズだ。

（The Agile PMLC (Project Management Life Cycle) より）

アジャイルやプロジェクトマネジメントの文脈で紹介される手法なので、メンバーのメンタリングやメンバー/マネージャー双方の感情面への対処については基本的に触れられていない。感情面に関する話を多くすると話がエモい内容になりがちなので、なるべくこの記事では触れないようにしようと思う。

立ち上がり（INITIATION）を重視する理由

僕が立ち上がりを重要視するのは、まだ感情問題に左右されにくいフェーズで、極力エモさを排除した考え・判断を文書化しておけるのは準備のタイミング　と考えているのが一番の理由だ。

最初に冷静な頭でその時点でベストと信じている事を定めておけば、実践段階で失敗や想定外が起こってしまった際の頼れるdiff（差分）になる。マネージャーだって1人の人間なので、24時間365日冷静沈着でfor the teamな判断を下せるわけではない（出来る人がいたらごめんなさい）。ライブや夏フェスに行った翌日などは「今からならまだ間に合う、ワイもKISSになりたい！ワイがKISSや！今日から顔面ペイントプログラミングや！！」という妄想に取り憑かれ仕事が手に付かなかったりするし、深夜便で海外旅行に飛び立つ日なんかはほぼ「有給がもったいない」という理由 だけ で出社しているので、演技力MAXで仕事のフリをしているだけだったりする。

僕は何事も完璧タイプのマネージャーでは無いという自信があるので、こんな具合に判断力や集中力が弱ってしまったり、逆に頭が冴えていても失敗や想定外に遭遇してしまったりする事もゼロではない。そんな時にこそ、冷静な状態の自分が考えていた事を自分自身の補正材料として引き出せる状況を作っておきたい。周りに悩みを相談したりもするだろうけど、ダメ・スイッチはあくまでも自分の手でロジカルにOFFれるように準備しておきたい。チームで複数のプロジェクトが並行して走る予定があるのなら、マネージャー自身の負担を下げる為にも、尚更準備フェーズに注力しておくのが重要と思っている。

立ち上がり（INITIATION）でやっておくべき事

これらを踏まえて、立ち上がりタイミングでマネージャーがやるべき事は「マネージメント要件の定義」だと考えている。具体的には、「チームとプロジェクトをより良くする為にやるべき事は何なのか？をマネージャーが考え・定めた結果」がマネージメント要件の定義になる。定義すべきことは全部で4つあるが、個々のタスク・個々のメンバーではなく、あくまでプロジェクトやチームという大きめの主語で考えて定義しておく。

【定義1. "マネジメント業務" を定義する】
今後のマネージメント業務の土台・屋台骨として必要不可欠と捉えており、自分の中でブラせたくない軸を1本作っておく為にも、業務内容は最初に定義しておいた方が良い。この定義をより普遍的なものとしてドキュメント化したものが Manager Readme と位置付けている（僕も以前 自分のManager Readmeを書いて公開 した）。

- 全社の事業戦略をメンバーに正しく伝える
　- 伝えるが、より主体的に各メンバーが全社の事業戦略に関心を払えるよう働きかける
- チーム目標を考え・共有し・フィードバックを貰う。そして決める
- 各メンバーのJob Descriptionと期待値を定義する
- 各メンバーをチーム目標に沿ってタスクにアサインする
- 社内調整（業務上の障害除去）する
　- 面倒な仕事、汚れ仕事はマネージャーがやる
- 各メンバーのアイデアやアウトプットをレビューする
- 各メンバーをサポートする
　- 会社での生活
　- 成長支援、キャリアパス構築支援
- 採用活動を行う
- コードを書く
　- コードを書く仕事を業務全体の2, 3割程度は確保するように努める

【定義2. "マネジメントにおける禁止事項" を定義する】
何故禁止事項まで定義しておくかと言うと、チーム/プロジェクトで何らかの状況是正が必要になっているか？を判断する為の指針が欲しいから、というのが理由として大きい。特に「危険や不安と隣り合わせ」という状況は速やかに是正しなければならないポイントと考えている。

- 不透明Exception
　- 情報の共有・公開を怠り、チーム状態やゴールを不透明な状態にする事
- 依怙贔屓Exception
　- 依怙贔屓やどちらかの肩を持つ（そして他方を下げる）ような言動をする事
- 赤信号皆で渡れば怖くないException
　- 危険かつ過度な負担で心身を削るような行為を求める事
- 完璧なマネージャーを目指し過ぎException
　- マネージャーといっても実体は超人でも聖人君子でも無いし至らない部分がいっぱいある。という事を隠す事
　- 基本怠惰で中身はタダのビールクズ人間である、という事を認識してもらう。マネージャーが完璧である事が前提で醸成された心理的安全性は脆いもので、真に安全とは言えない

【定義3. "マネジメントミッション" を定義する】
まずキャッチフレーズを決める。何故キャッチフレーズを決めるかと言うと、自分の行動を省みる際やマネジメントについて聞かれた際の説明の際にキャッチーなフレーズが1つ合った方が便利だからだ。

自分の場合はいつも、
　「高速道路を気分よくドライブしてもらう」
という事をイメージしていた。業務にしろ自身の成長にしろ、障害が少ない道を出し得る最高速度で走りながら目標に到達してもらう事 が理想と捉え、その為に道を造り・舗装するのがマネージャーのミッションかなと思っている。

【定義4. "マネジメントミッション遂行にあたってのリスク" を定義する】
危ない高速道路ってどんな仕様か？を考えて定義する。

- 急カーブがある
　- カーブ = 非本質的な業務遂行上の障壁
　- 急カーブは事故の温床
- 峠越えが発生する
　- 峠越え = 高負荷なタスク
　- 稀に峠を爆速で走れてしまう頭文字D的ツワモノ・エンジニアがいるが、彼等の存在は例外的なものであると認識しておく
　　- 一方で、彼等には彼等が走りたいスピードを維持してもらえるように努力もする
　- トンネルを掘れたら山を登らずに済む、という視点で解決策を検討する
- 標識が多過ぎる
　- 標識 = 情報
　- 情報は精査して極力スリム化する。シンプルな労働環境を保つ。考える事が増えれば負担が増え、反比例して楽しさが減少してしまう
　　- 「イノシシ注意！」とか言われても、言われた側は困惑するだけ
　- 「無くす」のは事故を誘発するのでNG
- サービスエリアが無い
　- サービスエリア = 休息
　- 流れる汗もそのままに走り続ける爆風スランプ的世界観をメンバーに強要しない
- 工事が多い
　- 工事 = マネージャーの介入
　- 究極の理想はマネージャーなんかいなくても各メンバーが自律・自走して組織目標を達成できる事である、という事を認識する

【定義とお気持ちをメンバーに表明する】
重要なのは、1回喋ってハイ終わり　ではなく、メンバーがコメントを付けられる形式のドキュメントツールを使ってドキュメント化しておくという事かなと思っている。チーム内で言った言わない問題が起こってお互いが懐疑的な環境になってしまうのを避ける為にも、ドキュメント化は手を抜かずにMUSTで実践しておいた方が良い。

〆

「まずチームやプロジェクトが今後遭遇する場面を想像しながらフェーズ分類する」
「分類したフェーズで特に大事なのは、立ち上がり（INITIATION）のフェーズ」
「立ち上がり（INITIATION）のフェーズで、4つのマネージメント要件を定義する」
という例を書いた。

とは言え、いくら事前に準備しようとそれがそのまま当てはまる程プロジェクトやチームは甘くない、、という話は後続フェーズのPLANNINGやEXECUTIONに繋がってくるので、このあたりの話はまた機会があったら書くかもしれない（書くとは言ってない）。