firisu the shooter

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

平成19年 問2

システムが対象とする企業・機関
1. プロジェクト名称 パッケージソフト適用による金融機関向け会計システムの開発
2. 企業・機関等の組織・業種 金融・保険・不動産
3. 企業・機関等の規模 301〜1000人
システムの規模
4. 対象業務の領域 会計・経理
5. 主なハードウェア クライアントサーバシステム(サーバ約3台)
6. ネットワークの範囲 同一企業・同一機関の複数事業所間
7. システムの利用者 101〜300人
プロジェクトの規模
8. システムの端末数 101〜300台
9. 総工数 90人月
10. 費用総額 80百万円
プロジェクトにおけるあなたの立場
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
1−1.プロジェクトの概要
 私は大手SI企業であるS社のプロジェクトマネージャ
である。論述対象であるA銀行の会計システム再構築プ
ロジェクトに全体責任者として参画した。
 当プロジェクトは、A銀行の会計システムがハードウ
ェア保守期限をむかえることにより発足したものである。
設計書類が最新の状態を保っておらず、度重なる機能拡
張により保守効率が低下していた。開発費用をなるべく
おさえて、メンテナンス性の高いシステムを構築したい
という要求から、パッケージソフトを適用する方針とな
っている。また、会計システムの性格上、納期厳守も当
然の条件とされていた。
 当プロジェクトで使用したのは、当時のS社の新製品
パッケージだった。汎用的な機能を押さえてはいるが、
適用事例はあまり多くないという点に弱みがあった。
1−2.情報システム開発の委託元に本稼働開始の可否
 について判断を仰ぐために用意した材料
 A銀行の旧会計システムは、長年の機能追加の果てに
非常に複雑な構造をしていた。そのため、その全容を把
握するには会計担当者やシステム担当者との密な連携が
必要であり、コミュニケーションコストが非常に高くつ
いた。私は、機能の漏れが無いよう慎重にプロジェクト
を管理していたが、運用テストにおいて問題が発生した。
一部の会計科目において処理結果の不整合が起きたので
ある。
 当プロジェクトは開発期間が8ヶ月と短く設定されて
おり、同時に納期厳守でもある。そこで私は、A銀行に
本稼働開始の可否を仰ぐため、以下の材料を用意した。
 1.必要な作業とその工数の見積もり表
 2.機能を段階稼働させると想定した場合のスケジュー
 ル表
 3.機能を段階稼働させる場合の影響範囲

2−1.本稼働までに解決できないと認識した課題
 処理結果の不整合は、運用テストにおいて新旧システ
ムの並行稼働を行った時に発覚した。S社パッケージに
精通したITアーキテクトに相談することで大まかな原因
をつかむことは出来た。すなわち1.データ処理のロジッ
クが正しくない、 2.勘定科目データの読み取り部が正
しくない、のいずれかである。
 それらの機能について、開発メンバにプログラムと設
計書の突き合わせを指示したが、全ての設計仕様が充足
されていることが分かった。つまり設計書それ自体に誤
りが存在したのである。しかし、誤りの特定と修正を行
おうにも本稼働が差しせまっており、対応し切れない事
態であることは明白だった。
2−2.課題を残して本稼働を開始した場合の影響範囲
 処理結果の不整合は、次のような箇所で発生していた。
1.月次処理の一部科目、2.会計年次ごとの統計算出結果
の一部、の2点である。幸いなことにこれらの処理は日
常業務で使用されるものではない。しかし前者に関して
は会計帳票の作成、後者は経営資料の作成に必要となる
ものなので、利用部門や経営層にも影響がある。すなわ
ち、機能の完全な網羅を本稼働後に実現するにしろ、そ
れまでの間は何らかの代替手段が必要になるのだ。
2−3.課題を残した本稼働を補うための対応策
 私は課題の優先順位と緊急性を考え、以下の対応策を
実施することにした。
 1.旧システムを待機系として利用する
 本稼働後、すぐに問題となるのが月次処理だった。し
かし新システムの月次処理の手戻りは3週間を見込んで
おり、本稼働した月中には間に合いそうにない。そこで
旧システムを待機系とし、月次処理の一部を担当させる
ことにした。月次処理の結果不整合は月次マスタファイ
ル作成に原因があるため、その部分だけ旧システムに処
理させることにしたのである。
 これにより運用担当者の手間が増すことになってしま
ったが、1−2で述べた材料を元に説明を行い、なんと
か同意を得られた。
 2.年次データの作成順の変更
 年次統計は会計年次が切り変わる時点で終了していれ
ば良いため、必要データの作成を遅らせる対策をとった。
すなわち、毎月末に行う統計一時データの作成を、会計
年度ぎりぎりにまとめて実行させることにしたのだ。
 これも運用手順の若干の変更を伴うが、作業順序が入
れ替わるだけで負担増とはなっていない。

3−1.対応策への評価
 私の実施した対応策はおおむね上手く行ったと評価し
ている。本番稼働後の追加開発により処理結果は正常に
なり、その間に実施させた代替運用でもトラブルは発生
しなかった。システムは現在に至るまで安定稼働してお
り、今のところなんの問題も起きていない。
 しかし運用手順の変更による運用担当者の負担増や、
そもそも追加開発が必要となってしまう事態を回避でき
なかったことを考えると、改善の余地があると私は考え
ている。
3−2.今後行いたい改善策
 今回のようなケースに対し、今後は次のように改善を
していきたい。
 1.運用手順の早期策定
 今回は運用手順の変更が決定された後でその詳細を決
めるという流れを取っていた。今後は手順変更での対応
を決定した時点で手順の詳細も確定したい。今回で言え
ば、1−2で述べた材料に運用手順書も含めるべきだっ
た。そうしておけば、運用担当者の混乱を最小限に抑え
ることが出来たからだ。
 2.追加開発の最小化
 今回、処理結果の不整合が発生した時点で追加開発と
段階稼働を決定したが、これは早急な判断だったと反省
する。もう少し熟慮すれば、段階稼働の負担を減らすこ
とが出来ていたように思えるからだ。例えば月次処理の
手戻りは3週間との見込みだったが、これを残業などに
より本稼働前に終わらせることも可能だったのではない
か。段階稼働有りきではなく、それまでの間に実行でき
ることについても、今後は考えを持って行きたい。
                     −以上−

Comments