プロジェクト定例会議で行うべきことについて。
プロジェクトメンバー間で、進捗状況、課題と解決策を共有する
プロジェクトが予定通りに進んでいるかを確認し、スケジュールの遅延を最大限抑えるための会議でもある。
時間だけを浪費する会議であってはならない。
報告は定量的に。課題数等を数値化するなど、状況を数値で判断できるようにする。
順調です、がんばって遅れを取り戻します、など、感覚的な報告であってはならない。
問題が発生すれば、その原因をしっかり分析し、解決策を決定し、共有する。
2009年07月05日
2009年07月04日
プロジェクトの開始時のポイント
プロジェクト開始時には、キックオフミーティングなどで、プロジェクトメンバー全員の意識合わせを行うことが重要。
プロジェクト開始時に行うべきことは次の通り。
・プロジェクトの目的、目標の共有
・体制や各メンバーの役割分担の共有
・プロジェクトの進め方やルールの共有
それにより、作業がすぐに開始できるよう体制を整える。
各メンバーがやらされ感を持つこともなくなり、前向きに自信を持って作業に取り掛ってくれるようになる。
・プロジェクトスケジュールの共有
・開始時点で分かっている懸念事項や課題の確認
プロジェクトの遅延を、全員で防ぐ。そのための意識を持たせる。
プロジェクト開始時に行うべきことは次の通り。
・プロジェクトの目的、目標の共有
・体制や各メンバーの役割分担の共有
・プロジェクトの進め方やルールの共有
それにより、作業がすぐに開始できるよう体制を整える。
各メンバーがやらされ感を持つこともなくなり、前向きに自信を持って作業に取り掛ってくれるようになる。
・プロジェクトスケジュールの共有
・開始時点で分かっている懸念事項や課題の確認
プロジェクトの遅延を、全員で防ぐ。そのための意識を持たせる。
2009年07月03日
会議、打ち合わせなどのコミュニケーションを頻繁にするべきかどうか
会議や打ち合わせなどを頻繁に行うと、当然それに工数が裂かれます。
会議の出席人数が多ければ、それだけ大きな工数を消費することになります。
しかし、会議などで進捗確認などを正確に行うことにより、仕様書の漏れや手戻りとなりそうなリスクを早い段階で検出/削減することが可能になります。
仕様不備によるプロジェクトの遅延を取り戻す工数よりも、会議の工数のほうが小さいことがほとんどでしょう。
そういった観点で考えると、納期遵守、低リスクを実現するためには、中身のある会議を重ねることは重要になります。
(だらだらと時間を消費するだけの会議が無意味なことは、いうまでもありません)
特に、プロジェクトの規模が大きいほど、その効果は大きくなります。
プロジェクトがきっちり回っているかどうかを確認するために、会議を重ねるのは有効であることのほうが多いと感じます。
会議の出席人数が多ければ、それだけ大きな工数を消費することになります。
しかし、会議などで進捗確認などを正確に行うことにより、仕様書の漏れや手戻りとなりそうなリスクを早い段階で検出/削減することが可能になります。
仕様不備によるプロジェクトの遅延を取り戻す工数よりも、会議の工数のほうが小さいことがほとんどでしょう。
そういった観点で考えると、納期遵守、低リスクを実現するためには、中身のある会議を重ねることは重要になります。
(だらだらと時間を消費するだけの会議が無意味なことは、いうまでもありません)
特に、プロジェクトの規模が大きいほど、その効果は大きくなります。
プロジェクトがきっちり回っているかどうかを確認するために、会議を重ねるのは有効であることのほうが多いと感じます。
2009年06月28日
プロジェクトのコストオーバー
多くの原因は、計画段階でコストを過小に見積もったことによる。
コストオーバーの原因には次のような場合が見受けられる。
小型プロジェクトの感覚で、大型プロジェクトの見積もりを行った場合
大型プロジェクトは小型プロジェクトよりも開発生産性が低下してしまうためである。大型プロジェクトには、小型プロジェクトにはないさまざまな問題があり、そのノウハウも蓄積が必要であることを理解すべき。
リーダーやマネージャに指導力がない場合
チームメンバーをリードできないと、進捗が遅れたり、課題を解決できなかったりと、問題山積みになり、解決がおぼつかなくなる。
メンバーのスキルが十分に備わっていない場合
プロジェクトで必要となるスキルをしっかりリストアップし、要員の確保や教育をスムーズに行う。特殊な技能を必要とするプロジェクトであれば、その要員が確保できているかどうかが大きなポイントとなる。
設計が不十分な場合
業務設計が不十分だと、手戻りが多く発生し、無駄な工数を生みやすい。システムが見たり触れたりする段階になって、顧客が使い物にならないと感じるなどすれば、プロジェクトの大きな巻き戻しは避けられない。
コストオーバーの原因には次のような場合が見受けられる。
小型プロジェクトの感覚で、大型プロジェクトの見積もりを行った場合
大型プロジェクトは小型プロジェクトよりも開発生産性が低下してしまうためである。大型プロジェクトには、小型プロジェクトにはないさまざまな問題があり、そのノウハウも蓄積が必要であることを理解すべき。
リーダーやマネージャに指導力がない場合
チームメンバーをリードできないと、進捗が遅れたり、課題を解決できなかったりと、問題山積みになり、解決がおぼつかなくなる。
メンバーのスキルが十分に備わっていない場合
プロジェクトで必要となるスキルをしっかりリストアップし、要員の確保や教育をスムーズに行う。特殊な技能を必要とするプロジェクトであれば、その要員が確保できているかどうかが大きなポイントとなる。
設計が不十分な場合
業務設計が不十分だと、手戻りが多く発生し、無駄な工数を生みやすい。システムが見たり触れたりする段階になって、顧客が使い物にならないと感じるなどすれば、プロジェクトの大きな巻き戻しは避けられない。
2009年06月27日
リーダーは悪い情報もしっかり集めよ
いい情報も悪い情報も、リーダーは吸い上げて、今後の活動に生かすべし。これは、チームリーダーにとって必要な心構えです。
チームメンバーから報告があっても、それがリーダーに都合のいいようにゆがめられた情報であれば、それがチームにとってどれだけ都合のよいものであったとしても、チームにためになる正しい情報とはいえません。
そのような情報を基にした判断は、チームの方向性をゆがめる判断となってしまいます。
部下が悪い情報を持ってきたとき、不機嫌になったり報告者を責めてばかりでは、部下は決して悪い情報を伝達してくれなくなります。
何か悪い状況になっても、それをリーダーは知ることができません。チームがコミュニケーション不足に陥っている状況にもなり、チームはより悪い方向に向かう可能性があります。
チームにとって悪い情報もいい情報も、チームにとっては正しい情報です。
問題点を早めに把握するためにも、悪い情報もしっかり取り入れる姿勢をリーダーは持つべきです。
ということを考えた1週間でした。
2009年06月25日
部下の育成
部下の育成についてまとめる機会がありましたので、こちらにも。
先輩・上司はよいお手本であるべき
仕事のできる先輩を見習い、それに追いつこうと後輩が努力することによって、後輩は成長して行く。そのようなお手本となる上司が、部下の育成には必要。
後輩に、きちんと説明する、具体例を示す
後輩は、いろいろな物事を吸収しても「わかったつもり」になっていることも多々ある。後輩の理解度を一層上げるために、後輩の目の前で手を動かし、具体的に説明し、実際にやってみせる、こういった努力も先輩は行うべき。
部下にも仕事をさせる
上司たるもの、部下より短時間で多くの仕事をこなせる存在である。
しかし、部下に仕事を渡さなければ、部下の成長もない。部下が指示待ちタイプの人材であれば、積極的に仕事を振り、その仕事を自ら部下がこなせるよう誘導してやるとよい。その場合は、部下に自ら考えて行動するように促すとよい。
部下の仕事をきちんと評価する
部下が仕事をうまくこなした時には、きちんとほめてやる。
部下が失敗したときには、反省させ、同じ過ちを繰り返させないように指導する。
部下が失敗する可能性がある場合には、事前に上司がチェックし、部下にフィードバックする。
先輩・上司はよいお手本であるべき
仕事のできる先輩を見習い、それに追いつこうと後輩が努力することによって、後輩は成長して行く。そのようなお手本となる上司が、部下の育成には必要。
後輩に、きちんと説明する、具体例を示す
後輩は、いろいろな物事を吸収しても「わかったつもり」になっていることも多々ある。後輩の理解度を一層上げるために、後輩の目の前で手を動かし、具体的に説明し、実際にやってみせる、こういった努力も先輩は行うべき。
部下にも仕事をさせる
上司たるもの、部下より短時間で多くの仕事をこなせる存在である。
しかし、部下に仕事を渡さなければ、部下の成長もない。部下が指示待ちタイプの人材であれば、積極的に仕事を振り、その仕事を自ら部下がこなせるよう誘導してやるとよい。その場合は、部下に自ら考えて行動するように促すとよい。
部下の仕事をきちんと評価する
部下が仕事をうまくこなした時には、きちんとほめてやる。
部下が失敗したときには、反省させ、同じ過ちを繰り返させないように指導する。
部下が失敗する可能性がある場合には、事前に上司がチェックし、部下にフィードバックする。
2009年05月03日
スケジュールマネジメント(タイムマネジメント)
プロジェクトマネジメントについて意識しようと思ったので、以下の内容をメモ。。。
勤務時間のすべてが、業務に費やされていることはない。
メールを書く時間、会議に出る時間など、与えられている業務以外の業務をこなす時間があるはずである。
他、突発的な作業が入ることも十分考えられる。
そのような事情もあるため、タスクのスケジュールは、余裕を持たせて組むのがよい。
たとえば1日8時間勤務であれば、「作業に携われるのは1日6時間」などと見積もったうえで、プロジェクトのタスクスケジューリングを行うのがよい。
また、この余裕が、スケジュール遅延時のバッファとしても役立てることができる。
勤務時間のすべてが、業務に費やされていることはない。
メールを書く時間、会議に出る時間など、与えられている業務以外の業務をこなす時間があるはずである。
他、突発的な作業が入ることも十分考えられる。
そのような事情もあるため、タスクのスケジュールは、余裕を持たせて組むのがよい。
たとえば1日8時間勤務であれば、「作業に携われるのは1日6時間」などと見積もったうえで、プロジェクトのタスクスケジューリングを行うのがよい。
また、この余裕が、スケジュール遅延時のバッファとしても役立てることができる。