技術コテコテのSEから、コンサルタントへの転進日記。この先どうなるのか?
水曜日, 2 月 14th, 2007 Posted in プロジェクト管理 | No Comments »
経済産業省がうちだしたITSSのせいかどうか知らないが、プロジェクトを管理する必要が高まるとプロジェクトマネージャーを投入することが多い。 では、プロマネでなければマネージメントできないかというと、そうでもない。ある一定以上の経験を持ったエンジニアであれば、誰でもマネージメントが出来るし、これまではずっとそうしてきたのである。 分業化が進んでいるのか、何かあると「プロマネを投入」となるが、技術力のないプロマネと、技術力とマネージメント力のあるITアーキテクトではどちらが役に立つのか。 Read more..火曜日, 2 月 13th, 2007 Posted in プロジェクト管理 | No Comments »
QCDが現場レベルでの目標になっているが、残念ながらプロジェクトマネージャー自身が全社レベルでのValueを忘れ、QCDにしか目がいかなくなっていることが多い。 スケジュール管理を例にとって見る。 スケジュール管理はプロジェクト内の作業状況を管理するものである。作業漏れを防止(Q)するためにWBSを作ったり、作業進捗を管理(D)するためにガントチャートを作ったりもする。また、コスト(C)が適正かどうかを図るために、作業進捗度合いと投入人員数を計算したりもする。 このような管理を行うためにさまざまな管理表を作成するが、スケジュールに十分な余裕があるのに何時間もかけてガントチャートを作らせたり、コスト的に問題とならない程度の作業でも細かな進捗管理を行ったりすることは、目的を逸脱していると言わざるを得ない。 あくまでもValueの実現を阻害する要因があるから、それを回避しようとQCDの管理をするのである。極論になるが、まったくリスクがなければ管理は不要である。 Read more..日曜日, 2 月 11th, 2007 Posted in プロジェクト管理 | No Comments »
QCDがプロジェクトの最終目的ではないことは述べたとおりであるが、では、なぜQCDが表面的な目標に掲げられることが多いのか。 システム構築を例にとって考えてみる。 同じシステムを作るにしても納期(D)が伸びると、それだけ余分な人員、すなわち人件費(コスト(C))を要することになり、収益が悪化する。また、そのシステムに不具合が多く品質(Q)に問題があれば、それを修復するためのコストがかかり、収益が悪化するというわけである。 システムを構築するプロジェクト要員に「会社全体での収益向上が目的である」といっても具体的に何をすればよいかはわからない。そこで、実作業レベルに噛み砕いた目標としてQCDが使われることが多い。 Read more..