プロジェクトは後ろから考える

システム開発プロジェクトにおいて、多くのケースで発生する間違い。

「計画を積み上げで作る」

ということ

そもそもシステムは「できたら新しいシステムのほうがいいよね」なんて軽いレベルの意思決定で作られるものではなく、多くの会社では会社の屋台骨としての必要性で新規、もしくはリニューアルするもの。つまり、屋台骨として必要！と経営としての判断がされているものがほとんどだと思うので、経営側のニーズがある。

経営も、「いつでもいいからできたら早めにほしいな」なんて曖昧な養成をするわけなく、マーケットや株主の意向を踏まえて投入するタイミングを意思決定している。

この意思決定したスケジュールが「天から降ってきた」ことでプロジェクトはスタートする

このプロジェクトスケジュールは、重要度の高い制約条件であり、これの是非を考えるのは最後の最後。プロジェクトの計画を作る人間は、この制約条件を前提にプロジェクトを設定する。

少し考えてみてほしい。

自分が結婚式をあげる、と思ったときに、ひな壇の上に飾る花の種類や値段を最初に決めるだろうか。

多くの人は違うと思う。

まずおぼろげながら式場を選び（成果物の定義）、式場と相談し招待客の都合等考えてスケジュールを決め（スケジュール計画の策定）、身の丈を考えプランを考え（予算の策定）というところまでやってから、詳細な内容（上記の花の選定等）を行うはずである。

予算もスケジュールも成果物もすべて制約事項であり、それらのバランスをとって決めていく必要があるが、このなかで一番譲れないのが「スケジュール」ではないだろうか。なぜなら、一度決めてしまったら変更がしにくいもの、だからだ。結婚式は自分たちだけであげるものではなく多くの参加者に祝福してもらって成立するものだから。

システムも多くの人が利用するものである。だから、スケジュールをまずはきちんと決めることが大切なのだ。

その上で、そのスケジュールと予算の中で最大限にできることはなにか、ということを考えていくことがプロジェクト責任者が行わなければならないことである。

そこそこの開発規模のプロジェクトにおいて、プロジェクト責任者は、現場サイドのメンバーから「こんな期間じゃできません。無理な案件受けてこないでください！」と言われることを経験していることだとおもう。

そのときに上記の「制約の順序」の話。そしてその制約のなかで「やり方」を考えることプロジェクト責任者・メンバーやその会社の力量が問われるということを話し合ってほしい。