検証と確認により実施すべきことは、品質を確保しつつ仕事を仕上げるということです。
製品を作ることばかりでなく、作業であったり、一つひとつの会議などのタスクであったりしても品質を保ってやり続けることで、全体の品質が保てます。
ここでは、品質を確保するやり方として、検証と合目的性確認の手法について説明します。
品質とは
品質はISOなどでも語られており、基本的にはある要求を満たしていることが品質を満たしていることと言えます。
ただ、ある要求と言うのは、ある時点で決めた要求であることもあり、その要求を満たしたとしても最終的に仕上がったものは、本来の要求を満たしていないことがあります。
また、さらにはV&V（Verification & Validation）と呼ばれる検証と妥当性確認ということも定義されています。
検証は、規定要求事項が満たされることを確認する、妥当性確認は、意図された用途への要求が満たされていることを確認することとされています。
言葉がかなりわかりにくく、結局何なのかが理解できないと思います。
品質とは、本来何かしら決めた仕様どおりになっていることであるべきです。それ以上の要求というのは、要求が誤っているかもしれませんので、マネジメントしていく上では、線引きが難しくなります。
要するに、こうしたほうが使いやすいだの、これがあったほうが満足度が高いだの、いったことを要求とするならば、どこまでの満足を確認できれば品質を満たしたと言えるのか、きりがなくなるのではないかと思います。
そうは言っても、実際の現場で起きることは、設計どおり・仕様どおりではあるが、使ってみると違うといった意見です。ある目的を持って進めてきたのですが、個々に見ると合っていて品質を満たしているのですが、結局目的とは合っていないということです。
これでは、これまでの営みが報われません。
そこで、やはり検証という基本的な品質マネジメントと並行して合目的性確認ということを行っていくべきと考えます。
妥当性確認という言葉はやや難解と思い、違う言葉を使わせてもらっています。
検証と合目的性確認とは
検証とは
品質の場面では検証という言葉がよく使われます。
検証とは、決めたこととあっているかどうかということになります。
ITシステム開発プロジェクトでの事例でいうと、設計・仕様とあっているかということです。
これは全体のことを言っているので、各フェーズでの検証ということでは、このとおりとなります。
構想・企画での検証
要求の起点になっていることなので、前工程がないです。よってこの内容が考えるべき人たちの考えとしてまとまっているか、という観点でレビューされていることになります。
要件定義での検証
構想・企画を受け、より具体的に要求を業務要件・システム要件に落とし込んだものになります。検証の観点の一つは、構想・企画が意図したことを漏れなく展開されているか、ということになります。
もう一つの観点としては、業務要件・システム要件は関係する人たちから納得されるものか、ということになります。
設計における検証
要件を設計することで仕様化します。モノづくりとしては設計ありきなので、狭い意味での品質ではこの設計が起点となります。検証の観点としては、要件は漏れなく仕様化されているかということになります。
実装における検証
実装段階では、局所的な実装物に対して、仕様どおりかどうかを確認していきます。
テストにおける検証
検証そのものの意味になります。実装されたものが要件を実現する実装物となっているかを、設計や要件に照らし合わせて、合っているかを確認します。
受入テストにおける検証
テストとは違った意味で設けています。テストは設計どおり作られているかという観点となりますので、検証そのものになります。受入テストは作られたものを、要求を出した側が検証することになります。どのように作ったかはブラックボックスでもいいので、最終的に作られたものが思ったとおりになっているかという観点になります。このあたりから、検証という範囲を超えてくる部分が明確になってきます。つまり、合目的性確認に実質なってきます。
運用テストにおける検証
運用テストは、業務要件に沿って実装されたものを使ってみて、変更後の業務が想定どおりかという観点になります。思ったより入力時間がないとか一人当たりのデータが多すぎるなど、想定外にうまくいかなそうな業務があれば、業務の設計変更を検討しないといけません。
移行における検証
変更後の状態に切り替え実装します。よって検証の観点としては、変更前から変更後へ網羅的に実施されたかという観点となります。さらに移行後の運用が始まると、変更後の状態として、当初の構想・企画時点での想定や業務要件として定義したものと比較してどうか、という観点もあります。
合目的性確認とは
Vモデルが完全モデルである前提とした合目的性確認
Vモデルは特に説明してきませんでしたが、簡単に説明すると、構想・企画、要件定義、設計、実装、テスト、受入テスト、運用テストと進めたとして、実装をＶの真ん中として、設計とテスト、要件定義と受入テスト、構想・企画と運用テストがそれぞれ対応し、検証していくというものです。
テストの種類等で若干違う説明になることもありますが、一つのモデルとして説明しました。
ウォーターフォールと呼ばれるもので、上から下に流れるように進めていき、上流での品質が完全である前提で、以下対応付けされた検証を続けていくことで、最終的に品質が担保されるというものです。
この完全モデルを前提とした場合、合目的性確認というのはどう位置づけされるでしょうか。
構想・企画や要件定義といった上流工程で目的を実現できるよう定義されているはずですから、Vモデルどおり進めていけば、最終的には合目的性確認となることになります。
実際の合目的性確認
完全モデルと揶揄したことからも想像できるように、少し規模が大きくなると完全はほぼありえません。
ではどうなるかと言いますと、プロジェクトを進めている間、始めから最後まで、場合によっては終わったと思われた後でも合目的性確認は続きます。
つまり、ずっと検証と同時に合目的性確認のマネジメントしていくべきということです。
なぜずっと確認していかないといけないかというと、理由は3つほどあります。
一つは、時間が経ってしまっていると目的そのものが変わってくることがあるから。
二つ目は、目的が大きな意味では変わらなくても、細かいレベルでの目的が変わったり、追加されたりするから。
三つ目は、目的がそもそも違っていたから。
検証と合目的性確認の方法
検証の方法
検証の方法としては以下があります。
- 関係者とのレビュー
- 前工程や前タスクとの整合性確認
- 別な切り口での他人チェック
- テストによる確認
それぞれバリエーションがありますので見ていきたいと思います。
関係者とのレビュー
検証の方法の一つとして、レビューによって確認するというものがあります。
関係者としていますが、関係者と言っても様々なケースがあります。
その対象となる当事者というのが一つです。
次が経営者や権限者です。
あるいは、外部などの専門家ということもあります。内部にも専門家はいるかもしれませんが、よほどの会社でないといないと思われるため、基本的には外部ということにしました。
人がレビューをするということは、答えを持っている前提で合否の判断を行うということになります。
したがって合格基準をわかっているという人にレビューをしてもらわないと、正解に近づかないという性格のものです。
タスクには仕上げプロセスがあるという話をしましたが、仕上げ段階で的確な人を集めレビューを行うことが多いです。
なお2番目の経営者や権限者は合否には関係しますが、少し意味が違う面もあります。それは答えを持ってはいるが、少し目線が上になっているということです。この場合は、レビューアに合わせて情報レベルを変えるなどの工夫が必要です。
前工程や前タスクとの整合性確認
前の工程やタスクは後のために行っています。プロジェクトにおいては徐々に詳細化されていくので、詳細化の前提となるタスクが前に行われているはずです。
タスクでの作業が細かいものですと、前タスクのことを忘れてしまって漏れがあったり、解釈を間違ったりします。よって当該タスクを仕上げるにあたって、前工程やタスクからのインプットを今一度確認し、整合性をチェックします。
この手法は前工程やタスクが正しい前提で実施するものなので、その点は注意が必要です。その点ではレビューにて多くの人から指摘を受ければ前工程やタスクの不備まであぶり出せる可能性があります。
別な切り口での他人チェック
他人による作業のダブルチェックにより作業品質を担保する手法はよく行われると思います。
それはある意味当たり前でもあるので、ここではもう一歩先の手法を紹介します。
他人がチェックするにあたって、別な切り口で検証します。
この検証方法は簡単に言うと検算と同じです。足し算の結果を引き算によって元の値になるかを検算するのは別な切り口と言えます。
データの集計結果を検証する時などに有効です。
一つひとつ作業を積み上げている人からすると、途中での間違いに気づかないことがあります。結果が間違ったとして、やってきた作業をそのまま辿って誤りを探しても、同じところで間違ってしまう傾向があります。
そこで別な切り口で検証していくことで、間違いをあぶり出すことができます。
集計であれば、列ごとに足すものを行ごとに足してみる等、集計の切り口を変えてみます。
結果の意味で検証することもあります。例えば欠品率を計算するとして、普通は5%程度なのに15%になっていておかしいといった検証です。
テストによる確認
設計に基づいてものが出来上がっているならば、テストをしてみるというのは有効です。
これはITのプログラムモジュールのようなものとも限りません。
マニュアルや説明書のようなものでも、その通りやってみるというが品質を高めます。
テストの手法として、システム開発では単体、結合、総合テストのように呼ばれていますが、どれもテストケースの考え方は同じです。
インプットとなる情報が何らかの処理を通してアウトプットになります。
それぞれのインプットとアウトプットが正常であるときと異常であったときでテストします。
そしてインプットとアウトプットの種類を網羅するようテストでます。
さらに種類や数値においては限界値でのテストをします。
これらを実施すれば、どのようなテストであってもかなり網羅できますし、もし他人がやったテストをもう一度テストするとしたら、たったこの3点で検証するだけでかなりのエラーが検出できるはずです。
合目的性確認の方法
合目的性確認の方法としては、一部検証でも出てきてしまっているのですが、上位目線での確認を常にしていくということがポイントとなります。
各種検証を行うにあたって、目的を意識して検証を行う
各工程や場面で検証を行います。その際は前の工程などを中心として、合っているかを検証します。
ある意味範囲を限定して検証しているということになります。
しかし、実際は前の工程などのインプットが誤っている可能性があります。あるいは状況が変化している場合もあります。
よって常に検証を行う際に、狭い視野を広くして目的を意識した検証を行います。
目的や理由を成果物に記載して、後工程で確認する
仕様書・設計書などは決定した仕様が記載されています。
ただし仕様はいくつか方法があるうちの一つである可能性があります。
選ばなかった方法があるとしたら、後からなぜその方法を選ばなかったか、もしくはなぜ選択したほうを選んだかを知りたくなる時があります。
それは、後々に実際は目的に合っていなかったと思われる場面があるからです。
一度迷って決定したことを再度検討する時間はもったいないですので、経緯や理由などは記録しておいたほうがよいでしょう。
目的が変わったと察知したら変更マネジメントを行う
そもそも今実行していることの目的が変わってしまうことがあります。
本来はそのようなことはあってはならないと思われるかもしれませんが、他のプロジェクトや外部の影響、あるいは予算が出なくなったなどで、実際には日常的に起きます。
明示的に目的が変わることもあれば、やっていくうちに実は本来の目的と合っていなかったということもあります。
いずれにしろ、目的のブレを察知できたら、変更マネジメントを行いましょう。
レビューの関係者として目的目線の人を定期的に入れる
作業レベルに入り込むと目的を見失うことがあります。ITにおいては、よりやり易いほうを選んでしまうことが起こり得ます。
ところが別な面で業務量が増加してしまうようなことが起きます。
その場合、目的を果たしていないことが考えられます。
このような安易な選択を起こしていないかは、目的をよく理解しているはずの人がレビューすることで、方向性が是正されます。
課題リストの傾向を見て目的とのズレを察知する
常に課題が起きたら課題リストに追加し、マネジメントされることの重要性は説明してきました。
課題のリストは、その時のプロジェクトの状況を如実に表しています。
見えていなかった部分に対する課題は後から多数出てきます。
課題が増加傾向にあったり、ある部分のみが増加傾向であったりしたときに、全体あるいは一部が目的からズレていた可能性があります。
内容を吟味して、もし目的とズレていたら手戻りしてでも軌道修正したほうが痛みが少ない可能性があるので、考えましょう。
細かいレベルで目的が追加されたときに、目的を満たしているか影響を確認する
全体としての目的としては問題ないとしても、ある一部の機能実現にあたっては、別な業務を遂行するための目的が入り込んで、そちらも実現すべきと決定されることがあります。
細かいレベルであっても、一連の業務遂行上不可避であれば、実現しなくてはならないことです。
もちろんやらなくてもいいという判断もあるでしょうが、やる必要があるということであれば、目的が追加されたことになりますので、全体をその目的の目線で見つめ直し影響がないかを確認します。
これらの確認を最初から最後まで一貫して行う
合目的性確認は作業に集中すると忘れ去られます。一歩上の目線からの確認が必要であるため、目線のレベルを変える訓練が必要です。
このようなレベル変更は頭を使うことですし、一般的にIQが高い人ができる傾向にあります。
しかし、常に合目的性確認を行えるよう、各場面で習慣化されていれば、誰でもできるようになります。
最初から実施していくよう心掛けましょう。
検証と合目的性確認におけるまとめ
検証は主に仕様どおりかという確認であり、品質のマネジメントを行ううえで必要なことです。
検証での起こりがちな問題
検証の状況を定量化して計測する場合、定量化された合格基準によって進んでいくことがあります。しかし、実際は進んでいないということが起きます。
これは主に進捗を悪く見せたくないがために起きることです。
ある時点での品質説明としてありがちなのは、何ケースのテストをしていくつ障害が出て、結果をいくつレビューしているというものです。
テストとレビューを規定数こなせば品質を保てる前提での説明となっています。ある意味間違った行為ではないのですが、先述したように、レビューアが実はよくわかっていない人であったり、テスト結果を見極められない人であったりしたら、定量化しても意味がないものになっています。
検証でのありがちな問題への対処
検証は、基準となるものや結果を確認する人が完璧であるという前提での行動となり、定量化された結果は参考にすぎません。
やはり完璧度合いを見極めないといけませんが、見えていない部分の不具合がまだ残っているということを前提に計画していくことが肝要となるでしょう。
比較的大きなプロジェクトであれば、表面的な完了としかなっていない場合は、2割は残存不具合があり、解決に倍の時間を要することを覚悟します。
検証だけでは本来の目的に達することはできない
残念ながらITにおいては特に、仕様どおりであっても仕様が間違っているということが起きてしまいます。
Vモデルと言われる検証のモデルを行っていったとしても、時間の経過とともにあるべき仕様が変わってしまうことは現実的にはあります。
この点は、マネジメントを難しくしている点でもありますし、発注しているのであれば、発注者と受注者で揉める原因となります。
発注している部分は、ある決まった範囲で品質が保たれていれば完成と扱うしかありません。
目的が変わった際には、変更として、追加が発生するのであれば認めざるを得ません。
このようにマネジメントしづらい側面がありますが、完成形が目に見えにくく、各所に影響も出やすいITの特徴からきているものです。目的のために変更を受け入れざるを得ないことは、予め計画しておかないといけません。
見えにくい完成形ではありますが、本当に有効な完成形を目指すための活動が、合目的性確認ということになります。
コメント