USDMとDRBFMを羅針盤にして派生開発を成功に導く
NECソフト株式会社
酒井 賢
５. 成果
変更要求仕様書と心配点シートを導入することで次のような効果が得られました。
・ 時間をかけて全員でレビューすることで、いままでよりも詳細な仕様化ができ、仕様化漏れがなくなった。
・ 理由を記載することで、要求の真の目的を理解でき正確な仕様化ができるようになった。
・ ユニークなIDを成果物に記入するようにしたので、どの開発でどのような変更が発生したのかを
追跡することができるようになった。
・ TMによって、変更に対する各モジュールへの影響が横断的にわかるようになり、
レビュー段階で変更箇所の漏れに気づくことができるようになった。
・ 変更が一覧化されて1つの表に集約されているため、影響範囲がひとめでわかり、
変更量と複雑さがイメージでつかめるようになった。
・ メンバー全員がレビューに参加することによって、自分の担当モジュールだけでなく、
他のメンバーの担当モジュールへの影響も意識するようになった。
・ 心配点シートで些細な心配でも吸い上げるので、メンバー全員が「プロジェクト全体」に対して、
責任感と参加意識が強くなった。さらに、バグの発生は、メンバー全員の敗北という意識が芽生えた。
・ 成果物レビュー時に心配点シートのレビューを行うことで、緊張の時間と弛緩の時間を作り出し、
レビューにメリハリが出るようになった。
・ ベテランになればなるほど、経験に裏付けられた心配点が記入される傾向があり、
なぜそのような心配点が出るのかが若手に伝わるチャンスとなった。
変更要求仕様書と心配点シートを導入することで、課題としていた4つは解消されました。大げさな話ではなく、本当に変更仕様に関する問題は発生しなくなりました。
少なくとも、ソフトウェアという不可視なものを扱う場合、「そこに変更のすべてがあり、常に最新の状態に保たれていて、その変更をメンバー全員が知っている」という安心感は、品質の向上にも役に立つものと思います。
６. 導入にあたってのポイント
導入と進め方のポイントを経験をふまえて記載します。
a. 必要性と表記方法のスタディ
変更要求仕様書と心配点シートを完成させるには、メンバー全員の協力が必要となります。そのためには、なぜ変更要求仕様書と心配点シートが必要なのか、どのようなルールで記入するのかを理解しておかなければなりません。事前に集まって勉強会を開きましょう。
b. 記入ルールの明確化
変更要求仕様書の要求事項、理由、仕様はプロジェクトリーダーが記入、TMは各モジュール担当が記入、心配点シートは全員が記入する事としました。なぜなら、USDMは、「何を変更するのか」の観点で記載するため、細かな実装を知らなくても書けるからです。これが書けないようではお客様との仕様調整は難しいということになります。TMは実装を知っているモジュール担当者が記入します。TMを記入する際には、必ず仕様を参照するので、自然とクロスレビューになります。
c. お客様をまきこむ
いきなりお客様に「変更要求仕様書を導入します」と言っても、なかなかOKが出ないかもしれません。私たちは、導入当初はお客様と実施するデザインレビューの際に改造仕様書のサブ資料のようなかたちで提出していました。開発のたびにだんだん露出度を上げていき、最終的には、改造仕様書を作成する前段階の仕様書として認知されるようになり、お客様もまじえてレビューを行うことができるようになりました。
d. 事前配布・事前レビュー
変更要求仕様書と心配点シートは事前配布・事前レビューを徹底します。配布時にレビュー記録表を添付して、レビューアはレビュー結果と追加の心配点を記入して、集合レビューの前に作成者に戻します。
これには2つの効果があります。１つは、仕様書がレビューに値する完成度になっているかの確認です。あまりにも要求を取り違えているとレビューに時間がかかるばかりで先に進みません。逆に、「て・に・を・は」などの些細な間違いは、レビュー時に気になって指摘し始めると、意外と時間がかかってしまうものです。そのような些細なものは、集合前の段階で指摘してレビュー前に取り去ってしまいます。
2つめは、事前に目を通すことで、無意識下に働きかける効果です。技術者は意外と仕事の時間以外でも、なにがしか担当モジュールについて考えているものです。変更仕様を脳内で熟成する時間を確保することで、心配点シートに載るような、ひらめきや気づきに期待します。
e. 仕様変更の度に全員レビュー
要件の追加や変更が入った場合や仕様変更が発生した場合には、必ず変更要求仕様書を改版して、常に最新の状態をキープします。仕様が変更になれば、影響範囲や心配点も変わるはずなので、どの工程であったとしても、再度全員でレビューを行います。時間はかかりますが、より安全で確実な変更を行うための投資と考えます。
f. 各工程の成果物のレビュー毎にその機能が取り込まれているか照らし合わせる
変更要求仕様書と心配点シートは、次工程のインプットであるとともに、実際は、すべての工程のインプット文書となります。変更要求仕様書に書かれた変更点は、改造仕様書にも反映されますし、テストも行われるはずです。ですので、各工程の成果物をレビューするときには、変更仕様が確実に反映されているか、他に心配点はないかを確認します。
g. 以前の変更要求仕様書と心配点シートを参照する
新たな変更要求仕様書を作成するときは、今まで作成した変更要求仕様書を見直して、類似の変更をしたことがないか、顕在化しなかった心配点が今回は顕在化する可能性はないかを考えながら作成します。変更要求仕様書はメンバーの叡智の固まりなので、何らかの気づきにつながるはずです。
h. 理由や粒度にこだわり過ぎない
変更要求仕様書導入当初は、要求の理由を書くのが難しく感じるはずです。要件書に理由が書かれていることは少ないですし、今まで要求に対する理由を考えたことがあまりないからです。仕様の粒度にも悩むと思います。細かくすると膨大な数になる可能性もありますし、荒くすると要求事項と同じになる気がします。でも、大丈夫です。要求事項によって荒い粒度になったり細かい粒度になったりするのは、複雑さや難易度などが自然と反映されているからです。レビューしてくれる人を信じて、理由や粒度にはあまりこだわらずに記載します。
i. レビューは緊張と弛緩を交互に
成果物のレビューは常に緊張感が伴います。そうした緊張感の合間に、頭をほぐす意味も含めて心配点シートのレビューを行います。変更要求仕様書の記載で想定される問題の検出はされているはずなので、心配点シートでは問題が発見されなくて当たりと思って、やや発散系になってもよしとしてやるのが良いと思います。リラックスした場の方が気づきが生まれる可能性が高まります。
