開発を支援する様々なこと

開発を支援する様々なこと

『XDDP』では必要最低限のプロセスとドキュメントを定めています。しかし、品質を保ち、継続的な開発を進めていくためには「レビューの実施」「適切な見積もりと計画」「要件の管理」「公式ドキュメントの維持」「開発プロセスの更新」などの、開発を支援する様々なことも必要になります。

レビュー

一般的な「派生開発」では、担当者があたりを付けてコードを変更するという、思い込みによる変更が行われています。そのため、問題が多く発生しています。この問題を解決する効果的な方法はレビューしかありません。『XDDP』では3つの成果物を用いることで、変更箇所、影響範囲、変更方法等のレビューを実施することができます。

公式ドキュメントの維持

一般的な派生開発では、新規開発の流れに沿ってドキュメントを完成させながら変更の作業が進められます。したがって、変更仕様の改訂が頻繁に起こるような場合は、ドキュメントの変更回数も増えていきます。しかし、限られた時間の中ではコードの修正が優先され、ドキュメントの更新がなされないまま、開発が進められてしまいます。

『XDDP』で作成するドキュメントは全て既存資産との「差分」です。テストで変更の正しさを確認し、問題がないと判断した時点で、公式な設計文書へ「差分」をマージします。そのため公式文書の変更を１回で済ませることができます。

見積もりと計画

限られた期間で慌てずに『XDDP』に取り組むためには、サイズに基づいた見積もりが不可欠です。『XDDP』では見積もりをするタイミングと、各タイミングにおいて何に着目して見積もりするかを定めています。また『USDM』において、Before/Afterを記述することで見えてきた「変更の量」や「難易度」も、見積もりに活用します。

モレを逃さない要件追跡リスト

暫定の仕様や、一度要求仕様が確定した後に生じた変更は、全て「要件追跡リスト」に登録します。この時、変更作業担当者とは別の人を追跡担当者として確保します。追跡担当者は『XDDP』のプロセスに沿って作業を進めるよう、変更作業担当者へ促します。また実現性が危ぶまれている変更要求仕様などもリストに登録し、適切に設計・実装されたかを追跡します。このようにすることで、忘れがちな追加や変更への対応も逃さずに進めることができます。

XDDP導入に「よくある問題」

『XDDP』を導入する際によくある問題として、まず、現状の問題を明らかにせずに『XDDP』に飛びついてしまい、効果が出ないといった問題があります。『XDDP』導入にあたっては、現状のプロセスの問題点を明らかにし、『XDDP』による改善をイメージできるようになってから導入する必要があります。

次に、｢スペックアウト｣が十分できていないまま、あいまいな状態で『USDM』を記述することがあります。このような状態では「変更要求仕様」として不十分であるため、実装でモレや勘違いに気づき、手戻りすることになります 。

また、実際に『XDDP』を実践してみると、｢要求｣や｢仕様｣をどう分割していいかわからず、途方に暮れることがあります。仕方なく、思いついた｢要求｣と｢仕様｣のみを記述し、先に進むことで、仕様のモレに後になって気付くことがあります。

さらに、大規模だからといって端からあきらめてしまい、【トレーサビリティマトリクス】(TM）を省略することがあります。これにより、変更の影響による不具合が後になって見つかるといったことが見受けられます。

『XDDP』は、比較的早い段階ではっきりとした効果が得られる技術です。しかし、誤った適用や正しくない導入により、失敗してしまうケースもあります。それを未然に防ぐためには、経験豊富な専門家に依頼することも、一つの方法と言えます。

XDDPによる｢派生開発｣に関する記事を見る

他のソリューションを見る

最新コラム