2008年12月アーカイブ

ITプロジェクトを実行する上では関連する部署が複数あり、様々なタスクを各部署に依頼する事があるかと思います。

各部署は通常業務が行われていますので、プロジェクト実行に関するタスクはなるべく平準化したいですし、業務の多忙時期には対応できなくなります。

プロジェクトはこれらの業務多忙期への配慮を行う事も大事ですし、依頼を行うことをとりまとめ、管理を行う必要があります。

関連部署では、プロジェクト実行のどの時期あたりにどういったタスクがあるのか理解し人員の手配なども行う必要があるからです。

意識的に管理を行わないとプロジェクトの各担当者が個別にぱらぱらと依頼が行われる形になってしまいかねません。

指示系統の混乱などによる各部署からの反発を避けるためにも、依頼事項を各部署の管理責任者にあらかじめ伝え個別調整に入ることが重要です。

ITプロジェクトならではですが、新しい技術などを取り入れるような場合ではアーキテクチャ設計に関する検証をプロジェクトの早い段階で行います。

この際に本番稼動のバージョンと同バージョンにするのが基本ですが、プロジェクト期間が長い場合は新バージョンが出たりして、どのバージョンでリリースを行うかの判断が必要になります。

たとえマイナーバージョンの変更でも本番適用前に検証を行うべきです。

 

似たようなケースですが開発環境と本番環境で構成が違っているために本番適用時に障害が発生するということがあります。

あまりプロジェクト実行の方法論には定義されていないと思いますが、アーキテクチャに関するリスクは早めにつぶすのが正解です。

 

タイトルとあまりあってない内容かもしれませんが。。。

 

プロジェクトを成功させるのに重要な要素のひとつにコミュニケーションがあります。

コミュニケーション環境を整えるのは非常に大切な仕事ですが、積極的にコミュニケーションをとってくれるメンバーがいると非常に助かるものです。

スキルは今一つ経験不足の新人でもコミュニケーションや場の雰囲気づくりで大いにプロジェクトに貢献するというのは、良く目にしてきました。

 

さて、忘年会のこの時期ですが、プロジェクトのメンバーを集めて飲み会をする良いチャンスです。

日頃は労いの言葉を言うきっかけがなくても、こういう場では、あえて口にしましょう。

プロジェクトの重要性、メンバへの期待、感謝、そういったものを伝えるのに非常に良いツールこそが

「飲み会」です。

普段は多忙なプロジェクトメンバも忘年会なら積極的に参加してくれるでしょう。

サブリーダーなどの責任を持った人などに挨拶をする場を設けるのも、良いと思います。

リーダーとしての自覚やコミットメントに繋がると思います。

 

くれぐれも説教はしないようにしましょう!

 

かなり昔の事ですが、プロジェクトプロセスの標準化、いわゆる社内のメソッドを作成するというプロジェクトに参加した事があります。

プロジェクトの最初に行ったのは、経験豊富な様々なコンサルティング会社出身のコンサルタントへのヒアリングです。

メソッドは大事だけど、ある事による弊害というのもあるのだな、とその時に知りました。

それから実感としてあるのは、標準化されたプロセスから外れるのは「悪」とみなされてはならないこと。

プロジェクトは生き物ですし、標準的に型にはまるプロジェクトは、なかなかない。

メソッドを理解し使うというのは、なぜ、それが標準になっているのか理解し、現在のプロジェクトにおいてどのようなアレンジをするのがベストなのか考えられることだと思います。

メソッドからはずれる事が悪い事だという社風があると、型どおりにやる事により本質を失い運営に支障が生じることもあります。

また、型に縛られると大きなコストの代償もあるので注意が必要です。

誤解の無いように、あえて申し上げますが、メソッドは重要です。

ただ、盲目的にメソッドどおりプロジェクトを運営しても、応用がきかなくなります。

 

大規模プロジェクトのマネジメントに関わる中で、良く思うのは「早く言ってくれれば。。。」という事です。

大規模プロジェクトは計画、体制、マネジメントがうまく機能しないとうまく行きません。

まずは、計画について、よくありがちな過ちを書いてみたいと思います。

 

業務が大幅に見直されるケース

業務が大幅に見直されるケースはデータ移行、業務移行の移行に関するコストが大きくなります。

これを計画時に軽く見積もるケースが良く見られます。

DB構造自体が大きく変わるとデータ移行のプログラムや検証がひとつのプロジェクトとなります。

業務移行にしても、教育、テスト導入、並行運用等、しっかり議論されるべきですが、あまり議論されないケースがあります。

 

業務チームへの参画についての計画

業務チームの参画は設計品質を左右します。

業務の担当者がプロジェクトへどの程度参画できるのか、どの時期が多忙なのか、どういうメンバーが参加できるのか、そういった部分は案外、見落としがちです。

 

プロジェクト計画における簡易チェックリストは無料配布するチェックリストを作成中です。

興味のある方はお問い合わせください。

このアーカイブについて

このページには、2008年12月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2008年11月です。

次のアーカイブは2009年1月です。

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

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1