仕事に効くコンピュータサイエンス
同じ仕事を二度しない — DRYと共通化読了目安 10分

章のまとめ — 重複をなくす技術と、なくしすぎない技術

この章では、同じ仕事を二度しないための4つの道具を見てきました。最後に、全体を振り返り、次の章へのつながりを確認します。バラバラだった4つの話が、一本の線でつながって見えてくるはずです。

章の冒頭では、週次報告の数字のズレ、新人への説明のブレ、ひな形の乱立、問い合わせ回答の食い違いという、4つの職場のあるある場面から出発しました。どの場面も、原因をたどれば「同じ知識が複数箇所に存在していたこと」に行き着きました。この章の4つの道具は、いずれもその一点に対する答えです。場面としては別々に見えても、原因は一つに収束していた、という発見が、この章全体の出発点でした。

4つの道具を振り返る

最初に見たのはDRY原則でした。「同じ知識には、ただ一つの正しい置き場所を作る」という考え方です。週次報告の数字がAさん・Bさん・Cさんで食い違っていたのは、返品ルールという知識の置き場所が、一箇所に決まっていなかったからでした。統一するだけでなく、参照先を一箇所に決めて初めて、重複はなくなります。見た目が似ているだけのものまで一本化しないよう、「同じ知識か、似ているだけの別物か」を見極める視点も、あわせて確認しました。

次に見たのは関数化、つまり手順書化でした。知識やルールを一箇所にまとめただけでは、毎回それを読み返す手間が残ります。手順に名前をつけ、「何を渡せば、何が返るか」を明確にしておくことで、誰でも同じ結果にたどり着ける状態を作れます。新人に毎回口頭で説明していた先輩の問題は、この手順書化によって解消されます。一方で、手順書が特定の人やタイミングに依存した「隠れた前提」を持ってしまうと、名前を呼び出しても、いつも同じ結果にはたどり着けなくなることも見ました。

3つ目に見たのは、シェアードサービスセンターに代表される共通化でした。一人の手順書のレベルを超え、部署をまたいで同じ機能が必要とされている場合、一つの専門チームに集約することで、重複した人員配置を解消できます。経理業務やヘルプデスク、採用業務のように、多くの部署が同じように必要とする機能ほど、集約の効果は大きくなります。一方で、集約は混雑や調整コストという新しい負担も生むことを確認しました。一箇所に依存する形になった以上、その一箇所が止まったときの影響も、あらかじめ見積もっておく必要があります。

最後に見たのは、共通化のタイミングの問題でした。まだ事例が出そろっていない段階で急いで共通化すると、「間違った土台」を作ってしまい、重複を放置するよりも重い代償を払うことになります。同じパターンが3回目に現れるまで待つ、という目安を持っておくと、この失敗を避けやすくなります。待つことにはほとんどコストがかからず、間違えて動くことのコストの方がずっと大きい、という比較も確認しました。

4つはひとつながりの話だった

改めて並べてみると、この4つは段階を追った一つの話になっています。

まず、知識をどこに置くかを決める(DRY)。次に、その知識を呼び出せる形にする(関数化)。その呼び出しを、個人や部署を超えて広く使えるようにする(共通化・シェアードサービスセンター)。そして、この一連の作業を、いつ始めるべきかを見極める(タイミング)。

置き場所を決めないまま手順書だけ作っても、どの手順書が正しいか分からなくなります。手順書を作らないまま共通の窓口だけ作っても、窓口の中の担当者が、結局それぞれ独自のやり方で対応してしまいます。そして、正しい順番で進めていても、タイミングを間違えれば、せっかくの仕組みが仇になります。4つの道具は、順番も含めて意味を持つ一つのセットでした。

この順番を意識すると、「まず何から手をつければよいか」も自然に見えてきます。目の前に重複があるなら、最初に問うべきは「置き場所は決まっているか」です。置き場所が決まっているなら、次は「呼び出せる形になっているか」。それも済んでいるなら、「この呼び出しを、他の部署も必要としていないか」という順で考えを進めます。どの段階からでも始められますが、前の段階が済んでいないまま次に進むと、土台の緩い仕組みになりがちです。

完成させることと、完成させすぎないこと

この章を通して伝えたかったことは、「重複はすべて悪であり、すぐに一本化すべきだ」という単純な話ではありません。

重複には、放置すれば必ず害になるものと、まだ判断材料が足りず、あえて残しておいた方がよいものの、両方があります。この章の道具は、どちらの重複にも同じように「早く消せ」と迫るものではなく、「今、消すべき重複はどれか」を見極めるための物差しです。

たとえば、返品ルールのように、組織のどこでも同じであるべきだと最初から分かっている知識は、早い段階でDRYを適用してよい対象です。一方、進捗報告のフォーマットのように、プロジェクトごとの違いがまだ見えていない段階のものは、急いで一本化せず、事例が増えるのを待つ対象です。同じ「重複」という見た目でも、中身によって扱い方が違うことを、この章を通して確認してきました。この判断は、慣れないうちは難しく感じるかもしれません。けれど「これは組織のどこでも同じであるべきか」と自分に問いかける習慣さえ持てれば、判断の精度は自然に上がっていきます。

物差しを持たずに重複を見ると、目についた重複を片っ端から一本化したくなります。けれどその衝動のまま動くと、5ページ目で見たような、間違った共通化を量産することになります。この章の4つの道具は、消すべき重複を消し、育てるべき重複は育てておくための、判断のための道具だったと捉え直してみてください。

「重複をなくす」というと、一度で終わる作業のように聞こえるかもしれません。実際には、置き場所を決め、呼び出せる形にし、必要なら広く共有し、そのつどタイミングを見極めるという、続けて回していく判断の連続です。一度きれいにしたら終わり、というものではなく、仕事の中身が変わるたびに、この4つの視点で見直す習慣が求められます。

この章の冒頭で、私たちは「チームのアーキテクチャ」という言葉を紹介しました。建物の骨組みと同じように、一度組み上げた構造も、住む人や使い方が変われば手直しが必要になります。重複をなくす技術は、この骨組みを整える最初の一手にすぎません。次の章以降でも、骨組みを健全に保つための道具が続きます。会議やインターフェースの設計、属人化への対策、データの持ち方など、III部ではこの先も「チームの構造」を扱うテーマが続いていきます。この章で得た視点は、それらすべての土台になります。

次章への橋 — 一箇所にまとめた後に残るもの

この章では、重複をなくし、知識や作業を一箇所にまとめる方法を見てきました。しかし、一箇所にまとめたからといって、それで仕事の設計がすべて片付くわけではありません。

一箇所にまとめた手順書や仕組みは、時間が経つにつれて、実態と合わなくなっていくことがあります。使われなくなった手順書がそのまま放置されていたり、一本化したはずのルールに、後から例外がいくつも継ぎ足されていたりします。組織や事業が変化し続ける以上、今日きれいに整えた仕組みも、いずれ現実とずれ始めます。これは失敗ではなく、時間が経てば必ず起きる自然な現象です。

問題は、そのズレに気づかないまま、古い手順書を使い続けたり、継ぎ足された例外だらけのルールを、そのまま次の担当者に引き継いだりすることです。1ページ目で見た「重複は発見が遅れる」性質と同じく、古くなった仕組みも、気づかれるまでに時間がかかります。

次の章では、こうした「もう使われていないもの」や「継ぎ足しで複雑になったもの」をどう扱うかを見ていきます。プログラムの世界で言うデッドコードの削除や、リファクタリングと呼ばれる整理の技術を、業務の棚卸しという言葉に翻訳していきます。

デッドコードとは、もう呼び出されることのない、使われなくなった処理のことです。仕事で言えば、誰も見ていない報告書や、形骸化した承認ステップにあたります。リファクタリングは、動きを変えずに中身を整理し直す作業です。仕事で言えば、業務の目的は変えずに、手順の無駄を削ぎ落とす作業にあたります。

この章で扱った重複が「同じものが増えすぎる」問題だったのに対し、次の章で扱う技術的負債は、「一度作った仕組みが、時間とともに実態から離れていく」問題です。どちらも、最初は小さな綻びから始まります。綻びを放っておくと、後から気づいたときには、直すのに大きな手間がかかる状態に育っています。

この章で重複をなくす技術を身につけたなら、次はその結果を長持ちさせる技術に進む番です。まとめることと、まとめた後の状態を保つことは、別の技術です。次の章で、その続きを見ていきましょう。一度作った仕組みを、作りっぱなしにしないための視点が、そこで待っています。

読む前と読んだ後で変わること

章の冒頭に戻ってみましょう。Aさん、Bさん、Cさんが、それぞれ違う返品ルールで週次報告を作っていました。この章を読む前なら、「もっと注意深く確認しよう」という反省で終わっていたかもしれません。

読んだ後なら、見方が変わります。まず、返品ルールという知識の置き場所が一箇所に決まっているかを確認します(DRY)。決まっていなければ、置き場所を作り、参照する形に変えます。次に、その置き場所を使った集計手順に名前をつけ、誰が担当しても同じ結果になるようにします(関数化)。もしこの集計作業を他の部署も同じように行っているなら、一つのチームに集約することを検討します(共通化)。ただし、まだ他の部署の事情がよく分かっていない段階なら、無理に共通化を急がず、事例が出そろうのを待ちます(タイミング)。

同じ一つの問題に対して、反省ではなく、具体的な4つの手当てが見えるようになる。これが、この章を通して身についた見方です。

持ち帰り

  • DRY・関数化・共通化・タイミングの4つは、段階を追った一連の道具である
  • 重複には、すぐ消すべきものと、事例が出そろうまで残すべきものの両方がある
  • 一箇所にまとめた後も、実態とのズレを保つ手入れが必要になる

やってみる

この章で紹介した4つの道具のうち、自分の仕事に一番当てはまりそうなものを1つ選び、同僚に話してみてください。話した相手からも、同じように心当たりのある場面が出てくるか聞いてみましょう。