SPPS お問い合せ
HOME 事業内容 会社案内 採用情報 特別連載 活動報告
活動報告

INDEX
2010.04.22
満足のいくECサイト構築
 − 成功の7つのポイント −
2009.11.20
プロセス改善によるソフトウェアの品質向上
Event & Seminar 活動報告
プロセス改善によるソフトウェアの品質向上

2009年11月20日、トーマツイノベーション株式会社様・ジャパニアス株式会社様との三社共同取り組みの一環として、「ソフトウェアの品質向上とプロジェクト管理について」というセミナーが開催されました。
その中でCTO 岡田篤彦は「プロセス改善によるソフトウェアの品質向上」というタイトルで講師を務めました。

今回は、セミナーでお話したことの一部をご紹介致します。


◆はじめに

テストで発見された不具合の65%以上が実装前の設計工程に起因すると言われています。
一方で、最大で80%までの不具合がレビューで検出できると言われています。そして、あるデータでは、不具合が後工程で見つかった場合、約450倍の改修コストが必要であると報告されています。

◆「終わりました」

よく「設計が終わりました」と言いますが、「終わりました」とはどういった事を指すのでしょうか。

何をもってして「終わった」と言うことができるのでしょうか。それにはもの作りにおける工程そのものを検証していくという考え方を持つべきでしょう。

グッドイナフという考え方があります。つまり、足りていれば良いということです。

足りているとは、調和が保たれているか、ということになるでしょう。

いわゆるV字モデルにおいて、後工程だけテスト過多となっている事が多いのですが、それでは調和が保たれているとは言えません。

皆様が現場で感じる「きな臭い」といった嗅覚のようなものは、直感的にこの調和が取れていないという事を感じているのではないでしょうか。

「開発側での確認が終わりました」
なんとなく「終わりました」ではなく、自分達の意思を入れた物であるべきでしょう。
手法としてはレビューやペアプログラミングなどが挙げられます。

「単体テストが終わりました」
誰が終わりを宣言したのでしょうか?なぜ?どうしてそう思ったのでしょうか?
そもそも何をどの程度実施するのか、という事を決めておかなければ「終わった」と言えないはずです。

つまり、どんな約束事があって、何をクリアすれば終わりと言えるのか、ということに合意がなされていないといけません。

私もオフショア開発のプロジェクトの検証において、この「終わりました、できました」という事に特に注意を払っていました。
「どうやって作ったのか」「どうやろうとして、どうしたのか」について常にチェックしていました。

プロジェクトにおいて重要なことは、作業の話なのではなく、何がどんな状態で出来上がっているか、ということです。逆に、いつにどのくらいの状態で、が判っていれば良いとも言えます。

また、Know How+To Doを分けて考えることが重要です。

プロジェクトとはラグビーボールのように不安定なものです。このような状態では良い品質の物ができる訳がありません。Know HowとTo Doでプロジェクトを両脇から支えるように、安定させることが必要です。言い換えると、To Doだけにならないこと、が重要になります。

◆品質向上は地味な積み上げ

ソフトウェア品質の向上は、例えば基本機能の動作確認→相互動作確認→信頼性確認という風に積み上げで行っていきます。

SPPSでは、品質は回復→向上→確保の3ステップで上げていくものと定義しています。

常にバグを出すことが重要なのではなく、何を狙ってテストを行うのかを定めて行うことが重要です。そうでないと、よくある話ですが「検証」がバグの発見のみで終わってしまいます。

以下に各ステップの概要を示します。

1.品質の回復
  ・普通の機能が普通に動くようになる事
2.品質の向上
  ・相互動作ができる、信頼性が高い
3.品質の確保
  ・テストを行うが、バグを見つけるのではなく、
   問題が無い事を確認する
  ・システム、プロダクトとしての調和は大丈夫か?
  ・限定的な状態での動作を保証する
  ・この範囲では大丈夫、という見方をする(「全部大丈夫」なんていうのは夢)

◆現状を打破する、SPPS的解決方法

現場(プロジェクト)では[有識者]と一緒に業務を行う事が重要です。

よく第三者検証を説明するときに「ユーザー目線」という言葉を使う方がいらっしゃいます。
しかし、これはたいへん危うい言葉である、と私たちは考えています。

JIS X 0129-1(ISO9126-1)によりますと、

  1.利用者が自分の真の必要性に気づいていないことがある
  2.必要性は、明示された後に変わることがある
  3.異なった利用者は、異なった運用環境をもつことがある

とあります。

そう考えますと、ユーザー目線という言葉は実に曖昧で危うい定義であると言えます。
仮にユーザー目線ということを考えるのならちゃんとした定義が必要です。決して、ユーザーに近い人を適当に集めて何かテストをすることではないはずです。それでは第三者検証ということはできません。

SPPSはこのような第三者として作業する「テスト会社」ではありません。あくまで専門的な第三者として、検証のプロとして、プロジェクトに対し、提案や分析を行っています。私たちはプロジェクトの利益代弁者である、とも言えます。


◆終わりに

「秘策」というタイトルのもと、ここまでお話をしてきましたが、ローマは1日にして成らず。プロセス改善は簡単なことではありません。しかしながら、すぐに実行でき、効果の高い事として以下のことを挙げさせて頂きたいと思います。

・ゲートを設ける
・Know HowとTo Doを分けて考える
・「足りないものは何だ?」というアプローチをとる
・「計画は変更していいのだ」という意識で臨む
・ユーザー目線という素人な話をしない

ご静聴ありがとうございました。


SPPS 岡田篤彦

活動報告トップページへ

Page Top
プライバシーポリシーCopyright(c)2005 SPPS-Inc, All Right Reserved.