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

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

夏の甲子園も終わり、すっかり秋めいてきました。我が家では長男の高校野球が終わり、少し一息ついて、世界陸上や女子バレーなど、野球以外のスポーツをテレビ観戦する余裕が出てきたような気がします。

最近はトップクラスのスポーツ選手の中でも、モデル並みのスタイルやルックスを兼ね備えた選手も多く、実際にプロのモデルとして活動する選手もいます。プロスポーツは集客力が必要なため、実力だけでなく見た目も重視されるのは当然の流れです。

そして、、、もちろん、システム開発のプロジェクトでも、見た目は大事ですよね！？

【　情報システムも見た目が9割？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
以前、竹内一郎氏の『人は見た目が９割』という著書が大ベストセラーになったのを覚えているでしょうか？当時はこのベストセラーにかこつけて、なんでもかんでも「見た目が９割」とつけるのが流行しましたよね。（※１）

日経コンピュータでも、「情報システムも見た目が９割」という特集記事を出していました。タブレットやスマホなどの普及に伴い、システムがユーザーに受け入れられるためにはユーザーインターフェースを重視する必要があるといった感じの記事だったと思います。（※２）

システムの品質に関して最近よく言われる「魅力的品質」が「当たり前品質」よりも重視されるようになってきたということかもしれません。ちなみに「当たり前品質」とは、システムダウンしたり誤作動したりしないといったレベルのことで、充足されているのは当たり前であり、充足しなければ不満を感じる品質要素とされます。これに対し「魅力的品質」とは、それが充足されると満足感を感じるが、充足されなくとも不満を感じない品質要素とされます。たとえば砂時計アイコンの代わりにボルト選手が走っている風のアイコンを表示して、待ち時間を飽きさせないようにするとか。。。（※３）

しかし、充足されなくとも不満を感じないということは、エンドユーザーの要求仕様や期待値としては含まれていないことだと思うので、「魅力的品質」という考え方はベテランのＰＭやＳＥにとっては「過剰品質」であるとか、品質ではなく等級（グレード）のことであり、現実のプロジェクトではそんなもの関係無いと感じる人もいると思います。（※４）

確かにボルト選手のアイコンを作る余裕があるなら、トリアージで削減した業務機能を少しでも復活させて欲しいと思う人も多いかもしれません。やっぱり、品質って本当に難しいですね！（※５）

【　設計品質の評価方法　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
上流や超上流工程の重要性が唱えられるようになって久しいですが、真の要求を分析してソリューションを明確化するためのプロセスも大事ですが、出来上がった設計書の品質をしっかり評価して、品質を改善していくという品質管理活動も大事です。（※６）

実装されたシステムの品質の評価は、テストで摘出されたバグの量と質を分析するという方法が一般的です。設計書の品質評価も、これと同じような考え方で、設計書のレビュー指摘の量と質を分析する方法がとられることが多いと思います。

上流や超上流工程でどんなプロセスを採用したとしても、設計書は人手で作ることに変わりはなく、いろいろな原因でいろいろな不具合が入り込みます。設計書のレビューを通して、できるだけ全ての不具合を無くしたいので、いろいろな視点、つまりレビュー観点を設定して、レビューを実施します。レビュー観点の漏れを無くすために、ＪＩＳの品質特性などを活用することもお薦めです。

テストにおけるバグ密度と同じように、設計書のレビュー指摘密度を算出し、あらかじめ設定していた基準値と比較することで、不具合がどれくらい混入しているかを評価します。バグ密度はバグ件数をテスト対象規模（ＦＰ数やステップ数）で割って算出することが多いと思いますが、レビュー指摘密度はレビュー指摘件数を設計書のページ数で割って算出するのが簡単でわかりやすいと思います。

また、どんな種類のレビュー指摘が多いかを分析することで、どの品質特性が弱いかを把握して、その原因を追究して対策を打つことで、設計品質の改善を図ります。

【　設計書の品質も見た目が９割？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さて、図３では、不具合の内容として誤字脱字のレビュー指摘が多い傾向が見て取れます。せっかく有識者が時間をかけてレビューをしているのに、肝心の設計内容が十分チェックされずに設計書のあら捜しに終始してしまっていると、設計品質は向上しません。したがって、誤字脱字や単なるドキュメンテーションの誤りは、レビュー指摘密度のカウント対象外とすることも多いと思います。

レビュアの心情としては、レビュー対象の成果物に誤字脱字がたくさんあると、それが気になって設計内容を見る気が薄れてしまう傾向があると思います。まずは誤字脱字をなくしてきれいにしてから本格的に中身を見るほうが効率的だと考える人もいるはずです。

しかし、レビューを受ける側としては、誤字脱字の修正を含めたドキュメントの整形は、最後の最後にしたいと思う傾向が強いのです。なぜなら、時間をかけてドキュメントをきれいにしても、レビューで大幅に修正が入ってしまうと、再度別の文章を書かなければならず、文章をきれいにする時間が無駄になると考える傾向にあるからです。

かくして、レビュアは早く形式レベルの指摘を無くして中身に入りたいために、一生懸命誤字脱字などの体裁チェックを行うことになり、レビューを受ける側は体裁ばかり指摘されるレビューに意義を感じなくなり、いくら時間をかけてレビューしてもいっこうに設計品質が良くならずに時間ばかりが経過して、最後は時間切れでレビュー不十分のまま実装に進んでしまうという悪循環に陥ることになります。

また、レビュアから見ると、誤字脱字が多いドキュメントというのは、作りっぱなしでしっかりと内部レビューされていないと感じると思います。それに、設計書のケアレスミスが多いということは、肝心のプログラミングやテストにもケアレスミスが多いことを連想するため、ベンダーに対するけん制の意味でも設計書の体裁をしっかりさせるのは当然ということになります。

このようにして、いつまでたっても発注側と受注側の溝は埋まらないことが、上流工程の品質が上がらずにプロジェクトが失敗するひとつの要因になっていると私は考えています。

設計書は、システムの要求仕様や機能を定義し、発注側と受注側の間でしっかりと相互確認すべきものであり、かつ、オフショアなどに開発を委託する際にも重要なインプット情報となるため、認識齟齬が生じないように体裁（見た目）も含めてしっかり作成する必要があるはずです。ただし、見た目を良くするためには、当然時間やコストもかかるものだということもしっかり頭に入れて、スケジュールや予算を組み立てる必要があると思います。

「プロジェクトを成功させるためには、設計書の見た目を良くする工夫が必要だ！」

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

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

※１　竹内一郎(2005)『人は見た目が9割』（新潮新書）

※２　『日経コンピュータ』2008年2月15日号、日経BP社より
・P044　特集１「情報システムも見た目が9割」

※３　狩野紀昭, 瀬楽信彦, 高橋文夫, 辻新一(1984) 「魅力的品質と当たり前品質」,
『品質』, 14, No.2 pp39-48

※４　品質と等級の違いについては、PMBOKガイドに以下のように記されています。

品質と等級とは、同じ概念ではない。（中略）等級とは、設計上で意図されるものであり、同一の用途であっても技術的特性が異なる成果物に定めた区分のことをいう。プロジェクト・マネージャーとプロジェクト・マネジメント・チームは、要求されるレベルの品質と等級を実現するためのトレードオフをマジジメントする責任を負う。品質要求を満たすことのできない品質レベルは常に問題であるが、低い等級が問題になるとは限らない。

・Project Management Institute, Inc.(2013)『プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）』（第5版）Project Management Institute, Inc.

※５　「トリアージ」については、当ブログの以下の回も参照してください。
・【第３９回】トリアージでデスマーチを脱却せよ！
・【第４０回】膨張するプロジェクトとトリアージ依存症

※６　「超上流工程」の重要性については、竹内博樹氏の以下ブログをご覧ください。
・特集　バックナンバー – PM+BAの実践講座