とあるPJの立て直し: 品質の課題と向き合う
この記事の目次
とあるプロジェクトの立て直しの記録に基づいて、プロジェクトマネジメントをテーマにシリーズで書き残したいと思います。今回は品質の課題について触れます。
要旨#
品質は触れば分かる#
本プロジェクトで開発されていたシステムは、触ると素人でもすぐに分かるほど非常に品質が低いものでした。一例を挙げると、URLを打ち込んでからログイン画面が表示されるまでに2分ほど時間が掛かるのですが、私はこれまでそのようなシステムを見たことがありません。
サービス提供を目指してシステム開発を行っている以上、致命的な状態です。ここで得られる教訓としては、どのようなシステム開発であっても、常に触れる状態を維持することです。それができないとすると何かリスクがある可能性が高いです。ユーザーが触るためのシステムを触らせない理由について聞いてみましょう。
では、なぜこのような状態に陥ったのでしょうか。
低品質を招くもの#
複合的な要因から低品質になっていたわけですが、要因の一部として考えられるのは以下のようなものです。いずれにしてもすべて無理から生じているものと言えます。
このような状況から、きちんとした機能を作ることは体制的にも期間的にも能力的にも不可能なまま、何か動いているらしいものを紙芝居のように続けて、「後でよくなる」と課題を先延ばしにしていたわけです。当然ながら、顧客が触れる環境は用意されておらず、顧客から見ると隔週の報告で見る紙芝居で「できている」ことになっていました。また、開発メンバーは顧客やマスタースケジュールを知らず、紙芝居機能の要件だけを伝え聞いて作っていたため、その範囲においては正常に開発されていたとも言えます。なお、プロトタイピング1を行うことが悪いわけではありません。
潜在的なリスク#
どんなに隠しても、先延ばしにしても、必ずお披露目(Unveil)するときが来ます。そのときに明らかになるのは素晴らしい製品ではなく、先延ばしにしていた潜在的なリスクです。
これらのリスクを抱えたまま、リリース日がいよいよ近づいてきていた頃合いでの引き継ぎでした。（引き継ぎ時点では、あと1年半くらいは開発してからリリースだと感覚的に思い込んでいましたが、実態は3ヶ月後でした）
悪いニュースほど早めに対応する必要があります。品質を高めるための具体的な活動内容については次の回に触れたいと思います。
品質とは何か#
品質の課題にどう対応したかをお話しする前に、品質とは何かについて触れておきたいと思います。品質の定義は様々ありますが、私が支持している定義の一つに「誰かにとっての価値」2というものがあります。
要件通りに機能すること、テストに通ること、これらも確かに品質の一つの側面ではあります。しかし、それだけでは不十分です。極端な例ですが、誰にも使われない機能に不具合があったとしても誰も困らないのです。反対に、よく使われる機能が要件通りに動いていたとしても使いづらければ品質は低いと言えます。
このような観点から品質を捉える尺度の一つとして「価値基準」で考えることをお薦めしています。
技術的負債#
品質は目に見えないことから、後回しにされたり、犠牲になることが多い要素です。しかし、ユーザーにとってはシステムを触ることで感じられるすべてでもあります。
一般的に、ウォーターフォール開発では実装フェーズと試験フェーズが分かれ、試験フェーズが後段に来ます。後段にあるため、「試験フェーズで品質を高めるのでひとまずはよい」といった軽い気持ちで実装フェーズを進めてしまうと品質は低下します。また、品質の低い機能を実装すると言うことは技術的負債を最初から抱えた状態にしていることになります。そして、技術的負債の返済が難しく大変なものであるかは周知のことと思います。実装フェーズにかかる労力あるいは時間を減らすことはできますが、試験フェーズでの「品質を高める」活動で多大な労力をつぎ込むことになります。
品質は高く維持する#
価値がある状態で生み出し、その状態を維持することが一つのプラクティスです。
低い水準で生み出し、試験を行い、修正をしたとしても品質の水準は低いままです。なぜなら試験の水準を超えたところで品質に対する活動が満たされたことになるため、試験の水準以上にはならないからです。さらに、（品質はともかくとして）実装がすでにあるため、変更を嫌い最小限の修正で試験を満たそうとします。逆の視点からは、機能に対する実装が先にあり、試験を実装すると「機能を満たすための試験」を作ってしまいます。このような事情から、品質を高くできるのは、設計と試験の実装が機能の実装と真に独立してしっかりとなされている場合に限られます。
テスト駆動開発3が品質に対して効力を発揮する背景はこのようなところにあります。ユーザーにとっての価値から導かれるシナリオ/テストケースを先に実装し、それを満たす状態で機能を生み出すことで、品質の水準を常に維持できるのです。そして品質の高い状態をCI/CDを活用して維持します。