無計画なコミュニケーションにいつまで振り回されるの？
社内ミーティングに追われ、自身の担当タスクを処理する時間が取れないという話を耳にすることがあります。
複数の人が集まり、組織として共通目的を持って協働するためには、コミュニケーションが欠かせません。しかし一方で、社内コミュニケーションにかかる負担は、組織のパフォーマンスを減衰させるコストにもなり得ます。
必要なコミュニケーションを取りながらも、考えること、手を動かすことに集中する時間も確保する。それには、コミュニケーションコストを積極的にコントロールする必要があります。一体どうすれば、そんなことが実現できるのでしょうか。
リレーに伴うコミュニケーションコスト
組織における業務というのは、基本的に「リレー」の連鎖としてデザインされています。ある工程での処理が終わると、次の工程に引き渡される。それが終わるとまた次に引き渡される。このようなリレーを繰り返すことで、最終的な成果物を生み出します。業務とは言わば、リレーの連鎖によって生じるフロー（流れ）であり、そこで辿る経路がいわゆる業務プロセスです。
コミュニケーションは、このようなプロセスとして描かれたネットワーク上を流れるフローユニット（個々の仕事・案件）を滞らせず、円滑にすることを目的とした活動です。
本記事で題材として取り上げたいのは、リレーに伴って工程間で発生する社内コミュニケーションです。その中でも特に、リレーの発生頻度が不規則なものに焦点をあてます。
例えば見積もり依頼がこれにあたります。依頼する側と依頼される側が集まり、見積もりに必要な説明や質疑応答を行う、といった形態です。
プッシュ方式による不確実性の拡大
このようなリレーに伴う社内ミーティングの多くは、リレーの必要性が発生するたび、前工程側によってミーティングが調整され、後工程側はそこに出席する形をとります。これは、前工程から後工程に対するプッシュ方式のリレーです。
後工程側にとって、プッシュはスケジュールへの割り込みです。次々に社内ミーティングをプッシュされ、時間が奪われていくと、その他の業務が滞っていきます。ミーティングを通して新たな業務タスクが追加されることを考えると影響は更に大きいと思います。
それより深刻なことは、発生頻度が一定ではないということです。この予測困難な割り込みが、後工程担当者が抱える業務スケジュールの不確実性を押し上げます。実務に割り当て可能な時間が安定しないからです。そしてその結果は残業となってあらわれます。
業務スケジュールは、実務への時間の割り当てが一定であることを前提として組み立てられています。そこに、発生頻度が一定ではない割り込みが発生し続けると、その不規則な波がそのまま業務時間の波となります。その波が上限を超えた日は、残業でカバーせざるを得なくなる。期限までに仕事を終らせることができなくなるからです。こんなことを続けていては、後工程側は皆、疲弊してしまいます。
プル方式によるコストコントロール
後工程側の業務スケジュールの不確実性を下げるためには、プッシュ方式でのリレーというフローをやめる必要がありそうです。
それならば、後工程側によるプル方式でのリレーという選択肢があります。後工程側の処理能力や負荷状況に応じてリレーに伴うコストをコントロールし易くなります。
手法としては、後工程側が任意のタイミングで前工程側に対して「次のフローユニットはあるか？」と確認することもできますが、これだと非効率です。リレー可能なフローユニットが存在することを前工程があらかじめ意思表示しておき、それをもとに、後工程が任意のタイミングでフローユニットを引き受けるためのコミュニケーションを行う形が良いでしょう。
任意のタイミングというのは、例えば、毎週月曜の10時から12時の2時間の間に20分ずつ合計6コマのミーティング枠を集中的に設け、その週に処理するフローユニットを受け取ってしまうのも良いでしょう。あるいは、毎日17時からの30分をその枠としておさえておき、1日の仕事のおわり頃に、次の日に処理するフローユニットを受け取るという仕事のリズムを作るのも良いかもしれません。
非同期方式によるコストコントロール
リレー方式の3つめとして、非同期という選択肢もあります。
非同期方式では、後工程側が任意のタイミングでフローユニットをプルすることに加え、前工程側も任意のタイミングでフローユニットをプッシュできます。コミュニケーション手法としても、ミーティングではなく、非同期が可能な手段を利用することになります。
非同期コミュニケーションの手段として考えられるのは、チケットやドキュメンテーションなどです。前工程側は、後工程側に引き渡そうとするフローユニットに関する情報をドキュメントにまとめておく。後工程は、任意のタイミングでそのドキュメントを読んで、フローユニットの処理に着手する。そのような流れになります。
私自身は、ミーティングのような同期コミュニケーションより非同期コミュニケーションが好みですが、業務の性質によっては、非同期コミュニケーションがかえってコストを押し上げることもあり得ます。
前工程側がドキュメントの作成に時間がかかり過ぎたり、後工程側がそのドキュメントを理解するのに苦労することもあります。その結果、両者でのコミュニケーションが何度か往復することもあるでしょう。あるいは、コミュニケーション品質が不十分で、両者の認識齟齬が後で発覚し、手戻りによるコストが増大することも考えられます。
WIP制限によって可視化されるボトルネック
さて、リレー方式をプルや非同期に切り替え、コミュニケーションコストも含めた後工程側の負荷を平準化すると、リレーを待つフローユニットが「待ち行列」を作りはじめます。これらのリレー方式では、後工程側で処理するフローユニットの数や量を制限（WIP制限）するため、空きが出るまで残りのフローユニットが待たされるのです。
この待ち行列が次第に伸びていくようなら、後工程の処理能力では前工程の処理量を捌ききれないということです。残業による稼働時間の拡大でカバーされて隠れていた潜在的な問題が顕在化したのです。
上の図では、前後2つの工程で構成された業務プロセスのうち、後工程がボトルネック（制約）となっています。前工程の処理能力（スループット）が6、後工程が4であるため、プロセス全体としては4以上の処理能力が出せません。前工程の処理量を4より大きくしてしまうと、待ち行列は長くなる一方です。
業務への需要に対し、業務プロセス全体の処理能力が不足して供給が追いつかない状態は、機会損失につながりかねません。ボトルネックを解消することが課題であるのは明らかです。
もちろん、業務への需要に対して供給が過多であるなら、業務プロセスの処理能力が過剰であり、単なる「作り過ぎのムダ」です。余剰能力を他にまわすことを検討すべきでしょう。
スケールアップよりスケールアウト
新たに「ボトルネックの解消」という、処理能力に関する課題が明らかになりました。これはもはや、本記事のテーマである「コミュニケーションコスト」とは関係の薄い話に感じられます。本当にそうでしょうか。
ボトルネックを解消する現実的な解決策としてまず考えられるのは、ボトルネックとなっている工程を担う体制をスケールさせることで、その方法は2軸あります。
ひとつは、ボトルネック工程を担うチームの人数を増やすこと。つまりスケールアップです。
ただし、チーム内のコミュニケーションコストは、その人数$${n}$$に対して$${n^2}$$ のオーダーで増加します。増員の程度によっては、処理能力の向上より、コミュニケーションコストの増加の方が勝る可能性もあるので注意が必要です。
次にスケール方法として考えられるのは、ボトルネック工程を担うチームの数を増やすこと。スケールアウトです。
この方法であれば、チーム内のコミュニケーションコストの増加もなく、期待した処理能力を得られる可能性が高いでしょう。
いずれにしても、増員を必要とするスケールアップやスケールアウトという解決策は、実現難易度も高く、時間がかかる方法であることが難点です。
クロスファンクショナルでマルチスキル
よく考えてみると、リレーに伴うコミュニケーションというのは、なんの付加価値も生み出していません。工程間でのコミュニケーションコストが発生しているだけです。これを「運搬のムダ」や「引き継ぎのムダ」と呼びます。
このようなムダは、工程ごとに体制が分かれていることで発生します。連続する複数の工程をひとつの体制がまとめて担当すれば、このムダを削減できるかもしれません。つまり、クロスファンクショナルチームです。
クロスファンクショナルチームは、各工程の体制をまとめただけではうまく機能しません。後工程側の担当者が、前工程が終わるまで手持ち無沙汰になるだけです。専門とする工程が何であるかに関係なく、得意領域を越えて互いに協力し合うことが求められます。このように協力し合うことで、各自のスキルは他の領域に及ぶようになり、マルチスキル（多能工）な人材になっていきます。
クロスファンクショナルチームはその名の通り、業務に必要な機能が凝集されたチームです。凝集度が高いチームは業務を独立実行可能であるため、他のチームとの結合度が下がります（疎結合）。それが、チーム間でのリレーに費やされるコミュニケーションコストを削減する効果をもたらします。
※ソフトウェアプロダクト開発チームの凝集度や結合度については、はてなブログの記事でも扱いました。
プロジェクトよりプロダクト
必ずしもマルチスキル化しているとは限らないのですが、「プロジェクト」は、クロスファンクショナルで業務を進める体制のひとつです。
業務遂行をプロジェクトで進めることを好む組織は、1人あたりが参加する定例ミーティングの数が多い傾向があるように思います。関わるプロジェクトの数が複数に及ぶことがその原因です。
体制を組むと、そこにはコミュニケーションが必要となります。その1つの形態が、定例ミーティングです。それゆえ、所属する体制の数が多い人ほど、それに比例してコミュニケーションコストが大きくなります。
プロジェクトの数が多くなる理由のひとつは、プロジェクトというものが、個々の案件に対して立ち上げられることにあります。
業務、言い換えればサービスやプロダクトには、複数の案件が存在します。並走する案件が多ければ、それだけ多くのプロジェクトが立ち上がることになります。組織内の規模に対し、過剰な数のプロジェクトが並走すると、プロジェクトの掛け持ちが常態化、悪化する。組織全体の処理能力の多くがコミュニケーションコストに消費されてしまうのです。
対して、サービスやプロダクト自体にオーナーシップを持つのがプロダクトチームです。
プロダクトチームは、次々と発生する案件を順次さばいていきます。プロジェクトチームとは違い、体制が増殖しにくいため、1人あたりの定例ミーティングも増えにくいというメリットが得られます。
※ソフトウェアプロダクト開発業務に関するプロジェクトチームとプロダクトチームの比較については、別の記事でもテーマとして扱いました。
※プロジェクトを掛け持ちする兼務問題については、はてなブログの方でテーマとして扱いました。
スタートアップのようなスピードと俊敏さ
少人数でスタートしたばかりの企業は、コミュニケーションコストが小さいと言います。少人数であることが有利に働いているのは間違いありませんが、それが理由のすべてでしょうか。
彼らは、少人数という制約を受けることで、クロスファンクショナルでマルチスキルにならざるをえません。そうでなければ事業が成立しないからです。ここが、工程や職能で集まった少人数チームとの決定的な違いです。
クロスファンクショナルチームは、必要な業務機能がそこに全て凝集されています。それ故、全員が全体を俯瞰した視野を持ち、全体最適な判断を可能にします。
このようなチームを作り上げ、スケールアウトさせることができれば、組織はその規模に関係なく、スタートアップのようなスピードと俊敏さでビジネスを展開させ続けることができるのではないでしょうか。
この記事が気に入ったらサポートをしてみませんか？