スケープゴート
組織パターンという本に「誰か一人を犠牲にする」パターンが紹介されている。
どんなに細かくても余計な作業には対処しなければならない。しかし、第一優先のタスクをやるべき時間がとられてしまうことも忘れてはならない。[...]
細かい余分な作業が大量にあると、やりたい仕事ができなくなるのだ。
それゆえ：
誰か一人余計な作業に割り当てて、その作業を終わらせてもらおう。
犠牲とか一人とか言い回しは、おそらく意図的だろう。犠牲になった人の作業が終わったら、元の仕事に戻してあげようとか書いてある。
ここでは、機械的に話を進める。もうすこし抽象化して捉えて、メインのプロジェクトから、派生したプロジェクトを分離し、一時的にリソースを配分する、という風に考える。ひとつのリソースを複数のプロジェクトに割り当てると、たしかに効率が悪いことがある。
余計な仕事が発生
本を閉じると、そこには現実が待っている。ちょうど数ヶ月スパンでプロダクトを開発しているところだ。プロダクトは機能の多さよりも、キャパシティのほうが重要である、という種類ものだ。運用が始まったとき、機能には妥協ができるが、トラフィックに対するキャパシティは妥協やコントロールがしにくいからだ。
現時点で手元には、
- そこそこのキャパシティで稼働する、機能 A
- 開発中の機能 B
がある。機能AやBというのは、実際には複数の機能群だ。フルキャパシティで動く部分もあれば、要件半分くらいでしか動かないだろうという部分もある。だが話を単純化しておこう。
このプロダクトのデモを見たい、という仕事が入ってきた。デモという言葉は曖昧なので、よく聞いてみると「プロダクトの機能 A, B, Cを利用したアプリケーション開発と運用を、実験として行う。運用フェーズを想定して、複数のサードパーティが、アプリケーションを開発する」というものだ。
突っ込みたいところや、だるいところがあり、その過程で感情的になり、箸が転がってもブチ切れるという精神状態になったりもしているが、ここでは機械的には話を進めよう。
不足しているものを列挙すると、以下の3つだ
- 機能 B（作りかけ）
- 機能 C（次のフェーズで開発する）
- サードパーティへのサポート（文書、トラブルシュート）
- アプリケーションの参照実装
である。問題は機能BとCである。機能Bはキャパを考慮して実装中なので、キャパの低い実装に切り替えると、トータルの手戻りが大きい。C は次のフェーズで開発する機能だ。
- アプリ
- プロダクト機能 A + 機能 B と C を追加
えらく変更/追加が多いではないか。急に入ってきた仕事は「プロダクトができること」を見せるものだ。本番運用があるわけでもない。やっつけ仕事だ。けれど、プラットフォームを使う必要がある。
汚れ仕事
とうわけで、汚れ仕事を分離することにした。プロダクトは予定通り開発をすすめる。この仕事用に、別の使い捨てのコンポーネントを用意する。
- アプリ
- やっつけラッパー (B + C)
- プロダクト (A)
アプリから見ると、A, B, C を提供するプラットフォームが存在する。A を提供するプラットフォームは、きちんと存在していて、ラッパーがプロキシする。
機能B と C はやっつけラッパーの中で、やっつけ実装する。
こうやってプラットフォームの開発を、（ほとんど）遅らせることなく、途中で入ってきた依存関係のあるプロジェクトを進めている。あと2週間くらいは、アルコールの摂取量が、高めになるだろうけど、酒を飲む程度の余裕があるということだ。
