システム開発における品質管理

システム開発で作成されるシステムは品質が高いものが望まれます。システム開発において、システムの品質を管理する品質管理は、システムをより良くするために重要な工程になります。

しかし、品質管理という言葉だけでは、どのようなことをするのか具体的に把握できません。品質管理では、品質をよくするようにと要望をただ出しているだけでは望む通りの結果は得られません。品質管理で注意すべきポイントを押さえておくことが重要です。

そして、システム開発を依頼する発注側が品質管理に関われる場面は限られています。その限られた場面を生かす為には、システムに対して何を望んでいるのか明確にする必要があります。

より良い品質のシステムにする為に、品質管理で何をするのか、注意するべきポイントはどこかを説明していきます。

品質管理とは、発注側の期待をどこまで実現するかを管理すること

システム開発における品質とは、発注側がシステムに求める期待がどの程度達成されているかという度合いを意味します。この品質が高いほど開発されたシステムに対する発注側の満足度が高いということです。発注側の満足度の達成率が100%に近いほど高品質なシステムと言えるでしょう。

逆にどんなにシステムに機能が充実していたとしても、それが発注側が期待する機能でなかった場合、そのシステムに対する満足度は低くなってしまいます。発注側がシステムに対して期待することには、以下のように様々なものがあり、発注側によって違ってきます。

• 要求された機能が備わっていること
• 故障をしない、または、故障してもデータが損失せずにすぐに復旧できること
• 処理速度が早く、操作しやすいこと

だからこそ、発注側はシステムに何を望むのかを開発会社に具体的に説明することが必要です。そのためには、品質にどのようなものがあるかを知ることが重要になってきます。

品質にはいくつかの段階があります。以下のように、備わっていることが大前提の当たり前品質から、備わっていれば魅力的だが、不足していても仕方ないと割り切れる魅力的品質まであります。

• 当たり前品質
  • 備わっていても当たり前としか感じないが、ないと不満に感じるもの
  • 例：システムが機能通り正しく動く、不具合がない。
• 一元的品質
  • 備わっているとうれしく、ないと不満に感じるもの
  • 例：使いやすい画面やボタン配置、画面の反応速度
• 魅力的品質
  • 備わっていなくてもかまわないが、あるとうれしいもの
  • 例：便利な追加機能、おしゃれなデザイン

後者の魅力的な品質を重視するあまり、最低限の品質を見落としていると、満足するシステムにはなりません。例えば、不具合が良く発生したり動作が遅かったりしたら、いくら優れた機能が多くてデザインが良かったとしても、そのシステムに対して不満を感じるでしょう。

品質と呼べるものは以下のような例があります。それらの中で、システムに大前提として求める当たり前品質と、なくても良いがあるとなおよい魅力的品質を区別して、優先度を付けましょう。そして、必須の品質から優先して開発会社に伝えていくことが、満足度の高いシステムを開発することにつながります。

• 機能性
  • 実装された機能が要望を実現できる度合い
• 信頼性
  • 故障せずに機能が正常に動作し続ける度合い、または、故障してもすぐにデータや機能を回復できる度合い
• 使用性
  • 利用者がシステムの使い方を理解しやすいこと、使いやすさの度合い
• 効率性
  • 適切な応答時間、処理時間で機能が実行される度合い
• 保守性
  • 保守(改修)や修理のしやすさの度合い。開発者本人しか理解できないような仕組みだと、改修や修理する際に時間や労力がかかってしまう。
• 移植性
  • 別の環境でも簡単に移して使える度合い。サーバーを移行する際や、OSが変わる際に重要。

品質管理の目的は、限られた予算と納期の中で最大限品質を高めること

品質が高くなる程、システムに対する満足度は高くなります。だからといって、品質をできるだけ高くすることを開発会社に依頼すればよいのかというと、そうではありません。

なぜなら、完成したシステムに対して発注側が評価する際の軸は品質だけではなく、納期と費用があるからです。品質、納期、費用の3つの軸が満たされるかどうかによって、システム開発が成功か失敗かの評価が左右されます。

特に難しいのが、これら3つの軸はどれかを満たそうとした場合に、いずれかが満たせなくなるトレードオフの関係にあることです。

短い期間で開発しようとすると、人員を増やすか開発する機能を少なくする必要があります。すると、増員することで費用が増えるか成果物であるシステムの品質が悪くなります。

費用を少なくすれば、その分、雇える技術者は減ることで納期が増えるか、複雑な依頼は出来なくなることで品質が下がるかになります。

品質を担保するために発注側の要求を満たそうとすると、開発期間が長くなり、その期間中は人件費を払い続けることになります。その結果、納期と開発費用が増えてしまいます。

このように、システム開発で発注側の評価に影響する品質、納期、費用は、それぞれのバランスを考慮して優先度をつけていかなければなりません。そして、この3つの軸の中で、品質は最も発注側の評価に影響する割合が大きくなります。例え他2つの納期と費用が満足できるものだったとしても、品質が満足できるのもでない場合、システム開発は失敗とみなされてしまうからです。

そのため、品質を出来る限り上げたいと発注側は考えますが、システム開発で使用できる開発期間と費用は限られています。品質管理の目的は、限られた納期と費用の中で成果物の品質を最大限保証することであり、品質を最大限高めることではないことに注意しなければなりません。

品質にこだわるあまり品質を高める要望を出し続けていれば、当然その分だけ開発期間と費用は増えてしまい、そのうちに開発期間と費用が許容範囲を超えてしまいます。そうするとシステム開発をそれ以上続けることができなくなり、肝心のこだわっていた品質が満たせないという状態になりかねません。妥協できる開発期間と費用の範囲内で品質を高めるためには、システムに求める要望の優先度を明確にすることが重要です。

品質管理の工程は、基準を決める準備と達成度の確認をする運営

システム開発の品質管理には大きく分けて、満たすべき品質の基準を決める準備フェーズと、成果物がその品質基準を満たしているか確認する運営フェーズの2つの工程があります。

満たすべき品質の基準を決める準備フェーズ

品質はシステムに対する発注側の要望がどれくらい満たされているかで評価されると説明しました。つまり、品質は、それを評価する人によって、基準が変わることになります。品質管理を始める前の準備として、これから作成するシステムにおいて、満たすべき品質の基準を具体的に決める必要があります。

 例えば、社内の手作業でやっていた事務作業をシステムで自動化する場合、そのシステムを使用するのは事務作業をする社員です。その社員にとっては、複雑な作業を楽にしてくれる便利な機能が備わっているか、それが使いやすいかという点が評価されます。

あるいは、24時間常に稼働するサーバーを運営する会社にとっては、安定して稼働し続けることが重要です。負荷が一時的に増えた際でも停止しない性能や、仮に停止した場合もすぐに元の正常な状態に復旧できることが求められます。

定期的に新しいサービスをユーザーに提供するサイトを運営する会社にとっては、新しいアイデアを反映しやすいシステムが適しています。安定稼働を重視して機能の追加に手間がかかるよりも、多少不具合が発生するリスクがあっても、変更を迅速に反映できる方が評価されます。

このように、開発するシステムを評価する人によって、求めるもの、重視する点は変わってきます。

機能の追加をしやすい代わりに停止するリスクがあったり、停止した際の復旧に時間がかかるシステムは、安定稼働を求める顧客にとっては低評価になります。逆に、斬新な機能を常に追加したい顧客に取っては、高評価になるでしょう。

システムに求められる要望によって、後のテストで確認すべき点も変わってきます。使いやすさを求めるなら、画面の応答時間は重要になるので、「応答時間が何秒以内」という基準になります。安定稼働なら、「想定される最大の負荷がかかっても停止しないか」や「故障で停止した際にデータが消えないか」という基準になります。

求める要望を満たす基準を決めておかないと、開発したシステムについて品質を満たしているかどうか判断するために、どのようなテストをすればいいのかが定義できません。

基準によって必要なテストは異なります。あらゆる基準のテストを実施して、その全てで最高の結果をだすのは現実的ではありません。それらのテストで基準を満たすようになるまで修正をしていては、いくら開発期間と費用があっても足りません。どこかの段階で、このテストに合格するならば品質を満たしていると判断する基準が必要になります。

その基準が高すぎると開発期間や費用が余分にかかることになってしまいます。そうならないように、準備フェーズでは、システムに求められる要望を満たす適切な品質基準を決めておく必要があります。

品質を満たす為の基準を設定する際、専門的な知識のない発注側だけで決めるのは困難になります。具体的な基準を設定し、必要なテストを定義するのは開発者の役割になります。発注側が決めるべきは、システムに何を求めているのかという要望です。それを開発者に伝えることで適切な方向性の品質基準を決めることができます。

成果物がその品質基準を満たしているか確認する運営フェーズ

準備フェーズで品質基準を決めた後は、システム開発の成果物が品質基準を満たしているか確認していく運営フェーズに移ります。

準備フェーズで決めた基準を満たすか判定するためのテストを開発した成果物に対して実施していきます。基準に満たないなら成果物を修正していく必要があります。

このテストは完全に開発側の仕事になるため、発注側が携わることはほぼありません。関わるとしたら、品質基準を満たすための改善作業をする際に想定以上の期間や費用がかかることになった場合になります。

基準を満たすために開発期間や費用を増やすことを了承するか、あるいは、優先順位が低い要望に関する品質基準なら、ある程度妥協することも一つの選択肢になります。その最終的な判断をするのは発注側の役割になります。

品質管理の重要なポイントは基準を決めて共有すること

システム開発において、成果物に対するテストは様々な方法があります。それらを全て実施するということは現実的ではありません。目的にそった必要なテストだけを実施する為には、具体的な品質基準を決めることが重要です。品質基準がはっきるすることで、基準を満たしているか判断する為にどのような観点で成果物を確認すればいいのかが明確になります。

確認すべき点が明確になっていれば、それを適切に確認するための効率的なテスト方法を定義することができます。それは、品質の達成を妨げる課題の早期発見につながり、開発期間が長くなるのを防ぎます。

品質基準を満たせなくなる指標を設定しておき、それを越えた際に改善するということを繰り返ことで、品質を向上させていきます。

品質管理を成功に導くためには、品質基準を決めた後に、それを組織内で共有することも重要です。それぞれの目指す方向や目標が違う人が集まって仕事をすると、様々な問題が発生します。一人一人が共通の目標をもって取り組まないと、目標を達成する難易度が高くなります。

システム開発を成功に導くためには、開発会社に品質基準を決めるノウハウと、基準を組織内で周知徹底する体制があることが重要になります。

開発会社にそれらが備わっているかどうかはどのように判断できるでしょうか。まず、品質管理の体制が整っているかを見るとよいでしょう。品質基準を決めて、それを基にチェック体制を作る際に、技術者の経験のみで決めているようではだめです。品質管理を支援する部署がある、もしくは、管理方法が組織内で標準化されている、そういう会社を選ぶべきです。

発注側が品質管理に関与できるタイミングは設計段階まで

システムの満足度を左右する品質管理ですが、実際に作業を行うのは開発側になります。この品質管理に発注側が関わることができるタイミングは限られています。望む品質のシステムにしたいならば、発注側が関われるタイミングに適切な対応を取らなければなりません。

品質管理で重要なポイントは基準を決めることだと説明しました。発注側が関わるタイミングも、この基準を決める段階、つまり準備フェーズになります。それはシステム開発では要件を聞いて設計書を作成する工程までになります。

発注側のシステムに求める要件を開発側と話し合い、品質基準も盛り込んだ設計書が作成されます。この設計書を作成する工程までに、品質基準の元となる要望を伝えきる必要があります。なぜなら、設計が終わって開発が始まっってしまったら、それ以降は要望を追加することはできなくなるからです。

開発側は設計書に基づいて、その後の開発計画を立てています。設計書に入っていない要求をシステム開発の途中で追加する場合、予定していなかった作業が発生することになります。

そうなると当然、開発期間や予算を当初よりも増やさなければいけなくなります。しかも、開発が進むほど、修正する際の作業量は増えて必要な期間や費用も多くなるため、修正は困難になります。

そのような状況にならないよう、発注側と開発側で目指す品質基準について認識をしっかりと合わせておく必要があります。その為に、重要になるのが、設計書のレビューです。

品質基準について発注側と開発側で話し合った結果を基にして、設計書を開発側が作成します。発注側は作成された設計書について、レビューすることで認識のずれをなくします。

当然、技術的なことは発注側にはわかりません。なので、発注側が設計書をレビューする際に見るべきは、以下の点についてきちんと伝えた通りに定義されているかということです。

• 要求が網羅されているか
• 実現するべき要件が明確で、具体的か
• 納期、開発費用が明確か、余裕があるか

要求が網羅されているかは、伝えた要望に漏れがないかを確認します。口頭で伝えていたとしても定義書に記載されていなければ、システムに盛り込まれていなくても文句を言えません。

開発期間や費用の確認も重要です。システム開発において、全ての要求を満たすことはできません。そのため、譲れない要件を満たすには、優先順位の低い要件をあきらめたり、予算や期間を増やす必要があります。

これらは発注側が決めるべきことです。開発会社とコミュニケーションを綿密に重ねて、優先順位の高い要件は何か、その為にどこまで予算や期間を調整できるかを伝えていきます。

想定外の問題が発生した際に対応するために期間や費用に余裕を持っておく必要があります。もし、期間や費用にそのような余裕が含まれていない場合、想定外の問題が発生したら、許容以上の期間や費用がかかるか、品質が悪くなる可能性があります。そのため、余裕も含めた開発期間や費用になっているか、それらが許容範囲かを確認します。

まとめ

品質とは発注側のシステムに対する要望、期待の達成度の度合いを意味するものであり、納期や費用と並んでシステムを評価する際の軸になるものです。品質、納期、費用は互いにトレードオフの関係であり、どれか一つを優先すると他のものの満足度が下がってしまいます。これらのバランスを考えて、限られた予算と納期の中で最大限品質を高めるように管理していくこが品質管理です。

この品質管理を開発チーム内で円滑に進めていく為には、システム開発で最終的に満たすべき品質の基準を決める必要があります。そして、開発中は成果物が定められた品質基準を満たしているか確認する為の適切なテストを実施して成果物を改善していきます。

システムに求める要望に沿った品質基準の定義や開発中にその基準を効率的にチェックする体制の構築が適切に実施されるかどうかが品質管理の重要なポイントです。システム開発を依頼する開発会社が品質管理を適切に実施する能力があるかどうかは、品質管理を実施・支援する部署があるか、品質管理の方法が標準化されているかなどで判断できます。

品質管理を成功に導くためには、発注側も品質管理に積極的に協力していくことが必要です。発注側は設計時に要望をきちんと伝えて合意しておきまましょう。開発工程中に要望を追加したり変更したりということは、品質の悪化、納期と費用の増大に繋がります。設計段階で要望を認識の相違なく伝えられているか、要件定義書や設計書などの成果物を確認しましょう。

品質管理でどのようなことを行うのか、注意するべき重要なポイントは何かを理解して、発注側の役割を果たすことが品質の高いシステムの開発につながります。