日経SYSTEMS 11月号のコラムは「QCDだけで評価は決まらない」です。
QCD（品質、コスト、期限）については皆さんご存じでしょう。でも、
この三つの基準を満たしているからといって，満足してはいけない。多くの場合，QCDの測定はシステムのリリース時点に行う。つまり，この三つの評価基準だけでは，ユーザーがシステムを使っているときのことを評価しないことになる。
これが大きな問題です。ソフトウェア品質モデルにあるような"利用時の品質"が測れていないと感じます。
利用時の品質とはユーザー視点の品質のことであり，ユーザーがやりたいことをいかに効率的，そして正確に達成できたかによって計る。満足度のような主観的であいまいな指標もあり，ユーザーごとに結果が異なるのが特徴である。
この利用時の品質を高めるというのは開発側の視点では分かりません。以前、僕が保守していたシステムは複雑でボタンがいっぱいありました。
そうした使いづらさについて認識していたものの，すぐに対応しなかった。機能として使えないわけではないし，そのほかの機能改善ニーズに追われていたからだ。何かの機能追加の際，ついでに手直しをしたことを覚えている。やったことは，画面上のボタンをカテゴリごとに集約し，利用目的に合わせてボタンの配置を変更する。ただこれだけである。
当然ながらたいした工数ではありません。それでもユーザーからの評価は非常に高かったのです。その経験から、僕なりにシステムへの関わりかたが変わっていきました。
システム開発にかかわるITエンジニアは，より効率の良い開発プロセス，より美しい内部構造，より正確な外部設計に向かっており，利用時の品質を置き去りにしているように感じる。システム開発の効率を高めることは重要だが，それは手段にすぎない。ITエンジニアの本来の目的は，システムを利用するユーザーの業務を支援したり，業務効率を高めたりすることである。ITエンジニアは，利用時の品質をどう改善していくのかについて，もっと取り組むべきことがあるように思う。
ここ最近、繰り返している内容ですね。もちろん、作りやすいことや拡張性は重要です。でも、それがユーザー視点になっていなければ自己満足になってしまいます。僕らはプロとしてソフトウェアを提供している。であれば、もっとユーザーとの関わりを増やしていく必要があると思うのです。
コメント (3)
「利用時の品質の置き去り感」まったくそのとおりと思います。
私も保守の作業で「画面上のボタンをカテゴリごとに集約し、業務フローに合わせて並べる」ことで、ユーザからの評価を頂いた経験があります。
昨今「ＱＡ」の名の元に、後付けの苦しい品質分析に、周りの仲間達が悩まさせれています。
大規模のS/Wであれば、品質のメトリクス値はある種の傾向を示し、その意味が見出せるのではないかと考えています。でも多くのS/Wは、そうではないかと・・・。
数年、この業界に身を置いてますが、画面を持つ情報システムのユーザーの興味は、
結局のとこ「見た目」と「性能」の２つかなーと思います。極論ですが。(笑)
そこの評価を超えないと、本質的なユーザニーズの評価、すなわちどこまでS/Wがビジネスに貢献したかの評価まで、たどり着けない、たどり着かせてもらえないなーと考えてます。今までの経験から、ですが。(笑)
話しが脱線しそうなうなので、戻します・・・。
「ＱＣＤ」や「開発プロセス」「ＱＡ」などは、とても重要と思ってます。でも鈴木さんのおしゃっるとおり「利用時の品質をどう改善していくのかについて，もっと取り組むべき」というのも重要であること、改めて認識しました。
素直に内容に共感してしまったので、突然ですが、コメントさせて頂きました。
投稿者: きむたか | 2009年11月02日 02:06
日時: 2009年11月02日 02:06
きむたかさん、コメントありがとうございます。
仰るとおり"結局のとこ「見た目」と「性能」"ですね。これを超えてこそ評価が得られる気がします。逆に言えば、超えさえすれば、得られることも多くなる気がしています。
共感ありがとうございます。これからもよろしくです。
投稿者: yusuke | 2009年11月04日 13:47
日時: 2009年11月04日 13:47
美しいアーキテクチャとか、洗練された設計とか、それを利用して効率化した時間を、ユーザとの対話、インタフェースの改善のために使いたいと思うのです。
後者は、効率化しないことで、効果が大きくできますというか、効果と効率がうまくあわない。
あう部分は、さっさとやる仕組みを考えて実施してみせるのが、プロとしての技術者の技の見せ所かなと。
投稿者: holic | 2010年03月02日 15:33
日時: 2010年03月02日 15:33