昨日の記事に書いたように、自分の仕事はソフトウェア開発のプロジェクト管理なのですが、ベータ版などの出荷間際の最終段階に入ると、必ず悩むことがあります。
それは、Bugをどこまで直すか、の決断です。
そもそもソフトウェアというものは、Bugが本当になくなることは絶対にあり得ません。
中には「そんな問題はBugではない、暗黙の仕様だ！」と言いたくなるようなBugも登録されるわけですが、とにかく規模が大きくなればなるほど、Bugを完全に消し去ることは難しくなります。
したがって、出荷時期が近づいてBugを直す余裕がなくなってくると、いわゆる「選別」をしていく必要が生じます。
つまり、絶対に直さなければ出荷できないような重要なBugと、次期バージョンで対応することにして今回は見送ってもまあOKというようなBugとに分ける必要があります。
この「選別」をする作業の中心となって、いろいろな人の意見を取りまとめ、最終的な決断に持って行くのが、我々の仕事の中でも重要なものになります。
あらかじめ断っておきますが、我々にはそのBugの選別に関して「特権」があるわけではありません。
つまり、そのBugを直すべきか次期バージョンに見送るべきか、独自の判断で決める権限はありません。
あくまで、各方面の関係者の意見を聞き、それらを総合的に判断して、人々の合意を得て、その上でBugの選別を行います。
したがって、いつも悩むのは、人々の意見が合わなくて板ばさみに苦しむ、ということです。
開発者は、大抵Bugを直すことを好みます。やはり、分かっているBugのある状態で出荷することは、開発者の観点からは許せないことだからだと思います。
一方、マーケティングやセールス関係の人達は、Bugを直すことで出荷日に影響が出ることを嫌います。彼らはその出荷日に合わせていろいろなアナウンスやイベントなどを計画しているため、それも当然だと思います。
ただ、今回出荷を控えている製品に関しては、そのような「板ばさみ」で苦しむことはほとんどありませんでした。
その代わりに悩んだのは、「最後の最後になって、重要なBugが見つかってしまった」という類の悩みでした。
出荷の間際になると、「出荷候補版」に相当するビルドを作り、それを元に最終テストに入ります。
しかし、もしもその「出荷候補版」をもう一度作り直すとなると、その作り直しに時間がかかるのはもちろんのこと、最終テストも基本的にやり直しですから、下手をすると出荷日が遅れてしまう可能性があります。
重要なBugが、もっと早い時期に見つかれば問題はないのです。
最終テストはまだ始まっていませんし、まだまだ日々の製品ビルドも続いています。
しかし、最後の最後に重要なBugが見つかってしまったら大変なのです。
そして今回は、出荷予定日の一週間ほど前になって、「ひょっとしたら出荷を停止して仕切り直しをしなければならないかも知れないBug」が見つかってしまいました。
そういう時、どのような対応の仕方をするかでプロジェクト管理者としての技量が問われるところです。
「面倒くさいから、関係者にはこれは大した問題ではないということにして丸めこもう」などと考えるのは論外です。
「いかに出荷日に影響を与えないでやり過ごすか」を中心に考えるのは、まあ無難ではありますが、長期的に物事を考えられているかは疑問です。
「もしもそのBugを直さないで出荷した場合に起こり得る問題はなにか」を考えるのは、基本だと思います。
「お客様の立場から考えた場合はどうか。そしてそのお客様の視点を理解するために、背景となるデータを集める方法はないか」というように考えるのは、かなり重要だと思います。
「この会社の長期的なゴールを考えた場合、はたしてこのBugを残したまま出荷するのがそのゴールに近い方法なのか、それとも出荷時期を遅らせて、マーケティングにインパクトを与えても、しっかり直してから出すのがゴールに近いのか」というように考えるのは、プロジェクトを管理する人間には必須だと思います。
結局、いかに大きな問題や緊急の問題が見つかったとしても、あらゆる視点・あらゆる可能性からその問題を見つめて、あらゆる情報を収集・整理して、あらゆる方面の人達に情報を伝えてかつ意見を伺い、総合的に最もいい結論を導き出すことができる技量が、この仕事には必要なのだと思います。
自分の場合は、本当にまだまだなのですが。