メディア

スケジュールとコストは、ユーザー側が始めからつかめ：ユーザーサイド・プロジェクト推進ガイド（3）（2/2 ページ）

» 2005年12月14日 00時00分公開

[山村秀樹，＠IT]

スケジューリング上の注意点

ベンダ任せの竜頭蛇尾プロジェクトにしない

　プロジェクトにベンダが入ってくるフェイズになっても、ユーザー側のプロジェクトチームはスケジュール管理の手綱を手放してはなりません。

　失敗としてよくあるのは機能要求定義の段階で時間配分がうまくできず、竜頭蛇尾に終わるケースです。ある業務部門に関する機能要求仕様が決定してから次の業務部門の調査を開始する形で進めていくと、調査に予想以上の時間がかかった場合、初期に調査した業務部門の要求ばかり大きく、最後の業務部門の要求をほとんど取り入れることができなくなります。これはプロジェクト管理がされていないことにほかなりません。「プロジェクト管理はベンダがすること」と思い込んでいるとこうなります。途中で気付いてもすでに手遅れになっているか、リカバリするとしてもかなり無理をしなければならなくなります。

　いくらベンダに高いプロジェクト管理費を払っているといっても、ベンダはプロジェクトの最上流であるユーザー側の作業に対して、進ちょく遅れなどの警告を出す以上のことはできません。実際、ユーザー側のプロジェクトチームはベンダの配下で作業していません。ユーザーはベンダの管理対象ではないのです。むしろ、ユーザーがベンダからの進ちょく報告をしっかりとチェックすべきです。

テストのための業務停止タイミングに気を配る

　複数の部門にまたがる大規模なシステムなどでは、この段階から、そのシステムが関係するサービスや全設備をやめる時期が取れるかどうか注意しておく必要があります。システムのリプレイスであれば、移行時だけでなく、そのほかの機会にも、既存システムを停止して開発システムを本番環境で稼働テストする必要があり、数回のシステム停止期間は必要となります。サービスや生産を管理している部署にかなり早めに連絡しておかないと、数少ないテストのチャンスを逃す事態になる恐れがあります。その時期と期間について気を配る必要があります。

カットオーバーまでの作業を網羅する

　スケジュールを立てるには、どのような作業があるのかをすべて知っておくことが前提となります。ユーザーサイドの（カットオーバーまでの）スケジュール表に載せる作業項目（工程）には以下のものがあります。

プロジェクトチーム編成
社内作業ルール作成、メンバーの教育
経営層、各業務部門、その関係部門、取引先など各関係者の機能要求仕様調査（ヒアリング、伝票や帳票、既設システムの調査など）
見積もり要求仕様作成、ベンダへ送付
ベンダから見積もり回答仕様受領、ネゴシエーションやベンダの調査を経てベンダ決定
プロジェクト（予算）承認申請、ベンダと契約、作業ルールの作成
関係者向けプロジェクト説明会の開催
関係者ごとに機能要求仕様の詳細決定
全体的な機能要求仕様決定
関係者やベンダと機能要求仕様、画面、帳票仕様、セキュリティポリシーなど決定
ベンダの製作仕様書を承認
開発場所（室）の用意
ベンダにて開発、テスト、メンテナンスツールの作成
コンピュータルームの整備、ケーブル敷設、ハードウェアの搬入、据付
プロジェクトチームや業務部門など関係者の立会いテスト
運用（並行）テスト、稼働判断
データ移行仕様決定、システム移行失敗時の手順作成
ベンダにてデータ移行ソフト開発、テスト
移行立ち会いテスト
エンドユーザー教育

　このほかにも、関連設備やシステムの機能の変更や追加を伴う場合、それぞれの設備やシステムに関して、現状の調査、仕様の決定、各設備のメーカーや各システムのベンダとの見積もり交渉、変更や追加などの実作業・テストがスケジュールの項目として増えます。これらの作業負荷は決して軽いとはいえません。また、仕様の変更があれば、当然、それに伴って見積もり交渉などの作業が増えることになります。

　スケジュールを感覚としてつかむために、まずはガントチャートで表してみてください。ガントチャートはスケジュールを分かりやすく表示する図表で、作業バランスの確認や調整に便利です。ガントチャートにすると、プロジェクトにはカットオーバーするまでにしなくてはならないことがたくさんあり、カットオーバー時期からベンダが開発に必要とする期間を引いた（ユーザー側の作業である）機能要求仕様の作成に費やすことのできる期間は、思いのほか短いことが分かります。

※「ガントチャート？面倒だ」という人は、「Elie_Schedule」を試してみてください。筆者が作成したもので、Microsoft Excel上でガントチャートを描画します。

ダウンロード

▼Elie_Schedule（Elie_World）

時間不足をベンダ丸投げで解決しない

　コスト削減が厳しく進められる中、残業規制も厳しく、システム担当部署のトップがシステム開発に明るくなければ「機能要求仕様の策定をベンダにさせろ」と指示するかもしれません。客である立場を利用し、ベンダとの契約書にそれなりの文言を挿入させ、ベンダに無理な作業を強要したりするわけです。

　しかし、これはするべきではありません。自社で作業することによって得られる貴重な知識や経験を放棄することになります。特に、よりよいやり方を考える習慣や技術を身に付けるチャンスを放棄することは大きな損失です。また、もともと無理な作業は無理なのであり、できないことをやらせようとしてもうまくいくわけがありません。

　ベンダに無理を強いることを自慢する人もいますが、その人はビジネスを知らないのではと思えます。良いビジネスには良好な取引関係が必要であり、受注側も発注側も両者が得するWin-Win関係を構築することが重要だと考えています。ビジネスである以上、両者の間に緊張感があることは自然なことですが、片一方の無理難題の押し付けなどはどちらにとっても得になるとは思えません。

　相手に無理を押し付けるということは、ベンダも企業であって利益を出すことを目的としていること、株主や取引先などステークホルダーが存在することを認識していないように思えます。利益を出さなければならない組織が、損失を出したままにしておくわけがありません。保守費用や改造費用に上乗せし、取り戻そうとします。この結果、システムの成長は停止し、エンドユーザーへのサービスが低下したり、ビジネス環境の変化への適応ができなかったりします。

　“ベンダに丸投げ”はユーザーサイドにおけるシステム開発の失敗の原因として、数多くの事例に見ることができます。プロジェクトチームの残業を想定以下に抑えることができても結局、スケジュールやコストは大きくオーバーします。企業の部門トップはトップマネジメントの代理人であり、トップマネジメントの指示に基づいて管理活動をするわけですが、このような状況に陥ることをトップマネジメントは望んではいません。

プロジェクト立ち上げ期チェックポイント

スケジュールやコストの概算見積もりを行い、ベンダ見積もりと突き合わせる
スケジュールやコストの管理には、リスクを織り込み、ベンダ任せにしない
ベンダへの丸投げ、無理強いは行わない。本来得られる知識や経験を放棄することになり、ベンダとの良い関係も築けない

　次回はトップマネジメントや上司、業務部門などへの協力要請について、考えていきます。

profile

山村秀樹（やまむらひでき）

某製造業において、主としてシステムの運用保守作業に従事している。仕事を通して、コンピュータ・システムに関心を持つようになり、中でもシステムの開発プロセスについて興味を感じている。

Elie_Worldを運営し、システムのライフサイクル全般にわたる作業について考えている。

「ユーザーサイド・プロジェクト推進ガイド」バックナンバー

前のページへ 1|2 　　　　　　