【公開】XP祭り関西2014講演資料「KPTによるプロセス改善~あなたはPDCAを回したことがありますか?」 #xpjugkansai
XP祭り関西2014が無事に終わりました。
参加者やスタッフの皆さん、お疲れ様でした。
私の講演資料を公開します。
【1】今回の講演では、KPTによるプロセス改善の経験談を中心に話しました。
私の立場として、最近はRedmineエバンジェリストと思われる時が多く、プロジェクト支援を依頼される時が多い。
なので、各プロジェクトを横断して、PMOの立場で、プロジェクトリーダーの管理を支援する場合が多いです。
そんな立場でプロジェクトを見ていると、うまく回っていないプロジェクトには幾つかの共通点がある。
真っ先に分かるのは、このプロジェクトリーダーは、PDCAサイクルを回した経験を持っていないから、チーム運営をコントロールできていないな、という点。
【1-1】PGあがりのPLには幾つかの落とし穴がある。
1点目は、何らかの計画書を作った経験がないこと。
例えば、WBSを作ったことがないので、目的や方法を知らない。
すると、行き当たりばったりで作業していることになる。
普通は部課長レベルになれば、彼らの仕事の殆どは、プロジェクト計画、部課の予算計画などひたすら計画書を作るのがお仕事。
マネージャレベルならば、このレベルはクリアしている。
【1-2】2点目は、作業指示ができないこと。
人は指示するだけで動くわけではない。
プログラマあがりのPLにありがちなのが、指示は出すけど、指示の目的や意図や期待する結果を伝えていないために、担当者のアウトプットが想定と違ってしまうこと。
そんなことが続くと、自分でやった方が早いから、PLが作業を抱え込んで破綻するケースが多い。
【1-3】3点目は、予実管理できてないこと。
マネジメントでは、当初の予定と実績を比較して、その差異をみつけて、変化に合わせて状況をコントロールしていく。
しかし、臨機応変に対応できてない。
この部分は、Redmineによるチケット駆動開発など、ツールでカバーできる部分がある。
【1-4】そして4点目は、「カイゼン」の経験がないこと。
ここで「カイゼン」は継続的に改善するという意味で、カタカナで表現している。
実は、部課長レベルでも、カイゼンの経験がない人は以外に多い。
その人達がよく言うのは、「これだけお膳立てしているのに、なぜ皆は変わらないんだ?」というフレーズ。
現場の状況に合わせて改善して効果を上げるのは、それなりのテクニックを必要とする。
【1-5】「これだけ! KPT」に書かれているように、改善サイクルを1年ないし3ヶ月のような長期スパンで回すのは至難の業だ。
むしろ、1週間~4週間のように短い期間で、どんどんPDCAサイクルを回して改善して行く方がやりやすい。
この点は、アジャイル開発をやっているチームの方がカイゼンにすごく向いている。
逆に、WF型開発に囚われすぎているチームは、カイゼンがとてもやりにくい。
KPTを実施するタイミングがプロジェクト完了時しか取れないので、せっかくチームの一体感が生まれてもチームは解散してしまう。
KPTで得られた知見をチームの成長に使えない弱点がある。
KPTのアンチパターン~XP祭り関西2014のプレ資料 #xpjugkansai: プログラマの思索
【公開】第10回 RxTstudy/第57回 SEA関西プロセス分科会「チケット駆動開発とメトリクス」の感想 #RxTstudy: プログラマの思索
【2】今回の講演では、僕の実体験「チケット駆動開発を始めた頃」「炎上プロジェクトに火消しPLで支援」「炎上プロジェクトにPMOで支援」について、KPTを実施して得た知見を話した。
ポイントはいくつかある。
資料に詳しく書いたので、読んで下さい。
・KPTはCAPDで回す
・SECIモデルで暗黙知を表出・内面化
・KPTは経験学習モデルに似ている
・KPTの良い兆候
・【反例】ベクトルがバラバラのチーム
・【反例】1回だけのKPT
・意見を出すためのフレームワーク
・【反例】コンフリクト
・タックマンモデルでコンフリクト解決
・【反例】残り続けるProblem
・フォースフィールド分析でProblemを考える
・【反例】期待過剰
・Will-Skillモデルでチームの成熟度診断
まとめると、こんな感じ。
【2-1】KPTでPDCAサイクルを回そう
・「チームに変化を起こす」ことを心がける
・「暗黙知にする」流れを意識しよう(SECIモデル)
・チームの経験からプラクティスを編み出す流れを意識しよう (経験学習モデル)
【2-2】KPTでチーム内の力学が分かる
・コンフリクトはチームビルディングのチャンス(タックマンモデル)
・推進力を強め、抑止力を弱める(フォースフィールド分析)
・成熟したメンバーは動機付けor委任で回る(Will-Skillモデル)
【2-3】KPTは日本人のチームに向いている
・ほとんどの日本人は、自分の意見を表明する行為に慣れていない
・意見表明に慣れていない人からKPTで本音を引き出す
【2-4】KPTのタイミングに注意しよう
・WF型開発はふりかえりするタイミングが取りにくい
【3】懇親会で感想を聞いたら、プロジェクトリーダーや管理職以上の方には、気づきが多かったらしく、参考になったという意見をもらえて嬉しかった。
ただし、チーム運営の経験がない開発者には、遠い世界の話に聞こえたらしく、その点は反省点かもしれない。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「コミュニティ」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- 『世界一流エンジニアの思考法』が学べる環境を手に入れてかつ継続する方法の感想 #devboost(2023.12.10)
- 第25回東京Redmine勉強会の感想 #redminet(2023.11.05)
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- デブサミ2023の感想(2023.02.11)
「プロジェクトファシリテーション」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント