著者：梅田 弘之
翔泳社
章ごとに分割して投稿します
スパイラルモデルは、プロトタイプ方式ともいわれる方法である。「まず、作ってみて」というのがスパイラルモデルの特徴であるが、
だからと言って事前の計画無しで良いわけではない。
開発プロジェクトのスケジュール表を作成する際は、単に作業内容を記述するだけではなく、その作業で作成される成果物をはっきりさせることがポイントである。
例えば、
基本設計工程では基本設計書
結合テスト工程では、結合テスト計画書と結合テスト結果書が成果物となる。
プロトタイピング手法の良さは、ユーザのニーズをこまめに、取入れられるという点なので各ラウンドの中でもこまめにユーザを確認してもらいながら、
プロトタイプの作成を進めるのである。つまり、大きな節目として、3ラウンドを計画しながらその中で細やかなスパイラルが日常的に行われるのが重要である。
適正な作業の分割を行うのに、WBS（Work Breakdown Structure ）という手法が使われることがある。必要な工程、作業をトップダウンで分析し、階層構造で表現したものである。
階層の上部は機能別の分割となるが、下部になるにつれて細分化された作業が示されることになる。
プロジェクトの段階によって プロジェクトWBS フェーズＷＢＳ タスクＷＢＳに分かれる。
電化製品や自動車など日本の製造業が国際競争力が持てるようになったのは、価格競争力に優れていたこともあるが、一番の武器は品質だ。
日本のソフトウェアは体系的に品質をコントロールするという発想に欠ける。
PMBOKなおｄの米国流プロジェクト管理を盲目的に追従するのではなく、日本の強力な武器であるＱＣ/TQCの「いいとこ取り」して世界一の品質を誇れるようになる気概を持ちたいものである。
一方、近代的な品質管理では「品質＝ユーザ満足度」と定着とされる。
つまりバグが無いだけでは十分とは言えず、ユーザの使い勝手の良いシステムを提供できて初めて品質の良いソフトウェアとなるのである。
一般の品質管理活動は、プロジェクトメンバーが自主的により よい品質を目指す「品質改善活動」と全社的に一定の品質を安定して維持する「品質安定活動」の２つからなる。
プロジェクト全体の品質を改善する土壌を作り上げる。「バグのないこと」という低次元な意識から「ユーザの使う立場をイメージした」使いやすいソフトウェアを作るプロ意識を全員が持つ必要が有る。
テストを行う際には「テスト計画書」を作成し、その内容に基づいてテスト作業を行う。
テスト計画書を作成するのは大変な作業であり、どの程度細かく書くべきかの判断が難しい。
しかし、テスト計画書があればテスト漏れを防止できるし、書く行為そのものがテスト項目の整理と洗い出しにも役立つ。
「バグがなければいいなぁ」という気持ちでテストに入ると、不思議とバグは見つけられない。「絶対バグがあるはずだ」とプログラマとして自分を否定する気持ちに切り替えると面白いほどバグが見つかる。
スケジュール管理、品質管理はIT以外の他の業界（工業製品の製造業、食料品製造）でも実践されている分野だと感じました。
著者の梅田さんは20代の内は東芝で働いており、そこで品質管理や外注管理の基礎を磨いていたから本書を書く下地になったのかなと思いした。前職の経験も考えようになって無駄にならないと本書を読んでいて思いました。
最新のテクニカルなキャッチアップも大事だが、本書で紹介されている基本的な項目も習得する必要があると感じました。
特に品質管理についてはある程度しっかり掘り下げないとバグを減らすことはおろか、お客様が満足するようなアプリケーションを作るのは難しいと感じました。
他業種でスケジュール管理、品質管理をしっかりやっていた人はその点習熟してるので、ＩＴエンジニアに転職するにしても強みになると感じました。
（自分を含め苦手意識があるのか、できない人が多いので…）
・ＱＣ検定3級の資格の本を買って読む。（資格を取るとは言ってない）
・個人開発でテスト計画書を書く
・ＴＱＣの本を買って読む
Be the first to comment
