前のページでは、一人の手元にある手順を名前で呼べるようにしました。では、その手順を部署をまたいで多くの人が使いたい場合は、どうすればよいでしょうか。このページでは、共通の部品を組織の中に置くという考え方を見ていきます。
一人の手順書は、その人のチームの中では便利に機能します。けれど同じような作業を、隣のチームも、また別のチームも、それぞれ独自にやっているとしたらどうでしょうか。手順書のレベルでの重複が、部署をまたいで積み重なっている状態です。このページでは、その積み重なりをどう解消するかを考えます。
部品を一箇所に置き、みんなでそこを使う
プログラムには、共通の部品をまとめて置いておく場所があります。日付を扱う処理、ファイルを読み込む処理など、多くのプログラムが同じように必要とする機能を、共有のライブラリとして一箇所にまとめておくのです。
それぞれのプログラムは、この共有ライブラリを呼び出して使います。自分でゼロから同じ機能を作り直す必要はありません。ライブラリの中身が改善されれば、それを呼び出しているすべてのプログラムが、恩恵を受けます。
ここで重要なのは、ライブラリを「誰が作り、誰が保守するか」が明確に決まっているという点です。使う側は中身の詳細を知らなくてよい代わりに、中身の正しさや品質には、作り手が責任を持ちます。共有される部品には、専属の担当が必要だということです。
もう一つ大事な性質があります。共有ライブラリは、一つのプログラムのためだけに作られてはいません。複数の異なる目的のプログラムから使われることを前提に設計されています。だからこそ、ある特定のプログラムの都合だけでは、勝手に中身を変えられません。変更するときは、そのライブラリを使っている全員への影響を考える必要があります。これは、後で見る落とし穴に直結する性質です。
仕事の言葉に翻訳する — シェアードサービスセンター
この考え方を組織にそのまま当てはめたものが、シェアードサービスセンター(Shared Service Center)と呼ばれる仕組みです。経理・総務・人事・情報システムなど、どの部署も似たような依頼を出す業務を、一つの専門チームがまとめて引き受ける形を指します。
たとえば、各部署がそれぞれ独自に経費精算の処理をしていたとします。営業部にも、開発部にも、それぞれ経費処理の担当者が必要です。やり方も、部署ごとに少しずつ違います。これは、前のページで見た「手順書が部署ごとにバラバラ」な状態が、人員配置のレベルにまで広がった状態です。
シェアードサービスセンターは、この経費処理を一箇所に集約します。各部署は、自分たちで処理する代わりに、シェアードサービスセンターに依頼を出すだけになります。処理のやり方は一本化され、処理に必要な人員も、各部署に分散させる必要がなくなります。
これは、ソフトウェアでいう共有ライブラリの組織版です。「経費処理」という共通の機能を、一箇所にまとめて置き、各部署はそこを呼び出すだけにする。DRY原則を、個人の手順書のレベルから、組織の人員配置のレベルにまで広げたものだと考えられます。
前のページで見た関数化との違いにも触れておきます。関数化は、一人や一つのチームの中で手順を名前化する話でした。シェアードサービスセンターは、その手順を実行する「人」そのものを、組織の中央に集約する話です。手順書という知識の共通化から、それを実行する体制そのものの共通化へと、話が一段進んでいます。
具体的な場面で見る
経理業務のシェアードサービスセンター。請求書の発行や支払い処理を、各部署がバラバラに担当している状態から、一つの経理チームに集約します。各部署は、必要な情報をフォーマットに沿って渡すだけで済みます。処理の品質が担当者の経験に左右されにくくなり、繁忙期の偏りも、集約したチーム内で調整しやすくなります。各部署に一人ずつ経理の詳しい人を置く必要もなくなり、組織全体で見た人員配置も効率化されます。
ヘルプデスクという共通窓口。パソコンの不具合やアカウントの設定変更を、各部署の詳しい人がその都度個別に対応しているとします。詳しい人の本来の仕事が、その対応のたびに中断されます。情報システムのヘルプデスクという共通窓口を一つ作れば、問い合わせは一箇所に集まり、各部署の担当者は本来の仕事に戻れます。対応の記録も一箇所に残るため、同じ不具合が繰り返されているかどうかも把握しやすくなります。
デザインの共通部品。資料のスライドデザインを、部署ごとに独自の見た目で作っているとします。毎回イチからデザインを考える手間に加え、社外に出す資料の見た目が部署ごとにバラバラという問題も起きます。共通のテンプレートやロゴの使用ルールを、デザイン担当のチームが一元的に管理し、各部署はそれを使うだけにします。
採用業務の共通化。各部署が個別に採用面接の日程調整や条件のすり合わせをしているとします。部署ごとに提示する条件の書き方や、選考の進め方に微妙な差が生まれやすくなります。人事が採用業務全般を引き受ける窓口になれば、各部署は選考基準を伝えるだけで、実務の負担から解放されます。候補者から見ても、窓口が一つに定まっている方が、やり取りが分かりやすくなります。
4つの場面に共通するのは、「多くの部署が同じように必要とする機能」を、一つの専門チームに集約しているという点です。各部署は、その機能の中身を知らなくても、依頼すれば結果を得られます。
落とし穴 — 共通窓口が渋滞する
共通化には、見落とされがちな落とし穴があります。一箇所に集約したことで、そこが混雑する窓口になってしまうことです。
ソフトウェアの世界でも、多くのプログラムが同じ共有部品に依頼を集中させると、その部品の処理が追いつかず、全体の速度がそこで頭打ちになる現象が知られています。これは、一箇所に集めたことの副作用です。
シェアードサービスセンターでも同じことが起こります。経費処理を一箇所に集約した結果、月末の締めのタイミングで依頼が集中し、処理が追いつかず、各部署の申請が滞ってしまうことがあります。分散していたときは各部署のペースで進んでいたものが、集約したことで、一箇所の処理能力に全体が縛られるようになります。
これは、6章で見たキュー(順番待ちの列)の考え方ともつながります。依頼が集中する窓口には、いつも一定の処理能力しかありません。到着する依頼の量が処理能力を超えた瞬間、列はどんどん伸びていきます。共通化を検討するときは、「集約後にどれくらいの依頼が来るか」を見積もっておくことが欠かせません。見積もらずに集約すると、便利になるはずが、かえって待ち時間の長い窓口を一つ作っただけ、という結果になりかねません。
もう一つの落とし穴は、共通の仕組みが「誰にも最適ではない」形になることです。多くの部署の要望を一つのフォーマットに詰め込もうとすると、結局どの部署の実情にも完全には合わない、中途半端な共通フォーマットが出来上がってしまいます。各部署は、そのフォーマットの外側で結局独自の工夫を続け、共通化した意味が薄れていきます。
たとえば、営業部は「顧客名」を最優先で見たいのに、開発部は「案件番号」を最優先で見たいとします。共通フォーマットが両方を無理に満たそうとすると、どちらの部署にとっても使いにくい、項目過多な様式になりがちです。共通化とは、全員の要望を足し算することではありません。本当に共通している部分だけを見極めて括り出す作業です。この見極めを誤ると、次のページで見る「早すぎる共通化」の罠に落ちます。
こうした落とし穴があるからといって、共通化そのものをやめるべきだ、という話ではありません。渋滞や調整コストは、共通化を運用しながら手当てできる問題です。窓口の受付時間を分散させる、優先順位のルールを決めるなど、運用でカバーできる余地は十分にあります。問題なのは、こうした負担が発生すること自体を知らずに集約してしまい、後から対応に追われることです。落とし穴を事前に知っておけば、備えて動けます。
さらに、共通部品を変更するときの調整コストも忘れてはいけません。一箇所を直せば全体に反映されるという利点は、裏を返せば、一箇所の変更が全部署に影響するということでもあります。自分の部署だけの都合で、共通の仕組みを勝手に変えることはできません。変更したいときは、影響を受ける全部署との調整が必要になります。この調整コストは、各部署がバラバラに運用していたときには存在しなかった、新しい種類の手間です。
窓口の混雑を防ぐには、依頼の受付タイミングを分散させる、優先度をつけて処理するといった、2章のスケジューリングで見た発想がそのまま応用できます。一箇所に集めたからこそ、順番の付け方を工夫する余地も一箇所に集約されている、と捉えられます。
最後に、共有ライブラリの性質から見えるもう一つの落とし穴があります。共通部品は、一つの目的のためだけに作られたものではありません。複数の異なる要望をまとめて受け止める前提で作られています。そのため、ある一つの部署が「自分たちの都合だけで急いで変えてほしい」と頼んでも、共通部品を管理する側はすぐには応じられません。他の利用部署への影響を確認する時間が必要だからです。これは共通部品を管理する側の怠慢ではなく、複数の依存先を持つ部品の宿命のようなものです。
共通化は、重複をなくす代わりに、「一箇所への依存」という新しい性質を組織に持ち込みます。分散していれば、ある部署のトラブルは他部署に及びませんでした。集約した後は、その一箇所が止まれば、全部署が影響を受けます。この依存が引き起こす、単一障害点という問題については、11章で改めて扱います。
次のページでは、この共通化そのものを、いつ・どのタイミングで行うべきかという、さらに手前の判断について見ていきます。
持ち帰り
- 共通部品を一箇所に置く考え方は、組織ではシェアードサービスセンターとして現れる
- 集約は重複をなくす一方、混雑や調整コストという新しい負担を生む
- 共通の仕組みは、誰にとっても完全には最適でない形になりやすい
やってみる
自分の部署以外でも同じように発生している作業を1つ思い浮かべ、「一箇所にまとめたら、誰が幸せになるか」を考えてみてください。同時に「集約したら、誰が困るか」も、あわせて考えてみましょう。