→プロジェクト管理
→見積もり・発注
→リスクマネジメント
- チーム内でやる進捗会議はムダ2012.1.31
- チームの進捗管理役をチームリーダーに負わせてしまうと、ただでさえ忙しいチームリーダーの仕事が増す。さらに、チームリーダーからプロジェクトマネージャへの報告会議を対面で行った場合、貴重なチームリーダーの作業時間を奪ってしまう。週に40時間のワークタイムがあったとして、チームリーダーが進捗管理タスクを2時間、進捗報告会議に2時間割くと、実にチームリーダーの1割の時間をムダに捨てることになる
- 結局、見えない進捗を管理するのであればチームリーダーに頼らざるを得ない。逆に言えばチームリーダーに頼らないで良いように進捗を見えるようにできればチームリーダーに頼らなくても良くなる。
- ［計画＆進捗管理編］成果物レビューを怠ってはいけない 2011.3.20
- PMたるもの、自分が率いるプロジェクトの成果物レビューを怠ってはならない。もちろん、全ての成果物を漏れなくレビューすることは、時間的リソースに制限のあるプロジェクトでは事実上不可能である。従って、全てを自分で行えというのではない。
- ここで言いたいのは、少なくともプロジェクトメンバーに「このPMはレビューを行うPMだな」と思わせることが大切だということだ。具体的な方法としては、抜き取り検査でも良いし、ウォークスルーで日頃から成果物の完成状況を見て回る方法でも良い。
- 「このPMは細かいところまでちゃんとチェックするな」と思わせることによって各メンバーの意識を向上させるのみならず、プロジェクト全体の士気向上にも役立てるのである。
- システムの納期とは確率分布だ 2009.10.11
- 発注者は「11カ月で完成するのなら余裕のあるプロジェクトだろう」と安心しているはずです。ところが実は12カ月というデッドラインに間に合う可能性すら50％以下だというのです。
- 見積もり担当者の「11カ月で完了します」という言葉と、そこから導き出される「デッドラインにさえ間に合わない可能性が高い」という予想。このあまりに異なる結果をなんとかしないかぎり、ITがもっとビジネスに貢献したり、開発からデスマーチをなくしたり、ということは難しいのでしょう。
- チケット駆動開発は進捗報告作りをどのように解決しようとするか？ 2009.3.20
- チケット駆動開発を運用してみて気付いたことは、進捗報告は手作業で集計してExcelに綺麗にまとめる必要は無いこと。進捗報告はチケットのステータスを自動集計してくれるインフラがあるから。
- しかしながら、顧客向けの進捗報告は、Redmineサマリをそのまま出すことはできない。理由は、チケットがタスクカードの観点で作られているから。
- 顧客向けの進捗報告は、ストーリーカードの観点で作成すべきなのだ。
- 進捗管理の不備 2008.8.29
- 「進ちょく会議で本来やるべきことは進ちょくが遅れた原因を明らかにしてその場で対策を講じること」と梅澤氏は指摘する。そこで梅澤氏は，工程が遅れた理由を突き止め，それに対して「どんな手順で，どこまでできたらよしとするか」まで決めたうえでスケジュールを再作成した。
- 標準工期より30%以上短いとデスマーチの危険、JUAS指摘 2008.6.26
- 日本情報システム・ユーザー協会（JUAS）は6月26日、システム開発の現状についてユーザー企業に尋ねる「ソフトウェアメトリックス調査2008」の結果を発表した。
- 標準の開発工期は投入人月の立方根の2.4倍
- 25％以上の工期短縮をする場合では、日別の工程管理に加えて、「ベテランプロジェクト・マネジャー（PM）による采配と、全社挙げての協力および監視」が必要としている。ただ、30％以上短い工期は「無謀」としてデスマーチ化の懸念を示している。
- 人月を入れ替えてはいけない 2008.5.21
- システム規模と開発規模の関係については，IBMが発表しているWalston ＆ Felix統計値（WF統計値）が有名だ。このWF統計値は，開発期間がそのシステム規模に妥当かどうかを判断する目安となる。
- プロジェクトの状況を客観的データで示す 2008.2.1
- 要件定義や外部設計といった上流工程で予想以上に品質向上のためのコストが必要なことが判明したときは，まずフェーズ全体のコスト・バランスの見直しを行い，上流工程へのコスト配分を増やすべきだ。
- 「上流工程にはあまりコストはかけたくない」，「欠陥はテストで叩ける」，「仕様は未確定だが，このまま見切り発車して後で修正すればよい」 ――。こうした，上流工程にコストをかけずに下流工程でなんとかするという考え方で，これまで多くのプロジェクトが痛い目に遭っている。上流工程に思いきって品質改善コストを投入することで，テスト工程にかかるコストを大幅に削減する。これが，プロジェクト全体のコストを低減する上で極めて重要である。
- 上流工程で予定よりもコストがかかることが判明したとき，通常はコンティンジェンシを使いたくなる。しかし，いきなりコンティンジェンシを使うのは得策ではない。それよりもまず，上に述べたように，上流工程へのコスト配分を増やすことを考えるべきだ。
- コンティンジェンシは，コスト配分の再調整ではどうにもならないような，大きなコスト超過が発生したときに限り使える追加予算，と考えるようにする。そのためには，コンティンジェンシの取り崩しをプロジェクト・マネジャーが自分の判断で勝手に行えない体制にしておく必要がある。日本IBMでも，コンティンジェンシの利用には明確な理由と公式な承認が必要である。
- 進捗度把握の主流は原価比例法 2008.7.3
- 原価比例法はプロジェクト開始時に原価総額を見積もり、実際にかかった原価から進捗度を把握する代表的な方法だ。工事契約に関する会計基準にも挙げられている。
- 一方のEVMはプロジェクト管理手法の一つ。プロジェクト全体を細かい作業に分割した後に出来高を予測し、進捗も細かい単位で把握する。手間はかかるがその分見積もり精度が高くなり、プロジェクト管理の強化につながる。
- スケジュール表を何度も書き換えてはいけない 2008.6.6
- フォロー線（▼）で実績更新することで，計画に対して遅れが一目で分かるようにしてある。また，定期的（1回/週，1回/月）にフォローすることで，前週や前月の間隔と比較し，遅れが改善傾向にあるのか，拡大傾向にあるのかが読み取れる。
- 納期優先の無理なプロジェクトが失敗を招く 2008.3.21
- 日本の社会は「委託者の地位が異常に高い」という特徴を持っている。委託者は納期はしっかり押し付けるにもかかわらず、要件定義ではなかなか結論を出さなかったりする。これが失敗プロジェクトへの道の第一歩である。
- 計画段階でのスケジュールの作成は、あくまでも合理的な計算の下に行うべきであり、そこに精神論をベースにした「頑張り」を持ち込んではいけない。納期をどうしても短縮する必要があるのであれば、人員の追加など、しっかりした根拠を持って短縮を行うべきである。
- プロジェクト推進計画の勘所 2008.1.7
- 工程進捗が不調の場合、大事なことは、顧客側の責任者の顔が立つだけの機能は何とか納期どおりに動かすことである。そのためにも必要最低限の機能セットは何かよく考え、議論し、これだけは何としてもきちんとまとめられるような戦略を立て、工程設計に反映しておかなければならない。
- 定量的に進捗度を定義すること
- 各工程の完成条件をプロジェクト内で共通に定義しておくこと
- 工程表ができたら、顧客側から工程表の提出を求められなくても自発的に提出し、顧客にレビューしてもらおう。工程表はシステム構築をいかに実現するかの基本設計の結果であるだけに、顧客とベンダーが考えているシステム像の食い違いを見ておくためにも工程表のレビューは大事である。
- 特に次の2点をしっかり見てもらおう。第1は、システムを組み立てる順序を明確化することにより、実現すべき機能の優先順位に対する考え方が顧客ときちんと合っているかどうかである。そして、なんとしても最優先機能の確実な実現に向けて、顧客とベンダー間で意思統一することである。
- 第2は、プロジェクトの納期を守るための最重要事項である仕様凍結日を顧客にしっかり認識してもらうとともに、早期仕様凍結の重要性を理解してもらうことである。
- プロジェクトを組み替えよう 2008.3.12
- プロジェクトは最初の計画通りに行くことはまずないので、必ず組み替えが起こることを前提とすべし
- プロジェクトを期日までに終わらせるための必携10訓 2007.12.19
- ＃1：要求を詳細に分析する
- ＃2：利用可能なリソースを的確に割り振る
- ＃3：トレーニングを実施し、知識の移転を行う
- ＃4：リスクを洗い出す
- ＃5：予測をたて、的確にタスクを割り当てる
- ＃6：仕事をモジュール化する
- ＃7：余分な会議を設けない
- ＃8：ものごとを書き記しておく
- ＃9：世界規模の分散開発に注意を払う
- ＃10：問題を上司に相談する
Last-modified: 2024-11-11 (月) 18:08:23
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
3-zu.jpg