会議についても学び直すべき　─『仕事が早くなる文章作法 - ［1］日本人のSE/プロマネが日本語を学び直すべき理由：ITpro』について

やべえ、sysprepやリモートデスクトップのエントリを書かなきゃいけない(なぜ？ｗ)のに、こっちも書きたい(挨拶)。

というわけでササッと書いちゃう。ざっくり書いて後で校正しまあす(某ユニットリーダー風

題名にある仕事が早くなる文章作法 - ［1］日本人のSE/プロマネが日本語を学び直すべき理由：ITpro であるが、ほぼ同意。というかそういう教育も必要であることにも同意する。じゃあなんでわざわざエントリを起こしたのか。

実は無駄な会議は偉人に学べ。メイヤー、マスク、ジョブスが執着した「規律」 : ライフハッカー［日本版］を見た時に、「なんか書きたい」というイラつきを覚えたのだが、この手のライフハックｗをネタに一本というのはなんか弱いような気がして放置していた。

実際にプロジェクトを廻してみれば実感する話だが、ITエンジニアの多くはコミュニケーション能力に問題がある。先の仕事が早くなる文章作法 - ［1］日本人のSE/プロマネが日本語を学び直すべき理由：ITpro でも指摘されている通り、文章能力という意味では壊滅的とも言えるレベルの人間のほうが多い。

(3ページ目)　(前略)プロマネは少ないときで月に平均200時間、多いときには350時間以上も稼働します。あまりに多忙を極めたので、ある時、3カ月ほどかけて自分の稼働時間を集計し分析しました。その結果は、発注主との打ち合わせが20％、社内と協力会社との打ち合わせが30％、プロマネとしてすべき計画立案や問題分析が20％だったのです。

　我ながら驚いたのは残る30％の時間をプロジェクトメンバーの文章指導にあてていたことでした。設計書を査読すると必ずと言ってよいほど用語の間違い、文法の間違い、表現の矛盾などがある。これを手直しさせ、再度査読することを繰り返すのです。ソフトウエア技術者の弱い文章力が開発に悪影響を与えていることは、現場では切実な問題でした。

ABC分析 *1ほどではないが、きちんと集計・分析したところが素晴らしい。オレ、ABC/ABMもコンサルネタにしてたりするのにな。自分には適用してなかったｗ。

でも、ちょうどいい数字が出ている。いわゆるSIerがITの開発プロジェクトを受注すると、プロジェクトマネジメントも合わせて受注していることが多い。上記引用部分にも『発注主との打ち合わせが20％』『社内と協力会社との打ち合わせが30％』とあるので、そこそこ～大規模なプロジェクトだろう。

小規模なプロジェクトではそうでもないのだが、プロジェクト規模が大きくなるにつれ、コミュニケーションコストがプロジェクト全体のコストに占める割合が大きくなる。当然、プロジェクトをマネジメントするプロジェクトマネージャやPMOも、多くの労力をコミュニケーションに割くことになる。下図に示すようにコミュニケーション先が増えるとコミュニケーションチャネルは増大する。下図の例では3人だとチャネル数は3だったのに対し、1人増えただけの4人ではチャネル数は6。1人増えただけで一気に倍である。半沢直樹である(違うし、今はなんちゃらヴェルトゲーム

f:id:shigeo-t:20140519055647p:plain

このコミュニケーションチャネル数は

　　　n × (n－1) / 2

で計算できる。3～4人程度の小規模プロジェクトならそれほどコミュニケーションコストは大きくない。しかし延べではなく毎日数十人、数百人が稼働する規模のプロジェクトになってくると、直接相互のコミュニケーションは不可能。100人が直接相互のコミュニケーションを取るとすると、4,950チャネルになるし。そのため、各々チーム化して階層化してコミュニケーションするわけだが、それでもコミュニケーションコストは非常に大きい。約100人のプロジェクトで、PMO含めて10チームあり、各チームはメンバー数10名、チーム間は各メンバーが直接コンタクトせずチームリーダーが取りまとめてコミュニケーションする形態だと仮定して、コミュニケーションチャネルは下記の通り。

　　　【チーム内】10×(10-1)/2 = 45

　　　【チーム内計】(10×(10-1)/2) × 10= 450

　　　【チーム間】10×(10-1)/2 = 45

　　　【プロジェクト内】(チーム内計) + (チーム間) = 495

チーム化・階層化することで、直接コンタクトする4,950チャネルに対し1/10の495チャネルとなる。しかし、これでも相当コミュニケーションコストは大きい。実際にはこんなにきちんとコントロールできないので、異なるチーム間で、リーダーでは無くメンバー同士のコミュニケーションが必要であるわけだが。

そこで仕事が早くなる文章作法 - ［1］日本人のSE/プロマネが日本語を学び直すべき理由：ITpro に挙がられるテクニカルライティングというのは、コミュニケーションロスを防ぐため、コミュニケーションコストの増大を防ぐために非常に効き目があるわけだが、多忙なプロジェクトマネージャ、チームリーダーにとってはいわゆる『会議』の改善も大きな比重を占める。

会議の改善はプロジェクトだけでなく、プロジェクトではない通常業務においても効き目がある。しかし、無駄な会議は偉人に学べ。メイヤー、マスク、ジョブスが執着した「規律」 : ライフハッカー［日本版］みたいなライフハックｗがよく出てくる割に改善されている様子はあまりない。そもそも会議の改善って、ライフハックｗじゃないからなあ。大体においてライフハック好きには、会議を改善する権限が無かったりする。

無駄な会議は偉人に学べ。メイヤー、マスク、ジョブスが執着した「規律」 : ライフハッカー［日本版］の場合、ちょっと引用するけどふつーの奴にはマネできない。例えば次。

メイヤーが会議に出るのは10分までと決まっています。カレンダーアプリの最低設定単位が30分だからといって、30分間会議する必要はありません。メイヤーのカレンダーで30分もの枠が取られるのはごくまれです。メイヤーと話したければ、すべてを迅速に行う必要があります。

いや、単なる出席者が「10分しか出ません」って全部の会議で言えないだろ。正に「正しいことをしたければ偉くなれ」(和久平八郎)なわけで、企業なら経営トップとか部門トップが仕切っている会議、プロジェクトならプロジェクトマネージャが仕切っている会議で、それぞれのトップが「10分まで」って決めない事には10分で終わらない。この例だとメイヤーが「会議に出るのは10分までと」決めたから成立する話。

この手の会議のライフハックｗが多いけど、多い理由は会議が長い&ダメ→会議のライフハック記事→特に改善無し→会議のライフハックｗ記事→特に(ry→ライフハッ(ryというスパイラル。

そしてこの手のライフハック好きは多くの場合そんなに権限が無い。ライフハック好きの単なる出席者レベルに、会議の進め方の話をしたって多寡が知れてる。

一方「経営者向けの会議の進め方」なんて記事はあまり見かけない。経営者なんて会議漬けだったりするので、実際に無駄な会議は偉人に学べ。メイヤー、マスク、ジョブスが執着した「規律」 : ライフハッカー［日本版］のように進め方を変えれば、相当時間短縮もできるし、会議内容も向上できるはずなんだが。まあ、ジョブズのはマネしないほうがいいかもしれない。相当ワンマン経営者でなければ成立しない。ジョブズは追い出された実績があるわけだが、追い出されても戻ってくるくらいの凄さがあるから成立するわけで、追い出されたら終わる人はマネしないほうがいい。オーナーだから会社を追い出される心配は無いという人はジョブズなみのワンマン振りはマネできても、追い出されないので、よっぽど自浄能力が高くないと企業そのものが腐る。

ライフハック記事側にも問題はある。まず無駄な会議は偉人に学べ。メイヤー、マスク、ジョブスが執着した「規律」 : ライフハッカー［日本版］の記事に出てくるみたいにお題目として『データに基いて合理的に意思決定する』『容赦なく質問する』『経験ではなく事実に基づき議論する』『チームに完璧な準備を要求する』『長期的なヴィジョンを思い出させる』『担当者に公的な責任を負わせる』なんて話をする以前の問題。

ほとんどの会議の進め方の記事では「会議」という一種類で押し通している。しかし実際には目的・目標や参加者の構成によって様々な「会議」の形式がある。これが全てではないが、例えばプロジェクトで使う会議の形式だと下記のような例。

ミーティング
ブリーフィング
ディスカッション
ブレインストーミング
レビュー
コーチング

他の形式も使う可能性はあるが、まずはこんなところで。ファシリテーションをする場合、まずは会議の形式からコントロール対象である。ほぼファシリテーションするだけでコンサルティングフィーを貰ってたことあるけど、会議の形式をあらかじめ設定して開催通知に明記するだけでも大きく改善できる。開催通知に明記してあれば、ほぼ会議の形式や進め方にはコンセンサスが取れている状態になる。

ミーティングとは関係者が集まって相談をし、意思決定をすることである。ほとんどの会議に関するライフハック記事では、ミーティングのことについて述べている場合が多い。しかし、ミーティングじゃない形式のほうが向いている場合は別の形式で開催すべき。

例えば朝礼や昼礼をする場合、全員を集めて開催する場合がある。基本的にはブリーフィングが向いているので、ブリーフィングとして開催し、短時間の情報伝達に留める。情報伝達という目的を達したら解散するべき。

バカが上位者にいると、ブリーフィングの場で連絡や報告されたことについても問題ありと認識すると、全員を拘束したままその問題について話し合いを始めてしまう。大多数の出席者には関係ないのに。正しい進め方は、その問題についてのミーティングを設定して終わり。出席者と開催日時、場所を決める事以上はやってはいけない。例え少人数であっても、ブリーフィングはブリーフィングで終わらせる必要がある。

プロジェクトの場合、通常は他のミーティングや作業の日程が詰まっているわけで、出席者全員が暇で暇で予定がガラガラという事態はほぼありえない。

ブリーフィングのように時間をもっとも時間をコントロールしやすい形態で、時間大延長戦するのは愚かとしか言いようが無いよ南(おっさんの実名書くなｗ)。実際に作業時間を食いつぶすため、作業の進捗遅延を招く。

基本的に時間を定めずに開催するのは、ここに挙げた形式だとブレインストーミングだけ。いい感じの結論に行くまでは終わらなくてもいいし、どうしても当日中はいい感じにならない雰囲気だったら別の日に仕切り直しでもいい。

プロジェクトマネージャの従事率が、『発注主との打ち合わせが20％』『社内と協力会社との打ち合わせが30％』ということを踏まえると、会議の改善がプロジェクト全体のコミュニケーションコストの改善に大きく寄与する。プロジェクトマネージャのところのコミュニケーションが改善すると、プロジェクトマネージャとチームリーダー間のコミュニケーションについても改善するはず。

ITプロジェクトにおけるチームリーダーは、リーダーとしての業務もさることながら、技術面・作業面でも寄与することを求められている。そのため、会議に多くの時間が取られると進捗遅延につながりかねない。そのため、プロジェクトマネージャーやPMO側からの会議の改善は、プロジェクト全体のコミュニケーションコスト低減に寄与する。

その先はチームリーダーやチームメンバーの個々の資質・能力に依存する部分が出てくるが、そこまでいっていわゆる会議のライフハック記事が役に立つ。

ミーティングでもカンファレンスでもレビューなんでもいいが、その打合せの目的・目標とタイムマネジメントをきちんとコントロールするだけで、ITプロジェクトのプロジェクトマネジメントは大幅に改善する。まずは会議の種類を認識して使い分けるところがスタートではないだろうか。