firisu the shooter

プログラミング、Web開発について

平成22年4月 問3

システムが対象とする企業・機関
1. プロジェクト名称 パッケージソフトを利用した会計システムの再構築
2. 企業・機関等の組織・業種 金融・保険・不動産
3. 企業・機関等の規模 1001〜5000人
システムの規模
4. 対象業務の領域 会計・経理
5. 主なハードウェア クライアントサーバシステム(サーバ約3台)
6. ネットワークの範囲 同一企業・同一機関の複数事業所間
7. システムの利用者 301〜1000人
プロジェクトの規模
8. システムの端末数 301〜1000台
9. 総工数 170人月
10. 費用総額 130百万円
プロジェクトにおけるあなたの立場
11. 期間 2007/04〜2008/02
12. あなたが所属する企業・期間等 ソフトウェア企業・情報処理サービス企業等
13. あなたの担当したフェーズ システム企画・計画, システム設計, プログラム開発, システムテスト, 移行・運用
14. あなたの役割 プロジェクトの全体責任者
15. あなたの管理対象人数 15〜20人
16. あなたの担当期間 2007/04〜2008/02

本文

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
1.1 プロジェクトの概要
 私は独立系SI企業N社に務めるSEである。都内に
複数の拠点を持つ金融機関A社の、会計システム再構築
プロジェクトに全体責任者として参画した。A社の会計
システム(以下、現行システム)は長年の機能追加によ
りメンテナンス性が低下していた。また設計書類が最新
に保たれておらず、システムの全容を把握するのが難し
い状態にあった。そこでN社がパッケージソフトを適用
した保守性の高いシステムの開発を提案し、受注に至っ
た。N社がA社のシステム開発を担当するのは今回が初
めてである。
 使用するパッケージソフトは当時のN社の新製品であ
った。汎用的な機能を備えており、カスタマイズ製も高
いのが強みだ。一方で導入事例はあまり多くなく、ノウ
ハウが無いことが弱みだった。N社として、今後のパッ
ケージシェア拡大のため、当プロジェクトは絶対に失敗
できないものだった。
1.2 重点的に管理したアクティビティとその理由、
 及び進捗管理の方法
 私は当プロジェクトにおいて、会計データの移行作業
についてのアクティビティを重点管理した。その理由は、
①アクティビティがクリティカルパス上にある、②現行
システムのデータ構造が複雑である、の2点だ。N社は
A社の会計システムに精通していないため、後者の理由
の方が大きい。したがって、現行システムの会計データ
仕様の把握から移行プログラム作成といった作業を、私
は重大視することにしたのだ。
 当プロジェクトでは、毎週チームリーダから私に各チ
ームの進捗報告をすることになっている。また月次での
進捗確認会議も実施しており、チームごとの意識あわせ
や重大事項の共有を行っていた。

2.1 進捗遅れの兆候を早期に把握し、品質を確保し
 た上で、アクティビティの完了日を守るための対策
 当プロジェクトは会計システムとしての性格上、納期
厳守が絶対の条件だった。またA社会計部門が多忙であ
るため、A社との打ち合わせが必至となる会計データ移
行についてのアクティビティには特に遅延が許されない。
 そこで私は、進捗遅れの兆候を早期に把握し、品質を
確保した上で、アクティビティの完了日を守るための対
策を実行することにした。
 1)技術チームの設置
 会計データの移行にはパッケージソフトの機能をカス
タマイズして使用する。しかし私の部下である開発チー
ムのメンバは当の機能について詳しい知識がなかった。
そこで技術部門からパッケージソフトに精通したメンバ
を技術チームとして参画させることにした。移行方式の
詳細や、データ仕様のレビューを行わせることで高い品
質を達成させつつ効率的な作業を行わせることが狙いだ。
工夫点としては、技術チームにも進捗報告と会議への出
席を義務付けたことである。彼らは当プロジェクト専任
のメンバではないのだが、進捗遅れの兆候を早期に把握
すべく、報告者は多い方が良いと考えたのだ。
 2)中間成果物のレビュー
 N社の開発標準では、外部設計以降の成果物の進捗は
「着手済」「完了」の2つのステータスで管理すること
になっている。成果物を保管するための構成管理システ
ムもそれに対応している。
 しかし私はこのやり方では進捗遅れを事前に防ぐには
不完全だと考えた。そこで進捗のステータスに「中間ま
で完了」を追加し、そのための中間レビューを行うこと
にした。レビューの対象は作業途中の成果物なので、無
論完全な状態ではない。そのため大まかな方向性が正し
いか議論させ、今後の作業予定を組み立てる場として活
用することを狙った。締め切り日を設定してあるだけだ
と作業が中だるみしがちになるため、こういった中間地
点の設定はモチベーション維持にも効果があると私は考
えていた。
 3)成果物の抜き取り検査
 私は一度完成とされた成果物でも自身の目で抜き取り
検査することを怠らなかった。なぜなら作業に親しい者
ではかえって気付きにくい問題や、ささいな見逃しから
後に深刻化する問題を防いでおきたかったからだ。当プ
ロジェクトで言えば、会計データ仕様の網羅性や、移行
機能の設計書などを注意して検査していた。

3.1 対策にも関わらず進捗が遅れた際の原因と影響
 の分析
 移行作業のアクティビティが移行機能の詳細な設計に
入ってから、成果物の作成が少しずつ送れるようになっ
てきた。開発チームのリーダにヒアリングしたところ、
作業には問題ないが技術チームによるレビューの承認が
遅れがちになっていることが分かった。設計項目が細か
くなってきたことで、指摘内容の確認に時間がかかって
いるのだろうということだった。
 ここで私は現状の遅れの影響を分析して見ることにし
た。短期的に見れば数日~一週間の作業遅延が起きるの
みだが、長期的な品質の低下は必至であると私は考えた。
なぜなら設計の初期から技術チームは仕様のクリティカ
ルな部分の指摘を多数しており、品質の根幹を担う存在
だからである。進捗遅れの中にあって、その品質が担保
されるかどうか私は大いに不安を感じていた。

3.2 追加で実施した対策と効果
 したがって私は追加で対策を実施することにした。そ
れは技術チームのプロジェクト専任化である。私は技術
部門の責任者と交渉し、一時的に技術チームの業務を調
整してもらうよう依頼した。すると、完全に専任にする
ことは無理だったが、稼働率を0.3→0.7へ大幅に引き上
げてもらうことが出来た。
 私のこの対策により、移行作業のアクティビティは少
しずつ遅れを回復し始めた。最終的には計画どおりにサ
ービス開始をむかえることができ、品質にも問題は無か
ったと考えている。その証拠にシステムはリリース当初
から安定稼働をしており、現在に至るまで大きな問題は
起きていない。
 しかし問題が全く無かった訳ではない。というのも技
術チームの稼働率向上により、費用が計画を大きく上回
ってしまったのだ。次からは同じ対策を考えるにしても、
費用面も考慮するよう注意したい。会社にちゃんと利益
をもたらすこともプロジェクトマネージャの仕事なのだ
ということを忘れないよう一層気を付けたい。
                     -以上-

Comments