少数精鋭による中央突破とアーキテクチャへのストレステスト

仕事上の成果物を作成するとき、いくつか似たものを作る場合がある。
複数のミドルウェアの設計・構築であったり、いくつかのサブシステム・サーバの構築であったり。

数が多いからといっていきなり作業者を多く投入すれば良いほど、ITのプロジェクトは単純ではない。
そんなことをすればかえって現場が混乱する。
スケジュールが押しているからと方針も決めずに全員がパラレルに走り出したらどうなるか。
それぞれが各個撃破されてしまう。一人は立ちすくみ、一人は別の方向へ、一人は後一歩のところで力つきる。
だれかが「こっちが正解だぞー」と叫んでも大軍はそう簡単に方向を変えられない。それまでに作って"しまった"成果物？があるからだ。

いくつか似たものを作るとして、それにマンパワーをかけられるのは、方式が確立された後なのだ。
少数精鋭が道を切り開いたあとに一気に進むのであればよい。

いくつか似たものを作る、それにマンパワーをかけることで早く全体を完了させることができるということは、
それが「パターン」化されたからだ。そのパターンを「アーキテクチャ」と呼んでも良いのだ。
重要なのはその「パターン」(アーキテクチャ)が、その似たものたちを上手く扱える程度に最大公約数的で、多少の差を吸収する柔軟性を持つ事だ。
これだと決めた「パターン」で進めて、あとで「こいつには使えない！こんちくしょう！」となったら中央突破していても意味が無い。
(先行部隊が見つけた進軍ルートでは、ある部隊の装備が運べない(狭すぎて通れない)！というようなところだろうか。)

それ故にこれだという「パターン」(アーキテクチャ)にはしっかりストレステストをかけなければならない。
もっとも厄介そうなものを早期に「パターン」にはめるのだ。最初か2番目位には。一番強いヤツから倒す、一番難しい問題から解く、そんなアプローチだ。
一番難しい問題を避けて80点をとっても、その問題が解けないのであれば、結局100点にならず、0点扱いになるのだ。