会議は決定力が9割

会議において大事なものは、根回しだとか、議事録を作ることだとか、アジェンダを用意することだとか、目的を明確にすることだとか、時間を超過しないことだとか、いろいろ言われるものがあります。

僕の世界では、決定力が9割です。それ以外ほとんど考えません。
会議で何かが解決すれば終了なんです。ろくすっぽ準備もしません。

極端なことを言ってすみません。でも、うちは議事録を作らず録画だし、資料を作る暇があまりないのでアジェンダもほとんどないし、根回しがないと動かない人がいません。
そういう僕の世界の話をします。
書き終わって見るとほとんど日記みたいになりました。読む価値があるのかはわかりません。

決定するシーン以外は極論言えば寝ててもいいんです。
寝てるときに話しかけられて「佐々木さん、どうですか？」って聞かれても、コンテナの起動速度のように早く反応して「この課題はこういう方針で対応する計画です」と会話が成立すればいいのです。だいたい自分が聞かれることはアウトプットが間に合ってないだけで用意してあります。
実際、リモート勤務だとデーモンで仕事（いわゆる内職）をしてる人が多いので、話しかけられて応答があって繋がれば違和感はありません。

そして、物事を説明・決定できることが大事です。
「この課題は同時に対応できない二つの問題があるので、優先順位をつけて対応しなければなりません。私はこちらを優先すべきだと思ってます。その場合のスケジュールはこのように計画してます。ただし、もう片方が後回しになる点はご容赦ください」

現場レベルだと、このくらい具体的に対応を説明できれば十分です。満点の計画でなくても、「説明ができている」ことで相手はだいたい納得してくれます。
問題点やリスクがあっても、説明して合意できていれば進行に影響を及ぼすことは多くありません。あらかじめきちんと説明できてないことが揉める原因になるのです。

難しいのは、より大胆に丸投げされるケースです。

「この製品のPoCをお願いします。期間は2か月です。ゴールは自分で決めてください」

みたいなやつ。PoCというのは、技術的な検証をして、実現可能か、導入すべきものなのか、そういうものを調べることを意味します。とはいえ、だいたい導入前提なので、色よい結果が期待されます。
ゼロから丸投げされると、ざっくりした計画と予算とか作って案件開始することまでは経験値によってできます。実際に使える人的リソースが決まってるので、経験値というより、人員の制限によって計画を作ることが多いです。くどいようですが私の世界の話です。よそは知りません。

ただ、その製品を指定されてもそれがどんなもので、具体的にどんな機能があって何ができて、自分たちは何をするべきなのか、実際にプロジェクトとして動く以前の事前調査が不可欠です。
なんなら、それだけで案件開始前に1ヶ月くらいほしいです。得体の知れないものをやみくもに触ることはできません。そういうことをすると、致命的な手戻りになるリスクを抱えます。

しかし時間はないのでノーヒントからでも、ある程度えいやと決めて、走りながら軌道修正することは必要です。

検討して決めない人ってみなさん嫌いじゃないですか。
そんな決断できない上司やPMはやりにくいですよね。
ただ、えいやと決めたからには真っ先にPMが走らないといかんのです。

なぜなら、地図も道具も情報もない状態で自走できる人がその辺に転がってるわけがないのです。
ITエンジニアはチームプレーで仕事をすることが身に沁みついているので、チームの役割とか仕事を定義しないと動けないのが普通です。
それが決められるところまでは、やはりリーダーの実力を発揮するポイントです。もちろん、頼れる優秀な仲間がいるなら分担するなり任せてもいいです。

会議では「私たちはここまでやります。ただし、情報がないので見込みの計画です」と含みを残しておきます。
もちろん、偉い人はPoC後の計画もつつがなく進行してくれないと困ると思ってるので、無茶な計画でも順調にクリアしてくれないと困ると考えています。
しかし、それを鵜吞みにして現場に過剰な負荷をもたらすのは無能なPMです。さりとて、情報ゼロで丸投げされた仕事は、大概普通の案件よりも進行難易度が高いです。さらに言えば、私は複数の案件のPMを兼務しているので一つの案件がおかしくなると、大変まずい事態になるのです。

そうすると、バシバシと決定して物事を進めるしかありません。私が大好きな爆速行軍こそが全員が幸せになる道です。誰かが、必要なことを爆速で全部決めれば余裕すら生まれます。
身体へのダメージを覚悟で20倍界王拳かめはめ波を打つくらいの気持ちで初動を急ぎます。
ダメな案件は初動がまず悪いことが多いです。出だしから遅れるとだいたいそれを取り戻せません。だって、初動を爆速でやっても、チームが走り出すまでは時間がかかるのがプロジェクトってものです。

初動の段階でどうしても立ち上げが遅れるとなれば、何をやるのかやらないのかを決めます。
冗談じゃなく、情報収集なんかあっという間に一週間、二週間と過ぎていきます。わけわからんマニュアルを読んで情報を集めて質問をして、ちょこっと触りつつ機能を調べてたら、あら不思議。二ヶ月期限なのにあと一か月しかない、なんてことにもなりかねません。
まあ、本音を言えば事前検討で一か月くらいはあらかじめ欲しいし、稼働も請求するのが健康だと思いますが、なかなかそうはいきません。有償製品のPoCを無料で長期間させてくれるベンダーばかりではありませんし。それが許されるとしても、導入未確定のものに何か月も付き合わせるのも優しい行為ではありません。
そういう相手のことも考えると、爆速が大事なんです。大規模システムだとそう身軽にはいかないんですけど、無理を通すのも仕事ですから。

で、今日は会議の話を書くつもりだった気がするので無理やり会議に話を戻すと、先手を打って承諾をもらうのが大事なわけです。

「この部分がコア機能なので重点的に検証します。他は残り工数見合いです」とか、ざっくりした方針の合意をとっておくと齟齬になりにくいです。

重点的にやることが決まれば納品物のイメージもつくし、検証手順を作る手掛かりにもなります。しかも、それが重要だと合意できれば、それを軸に将来設計すると想定したノウハウの蓄積もできます。
ここまでやれば、メンバーに振れる仕事もかなり増えてきます。

次にベンダーとの会議のコツです。
会議のコツは、主導権を握ることです。

長く付き合うに足る相手かどうか、付き合いやすい関係を作れそうかどうか、そういうのを見ます。平たく言えば同じペースで仕事をしてくれそうかというのがポイントです。
やっぱり技術的な質問とか、価格の質問とか、何週間も回答できない会社はあります。そういう製品を導入すると、運用でも同じ状態になるわけです。無駄な運用コストがかかります。
対応がいい会社、同じペースで仕事できそうな会社と出会えたら、たとえ成約に至らなくても大事にすべきだと思います。貴重なので。

もう一つ。やっぱり主導権は握ってもらった方が楽なんです。
会議って主催するより招待される方が楽ですよね。
相手に楽をさせます。そして、主導権を握ることで自分がキーマンであると理解してもらいます。
実際、技術的なこともめちゃくちゃ突っ込んで聞くし、調整も全部やるのでキーマンなのは間違いないです。
私は別に導入の判断をする権限はないですけど、とりあえず極めてそれに近い立場であると思ってもらいます。実際に、導入への手ごたえとか、相手のためになる情報も随時共有します。

だいたい全部決めたいこと決めると、「あー、楽になったなー」って気分になります。あとは若い子に任せてゆっくり寝ます。実際には想定外の事態の対応とかですぐに駆り出されるわけですが。

はい。決めることは決めれば楽な仕事です。
え？めちゃ働いてる？プレイイングマネージャーになってる？
そんなことはないです。マネジメントはここまでやらねばならないのです。たぶん。

さて、読む側がどう思ったかはさておき、私はやっぱり決定力が9割だと思って仕事しとるわけです。
やっぱり技術のことも深く切り込むわけですけど、調整や事務作業もあるわけですけど、「決める」ことだけはなかなか任せられる人がいないのです。プロジェクト全体の視点で考えるのはPMしかいないわけです。

上流から下流まで一通り経験したからこそ矛盾のない設計や調整ができるし、下流にいれば不満がどれだけあっても動かすことはできなかったわけです。それが今では自分で決めることができるわけで、すごく幸せな仕事をしてます。

そんなことをしながら、組織のことについて意見をつけたり、事業部長から経営企画に出す目標の内容についての意見を述べたり、様々な活動をやってるのは楽しいです。
好き勝手やれて果報者だなと思います。もっと暴れるためにも、決断速度を上げて余力を作って行きます。