トップページ > 開発プロセスごとの改善方法 ― 概要 > 派生・保守開発

派生・保守開発

既存のソフトウェア資産を流用した開発

ソフトウェア開発においては、1度開発したら終わりということはなく、開発したソフトウェアにさまざまな変更が加えられて、また新たなソフトウェアが生み出されます。ソフトウェアがリリースされた後、新たにどういった変更が加えられるのでしょうか。

このように1つのソフトウェアへ変更が加え、新たなソフトウェアを開発することを派生開発や保守開発と呼びます。

派生開発

リリース済みもしくは開発中のソフトウェアを流用し、新たなソフトウェアを開発すること。

保守開発

リリース済みのソフトウェアへ機能改善や不具合修正など比較的小さな変更を加える開発のこと。リリース済みのソフトウェアを利用しているユーザー向けに実施されることが多い。

最近のソフトウェア開発では、これまでのような1つのソフトウェアに長い期間をかける開発ではなく、既存のソフトウェアを流用した派生開発や保守開発が増えてきています。

派生開発・保守開発のよくある問題

派生開発や保守開発では、新規開発とは異なる問題が発生します。

以下に記載する問題は複数のソフトウェアを複数の開発者が並行に担当していることに起因しており、開発ソフトウェアに関する情報を開発組織内でうまく情報共有できていない、または情報共有するための作業に多大なコストを払っていることが要因です。プロセスの改善を実現する際はこれらの問題を、開発者の負担を増やすことなく解決しなければなりません。

開発ソフトウェアと流用元ソフトウェア、他の派生ソフトウェアとの整合性が取れない

過去に開発したソフトウェアAを流用して新しいソフトウェアBを開発する場合を考えてみます。

開発済みのソフトウェアAは保守開発により不具合修正が行われ新たな変更が加えられます(変更A)。開発するソフトウェアBには、ソフトウェアAには無かった機能が追加実装されます(変更B)。この場合、ソフトウェアBはソフトウェアAの変更Aを取り込まなければ、デグレードが発生してしまいます。

保守開発と派生開発の整合性

今回の例のように、1階層(ソフトウェアA→ソフトウェアB)の場合は、もしかしたら開発者の方が記憶しておりデグレードを防止するために動いてくれるかもしれません。しかし、階層がさらに深く、複数の派生ソフトウェアが開発されてしまうと、ソフトウェア間の整合性を保つことが難しくなります。

新規開発と比べて、ソフトウェアの検証やレビューなどのプロセスが順守されにくい

新規開発の場合、例えばウォーターフォール型の開発プロセスのように、設定や実装、検証などのプロセスが割としっかりと定義された上で開発が進みます。一方で派生・保守開発の場合、既にある程度のドキュメントやソースコードが存在することもあり、変更設定や変更実装がプロセスとしてきちんと定義されないことが多くあります。

新規開発と派生・保守開発のプロセスの違い

派生・保守開発において、既に存在するソフトウェアに変更を加えた際は、変更の影響範囲を特定しレビューや回帰テストを実施する必要があります。派生・保守開発では新規開発よりも少ない期間と工数が割り当てられることが一般的であるため、新規開発規模のレビューや検証を実施することができません。納期を守るためにレビューや検証を実施したかどうかのチェックが簡略化され、リリースされた後に不具合が発見されることも珍しくありません。

開発担当者が派生ソフトウェアごとに変わるため、前任の開発者の作業内容がわからず、実装に余計な工数がかかる

ソフトウェア開発のチーム構成は、開発ソフトウェアごとにアサインされます。派生・保守開発の場合も同様に、開発する派生ソフトウェアごとに人員のアサインが行われます。現在の開発の現場では、1名の開発者が複数のソフトウェア開発に並行してアサインされることがあります。

コストのかかる確認作業

例えば、ソフトウェアAの開発時点では開発メンバーとして参画していなかった開発者が、派生ソフトウェアBの保守開発に参加した場合、この開発者は元々の設計思想やアーキテクチャ、ソースコードがどう変更されていったかを知りません。ドキュメントやソースコードを読み、それらを理解する必要があります。保守開発において不具合修正の際に、ソースコードを変更しようとした場合、コードからは理解できない実装が見つかり、ドキュメントを読み漁り、当時の開発担当者へ問い合わせを行うことで対応を行っています。こうした作業には多くのコストがかかっています。

ソフトウェア構成管理による改善を行うべき理由

開発者はドキュメントやソースコードなど、ソフトウェアを動作させるために必要なファイルを作成することが開発業務の目的となります。

現在の開発の現場では、ドキュメントやソースコードをいつ誰が何を変更したかを追跡可能にするために多くの時間を割いています。例えば、ソースコードのどこをなぜ修正したかを管理台帳に記載する、などがあります。ファイルの変更に関連する「事務手続き的な作業」により、開発者が注力すべき開発業務の時間が奪われています。

変更管理のための無駄な作業

開発者の最終成果物が「ファイル」である以上、それを管理するソフトウェア構成管理が開発者の作業を効率化する責務を持ちます。

開発プロセスごとの改善方法に記載した通り、残念ながら現在のソフトウェア構成管理は時代遅れです。Subversionなどに代表される現在の主流なバージョン管理ツールでは、開発者の事務手続き的な作業を軽減することはできません。現在の開発の現場におけるソフトウェア構成管理の活用方法を正しく理解し、プロセス改善を実現させましょう。

ソフトウェア構成管理を活用した派生・保守開発の改善

開発ソフトウェアと流用元ソフトウェア、他の派生ソフトウェアとの整合性が取れない

整合性を取るためには、どこに何を反映すべきか、を把握できている必要があります。

ソフトウェアの家系図を作成することにより、各ソフトウェアがどのソフトウェアを親としているのか、さらにどのソフトウェアが子なのかを正確に把握できるようにします。

変更の影響範囲

上記図を例にすると、ソフトウェアAが変更された場合、その変更はソフトウェアBとCへどういった影響があるのかを精査する必要がある、とわかります。

家系図は日々進化します。新たな派生ソフトウェアが開発された際に家系図も更新する必要があります。そのため、人手による管理ではなく、支援ツール等を利用した家系図の管理を行うことで、家系図自体の管理コストを削減することができます。

家系図とブランチ構造の関係

また、家系図は構成管理ツール上のブランチと密接な関係があります。家系図上のソフトウェアはほとんどの場合、構成管理ツールのブランチをしてそれぞれが独立して管理されています。家系図により、ソフトウェアの関連だけではなくブランチの構成も可視化できる点が大きなメリットとなります。

新規開発と比べて、ソフトウェアの検証やレビューなどのプロセスが順守されにくい

新規開発と同じ期間やコストがかけらない以上、新規開発と同じプロセスを使うことができないことをまずは理解します。派生・保守開発に適したプロセスが必要です。

派生・保守開発では例えば以下のような専用のプロセスを定義し、重要なフェーズは開発リーダーやマネージャーの権限を持つものが承認しない限り、次のプロセスへ進めないよう承認フローを運用に組み込みます。このような仕組みはルール化など人手による努力で実現するのではなく、開発組織規模で支援ツール等を利用して管理することが望ましいです。

派生・保守開発のプロセス

開発担当者が派生ソフトウェアごとに変わるため、前任の開発者の作業内容がわからず、実装に余計な工数がかかる

ドキュメントやソースコード単位における変更管理では、1つのファイルがいつ誰によって変更されたの履歴のみが把握できます。開発の現場においては、不具合XXのためにドキュメントAとソースコードBおよびCが変更されている、といった変更理由単位での追跡が必要です。

変更パッケージ

上記のように、変更理由を元に変更されたドキュメントやソースコードを芋づる式に追跡できる仕組みを準備します。ソフトウェア構成管理においては、外部の課題管理ツールを連携させ、コミットログにチケットIDを記載する、などで上記が実現されています。構成管理ツールと課題管理ツールが別々のツールである場合、連携部分のメンテナンスは開発プロジェクト内で実施する必要があることに注意が必要です。

派生・保守開発の改善ポイント

派生・保守開発においては、これまでの新規開発との違いを開発者の努力ではなく仕組みで吸収する必要があります。

改善の第一歩は、開発者が本当にするべき活動へ集中できるよう、無駄な作業を排除することです。無駄な作業とは、人手による変更の追跡管理や属人的な開発ソフトウェアの情報共有などがあります。これらの無駄を排除することで、初めてプロセス改善を推進するための開発者の余裕が生まれるのです。

プロセス改善支援ツールを用いる

プロセス改善を支援するツール "AccuRev"では、今回ご紹介した問題解決方法を全てツール上で実現することが可能です。

AccuRevでは、ソフトウェアの家系図と開発プロセスを合わせた1枚の図を使用した構成管理・変更管理が可能です。また、AccuRevには課題管理ツールとしてAccuWorkが標準搭載されており、開発者自らが構成管理と課題管理を連携させる必要がありません。こうしたツールを利用することもプロセス改善には有効です。

このページのトップへ