ものづくり時に目指すこと
ものづくり時に目指すこと、それは「欠陥ゼロ」です。
作ったものに誤りが1つもない、プロフェッショナル魂。
レビューで見つかるだろう、テストで見つかるだろうと、自分の責任を転嫁すること、確認を怠るのはダメ。甘いです。
後フェーズへの積み残しもダメ。もし、現時点で決まらないことがあるのなら、別でしっかり管理すべき。
不明点は必ず確認し、解決する。
自分の作ったものに、バグが1つもないことを目標として作業をすべき。
作りっぱなしでレビューに挙げるのは、プロフェッショナルとして恥ずかしい。
セルフチェックすることが重要。誤字脱字、記載漏れなど、最低限自分で摘出できるものは自分で摘出する。
その上で、レビューやテストでは、自分で思いつかないような、別視点でのバグを摘出するものと捉えましょう。
これだけやったのに、それでも見つかったものは、自分でも取り切れない、レビューやテストで見つかるものです。
完璧なものを作り上げましょう。
テストと品質
「検査（テスト）の強化が、品質改善の最善策とは見なされない」と、PMBOKでは解説されています。
なぜでしょうか？
テストは、品質を保証する行為です。
このテストをやったから、このパターンにおいては想定通りの動きをします、ということを保証しています。
品質を高くすると言って、とにかくテストパターンを増やしまくる策をとると、
同じようなテストを繰り返して、コストがかかる割には効果は薄く、
しかも実施していないパターンについては保証されないまま、ということになります。
動かすとすぐバグが見つかるようなプログラムに対して、手厚いテストを行っても、
手間ばかりかかり、結局はバグが残存してしまう、というのは容易に想像がつくと思います。
元々の品質がしょぼいと、いくら直しても、大した品質にはなりません。
そのため、品質を高くしたいのであれば、ものづくりの段階で対策を打っておくべきです。
こんな風に設計や製造をする、こんなレビューをする、といった、「計画によって」求められる品質を達成すべきです。
例えば…
・設計者に対し、事前にシステムの要求事項の説明をしておく
→要求を汲んで設計を実施することにより、要求の認識違いなどを防ぐ
・プログラマに対し、以前の開発で発生した製造バグの内容の展開をする
・開発中において発生したバグの展開を行う
→同じようなバグを作りこまないようにする
・レビューの際に、要求事項や議事録などを参照し、要求を満たしているかを確認する
→要求の実装漏れがないようにする
・あとはよくある、レビュー時間の目標値、設計・製造バグ数の目標値を定めること など。
ものづくりのフェーズに、重要なリソースや、多くの時間をつぎ込むことも大事と思います。
プロジェクトが炎上するのは、テストフェーズになってからが多いです。
ものづくりのフェーズをやっつけで何とか終わらせ、あとはテストで確認しよう、と考えているプロジェクトはとても危険です。
ものづくりの段階で、いかに品質の高いものを作るか、を意識して進めることが重要です。
その方がコストもかからず、結果的にプロジェクトを成功に導く可能性が高い、と考えます。
作りこみ時の品質を高めるには？についてはこの本。
バグはどこで生まれる？
自動車の組み立てを考えてみます。（厳密ではありませんが）
(1)車両の設計
→(2)部品の設計
→(3)部品の作成
→(4)車両の組み立て
→(5)組み立てチェック
→(6)動作テスト
→(7)走行テスト
→(8)納品
というフェーズがあったとき、不具合を作っているのはどのフェーズになるでしょうか？
正解は、(1)～(4)の、ものづくりを行っているフェーズです。
設計に誤りがあれば、最終的に出来上がる車に不具合が出てしまうし、
部品の寸法を間違えたり、組み立てるときに部品を付ける場所を間違えたりしても、車に不具合が出ます。
ですが、部品の寸法を測定したり、走行テストをしている段階では、不具合を作りこんではいません。不具合があるかを確認するフェーズとなります。
システム開発の話に戻ります。
基本的には自動車の組み立てと同様、「ものづくりを行っているフェーズ」にて、不具合が作りこまれます。
○要件定義…要件の漏れ、誤り
○設計…設計ミス、要件定義との相違（誤り）
○製造…コーディングミス、設計書との相違（誤り）
・テスト…設計・製造のミスを摘出
・ユーザ納品…要件を満たしているかを確認
バグを作りこむのは、ものづくりのフェーズだけです。
バグを発生させないようにするには、このフェーズを抑えないといけません。（予防）
ものづくり以降のフェーズは、バグがないことを検査し、是正するフェーズとなります。
また、かかるコストも「予防のコスト＜検査・是正のコスト」となることが知られています。検査よりも、予防が重要であることを示しています。
適当に作った後、一生懸命にバグを探して、せっかく作ったプログラムに修正を入れる、というのは、無駄な時間をかけているとしか言いようがありません。
せっかくなら、作るときに完璧にして、無駄な修正を入れない方がいいですよね。
品質は、作るときに高めるものです。
作るときに不具合が埋め込まれることを意識し、高い品質のものを作りこみましょう。
金メッキにならないために…
（記事：金メッキ（過剰品質）の続きです。）
では、言われたことだけやればいいの？ということが浮かんできます。
半分は正解と思います。（前の記事のとおり）
ただし、要求には「暗黙のニーズ」と呼ばれるものがあり、明文化はされていないが、やって欲しい要求というものが存在します。
例えば…画面間で使用感（ボタンや項目の位置）をそろえて欲しいなど。画面ごとにあまりにつくりが違うようだと、ユーザは戸惑ってしまいます。
暗黙のニーズも、満たされないとユーザの不満を増やし、品質が悪いと判断されてしまいます。
この暗黙のニーズを、スコープマネジメントにより、明文化することがポイントとなります。
気になることは必ず確認し、やるべきことを明確にします。
そうすれば、過剰品質にならず、要望通りの品質を満たすことができます。
暗黙かそうでないかを見分けるのはとっても難しく、微妙なところとなります。
少なくとも、自分がこれもやった方がいいのでは？と思ったところは、
リーダ、またはユーザに確認した方が、安全と思います。
勝手に直してはいけない、ということに気を付けましょう。
＊
（以下、スコープマネジメントっぽいですが、上の話に合わせて紹介します。）
実作業において…
「これを直しておくように」と言われた
→言われたののほかに、気になることがあった
さてどうする？
＜黙って直す＞
・意外に直すところが多く、時間かかる…これだけって言ったのに、まだ終わらないの？
・直している途中に、新たなバグを埋め込んでしまう
・実はもう別の人が直しており、無駄足
＜念のため、確認する＞
・一緒に直しておいて。気づいてくれて助かった！
・それは他の修正と一緒に直すつもりだったから、今はやらなくていいよ
という差が出てきます。
暗黙のニーズが存在することを理解した上で、
計画外の作業をするときは、必ず確認してからにしましょう。
金メッキ（過剰品質）
PMBOKにも出てくる、「要求以上のものを提供する」ことです。
要求を満たせないことにより、品質が悪いと判断されることを説明しましたが、
その逆、要求以上のものを提供したら、品質が良くなるのか？
答えは自明です。良くはなりません。
こんな要望はなかったけど、あった方がいいと思うから入れておこう、
として追加した機能にバグがあったりしたら逆効果…目も当てられなくなります。
そもそも、要求にないものは使われないかもしれません。
要求を満たすことにより、作業の価値が創出されます。
それ以上のものを作っても、付加価値がつくとは限りません。
品質についても同様です。
多くのPJでは、品質計画として、
「このくらいの時間レビューする」「このくらいのテスト項目を実施する」
といった指標が決められていると思います。
この指標を大幅に超えた作業をしたからと言って、その分だけ品質が上がるとは限りません。
費用対効果はどんどん悪くなっていきます。
一般的に、50→55にするコストと、90→95にするコストは全然違うといわれています。
品質計画として、「80」を目指すと決めていたのであれば、ここを目指すべきです。
これ以上は過剰品質（金メッキ）となり、納期遅延・コスト悪化の原因となります。
というわけで、PJで決められている品質計画を意識して、作業を進めることが重要です。
品質計画は、多くはコストとのバランスが取れたものであるからです。
計画で定められた指標を意識しながら、その中で最大限の効果を発揮するような作業を行っていくことが求められます。
例えば…
テストであれば、同じようなロジックを通る複数のパターンは、どれかに寄せてしまうとか、
ただ漠然とレビューするのではなく、間違えやすい点を事前に抽出し（バグ傾向などを事前につかんでおく）、そこを中心にレビューするとか。
ただ項目や時間を増やしても、品質は上がりません。
コストとバランスを取り、効果的な対策を打っていくことが必要となります。
