製品開発における品質追求と妥協のジレンマ

自分は以前ソフトウェア開発会社にて働いていた際には、プログラムコーディング、テスティング、提案を通して製品の総合的なクオリティを高めていく担当をしてきて、その中で感じてきたジレンマを書いてみる。
開発に携わる人の中で、これを読んで何か考え改まる部分があれば幸いです。

追求と妥協の天秤

筆者はA型思考なせいか、とことん作りこんでクオリティを限界まで上げたいと常々思っている。仕事には妥協は許したくないし、社会人になってからその気持ちはずっと変わらずに仕事というものに向き合ってきている。

しかしそのような意思があって、実際に開発に携わるとそうも行かない事を痛感する。特に分かりやすいのが発売日が迫る開発終盤。時間をかければかける程に磨きをかけられるけれども、基本的にはその追求に終わりは無い。100%の完璧なものを目指したら、いつまで経っても発売できないため、どこかで線引きをしなければならない。つまり妥協しなければならない。

開発終盤には必ずどこまで追求し、妥協するかをPM（プロジェクトマネージャー）やマーケティングチーム、サポートチームの人らと連日のように議論、最終調整していく事となる。自分の立場としては出来るだけ多くの要素を反映させるべく、材料をかき集めて提示する。しかし後術のようにこれがなかなか難しい。

妥協的思考麻痺

開発業の人達というのは次第に「開発には妥協は付き物」という考えの下、妥協することが気にならなくなってくる。プロジェクトの度に「前回はこれだけ妥協したのだから今回も」と、妥協ラインを前回と同じ位置に最初から設定した上で開発が進行し、結局開発最終段階で既に妥協した部分が多分あることを忘れて、新たな妥協を生み出していく。これが積み重なっていくことで製品群のクオリティが下がっていく形態が出来上がってしまうので注意が必要。

妥協ラインというのは前回を振り返って決めるのではなく、プロジェクトの度に新規に設けるものでなくてはならない。

ちなみにQA（Quality Assurance）やテストなど、バグやクオリティ関連の報告する立場の方々は、この妥協ラインというのを意識してはいけないと思う。妥協ラインはあくまで判断を下す立場の人に任せてしまって、とにかくあらゆる問題、あらゆる改善提案を自分らでフィルターせずに全て報告するべきであり、判断を下す立場の方々は多量に流れ込んでくる案件を処理するのは大変ではあろうけれども、フィルターはあくまで自分のみが行うものと割り切るのが良いと思う。

追求は目先の売り上げの為だけか？

前述の通り、自分は最終的な判断をするPM（プロジェクトマネージャー）などに提案・議論する事もある立場だった。開発前半〜中盤であれば基本的にはどのような提案も通るものの、終盤ともなると天秤にかけられ、大半が切り捨てられる。

そして様々なプロジェクトにおいて終盤に提案した際によく言われた言葉がある。「それを残り少ない時間の中で反映する事で、この製品は売り上げが何本伸びる？」と。

製品の種類にもよりますが、例えばテレビゲームなんかは購入してやりこまないと見えない部分が多分にある。こういった深い部分は目先の売り上げにはほとんど影響しないため、上記質問は「ほとんど伸びません」となり、「ならば却下」となる。

しかし「クオリティ」というのは、外観、性能、楽しさという売り上げに直結する部分ではないものの、会社と客の信頼関係を築く非常重要な要素であり、製品が気に入ってシリーズ購入の決意へと繋がったり、購入者による評判で新たな客を獲得するなど、次の製品へとじわじわと売り上げに影響させるもの。確かに目先の売り上げにはほとんど影響が無くても、将来的に考えれば大きな影響を与えるものである。

膨大な案件を生かすか殺すかと天秤にかけなければいけない状況で、熟考していられないから、シンプルに目先の売り上げを天秤材料に使うのはわかるけれども、今一度クオリティに対する重要性を考え直してほしいと思う。

Postponed（次期アップデート対応）の落とし穴

最近のハードウェア＋ソフトウェアはネットワークに対応し、製品発売後もアップデートする事ができる。これにより近年のソフトウェアは作りが甘い。具体的にはリリース目前にしてバグが多くても、残ったバグは次期アップデートで対応させれば良いという考えから、発売延期せずに、若干未熟な状態で発売されたりする。この考え自体が前述の妥協的思考麻痺と言え、非常に良くない傾向。

そしてこの次期アップデートに持ち越す事を「Postponed」等と呼ばれている。バグなどの案件は独自のデータベースシステムなりExcelなりで管理され、ステータスとして「Postponed」と付けられる。他にも「（問題ではあるけど）修正しない・修正できない」という意味で「Won't Fix」という判断もある。

開発終盤における「Postponed」と「Won't Fix」の2択は、当然Postponedの方が気楽に選べる。「対処する事は対処するのだから」と、今回のリリースで「問題として残る事」への罪悪感的なものが薄いというわけである。これにより、本来はもう一つの選択肢「今回対処する」も軽視され、Postponedにポンポン割り振ってしまう傾向が見られたりして、これが非常に危険。

Postponedの落とし穴が一つある。例えば、とあるバグはユーザーにとって使い勝手が悪くなるものであったとする。対処されるまでの長い期間、ユーザーはそのバグと付き合わなければならず、毎日のように軽いストレスが掛かり続ける事となる。

そしてようやく次期アップデートで対処したとする。するとユーザーは喜ぶのではなく、戸惑うケースがある。人間というものは慣れる生き物なので、不便な状態に適応して慣れてしまい、その後バグが取り除かれた事による変化が逆にストレスとなってしまったりする。

これにより「Postponed」と決断した後、時期アップデート時に直さない方が良い状況として「Won't Fix」に切り替わるケースも多々見てきた。つまり最初の判断で「対処する事は対処するのだから」と楽観的に「Postponed」とした判断は、結果的に「Won't Fix」となる可能性もありうるため、そうしたケースもある事を意識して、今一度「Postponed」が「軽くない事」を認識して欲しいと思う。

ざっと書きましたが、開発現場における問題やノウハウは様々経験してきており、何か紹介したい内容が思いつけば書いていこうと思います。