タスク集中型のエンジニア職とミーティング駆動型のビジネス職
ソフトウェアエンジニアの仕事の進め方は、ビジネス職のそれとは根本的に違います。まったくの別ものだと言っていいぐらいに。それらを名付けるなら、前者の仕事の進め方は「タスク集中型」で、後者は「ミーティング駆動型」といったところでしょうか。
もし、職種ごとに仕事が完全に分離して接点を一切持たないとしたら、この違いはおそらく問題にならないでしょう。が、もちろんそんなことがある訳もなく、互いにコミュニケーションを取らなければ組織として機能しません。そのため、仕事の進め方の違いは、人と人との接点である「コミュニケーション」において、しばしば悪い影響を及ぼすのです。
悪い影響を避けるためには、この違いを意識したコミュニケーション設計が必要です。しかし、残念なことにそのような上手くいく設計を、全ての組織が手にするわけではありません。同じ組織で共に働いていても、職種が異なると、相手のやっていることは十分には見えないものです。この不透明性が、気づかぬうちに非効率なコミュニケーションを生み出してしまうのです。
Maker's Schedule, Manager's Schedule
本記事とあわせ、書籍『ハッカーと画家』の著者でもあるポール・グレアム氏が2009年に公開した記事 "Maker's Schedule, Manager's Schedule（英語原文）" を読むことをおすすめします（日本語訳はこちら）。
今回の記事で取り上げたテーマはもともと、10月4日に投稿したnote記事『開発チームの時間を無駄にしない。それはプロダクト開発における重要課題である』の草稿に含まれていました。しかし記事が長くなり過ぎたためにカットし、あらためて一つの記事となるよう書き起こしたという経緯があります。
その最中にちょうど発表された2022年10月第3週のはてなブログランキングで1位となったnaomasabit氏の記事の中で "Maker's Schedule, Manager's Schedule" が取り上げられており、その存在を知りました。ここで言う "maker" とはエンジニアのことです。比較相手が "manager" である点は本記事とは異なりますが、偶然にも本記事ととても似たテーマを扱ったものです。
なんと言うか、オリジナリティのある記事を書くというのは本当に難しいものだと痛感するところです……本題に戻ります。
ミーティング駆動型
ビジネス系の職種は、その性質から、ミーティングが仕事を駆動するような働き方であることが多いのではないでしょうか。議論したり、アイデアを出し合ったり、提案したりされたり、判断を仰いだりといったことが仕事の中心なのです。ミーティングによって、担当する仕事のアウトプットが形作られていき、1度のミーティング、あるいは複数回のミーティングを経て、最終形に達するようなイメージでしょうか。
ミーティング以外の時間は、次のミーティングに向けた準備にあてられることも多いように思います。そのために使われる時間は、ミーティングとミーティングの合間に断片的に散らばる余白です。1コマあたり、せいぜい30分から1時間程度でしょうか。彼らのカレンダーは、さながら時間割のように、几帳面に登録された多くの予定とその合間に入る余白が連続するパターンが整然と並びます。
彼らの仕事の舞台であるミーティングというものは、1人では成立しません。必ず複数人で行われます。できる限りその場で結論を得るために、それに必要な権限、知識、能力などを持つ人たちを参加者として招集します。5人、10人、あるいはそれ以上の人たちが関わることになるかもしれません。そして、予定された時間に関係者が集まり、1つのテーマ、あるいは複数のテーマについて話し合うのです。
このような会議体は、チームやグループとしての定例ミーティングとして運営されることもありますが、多くは個人が担当する案件ごとに随時的に設けられます。ビジネス職はみなそれぞれが、いくつかのミーティングの主催者となり、巧みなファシリテーションによって、担当案件を進行させていくのです。
これが、ミーティング駆動による仕事の進め方です。
タスク集中型
一方で、ソフトウェアエンジニアにとっての仕事の中心は、ひとり、あるいは少人数で何かを作り上げることです。そういった作業に集中する時間をどれだけ確保できるか、それがアウトプットの質や量に大きく影響します。
彼らがひとたび仕事に取り掛かれば、数時間はその作業をやり続けます。時間とともに徐々に集中力が高まっていき、頭の中ではいま取り掛かっている作業に関する考えが次々に処理され、構造化されていきます。その間は、できることなら誰にも邪魔されたくない。無理な割り込みが入れば、頭の中で組み立てた論理構造が霧散してしまうからです。そんなことになれば、また時間を掛けて一から組み立て直すことになってしまいます。
彼らにとってミーティングとは、仕事を上手く進めるために必要な話し合いの場です。そのようなミーティングで自身が主催者となることもあまりなく、チームやグループとして実施する数少ないミーティングがあるのみです。そこで話し合われるのは、次の作業の計画や現在の作業を進める上での障害となっている問題の解決方法、完成した成果物のレビュー、どのようにすれば仕事のパフォーマンスがより向上するかといった内容です。
このようなミーティングは基本的に定例で行われます。実施する曜日や時間帯も、作業への集中の妨げにならないよう計画されています。もちろん、作業を進める上で誰かに声を掛け、アドホックなミーティングを実施することもあります。そのような場合でも、声を掛ける側のエンジニアは、相手の作業の邪魔になるかもしれないことを配慮しながら話しかけます。
エンジニアたちが受け持つ仕事の性質は、これほどまでに作業への集中にこだわる必要のあるものなのです。
作業時間を断片化させるミーティングはマルチタスキングを生む
様々な職種の人たちが集まり、組織として高いパフォーマンスを発揮するためには、仕事の進め方のこのような違いを互いに理解することが欠かせません。不理解なままで仕事を進めようとすると、表立った衝突や対立が発生したり、気づかぬところで仕事の効率性を犠牲にすることになりかねません。
陥りがちな失敗は、ビジネス職の仕事の進め方に、エンジニア職を巻き込んでしまうというパターンです。ソフトウェア開発を事業の核に据える組織であれば、ビジネス職にとってエンジニアは最重要の関係者です。要件やフィードバックを伝える相手であり、ソフトウェアシステムに関する有識者でもあります。ミーティングには、エンジニアの参加が欠かせません。だから、ビジネスメンバー個々が開催するミーティングに、エンジニアが次々と招集されてしまう。その結果、エンジニアは作業に集中するための連続した時間が確保できなくなり、非効率な働き方を余儀なくされます。
エンジニアからしてみれば、こういったミーティングへの参加はマルチタスキング以外の何ものでもありません。集中して作業に取り組むために必要な連続した長い時間枠の所々に、30分から1時間程度のミーティングが重なって実施されるからです。このようなスケジュールを私は「作業時間の断片化」と呼んでいます。作業に取り組んでいたエンジニアは、ミーティングの開始時間になるといったん手を止め、何とか頭を切り替えてミーティングに臨みます。ミーティング終了後、また頭を切り戻して作業を再開しようとしますが、それには時間がかかります。集中力も途切れてしまっています。そもそも、ミーティング前の頭の中の状態を完全に再現することは不可能です。
だったら、数時間かかる作業をもっと小さな、例えば30分で終わる粒度のタスクに分割して取り組めば良いと思うかもしれません。そうすれば、次のミーティングまでの短い時間の間にそのタスクを終わらせることができ、マルチタスクにはなりません。しかし、エンジニアのタスクの最小粒度は、たいてい数時間かかるものなのです。それより小さく分割することが難しい。そもそもこの背景が、ビジネス職とエンジニア職の仕事の進め方の違いを生んでいるのかもしれません。
ミーティングのような同期コミュニケーション手段は、組織として効率性を観点に設計すべき対象です。例えばミーティングの時間枠を営業時間の初めの方や昼休みの直後、営業時間の終わり頃などに設定すれば、エンジニアの作業時間が断片化されず、マルチタスクも起こりにくくなります。
エンジニアのレスポンスタイムは悪いのか？
私が知る限り、チャットやメールに対するビジネスメンバーのレスポンスはクイックです。ミーティングも含め、多方面とのコミュニケーションが仕事の中心であることから備わった反応速度なのでしょうか。
それに比べてエンジニアメンバーの反応速度が悪いのかと言うと、そういった印象は持っていません。しかし、メッセージの発信者が期待する暗黙的な時間内に返信することを苦手とする人をちらほらと見かけます。チャットメッセージに数時間、あるいは数日返信せず、ビジネスメンバーからの不満が吹き出すことが時々あります。どの程度の時間内で返信するのが適切であるかは分かりませんが、不満の矛先となるエンジニアメンバーの反応速度が他と比べて相対的に遅いのは確かです。
このような状況が感情的な対立にまで発展したケースはまだ見たことがありませんが、信頼関係への影響はあるかもしれません。メッセージへの返信を無責任に放置している。待たされる側からはそう見えてしまうようです。
返信を待たせている側のエンジニアに事情を聞いた限りでは、彼らはメッセージを放置しているわけではありません。多忙すぎてメッセージへの返信が滞ってしまっているように見えるケースもありますが、実際にはミーティングの問題と根本原因は同じではないかと感じます。マルチタスキングです。
チャットメッセージに対する返信という行為も、ミーティングよりは短時間とは言え、頭の切り替えが必要な活動です。そこでかかる認知負荷がストレスになるのです。メンションされたメッセージに返信するためには、まずその内容を読んで理解しなければいけません。その内容が、即答できるものならまだ良いのですが、そうでなければ必要な調査や工程を踏むことになります。返信できる材料が揃ったら、文面を考えて返信する。この一連の流れを終えてようやく作業を再開しようとした時に、頭の中と集中力を戻すことが困難なのです。だから、返信を後回しにしてしまうようです。
そもそも文面を読んで理解することすらマルチタスクによるスイッチングが発生するため、読むことも避けてしまう。そうして作業に集中しているうちに、次々と新たなメッセージが届きます。ようやく作業を終えた頃には数時間が経過し、いくつかのメッセージには返信するものの、その中から返信が漏れるものがあっても不思議ではありません。
文字数の多いメッセージは特に、読むことすら後回しにされる傾向が高いようです。また、読んだとしても内容が込み入っていて理解するのに時間がかかりそうなメッセージも後回しにされがちです。メッセージの送信側は、この辺りに工夫の余地があるように思います。「相談があるので○○時頃にお時間ください」ぐらいのメッセージにして、口頭で説明するという手もあります。そうすればきっと、「了解」といったスタンプがリアクションとしてすぐに返ってくるでしょう。
メンションされた側のエンジニアも、「後ほど返信します」ぐらいのリアクションは返しておいた方が良いでしょう。そうすれば、メッセージに気付いていることを相手に伝えることができ、安心してもらえます。このようなリアクションのために、スタンプのバリエーションを増やしておくのも手だと思います。
最後に - カレンダーの余白は空き時間ではない
カレンダーアプリケーションを使って予定を管理している人は多いのではないでしょうか。個人で導入したツールではなく、会社として社員全員が使うツールです。そこにはミーティングの予定はもちろん、休暇の予定や採用面接など、明確に時間枠が決まっているものや、一緒に働く仲間に伝えておくべき予定などが登録されています。
カレンダーでの予定の共有は便利である反面、予定が可視化された同僚のカレンダー内の余白を空き時間だと誤解する人が多いように思います。集中時間を確保したいエンジニアは、防御策として余白部分にも「○○機能の設計と実装」といった予定を入れたり、「ミーティングはこの時間帯に」といったアナウンスを予定として登録するのも良いのかもしれません。ちょっと面倒ですけどね。
この記事が気に入ったらサポートをしてみませんか？