2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

この記事は

過去の自分に教えたい、ソフトウェア品質の心得を投稿しよう by QualityForward Advent Calendar 2024 に参加しています。
(遅刻してすみませんでした)

それを書く私は

  1. ソフトウェアエンジニアとして働くようになって「プロジェクトがうまくいかないのは【おかしい】」と思い
  2. プログラムを作る技術はあるのに、それでも品質問題でプロジェクトがうまくいかないなら、品質を何とかする技術が必要なんだと思い
  3. テスト技法やら定量化手法やら、小手先の技術を勉強し
  4. もっとプロセスよりの問題だと気づいて品質プロセスを勉強しはじめる

といった過去を持つ者です。

はい、2~4あたりの自分を想定した記事になっております。

品質ってなんぞや

かの狩野先生(ダジャレじゃない)が説明されている動画がこちらです。

うまく聞き取れなかったところは巻き戻したり、古すぎる笑いポイントは聞き流したり、しながら5回ぐらい視聴すると凡人の私でも「何となく」わかった気がします。

上の動画ではとっても大事なことが山ほど語られているのですが、
今回の記事で大事なのは

  • 「品質とは "ふたつ" の比較から生まれる」ので、比較対象がないと品質は語れない

という点です。

何を作るかが決まらないと品質も決まらない

「いま作っている/作ろうとしているモノの品質」を語るためには比較対象が必要です。

大抵のソフトウェア開発では
プロジェクトを立ち上げる前かプロジェクトの初期で「何を作るか」を決めています。
なので、「いま作っているモノの品質」を知りたいとき、
「いま作っているモノ」と「作ると決めたモノ」の比較をすることになります。

ということで、「何を作るか」を決めるのが大事です。

 

……。

 

この段階で納得しないでくださいね?

「何を作るか」は比較可能か

比較というのは、対象が同じ評価軸の上に乗っかっているのが大前提です。

レシピに「ジャガイモ(大)2個」としか書いてなかったとき、
あなたの手元にあるジャガイモのどれをどれだけ使うか悩みませんか?
手元のジャガイモは大きさなり重量なりを計れますが
レシピの「大」は同じ軸にないから比較しようがないですよね。

翻って
①「いま作っているモノ」を表現している指標

②プロジェクトを立ち上げる前かプロジェクトの初期で決めた「何を作るか」の表現
って
比較可能ですか???

この記事では①を「(開発中に使う)品質指標」、②を「要件」と名付けましょう。

要件を考えるとき、
大抵のプロジェクトでは、ビジネスや実現性のことを考えていると思います。
要件を定義する人達はプロジェクト完了後に得られるモノにフォーカスしているので
プロジェクトの真っ只中のことまで気を回している余裕がありません。
「要件定義書」は、開発途中に使う品質指標と比較できない文章で書かれているか、
偶に品質指標が出てきたとしても、開発中「それだけで事足りる」には足りません。

「品質計画」で比較可能にする

レシピに「ジャガイモ(大)2個」と書いてあったら。

  • そこそこ料理の経験があり、かつ、自分一人向けの料理で、加熱済みだったら量も味も不問である!というときは、手元のジャガイモから適当に選んで使ってしまいますね。
  • その料理の熟練者だったら、今までの経験から多分こんなものという量がわかっているので、手元のジャガイモから適当に選んで使ってしまいますね。
  • 初めて作る料理で、人に提供するから「ふつーにおいしい」はクリアしたい!てときは、多くの人は「ジャガイモ 大 重さ」とかでググったり、今なら「はろーぐーぐる、ジャガイモ大の重さを教えて」なんてやるんじゃないでしょうかー。そして手元のジャガイモを秤に乗せて、ちょうど良さげなものを選びますよね。
     

ソフトウェア開発は毎回あたらしいものを作るので、かつ、ビジネスなので失敗もしたくないので、大抵のプロジェクトでは、3番目と同じで、比較対象が同じ評価軸に乗っかるようにします。

それが「品質計画」です。
 

品質計画の具体的なやり方、品質計画書とはこういうもの、という情報は
世の中に山のように良い情報がありますので(無数の玉石混交の中に)
そっちを見てください。

そして、沢山の情報や、肌馴染みのない単語に埋もれて「品質計画って難しいし、何かアカデミックで使いこなせる気がしない」と思ったら。
いろんな情報をそぎ落として、以下だけ頭に残してください。

品質計画は「いま作っているモノ」と「作ると決めたモノ」の比較ができるようにすること

その目的がブレなければ、たぶん、「じゃあ何をするの?」「じゃあいつやるの?」といった疑問を解消していく内に、品質計画っぽいのができていると思います。

「自分たちが比較できるように」を忘れなければ、使わない/使えない品質計画になることもないでしょう。

ソフトウェアエンジニアとして責任感があれば、ちゃんと作れているかな?という不安は常に湧くでしょう。
手を動かし始めたら直ぐに比較したくなるハズです。そのときに「品質計画がなかったら比較できない」と覚えていれば、プロジェクトの初期に「品質計画ほしい!」てなると思います。

そして。
「いま作っているモノ」をどれだけ適切に比較できるかは、品質計画の質によります。
作っている最中に適切に評価できれば、リリースするものがおかしなことになることは、大抵はありません。

はい、タイトル回収しました。

おわり。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?