firisu the shooter

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

平成22年4月 問2

システムが対象とする企業・機関
1. プロジェクト名称 パッケージソフト適用による会計システムのリプレース
2. 企業・機関等の組織・業種 製造
3. 企業・機関等の規模 301〜1000人
システムの規模
4. 対象業務の領域 会計・経理
5. 主なハードウェア クライアントサーバシステム(サーバ約3台)
6. ネットワークの範囲 単一事業所内
7. システムの利用者 31〜100人
プロジェクトの規模
8. システムの端末数 31〜100台
9. 総工数 120人月
10. 費用総額 110百万円(ハードウェア費を含まない)
プロジェクトにおけるあなたの立場
11. 期間 2006/04〜2006/12
12. あなたが所属する企業・期間等 ソフトウェア企業・情報処理サービス企業等
13. あなたの担当したフェーズ システム企画・計画, システム設計, プログラム開発, システムテスト, 移行・運用
14. あなたの役割 プロジェクトの全体責任者
15. あなたの管理対象人数 10〜15人
16. あなたの担当期間 2006/04〜2006/12

本文

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
114
115
116
117
118
119
120
121
122
123
124
125
126
127
【ア】
1.システム開発プロジェクトの特徴
 A社は電子部品の製造を営む地方企業である。競争激
化に伴い、社内システムの運用コストダウンの必要に迫
られていた。とりわけ会計システムの保守に多額の費用
がかかっており、経営会議にてシステムのリプレースが
決定された。
 A社は社内に開発要因を持たないため、情報サービス
業者のS社にシステム開発を請負で発注した。私はS社
に所属するSEであり、当開発プロジェクトのプロジェ
クトマネージャとして任命された。当プロジェクトの特
徴としては、1.会計業務の性格上、納期厳守、2.S社の
製造業向け会計パッケージソフトを採用する、という店
が挙げられる。S社にとってこのパッケージソフトは当
時主力製品であり、今後のシェア拡大のためにも、絶対
に導入に失敗できないものになっていた。
2.プロジェクト組織の構成について
 プロジェクト開始前に、私は社内のチーム体制を確立
した。私を含む少数名からなる管理チーム、設計・製造
を担当するSE5名強からなる開発チーム、ITアーキ
テクト2名からなる技術チームである。実際にはここに
A社担当者3名の利用部門チームを加えた4チームにて
開発が進行した。各チームにはチームリーダーを設置し
ており、効率よくプロジェクト運営を行えるようにして
ある。
 特筆すべき点として、技術チームのITアーキテクト
がS社パッケージソフトに精通している点が挙げられる。
当プロジェクトは開発期間が8ヶ月と短く、その事情を
考慮した形だ。また、利用部門チームについても現行シ
ステムを熟知した要員がアサインされていた。

【イ】
1.チームリーダに分担させた業務の内容と分担させた
 理由
 私は、プロジェクトの管理・運営を効率よく実施する
ために、管理業務の一部をチームのリーダに分担するこ
とにした。
1−1.変更管理における変更の承認
 S社パッケージソフトは汎用的な機能を揃えているが、
現行業務の全機能を必ずしも充足できる程ではない。納
期を守るためにはカスタマイズ内容の見極めを素早く行
う必要がある。特に、一度仕様が確定した後の仕様変更
では、意思決定の早さ・正確さがスケジュールの遅延を
防ぐには必須となると考えられた。
 そこで私は、仕様変更の承認権限を技術チームリーダ
に移譲し、一連の業務を分担させることにした。その理
由はもちろん、技術チームリーダがS社パッケージに精
通しているからである。
1−2.進捗管理における進捗遅れの判断と対策の指示
 当プロジェクトは8ヶ月という短期間のものであり、
また、納期厳守でもある。そこで進捗管理においては進
捗遅れの兆候を事前に察知して対策を取ることが重要と
言える。各メンバの進捗状況はチームリーダを通して私
に伝えられることになっていたが、それだけでは進捗遅
れへの対策が遅れる可能性があると私は考えた。
 したがって、私は、進捗管理における進捗遅れの判断
と対策の指示を、管理チームの品質保証担当I氏に分担
した。I氏は本来成果物をチェックし品質保証を行う立
場であるが、開発チームのリーダを経験したことがあり
マネジメントの素養がある。また細かな成果物の中身に
も目を通すため、品質だけでなく進捗状況の変化にもい
ち早く気付くことが出来るからだ。
2.分担のルールとその周知徹底の方法
 私は管理業務を分担する際に、分担する業務範囲に気
を使うようにした。また業務内容を任せきりにせず、状
況報告を義務付けた。そうすることで独断によるプロジ
ェクトの暴走を防げるからである。それぞれの分担内容
について、特に下記のルールを設けた。
2−1.変更管理台帳の作成及び変更上限数の設定
 技術チームリーダに対し、全変更内容を変更管理台帳
に記録させ、私に提出することを義務付けた。これを私
がチェックすることで、変更内容の適正さを効率良く把
握できる。
 次に、それら仕様変更の上限数を「設計書1枚あたり
2件」のように定めた。それを超える仕様変更は必ず私
へ報告するルールとして、プロジェクトの状況を勘案し
て受け入れの可否を決定することにした。
 これらのルールを徹底するため、私は週次進捗会議に
て仕様変更についての報告を行うよう指示を出し、分担
業務がしっかり行われているか監視した。
2−2.進捗遅れの度合を定量的に計り、報告させる
 進捗遅れを予期あるいは把握した際に、まずその度合
を計算して私に報告させるルールを作った。そこでその
遅れが7日以内に収まるものであればそのままI氏に対
策をまかせ、それ以上であれば私の判断と指示による対
策を実施することにした。こうすることで現場レベルの
問題に対処しやすくなり、逆に全体的な問題にもしっか
り対策が打てる。
 このルールを徹底するため、私は進捗報告会議外にも
I氏と二人でミーティングを行うようにした。ただし原
則として月次での開催であり、まとまった情報をやりと
りすることが目的という点が進捗会議と異なっている。
これによりI氏が責任を持って進捗管理を担当してくれ
ることを期待した。

【ウ】
1.業務の分担に対する評価と認識した課題
 私の実施した分担はおおむね上手くいった。システム
は無事本番稼働し、現在に至るまで大きな問題も起きて
いない。しかし、以下の点については課題が残っている。
1−1.仕様変更台帳の漏れ
 仕様変更がたった一度だけ、台帳から漏れていたこと
があった。技術チームリーダに話を聞くと軽微な変更と
思い記録しなかったとのことだった。しかし設計書の突
き合わせにより矛盾が生じるレベルではあり、本来記録
してしかるべきと言える。
1−2.進捗管理分担の範囲
 I氏に対し7日以上の遅れは私と協議するよう命じた
が、当プロジェクトではその規模の遅れは発生しなかっ
た。また、どの道週次で進捗報告会議を行うため、この
ルールは不要にも思える。進捗管理の判断の権限はもっ
と大きく移譲しても安全ではないのか。
2.今後の改善点
 移譲の問題に対し、以下のように改善していきたいと
考える。
2−1.仕様変更問い合わせ台帳の作成
 今回は仕様変更の詳細を記録させたが次回からは仕様
変更の問合せ自体も記録させる。こうすることで例え軽
微な仕様変更でも漏らさずに実施記録を取らせることが
できるはずである。
2−2.進捗管理対策の許可以外をすべて任せる
 従来どおり7日を基準に考えるが、7日移譲であって
も対策の決定や実施は分担してしまい、その実施直前の
許可のみ私が下ろす形式にする。何か問題があれば会議
で把握することができるので、これが最速の方法である
と考えられる。
                     −以上−

Comments