firisu the shooter

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

平成20年 問2

システムが対象とする企業・機関
1. プロジェクト名称 パッケージソフト適用による製造業向け会計システムの開発
2. 企業・機関等の組織・業種 製造
3. 企業・機関等の規模 301〜1000人
システムの規模
4. 対象業務の領域 会計・経理
5. 主なハードウェア クライアントサーバシステム(サーバ約3台)
6. ネットワークの範囲 単一事業所内
7. システムの利用者 31〜100人
プロジェクトの規模
8. システムの端末数 31〜100台
9. 総工数 120人月
10. 費用総額 95百万円(ハードウェア費を含まない)
プロジェクトにおけるあなたの立場
11. 期間 2007/04〜2007/12
12. あなたが所属する企業・期間等 ソフトウェア企業・情報処理サービス企業等
13. あなたの担当したフェーズ システム企画・計画, システム設計, プログラム開発, システムテスト, 移行・運用
14. あなたの役割 プロジェクトの全体責任者
15. あなたの管理対象人数 10〜15人
16. あなたの担当期間 2007/04〜2007/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
【ア】
1−1.情報システム開発プロジェクトの概要
 A社は電子部品の製造を営む地方企業である。システ
ム老朽化による運用コスト増大に対処すべく、会計シス
テムの再構築を実施することにした。会計システムとい
う性格上、納期を厳守する必要があり、製造コストを押
さえるためにもパッケージソフト適用による開発を決定
した。開発の条件としては、現行のシステムの機能を漏
れなく充足することが挙げられた。A社は社内に開発要
員を持たないため、SI企業であるS社に開発を外注す
ることにした。私はS社のSEであり、プロジェクトマ
ネージャとして本開発プロジェクトに参画した。
 なお、開発で適用するパッケージソフトはS社の新製
品である。汎用的な機能を揃えてはいるものの、適用事
例がまだ少ない。そのためカスタマイズ範囲の早期把握
がプロジェクトにおける重点事項であった。
1−2.プロジェクト遂行中に察知した問題の兆候
 当プロジェクトでは機能要件を早期に固めるため、外
部設計においてプロトタイプを利用していた。利用部門
であるA社会系担当者にプロトタイプを使用させ、動作
確認してもらうことが主な目的である。動作確認時のユ
ーザの反応に着目し、意見・要望を引き出すことで、高
品質の設計が実現できると考えていた。
 しかし、外部設計が終わりに近付いた時、私は1つの
兆候に気が付いた。設計開始当初と比べてユーザからの
意見・要望数が激減しているのである。プロトタイプの
利用時にはチェックリストに基づき動作確認を行い、全
てのチェックが済んだあと意見・要望を聴取することに
なっている。当初はA社担当者があれこれと積極的に意
見を出していたのだが、最近では規定の動作確認を行な
ったらそれで終了ということが多くなっていた。

【イ】
2−1.兆候の詳細や出現の背景についての調査
 私はまず意見・要望数が減るという兆候の詳細を調査
した。設計終了が近付くにつれて仕様の変動が少なくな
るのは一般的なことであり、それがユーザからの意見減
少という形で現れているだけかもしれないからだ。時系
列ごとの意見数の推移表を作成したところ、確かに全体
的な減少傾向が見られた。しかし外部設計の半ばごろを
境い目にして急激な減少が見られ、意見ゼロということ
も度々あった。
 私はこの兆候を看過せず、A社側に何らかの異変が起
きていると判断した。そのため兆候出現の背景を知るべ
くA社担当者にヒアリングを実施した。そうしたところ、
A社内に異動があり会計部門の人員が減った結果、日常
業務が多忙で当プロジェクトに時間が割けなくなってい
ることが分かった。
2−2.兆候を静観した場合に起きうる問題とその根拠
 私はこの兆候を静観した場合に、どのような問題が起
きるか考えてみた。短期的な観点から言えば、特に問題
はない。なぜなら外部設計は滞りなく進んでおり、内部
設計以降はシステムテスト開始前までS社のみで開発が
進むからである。
 一方で長期的な観点からは、次のような問題が考えら
れる。1.外部設計に機能の把握漏れができ、後になって
大幅な手戻りが発生する。2.システムテスト・運用テス
トにおいてA社担当者の十分な協力が得られず、進捗遅
れにより本番稼働を実施できない。時間が経てばA社側
の多忙が解決される可能性もあり、必ずしも大きな問題
が発生するとは限らない。しかし8ヶ月という短い開発
期間を考慮すると、万が一にも手遅れになってからでは
対処のしようがない。
 以上のような考えから、私は何らかの対策を打つべき
であると判断を下した。
2−3.実施した対応策
 今回の兆候はA社の体制によるものだが、私はS社と
しても出来る限りの対応を行なっていくべきだと考えた。
 1.A社会系部門長への働きかけ
 私はまずA社担当者の多忙そのものを解決しようと試
みた。そのためにA社会系部門長であるR氏に対し、業
務量の調整や人員増加を依頼しに行った。プロジェクト
のキックオフミーティング時に顔合わせを済ませていた
こともあり、快く話を聞いてもらうことができた。しか
し結論を言えば、費用の問題があり対応は難しいとのこ
とだった。
 2.S社体制の増強
 A社側の対応が難しいとわかり、私は次にS社で実施
可能な対応を取ることにした。社内にA社業務に精通し
た社員がいることが分かったので、急きょプロジェクト
へ参画してもらったのである。その社員には外部設計書
のレビューに参加してもらい、機能の把握漏れがないか
徹底的にチェックしてもらった。
 また、システムテスト時に一時的に参加メンバを増員
することにした。もしA社担当者の協力があまり得られ
なかった場合に、十分な品質を担保すべくテストを行う
ためである。増加メンバには規定を満たしているかの単
調なテストを割り当て、既存メンバには機能間の矛盾洗
い出しなど複雑なテストを割り当てるよう工夫した。

【ウ】
3−1.活動への評価
 私の実施した対応策はおおむね上手く行ったと考えて
いる。A社業務に精通した社員による設計書レビューに
より、いくつかの仕様の抜けを発見でき、設計品質が向
上した。また、やはりA社側の多忙は解消されなかった
が、テスト要員を増強したため本番稼働にも間に合った。
システムは現在に至るまで安定稼働しており、大きな問
題は起きていない。
 しかし費用面でいえば計画より大分増加してしまった。
問題への対応がメンバ増員ありきだったことが原因であ
る。その点から言えば当プロジェクトは大いに改善の余
地がある。
3−2.今後実施したい改善策
 今後私は以下のような改善策をとっていきた。
 1.業務知識を考慮したメンバ選定
 当プロジェクトでは、新製品のパッケージを適用する
こともあり、パッケージを熟知した社員を中心にメンバ
を選んだ。これを次からは業務知識も考慮してメンバ選
びを行うようにしたい。今回急きょ増員したレビュー担
当の社員は、初期から参画させていれば追加費用が発生
せずに済んだからである。
 2.上長を通した顧客との交渉
 今回A社側の体制について私が直接交渉をしたが、今
後はS社内の上長を通して交渉をしたい。当プロジェク
トはA社にとって重大なミッションであるはずで、S社
として強気に交渉に出ても良いと考えられるからだ。い
わゆる「痛み分け」ならまだしも、一方的に自社内で問
題を抱え込んでしまうのは一社員として良くない行動で
ある。費用増大による収益圧迫という結果になってしま
ったのは私の責任であるので、この点は深く反省し二度
と繰り返さないようにしたい。
                     −以上−

Comments