軽く設計書とおっしゃっていますが、何設計書の話をしておられますか。
まさか基本設計書のことをおっしゃっていませんね。
もしバグ程度の対処で基本設計書に対応しなければいけないなら、全体の工程がおかしいと言うことになります。
設計工程が、きっちりブレイクダウンしていないということです。
たとえば、何かのパラメータを保持していなければならないという対処だとしましょうか。
このとき、もし基本設計書に記載が必要ということであれば、基本設計にそのパラメータが関係する記載があると言うことになります。
だったら、そもそもその基本設計書はろくなものではないという判断をせざるを得ません。
基本設計からやり直しです。
普通は基本設計は、どのような動きをするシステムを目的とするということしか書いていないはずですから、細かい動きなんかは指定していません。
プログラムのバグというのが影響するのは、外部設計書以後です。
そのパラメータをDBに保存しておかなければならないということになるなら、外部設計書を修正する必要があります。
パラメータの更新タイミングが間違っていたのであれば、内部設計書の記載の修正になります。
もっと生のプログラムレベルの話、初期化を忘れていたとかインスタンスを生成させずに参照したというような話は詳細設計書になります。
また、バグという見方はよくない。不具合、です。
テスト工程でよく「バグ発見」と言いますが、これは間違いですよ。
テスト者は「おかしい」と思うのです。それをレポートするのですから、不具合報告です。
不具合の中にはバグも入っていますが、そればかりではありません。
「非バグ」をきっちり見て整理できないようなプロジェクトは究極の信頼は勝ち取れません。
テスト者の操作ミスもありますし、システムへの誤解で指摘を間違えることもあります。
このときは「指摘ミス」と言うことになります。
こういう指摘ミス、を捨てて記録しない人がいるのですが、明らかに間違いです。
指摘ミスをしたというのは事実ですから、それがあるならマニュアルに記載することを検討すべきです。
ユーザー様もやる可能性があるわけです。
指摘ミスが、なんとなくシステムをこう考えてしまうというものであれば、これは基本設計上レビューをしなければ行けないことになります。
指摘はあったが「仕様通り」という場合もあります。
たとえば入力は常に数字であるというエリアでアルファベットを叩いたらプログラムが落ちたとかいうことがあったとします。
仕様ではそこは数字でなければならない、だから数字以外の入力をしたらユーザーのせいだ、と言えますか。
これは、たとえばHTML5で画面を作っていたら入力チェック属性を与えてガイドをすべきではないですか。
プログラム固有画面なら、そのエリアでのキー押下で['0'..'9']以外は受け付けないコンポーネントを作りnumentryというクラスにすべきではないですか。
そうすると、内部設計書で、そのクラスを登録し、部品として品質を確保すべきでしょうね。
いいでしょうか、開発の場合は、フォーカスおよび開発スパンを考えてください。
一体どこの工程に影響している事象か、を考えてみるのです。
なんとかしなければいけないけど、技術的にかなり困難なものを「バグ」なんていったら、いつまでもバグが片付かないということになり、出荷認定がおりません。
法律的な問題がからんだり、機械の機能自体の問題にからんだものであれば、基本設計より前の「要求仕様」での再考慮が必要と言うことになります。
redmineは大変に優れたツールですけど、これを導入することでみなさん思考停止になる場合が結構あります。
コミットがローカルでもできますし、一種のメモみたいな感じでちょこまかやってサーバーコミットをすると、ソースは直っているけどいったい何、という話になります。
もちろんコメントも入れますけど、脈絡が不鮮明になるんです。
何かを直すとき、影響範囲がどの設計書にあるか、を記録するようにしないといけません。
全部の工程が同じメンバーでなされるなんて言うことは普通ありません。
上流の、要求仕様や用件定義と決定したのは、技術者ではなく経営陣や営業が主であったはずです。
ここにはコンサルタントだとか社外の協力会社の人たちも議論に加わったかもしれない。
工程はどんどんブレイクダウンしていきます。そしてその都度、メンバーは変わっていきます。
当然品質上の評価で、この工程はもうクローズしていいから次に行くことを許す、という判断はなされています。
プログラムをメイキングする部隊が、基本設計はおかしいから直そうという権限はありません。
でも基本設計で考慮いただきたいこととして発見があるなら、報告として上げる必要があるでしょう。
そのため、困難ではありません。こういうことをしてください。
バグ表ではなく、不具合発見表、というものを作ってください。
何日の何時何分に、誰がそれをどういうことをしているときに発見し、現象はこうであるという記録です。
必ず記載するルールにします。
画面がこうだとか、データがこうなっているというのであれば、その状況がわかるエビデンス資料を添付します。
そして、エビデンスに番号をふり、不具合発見表の中に、その番号を記載します。
各行には「判断」と言う項目と「対処方針」「対処チェック」と言う欄を作っておきます。
さらに「影響範囲」という欄を設定します。
この影響範囲は、実際の工程で作られている設計書を並べてください。
「外部設計書影響範囲」「内部設計書影響範囲」というように並べます。
そして、これらは、範囲を記載する欄とチェック欄の2列構成にしましょう。
開発のSEがその不具合表を見て、バグと判断するかそうでないかを記載します。
バグであれば、担当者と一緒に判断し、どこが悪いからどうなおせばいい、と記載します。
直すとした場合、どの設計書に影響するかを記載します。
プログラムをいじくるまえに、この記述は必ず行います。
よかれと思ってやったらデグレードが起きた、なんていうことを少なくするようにしたいのです。
この影響欄はブランクは許しません。影響しないのであれば”－”を入れるように決めます。
そうすると、考慮した証拠になります。
”－”でない不具合は、修正後、影響範囲のチェック欄にチェックを入れなければいけません。対処をしたという記録です。
このルールで影響範囲のチェック欄以外がうまった不具合は、プログラムを操作してもかまいません。
往々にプログラマは先に手を動かしてしまいます。
また、人に発見されたタイプミスでも、たかがケアレスミスだとして記録したくないという神経が働くのが通例です。
不具合記録にしてしまえば絶対に記録されています。
分析をしたときにタイプミス程度なら「軽微」ということになり、やった当人が責められるなんていうことはなくなります。
もうお分かりだと思いますが、この話を進行させるには役割が一つ必要です。
「ライブラリアン」です。
redmineが勝手に暴走して誰も全体像がわからなくなるようなトンマなことが起きないように、品質監督としてライブラリアンは必要です。
![その他([技術者向] コンピューター) イメージ](https://gazo.okwave.jp/okwave/spn/images/related_qa/c205_4_thumbnail_img_sm.png)
お礼
ここまで記載頂き、大変感謝申し上げます。 大変参考となりました。会社に進言をしてみたいと思います。 ありがとうございました。