見出し画像

進捗会議

私は、「会議(体)」というものがあまり好きではありません。

というか、超嫌いです。もちろん、会議の重要性は十分に理解していますが、その十分に理解すべき『重要性』に重点を置いた会議体というものを殆ど見たことがなく、その"時間"というリソースを費やした対効果を考えた時、どうしても「採算があわない」と感じてしまうためです。

重点とは、すなわち『要諦』であり、その活動自体の骨子であり、目的と連動するべき目標に影響を与えるものと言っても差支えがありません。それを差し置いて行われる会議とは一体何なのでしょう。

その間に拘束される時間は仕事のスケジュールとしても、人生(残りの寿命)としても、無駄遣いしている気がして、どうしても好きになれないのです。

会議とは

そもそも「会議」とは、

 関係者が集まって特定の課題について相談をし、意思決定をする

ことです。つまり、本来は決まっていないことを決めるために、「1人では解決できないから、他者の力を得て、一緒に解決していこう!」と言う活動を"会議体"と言うのです。

逆説的に言えば、「決める」「解決する」という結論に至らない会議は、すべて目的を果たしていないか、無駄に会議と言う形式を取ることで、コストやスケジュールに害を与えている可能性がある、ということです。

この本質的な考え方から言えば、一般的に行われる会議の大半は、ただの多人数への"報連相"コミュニケーションにしかなっていないことがよくわかります。


コミュニケーション・マネジメント

けれども、その一般的に行われる会議(報連相コミュニケーション)に関して言えば、計画プロセスにおける"コミュニケーション・マネジメント"では、プロジェクトの成功に必要と言われています。

PMBOKの言う"会議"とは、

◆会議の種類
 ・ 情報交換
 ・ ブレーンストーミング、選択肢の評価、構想
 ・ 意思決定

◆ベストプラクティスとしては、
 ・ 異なる種類の会議を混在させない。
 ・ 明確な議題、目的、目標、および時間枠を設定する。
 ・ 議事録と対応処置を文書化する。
 ・ 議事録はプロジェクトマネジメント計画書に決められた通りに保管。

とされていますが、じゃあどこで情報交換を行うべきか?とは書かれていません。むしろ、「情報の共有」をするためにただの情報交換を行うというのであれば、別に会議でなくてもいいはずです。朝礼などを用いるとか、メールやチャットを活用するとか、目の届くところに全員いるなら雑談程度でもいいはずです。私なら、口頭通達+メールを活用すると思います。いつも大抵はそうしているので。

一般的に、適切なコミュニケーション(主に情報共有)をおこなううえで、具体的には

 ・どこで(Where)
 ・どのタイミングに(When)
 ・どんな人にむけて(Who)
 ・どんな内容の(What)

情報を連携、共有するのかを定義、あるいは計画することが求められると思います。必要があれば、会議体も当然コミュニケーションの1つとして検討されることになるのは致し方ないかも知れません。ですが、本当に必要な会議なのかをしっかりと吟味しておかないと、アッという間にスケジュールを逼迫させることになりかねません。



けれども進捗会議は

ところが、先ほども言ったように、本来"会議"とは決まっていないことを決める場です。「仕様を検討する会議」や、「課題解決に向けて話し合う会議」であれば、本来の目的に沿った有益なものとなるでしょう。

しかし、"進捗会議"と言うのは一体何を決める場なのでしょう?

先ほどの要素に照らし合わせてみれば

 ・定期的に(When)
 ・一ヵ所に人を集めて(Where)
 ・リーダーまたはマネージャーが(Who)
 ・普段管理できていない進捗状況を(What)

知りたいだけの場にしか見えません。「経費を費やしてまでそこに集まるすべての人にとって有益か?」と言うと非常に疑問が残ります。情報交換を目的とする…と言っても、マネージャーが一方的に知りたいだけではありませんか。メンバー間で、他のメンバーの進捗状況なんて聞いても、ありがたいケースなんてごくわずかです。

 なぜ、そこまでキツい言い方をするのか?

と言うと、進捗を知りたい人間が1人いるだけなら、その1人がメンバーのところに行って、聞けば済むだけだからです。わざわざ全員の作業を止めさせて、1ヶ所に集合させることに何の意味があるのでしょう?

進捗の確認程度なら、私がマネージャーをする際には

 それぞれのメンバーの机まで足を運んで、個別に聞いていました

それ以上の労力をかける必要は全くありませんし、もし課題や問題などについて共有したいことがあれば、そのためだけに本当に必要なメンバーを集めて別途会議していました。


どれだけの人が不満を持っているか

実際、あるアンケートでは、次のような結果も出ているようです。

画像1

このような原因は、プロジェクトの進捗会議等で意識を合わせることで解決できそうですが、進捗会議についてフィードバック、コミュニケーションに満足されていますか?の問いの回答をみると、44%もの人が「進捗会議」のコミュニケーションに何かしら不満があると回答しています。この中には、普段開催する側の人も含まれていますから、その人たちを除けば確実に過半数を超えることになります。

これは驚異的な数字です。

何よりも問題なのは、こうした会議体がガントチャート等のスケジュールには一切見えていないことです。そのうえで、各担当者に作業見積もりを依頼した際、「何日でできる?」と聞いて

 「3日でできます」

と答えられると、それを聞いたリーダーあるいはマネージャーは

画像2

3人日(8h × 3日 = 24h)という限られた時間をスケジュールとして設定します。その間に進捗会議が途中に設けられていて、内2時間はほかの作業に取られてしまうとしても、メンバーの都合や負担など一切省みることなく、スケジュール内に収めさせようとします。

これでは既に、「計画であって計画でない」ただの形骸化した表です。精度の欠けらもありません。この時点で"残業"による想定外経費の上積みが確定します。

特にこうした、

 管理者の、管理者による、管理者のためだけの自己満足会議

というのは、コミュニケーション・マネジメント、ひいてはプロジェクトマネジメントを根底から阻害する要因の1つとして、昔から問題提起されていました。欧米や、外資系企業、あるいは外国人社長などがCEOに立った企業では、こうした会議体はほとんど行われていません。日本特有の悪習の1つなのです。


費用対効果は常に意識しよう

とはいえ、プロジェクトマネジメントの標準でおなじみのPMBOKでも、当然"会議"(Meeting)という言葉は存在しています(そもそも欧米ではそういう"決定しない"会議はあまりしないか、しても短時間で済ませますが)。

せめて、せっかく多大なコストとスケジュールを消費して行うのであれば、

 ・課題を共有・検討(プロジェクト作業の指揮・マネジメント)
 ・進捗をチェック(プロジェクト作業の監視・コントロール)
 ・変更点を議論し、受入れや却下をする(統合変更管理)
 ・関係者への情報共有(コミュニケーション・コントロール/ステークホ  ルダー・エンゲージメント・コントロール)

あたりは意識して取り込むべきでしょう(専門用語を覚えるかどうかはともかくとして)。その最低限の対効果が期待できない会議は、おそらく会議体形式にしている時点で、ムダが多く、コストセンターとして著しい損失を出している可能性があるということです。

リーダーやマネージャーと言えば、人によっては経営側(課長以上)の役職者になる一歩手前でもありますよね。プロジェクトマネジメントが『プロジェクト経営』と言われるくらいですから、ここでマネージャーとして大成すると、規模が異なるだけで企業の運営だって大半のことができてしまいます。

仮に、EVM(Earned Value Management)を用いないとしても、「ヒト、モノ、カネ、情報」を管理・コントロールする立場として、一つひとつのアクティビティに対して、

 ・プロジェクト予算(経費)をどのように使うのか
 ・使った経費に見合った成果を得られる活動なのか

くらいは最低限度、意識できなければ"マネジメント"としては失格扱いされても不思議ではありません。そのことをしっかり意識した会議体となるよう、努力しましょう。


スケジュールに明確化されないアクティビティの恐怖

このコミュニケーション・マネジメントとスケジュール・マネジメントの紐づけが適切に行えていないと、必ずスケジュールが逼迫します。納期や期限などばかり重要視するあまり、プロジェクトメンバーにはっぱをかけていると、メンバーは個人の力量と都合で、品質面を疎かにするようになります。そうしてプロダクトが出荷された先で問題が起こり、利用する者が被害を受けるようになるのです。

7payの二段階認証問題も、元をただせばそうでしたよね。

事件の問題点として、内製でなんとかしようとしたり、仕様検討する層にセキュリティに関するリテラシーの高い人材が不足していたりと言ったことが目立ちますが、それもこれも

そもそも、セブン&アイは19年10月をめどに7pay単独アプリの配信を始め、利用可能な店舗をグループ内外に広げる計画を発表していました。しかし競合のファミリーマートが独自のスマホ決済「Famipay(ファミペイ)」を7月1 日にリリースすることになり、遅れを取らないよう「セブン-イレブンアプリ」を利用することで7payリリースを先行しました。

つまり現場的にも、相当期限を前倒した厳しい開発スケジュールに追い込まれた状況であったといえます。

そうやって、Q(品質)・C(コスト)・D(期限)のバランスや、実現性を無視したITリテラシーの低い経営層の横やりが入ったせいで、十分な検討時間が設けられず、機能として不足していることに気づかない…と言う最悪の事態を招いたことが、根本にあったのではないでしょうか。

計画としてスケジュールに含まれないアクティビティでもある会議体は、時として計画そのものを"絵に描いた餅"にしかねない、そんなリスクを相当はらんでいるということをリーダーやマネージャーは自覚しておかなければなりません。


ちなみに

私がここまで「進捗会議」を嫌うのは、1社目、25~6歳前後の頃にあった1つの会議がすべての発端です。

画像3

その日は、3社での電話会議(当時、まだTV会議はなかったので)でした。私もまだまだただの1エンジニア。私たちの会社からは10名ほどのメンバーが参加していました。

スケジュールは比較的タイトだったのですが、リーダーが管理をまったくしない人で、電話会議などでA社から状況を確認される際には、リーダーが答えられないために、全員が参加し、各々が自分の担当分を報告する形になっていました(B社はリーダーが取りまとめていたようですが)。

そのため、オンスケの状態だと1分もかからない報告なのに、会議が終わるまで(およそ2時間ほど)全員が自席に戻れないような状況だったのです。

これだけでも、相当無駄な時間なのですが、ある時、B社の進捗があまり芳しくないという報告があったときでした。A社のマネージャーが、その場で感情的に怒り出したのです。

 「どうするつもりなんだ」
 「お客さまにどう報告すればいいんだ」
 「黙ってないで、なんとか言え」

と、頭ごなしにキレ始めたのです。B社のリーダーさんは初老で、物腰が柔らかそうな方だったのですが、この方も対応がイマイチ上手くなくて、

 「スケジュールを延期させてもらえたら…」

などと歯切れの悪い、しかも一方的に相手に迷惑がかかるような発言をするものだから、A社のマネージャーはさらにヒートアップし始め、その場で私たちは延々と通常の2時間+2時間の計4時間もの間、B社への説教を聞き続けなければならなくなり、その進捗会議が終わるころには私たちのチームも、

 0.5人日(4h) × 10名 = 延べ5人日(0.25人月)の進捗遅れ

となってしまっていました。

以来、『くだらない進捗会議』を心底憎むようになり、私なりに「進捗の適宜把握」「問題が顕在化する前にコントロール」をするための最適解を模索し続けました。

ある意味で、私自身の大きな転換点であり、1つ大きく成長させてくれたイベントではありましたが、二度とこんな人生の無駄遣いはしたくないし、メンバーにさせたくないと思っています。

この記事が参加している募集

#とは

57,808件

いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。