概要

そろそろ年度末だし、新年度からプロジェクトリーダーとしてやっていく人もいるかと思うので、プロジェクトリーダーはどういうことをしないといけないかと、心得的なものを投稿しようと思います。今業界全体的にリーダー不足になってるんで、プロジェクトリーダーという役割について興味持ってくれる人が増えると嬉しいです。
※ここでのプロジェクトとはシステム開発等IT関連のプロジェクトを指すものとします。

軽く自己紹介

2013年頃から7年くらいプロジェクトリーダーとして請負業務などの仕事をしてきました。最近はプロジェクトマネージャーも兼ねてやっていたり、うまくいっていないプロジェクトにコンサルとして入って立て直すというようなこともしています。

レジュメ
https://www.resume.id/branch

まずは結論から

プロジェクトリーダーの使命

「担当するプロジェクトを成功へと導く」

「プロジェクトの成功」とは

無理なく遅延なく、見積もった費用や期間に収まる形で全てのタスクを完遂する
品質の良いシステムを作り上げる
自分自身や各メンバーが成長できる
メンバーの誰も疲弊せずに完遂できる

そのためにやるべきこと

ゴールの設定を行う
- KGI / KPIの作成
- 作るべきシステムの「あるべき姿」（完成イメージ）の共有
プロジェクトを進めるために必要なものの整理をする
- バージョン管理やコミュニケーションツールは何をつかうか
- ドキュメント類はどこに配置するか
- 開発環境や検証環境をどのように作成・調達するか
- 何を整理してお客（またはプロマネ）と合意する必要があるか等
全てのタスクの洗い出しを行う
- 上記の整理事項もタスクとして洗い出す
- 荒すぎず、細かすぎない粒度で洗い出せるのが理想
  - それらのタスクの完了を定義する
- 行うべき全体の内容を把握する
- それらのタスクの緊急度・優先度を決める
スケジュールを管理する
- タスクを完了させるために必要となる日数を見積もる
- KPIなどからマイルストーンを設定する
進捗状況を随時把握する
- 作業状況の見える化を行う
- 進捗の測定方法は事前に決めておく（「なんとなく50%」とかやってると後々痛い目にあう）
- 全員の状況を把握して、必要に応じて担当のアサインを変えたり、スケジュールの調整を行う
- 定期的に棚卸しを行う
品質を担保する基準を作る
- テスト計画や、行う内容の整理
- 品質が担保されていることの分析および説明責任
  - 後で分析できるように以下を記録する
    - 設計書やコードのレビュー記録
    - 抽出したバグの記録
課題やリスクを洗い出す
- それらの優先度・緊急度も常に把握しておく
- 先手先手で課題やリスクを解決するための行動を起こす
メンバーよりも一歩先の作業を検討する
- みんなが実装をしている段階でテストの方法を検討するなど
メンバーに役割を指名する
- 一人ですべてを見きれない場合に責任者を決めてその人に特定範囲の権限を与える

プロジェクトリーダーとしての心得

信頼されることを第一に行動する
- 顧客(プロマネ)から信頼されないと厳しい目で見られたり過干渉が発生してプロジェクトが回しづらくなる
- メンバーから信頼されないとプロジェクトは崩壊する
偉そうにしない
- 謙虚でいること
  - 別にリーダーは偉くもなんともない（ひとつの役割にすぎない）
    - ぼくは上司・部下・先輩・後輩・新入社員関わらず敬語で接するようにしています
  - 意見やダメ出しにちゃんと耳を傾ける
- みんなを尊敬する
  - 相互尊重の精神
  - やってもらった仕事に対しては感謝を伝える
  - 褒める（とっても大事なこと）
メンバーを信頼する
- 作業を指示するのではなく、仕事を任せることを心がける
命令ではなく依頼。指示ではなく牽引
- リーダーが「リードする人」という意味だというのを常に心がける
タスクの優先度/緊急度は臨機応変に変更する
- 「今やるべきこと」を常に把握してメンバーに仕事を割り振るのがリーダーの仕事
- 常に「次何をするべきか」はメンバーも把握できる状態にしておく
  - それがわからない状態は不安になったりモチベーション低下にもつながる
主体的に動く
- 指示待ちの状態はリーダーとして動いている場合基本はなりえないと思う
- 顧客が決めかねているといったケースでもいつまでにfixする必要があるか当事者意識を持って行動する
目標を共有する
- いつまでにやるべきかを常に共有してゴールを目指す
- 「最悪リスケできるから」を前提で動いてはいけない(かといって無理させるのは禁物）
褒めるときはみんなの前で、叱るときはこっそりと
- 叱るときはきちんと叱る
  - ただ声を荒げて感情的に怒るのは業務上では最悪の行動
  - ちゃんと理由を告げて大人の対応で叱る
- 褒めることを忘れてはいけない
決断はスピーディに、リーダー自身で行う
- 意見は聞くが最終決断はリーダーがする
- 間違えた決断でも決断しないよりはマシ（曖昧な状況が一番メンバーのモチベーションが下がる）
- 間違えた決断だとわかったらすぐに訂正すればいい（状況を随時把握できていればそれも早めにできる)
決断には責任を持つ
- 間違えた決断をしたとわかっても放置せず訂正するまでが「責任」
「なんとなく」で決断しない
- 「なんとなく」で決断したものは後になって「やっぱりこの方が」となるリスクが高く、メンバーを振り回す結果になる
  - 「なんとなく全員朝と夜ミーティングした方がいいんじゃないか」とか
  - 理由が薄いから形骸化もしやすく、無駄な時間を費やす結果に終わることが多い
- KPTなどの振り返りで多くのメンバーが感じている問題や、数値として現れている課題・リスクに対して分析をした上で対策は実施する
依頼事項はきっちりと伝える
- 顧客、内部どちらにもきっちりと理由や背景も伝えてお願いをする
- 「察しろ」はNG。言ってないことと同じ
メンバーの失敗を責めない
- 失敗を責めると失敗が表面化しないチームになる
  - むしろ「報告ありがとうございます」と言うくらいがちょうどいい
- 失敗は個人の責任にするのではなくチームの責任として捉えて一緒にリカバリー策を考える
失敗を顧客に謝ることはリーダーがやる
- リスクコントロールの一貫としてリーダーが把握しておくため
  - 以下を説明する
    - 発生している事象
    - それに伴う影響範囲（システムの影響・ユーザーの影響）の説明
    - 対応しようとしている方針（合意をとる）
    - 再発防止策
      - すぐに思いつかない場合は「後日報告する」旨を伝える
- メンバーはリカバリーするための対応に専念させる
- 常にメンバーの味方となって対応をする
なんでもかんでも共有はしない
- 何でも「みんなに共有する」のが正しいとは限らない
  - 混乱する原因となる情報は自分の中に留めるか、限られたコアメンバーなどに留める方がいい
  - 事実は共有する
    - 進捗が遅れている、現状こういうリスクがある、など
  - 推測は共有する範囲を関係者などに留める
    - なんとなくあの機能で重いバグが出そうといったまだ根拠がはっきりしてないものなど
- ミーティングも関連するメンバーを招集するに留める
  - 全体進捗の意識合わせなどは全員参加の方がいいとは思う
  - 全員でミーティングしても時間の無駄になるケースの方が多い
ナレッジの共有は常に意識する
- 環境構築やハマリポイントなどは文書化しておく
- ただ何でもかんでも文書化すると工数ばかりかかるため「何の情報を文書化するか」はリーダーが判断する
ハッタリをかます(自信がある振る舞いをする)
- ハッタリ力もリーダーとして大事
  - 内心「終わらない」と思ってても、それを表面化させるとチーム全体が不安になる
    - 本当に「終わりそうにない」ならそれを愚痴る前にリスケなど何かしらの行動を起こすべき
  - チームを不安にさせないというのもリーダーの大事な仕事
- 発言は自信を持ってある程度声を張る
  - 自信のない人の発言はチームや顧客から「大丈夫かな」と思われる
  - 間違えてたら後で訂正したら良いだけだからその場では断言するくらいがちょうどいい
一人で全部やろうとしない
- 一人でやれることには限界がある
  - 抱え込んだ結果プロジェクトが回らない状態は最悪のケース
- 機能や工程などで責任者を任命して仕事を任せる
  - 新人に任せる場合はそのスキルに応じてサポートはする
  - 特定のタスクの洗い出しのみを任せるなど、任せるスコープはその時に応じて様々
  - 任命する場合は権限の範囲まで伝えることが大事（じゃないと動きづらい）
- 進捗の把握も、自分で全部確認するよりメンバーからエスカレーションしてもらう仕組みを作る方がいい
  - 進捗の測定方法を共有できていればメンバー自身で自分の進捗の把握ができる
  - 「失敗を怒らない」を徹底していれば進捗が悪い場合もメンバーから自発的に伝えてくれる
相談ベースで動く
- 「方針」は予め提示できる状態にした上で「こうしようと思う」という形で動く
- 決定するのはリーダーだが、いきなり決める前に方針などはメンバーにも頭出しする
  - その結果有用な意見がもらえることも多い
- 顧客との対応に関しても同様
- いきなり「こうします」と言われたら（本当は別の方法がいいのに）と思ってても了承してしまうことの方が多い
  - 結果的に不満が出る可能性がでてくる

プロジェクトリーダーとは

ざっと結論の一覧を書きましたが、ここからは詳細を補足していくような形で書いていこうと思います。
上にも書いた通り、プロジェクトリーダーの使命は**「プロジェクトを成功へと導く」**ことにあります。ここでいう成功は、単に納期に間に合うといったものだけではなく、品質がよかったり、チームが疲弊していないといったことも条件に挙げられます。

ウォーターフォール型で大規模開発をしてたときには、プロジェクトマネージャーとプロジェクトリーダーの作業が分かれ、プロジェクトマネージャーが「顧客やパートナーとの調整」や「プロジェクト全体の管理」をやり、プロジェクトリーダーが「プロジェクトマネージャーへの報告」「担当するプロジェクトの管理」をするというような住み分けがされていましたが、アジャイル開発で5〜10人規模でやるようになってからは、プロジェクトリーダーがプロジェクトマネージャー業務も兼ねるというケースが増えてきたように思います（単に人手不足だからかもしれないけど）。

なので、ここでは「顧客との調整」もプロジェクトリーダーの役割としちゃいます。

基本的な仕事の内容

プロジェクトによって役割は多少は変わるかもしれませんが、基本的には以下のことに責務を持ちます。

ゴールの明確な設定
要員計画
必要なツール類の整理
スケジュールや進捗の管理
メンバーの役割の割当
リスク管理
品質管理
チームビルディング

ゴールの設定

これはもともとはプロジェクトマネージャーが行う責務ですが、やるケースも考えてこちらに記載しておきます。

チームで作業をするにあたって、まず大事なのはゴールの明確な設定です。以下のポイントに沿って作るものの「あるべき姿」を共有します。

ぼくらは何を作ろうとしているのか
それは何のために作るのか
それによって何が解決するのか
それは誰のために作るのか
それの重要なポイントはどこなのか
それはどう使われる想定なのか
それをいつまでに作るのか

その他、どういう性能が求められ、どういうUI/UXが求められているのかもなるべくイメージしやすい状態に落とし込んでいき、PRD(Product Requirements Document)として皆が参照できる場所に配置をしておきます。プロジェクトの大きさに関係なく、ペライチくらいの記述でもいいのでなるべくは作る製品のイメージを明確にするという点で作成した方がいいです。

PRD: https://note.com/miz_kushida/n/n7e35a2a2b370

受託の場合、これらは顧客から「納期」や「要件定義書」という形で提示されることも多いです。「何月何日までに検証まで終わっていてほしい」と言われた場合、それがひとつのゴールになるでしょう。ただ、具体的なイメージのヒアリングや、それが実現可能かどうかを検証したり、あるいはどのように実現するか検討したり、無理な場合いつまでなら可能かを調整したりする必要があります。

また、見積もりの前に、以下のことも整理して顧客と合意をとっておきます。

非機能要件
- 可用性、性能/拡張性、運用/保守性、移行性、セキュリティ、システム環境/エコロジー(これは決めないことが多いけど）
環境
- オンプレまたはクラウドの場合どこを使うか
開発言語やフレームワーク
- 新規の場合だいたい「こちらがわで決めていい」にはなります
最終成果物
- ソースコード、検証項目書など、最終的に作成される成果物
品質担保
- どこまで担保するか（たとえば単体試験の場合カバレッジを気にするかとか）
利用するツール類
- gitとか、タスク管理ツールとか、ドキュメントの執筆とか
リリース手段
- CIで自動化するかとか、その頻度とか

工数の見積もり

ゴールとして提示された期限で実現可能かを検証するために、工数の見積もりを行います。
見積の手段としては以下のようなものがあります。

ストーリーポイント法（アジャイルでよく使われる）
ファンクションポイント法
三点見積法
二点見積法
KKD法

いずれの方法をとるとしても、まずは「何を作るのか」をある程度明確にしておく必要があります。顧客（あるいは、自社開発の場合は企画）からどういうものを作るのかをヒアリングし、そこから必要な画面数や操作数、項目の数、サーバーサイドの処理数、扱うデータの数、エラーハンドリングなどの数（改修の場合は影響範囲も）を推測して列挙します。
決まっていない部分は「リスク」として盛り込みます。

これはあくまでぼくのやり方なのですが、だいたいは実装するソースコードを思い浮かべながらまずはストーリーポイント法＋二点見積法で見積もります。
(ソースコードとか思い浮かばん！って場合は、設計書とかテストなど、ある工程から想定して算出するでいいと思います）

ストーリーポイント法
https://www.ryuzee.com/contents/blog/3716

二点見積法
https://dskst9.hatenablog.com/entry/2017/07/09/000833

各タスクの工数 = [楽観的見積もり] + [不安量]
不安量 = ([悲観的見積もり]-([楽観的見積もり]+[悲観的見積もり])/2))^2
合計工数 = [楽観的見積もり合計] + sqrt([不安量の合計])

まだ未決定な箇所がある場合にはリスクとして[悲観的見積もり]に積みます。
たとえば、実装工数を以下のように見積ったとします。

タスク	楽観	悲観	不安量
画面作成	5sp	15sp	25sp
API作成	3sp	8sp	6.25sp
合計	8sp	23sp	31.25sp

なので、工数は「8sp + sqrt(31.25sp) ≒ 13sp」
上記はあくまで「実装」で思い浮かべた工数なので、次は行うべき内容によって以下の比率で再計算します。

「要件定義」:「基本設計」：「機能設計」:「詳細設計」：「プログラミング」：「単体試験」：「結合試験」：「総合試験」 = 1:1:2:2:2:2:3:2

たとえば、詳細設計から結合試験までを行う場合なら、 13sp + 13sp + 13sp + 19.5sp = 58.5sp と計算します。
スクラムでやるなら1スクラムあたり何sp消化できるか、ウォーターフォールなど日数を見積もりたい場合は、そこから1spが何人日かを予め定義しておいて、実際の工数を割り出します。

(1スプリントで10sp消化できるとした場合は6スプリントかかる計算になるし、1sp=0.5人日とした場合は、29.5人日≒1.5人月となります)

なお、この比率は求められる品質レベルから算出します。
たとえばドキュメントをかっちり書く必要があるのなら設計の比率を上げる必要がありますし、メモレベルでよかったり、GitのPullRequestなどに記載する程度でいい場合は比率は下がるでしょう。テストの工数も同様です。なお、上記のは「ある程度かっちりやる」場合の比率です。

比率を算出する際、ぼくはよく以下の機能を作る場合にそれぞれかかる工数を考えます。

画面を３つ作成
- リスト画面と詳細画面と新規作成・更新画面
1データあたりの項目は10個程度
新規作成と更新ではそれぞれの項目に入力チェックがある
- プライマリキーによる整合性のチェックも行う

これの実装を(コードレビュー含め)３人日としており、この設計書を書き起こす場合や、試験をする場合にどれくらいかかるかを求められているレベルから想定して比率を決めています。
(また、アジャイルだった場合はやりながら実績と合わせるために比率の調整もしていきます)

見積もりにかける時間

「結構時間かかるんじゃないの」って思うかもしれません。実際、結構時間はかかります。
規模にもよりますが、だいたい3kstepくらいのシステムを作る場合でも1〜2日程度時間をつかっています。

ここで見積もりを誤ると、その後の計画にも影響します。最悪デスマーチになるためとても重要で責任の重い工程です。
なのでわかる範囲でなるべく細かくやるべきことを洗い出して、工数に積みます。

見積もり時の注意点

必ず見積もり時の前提条件をある程度細かく書き、先方とも連携＆合意をとりましょう。
その前提から大きく外れた場合は再見積もりをしないと、どんどんと工数は膨らみます。工数が増えても再見積もりしない限りはスケジュールは変わらないので、結果全員が疲弊することになります。

また、バッファを設けることも重要です。ぼくの場合は、上記の見積をした後にだいたい**20%**をバッファとして積むようにしています。これは「プロジェクトの8割は見積もり時よりも±2割工数の差異がでる」というのをどこかで読んだので（どこだったかは忘れた…)。そのバッファ内で収まる変更要望は吸収しますが、それを超える場合は再度見積もりの調整をします。
※ なお、そのバッファはあくまでもバッファなので、最終フェーズまではもともと見積った工数でスケジュールを立てます（パーキンソンの法則に陥らないようにするため）。

必要なツール類の整理

プロジェクトを進めるにあたって、必要なツールや環境などの整理・調整を行うこともプロジェクトリーダーとして重要な業務です。
最低限以下は検討します。

コミュニケーションツールをどうするか

おそらく一番重要なので、まず最初にここを決めておくことをおすすめします。メールでしかコミュニケーションをとれないと今どきはかなりきついので、SlackやChatworkなどのチャットツールを利用できる調整をした方が良いかと思います。
また、テレビ会議としてGoogle HangoutやZoomなど予め決めておくとわざわざ打ち合わせのたびに相手先へいかなくてよくなって幸せになれます。

どの環境を選ぶか

オンプレだったり、クラウドだったり、クラウドならどこを使うかといった検討を行います。
顧客から指定されるケースもありますが、それも含めて検討する場合にはそれぞれにメリット・デメリットがあるので、システムにあったものを選びます。

オンプレミス
- 強み：なんだかんだ安くつくケースが多いです。社内システムのようにそんなにアクセス頻度が多くなく、サーバー環境がすでにあるのなら、そこに載せてしまうのも十分検討の余地があります。まだまだクラウドを使ったことがないという人も多いので、その後の保守人材を探すのも楽かも
- 弱み：ITSCM(ITサービス継続性管理)の考慮が必要です(Dockerは必須だと思う)。また、バックアップなども独自に考えないといけない。社外に公開するシステムの場合は可用性についての考慮も必要です。その他セキュリティやメンテナンスなど検討すべきことが多いので正直クラウドの方が楽です
クラウド(GCP)
- 強み:AWSに比べて安くつくケースが多いです。サーバーがGAEに乗っかる場合はかなり顕著。ゼロからシステムを構築する場合はGCP一択かなとぼく個人的には思ってます。FireStore(旧DataStore)がとっても安い
- 弱み:既存システムを移管する場合、DBにやや難ありです（一応MySQL /PostgreSQL互換のサービスはあるけど、可用性に課題がでます)。GCEを使う場合は結局AWSとそんなに値段は変わらないという結果にもなります
クラウド(AWS)
- 強み:既存システムを移管する場合はAWS一択かなと思ってます。Amazon AuroraとLambdaが強力。サービスの数が膨大で、やりたいこと何でもできちゃいます
- 弱み：GCPより高くつきます。とはいえ、EC2とGCEはあんまり値段も変わらないので、そこに載せる場合はそんな弱みでもないかも。サービスの数が多すぎる（＆似たようなサービスも多い）故に、アーキテクチャの構築でかなり悩むかも
クラウド(Azure)
- まだ使ったことないからよくわからない(´・ω・`)ただ、Office製品の連携やWindows Serverの構築や移管は楽と聞いたことがあります

その他、以下のような検討も必要です。

Dockerで構築するか、その場合オーケストレーションツールをどうするかといった検討
どのように継続的に開発するか
開発環境、検証環境をどう構築・調達するか

どの言語・フレームワークを選ぶか

これも、それぞれの言語でそれぞれ強みや弱みがあります。JavaだとVMでメモリを食うからクラウドを使う場合はどうしてもある程度のスペックが必要になったり、Goだと低スペックでも十分パフォーマンス出るから安くつくけど、技術者がなかなか見つからなかったり。
あと、どういうライブラリが利用できるかも言語やフレームワークを選ぶ上で重要な要素です。
(ここは語りだすと長くなりすぎるので割愛します）

管理ツール

その他、以下は早いうちに調整すべきです。今後のプロジェクトの運営の仕方に関わってきます。

バージョン管理： Git / SVN
タスク管理： JIRA / Redmine / ZenHub / Trello
ドキュメント管理: Confluence / Google Docs / etc...
CIツール： Circle CI / Jenkins / Travis CI / Cloud Build / etc...
定義ツール： Terraform

他早い段階に決めておくべきこと

会議体：週1〜2回行うとか、そういった調整
- どのようなことを話し合うかも前もって認識を合わせておく（その後、やりながら調整）
報告：どのタイミングでどのように報告するか
各役割：プロダクトオーナーや問い合わせ窓口が誰かは最低限決めておく

要員計画

※これも本来はプロジェクトマネージャーが行う場合も多いですが
見積った工数から、期限までに終わらせるには何人の要員が必要かを算出し、調整をします。
その際、以下のことを注意して決めます。

独立した機能として並行して作業可能な数を超える人数を入れると空き時間が発生するリスクがある
人が多いほどコミュニケーションなどのコストがかかる
人が少ないと同時進行できるタスクに限界がある
人月/月＝人の数として計算すると危険

（ブルックスの法則）

また、人はそれぞれ持っているスキルが異なっているため、どういうスキルセットの要員が必要かも計画時に考える必要があります。
社内にそのスキルセットを満たせる人がいない場合には外から要員を集める必要がありますが、最近は単価が高くなってきているため、場合によっては予め顧客と調整する必要もでてきます。
(高い単価は出せない、となるとスケジュールの調整が必要になってきます）

スケジュールや進捗の管理

ここがおそらくプロジェクトリーダーとして一番重要な業務です。
進捗状況を管理するために全体のスケジュールを引きます。スクラムで行う場合にはスケジュールというのは設定しないかもしれませんが、どちらの場合でも必要なのがタスク分解です。

その際に、想定しうるすべての作業をタスクとして分解します。

未決定内容の調整
- その他調整事項
設計
実装
検証
リリース

この際、それぞれの分類に応じて進捗状況を客観的に把握できるための基準を予め決めておきます。
たとえば設計の場合、それぞれでデータ設計、画面設計、インタフェース設計、機能設計、入出力設計、レビュー、コメント反映といった形で進捗を分けることができるでしょう（設計書を書かないとしても、どう作るかの方針を決めるというタスクは発生すると思います）。7項目あるうちの4項目が終わってる場合、進捗は57%と見ることができます。期間内にどれだけの割合をこなせているかによって、進捗が見える化できます。

ただ、上記の進捗の出し方だとまだ「終わり」の基準が個人に委ねられるため、「本人は完了したつもりだけど実際は全然考慮が足りておらず、手戻りが発生して本来の進捗とかけ離れる」といったリスクが出てきます。そのリスクを軽減するために、以下のようなやり方で終わりの基準も明確にしておくことが必要です。

完了基準の意識をあわせておく（文書化しておくのがベスト)
セルフチェック用のチェック項目を各状態に作成する
- 設計で気にするべき内容を予め決めておく
それぞれの段階で中間レビューを挟む

ただ3つ目のはレビュワーの負担が増すため、その考慮もスケジュールに盛り込んでおく必要が生じます。また、全員同じ水準でやるのではなく、メンバーのスキルや経験年数に応じてやり方を変えるといった方法も有効です。

リーダーは、各メンバーの進捗状況を常に把握しておく必要があります。それがわかっていないとプロジェクト全体の進捗が予定通りなのか遅れているのかがわかりません。状況を俯瞰的に見て、進捗が遅れているメンバーのサポートをしたり、原因を見つけ解決したり、あるいは他の人にタスクを巻き取ってもらったりリスケをするなどの調整を行う必要があります。

進捗の遅れは、気付きが早ければ早いほどリカバリーはしやすく、遅いほど困難になります。
毎日の作業をこなしつつリカバリーをする必要があるのと、現在遅れが生じている＝その後もしばらく進捗が上がらないケースの方が多いため、たった1人日の遅れが出ただけでも、リスケをせずリカバリーするのには結構なエネルギーを要します。

クリティカル・パスの把握

進捗管理にもう一つ重要なものはクリティカル・パスの把握です。

クリティカルパスとは？使い方や求め方を解説
https://www.jooto.com/contents/critical-path/

クリティカル・パスの完了が遅れるとプロジェクト全体の遅れにつながるので、どこがクリティカル・パスなのかは常に把握しておく必要があります。また、他のタスクがいくら早く完了したとしてもクリティカル・パスが完了しないとその次の作業ができないため、それも考慮してスケジュールを組む必要があります。

メンバーの役割の割当

プロジェクトは、一人で回せるほど甘くはありません。プロジェクトリーダーになった初めの頃は、どうしても自分でタスクを抱え込んでしまい、「何でも自分がやる」というようになってしまいます。しかしそれは不幸な結果にしかなりません。そうやってしまうプロジェクトリーダーはメンバーからも信頼されなくなり、「自分だけ頑張ってるのに報われない」という状態を引き起こして病んでしまいます。

ぼくが見てきた中でも、優秀なプロジェクトリーダーほどメンバーに仕事を振ることに長けてました。全員がそれぞれの役割を持って作業を行い、機能をすることではじめてプロジェクトは円滑に回ります。

機能の実装などタスク単位はイメージしやすいでしょうが、それ以外にも「コードレビュー」や「品質管理」といった工程ごとに責任者を決める方がプロジェクトは回りやすくなります。
重要なことは、タスク単位でも工程単位でもいいので「振った以上はその人に任せる」ということです。

ただし、ただ闇雲に任せてもうまくは行きません。ゴールとか、作業ことにやるべきことを示すことはリーダーの責務です。それらを提示せずに仕事をふっても「無茶ぶりされた」と思われるだけなので、きちんと背景や期待している仕事内容を提示したり、意識を合わせた状態で割り振る必要があります。
最初から文書化しておくというのも手ですが、「最初はリーダーも参加してレビューをし、責任者に重点的に見てもらいたい場所を伝えながら徐々に任せていく」というようなOJT方式での任せ方も有効です。

※ コードレビューの場合は「全員で見る」といったやり方をしてるプロジェクトもよくあります。アリだとは思いますが、その場合でも「どういうところを重点的に見る必要があるか」や「なぜ全員に見てもらうのか」といった指針は初めにリーダーが提示する（あるいは誰かにその指針を作ってもらう）必要があります。そうでないとうまく機能しない結果になります。

リスク管理

リスク管理も、プロジェクトリーダーの重要な仕事です。リスクとは「将来起こりうる課題・問題」であり、円滑に回すためには前もってそれらを把握して対策を考える必要があります。

リスクには、たとえば以下のようなものがあります。

まだ決まっていない仕様がある
想定より実装が難しそうで割り当てる予定のメンバーのスキルでは作れない可能性がある
検証が難しそうな実装がある
徐々に遅延が目立つようになってきている（メンバーの残業が増えてきている）
休みがちなメンバーがおり、スケジュールが安定しない
顧客の中に意見をころころと変えてくる人がいる
連携機能を作成している会社の進捗が遅れている

これらは、それぞれ重要度や緊急度を決めて前もって対策を考えていく必要があります。
多くのメンバーは、今のタスクをこなすために将来的なリスクにまで気をもむ暇はないケースの方が多いので、リーダーが常に「いつ対策をしないといけないか」などは把握して、適切なタイミングで対策を講じる必要があります。

品質管理

品質は、プロジェクトの成功・失敗に関わる重要な指標です。いくら納期に間に合ったとしても、バグだらけでは顧客からの信頼は落ちるでしょうし、最悪は検品で突き返される可能性もあります。
また、納品する会社によっては「品質見解書」の提示を求めているところもあります。何を書くかは会社によって異なりますが、品質に厳しい会社だとIPAが定めてるような以下の内容を求められます。

定量的品質管理
https://www.ipa.go.jp/files/000004865.pdf

設計書のレビューはしたか（どれくらい行い、どんな指摘を抽出できたか）
- ページ数あたり何件の指摘があったか、それは基準値以内に収まっているか
- 指摘内容の傾向や、類似の指摘箇所がないことをどう担保したか
コードのレビューはしたか（どれくらい行い、どんな指摘を抽出できたか）
- ステップ数あたり何件の指摘があったか、それは基準値以内に収まっているか
- 指摘内容の傾向や、類似の指摘箇所がないことをどう担保したか
ステップ数あたりどれくらいの試験を行ったか（計画値と実績）
- 単体、結合、総合などそれぞれの工程で求められる
ステップ数あたりどれくらいのバグが抽出できたか（計画値と実績）
- 単体、結合、総合などそれぞれの工程で求められる
- それぞれのバグの傾向や原因の分析
- バグ抽出件数は基準値以内かどうか
  - 基準値を超えている場合、その品質担保のために何を行ったか
- バグが混入した原因の分析
  - 類似のバグがないことをどう担保したか
  - そのバグは本来どの工程で抽出すべきもので、いつ抽出されたのか

これらの報告書を書くためには、それぞれの工程のレビュー時間や指摘内容を記録しておく必要があります。
また、ウォーターフォール型の場合は工程ごとに指摘内容/バグ内容を分析して、類似のものがないかを摘出するための対策を行う必要もあるでしょう。

別にこういった品質見解書を求められていないとしても、どういうレビュー指摘があったかや、どういうバグが出たかを記録しておくことは、品質を高める取り組みとしては有効です。その後のレビュー観点の作成や検証の重点項目の作成など、ブラッシュアップのインプットとすることができます。

品質は評価にも直結するため、高い品質のシステムを作ることができると顧客の信頼や評価に繋がります。たとえ求められていなくても無理のない範囲で自発的にとりくむことが良いと思います。

チームビルディング

チーム全員がやりやすい環境で仕事ができるようにするというのも、プロジェクトリーダーとして重要な仕事です。
仕事がしやすい環境だとモチベーションも高まってくるし、チームとしての団結力があると全員が当事者意識を持って作業にあたれるようになります。
「一緒に仕事ができてよかった」と言ってもらえることは、なんだかんだ言ってもやっぱり嬉しいですよね。実際そういうプロジェクトもいくつか見てきましたが、全てに言えることは「チームビルディング」として成功してたなぁということです。

ぼくが今まで会ってきたなかでもトップクラスに尊敬してる一人のPLは、とにかくチームビルディングがうまかったです。
その人はプログラミングの知識は全くもっていなかったのですが、人の使い方がうまいというか、一緒にやっていても安心ができ、「この人がPLのプロジェクトはうまくいく」という感覚がありました。ぼくは結構ドライな方なのですが、その人が困っていると「この人のために頑張ろう」と奮い立ったのを憶えてます。

チームビルディングで重要なのは、段階に応じて以下のように振る舞うことだと言われています。

最初
- 目標やゴール、現状の課題などをリーダー主導で見つけて共通の目標を掲げる
共通目標が決まった段階
- 相互理解のために他のメンバーとの橋渡し役にリーダーがなる
- 意見の言いやすい雰囲気作りにしていく
  - そのためにもリーダーが率先してみんなの意見に耳を傾ける
  - 対立しているそれぞれの意見も否定せず、お互い解決できる状況に落とし込んでいく
- メンバーのサポートを他メンバーに依頼したりしながらチームとして課題に取り組んでいく
チーム内の相互理解が深まった段階
- それぞれのメンバーの個性を見極めてそれぞれに合う役割を任せていく
  - そのメンバーが主体的に行った行動を尊重する
- チームとして更にまとまるためのチーム内の共通目標を作っていく
  - リーダー主導というよりは、リーダーはまとめ役に徹する
メンバー間で主体的に動いて課題を解決していける段階
- 更にチームワークを高めるアクティビティの実施（ランチ会など）
- リーダーは主体的に動いているメンバーのサポート役に徹する

良いプロジェクトリーダーとは

だいぶ長文になっちゃったのでここまで読んでくれる人は少ないかもしれませんが、ぼくが思っている「良いプロジェクトリーダー像」について書いていきます。とはいえ、これらは心得の部分に最初に書いたやつとほとんど同じです。

謙虚である

これはリーダーというより、ビジネスパーソンとしても必須のことだと思ってますが。
「実るほど頭を垂れる稲穂かな」
ということわざもある通り、立派だなって思う人ほど謙虚さを持っている人が多いと思ってます。

逆に、下に偉そうにしたりパワハラしたり何にでも噛み付いたりマウントをとったりする人は、なにか強いコンプレックスを抱えているのか、自己顕示欲が強い（悪い言い方すると幼稚な）人が多いように感じ、少なくともぼくはあまり尊敬できません。

高圧的な人の前では、人はどうしても萎縮します。またその人の為に頑張ろうとも思えなくなり、結果的には完全に仕事として割り切って作業をするという状態になります。
また、そういう人のもとでプロジェクトを行っていると、おそらく終わったときには「やっと開放される」という思いの方が多くなるでしょう。そんなプロジェクトは「成功している」とはあまり思えません。「この人と仕事できてよかった」と思ってもらうためにも、常に謙虚さは持ち続けたいです。

目標の提示がうまく、押し付けをしない

プロジェクトリーダーの一番大事な仕事は、プロジェクトを成功させるための「指針を提示する」ことだと思っています。
良いプロジェクトリーダーほど、ゴールを具体的な目標に落とし込む力や、それをどうチームで共有するかの力に長けています。ただ、その裏には長年の経験から「どう浸透させるか」といった計算をしていることが伺えます。

仕事を振るのがうまい

プロジェクトリーダーとしての仕事がうまい人は、メンバーをよく観察していてそのメンバーに適した仕事をふることに長けています。また仕事の振り方もうまく、きちんと理由や背景を説明し、期待している作業内容（どういったことをしてほしく、どういう成果物がほしいのか）もきちんと説明した上で仕事をふっています。
これは「目標の提示」のうまさにもつながっています。小さなタスクでもその方向性と指針を提示し、メンバーを作業プロセスの迷子にさせずに期待する成果物を最大限のパフォーマンスで作れるように配慮しています。

なお、仕事を振る際にはいつも以下を心がけるといいかなと思ってます。

インプットとすべきものをきちんと伝える
なぜその作業が必要なのかの背景や理由を伝える
作業してほしい内容や成果物のイメージをなるべく具体的に伝える
- それが初めて作るものの場合は、たたき台を作っておく
- また、初めての作業の場合途中途中で認識ズレがないか確認をする
- 作業プロセスのイメージがあるのならそれも伝える
  (プロセスのイメージがない場合はまずそれを検討してもらう作業を指示する)
その作業が今後何で活用する想定なのかをきちんと伝える
考慮しないといけないポイントや、参考にできそうなものがあるならそれも伝える
(何の考慮が必要か見えていない場合それを検討してもらう作業を指示する)

作業状況やナレッジの見える化をする仕組みを作っている

プロジェクトとして一番良い状態は、チームの各メンバーが当事者意識を持って行動ができるようになることです。
良いプロジェクトリーダーは、メンバーが次の行動を正しい優先順位で行えるよう、常に全員の作業状況や、プロジェクト全体の状況の見通しをよくする試みを行っています。そうすることで、進捗が悪いメンバーがいれば他のメンバーが自発的にサポートしたりするようにもなり、リーダーの負担も軽減されて良い循環がおきやすくなります。もちろんリーダー自身もサポートしたり、周りにサポートを仰いだりします。

また、チームが持つべきナレッジについても見える化する対策をしています。
プロジェクトの初期は、メンバーもプロジェクトの作業に慣れていないために生産性が上がらずにナレッジの文書化まで手がつかず、どうしても各々の中にナレッジが点在してしまいがちです。残念なプロジェクトだと、それがそのまま最後まで改善されませんが、良いプロジェクトだと早い段階でリーダーがナレッジを共有するための仕組みを作ったり、しばらくは自分自身でそれらを文書化して手助けしながらチームとしてのナレッジを蓄積するようにしています。

先手先手の行動をとっている

リーダーとしてやるべきことは、未来のタスクを作り出すことです。
その日のタスクはメンバーにこなしてもらいながら、次の日のタスク、その次の日のタスクを検討していきます。そして課題やリスクを常に考え、前もって調整をしたり、対策をしたりしていきます。
それができないと、メンバー達は次何をしたらいいかわからずにプロジェクトの中で迷子になっちゃいます。あるいは突然リスクが爆発して作業が止まってしまうという状況に陥ることもあります。

メンバーをよく観察している

メンバーにはそれぞれに個性があり、良いプロジェクトリーダーほどメンバーそれぞれの個性を捉え、それに応じて対応を変えています。
たとえば問題を一人で抱え込みがちな人には定期的に状況を確認するようにしたりしてサポートをしたり、コーディング中かなり集中して作業をしたがる人であればその間は話しかけないようにする、といった具合です。
メンバーをよく観察し、プロジェクトリーダーがそのメンバーに対して正当な評価ができて必要なサポートができるようになると、自然とメンバーからも信頼されるようになります。

知識を出し惜しみしない

ときどき「成長のために自分で考えさせ発見させる」「失敗してもいいから挑戦させる」という方針をとっている人がいます。教育の方針は人さまざまなのでそれらを否定するつもりはありませんが、少なくともプロジェクトを円滑に進めるという点では自分が持っている知識は出し惜しみせずに皆に共有する方がベターかなと思ってます。
「プロジェクトを成功させる」ことがプロジェクトリーダーの使命なので、失敗はリスクですし、リスクは共有する方が良いです。

それに、失敗して「そうなるのはわかってた」とリーダーに言われて「自分の成長のためにあえて見守ってたんだ」と思う人よりは「え…ならなんで最初に教えてくれなかったん？(´・ω・`)」って思う人の方が多いでしょう。それよりは最初に注意すべきポイントを出し惜しまずに教えた方が信頼はされやすくなるんじゃないかと思います。

褒め方・叱り方がうまい

褒めるというのは仕事を円滑にすすめる上でとても大事なことだと思ってます。だいたいの人は褒められて伸びるタイプです。結構プロジェクトリーダーとして業務してる人の中には意識的に褒めるように務めてる人が多いです。

一方で、叱ることも必要な場面に出くわします。基本失敗して叱ることはすべきではないのであんまり叱るというケースは多くないのですが、中には他人の失敗を責めたりサボったりしてるメンバーがいたり同じミスを繰り返して明らかに注意力散漫だったり他メンバーを下に見たりしてるメンバーに対しては、毅然とした対応をしないとメンバーから信頼されなくなります。
ただ、そういった場合に他の人がいる前で怒るのはNGです。全体の生産性も下がるし、関係もぎくしゃくします。そうならないためにも個室などに呼んで大人の対応で叱るようにするべきです。

Mtgをテキパキする・決断や行動が早い

優秀だなと思うプロジェクトリーダーほど、決断や行動が素早いです。
ぼくが20代の頃に凄いなと思った人の例でいうと、30分のMtgで毎回議題が10以上ある中取り仕切って周りの意見も聞きながら決断を次々と下している人がいました。その際に理由もメンバーに伝え、皆が納得できる決断をしていたのを記憶してます。そして決めた内容はすぐに行動に移すか、メンバーに優先度も教えつつ作業を降って次々と課題を解決していました。
もちろん中にはすぐに結論がでないものもありました。ただその場合もすぐに「緊急度は高くないから次回のミーティングで改めて議論しよう。その際に貴方が考えるアイデアを提示してほしい。私も考えておくから」という暫定的な決断を下し、1つの議題に5分以上は費やさないようにしていました。
その素早さはリーダーシップとして快かったし、リーダーとして非常に大事なスキルだなと思ってます。

一度、飲みの場でその話をしたとき、その人は心得としてこう教えてくれました。

方針を提示するのがリーダーの仕事
行動を見せることもリーダーの仕事
経験的に、3分考えた場合と1時間考えた場合で出る結論の質にそんなに差はないから3分以上はかけない
その時決めた方針が間違えても謝って訂正すればいい。ただ訂正する必要があると考えた場合はすぐにするべき
決断できないリーダーは信頼されない

これは今でもぼくも心がけるようにしてます。

自信を持って発言をする

これも上の人から言われた言葉なのですが、「自信を持って発言する」ことはリーダーにとって非常に重要です。
(ぼく自信これが一番苦手なんですが、少なくとも顧客とのミーティングではなるべく意識的にやってます）
自信がなさそうな言い方をしていると「大丈夫かな」と思われ、結果的に信頼されずらい状態になってしまいます。

自信があるような発言するために、

なるべくはっきりと声を出す
- これだけでだいぶ印象が違います
目を見て話す
- これも目をそらしながら言うより印象が全然違います
結論から話す
- 「結論」、「その根拠や理由」、「たとえば」の順で話すのが効果的
- これも結論を最後に言うよりだいぶ印象が違います
素早く返す
- 1〜2秒以内に先方からの質問に答えるように心がける
  → 長考したり言葉につまるとそれだけで自信なさげになります
- 2秒以内に答えが返せない場合は「すぐには思いつかない」ことをすぐ伝える
  - ミーティング中に思いつけば議題が終わった後に回答といったこともできる
「〜だと思う」「たしか〜」という言い方は控える
- 3日以上かかると思います　→ 3日以上かかります
- たしか前の機能で実装しました → 前の機能で実装しました
  - 間違えてた場合後で訂正すればいい
    - ただそれが何度も続くと信頼を損ねるから注意
- 本当に自信がない場合は「一度持ち帰って検討する」と伝える
わからないことは「わからない」ときちんと伝える
- その上でいつまでに調べて回答するようにする旨伝える
事実と意見は分けて話す
- これは「自信のある発言」というよりはビジネストーキングの基本
- でも結構歳を重ねててもできない人が多い。意識してやる必要がある

相談ベースで動く

これも、仕事できるプロジェクトリーダーの動き方を見て学んだ内容です。
(上に書いた他の見出しも基本そうだけど）
相談ベースといっても、予め答えは用意をした上で最終的にはメンバーや顧客と合意をとるという形で動いた方が、独善的な印象にもならずにスムーズにプロジェクトは回ります。また、それはメンバーや顧客の受け止め方も違ってきます。

たとえば、タスクの優先順位について検討をしているとします。その際に

「タスクA、B、Cの順にやっていきます。完了予定日は○月○日です」

と、決定内容を伝える形よりは、その前に

「タスクA、B、Cの順でやろうと考えてます。他優先すべきタスクなどあれば教えてもらえるとありがたいです」

と頭出しする方が相手も意見を言いやすくなります。
今はSlackのように気軽にコミュニケーションができるツールもあるので、事前に方針を相談ベースで伝えて顧客とのミーティングでは最終的な意識合わせの場として使う方が円滑に進みやすくなります。

そうやると、「ワンクッション置くことでやりとりが2倍になって相手に負担がかかるんじゃないか」と不安に思う人もいると思います。実際にそれを嫌がって「結論だけ教えてくれたらいい」という人も中にはいます。そう言う人にはそう対応をすれば良いと思いますが、多くの人はそんなに１回やりとりが増える程度のことを不満に感じません（長文だとうわっとなると思うので簡潔にまとめるべきですが、2〜3行程度のメッセージなら読んで「わかりました」と返せば済むだけですから）。

むしろ多くの人は「こちらの想定と違う動きをされている」方が不満がたまります。それを決定ベースでこられると「いや、事前に相談してよ(´・ω・`)」ってなる人の方が経験的にも多いです。

残念なプロジェクトリーダーとは

残念なリーダーは、上記ができていない場合は当然なのですが、他にも共通してあると思う部分（あと、ぼくが失敗して反省した部分）について列挙します。

メンバーを見ない

「自分の仕事はスケジュールの管理だから」と割り切ってメンバーを観察せず、駒を配置するように担当を割り振っていくプロジェクトリーダーも中にはいます。そして進捗状況をタスクの内容から判断して勝手に管理していき、一切コミュニケーションを取ろうとしないリーダーは、メンバーからも信頼されませんし、実態の把握もできません。結果的に進捗が大幅に遅れていることが後半で発覚して大炎上を起こすというプロジェクトがありました。

ぼくもどちらかというと人見知りが激しくコミュニケーションが苦手な方なので、黙々と作業をしたくなる気持ちはわからなくはないのですが、チームの実情を見ないのは致命的だと思うのでいつも意識してコミュニケーションは取っています。最初はストレスもありますが、リーダーとして認められてくると気軽に話しやすい雰囲気になるので、そのストレスなんて一時的なものです。根気よくやるべきことをこなしましょう。

メンバーを信頼していない・一人で全部やろうとする

これはプロジェクト・リーダーの初めの頃には皆かかる病かと思います（ぼくもこれで大失敗しました）。
信頼をしていないつもりはないのですが、

自分がやらないと駄目だ
全部自分が把握しとかないと
自分が手本を見せないと

と意気込み、どんどんと仕事を抱え込んでしまって、結果「周りは余裕あるのに自分だけ忙しい」という状況に陥ってしまいます。それが「信頼してないことと同じ」なんだと気づくのにぼくは1〜2年かかりました。

特に周りが若手や新人しかいないという状況だと、なおさら「自分がやらないと」という思いが強くなりがちです。それは良い意味では「責任感が強い」ので、自分を責める必要はないと思ってますが、「まだ新人には難しい」と思っても任せましょう。作業の指針を提示し、期待する作業を教え、定期的に状況を確認するようにすればちゃんと期待に応えてくれます。もちろんそれらの説明コストやレビューコストはかかりますが、せいぜい1〜2時間程度のものです。それで1〜2人日の仕事をこなしてくれるのですから、自分でやるよりずっと円滑に進みます。

※もちろん、メンバーをよく観察して「できる範囲」にまで分割して仕事を振ることは大事です。

信頼されていない

リーダーにとって大事なことは、メンバーや顧客から信頼されることです。
顧客から信頼がされないと、不信感を持たれて色々と干渉されるようになります。

「何をやっているのかわからないので、毎日朝昼晩と進捗状況を報告するようにして下さい」
「貴方がそう言っている根拠を提示して下さい」
「やはりこちらでもレビューしたいので明日設計書を送って下さい」

プロジェクトリーダーが、こういったことを顧客から言われている場面をぼくも何度か見たことがあります。信頼関係ができていれば、いずれも言われてなかったでしょう（実際、同じ担当者でも別のプロジェクトリーダーとはスムーズに行えていたというのも見たことがあります）。
結果的に先方にも負担が発生してお互いに不幸な状態になります。

ただ、顧客から信頼されないことはまだマシで、内部のメンバーに信頼されない場合は致命的です。

メンバーに信頼されていないと、それぞれが自分勝手に行動をするようになり、チームのまとまりは崩壊します。
あるいは仕事として割り切ってしまい、リーダーとあまり関わろうとせず、メンバーが課題だと思っていることもリーダーが吸い上げたりできなくなって生産性の向上は見込めなくなります。
またリーダーが作業を指示しても意味がないと思って裏ではやっていないということも頻繁に発生するようになったり、指示されるたびに不満がたまって悪循環となるといったことが発生し、そうなるともうリーダーを交代させるしか状況は改善しなくなります。

失敗を責める

これはプロジェクト運営としても、チームビルディングとしても一番やってはいけないことだと思っています。
誰だって失敗をしたくて失敗してるわけではありません。それでオロオロして相談してきてるのに「何やってんの？」とか言うと泣きっ面に蜂状態です。結果どうなるかというと、「自分でリカバリできそうな失敗はもう相談しない」「そもそももう相談しない」といった形でミスが表面化しづらくなり、プロジェクトとしてのリスクとなってしまいます。

ぼくが尊敬してたプロジェクトリーダーとプロジェクトをやってたとき、ぼくが一つの機能実装がまるまる抜けていた（設計時の最後に詰め込まれた機能で、連携資料を見てなかった）ことが結合試験の際にわかり、大慌てで報告すると
「まずは報告ありがとう。リリース前に発覚できてよかった。ひとまず私から先方に謝っとくからその間にリカバリ案考えられる？それか一緒に考えよう」

という感じで言われて「あーもうこの人に一生ついていこう」と思ったのを憶えてます。そしてぼくが実際にプロジェクトリーダーになったときに、些細なミスでも吸い上げられることがリスク管理の意味でも非常に重要なんだと学び、ぼく自信も絶対にミスは責めない（むしろ報告ありがとうと伝える）ことを徹底しています。

~~ちなみに、ミスすると怒鳴るプロジェクトリーダーの下では結合環境のデータを間違えて消しちゃっても知らんぷりしてました。~~

その場しのぎの対応をしている

その場しのぎの対応をし続けてしまうというのも、プロジェクトリーダーとしてはよくない行動です。これは言い方を変えると「顧客またはプロジェクトやタスクに振り回されている」に他ならず、タスクの優先順位などを管理できていないと言えます。

これは、一見すると「決断や行動が早い」という良いパターンのようにも見えるため、たちの悪い病です。しかしその決定的な違いは「タスクのコントロールができているか」と「先を見据えての行動になっているか」にあり、前者はそれができていて、後者（つまりその場しのぎ）はそれができていません。

たとえば、ある担当者の実装の進捗が悪く、そのままではスケジュール通りに終わらないとします。周りを見ても余裕のある人がいなかったため、自分で巻き取って終わらせるという決断をしたとします。
だけど貴方にも貴方の作業があるはずで、上記の決断はそれらのタスクが遅延するということを意味します。それが優先度の高いものでなければまだ問題はありませんが、たとえばそれが直近の作業タスクの分割や整理だった場合、そうすることで次の作業をするメンバーが迷子になってしまいます。

プロジェクトリーダーの作業タスクは、スケジュールには乗らないということが多いため顧客側の見栄えをよくするために後回しにしてしまうというのは、いくつものプロジェクトで目にしてきましたが、遅延はそういったことの積み重ねでどんどんと膨らみます。どの選択をするのかを常に考えながら行動をすることが作業において重要です。

自分を卑下しすぎる

謙虚でいることはとても重要ですが、自分を卑下するというのはリーダーとしてはNGです。
ときどき、報告する際にこういったニュアンスで報告する人がいます。

「自分はわからないんですが○○(メンバー)が理解してます」
「自分は解決できなかったんですけど○○が解決しました」

これは、チームとしても顧客とのやりとりという面でもマイナスにしかなりません。
本人はメンバーを立てたくてそう言っているとしても、聞いた側はメンバー含めて「その一言を言う必要ある？」となるだけで、頼りなさがにじみ出て逆効果にしかならず、信頼もされなくなってしまいます。

上記のは顕著な例ですが、言い方が違うだけで実際は同じことを言っているという場面はちょくちょく目にします。リーダーは個人ではなく、チームの代弁者として窓口になっていることを自覚して、チームで解決できるというように意識を変えなければ一向に一体感も生まれず、頼られなくなってしまいます。

気まぐれに方針を変える

「なんとなくこう思うから」という理由でころころと方針を変えるのもプロジェクトリーダーとしてはやってはいけない行動です。方針にはそうする根拠が必要で、その芯がないと結果的にチームのメンバーも顧客も振り回してしまうことになります。言っていることにブレがあるとメンバーは動揺し、「この人の発言は信用できない」と思われます。

大まかな方針ではあんまりそういうブレはおきることは少ないでしょうが、たとえば設計レビューなんかで、ある時には「書き方がわかりづらい、箇条書きにしてほしい」と伝え、別のときには「箇条書きだと背景が伝わらない」と指摘する、といった場面はよく目にします。そのようなレビューの仕方をしていると何を基準にすれば良いのかわからなくなり、一向にナレッジがたまらず、生産性が向上しないばかりか、「この人の指摘は次の参考にはできない」となって信用を失います。

もしもチームの取り組みやプロセスなどを変えたい場合には、予め他の人の意見も聞きつつ独善的にならないよう最適解を見つけ、問題の分析も行ってから行うべきです。KPTなどの振り返りの手法がその際は役に立ちます。

一度決めたことを変えない

一方で、一度決めた内容を何があっても変えないという人もいます。一度決めたことはなるべく変更しない方がいいとはぼくも思います。変更にはコストがかかることはプロジェクトを回す上で肝に命じた方が良いです。
ただ、それが実態と合っていない非効率なやり方だと周りが思っている場合、作業が形骸化する原因にもなります。決めた方針やタスクの優先度なども定期的に見直しをして、必要な場合には変更する調整をしていくことが重要です。

知ったかぶりをする

プロジェクトリーダーをしている人の中には、技術的なことを一切知らない（プログラミングをしたことがなかったり、ITの基礎知識がない）という人も中にはいます。ただ、それは「良いプロジェクトリーダー」「残念なプロジェクトリーダー」の基準にはなりません。一切知らなくても「この人は凄いな」という人はぼくも何人も見てきました。

ただ、凄いと思うリーダーは少なくともしっかり理解しようとします。細かい実装はわからなくても「自分が何のシステムを作ろうとしているのか」の仕様をしっかり把握しようとし、それを実現するために自分がどう立ち振る舞わければならず、誰に助言をもらう必要があるのかを整理して優先度を決めてプロジェクトの遂行のために突き進みます。理解できなければ理解できるまで話を聞こうとします。
最初は（ITに勤めてるのならそれくらいわかっとけよ）と思うような基礎的な説明をしないといけない煩わしさをメンバーが感じたとしても、その姿勢は徐々に信頼へとつながっていき、「この人は技術は明るくないけど作ろうとしてるものは理解してる」となってメンバーが自らリーダーにわかりやすく説明する努力をし始めます。そしてそのために必要な調整や技術的な課題なども進んでリーダーへ伝えるようになります。そういうプロジェクトに、ぼくも何度か参画しました。

一方で、知ってるフリはすぐメンバーにバレます（ぼくもすぐわかりました）。それは、多少技術的スキルが高い人がリーダーを務めていたとしてもです。そして知ったかぶりが露呈すると、メンバーからの信用は失います。

誰でも知らないことはあるのですから、知らないことを「知らない」という勇気は持つべきです。特に「品質の良いシステムの完成」というミッションを抱えているプロジェクトリーダーが自分のプライドを優先すべきではありません。しっかりと「知ってること」「知らないこと」の整理をしてメンバーに助けを借りながら深く把握してシステムを完成に導く必要があります。

命令し、それを当然とする

「謙虚さ」でも書きましたが、プロジェクトリーダーはあくまでひとつの役割であり、プログラマーやデザイナーやテスターとの上下関係はありません。窓口であり、責任者にすぎず、あくまでも相互尊重の関係であるべきです。

しかし、中には「自分がこの中で一番えらい」と思っている人もいます。そして周りを見下して作業を命令してくる人もいます。うまくやってもそれを当然とする人もいます。
そういうプロジェクトは、だいたいうまくいきません。たとえ納期を守れたとしても、品質がよかったとしても、メンバーは全員疲弊しますし、プロジェクトが終わったら「やっと開放される」としか思いません。中には精神的にまいって途中でリタイヤしてしまう人も現れるでしょう。

えてしてそういうプロジェクトは、プロジェクトリーダー自身が個人的には能力が高く、周りを信頼せずに一人で頑張ってもなんとかなっているという図式になってます。そしてそれで完遂できてるワーカーホリックな人も多いのですが、ぼくはそういうプロジェクトは全部「残念なプロジェクト」だと思っており、新人プロジェクトリーダーさんにはそうはなってもらいたくないと思ってます。

とりえあず何でも共有する

最初の頃、ぼくは「プロジェクトの内容は全員が同じ粒度で共有できた方がいい」と思ってました。その方が全員で作っているという連帯感も生まれると考えていました。だけど、結論をいうと共有する情報は取捨選択すべきです。

もちろん「直近やらなければならないこと」や「現在の状況」や「全体像」といったものは全員が共有できている状態が望ましいと思っています。しかし、プロジェクトを進める中ではいくつものノイズも発生します。たとえば、以下のような。

顧客が現在の品質をよく思っていない
まだ仕様がブレブレで、言ってくる内容がコロコロ変わる
(自分が)プロジェクトに不安を感じている

まずひとつ目の内容は、全員に共有したところですぐにどうにかなるものではありません。方針や立て直し案を思いつくまでは、全員ではなくコアメンバーのみに共有するという方が全体のモチベーションダウンを避けられるでしょう。
２つ目も、変わるたびに共有していると混乱を生じる結果にしかなりません。「今そこの仕様がぶれてるから設計はまとまるまでペンディングしといて」くらいの共有にとどめる方が実装漏れといったリスクを軽減できます。
３つ目は、士気を落とす結果にしかならないので口にすべきではない情報です。そう感じているのならリスク管理を洗い出して行動できる状態にまで落とし込んでから共有すべきです。一人で解決できなさそうなら、コアメンバーへの共有だけに留めるべきです。

また、何でもかんでも全員でミーティングをするというのもあまりしないほうが良いと思ってます。ミーティングをするということは、作業工数を奪うということでもあるため、必要なメンバーだけを招集するという方が結果的にうまく回ります。

他力本願

リーダーは、プロジェクトを遂行するために何をしなければいけないのかを考える仕事です。なので、必然的に自分で考えて（あるいは周りの助けを借りて）主体的に動いていかなければいけません。

よくあるプロジェクトの課題で、「先方が約束した日までに仕様を提示してこない」「連携先が設計書を出してこない」といったものがあります。
凄いなと思ったプロジェクトリーダーの人は、それを優先度の高いリスクだとしっかり把握して自分ができる限りの行動を起こしていました。たとえば、以下のような行動です。

いつまでに貰えないとリスケする以外になくなることをきっちりと伝える
- メールなど証拠として残る形でも伝え、CCにその上長や責任者も入れる
- その後も何度も催促をする
直接相手の会社に乗り込んで強引に打ち合わせをする
- 相手が決めかねてる仕様部分をこちらも把握して提案する
- 二度ほどやったけどこれが一番うまくいきます
スケジュールを調整してできる場所を先に行う
- ただ、これはクリティカル・パスがある場合は難しい
- これもあまりうまくいくケースを見たことはないです
こちらで想定した仕様を突きつける
- これも、あんまりおすすめしない

一方で、残念なプロジェクトリーダーは「貰えないんだから仕方ない」「相手も忙しいのだろう」「先方がくれないのが悪い」という姿勢でその部分を放置してしまう人もいます。中には「結局期限までにできなくて困るのは相手だから」という人もいます。

もちろん約束した日に提示をしない相手側が悪いというのはわかるのですが、そうやって放置してうまくいったプロジェクトを見たことはありません。たいていはリスケはされずに無理やり最後高稼働で対応するというような場面を何度も見てきました。

プロジェクトリーダーはそのプロジェクトを成功させることが使命なのですから、リスク管理の一環として行動をする必要があります。

ちゃんと依頼しない

顧客に対して弱いプロジェクトリーダーは、それだけで結構不幸になります。もちろんそれは内部にも言えます。
時々、依頼しているのか独り言なのか報告なのかわからないような形で伝えるプロジェクトリーダーさんがいたりします。それを顧客は優先度の高い依頼だと認識せずにそのまま放置され、何も決まらなかったという場面も何度か目にしました。

日本人は結構「察してほしい」と思う人が多いです（ぼくもその傾向あるし）。でも、プロジェクトを遂行していくにあたっては明確に依頼の場合は依頼だとわかるように伝える必要があります。
伝わっていない依頼はしていないものと同じなので、しっかりと明確に伝えるべきです。

最後に

長くなりすぎたのでここまで読んでくれる人はいない気がしますが…(´・ω・`)
ぼくなりに「こういうプロジェクトリーダーになりたい」と思い、自分でも実践している内容についてを列挙しました。
最初はぼくも残念なプロジェクトリーダーとして、3プロジェクト炎上させたり品質の悪いものしか納品できなくて反省したりしていました。最近ではそこそこ成功に導けるプロジェクトも増えてきたので、その際にやってる心得的なものをまとめたつもりです。

プロジェクトリーダーは、結構たいへんな仕事です。内外含めて多くのコミュニケーションを取らないといけないし、ITのプロジェクトの7割は失敗してるとも言われてます。最初の見積もりを誤ると、どれだけ頑張っても炎上します。それに、本当は自分でプログラミングをやりたいのに周りにまかせないと終わらないという葛藤もでてきます。

ただ、自分ひとりでは作れない規模のシステムが形になっていくというのは、一人でやるのとは違う面白さがあります。全体の仕様を誰よりも一番理解ができ、それがメンバーの力を借りて目の前で構築されていくのはやっぱり楽しいです。おそらくそれはオーケストラで指揮者が味わう楽しさに近いのかもしれません（わかんないけど）。

今、IT業界全体が人手不足でまだあんまり経験数がないのにプロジェクトリーダーを任されているという人も多いかと思うので、多少でも参考になったらいいなと思います。