firisu the shooter

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

平成17年 問3

システムが対象とする企業・機関
1. プロジェクト名称 パッケージソフトを利用した会計システムの再構築
2. 企業・機関等の組織・業種 金融・保険・不動産
3. 企業・機関等の規模 1001〜5000人
システムの規模
4. 対象業務の領域 会計・経理
5. 主なハードウェア クライアントサーバシステム(サーバ約3台)
6. ネットワークの範囲 同一企業・同一機関の複数事業所間
7. システムの利用者 301〜1000人
プロジェクトの規模
8. システムの端末数 301〜1000台
9. 総工数 170人月
10. 費用総額 140百万円
プロジェクトにおけるあなたの立場
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
115
116
117
118
119
120
121
122
1.1 プロジェクトの概要
 私は独立系SI企業N社のSEである。都内に拠点を持
つ金融機関A社の会計システム再構築プロジェクトに、
全体責任者として参画した。A社の会計システム(以下
、現行システム)は度重なる保守によりメンテナンス性
が低下していた。また設計書類が最新に保たれておらず、
システムの全容を把握するのが難しい状態にあった。そ
こでN社がパッケージソフトを利用した保守性の高いシ
ステム開発を提案し、受注に至った。
 使用したパッケージソフト(以下、N社パッケージ)
は、当時のN社の新製品である。汎用的な機能を一通り
揃えており、カスタマイズ性も高いのが強みだ。一方で
導入実績はあまりなく、ノウハウが少ないのが弱みだっ
た。N社にとって当プロジェクトは、今後のパッケージ
シェア拡大のためにも、絶対に失敗できないものだった。
1.2 チームの再編成によって対処した問題
 当プロジェクトは金融担当部門のメンバからなる開発
チームと、技術部門のメンバからなる技術支援チームが
協力して開発を進めていた。開発チームの大部分がN社
パッケージを未経験だったので、それを技術支援チーム
の設置により補おうとしていたのだ。
 しかし外部設計の半ばごろに問題が発生した。設計書
作成タスクの進捗が目に見えて遅いのである。遅れのポ
イントを調査したところ、レビュー毎の指摘事項件数が
計画の2倍近くに昇るようになっていた。開発チームの
リーダに話を聞いてみると、レビューでの指摘はほぼ全
て技術支援チームによりなされたものだという。パッケ
ージの設計基準にのっとった正しい指摘が多いのだが、
当の開発チームにその対応力が無いことが分かった。
 当初2チームには、情報共有を初めとした協働関係を
期待していたが、その考えは間違っていたかもしれない
と私は思い始めた。私はチームの再編成を決意した。

2.1 チームの再編成を行った方法と、再編成が適切
 だと考えた理由
 私がチームの再編成を適切だと考えたのは、当初の2
チーム体制が上手く機能していなかったからである。具
体的には技術支援チームのメンバが、外部からのオブザ
ーバに留まっているのがよろしくないと考えた。
 そのため私は、各メンバがもっと積極的に協力しあえ
るよう、以下のようにチームの再編成を行った。
 1)技術支援チームの専任化
 技術支援チームのメンバは当プロジェクト以外にも仕
事を抱えており、必ずしも多くの時間を割ける状態には
なかった。そこで私は技術部門長と交渉し、技術支援チ
ームを当プロジェクトのみにアサインしてもらうよう要
請した。その際には、当プロジェクト成功とパッケージ
シェア拡大による全社的なメリットの大きさなどを説き、
WIN−WINの関係になれることを強調した。その結
果、一部メンバを若手社員に入れ替えるという条件で、
技術支援チームの専任化を正式に行えるようになった。
 2)チームの結合と再分割
 私は一度両チームを1つに統合し、機能A・Bの2つ
のチームに再分割した。A・Bチームにはそれぞれ元開
発チームと元技術支援チームのメンバが半々おり、チー
ムリーダーも元チームから1人ずつ選出した。これによ
り公平な発言と活発な意見交換を促して、パッケージの
厳しい設計規則を乗り越えられる知恵が出ることを期待
したのだ。
2.2 チームの再編成による効果をどのように確認し
 たか
 1)連帯意識の確認
 私はチームの再編成をした後、何よりチーム内の連帯
意識の状態が気になった。レビュー内での厳しい指摘を
根に持ったメンバが、連携の足を引っ張るかもしれない
と考えていたのだ。しかし結論から言えばそんなことは
全くなかった。というのも、元技術支援チームの専任化
が功を奏していたのだ。お互いが対等な立場で開発を進
められるようになったので、白熱した議論が連帯意識を
かえって強める結果に繋がっていた。仕事中のさりげな
い様子を観察している限りでも、良好な人間関係が出来
ているように見えて、確かな効果があったことを私は感
じていた。
 2)進捗遅れの回復の様子
 しかし1)で述べた連帯意識も、何かしら定量的な効果
が得られなければ意味がない。そのため私は各種の管理
指標、すなわち、レビューでの指摘件数の推移や設計タ
スクの進捗回復度合いを観察し続けた。
 まずレビュー指摘件数は、再編成直後こそさほど変わ
らなかったものの、外部設計終了が近付くにつれて計画
値との差が縮まっていった。逆に内部設計が始まってか
らは計画値を下回ることが多かった。これはもちろん品
質の高まりによるものであり、他の管理指標からもそれ
が見て取れるようになった。
 また、肝心の進捗遅れも回復を見せ、2週間あった遅
れも2ヶ月ほどで取り戻せた。それは内部設計の終了直
後のことであり、後続の工程への影響は出ずに済んだ。
 このような数字上のデータからも改善の効果を私は確
認した。

3.1 チームの再編成についての評価
 私の行った再編成は概ね成功だったと考えている。シ
ステムは無事本番稼働をむかえており、現在に至るまで
大きな問題は起きていない。
 しかし、次のような点では改善が必要だと感じている。
 1)新規メンバへの配慮不足
 技術支援チームの専任化を行った時、一部メンバが若
手社員と入れ替えられたが、その若手社員への配慮が足
りなかった。プロジェクトの前提知識もなくアサインさ
れたので、当初は仕事を上手くこなせていないようだっ
た。
 2)専任化によるコスト増大
 メンバの専任化により、プロジェクトのコストが増大
した。というのも当初計算していた技術メンバの稼働率
が0.3→1.0へと大幅に上がったからだ。これを必要事項と
してそのまま受け入れてしまったのは良くなかった。
3.2 改善の方法
 以上のような問題に対し、私は以下のように改善して
いきたい。
 1)再構成に伴う全体ミーティング
 メンバの入れ替えが発生する時は全体ミーティングを
開催したい。そこで再構成へ至った経緯を説明し、新メ
ンバへの受け入れ研修方法などを議論するのだ。そうす
ることで、再編成直後の混乱をおさえて効率的なプロジ
ェクト運営が可能になるからだ。
 2)山積み債権さんからの必要要員割り出し
 今回技術支援チームを全員当プロジェクトへ付け替え
たが、これはやりすぎだった。次からは必要工数の計算
をしっかりやり直し、最低限の稼働だけで済むようにし
たい。コストを犠牲にした上でのプロジェクト完成は、
健全なやり方とは言えないし、会社に損失を与える可能
性すらあるからだ。            −以上−

Comments