プロジェクトマネジメント: 2008年6月アーカイブ

システム開発を行う前にすでにバグがあるって事実、なんだか変ですよね

でも事実、要件変更に伴い影響範囲の検証が不十分なために発生する仕様障害、

業務パターンの考慮漏れによる仕様障害など、システム開発に着手する前にすでにバグは

誕生しているのです。

あるリサーチによるとITプロジェクトの失敗要因の4割近くが要件定義フェーズに起因するそうです。

 

プロジェクト規模が大きくなるほど、各要件の変更に関する情報共有や経緯の把握、影響範囲を

確認するのが容易でなくなっていきます。

要件定義を支援する市販のツールもあるので、プロジェクト品質向上のために活用するのも

良いかと思います。

 

 

プロジェクトの初期段階では、決まっていない事が多く、予算化する上でのひとつのコツが

「バッファ」です。

 

予算が大きくぶれるような要件が新たに出てくる事もあれば、想定外の出来事が起こるのが

ITプロジェクトです。

 

この事をあらかじめ前提として進めるのですが、プロジェクトのフェーズ、要件の明確さ、難易度など

を考慮し、バッファを決めます。

 

重要なのは、予算に対するバッファをプロジェクトでオープンにしておくという事です。

追加の要件が出た場合、バッファの中で対応していくという事で、顧客側も予算の追加を

社内で獲得するという作業を行わなくてすみます。

バッファをマネジメントする事は、すなわち予算を管理するという意識が共通意識となります。

これはプロジェクト予算をいたずらに増加させかねない、重要度の低い要求へのけん制にもなります。

 

バッファを示す場合には、後日、バッファの中で対応するものかどうかという議論にも

なりえるので、見積り根拠を明確にする事は重要です。

 

ITプロジェクトでは、非常に重要な割に主役になる事は無い「データ移行」

プロジェクトによっては百人月を超える、データ移行だけでも一大プロジェクトになる

システム化のスコープが決められていない場合はデータ移行の範囲も決められないですが、

場合により、データ移行の複雑さ、データ精度などがシステム化のスコープを決めるケースがあります。

プロジェクトを立ち上げたばかりで、業務の変革をどのように実現するかという熱い議論をしている際

にデータ移行についての調査というのは意図して行わない限り後回しにされてしまいがちです。

データ移行は企業規模によっては、かなりやっかいなものです。

少しでもいいので、プロジェクトの初期段階で移行データの調査をしておいて、感触をつかんでおく

事が重要だと思います。

 

今更ですが、このタイトルが適切なのか、ちょっと悩みます。。。

 

さて、予算設定時の前提となる軸の話ですが、まず受注側も発注側も何を前提とした金額なのか明確にするということです。

これは仕様を詳細に決めるという話ではなく、大きな要件を明確にし、受注金額の前提となるものは何かを共有する事です。

例えばユーザ要求の定義を行う必要がある場合、実際にかかる工数はユーザが打ちあわせ等の時間をとれるかどうかでスケジュールに大きな影響を受けます。

また、企業によっては要件を決めるのに様々な承認行為が必要となり、企業体質がスケジュールに大きな影響を与えます。

これらの事に対しても前提として、どのようなスピード感や現場の協力を得られるかを明示的にする事は大事なことです。

 

また、後々、このあたりの事は書いていきたいと思います

 

どんなプロジェクトでもシステム導入に関連した予算枠というのは、ありますよね

システム要件も決まらないまま、一括請負をして、要件が増えて受注金額をめぐって交渉、なんて事になったら、発注者側も受注者側も気分が良いわけありませんし、たいがいプロジェクトは赤字になり、予算をけずられ、プロジェクトに関わるエンジニアが苦労するという図式ができあがります。

かといって、プロジェクトの実行判断を行う上で想定予算を出さないことには経営判断はできません。

そして一度、出た予算は一人歩きし、その予算をさらに拡大させるというのは、大抵の場合、大変なことです。社内でのプロジェクト責任者の責任問題になりかねません。

システムの要件は現場の担当者に聞くと様々な新要件があります。

これを要件の重要度を判断せずにシステム要件にすべて反映させれば、当然、予算を大幅にオーバーします。

これをコントロールするには、予算設定時の前提となる軸が必要です。

 

(続く)

どんな組織でも、あたりまえですがコミュニケーションは重要です。

ITプロジェクトでは当然のごとく、メールで情報のやりとりを行いますが、人数の多いプロジェクトで情報共有のためにメールのCCに全メンバを入れて情報発信をするというケースがありました。

情報発信しているんだから、見ていないのはあなたの責任でしょ、という雰囲気さえ感じます。

 

プロジェクトマネジメントを行う上でコミュニケーション環境を構築するのは非常に大事です。

メールで情報をやりとりするだけでなく、定期的に情報や課題を共有し、知恵を出し合うことによりコミュニケーションが円滑になり、チームとしての一体感も生まれます。

ミーティングだけでなく、コミュニケーションを活性化するために座席位置やメールの件名ルール、等様々に工夫するべき点があります。

 

アナログなコミュニケーションを日頃から行うのが何よりも重要です。

昔のお客様先の社訓にありました。

「あいさつをしよう」

大事です。

「おはようございます」言えてますか?

 

 

ITプロジェクトはフェーズが進むにつれ、新しくメンバが加わるのが常です。


新しく加わったメンバが速やかにプロジェクトの内容を理解し、パフォーマンスを発揮できるように
環境を整えるのも重要なマネジメント事項です。

プロジェクトの実行背景や経緯がわかるようにドキュメント体系、用語集を用意しておく事が大切です。
ドキュメントは共有サーバに保管し、仕掛用の個人フォルダとプロジェクトで共有するフォルダを分けるべきで、プロジェクト共有フォルダは体系だった管理を行い、何がどこに配置されているのか、アクセス権どう設定されているか等、しっかり管理を行うべきです。(特に大規模なプロジェクトでは)

初めに決めておかないと、プロジェクトがある程度進捗してからドキュメント体系を整理すると、かなり無駄な労力が必要となります。

 

このアーカイブについて

このページには、2008年6月以降に書かれたブログ記事のうちプロジェクトマネジメントカテゴリに属しているものが含まれています。

次のアーカイブはプロジェクトマネジメント: 2008年7月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1