トラブルリカバリ日記－００３ ～現場に入る前に仮説を作る
最初の一歩の現状把握のために、資料などを集めましょう、とこちらの記事で書きました。
では、資料を読み込んだならば、次に何をすべきでしょう。
仮説を作りましょう。
仮説の観点はいくつかあります。
開発する機能がいくつかあるのであれば、 A機能、B機能、C機能、～～～～といったように機能ごとに品質や設計上の課題があるかないか、と考えます。
考えるといっても、適当に考えればよいのではなく、手元に集まった資料から読み解いていきます。
例えば、障害一覧があります。 トラブっている状態ですと、だいたい障害が多く発生している機能があります。
ただ、気をつけないといけないのは、障害数が多いからといって品質が悪いとは限りません。障害が修正されているならば、その時点では品質が確保されている可能性があります。
また、テストケースが少なければ発生障害数は少なくなるので、ケース密度も指標として見たほうがいいです。
これらは定量データからの仮説立てになりますが、実際の障害の中身もサンプリングで見るようにしましょう。その実の障害内容にトラブルとなった要因が転がっていたりします。
また、設計書を見てもわかることもあります。設計として書くべきことが書かれているか、メンテナンスされているか、機能ごとに記載レベル、内容は統一されているか、など。
体制図からも仮説だてをします。例えば、プロジェクト体制に会社組織の論理が持ち込まれていないか。プロジェクトへは会社組織の論理を持ち込んではいけませんが、往々にして持ち込まれるケースがあります。そしてそのような場合は、プロジェクトはうまくいかず、設計されたものは組織間で整合が取れていないケースがあります。
マスタースケジュールからは、どこかにスケジュールの歪みはないか、と見てみます。
プロジェクトのもともとのスケジュールはきれいなスケジュールが書かれているはずです。それがどこかから、進捗が遅れ、スケジュールに無理が生じてしまいます。そのタイミングがどこなのか、そこで歪が発生した原因は何なのだろうか、と考えます。
このように、まずは仮説を立ててからプロジェクト現場の中身に入っていくようにしましょう。現場に入ってからは仮説に対して検証をしていく、ということになります。
そして、仮説は外れているものもあります。外れていたならば、それを早く軌道修正して新しい仮説を立てましょう。いつまでも元の仮説に縛られてしまっては、いいトラブルシュートはできません。
トラブルリカバリ日記としてこちらに書きしたためています。
