Click here to visit our sponsor


□------------------------------------------------------------------□
□ アプリケーションプログラムの再利用について
□------------------------------------------------------------------□

---------------------------------------------------------------------
設問ア
----
1−1.私の業務
----
 私は、大手ハ−ドウェア企業に所属するSEである。
現在、大手銀行A行向け勘定系システム(以下、A行シ
ステム)の開発にサブリーダとして従事している。
----
1‐2.再利用を前提とした開発
----
 A行システムの開発言語はオブジェクト指向言語であ
る。A行システムの開発は、先行して開発している当社
の汎用パッケ−ジ(以下、標準版システム)のカスタマ
イズ(修正、派生等)が前提であり、A行固有の機能に
ついてだけ、部品(クラス、メソッド等)を新規製造す
る方針である。従って、新規開発部分が少なく、生産性
の向上や高い品質が期待されていた。
----
1‐3.効率的な再利用を行う為の組織
----
 A行システムチ−ムの構成は、課長以下社員6名、協
力会社は4社である。開発期間は2年以上の大型プロ
ジェクトである。標準版システムプロジェクトの規模は、
A行システムプロジュクトと同程度であり、およそ半年
先行していた。標準版システムは、特定ユーザを持たな
いパッケージであり、A行はそのファーストユーザであ
る。私が所属するA行システムチームと標準版システム
チームは同一部門内に設置された。お互い数年来の同僚
であり、スキルや性格等は把握され人間関係は良好で
あった。つまり、相互に連携し順調にプロジェクトが進
行する仕組みは整備されていた。私はリ−ダのサポ−ト
の他に、担当するサブシステムに関しては実質的なリ−
ダの役割をもっている。私が担当したサブシステム(以
下、ローカル処理クラス)は、全体の1/4程度の規模
である。協力会社は2社が関与している。
---------------------------------------------------------------------
 設問イ
---------------------------------------------------------------------
2−1.再利用の方針
----
 課長以上の全体会議で、A行システムの開発は、標準
版システムの再利用で行うという方針が既に決定してい
た。それを前提に、私たちプロジェクトチームは、実際
の開発に先立ち以下のことを確認する必要があった。
・標準版システムのうち再利用できる部分の特定
・再利用する場合のプロセズ
・単体テスト及び結合テストの範囲、方法
私たちは、標準版システムチームを交えて数度のミー
ティングを行い。以下の結論に至った。
 標準版システムは現在開発中であり、部品(クラス、
メソッド等)の詳細設計さえ終了していない部分も多数
存在する。従って、再利用範囲の特定やカスタマイズの
程度は、現時点で調査可能なものから行い、それ以外の
部分は、標準版システムの部品が完成次第随時行う。
 再利用の手順としては、標準版システムチームは、部
品の新規リリース、既存部品の修正版リリース等の一元
管理を行う。リリース物件には再利用にあたっての特記
事項等を明記する。さらに、リリース計画表を作成し関
係者全員がいつでも見えるようにする。A行システム
チームは、以上のようにして一元管理されている部品を
コピーして利用する。
 標準版システムとしてリリースされた部品は全て評価
済みであるので、そのまま流用する部品については、単
体テストは省略する。カスタマイズした部分についての
み単体テストから行う。テストの方法は、単体テストは、
ホワイトボックステスト、連結テストは、ブラックボッ
クステストとする。単体テストは開発ツールのデバック
機能を使用する。テストデータは、親クラスの評価で使
用済のものを一部活用する。
----
2−2.再利用に当たって実際に発生した問題
----
 上記の方針に基づき順調にプロジェクトは進行してい
た。ところが、製造フェ−ズの中盤辺りから部品の供給
元である標準版システムプロジェクトが原因の三つの問
題が生じてきた。
・部品の不足
 第一に、標準版システムの開発スケジュールが遅れ、
カスタマイズ対象である部品が期日にリリースされなく
なった。標準版システムの進捗の遅れは、プログラム設
計に当初予定した工数以上がかかってしまったことや度
重なる開発環境(OS、開発ツール等)のバージョン
アップ対応が原因であった。この結果、我々のA行シス
テムプロジェクトのカスタマイズ作業がストップするこ
ともあった。
・部品の品質低下
 第二に、標準版システムの部品にバグが目立つように
なった。バグの多くは、条件漏れや例外処理に関する考
慮漏れが原因であり、充分なテストが行われていれば発
見できるはずのものであった。この結果、我々のシステ
ムは、親クラスのバグを継承してしまっていた。プロ
ジェクトは、バグ個所の特定や標準版システムチームへ
の修正依頼などの予定外の作業に追われることが多く
なった。同時に、開発メンバー個々のモチベーション低
下や緊張感が次第に失われていった。
・部品の機能不一致
 第三に、標準版システムの部品とA行版システムの仕
様とが予想以上に不一致していることが判明した。私は、
協力会社2社から、デ−タ型などの相違、メソッドや引
数の不足、処理フロー不一致によるカスタマイズが相当
量必要な為、新規にコ−ディングする量が予定よりかな
り増加してしまうとの連絡を受けた。
----
2−3.対応策
----
 私は、事態を早速、チ−ムリ−ダであるT氏、及び課
長に報告した。そして、後日、ミーティングが開催され
ることとなった。また、協力会社2社に対して、改めて
不備を謝罪するとともに、新規コーディングの作業は指
示を出すまで着手しないようにお願いした。
 私は、標準版システムチームの進捗の遅れが全ての原
因であると判断した。ミーティング開催までの間、私は、
標準版システムチームのメンバー数名及び協力会社と対
応策についての意見を交換した。そして、対策検討の
ミ−ティングで資料として以下の様にまとめ説明した。
・基本的には、標準版システムプロジェクトの進捗の遅
 れが原因である。
・標準版システムの品質低下は、時間に追われテストが
 不充分であったと推測できる。
・部品の仕様に関して、標準版システチームとの打合せ
 が不足していた。
・仕様に関しては、標準版システムチームの全面的な協
 力が必要である。
・標準版システムをカスタマイズする方針は変えない。
・カスタマイズの範囲、分量の増加は避ける。
これらの他に、プロジェクトが標準版システムチ−ムに
全面的に依存、或いは信頼し過ぎた点を反省した。今後、
標準版システムチームとのコミュニケーションの充実を
図かり、両チームの協力体制を強化する必要もあった。
 私は、具体的な処理方法として二つを挙げた。
・標準版システムの仕様は、ファーストユーザであるA
 行システムをより考慮したものにする。
・テスト作業等、両チームメンバーはお互いサポートす
 る。
 課長経由で全体会議で報告され、上記二項に加えさら
に一項目追加された。
・標準版システムチームは、A行システムチームで再利
 用が予定される部品について優先的に扱う。
 部門全体及び標準版システムチ−ムの理解と協力の結
果、カスタマイズは順調に進み出した。
---------------------------------------------------------------------
設問ウ
---------------------------------------------------------------------
3.施策の評価と今後の課題
---------------------------------------------------------------------
 実施した施策について現時点での成果を確認する。ま
た、今後のプロジェクトに反映すべき事項を課題として
付け加える。
----
3−1.施策の評価
----
 プロジェクトの製造フェ−ズで発生した今回の問題は、
プロジェクト内部の原因というよりは、社内他プロジェ
クトが原因であった。従って、プロジェクト内部で事態
を解決することは出来ないとすぐに感じた。私は、私一
人で対応できる問題でないと判断し、上司に相談し適当
な処理をとることができた。特に、関係者との意見交換
から得た意見が全面的に採用された点や迅速に処置が施
された点は、自他とも評価している。
 現在は、オブジェクト指向開発を最大現に生かした安
定した品質管理が行われている。標準システムチ−ムと
のコミュニケ−ションが図られ関係は従来通り良好であ
る。
----
3−2.再利用についての今後の課題
----
 今後、オブジェクト指向のプロジェクトが主流になる
と思われる。オブジェクト指向の開発は、部品の再利用
に適しており資源の一層の活用を期待している。部品の
効率的な利用は品質管理だけでなく、スケジュール管理、
費用管理に貢献する。今後、再利用を前提に、より早い
段階から関係者間のより一層のコニュニケ−ションが必
要だと痛感した。





[ 戻る ]