DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

menuclear
ホーム > ブログ > 工藤 武久の記事一覧 > 【第62回】できていますか?レビュー指摘分類のルーティン化


【第62回】できていますか?レビュー指摘分類のルーティン化

Pocket

ご訪問ありがとうございます!          < 前回 | 目次 | 次回 >

ラグビー・ワールドカップの初戦、日本代表は優勝候補の南アフリカ代表に逆転勝ち、世界中を驚かせました。五郎丸歩選手がゴールを狙う際に行う「ルーティン」に注目が集まり、ビジネスの世界でも「ルーティン」効果により、成果をあげようという機運が高まっていることと思います。(※1)

昨今では、システム開発を行う多くの組織で、レビュー記録票の標準フォーマットが整備され、レビュー指摘分類を記入できるようにしています。ということは、設計品質分析に欠かすことのできないレビュー指摘分類が「ルーティン」化されてきたと考えても良いのでしょうか。。。

 

【 品質確保の基本3原則 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
実は、今回のテーマであるレビュー指摘分類をたとえるメタファーとして最初に思い浮かべたのは、ゴミの分別でした。通勤電車の車内モニター広告で、発展途上国の子供たちにゴミの分別の大切さを啓蒙している映像を何度か見かけました。プラスチックゴミを石油に戻してエネルギーとし再利用できることを目の前で示すことで、ゴミの分別の「ルーティン」化を図ろうという試みです。この映像を見て、私はシステム開発におけるレビュー指摘分類を連想したのです。

レビュー記録票に記録されるレビュー指摘には、「要件の抜け漏れ」のように放置されるとシステムの不具合につながるものだけでなく、単なる「誤字・脱字」であったり、設計書の記載内容に関する「質問」であったり、実にさまざまな内容が含まれています。

それらの指摘を分別、いや分類せずに、ごちゃまぜにしたままレビュー指摘密度(1ページ当たりのレビュー指摘件数)を算出しても、効果的な品質分析ができないのは明らかです。レビュー指摘密度やレビュー指摘分類による品質評価の有効性をプロジェクトメンバーに示すことで、レビュー指摘分類の大切さを印象付け、レビュー指摘分類の「ルーティン」化を図ることは、組織としての設計品質向上策として有効な活動です。

さて、ゴミの分別に関しては、環境と経済が両立した循環型社会を目指すための「3R」という考え方があります。「3R」とは、1.リデュース(Reduce:ゴミの発生抑制)、 2.リユース(Reuse:再使用)、 3.リサイクル(Recycle:ゴミの再生利用)の3つのキーワードの頭文字をとったものです。(※2)

この「3R」からヒントを得て、システム開発の品質確保のための基本原則として、以下の3つがあげられるのではないかと考えてみました。

< 品質確保の基本3原則 >

1. 不具合の混入抑制
⇒ 設計書やシステムへの不具合混入を抑制する活動

2. 不具合の類似見直し(横展開)
⇒ レビュー、テストなどで摘出された不具合と同種の不具合が他にも残存していないかを調査し、対策する活動

3. 不具合の再発防止
⇒ レビュー、テストなどで摘出された不具合と同じ原因による不具合の新たな混入を予防するためのプロセス改善など

レビュー指摘密度やレビュー指摘分類などによる品質分析は、これらの3つの活動につなげるためのものです。「3R」が効率的に回るためにゴミの分別の「ルーティン化」が欠かせないのと同様、「品質確保の基本3原則」が効率的に回るためにレビュー指摘分類の「ルーティン」化も欠かすことができないのです!

 

【 レビュー指摘分類は、まだ未成熟? 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
皆様の組織では、レビュー指摘分類はどんな分類を用いているでしょうか?よく見かけるレビュー指摘分類としては、指摘内容(記述漏れ、記述誤り、記述があいまい・・・)とその原因(理解不足、検討不十分、ケアレスミス・・・)の2種類の分類を記録するようなものが多いかと思います。

これらのレビュー指摘分類を見ていると、なんとなく設計書を書く担当者の作業を中心にしたもののように思えます。テスト工程におけるバグの分類(現象、原因、混入工程など)に比べて、なんとなくゆるい感じを受けます。上流工程の重要性が唱えられているにもかかわらず、なかなか設計レビュー指摘分類を用いた品質評価は浸透していない、まだまだ未成熟なように感じています。

その原因はいろいろ考えられますが、やはり実装されたシステムを動かしてみて検出されたバグに比べて、まだ実装されていない設計書に対してレビュアという人間が指摘したレビュー指摘は、レビュアの主観が入り込みやすく、あいまいなものという印象が強く、わざわざ時間をかけて分析をしてもそれほど効果が出ないという考え方が根底にあるように思います。

レビュー指摘の分類、品質分析に多くの時間をかけるよりも、設計書そのもののレビューにもっと時間をかけて、少しでもたくさんのレビュー指摘を出すような活動をした方が品質が良くなると考えている人が、まだまだ多いのではないでしょうか?

そもそもレビューは設計工程の終盤にまとめて実施するという古典的なプランニングをしていた場合は、確かにレビュー後に品質分析を行って、さらにそのフィードバックを行っている時間的余裕などまったくありません。品質分析だけしておいてフィードバックをしないとしたら、レビュー指摘を分類する意味はあまり見いだせません。形式的な品質評価のためのレビュー指摘分類など、いっそやめてしまった方が良いでしょう。

設計工程での品質評価結果を後続工程のプランニングのインプット情報として使うという考え方もあるかもしれませんが、ウォーターフォールモデルの場合は各工程で所定の品質を確保してから次工程に進むというのが大前提なので、その考え方はあまり推奨できるものではありません。前回のブログで示したように、その工程内で品質管理のPDCAサイクルがしっかりと回るように、各工程のプランニングを行う必要があるのです。

 

【 レビュー指摘分類にJIS品質特性、副特性を使ってみる 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
各設計工程内で品質管理のPDCAサイクルがしっかり回るようなプランニングが出来たとして、まだまだ未成熟のように思えるレビュー指摘分類をどう見直していけばよいのでしょうか?

私からのご提案は、JISの品質特性、副特性を活用したレビュー指摘分類です!(※3)

前回のブログ 【第61回】レビューチェックリスト地獄からの脱出大作戦! では、品質マネジメント計画書に、各設計工程で作りこむべき品質特性の全体像を整理したうえで、各工程開始時にその工程でカバーすべきとした品質特性を中心にレビュー観点をブレークダウンしたレビューチェックリストを作成することを推奨しました。

JIS品質特性、副特性は、品質の多面性をうまく分解して表現している概念だと思います。この概念を実際のプロジェクトにも適用しようという試みとして、品質マネジメント計画書やテスト計画書などに登場しているのを以前からよく見かけたことがありました。しかし、実際の設計、テスト工程を進める場面では、JIS品質特性、副特性を効果的に活用している事例をあまり見かけたことはありません。。。

そのようなもやもやした思いを持っていた中、数年前にプロジェクトマネジメントのご支援の一環として設計工程におけるレビュー品質分析を行う機会があり、JIS品質特性、副特性をレビュー指摘分類に活用できないかとお客さまと一緒に考えて適用してみたのです。

適用方法はシンプルで、レビュー記録票のレビュー指摘分類をJIS品質特性、副特性の分類に置き換えただけです。ただし、「合目的性」、「使用性」・・・など、そのままの用語だと、レビュー記録票の記載者がその意味を取り違えるかもしれないと考え、それぞれの分類名をかみくだいた表現にしたり、それぞれの分類の意味や具体例なども補記してレビュー記録票の別紙として添付し、いつでも参照できるようにするなどの工夫も行いました。

< レビュー指摘分類にJIS品質特性、副特性を活用するメリット >

1.品質の多面性について、設計担当者やレビュアに意識付けできる

2.レビュー観点とレビュー指摘分類を対応づけることで、品質評価活動に一貫性を持たせることができる

3.業界標準の考え方を活用することで、異なる組織間で品質に関する共通認識を持ちやすくなる

4.これまでの設計担当者の作業に着目した品質分析から、設計内容そのものに着目した品質分析へのシフトが可能になる

これらのことが全て狙い通りの成果に結びついているかどうかは、長期的に経過観察していく必要があり、現段階ではまだはっきりした答えは出ていないかもしれません。しかし、上流工程の品質向上のためには、レビュー指摘分類を効果的なものにする取り組みがまだまだ必要ではないかと思います。そのひとつの方向性として、レビュー指摘分類にJIS品質特性、副特性を活用することをお試しいただけたらと思います。

「レビュー指摘分類にJIS品質特性、副特性を活用してみよう!」

そして、テスト工程におけるバグの分類と同じように、レビュー指摘分類がどのシステム開発組織においても「ルーティン」化されるように、我々としても啓蒙活動を続けていく必要があるということを、このブログ執筆を通してあらためて認識致しました!

それでは次回もお楽しみに!          < 前回 | 目次 | 次回 >

工藤武久

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
応援してくださる方は、クリックよろしくお願いします!
◆ 人気ブログランキング
◆ にほんブログ村
~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~

※1 「五郎丸歩」『フリー百科事典 ウィキペディア日本語版』
2015年2月8日 (日) 15:57 utc https://ja.wikipedia.org/wiki/五郎丸歩

※2 「3R」『フリー百科事典 ウィキペディア日本語版』
2015年2月8日 (日) 15:57 utc https://ja.wikipedia.org/wiki/3R

※3 「JIS品質特性、副特性」については、以下参照。
・「ISO 9126」『フリー百科事典 ウィキペディア日本語版』
2014年7月16日 (水) 13:57 utc https://ja.wikipedia.org/wiki/ISO_9126


| 目次
Pocket

採用情報
PM-waigaya
PM-WaiGaya
コンサルタントのトーク動画
PM Weekly Talk
PM Weekly Talk
コンサルタントが語る「PMBOK®12 の原理・原則」

Profileプロフィール

Avatar photo
工藤 武久
■株式会社アイ・ティ・イノベーション  ■コンサルティング本部 - 東日本担当 ■学歴:早稲田大学 - 第一文学部卒業 ■メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、SE、PMとして携わる。立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトの幅広い実務経験を重ねた。 ■2007年より株式会社アイ・ティ・イノベーションにおいて、大規模プロジェクトにおけるプロジェクトマネジメント支援や品質管理支援等のコンサルティングを手がける。 ■PMP、情報処理技術者試験(プロジェクトマネージャ、システム監査技術者他)など。 ■Twitter:https://twitter.com/iti_kudot  ~・~・~・~・~・~・~・~・~・~ ■ ブログランキングに参加しています! ◆人気ブログランキングにほんブログ村 ↑是非応援(クリック)お願い致します↑ ~・~・~・~・~・~・~・~・~・~ ■主なタグ:統合, スコープ, タイム, コスト, 品質, 人的資源, コミュニケーション, リスク, 調達, ステークフォルダ

Recent Entries最近の記事