(1)開発成果物の管理についての検討事項
ソフトウェアの開発での開発成果物としては、仕様書や設計書などのドキュメント、プログラミングの結果であるソースコードと実行媒体がある。
仕様書や設計書はソフトウェアで実現する機能や、ソフトウェアの詳細な内容などが書かれている文書であり、プログラミングの前に作成しその内容はレビューなどで承認されたもので、プログラムはこのドキュメントに沿って作成される。
ソースコードは仕様書や設計書をインプットとして作成され、プログラミング言語で書かれており、このソースコードをビルドすることで実際に動作する実行媒体を作成することができる。
実行媒体はソースコードをビルドして生成されるもので、ターゲットとなるコンピュータ上で動作し、要求された機能を実現する。
ソフトウェアは一度開発してしまえばそれで終わりというわけではなく、不具合(バグ)があれば、ソースコードを修正し、実行媒体を生成してリリースするという作業を行うし、仕様の変更があればドキュメントを修正して、それに合わせてソースコードを変更して、実行媒体を生成するという流れの処理を行う。

(2)開発成果物管理における課題と対策提案
近年のソフトウェア開発では、0から全てを開発することは少なく、他のプロジェクトで開発したソースコードを流用して使用することが多くなってきている。しかし、この流用したことは流用した側(流用先)では理解しているが、流用された側(流用元)に知らされることは少ない。
流用するソースコードの多くは開発が完了し、十分な動作実績を持つものも多いが、不具合が0ということはなく、新たに不具合が見つかり修正したり、ユーザーからの要求で仕様変更が発生しソースコードを修正することがある。
しかし、これらの情報は流用元では共有されていても流用先に伝わらないことが多く、流用元で見つかった不具合を抱えたまま運用されるということが多い。
また、仕様変更で流用元のソースコードを修正する場合、流用元では流用元内での影響度を考慮して変更を行うが、流用先での影響は考慮しないため流用先で修正したソースコードをそのまま使用した場合、思わぬ不具合が発生することがある。
他にも、流用時に流用先でソースコードを変更して使用したが、流用先で修正が発生したときに、先の流用時の変更を行うのを忘れ不具合になることなど、ソースコードの流用についてはさまざまな問題が発生する。
ソースコードの流用についての問題の対策として、ソースコード関数レベルで流用状況をまとめ、それをデータベースにし、変更が発生した場合には流用先、流用元について変更の要否を検討するという方法が考えられるが、作業が煩雑でありデータベースへの登録が漏れることが多くうまくいくことは少ない。
そのため、作業者の負担を軽減するために、流用時にはソースコードに流用元の情報と流用後の変更の有無を記述することをルールとして設ける。また、開発したソースコードは管理サーバーにまとめて保管する。そして、ソースコードの変更を行ったときには、検索機能を用いて修正を行ったソースコードの流用先、流用元を洗い出し関連する技術者に変更内容の情報とソースコードの差分情報の連絡を行うことにした。

(3)提案の効果とリスク
ソースコードの流用情報をソースコード内に記述するのはデータベースに登録するのと比較しソフトウェア技術者としては手間がかからないため、ルールの浸透は難しくない、ほとんどの場合、うまく言っている。
また、変更時の他のプロジェクトへの影響の調査も、人手で行うことは少なく、ソフトウェア変更内容確認レビュー時に資料として作成することを義務化することで漏れなく実施できている。
ただ、このルール制定後のソースコードには有効であるが、過去のソースコードには流用情報がないため、このルールに頼ってしまった結果、過去のソースコードについては必要な変更が行われていなかったり、安易な変更による不具合もなくなってはいない。

[Intermission]
問題では“技術的課題”と書いてあるので、少し記述内容は弱い気がします。
しかし、適当な構成管理の技術的課題というのが思いつかないので、本番の試験でもかんな感じの内容でしかかけないと思います。
あとは、バージョン管理やリリース管理ですけどどちらも技術的要素は少ないよなぁ…。

戻る 一覧へ