なぜプロジェクトは火を噴くのか

　SEやプログラマーと言ったら残業、休出の多い職業の代名詞ではないでしょうか？　それは何故かといえば「プロジェクトが火を噴く」からです。つまり、実際の作業スピードと工期がかみ合わなくなるからです。

　しかし本当に「かみ合わなくなる」のでしょうか？

　この業界の人に飲み会でもさせて愚痴をはかせたらたぶん一番多く出てくるのは「仕様変更」ではないでしょうか？

　しかし、仕様変更は本当に悪なのでしょうか？　私は宴会上の空気の関係で仕様変更が悪であるかのように同調したことはありますが、本心では決してそうは思っていません。

　プロジェクトの始まりは見積りからだと思います。この時点ですでに問題はないでしょうか？　つまり、「まだよくわからないけどざっくり見積もって」と言われたとき、どう応じるかですでにそのプロジェクトの命運がわかれていると思います。そのとき、どんな作業に応じることができて、どんな作業に応じることができないのか、はっきりしているでしょうか？

　そしてスケジューリングですが、その根拠ははっきりしていますか？　単なるデータ入力などでしたら手戻りなんてほとんどないでしょうからウォータフォールでもいいでしょう。しかし、システム開発では手戻りはするものです。言い換えれば仕様変更はされて当たり前です。それに関するスケジューリングは行っていますか？　これは「予備日を入れる」ということではありません。スケジュールの中に仕様を変更してもらうタイミングを入れてしまうのです。つまりPDCAサイクルを意識するのです。

　私が常々提唱しているのは、「とにかく動くものを早く作ってしまう」ということです。これは最近のアジャイルだとかXPをキーワードにした開発手法をご存知の方には当たり前のことかもしれませんが、旧態然としたウォータフォール信者にはなかなか思い至らない発想のようです。そして仕様変更が大変なほどに作り込むまえから顧客に口出しをしてもらうということです。しかし、そのとき必ず「使う人」の意見も忘れないでください。特に工場関係などは、仕様を決める人と使う人が違ったりして、後々にもめる原因となります。このとき、ユースケース図なんかが威力を発揮すると思います。UML関係の本や記事ではとかくクラス図が取り上げられることが多いですが、ユースケース図に命を懸けるぐらいにすると、だいぶシステムがまとまる感じがします。

　とはいえ、特に大きなプロジェクトをやっているとなかなかそうは行かないものですね。複数社が絡んでいたり、元請け、下請けの関係だったりするとなかなか上手く行かないものです。それは私もどうしたら良いかわかりません。今、鋭意研究中です。