プロジェクトファシリテーション実践編：ふりかえりガイド
ここでは、PF=Project Facilitation(プロジェクトファシリテーション)について議論しています。 プロジェクトを活性化し、楽しくプロジェクトを成功に導くための、実践的な課題を扱います。 プロジェクトの成功に大切なものはなんでしょうか？ 個々人のスキルは重要です。そして、ここで取り上げるのは、集まった個人のスキルを１００％以上に発揮させるチーム作りとしての、「プロジェクトファシリテーション（PF）」です。 プロジェクトマネジメント（PM）が重要であることは昨今強く言われています。 PMが「計画達成のマネジメント」に重点を置くのに対してPFは「参加者の協調の場作り」に重点を置いています。PMは、計画の立案と実行、差異に注目した管理が中心で、どちらかと言うと「コマンド･コントロール型」のマネジメントスタイルが背後にあります。これに対してPFは、その場その場の変化に対応し、チーム
マネージャ 2.0: スクラムでのマネージャの役割
企業の世界において、マネージャの伝統的な役割は“指揮統制”として知られるモデルに基づいます。ここでのマネージャの役割は何をする必要があるかを特定し、従業員に詳細な指示を与え、従業員が確実にその指示に従って仕事を完了するようにすることです。このモデルでの従業員は単純に与えられた指示に従い、正しい仕事を正しい方法で完了するためにマネージャの判断と知恵を信じるだけです。 しかし、ソフトウエア開発のような複雑で変化の激しい環境ではこの手法は機能しなくなりやすいです。まず、マネージャがすべての要求の完全な細部まで理解し、従業員の仕事を指導するため正確な指示を出すのは難しくとても時間がかかります。ソフトウエア開発チームの仕事は相互の関連の度合いが高く、複雑に依存し合い、変化や予期しない驚きが頻繁に発生します。ひとりのマネージャがチームのためのすべての基本的な判断を下すことを期待するのは現実的ではありま
今知ってほしいプロジェクトマネジメントのもう一つの世界観 ~予測型と経験型~ - higosophy
主張 ソフトウェア開発prjがなかなかアジャイルにならないのはなぜかなぁと考えてみた。 昨今、エンジニアにおいては、知識としての共有の機会も増えているし、実際に経験済み、習慣化済みになってきているように思う。要は「しっくり」くることが多いのだと思う。 しかしながら、現実のprjが経験型のアプローチ(アジャイル)を取ることはまだまだ少ない。この要因として、エンジニアと協業する他のメンバー、あるいはprjの利害関係者(組織の上層部を含む)が予測型の進め方を望むからではないか、と感じている。 というわけで、エンジニアと仕事をするエンジニア以外の人に伝えたいと思い、書いてみる。そのためにはおそらく、アジャイル開発、スクラムのプラクティスがどうこう、というよりは、プロジェクトマネジメントの世界観として語る方がよいかというのが本稿。エンジニアとして、抽象的な「しっくり」の言語化にもなればよいと思う。最
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
