本稿で書くこと
本稿では「定例ミーティングの際にどのような発言をすればマネジメントの援護射撃ができるか」を列挙します。非マネージャであるいちチームメンバーであっても、ミーティング等の場における発言を通すことで、良きマネジメントを促すことが可能なはずです。本稿に書かれていることは全て私の経験に基づくものであり、他所の現場にも一般化できるようなものではありません。
本稿で書かないこと
本稿ではプロジェクトマネージャの仕事について説明しません。マネージャとしてプロジェクトマネージメントのノウハウを知りたい人は、既に世間に流通している素晴らしい書籍の数々で学ぶべきです。IPAのプロジェクトマネージャ試験を受けてみるのも良いでしょう。
プロマネを援護射撃するための8つの発言
(1) それ、いいですね！
「素晴らしい」「すごい」「かっこいい」など、何でもいいのでマネージャや他のメンバーの報告を軽く褒めましょう。しつこくなりすぎない程度に、30分に1回程度の頻度で構いません。ポジティブな言葉が気軽に出てくる場はコミュニケーションが捗ります。気分良く仕事したいですよね。
(2) それ、いつまでにやればいいですか？
新たなタスクを任された場合、期限が明示されないことがあります。そういう時はマネージャがスケジュールを立てられていないか、立てていたとしても「スケジュールをメンバーらに共有しなければならない」という意識が低い恐れがあります。スケジュールが明確でないタスクは優先度も明確でないかもしれません。大なり小なり、後々の地雷になる可能性があります。早めにリスクを摘んでおくためにも、マネージャに質問してスケジュールの確認を促しましょう。
(3) それ、誰がやるんですか？
ミーティング中「これもやらなきゃですね」と新たなタスクがポップアップすることがあります。そして誰にもアサインされないまま、スケジュール上の終盤になって「忘れてた！」と発火することがあります。未アサインタスクを宙ぶらりんのままにしておくのは危険です。マネージャに「誰がやるのか」を質問して、ちゃんと確認してもらいましょう。もちろん「いつまでにやればいいですか？」と尋ねるのも忘れずに。
(4) それ、◯◯さんが詳しいですよね？
ミーティング中に出た議題や何かしらの問題について、マネージャや他のメンバーが眉間にシワをよせて悩むタイミングが生じることがあります。そんな時、あなたはこう思うかも知れません。「みんな何を悩んでいるんだろう。この問題は◯◯さん（あなたの組織内の誰か。あるいは既存のドキュメントに読み替えてもよい）が詳しいから聞けばすぐ答えがわかるのに」「いや、自分なんかが思いついたことはみんなも思いついているに違いない。◯◯さんに聞いてもわからない問題だからみんな悩んでいるんだろう」と。そんなことはありません。みんなが知らないだけです。声に出していいましょう。「それ、◯◯さんが詳しいですよね？」と。
※ もし「◯◯さんに聞いた上で悩んでるんだよ！」と返されたらどうしましょう？どうもしません。
(5) それ、図で説明してくれませんか？
ミーティング中、何らかのクラスの設計や処理フローなどの抽象的な概念について、みんなが口頭だけで議論を始めることがあります。言葉のラリーは延々とつづきますが、あなたは追いていけないかもしれません。「すごい。みんな頭がいいな……。図もなく言葉だけでこの抽象的な問題について議論できるなんて」と思うかも知れませんが、5000円賭けてもいいです。みんな理解できていません。いや、全員が全員理解できていないとは言いませんが、何割かは誤った解釈を脳内に描いている可能性があります。誤解を残したまま進む議論に意味はありません。さっさと図に描いてもらえば、最初から明確な議論ができます。時間を無駄にすることはありません。仮に図が描けなかった場合、これはそもそも議論できません。全ての議論は図で説明できることが大前提です。
(6) それ、誰がどうやって使うんですか？
別の言葉で言えば「みなさん、どんなペルソナを思い描いているんですか？」となります。ミーティング中、開発中のソフトウェアに対して新たな機能が要件として上がるかもしれません。メテオフォール型開発という言葉がありますが、トップダウン的に思いつきベースで要件が追加されることがあります。そのような場合、本当にこの追加要件について工数を割く価値があるかを見直す必要があります。仮にトップダウンでこのような要件が降って湧いた場合、プロジェクトマネージャは強く抵抗できないかもしれません。或いは、単に疑いなく要件として受け入れるかもしれません。あなた以外の誰も、この新たな要件に対して歪さを感じていない恐れもあります。少しでも違和感を感じたら「それ、誰がどうやって使うんですか？」と尋ねましょう。誰も明確に答えることができなかったらビンゴです。誰もユーザーストーリーを作っていません。その要件については再考すべきでしょう。
(7) それ、マイルストーン設けませんか？
考えにくいことですがプロジェクトの開始から終了までの間、一度も途中成果物（プロトタイプやアルファ版）をまとめるつもりのないスケジュールが設定されてしまうことがあります。マイルストーンとなるはずのそれら途中成果物が一度も作られないということは、一度のレビューもできずに締め切りを迎えるということです。別の星へロケットを飛ばしておいて軌道修正を一切行わないのと同じです。目標地点への到達が絶対不可能とは言い切りませんが、失敗の確率はかなり高いと言えるでしょう。
(8) それ、どういうプロセスを踏めば完了とみなせるんですか？
これは適用範囲の広い質問です。例えばソフトウェア開発において「完成」が定義されないことは無いはずです。しかし残念ながらマネージャの描く「完成の概念」が共有されないままプロジェクトが進んでいくことはあるかもしれません。「完成の概念」についてもレビューが必要かもしれないのに、です。そしてソフトウェア自体に限らず、その開発の各種タスクについても「タスクの完了」にどういう手順で到達できるのかが定義されないことがあります。例えば「◯◯という機能についてテストする」というタスクにおいても、どのようなテストをするべきかが明示されていません。本当は想定する工数では全然足りないくらい、多くのテストケースを書かないといけないかもしれません。このように「完成」や「完了」が未定義のままTrelloやRedmineに並べられているタスクは、それ1つ1つがリスクです。スケジュール終盤で発火しないことを祈るくらいなら、さっさと完了の定義について確認しましょう。
本稿で使った用語
PMBOKとかスクラム関連書籍にあるような用語の使い方はしません。以下、本稿で使う主な用語について説明します。
プロジェクト
本稿での「プロジェクト」とは、ざっくりと「何らかの目標を達成するための計画」のことを指します。そもそもプロジェクトという言葉が使われない組織もあると思うし、仮にあったとしてもプロジェクトマネージャという役割が明確にアサインされない現場もあります。それでもプロジェクトという概念はどの現場にも存在するはずです。
プロジェクトマネジメント
厳密には色々な方法論や考え方があるらしいですが、本稿では「プロジェクトを成功させるために、仕事の進め方やゴールを定めたり、そもそもゴール達成にどんなタスクがあるのか洗い出したり、タスクに対して適切な人員をアサインしたり、関係者に色んな調整とか根回しをしたりして、とにかく期日までに目標達成する確率を上げるために立ち回ること」くらいの意味で「プロジェクトマネジメント」という言葉を使います。設計やコーディングはプロジェクトマネジメントには含めません。
プロジェクトマネージャ
本稿では「上長からあるプロジェクトのマネジメントをアサインされた人」のことを単に「プロジェクトマネージャ」と呼びます。プロジェクトマネージャにアサインされるにあたって、大々的な「プロジェクトマネージャ認定式」のような儀式はまず確実に行われませんし「プロジェクトマネージャ認定書」も発行されません。上長から「じゃ、これやっといてね」とか「君に任せるね」と言われてヌルっとアサインされます。いつの間にかマネージャにされます。プロジェクトマネージャは目的のプロジェクト用に集められたメンバーの先頭に立ち、ゴールに向けて指揮をとらなければなりません。
プロジェクトチーム
本稿では「目的のプロジェクトを成功させるために作業してくれる人々」をまとめて「プロジェクトチーム」と呼びます。
チームメンバー
本稿では「プロジェクトチームに属するメンバー」のことを「チームメンバー」と呼びます。本稿を読むあなたであり、私のことです。あ、でもややこしいのでプロジェクトマネージャはチームメンバーとは明確に区別させてください。チームメンバーはそれぞれのスキルを活かしてプロジェクトを成功に導きますが、基本的にはプロジェクトマネージャの指示に従って作業する必要があります。マネージャから指示されていないことはやってはいけません……理想的を言えばですが。
定例ミーティング
本稿では「プロジェクトマネージャとチームメンバーを集めて定期的に行われるミーティング」のことを「定例ミーティング」と書きます。定例ミーティングの場ではメンバーらによる進捗報告や、プロジェクトマネージャからのタスクの設定や調整が行われるという想定です。