火曜の朝、あなたは週次報告のために数字を集計しています。先月も同じような表を、別の目的でゼロから作った覚えがあります。「これ、前も作らなかったっけ」という違和感。それが今日の入り口です。
このページの問いはこうです。なぜ同じ作業が組織のあちこちで、何度も生まれ直すのでしょうか。どうすれば、一度で済むようにできるのでしょうか。
一人の工夫から、チームの設計へ
ここまでの章では、自分一人の働き方や、一つの仕事をどう進めるかという工夫を見てきました。ここからは視点を変えます。複数の人が関わる仕事を、どう組み立てるかという話です。
ソフトウェアの世界では、部品をどう配置し、どう繋げるかという全体設計をアーキテクチャと呼びます。1枚の図面ではなく、建物全体の骨組みのようなものです。この章からの3部では、チームというアーキテクチャを、CSの目で見ていきます。
その最初のテーマが、重複です。建物で言えば、同じ配管をあちこちに二重に通してしまうようなものです。一箇所直せば済むはずの部分を、複数箇所に分けて作ってしまう。これがチームのアーキテクチャで最初につまずきやすい点です。
同じ集計が3つの机で生まれる
週次会議のための売上集計を、営業チームのAさんが自分のExcelで作っています。隣の机では、Bさんが同じ売上データを別のフォーマットで集計しています。経理のCさんも、月次締めのために同じ元データから独自の表を作っています。
3人とも、見ているデータの出どころは同じです。計算のルールも、聞けばほぼ同じだと答えるでしょう。けれど月末に3つの数字を並べると、微妙に食い違っています。
原因を辿ると、返品の扱いが3人でバラバラでした。Aさんは返品分を売上から差し引き、Bさんは差し引かずに集計し、Cさんはさらに別の枠で扱っていました。
誰も間違ったことをしたつもりはありません。それぞれの表の中では、計算は正しく完結しています。ただ「返品をどう扱うか」というルールが、組織のどこにも一箇所にまとまって書かれていなかっただけです。
会議の場で3つの数字が食い違うと、議論は本題に入る前に「どれが正しいか」の確認で終わります。これが毎週続くと、報告そのものへの信頼が少しずつ削れていきます。
さらに厄介なのは、誰も嘘をついていないという点です。Aさんの表もBさんの表も、それぞれの中では計算が合っています。「正しいけれど、互いに矛盾する」資料が3つ存在する状態は、「誰かが間違えた」状態よりも実は解決しづらいものです。犯人探しをしても、誰も見つからないからです。
新人への説明を、毎回ゼロから話す先輩
別の場面も見てみましょう。新人が入るたびに、先輩が経費精算のやり方を口頭で説明しています。先月教えた内容と、今月教えた内容は、実は微妙に違います。先輩自身、前回具体的に何を話したか、正確には覚えていないからです。
半年後、新人同士が雑談で手順をすり合わせると、「言われたルールが違う」という小さな混乱が起きます。どちらかが聞き間違えたわけではありません。教える側の説明が、話すたびに少しずつ形を変えていたのです。
原因は先ほどの集計の例と同じです。手順が先輩の頭の中にしか存在せず、書き出されていません。書き出されていない知識は、伝えるたびに輪郭がぼやけます。
もし先輩が異動したり、休職したりしたらどうなるでしょうか。経費精算の正しい手順を知っている人が、組織から消えてしまいます。知識が一人の頭の中だけに存在するというのは、その人がいなくなった瞬間に、知識ごと失われるということです。この問題は11章で改めて「属人化」として詳しく扱います。
テンプレートは増えるのに、正しい版が分からなくなる
もう一つ、よくある場面を挙げます。提案書のひな形を、ある部署が独自に整えました。別の部署がそれを見て「便利そうだ」とコピーし、少し手直しして使い始めます。さらに別のチームが、そのコピーをまたコピーして使います。
半年後には、社内に似たようなひな形が5つも6つも存在します。どれが最新で、どれが正しい書式なのか、もう誰にも分かりません。元のひな形を作った部署がフォーマットを更新しても、コピーされた側には変更が届きません。
会社のロゴが変わった、法律用語の言い回しが変わった。そうした変更が必要になったとき、正しい修正先が一箇所に決まっていれば、そこだけ直せば済みます。ところが版が5つも6つもあると、5つも6つも直さなければなりません。しかも「あと何個コピーが存在するか」は、誰にも把握できていません。
同じ問い合わせに、違う答えが返ってくる
もう一つだけ、場面を重ねます。問い合わせ対応の窓口で、同じ質問に対して担当者ごとに違う回答をしています。返品期限は何日か、送料はいくらか。ルールはどこかに存在するはずですが、担当者の記憶や過去のメールを頼りに、その場で答えています。
ある日、同じ顧客が二度目の問い合わせをして、前回と違う回答を受け取ってしまいます。顧客からすれば、会社としての一貫性がないように見えます。実際には、ルールを一箇所にまとめる仕組みがなかっただけです。
このように、重複の被害は社内にとどまりません。社外に出ていく回答や資料に食い違いが生じれば、それは信頼の問題として顧客の側に届いてしまいます。
なぜ同じ作業が際限なく再発明されるのか
ここまでの3つの場面には、共通点があります。「同じ知識」や「同じ手順」が、複数の場所にバラバラに存在しているのです。一箇所を直しても、他の場所は自動的には直りません。だから時間が経つほど、あちこちの版が少しずつズレていきます。
ソフトウェアの世界では、これは古くから知られてきた問題です。同じ処理の手順を、コードの複数箇所にコピーして書いてしまうと、仕様変更のたびに、コピーした箇所すべてを直す必要が出てきます。直し忘れた1箇所が、後日の不具合になって表れます。
この経験から生まれた設計の知恵が、この章の主役です。コンピュータサイエンスでは、知識やロジックは「一箇所にまとめて置き、必要な場所からはそこを参照する」という考え方を徹底します。これが、この章で扱う一連の道具立ての土台です。
大切なのは、これが「几帳面さ」や「丁寧さ」の話ではないという点です。先ほどの3人はいずれも、仕事に手を抜いていません。むしろ真面目に、それぞれの持ち場で正確な表を作っています。問題は個人の姿勢ではなく、知識の置き方という設計にあります。設計の問題は、気合いや注意力では解決できません。置き場所そのものを変える必要があります。
この章の地図
この章では、4つの道具を仕事の言葉に翻訳していきます。
まず次のページで、同じ知識を二度書かないという原則そのものを見ます。プログラムの世界でDRY原則と呼ばれる考え方です。「同じ内容は一箇所だけに置き、他はそこを参照する」という、シンプルだけれど、実際には徹底しにくい原則です。返品ルールも経費規定も、この原則を当てはめれば置き場所が定まります。
その次は、手順を「名前」でまとめて呼び出せるようにする考え方です。プログラムでいう関数化にあたるもので、仕事の場面では手順書やチェックリストという形を取ります。「あの手順、名前で呼べば誰でも同じ結果にたどり着ける」状態を作ります。先輩の頭の中の説明を、誰でも読める形に取り出す作業です。
さらに、個人や部署をまたいで共通の作業をまとめて引き受ける場所、いわゆるシェアードサービスセンターの発想を扱います。共通部品を一箇所に置くという考え方の、組織版です。経理・総務・情報システムなど、多くの部署が似た依頼を出す業務を、一つのチームがまとめて引き受ける仕組みを見ていきます。
最後に、この章でいちばん見落とされがちな注意点を扱います。共通化は早すぎても失敗するという事実です。まだ実態がよく見えていない段階で無理に一本化すると、バラバラにやっていたときより悪い結果を招くことがあります。「まとめれば楽になる」という直感は、半分だけ正しいのです。
重複をなくすことは、単に「手間を省く」以上の意味を持ちます。知識の置き場所を一つに決めることは、チームの誰もが同じ前提で仕事を進められる状態を作ることです。逆に言えば、重複が放置された組織は、気づかないうちに複数の「別の会社」が同居しているような状態になっています。
同じ社名の名刺を持っていても、返品の扱い方も、経費精算の手順も、提案書の書式も、チームごとにばらばらの「方言」で運用されている。これが重複の行き着く先です。外から見れば一つの会社でも、中身は小さな部族の集まりになっています。
この状態は、人が増えるほど悪化します。2人だけなら、口頭ですり合わせて済ませられます。しかし10人、30人と増えていくと、全員が全員と口頭ですり合わせることは物理的にできなくなります。だからこそ、知識を一箇所に置くという設計が、組織の規模が大きくなるほど効いてきます。気持ちの持ちようの話ではなく、人数が増えたときに必要になる仕組みの話です。
数字の食い違い、説明のブレ、ひな形の乱立。どれも根は同じです。次のページから、それぞれの対処法を具体的に見ていきます。まずは最も基本になる原則、DRYから始めましょう。
重複は「見つけにくい」からこそ厄介
最後にもう一点、重要な性質を確認しておきます。重複は、ほとんどの場合すぐには気づかれません。Aさん、Bさん、Cさんの表がズレていることは、誰かが3つを並べて突き合わせるまで表面化しませんでした。
普段の仕事は、それぞれの持ち場の中で完結しています。自分の表だけを見ている限り、何の問題もありません。問題が表に出るのは、複数の版が同じ場に並んだときだけです。つまり重複は、発見されるタイミングが遅れる性質を持っています。
だからこそ、気づいてから直すのではなく、最初から「知識は一箇所」という前提で仕事の置き場所を設計しておく方が、結果的に手戻りが少なくて済みます。次のページから見ていくDRY原則は、この前提を作るための最初の一歩です。
持ち帰り
- 同じ知識や手順が複数の場所に存在すると、時間とともに必ずズレていく
- 「前も作った気がする」という違和感は、重複を疑うべきサインである
- この章はDRY・関数化・共通化・抽象化のタイミングという4つの道具を扱う
やってみる
今日、自分が最近作った資料を一つ選んでください。「同じ情報が、他の誰かの資料にも存在していないか」を1分だけ確認してみましょう。