ソフトウェア品質向上活動を分類した4レベル、今どのレベルですか？
講演や発表での事例、エンジニアコミュニティでの事例や雑談、ブログ、tweet, facebookを見聞きしていると、ソフトウェア開発の目的やソフトウェアの品質向上活動をいくつかのレベルに分けられるのではないかと感じていました。
講演の機会をいただいたので、これまでの私の考えを少し整理して、以下のとおり4+1レベルに分けました。タイトルとアブストを考えた時点では3レベルとしていたのですが、4+1が説明がしやすいと思い、変更しました。セッションの主旨がソフトウェア品質に関するものなので、品質向上活動としていますが、ソフトウェア開発の目的と考えることもできます。
レベル1: 開発関係者が各々の考えで品質向上活動を実施している
開発中のソフトウェアに求められる品質を共有できておらず各々の考えで取り組んでいる状態。使い勝手が最優先と考えて、ユーザビリティの向上に時間を使っているメンバもいれば、保守性が大事と考えてドキュメントやソースコードの保守性向上に時間を使っているメンバもおり、合意していない、合意しようとしてできていない状態です。
レベル2: 開発関係者の間で品質向上活動が合意できている
開発中のソフトウェアに求められる品質が合意できており、関係者がその向上につながる活動をできている状態です。「このソフトウェアに求められているのはスループットと可用性」「このソフトウェアに求められているのは使っているときの心地よさ」といったレベルで大まかに求められている品質が合意でき、それを詳細化した上で活動できている状態です。実際にその品質が実現できているかどうかは、ここでは厳密には求めず、合意ができているかどうかという点に着目します。
レベル3: 品質向上活動が特徴づけられている
レベル2に加えて、どうすればその品質が実現できるかが開発活動、体制、コストをはじめとする状況や環境と関連づけられている状態です。たとえば、メモリ等の計算機リソースが厳しい環境での開発が求められる品質だとします。そして、開発関係者の間でそのことが合意できており、システムテストでの調整が難しいことがこれまでの実績からわかっており、レビューで検討しながら開発していくことが重要であることがわかっているとします。ここまでがレベル2の状態です。レビューでの指摘が本質的で品質向上に大きく寄与している主要因が、他メンバや同僚への支援が人事評価の対象となっていることがわかっている状態がレベル3です。もちろん特徴づけが間違っている可能性もありますが、因果関係が説明できるか（成功要因が明らかになっているか）どうかという点に着目します。
レベル4: 品質向上活動が特徴づけられており競争力になっている
レベル3に加えて、その品質が他への優位性となっている状態です。レベル3で挙げた限られたリソースで動作するプログラムが他ではマネができず、顧客やユーザが求める主要な品質になっている場合にはレベル4になります。レベル4は活動としては同じことをしていたとしても、他の状況によってレベル3になることがあります。先の例だとリソースが潤沢なハードウェアが安価で提供されるようになると競争力としては成り立たなくなる可能性があります。
2012/10/26のソフトウェアテストシンポジウム北海道の講演では、それぞれのレベルの事例とレベル間の移動を解説します。振返りや見直しのきっかけになれば幸いです。アブストラクトはこちらから。申込みは10/19まで。申込みはこちらから
そしてもう一つ2012/10/25 15:30から札幌HBA本社ビルで、メトリクスの原理・原則と表層的なメトリクスにならないための考え方や事例を紹介します。事例4件には、研究グループの仲間と一緒に私が苦労したものを含めています。タイトルは、「ソフトウェアメトリクスの活用事例と国際研究動向」。日経SYSTEMS 2012年5月号に寄稿した3種類の考え方も踏まえ、ご参加者とディスカッションできればと思っています。
研究テーマとしてのメトリクスは主要な柱の1つで論文も多いのですが、実務者向けのメトリクスの講演は少なく、今回のために構成を練りました。こちらも濃い内容になっていると思います。本セミナーは北海道、札幌でITエンジニアのコミュニティを引っ張ってきた安達氏のセミナー事業を応援したくて私からお願いしました。タイトルと概要、申込み方法はこちらから。