firisu the shooter

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

平成17年 問1

システムが対象とする企業・機関
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
114
1.1 プロジェクトの概要
 私は独立系SI企業のN社のSEである。都内に拠点を
持つ金融機関A社の会計システム再構築プロジェクトに
全体責任者として参画した。A社の会計システムは、度
重なる保守と機能追加の結果、メンテナンス性が非常に
低い状態だった。また設計書類が最新に保たれておらず、
システムの全容を把握することが難しくなっていた。そ
こでN社がパッケージソフトを利用した保守効率の高い
システム開発を提案し、受注に至ることになった。
 使用するパッケージソフト(以下、N社パッケージ)
は当時のN社の新製品である。汎用的な機能を一通り揃
えておりカスタマイズ性も高い。一方で導入実績はあま
り多くなく、ノウハウが無い点に弱みがあった。N社と
して今後のシェア拡大のためにも、本プロジェクトは絶
対に失敗が許されないものであった。
1.2 プロジェクトの関係者
 本プロジェクトのメンバは主に3つに分けることが出
来る。まずN社金融担当部門の開発メンバと、N社技術
部門の技術支援メンバである。最後が利用部門となるA
社会系部門のシステム担当者だ。
 技術支援メンバはN社パッケージの導入支援に当たる。
開発メンバの大多数はN社パッケージの開発経験がない
ため、外部からのサポートが必須だからだ。
 A社のシステム担当者は、主に要件定義の際に協同し
た。N社がA社のシステムを開発するのは初めてなので、
仙人の担当者が数名設置されたのだ。しかしシステム担
当者と言っても、情報分野へさほど詳しい知識は持って
いなかった。現行システムは外注して作らせたものであ
り、しかも当時のシステム担当者は既に退職していたの
だ。
 私はこれらの状況から、関係者間での円滑なコミュニ
ケーションが重要となるだろうと考えていた。

2.1 重要と考えた関係者とその理由
 本プロジェクトは1.新しいパッケージソフトを使用す
る、2.利用部門のメンバの知識が少ない、という2つの
問題を抱えていた。技術と業務の知識を、どう開発メン
バに与えていくかがプロジェクトの成否を左右する。そ
こで私は、以下の関係者とコミュニケーションを取って
いく必要があると考えた。
 1)技術部門のN社パッケージ責任者
 本プロジェクトには技術支援メンバがアサインされて
いるが、私はそれだけでは対処できないリスクがあるこ
とに気付いた。例えば未発見の重大なバグを見つけた時
や、ハードウェアとの相性問題が発生した時などである。
このような不測の事態に少数のメンバで対処しきること
は難しい。
 そこで私は、N社パッケージの責任者に話を付け、有
事の際にサポートが得られるよう要請した。
 2)A社会系部門のトップであるR部長
 前述のとおり、A社会系部門の担当者は現行システム
の知識に乏しい。つまり仕様確定には、システム面だけ
でなく業務面での情報に頼らざるを得ない。
 そこで私は、A社会系部門のR部長を重要な関係者だ
と判断した。R部長とのコミュニケーションにより、一
般社員との接触や業務知識の入手が可能になるからだ。
2.2 重要な関係者とのコミュニケーションの内容や
 方法
 上述のように、私は情報の入手を目的として重要な関
係者とのコミュニケーションを図った。そのためには、
こちらの情報も提供して相互理解をした上で、継続的な
関係を築く必要がある。したがって私は、以下の方法に
より、コミュニケーションを行うことにした。
 1)キックオフミーティング
 プロジェクト開始に先立ち、私は関係者全員を集めて
キックオフミーティングを行った。その場にはもちろん
N社パッケージの責任者やA社のR部長も招いた。そこ
でプロジェクトの概要と課題を説明し、関係者一同に状
況の理解を促した。特に重要な関係者向けに、プロジェ
クトの抱えるリスクを具体的に説明し、その対処への支
援を強く呼びかけた。
 2)月次ミーティングへの参加呼びかけ
 プロジェクトでは各チームリーダによる月次ミーティ
ングを行っていたが、そこに重要な関係者にも参加して
もらうことにした。工夫した点としては、報告内容をな
るべく減らし重要なものに絞ることである。なぜならば
重要な関係者にはクリティカルな部分での助力を期待し
ており、細かな問題に気を取られて欲しくないからだ。
また、月次ミーティングを退屈で苦痛なものだと感じら
れてしまうと、モチベーションが低下して困るという問
題もある。

3.1 コミュニケーションの内容や方法についての評
 価
 私の行ったコミュニケーションは概ね成功したと考え
ている。キックオフミーティングでは私の熱意が通じて
重要な参加者が協力的な姿勢を見せてくれた。さらに月
次ミーティングにもほぼ毎回出席があり、重大な指摘が
なされたり、要員面での協力を約束したりといった良好
な関係が続いた。システム自体も無事本番稼働をむかえ
ており、現在に至るまで安定運用されている。
 しかし問題が全く無かった訳ではない。今回予算や費
用について重要な関係者を設定しなかったが、その点で
少々議論が起きたことがあった。A社会系部門に要件定
義のサポートを依頼した際、どちらが費用を負担するか
もめたのである。具体的には私の上長が予算増加をなか
なか承認してくれず、A社のR部長と何度も交渉を重ね
ることになったのだ。
3.2 今後の改善の方法
 以上の問題を再発させないため、私は次のような改善
策を行なって行きたい。
 1)費用面でのコミュニケーション
 上記の問題は私が重要な関係者を見る範囲が狭いゆえ
に起きたものである。よって今度からは自社/他社とも
に広い関係者を巻き込んでコミュニケーションを行いた
い。具体的にはN社内の予算承認者や、発注者側の意思
決定者といった費用に関わる関係者である。
 2)プロジェクト開始前からのコミュニケーション
 今回はプロジェクト開始後に他社に支援を要求したの
が良くなかった。そこで次回からは、プロジェクト前か
ら関係者とコミュニケーションを取りたい。あらかじめ
必要な支援を割り出しておけば後で問題になることも少
ないだろうし、より密な関係を築けるからだ。
                     −以上−

Comments