プロジェクトマネジメントFAQ - 室長のひとりごち

1日何時間で作業を見積もればいいですか

就業時間で見積もります。ただし、次の事項を考慮してください。

組織内の間接業務

フルフルな就業時間で見積もると残業することが前提となってしまうので実務に使える時間は目減りすることを忘れてはいけません。

さらに、プロジェクト内の作業においても仕様書を書く、コーディングするという正味の生産的な作業の他に生産的な作業ではないけれど欠かすことができない作業もあるので実質な作業時間は1日の半分くらいだと思っていた方が良いです。

見積もりはできる人が見積もりをしがちです。プロマネができるエンジニアに振るからですけど。

見積もりをする際には、誰のレベルで見積もりをしたか、例えば、できるエンジニアなのか、中堅のAさんレベルなのか、新人のBさんレベルなのか、を確認する必要があります。

さらに、見積もった後はチームでその見積もりが妥当かどうか、ウォークスルーをして見積もり時の前提や範囲を可視化しましょう。

プロジェクトの特性で選択してください。いつもウォーターフォールだからとか、顧客がアジャイルをやりたいからとかで選択してはいけません。

納期、品質、リリースサイクルなど、プロジェクトの特性に適合する手法を選択しましょう。

もし、未経験のシステム開発手法を選択する必要がある場合には、炎上して多大な火消すコストを投下するくらいなら、最初から専門家をアドバイザリーとしてアサインしましょう。

ただ、アドバイザリー役に実務をやらせてはいけません。実務は全てチームでやらないとコストを持ち出してアドバイザリーを雇っている意味がありません。

プロジェクトの規模によります。ただ、機能しないエンジニアを入れても成果が出ないばかりか、成果のでる複数のエンジニアの足を引っ張るのでそんなエンジニアは入れない方がましです。

プロジェクトマネジメントは、プロジェクトの規模には影響を受けません。大なり小なりどちらでも、プロジェクトをマネジメントするために行うので。

プロジェクトマネジメントのデファクトのPMBOKはどの業種でも使えるように多数の業種のプラクティスを汎化したプラクティスのエッセンスです。

それゆえ、フレームワークになっているので業種特有やプロジェクト固有の特性はプロジェクトマネージャがインプリしなければなりません。

それをしないでPMBOK使えねーというのは、お前が使えねーです。

日常になってしまっているからじゃないかな。

プロジェクトマネジメントがない世界でプロジェクトをやるなんて考えられません。旧石器時代に戻れっていうことですか。

プロジェクトの規模や契約条件により、組織がパーになることだってあります。しないように履行するのが日本の組織の選択ですが。

プロジェクトが組織にというよりは、組織の文化がプロジェクトに振る舞いを制約します。

ただ、一方的ではなくて、プロジェクトの特異な点が組織に逆流することもないわけではありません。

過去の類似実績から類推するのがいいです。ただ、同じものはありえないので。

それよりは、チームの中で中堅クラスのエンジニアに先行作業として1つやらせてみて、それを標準値にする方が精度が高いです。

要件定義局面で実施します。もし、基本設計＝外部設計からの受託であれば、基本設計局面の前か中の頭に、要件確認タスクをしっかり入れてください。

入れないと死にますよ。

今日はここまで。