「遅れ」にこだわってどうする！？
先のことは誰もわからない。であれば，難しいことから片付けていくしかない。
いまやっている仕事は，非常に複雑かつ企業の生命線となる機能と，管理に必要な単純な機能がはっきりと分けられるシステムの構築である。当然前者の方がリスク的に高いものなので，顧客を安心させるために優先的に着手している。その中でも，ある程度の機能分割(全部で約200機能くらいと予想)を行い，優先順位をつけて実装順序をコントロールしている。そして，機能単位でリリースし，それに対して試験を行っていく，かなりアジャイルな展開で開発をしている。実装開始からたった1週間で，(紙芝居ではなく)ちゃんと動いて見ることができる機能を手にできていることは，驚きに値するし，評価されるべき事実だ。
しかし，もちろん機能を作りきっているわけではない。未実装，バグ，その他の実装の問題は当然のように発生している。ある時間単位で実装完を目標とする機能をスケジューリングしているので，未実装があるということは，スケジュールの遅れを意味する。一般的には，スケジュールの遅れを取り戻すために，人員の増強を行おうとする。そして，開発作業の並行度を高め，当初の期限を守ろうとする。
では，「遅れ」について，それを取り戻すことにこだわるべきなのだろうか？
実装作業において最も重要なこと，それは「適切な船頭がいること」である。そして，その船頭には「負荷がかかっていない」ことが最低条件となる。適切な船頭は，仕様の理解度，実装に対する考え方，試験の方法などを理解し，それを実施できる人である。さらに，船頭は実装者に対する教育も行い，実装作業を正しい方向に導く大事な役目も担う。そんな船頭から知識を得て，実装者は船頭に近づいていく(船頭にはなれないだろうけど)。
今のやり方は，リスクが高いものから順に実装を進めていっている。つまり，その辺の開発者を連れてきたって，全く戦力にならないどころか，船頭がその新人を戦力にするために努力する必要があり，リスクが高いが故に注力しなければならない管理業務が，結果として疎かになる。これは過去の経験上はっきりと言える。船頭が船頭じゃなくなれば，船はまっすぐ進めない。リスクを管理することすらできないため，リスクの高い機能から手をつけている意味がなくなる。
目の前の「リスクが低い」と判断して実装を後回しにした「遅れ」については，基本的には後で何とでもなる。複雑度は低いはずなので，それほど教育を行わなくても，的確な指示を与えられれば対応は可能なはずだ。顧客だって，「その修正はいつでもいいや」的な発想をしてくれるはずである(ちゃんと説明は必要だけど)。しかし，「リスクが低い」と判断して実装を後回しにした「遅れ」に「こだわり」を持ってしまえば，それに対してかける労力の代わりに，リスクが高い機能に対する密度の薄まりは想像を絶するものになる。仕様を理解している人であればあるほど，その想像はしやすいはずだ。
リスクが高いからこそ，その機能の実装に集中すべきであり，逆の言い方をすると，実装に集中できる開発者の人数に止めて，管理面でのコストを抑える必要がある。それなのに，「遅れ」を取り戻すために管理コストを増大させて，全体の進捗を停滞させていいものだろうか？それが最善の手といえるのだろうか？難しいことに対して集中したいという至極当たり前のことをしたいだけなのに，なぜそれを拒もうとするのだろうか？
顧客は安心したがっている。「複雑な機能は実装できたから，もう安心だね，人をかけて残りの機能をやっつけよう」という気持ちを持てるような開発の進め方をしたい。そのためには，目の前の「遅れ」や簡単な機能の前倒し実装には，こだわってはいけないのだ。
顧客は，リスクの高低を自然と理解できるために，上記の考え方に対して割と柔軟な姿勢をとってくれる。これは，システム開発という「失敗して当然」な難しい作業を知っていればいるほど，過去に痛い目に合っていればいるほど，開発ベンダーにある程度協力的だ。不思議なことに，「遅れ」を取り戻すことにこだわりを持つのは「開発ベンダー」側の人間だったりする。しかも，立場の偉い人であればあるほど，現場にいない人であればあるほど，その傾向は強いように感じられる。複雑さを取り除くというEoDの大前提を考えれば，人員投入＆並行開発という手段は，リスクが高い状態では機能しないと思えてならないのだ。
