プログラマの思索

XP祭り関西2014が無事に終わりました。
参加者やスタッフの皆さん、お疲れ様でした。

私の講演資料を公開します。

【参考】
XP祭り関西2014 - XPJUG関西wiki

【1】今回の講演では、KPTによるプロセス改善の経験談を中心に話しました。
私の立場として、最近はRedmineエバンジェリストと思われる時が多く、プロジェクト支援を依頼される時が多い。
なので、各プロジェクトを横断して、PMOの立場で、プロジェクトリーダーの管理を支援する場合が多いです。

そんな立場でプロジェクトを見ていると、うまく回っていないプロジェクトには幾つかの共通点がある。
真っ先に分かるのは、このプロジェクトリーダーは、PDCAサイクルを回した経験を持っていないから、チーム運営をコントロールできていないな、という点。

【１－１】PGあがりのPLには幾つかの落とし穴がある。
1点目は、何らかの計画書を作った経験がないこと。
例えば、WBSを作ったことがないので、目的や方法を知らない。
すると、行き当たりばったりで作業していることになる。

普通は部課長レベルになれば、彼らの仕事の殆どは、プロジェクト計画、部課の予算計画などひたすら計画書を作るのがお仕事。
マネージャレベルならば、このレベルはクリアしている。

【１－２】2点目は、作業指示ができないこと。
人は指示するだけで動くわけではない。
プログラマあがりのPLにありがちなのが、指示は出すけど、指示の目的や意図や期待する結果を伝えていないために、担当者のアウトプットが想定と違ってしまうこと。
そんなことが続くと、自分でやった方が早いから、PLが作業を抱え込んで破綻するケースが多い。

【１－３】3点目は、予実管理できてないこと。
マネジメントでは、当初の予定と実績を比較して、その差異をみつけて、変化に合わせて状況をコントロールしていく。
しかし、臨機応変に対応できてない。
この部分は、Redmineによるチケット駆動開発など、ツールでカバーできる部分がある。

【１－４】そして4点目は、「カイゼン」の経験がないこと。
ここで「カイゼン」は継続的に改善するという意味で、カタカナで表現している。
実は、部課長レベルでも、カイゼンの経験がない人は以外に多い。
その人達がよく言うのは、「これだけお膳立てしているのに、なぜ皆は変わらないんだ？」というフレーズ。
現場の状況に合わせて改善して効果を上げるのは、それなりのテクニックを必要とする。

【１－５】「これだけ! 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モデル)

Twitter / Uemmra3: あきぴーさんの経験から、組織をうまくまとめるのには潜在的な衝突を早めに出してあげて、つまらない障害を早く乗り越えてチームをまとめる。タックマンモデルというらしい。 #xpjugkansai

【2－3】KPTは日本人のチームに向いている
・ほとんどの日本人は、自分の意見を表明する行為に慣れていない
・意見表明に慣れていない人からKPTで本音を引き出す

【2－4】KPTのタイミングに注意しよう
・WF型開発はふりかえりするタイミングが取りにくい

【3】懇親会で感想を聞いたら、プロジェクトリーダーや管理職以上の方には、気づきが多かったらしく、参考になったという意見をもらえて嬉しかった。
ただし、チーム運営の経験がない開発者には、遠い世界の話に聞こえたらしく、その点は反省点かもしれない。