自分でやろう - PART1 |
||
|
必要以上の困難さ |
||
|
明日起こる事態を予測するのは簡単ではないから、昨日行った決定を今日覆さなければならない状況は常に起こります。実際、開発者のみなさんなら開発方針を変更しなければならない場面に何度も遭遇しているでしょう。 |
||
|
設計部門とコーディング部門が別になっている組織があります。とくに大きな組織ではそうなっているケースが多いようです。そういう環境では、ちょっとした方針の変更にも手間取ることになってしまいます。設計部門で発生した変更はコーディングに適用されなければならないし、コーディング上の問題から発生した変更は設計にフィードバックされなければなりません。しかしこのような部門にまたがる変更は「ビッグイベント」です。 |
||
|
もしかしたら部門間ミーティングで無駄な時間を過ごしたあげく、結局はお互いに妥協をしなければならないかもしれません。だとすると、本当は必要な変更だったとしても、無理矢理にでも部門内部で片づけてしまった方が面倒が少ないと思えてきます。そういうことを本当にやってしまうと、あとで必ずしわ寄せがきます。 |
||
上下関係? |
||
|
変更を困難にしている問題がもう一つあります。とてもメンタルな問題です。それは、「設計はコーディングよりも高級な技能だ」という一般認識に起因します。さて、実際にはどうでしょうか。 |
||
|
|
|
|
(「コーディングの向こう側」は2000年4月から2001年5月にかけて作成されたコンテンツです。)