組織がサイロ化したままでも、情報の入口と出口だけ整えれば、進捗の確認、プロジェクト間の調整など「仕事のための仕事」はなくせる

ワークマネジメントについて考えた前回の記事以降、いろんな人に話を聞いた。ワークマネジメントの違う説明を考えてみる。どうでしょう！

「仕事のための仕事」が増える問題をなんとかするのが、ワークマネジメント（前回の記事と同じ文章）

優秀なメンバーを集めても仕事やプロジェクトが大きくなるに従って、仕事の範囲や責任、進捗の確認、プロジェクト間の調整、各種ツールでのやり取りなど、「仕事のための仕事」が占める割合が膨大になる

従業員の60％は従来費やすべき本来の仕事の倍の時間を日々さまざまなチャネルで発生するメッセージや依頼事項、確認事項、突然の仕事、進捗会議や調整事項に対応をする「仕事のための仕事」の時間に浪費してしまっている、という調査

引用元：「ワークマネジメント」が秘める可能性。マインドフルネスなチームの働き方とは

ワークマネジメントって結局なんだよ、にいい感じで答えてみたい

というチャレンジの2回目。

前提1:組織のサイロ化とは

そもそもサイロとは、家畜の飼料、米や麦などの農産物などを個別に貯蔵しておく大きい容器あるいは倉庫のことです。
各サイロは、互いの内容物が混ざらないように独立しています。つまり、サイロ化とは各部門などが独立して業務が完結しているが、各々の間で壁があるために連携できない、縦割り構造になってしまっている状況のことを指します。(引用元)

前提2:サイロにもいろんな大きさがある。

個人間でサイロ化する･･･本人は自分の業務を遂行できているが、個人同士の連携が難しい状態。

プロジェクト間でサイロ化する･･･各プロジェクト内では業務に問題はない。ただし、プロジェクト間では連携が難しい状態。（プロジェクトの定義はこちら）

複数プロジェクトのまとまり（部署、事業部等）間でサイロ化する･･･一つの組織内では業務に問題はないが、組織間の連携が難しい状態

前提3:サイロ間の連携が必要な場合に、「仕事のための仕事」が発生し、上位のサイロが担当する

・2つ以上のプロジェクト間の連携が必要になった
・互いの情報は公開されてないため、窓口の人が口頭で話すための打ち合わせが設定される
・打ち合わせで、互いのプロジェクトの利害を公開し、落とし所を見つけたりいろいろと「調整業務」が発生する。これが仕事のための仕事。
・サイロ間の調整は「その2つのサイロ（プロジェクト）を含む上位のサイロ（組織）」がやることが多そう。

前提4:サイロの大きさが複数ある場合、「仕事のための仕事」の連鎖が起きてもっと工数が増える

例：
・プロジェクトAとプロジェクトBで「A→Bの人員異動」についての調整業務が行われる。人材が異動することは決定した。具体的の誰が異動するかはその場の打ち合わせでは決められなかった。
・プロジェクトAの内部で「小さいサイロ」が出来ている。稼動状況的にプロジェクトBに異動可能な人材を誰にするかを「プロジェクトA内の小さいサイロ」間で調整をする必要がある（これが仕事のための仕事の連鎖）

「仕事のための仕事」を減らすために、サイロ間の仕事のリクエストの送受信のフォーマットだけ合わせるのがワークマネジメントの第一歩では。いきなり全部「見える化」しようとすると無理。

プロジェクト間の人材異動を簡単にするために、全人材のスキルセットを見える化しよう、みたいな方向に行くと、負担が大きい（個人的にはここがひとつ発見）。

第一歩は「他のプロジェクトに人材異動を依頼するときには、こういう項目で依頼する」というサイロ間の取り決めだけ決めておくのはどうか。すると、その取り決めに合わせて、各サイロ内で個別最適化される。でもそれでいい。サイロ内にはできるだけ口出ししないというのがよさそう。

フラットな組織（定義は読んでる人に任せた）を目指すときには、結果として「個人が自分が所属してない事業部の情報まで見えている」を目指すことになる。すると結果として「個人、プロジェクト、事業部」等、大きさの違うサイロ間の仕事のリクエストの送受信フォーマットが全部整えるということになる

タイトルに全部書いてしまった。A事業部に所属する「Xさん」が、B事業部の状況を把握するためには、A事業部とB事業部で何かしらフォーマットがそろってないと「誰かに時間をもらって口頭で確認する」という業務が発生してしまう。という当たり前の話だ。

もしくは、なんか偉い人から状況を確認されて答えたり、進捗を報告するための資料をつくるという仕事がたくさん発生する。フォーマットが整っていたら、偉い人が自分で読み解けばよい。

みんなで同意すべきことは何か？自分の仕事を依頼したり、されたりするときの自由度は減るから多少やりにくくなるかもしれない。でも、そこのフォーマットを合わせることで、結果として他の人達の仕事量を減らせるから我慢して。

仕事のための仕事が減ったとしても、それで成果がもっとでるわけではない。「仕事のための仕事」が減ったとしても、人件費がすぐに減るわけではない。だから、そこはちゃんと考える必要がある。

仕事のリクエスト方法を統一してみると･･･？
・依頼する側はやりにくくなる（−）
・依頼される側はやりやすくなる（＋）
・チーム全体としては、進捗の確認、プロジェクト間の調整等が減る（＋）
・上記3つによって、成果が増えるのか、コストが減るのか等の仮説を立てて検証する

ワークマネジメント、ツールの導入の前に、社内の仕事の方法、特にサイロ間の仕事のリクエストに関するガイドラインをつくるというのがありそう。

それこそこういうレベルのとかもあるかも。

・緊急でない場合はEメール。
・Slackは、一人または複数の人への簡単な質問や、何かについての注意喚起のために使用します。
・個人対個人の会話は、Slackでのやりとりでは対応できないような複雑な内容の場合や、ミスコミュニケーションの可能性が高い場合に使用します。
・2人以上の人が何かを議論する必要がある場合のミーティング。

前回のよりはわかりやすくなったかなあ･･･。またいろんな人に聞いて考えます。