この記事はNuco Advent Calendar 2022の1日目の記事です
はじめに
やる気を削ぐ会議術
会議（かいぎ）は、関係者が集まり、特定の目的（議題）に関して意見交換・審議し、合意・施策などの意思決定をすること、およびその物理的構成員の集まりを意味する。
仕事でエンジニアリングを行う人々にとって会議という営みは不可欠である。
そもそも会社という複数の人々の共同体を会議なしで運営することが不可能であることから、当然職業エンジニアにとっても会議は避けられない。
- システムの仕様決めのためのチーム内外での話し合い
- 非IT部門に対するサポートのための説明会
- 顧客に対する技術的なプレゼンテーション
- 上司との1on1
- etc...
上記のように様々な目的で会議は日々開催される。
開発が仕事であるエンジニアにとっては会議そのものは間接的な業務であるから、会議そのものが好きなエンジニアというのは極々少数はであることが広く知られている。
それどころか会議を忌避しており、できる限り避けたいと思っているエンジニアも少なくない。
今日は皆さんにより効果的にエンジニアのやる気を削ぐ会議術を紹介したい。
これをマスターすることで、エンジニアリングチーム全体の生産性を下げ、さらには離職者数及び退職率を向上させ、人的コストを削減させる効果が期待できる。
そうして削減したコストを事業投資へと分配することで日本企業の国際的競争力を復活させ、失われた30年を取り戻し、本記事が岸田政権の掲げる新しい資本主義実現の一助となることを筆者は切に願っている。
入門編
まずは入門編として5つの会議術を紹介しよう。
入門編では時間のない読者のためにも明日からすぐ使える内容をピックアップした。
人数を増やす
まず最初に紹介する会議術は会議に参加する人数を増やすことである。
これは会議術としてはあまりに有名であるからご存知の読者も少なくないと思う。
戦いの基本中の基本、人海戦術は会議においても有効である。物量に勝る暴力なし。
会議の参加者が多ければ多いほどエンジニアに「これって俺いなくてもいいんじゃ…」と思わせることができ、徐々にMPを削る効果が期待できる。
しかもこれは人数を増やせば増やすほど効果的であり、威力を定量化できるため効果を予測しやすい。
最低でも10名は用意しておきたい。
昨今ではリモートでの会議が多い。この業界では特に他の業界に比べ普及率が高い。
Google Meetのインカメラのパネルが画面に収まらなくなり表示が省略される様は圧巻である。
このときにやってはいけないのが、カメラOFFにさせることである。カメラをOFFにすると会議に参加していなくてもバレないため効果が大きく下げられてしまう。
絶対に参加者のカメラはONにさせるように強制しよう。
また、たまに話題を振るのも効果的である。話を聞くのに集中せざるを得なくなり、会議中に隠れて内職されることを防ぐことができる。
あくまでこのテクニックの肝は本当は開発のタスクに当てられた時間を無駄にしてしまった感をエンジニアに与えることである。
つまり会議に参加する意義を与えてもいけないし、内職させる時間も与えてはいけないことに留意いただきたい。
念の為呼んでみる
これも簡単にできるテクニックである。
会議の本題に直接必要かわからないけど、○○の話になったときに△△さんがいてくれたら助かるな、そう思ったときは迷わず会議に招待してしまおう。
「△△さん、とりあえずXX日YY時のMTG参加してもらっていい？」
そう言われた時点でエンジニアのやる気は削がれる。そしてエンジニアが会議に参加して、結局一度も話題が振られることもなく終わると追加でボーナスダメージが入る仕様になっている。
したがって会議には関係なければ関係ないほど招待する価値が上がるというわけだ。
このテクニックを用いることで前述の人数を増やす会議術の効果も期待できるため初心者の方には非常におすすめである。
最初の内は慣れないかもしれないが、上級者になると頭に思い浮かんだ人は何も考えずとも反射的に会議に招待することができるようになる。
日々の反復練習が重要だ。がんばろう。
内容を事前に伝えない
これは会議に招待するときに使えるテクニックである。
「XX日のYY時から打ち合わせの時間もらえる？」とだけ伝えるのである。
この時点で何のために時間が取られたのかわからないエンジニアにはストレスが生じる。
内容がわからない以上、事前に何を準備すればいいかわからない、そもそも本当に自分が参加すべき会議なのかすらわからない。
正体不明の何かに貴重な限られた業務時間を奪われるという感覚が不快であることは想像に難くないはずだ。
このとき、「何の件ですか？」とエンジニアに尋ねられても絶対に詳細を話してはいけない。
仮に答えたとしても「○○のシステムについてちょっと聞きたくて」のように非常に抽象的に回答してお茶を濁そう。濁っていれば濁っているほどいい。
あなたとはもうこれ以上会話する気はありませんよ、というオーラを醸し出して逃げ去ろう。
会議当日まで何が起きるかわからないという不快感で継続的にダメージを与えることができる。
特に効率を重んじるタイプのエンジニアはなるべくスマートに会議を進めるために事前に準備したいと思っている。そういうタイプのエンジニアは特に特攻ダメージが入るので積極的に使っていこう。
多めに時間をおさえる
これも予定を招待するときに使える基本的なテクニックである。
もし会議の時間が足りなくなって議論が充分に行えなかったらどうしようという不安に駆られたことはないだろうか。
そんな不安も解消できる一度で二度おいしいテクニックだ。
会議の時間を余裕を持っておさえよう。最低でも1時間はおさえたい。
理想は2時間以上確保できるといい。会議の進行も急がずゆっくり行えるため、進行役の方にも非常に優しいテクニックだ。
会議の資料もじっくり読み合わせできる。会議が始まったらまず資料をゆっくり読み合わせしよう。
これで会議に置いてけぼりになる人もいなくなり、非常に効率良く会議を進行できる。
全員が同じ前提条件で会話できるため議論も活発になること請け合いだ。
エンジニアは予定が多めに押さえられた時点でストレスが生じる。
開発タスクを消化するための貴重な勤務時間の内、これだけを奪われた、というだけで精神的にダメージが大きい。
会議を早く終わらせてしまうと、「やった！時間が浮いたぞ！」という安堵感を与えてしまうため、可能であれば話を脱線させるなどして、押さえた時間ギリギリいっぱい使うことが望ましい。
時間をオーバーする
ここまで読んでくださった読者の皆さんであればこのテクニックがいかにエンジニアのやる気を削ぐ上で効果的であるかは理解いただけているだろう。
「やっと終わる…自分のタスク消化できる…」と思って安堵したエンジニアに対して追い打ちをかけよう。
「あと少しでアジェンダ消化できるのでこのまま延長してやっちゃいたいと思います。」と終わり際に発言しよう。
当初予定していたよりも作業時間が少なくなることでプレッシャーを与えるのだ。
このときエンジニアが退席する可能性を下げるために「○○さんもちょっと残ってもらっていいですか？」と一言添えると効果的だ。
ぜひ試してみてほしい。
応用編
正直、入門編の内容だけでもかなりエンジニアのやる気を削ぐことができる。
まずは入門編の内容を完璧にこなせるように日々意識して欲しい。
それだけで飽き足らず、より高みを目指したい人のために応用編も用意した。
かなり難易度も高く、専門的な内容であるため適用できる場面も限られるが、うまく決めることが出来ればエンジニアの心をへし折ることは容易いだろう。
何度も同じ説明をさせる
これは入門編では？と思うかもしれない。
確かに何度も繰り返し「すみません、今の説明もう一回してもらっていいですか？」と聞くのは簡単だ。
しかし同じミーティングの中で何度も同じ質問をしてしまうと、頭の悪いやつに見えてしまう。それは損だ。
今回ご紹介するのはもっとロングスパンで行うテクニックである。
エンジニア技術的な質問を投げかける。「ここってどういう処理になってるんでしたっけ？」のような質問でいい。
そしてその場ではわかったように振る舞う。このとき本当にわかっていてもわかっていなくてもいい。
なんなら本当にわからなかったらもう一度聞いてもいい。エンジニアはより平易な表現で説明してくれるはずだ。
その会議はそのまま終える。そして少し間を空けよう。少なくとも1週間は欲しい。
そしてタイミングを見計らってこのように切り出す。「すいません。この間説明してもらったと思うんですけど、ここの処理どうなってるかもう一度教えてもらっていいですか？」
エンジニアは前回と同じように丁寧に説明してくれるはずだ。専門外のテーマに関する説明なんて、エンジニアでも簡単には覚えられない。この時点では快く教えてくれるはずだ。
これを適度に間を空けて繰り返し行う。
同じ説明を何度もさせられている内にエンジニアはこう思うはずだ。「どうせまた説明してもすぐ忘れるんだろうな…」こんなやるせない気持ちに支配される。
このテクニックのポイントは理解できなかったのではなく、時間が空いたので忘れてしまったと思わせることである。こうすることで理解力がない無能だと思われるリスクを減らせる。
どう考えてもいらない資料を作らせる
かつてはExcelやWordのようなMicrosoftが作った最高の嫌がらせツールが隆盛を誇っていた。1
資料作りも昨今ではWeb上のWikiライクなツールで済ませることが増えてきて、多少楽になってしまったとはいえ、未だにエンジニアのやる気を削いでくれる有効な方法である。
会議の事前資料もたっぷり用意してもらおう。
検討技術のメリデメを表にまとめてもらっちゃったり、
要件定義もロクに済んでないのに現段階での想定するAWSアーキテクチャ図と料金概算も作ってもらって、
使用するライブラリとそのバージョン一覧も記載してもらいましょう。
資料がいっぱい増えるとなんとなく仕事も進んだ気がするし、仕事終わりのビールもうまい！！
エンジニアのやる気も削げるし一石二鳥で最高だ！！ガッハッハ！！🍺
事前に資料を配った上で、当日資料を読み上げる
これはなかなか玄人好みの小技であるが、うまく決まると爽快なので覚えておいてほしい。
まず事前準備として、一旦会議で話す内容とそれに必要な資料を準備をして、事前に会議参加者に送付しておく。
そう、入門編で習った内容とは真逆のことをするのだ。この時点でなかなか難易度が高い。
送付の際にポイントがあって、事前に資料に目を通してもらうように一文添えておこう。
まあ、そんなことをしても大抵の人は目を通さずに会議に参加するが、エンジニアという生き物はなかなか几帳面な部分があって、意外と事前に目を通して参加してくれる。これが重要なポイントである。
そして当日、会議が始まったら本題に入る前に丁寧に丁寧に端から端まで舐めるように資料を読み上げよう。
そう、万が一当日までに時間がなくて事前に資料を一読できなかった参加者がいた場合、その人が議論の置いてけぼりになるリスクがある。
その防護策としてこれは実に理に適っている。
そしてエンジニアはこう思うに違いない。
＿人人人人人人人人人人人人＿
＞ なぜ事前に読ませたし ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣
完全勝利である。
なぜ事前に読んできた自分が損をしなければならないのだ。
そもそも事前に目を通してこない方が悪いのだから、そういうやつは無視して議論を進めるべきじゃないのか！！
無力感がエンジニアを襲う。もう完全に心が折れる寸前だ。
細切れに会議を設定する
多様なタスクを抱えるワーカーの生産性にとって、コンテキストスイッチというものの影響は大きいらしい。
コンテキストスイッチという言葉に聞き覚えがない方は下記の記事を参考にしていただきたい。
コンテキストスイッチが生産性に影響を与える以上、会議のタイミングも重要であるだろう。
タスクに取り掛かっている間に割り込みで打ち合わせが入ったりすると、生産性が低下するらしいが、そんなエンジニアの事情など我々の知ったことではない。お構いなしにぶち込んでやろう。
エンジニアのやる気を更に削ぐ方法は簡単だ。
あなたはあるエンジニアくんにサービスのドメイン変更PJTについての事前ヒアリングを実施しようと思っているとしよう。
まずは会議に招待したいエンジニアくんの予定をカレンダーで確認しよう。まあここまでは普通だ。
ふむふむ。どうやらエンジニアくんは1件定例会議の予定がある。
朝一出社して、メールやチャットの確認、その日のタスクや他のメンバーの進捗状況などを共有し終えたあたりで、一旦会議を挟んでその後じっくりタスクに取り掛かろうという魂胆だろう。
浅はかなエンジニアよ、その程度の目論見、カレンダーを見ただけで手にとるようにわかるのだよ。
というわけでさっそく貴重な作業時間を削るべく、会議に招待しよう。
と、入門編を終えたばかりの諸君はこのように予定を押さえたくなるかもしれない。
休憩する間も与えずに間髪入れず会議漬けにしてやろう、と。
チッチッチッ。甘いな。もっといい方法がある。
こうするのだ。
わざと空けた1時間でタスクに取りかかるわけだが、1時間後にすぐまた会議がある。
せっかく脳がタスクに慣れてきたところで一旦リセットされる。そして午後からまたタスクに取りかかる。
つまりこれでエンジニアくんの午前は死んだも同然なのである。
その死んだ午前と同様に、エンジニアくんがカレンダーを見る目もまた死んでいるだろう。
このテクニックを使うに当たっての注意点として、空き時間をランチなどに使われる恐れがあるため、12-13時あたりの時間帯を空き時間にするのは避けよう。
会議間の空き時間を無駄にさせるというのがこのテクニックの重要な点なのだ。
読者からのお便り
読者の皆様からも大変貴重なテクニックをご紹介いただいたので、ぜひ紹介させていただきたい。
ラジオネーム@LesserFoxさんからの投稿です。
開始時刻を遅らせる
「終了時間がオーバーするのも効果的だが開始時刻になっても数分程度メンバーが集まらず会議が始まらない状態を頻発させるのも同じく効果的である。
その間に少しでもタスクを消化しようかな？とエンジニアが手を動かしだしたところで「メンバーそろったから始めたいんだけど、いける？」(意訳: 準備できてないのあとお前だけだぞ。)と軽く与圧するとなお良い。
この時、あまり開始が遅れすぎるとエンジニアのタスクがしっかりと進行してしまったり、会議時間の不足で会議自体がリスケしてしまう可能性があるのであくまで数分、致し方ない事情として目をつぶれる程度に抑えるのがポイントである。
また、これにより案の定会議時間がオーバーすれば追加でダメージボーナスが入る。」
これは明日から使える素晴らしいテクニックだ。
たった数分でダメージを与えられるコスパの高いテクニックなので、ぜひ皆さんも真似して欲しい。
会議に遅れたときに申し訳なさそうに入るのではなく、さも当たり前かのように堂々と会議を始めよう。
まとめ
エンジニアのやる気を削がないように会議体を設計しよう
ここまで読んでいただいた皆さんはお気付きのことと思うが、もちろん本記事はネタである。
絶対に真似をしてはいけない。この記事はアンチパターンをグッドパターン風に記述するという技法を使ったネタ記事なのだ。
私はこれを勝手にAnti-Good Inversion Method(AGIM)と呼称している。
単純にアンチパターンを書き連ねただけだとパンチが足りないな、というときに使えるテクニックなので覚えておいて欲しい。
本記事の冒頭でも述べさせていただいたが、仕事において会議は重要である。
会議の運営はソフトスキルであるがゆえ、軽視されがちであるが、誤った運営方法はチームのメンバーの生産性やモチベーションを著しく低下させてしまう。
もし今の会社やチームでこのような会議運営がなされている場合はそっとこの記事のURLをチャットにシェアして気付きを与えてあげよう。
おわりに
弊社では、経験の有無を問わず、社員やインターン生の採用を行っています。
興味のある方はこちらをご覧ください。
-
本記事はネタです。ExcelやWordは素晴らしいツールであり、悪いのは用法用量を守れない人類です。 ↩