firisu the shooter

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

平成20年 問1

システムが対象とする企業・機関
1. プロジェクト名称 WEBを利用した通信教育(E-ラーニング)システムの開発
2. 企業・機関等の組織・業種 その他サービス
3. 企業・機関等の規模 301〜1000人
システムの規模
4. 対象業務の領域 その他(サービス)
5. 主なハードウェア Webシステム(サーバ約5台)
6. ネットワークの範囲 他企業・他機関との間
7. システムの利用者 1001〜3000人
プロジェクトの規模
8. システムの端末数 1001〜3000台
9. 総工数 120人月
10. 費用総額 95百万円(ハードウェア費を含まない)
プロジェクトにおけるあなたの立場
11. 期間 2007/04〜2008/02
12. あなたが所属する企業・期間等 ユーザ企業等のシステム部門
13. あなたの担当したフェーズ システム企画・計画, システム設計, プログラム開発, システムテスト, 移行・運用
14. あなたの役割 プロジェクトの全体責任者
15. あなたの管理対象人数 10〜15人
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
123
124
125
126
127
1.1 プロジェクトの概要
 A社は資格教育サービス業者である。都内に複数の予
備校を持ち、対面式の授業と資格教材の販売をしている
大手の企業である。A社ではここ数年新規顧客への売上
が伸び悩んでおり、魅力的な商品の開発が急務とされて
いた。新年度の経営会議でいくつかの新プロジェクトが
立上げされることになり、その一つがWEBを利用した
通信教育(E-ラーニング)システムの開発である。当
システムではオンデマンドの授業動画の配信や、画像を
多用した教材の掲載など、マルチメディアコンテンツを
売りにしている。しかし、当時のA社にはWEBシステ
ムの開発経験がなく、プロジェクトは厳しいものとなる
であろうことが予測された。
 私はA社情報システム部に所属するSEであり、当プ
ロジェクトのプロジェクトマネージャに任命された。開
発期間は約10ヶ月で、走行数は120人月ほどである。開発
メンバは全てA社の社員で構成されていた。
1.2 合意を得られた利用部門の作業
 当システム  を実際に利用するのは、顧客へサービ
ス提供を行う業務部門である。その担当作業としては、
①テキスト・画像・動画といった教材コンテンツの作成
、②要件定義書・外部設計書の承認及びレビュー、③シ
ステムテストへの参加などが挙げられる。
 作業範囲の合意は早期に得ることが出来たが、具体的
な担当料の確定に多少手間どった。業務部門としてはな
るべく作業量を減らしたいわけだが、システム部門とし
てはそれだと困るのである。最終的にシステム部門が最
大限に作業環境を整えるという条件で、業務部門には私
が設定した担当作業を全て行なってもらえることになっ
た。更に私は、プロジェクトへの参加メンバについても
教材作成に熟練した要因をアサインするよう調整を行い、
業務部門長の許可を得ることが出来た。

2.1 利用部門の作業が計画どおりに実行されなかっ
 たことによって発生した問題と原因
 当プロジェクトでは、メンバを管理チーム・技術チー
ム・開発チーム・業務チームの4チームに分けた体制を
とった。実作業を行うのは開発チームと業務チームであ
る。このうちシステムの利用部門にあたる業務チームの
作業が計画どおりに実行されないという問題が起きた。
具体的に遅れが起きたのは下記の2つの作業である。
1)外部設計書の承認遅れ
 外部設計工程が半ばを過ぎたころ、レビュー後の設計
書を業務部門に承認してもらうアクティビティに遅れが
見られるようになった。週次報告会議の際に業務チーム
のリーダーに詳しく話を聞いたところ、業務部門が繁忙
期に入り多忙のため、作業時間が充分にとれなくなって
いることが分かった。私はすぐに業務部門長に掛け合い、
プロジェクトの作業に専念できるようにして欲しいと要
求した。しかしその答えは「今は業務部門全体が多忙で
あり、とても調整は出来ない。定例業務のため後回しに
することは難しい」という一点張りであった。
2)初回配信コンテンツの作成遅れ
 開発チームがシステム製造を行うのに並行して、業務
チームが初期配信コンテンツの作成を行う段取りを取っ
ていた。しかしそのコンテンツ作成が計画の8割程度の
進捗速度にとどまるという問題が起きた。その一連のア
クティビティはクリティカルパス上にはなく、表面的に
はプロジェクトへの遅れは発生しない。しかし次にひか
えるテスト工程のテストケースへの遅れにつながりかね
ないため、対策は必須だった。デッドラインは1ヶ月以
上先だが、遅れを積算すると計画より既に2週間分のマ
イナスとなっていたのだ。
 この遅れを詳しく調べたところ、コンテンツ作成ソフ
トの使い勝手に起因するものだと判明した。それは業務
チームからのヒアリングですぐに分かった。この段階で
は業務チームの作業時間には余裕があり、コンテンツの
元となる教材や使用する機材も揃っていたので、他に原
因はないと判断できたのである。
2.2 納期や予算を守るために実施した対策
 私はこれらの問題につき、その原因に応じた対策を実
施した。その際にはプロジェクトの納期と予算を守れる
よう効果を事前に見積もることも忘れなかった。
1)外部設計工程の作業入れ替え及び内部設計工程の前倒
 し
 私は業務部門長との交渉を続け、少し先の繁忙期が収
まった時期にまとまった作業時間を取ってもらえるよう
合意を得た。しかしその頃には内部設計が開始しており、
外部設計全体としては間に合わない。そこで私は、業務
チームの参加が必須のユーザインタフェース関連のアク
ティビティを後回しにした。さらに業務チームとは関わ
りの薄い内部設計の一部のアクティビティを前倒しして
実施することにした。こうすることによりメンバの手持
ちが無くなった上に、作業の並行化で既存の遅れを取り
戻すことが出来た。遅れの量が一週間未満と比較的小規
模だったため、作業順序の入れ替えによる混乱が起きに
くいと判断したのだ。また、この手法なら追加予算もか
かることはない。
2)コンテンツ作成ソフトの勉強会実施
 コンテンツ作成段階では開発チームの進捗は順調だっ
たため、彼らを主体とした勉強会を開催した。目的はも
ちろん業務チームの教育である。ツールの選定を行なっ
たのが開発チームであったため、効果的な指導となるだ
ろうと考えたのだ。このアクティビティは計画にはない
ものだったが、未消化のバッファを割り当てたため、進
捗に影響が出ることもない。

3.1 対策への自己評価
 私は実施した対策はおおむね上手く行ったと考えてい
る。いずれの問題においても発生した遅れを回復するこ
とが出来たし、プロジェクトの納期と予算を守ることも
出来た。実稼働をむかえた後も、今に至るまで問題は起
きていない。
3.2 今後改善したい点
 今後改善したい点としては、対策ではなく予防に力を
入れることである。まず1)の問題では業務チームの多忙
が原因であったが、それは定例業務であり事前に把握で
きる問題のはずである。メンバのプロジェクト参加可能
時期は、本来プロジェクトマネージャたる私が厳密に調
べておくべきことである。次回からはこの点を計画段階
にて充分考慮しなくてはならないと深く反省している。
 次に2)の問題については作成ツールの使い勝手が問題
となった。これに対しては①ツールの選定段階で業務チ
ームの意見を取り入れておく、②初めからツールの勉強
会を計画に盛り込んでおく、という2つの観点から改善
が可能であると考えている。特に②の勉強会については
当初業務部門へ「最大限の作業環境を整える」との約束
をしたにも関わらず逸しており、完全に私の手落ちと言
える。後々の信頼関係にも影響するものなので、プロジ
ェクト報告書にも教訓として記録した上で、業務部門へ
正式に謝罪も行った。
 今回のプロジェクトは全体として無事完了に至ること
が出来たが、上記のように明確なミスもあった。A社が
社内開発を行う企業だということを踏まえ、今後は、よ
り計画性のあるマネジメントを実行できるようになりた
い。
                     -以上-

Comments