ここまで3ページにわたって、重複をなくす方法を見てきました。DRY、関数化、シェアードサービスセンター。どれも「まとめれば良くなる」という話でした。では、まとめることに、タイミングの良し悪しはあるのでしょうか。
結論から言うと、あります。ここまでの3つの道具は、正しく使えば強力です。けれど、正しいタイミングを外すと、重複を放置するよりも悪い結果を招くことがあります。この章の最後に、その見極め方を扱います。まとめる「べきか」ではなく、まとめる「いつか」を問うページです。
早すぎる一般化という失敗
プログラムの世界には、早すぎる抽象化、あるいは投機的な汎用化と呼ばれる失敗のパターンがあります。まだ実際の使われ方が2つか3つしか出てきていない段階で、「将来どんな要望が来ても対応できるように」と、あらかじめ何にでも対応できる汎用的な仕組みを作り込んでしまうことです。
一見、先回りした良い設計に見えます。しかし実際に新しい要望が来たとき、事前に想像していた形と微妙に違うことがほとんどです。汎用的に作ったつもりの仕組みは、その「微妙に違う」要望にちょうど対応できず、結局、仕組みの外側で個別対応するか、仕組みそのものを作り直すはめになります。
想像で汎用性を作り込むことの限界は、想像している人が、まだ見ぬ将来の要望を正確に予測できない点にあります。2つか3つの事例しか見ていない段階では、「何が本当に共通していて、何がたまたま似ているだけか」を、確信を持って判断する材料がまだそろっていません。材料が足りないまま作った土台は、どれだけ丁寧に作っても、実物と噛み合わない可能性を抱えています。
ここから導かれる経験則があります。「間違った抽象化は、重複よりも高くつく」という考え方です。同じような処理が3箇所にコピーされているだけなら、必要になった時点で1つずつ直せば済みます。しかし、間違った形で一本化されてしまった仕組みは、それを使っているすべての箇所を巻き込んで壊さないと、やり直しがききません。重複は「後で片付けられる借金」ですが、間違った共通化は「土台からやり直す借金」になりやすいのです。
なぜこれほど差が出るのでしょうか。重複しているだけの状態は、それぞれが独立しています。1箇所を直しても、他の箇所には影響しません。一方、共通化された仕組みは、複数の利用箇所が同じ土台の上に乗っています。土台の設計そのものが間違っていた場合、上に乗っているものすべてを一度どかしてから、土台を組み直す必要が出てきます。独立している方が、実は直すときの身軽さでは勝るのです。これは、この章のここまでの主張と矛盾するように聞こえるかもしれません。けれど正確には、「重複が悪いのではなく、間違った共通化がより悪い」という優先順位の話です。重複をなくすこと自体は、引き続き目指すべき方向のままです。
仕事の言葉に翻訳する
仕事に置き換えると、これは「見えていない段階で、無理に一つのルールに束ねてしまう」失敗にあたります。
たとえば、まだ案件が2件しかない段階で、「今後増える案件すべてに対応できる、万能な進捗管理シートを作ろう」と意気込んで作り込んだとします。3件目、4件目の案件が実際に来てみると、最初の2件とは性質が違う項目が必要になります。万能を目指して作ったシートは、その違いにうまく対応できず、結局作り直しになります。
これは、前のページで見た「共通の仕組みが誰にも最適でない」問題の、根っこにある原因でもあります。まだ十分な事例を見ていない段階で共通化を急ぐと、何を共通にすべきかの見極めそのものを誤ってしまうのです。
「早く手を打った方が偉い」という空気は、多くの職場にあります。先回りして仕組みを整えることは、一見、評価されやすい行動です。けれど、材料がそろう前に組み立てた仕組みは、後から材料が増えるたびに、組み替えの手間を生み続けます。早さそのものに価値があるのではなく、正しいタイミングで手を打つことに価値があります。
「まだ2件しかないのに、共通化を待つなんて非効率ではないか」と感じる人もいるかもしれません。しかし、待つこと自体にコストはほとんどかかりません。2件のまま、それぞれ個別に対応しておけばよいだけです。コストが発生するのは、間違った共通化を作ってしまった後、それを解体して作り直すときです。待つことと、間違えて動くことの、どちらのコストが大きいかを比べれば、多くの場合、待つ方が安全な選択になります。
具体的な場面で見る
進捗報告フォーマットの早すぎる統一。 1つのプロジェクトの報告フォーマットを、「他のプロジェクトでも使えるように」と汎用化して作ったとします。実際に別のプロジェクトで使ってみると、必要な項目が微妙に違い、結局そのプロジェクト用に別枠を作る羽目になります。最初から個別に作っていた場合より、汎用化の分だけ複雑になった上に、結局作り直しています。汎用化のために増やした項目欄の多くは、どのプロジェクトにとっても空欄のまま残ることになります。
新人研修プログラムの早すぎる一本化。営業職向けの研修をベースに、「どの職種にも使える研修プログラム」を最初から目指して設計したとします。実際にエンジニア職の新人に使ってみると、営業向けの内容がそのまま流用できず、大部分を作り直すことになります。最初から営業向けとエンジニア向けを別々に作っていれば、それぞれはシンプルなまま済んだはずです。「共通の研修があった方が公平だ」という思い込みが、かえって双方に中途半端な内容を押しつける結果を招いています。
承認フローの早すぎる共通化。少額の備品購入と、大型設備の投資という、性質の異なる2つの申請を、最初から1つの承認フローにまとめたとします。少額の備品には過剰に重い手続きが課され、大型投資には逆に足りないチェック項目が出てきます。どちらの申請にとっても、使い勝手の悪いフローになってしまいます。これは4ページ目で見た「誰にも最適でない共通フォーマット」の、発生する前段階そのものです。
3つの場面に共通するのは、「実際の事例が出そろう前に、共通の型を決めてしまった」という点です。型を先に決めると、後から出てくる事例の方を型に無理やり合わせることになります。本来、型は事例から浮かび上がらせるものであって、先に用意して事例をはめ込む枠ではありません。
落とし穴の裏返し — いつ共通化すればよいか
ここまで早すぎる共通化の失敗を見てきましたが、逆に「共通化はいつすればよいか」という基準も必要です。
一つの目安は、同じパターンが3回目に現れたときに共通化を検討する、という考え方です。1回目は、それが繰り返されるパターンかどうかまだ分かりません。2回目で「もしかしたら」と気づきます。3回目まで見て初めて、本当に共通する部分がどこで、部署や案件ごとに違う部分がどこかが、具体的に見えてきます。
この目安を実践するコツは、「似たような作業をした」という気づきを、その場でメモしておくことです。記憶だけに頼っていると、2回目・3回目が来たときに「そういえば前にもあった」と、気づくタイミングそのものが遅れてしまいます。簡単な記録を残しておくだけで、共通化を検討すべきタイミングを逃さずに済みます。
2回目までの重複を、焦って一本化する必要はありません。2箇所のコピーのまま、必要なときにそれぞれ直しておく方が、無理な共通化で全体を壊すよりも、結果的に安全です。重複は不格好に見えますが、間違った共通化ほどの被害は生みません。
この基準は、1ページ目で見た「重複は放置してよい」という話とは違います。放置すれば、いずれ数字がズレ、説明がブレていきます。ここで言っているのは、「重複に気づいた瞬間に、慌てて一本化に走らなくてよい」ということです。重複を認識した上で、事例が出そろうまで意識的に待つのと、重複に気づかずに放置するのとは、まったく違う状態です。前者は準備された待機であり、後者はただの見落としです。
見分け方は簡単です。「この重複を自分は把握しているか」「必要になれば直せる状態か」という2点に答えられれば、意識的な待機です。どちらにも答えられないなら、それはただの見落としであり、1ページ目で見たような、静かなズレの温床になります。
もう一つの目安は、「共通化を後からでも変更できる余地を残す」ことです。最初から完璧な共通の型を作ろうとせず、まず一番シンプルな共通部分だけを括り出し、残りは個別対応のままにしておきます。事例が増えるたびに、共通部分を少しずつ見直していけば、最初から万能を目指すより、実態に合った形に育てていけます。
たとえば承認フローの例で言えば、最初から「全申請共通の1本のフロー」を目指すのではなく、まず「申請者と承認者を記録する」という、どんな申請にも確実に共通する最小限の部分だけをまとめておきます。金額に応じた承認段階の違いなど、まだ事例が少ない部分は、あえて個別対応のまま残しておくのです。共通化する範囲を小さく始めることで、後から広げるか、そのままにするかの選択肢を残せます。
DRY・関数化・シェアードサービスセンターは、どれも強力な考え方です。しかし、いつ・何を対象に行うかを間違えると、重複よりも重い代償を払うことになります。「見えてから束ねる」という順番を、この章の締めくくりとして覚えておいてください。
もう一つ、覚えておきたい心構えがあります。一度作った共通の仕組みを見直すことは、「最初の設計が失敗だった」ことを意味しません。事例が増えれば、以前は見えなかった共通点や相違点が見えてきます。見えたものに合わせて仕組みを調整するのは、むしろ健全な運用です。一度決めた共通化を、変更してはいけない聖域のように扱ってしまうことこそ、この章で見てきた問題を悪化させる態度です。仕組みは、事例とともに育てていくものだと捉えておきましょう。
持ち帰り
- 早すぎる共通化は、重複よりも高くつく「間違った土台」を作ってしまう
- 事例が3回目に現れたタイミングで共通化を検討するのが一つの目安になる
- 完璧な共通の型を最初から目指さず、後から見直せる余地を残しておく
やってみる
最近「共通化しよう」と思いついたルールや仕組みを1つ思い出し、それが本当に2回以上、実際に繰り返された事例に基づいているか確認してください。事例が1回だけなら、共通化はいったん保留にしてみましょう。