HOME > ソフテックだより > 第252号(2016年2月17日発行) 現場の声編「派生開発における3つの工夫について」

「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより(発行日順)のページへ
ソフテックだより 技術レポート(技術分野別)のページへ
ソフテックだより 現場の声(シーン別)のページへ


ソフテックだより 第252号(2016年2月17日発行)
現場の声編

「派生開発における3つの工夫について」

1. はじめに

私は、今年で入社4年目の中国出身の社員です。弊社では制御用ソフトソフトウェアの受託開発に特化して、様々な開発を手掛けております。ソフテックだより第242号 現場の声編「新規開発で感じた達成感」でも紹介したように、一からの新規開発も少なからずありますが、派生開発が過半数を占めています。私自身も、入社してから派生開発、とりわけ組み込みソフトの派生開発に関わることが多いです。今となっては、当たり前に感じるものもありますが、派生開発に携わって感じたいくつかの事柄を取り上げてみたいと思います。

2. 派生開発の課題

参考文献(*1)の「『派生開発』を成功させるプロセス改善の技術と極意」によれば、派生開発というのは、ある製品やシステム(のソースコード)をベースにして、新しい機能を追加したり、操作性などを改良したりして新しい製品やシステムを作り上げて行くことを指しています。派生開発の課題として、まずは、ソフトウェア規模の増大や、コストの削減など市場要求の激しい変化に伴い、「納期が短い」という点が挙げられます。もう1つは、そういった短納期の制約の中で、「部分理解」すなわち全体を理解できていない状態で、追加・変更作業が強いられることです。短納期と部分理解の課題をクリアし、開発を成功させるためには、担当者の思い込みや勘違いに気づく方法を取り入れる工夫がポイントになると感じました。

3. 3つの工夫について

ここでは今まで携わってきた同一プロジェクトの派生開発に取り入れた工夫を3つご紹介させていただきます。どういったシステムを開発するかによって大きく変わってくるところはありますが、なるべく応用の効く基本的なものを以下にリストアップしてみました。

3-1 新規開発から培ってきた情報を有効に共有する工夫について

上記の派生開発の制約を打破するために、最初は見積もり段階において、お客様の真の追加・変更要求仕様を正確に掴み、正確かつ迅速な作業ボリュームを算定することが重要だと感じました。その手段として、ソフテックだより第35号 現場の声編「顧客要求を読み取ることの難しさ」でも紹介したように、ソフテックではお客様や担当者との間でLotus Notes(ロータスノーツ) で情報を共有するということを行っています。本プロジェクトの派生開発において、お客様から新たな仕様変更・追加要求の打診が来るたびに、お客様との共同作業でその実現性検討を進めていくうちに、新規開発からLotus Notesに蓄積してきた情報を参照して、正確で迅速な見積もり作業ができるということを実感してきました。お客様とのやり取りをよりスムーズに行うために、以下2点をこころ懸けております。まず1つ目は、不明点・曖昧点を顧客へ確認する際、図・表などを駆使し、ビジュアルに質問の要点が分かるようにすることです。2つ目は、お客様の要求する仕様には何らかの理由や背景があるか、これを意識しながら、お客様の要望する方法の他によりよい提案ができないか可能性をできる限り探ることです。そうすることによって、お客様との間に意思の疎通が図れることで、後工程になってから問題が起き、膨大な後戻りを発生することがほとんど避けられると感じました。

3-2 新規開発の設計思想を継承と伝承する工夫について

ソフテックだより第122号 現場の声編「本当にソフトウェアは劣化しないのか?」でも紹介したように、派生開発において、一番発生しやすい問題は、設計と実装が乖離することです。それを防ぐための手段として、仕様追加・変更が発生するたびに、ドキュメント資産から、特に新規開発時の設計書から、設計思想をしっかり継承した上で、設計書の更新を怠らないことが大事だと感じました。
設計書には、設計思想や実装制限などいろいろな情報が含まれております。設計内容の更新を怠ると、重要な設計情報が喪失される状態に陥り、結局プログラムを見なければ何も分からないので、次の追加・変更における見積もりを誤り、その追加・変更による影響範囲の見極めを誤り、最終的にプログラムの納期や品質の要求を達成できなくなる恐れが極めて高まってしまったことがあるからです。
3-1の内容にも関係しますが、派生開発が発生した際に、最初にお客様から、既存仕様の詳細に関するお問い合わせが多々ありました。こちらのお問合せに素早く対応するには、お問合せのたびにプログラムの中身をチェックするのではなく、設計書だけ参照すれば済むようにしておく必要があります。

3-3 不適合の発生を減らすためより上流工程のレビューを重視する工夫について

派生開発における不適合の多くは、ここを変更すればよいと思った箇所が思い過ごしだったり、ほかに関連して変更すべき箇所があることに気づかなかったり、勘違いして無関係なとことをいじってしまったりプログラムの変更方法が間違っていることに気づかなかったりしているところから発生しています。
派生開発において、不適合の発生を減らすために、レビューにより上流工程で不適合を見つけることが不可欠だと感じました。図1に示しますように、派生開発の各工程において、見積レビューや、設計レビューや、コードレビューや、テストスペックレビューがありますが、より上流の見積・設計レビューをしっかり行うほど、その効果が大きくなると実感しました。見積レビューに関しては、3-1で述べさせて頂きましたLotus Notesでの情報共有が有効と考えられます。設計レビューをスムーズに行うためには、3-2で述べさせて頂きました設計書を絶えずにメンテナンスすると同時に、派生開発が発生するたびに、変更箇所をトレーサビリティ・マトリクスで捉え、変更方法を関数レベルまで明確にすることなど変更設計書が重要と感じました。問題の多くが、見積・設計レビュー段階で発見されるので、そこをすり抜けてテストの段階で発見される不適合が減少した経験を多く持っております。

派生開発の各工程におけるレビュー
図1. 派生開発の各工程におけるレビュー

4. 終わりに

今回は、派生開発において重要だと感じた3つの工夫を簡単にご紹介させていただきました。今まで携わってきた派生開発の中で発生した思い込みや勘違いは、周りの先輩から指摘により気づくことが多々ありました。
但し、周りの先輩のスケジュールや、コストなどの面から、効率と効果の高いレビューを実施することが必要不可欠だと感じています。
これからも自分が考えていることや認識していることを具体的に表現し、レビュー対象となる成果物のチェックのしやすさに配慮することで、品質の高い製品を目指して改善していきたいと思います。

最後までお読みいただきありがとうございました。

(S.S.)

[参考文献]
※1「『派生開発』を成功させるプロセス改善の技術と極意」
編著者:清水 吉男
出版年:2007/10/27
出版社:技術評論社

関連ページへのリンク

関連するソフテックだより

ページTOPへ