アジャイル開発での根本的な改善活動--KPTから考える「ふりかえり」の重要性

吉原庄三郎 (ウルシステムズ) 2016年07月15日 07時00分

  • このエントリーをはてなブックマークに追加

「ふりかえり」はゴールの共有が重要

 アジャイルによる超短期リリースを実現するために欠かせないのが自己組織化であることは以前に述べた。その自己組織化を実現するための具体的な手法が「ふりかえり」である。

 文字通り、イテレーションの終わりに開発チームのメンバーでユーザーに価値のあるシステムを提供できているか、品質や生産性をもっと向上できないかを振り返る。デイリーミーティングが品質や生産性の微修正なら、ふりかえりは次のイテレーションに向けて根本的な改善を図る活動である。開発チームが自分たちの仕事のやり方を自らの手で改善することでプロジェクトマネージャに指示されるのではなく、ボトムアップでの自己組織化を実現できるわけだ。

 アジャイル開発をやったことがある読者なら、きっとふりかえりの経験もあるはずだ。アジャイル開発のプロジェクトに2回ほど参加すれば、5回や10回はふりかえりを経験することになる。それだけに「わかっている」つもりになっている人も散見される。

 しかし、実はふりかえりにも技術が必要である。ふりかえりを行っている様子を見れば、チームの自己組織化の度合いが分かると言っても過言ではない。

 重要なポイントを外すと、ふりかえりの効果は薄れる。確かにイテレーションが終わる節目の度にチームで話をすることに一定の意味はある。チームの状況を話しあうことで一体感が生まれることだろう。

 しかし、それも最初だけである。具体的な成果につながっていると実感できなければ、マンネリ感が漂い、ふりかえりが形骸化することになる。今回はより多くの成果を生み出し、自己組織化を促すふりかえりのポイントを解説する。

 なお、ふりかえりの手法にはいくつかあるが、今回はKPT(ケプト)を念頭に置いて話を進める。1990年代後半にAlistair Cockburn氏が紹介した後、日本国内のアジャイル界隈で圧倒的な人気を博している手法だ。

 KPTは「Keep」「Problem」「Try」の頭文字から取ったものだ。Keepは継続すべき良かった点、Problemは改善を要する点、TryはProblemの解決策やKeepをさらに改善する方策をそれぞれ指す。

 イテレーションの終了時、自分たちの活動についてKeep、Problem、Tryの順に話し合う。KPTは非常にシンプルで初心者でもとっつきやすいため、筆者もよく使っている。

分析的な視点を持つ

 ふりかえりのポイントの1つめは分析的な視点を持つことだ。KPTは使うだけですぐに効果的なふりかえりができるわけではない。KPTはあくまで問題点を上げた上で解決策を考えるだけのものである。

 実際にやってみると分かるが、これがなかなか簡単ではない。とりわけ難しいのはProblemを提示することだ。何を問題として挙げるべきかわからないのである。これはチームで自己分析するということが日頃の習慣になっていないからだ。

 例えば、読者が所属するチームの問題点を幾つか書き出してみてほしい。開発手法はアジャイルではなくウォーターフォールでも構わない。どうだろう。

 第三者にも説明できるように書くとなると筆が止まるのではないか。きっと読者は普段から感じていることがあるはずだ。それでも日頃から分析的に観察していなければ、ふりかえりの短い時間でポンポン発言することは難しいのだ。

 問題発見や課題設定が難しいのはロジカルシンキングなどでも言われていることである。最初からチームを分析的な視点を捉えることができるメンバーは珍しい。一番の近道はデキる人と一緒に振り返ることだ。

 開発チームが未熟な間はアジャイルコーチなどの第三者にファシリテートしてもらうのがよい。コーチに刺激を受けて観点が刷り込まれていく。ふりかえりを開発チームだけで行えるようになれば本物といえるだろう。

 ちなみに、ふりかえりをする際に数を追うのは避けたほうが良い。アジャイルコーチによっては、とにかく沢山のProblemを出すことを薦める場合がある。

 しかし、8人チームで1人30個の課題を出すと、1回のふりかえりで240個ものProblemにもなる。大半は重要度の低いものだろう。共有するだけでもメンバーが疲弊してしまう。むしろ、最も重要だと思うProblemを1人1つずつ出してもらい、それを丁寧に話し合う方が効果は大きい。

目的を明確にする

 2つめのポイントは、ふりかえりの目的を明確にすることだ。例えば、チームメンバーが「コミュニケーションが足りない」というProblemを出したとしよう。

 こういったテーマは多くのメンバーが共感するところだろう。では、Tryは「毎日、休憩時間には雑談をする」「何か困ったらすぐに相談する」「毎週、飲みに行く」としよう――。これは論理的に分析することに慣れていない人が陥りやすいパターンである。

 そもそもコミュニケーションとはなんだろうか。どんな形のコミュニケーションが望ましいのだろうか。コミュニケーションは多いほどいいのだろうか。

 これらを何の基準も持たずに議論したら、時間がいくらあってもキリがないだろう。本来必要なのは、目的に対して最適なコミュニケーションのあり方である。ふりかえりにおける議論とは特定の目的に対して行われるべきものなのだ。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

  • このエントリーをはてなブックマークに追加

この記事を読んだ方に

関連ホワイトペーパー

連載

CIO
ITアナリストが知る日本企業の「ITの盲点」
シェアリングエコノミーの衝撃
デジタル“失敗学”
コンサルティング現場のカラクリ
Rethink Internet:インターネット再考
インシデントをもたらすヒューマンエラー
トランザクションの今昔物語
エリック松永のデジタルIQ道場
研究現場から見たAI
Fintechの正体
米ZDNet編集長Larryの独り言
大木豊成「仕事で使うアップルのトリセツ」
山本雅史「ハードから読み解くITトレンド放談」
田中克己「展望2020年のIT企業」
松岡功「一言もの申す」
松岡功「今週の明言」
内山悟志「IT部門はどこに向かうのか」
林 雅之「デジタル未来からの手紙」
谷川耕一「エンプラITならこれは知っとけ」
大河原克行「エンプラ徒然」
内製化とユーザー体験の関係
「プロジェクトマネジメント」の解き方
ITは「ひみつ道具」の夢を見る
セキュリティ
エンドポイントセキュリティの4つの「基礎」
企業セキュリティの歩き方
サイバーセキュリティ未来考
ネットワークセキュリティの要諦
セキュリティの論点
スペシャル
エンタープライズAIの隆盛
インシュアテックで変わる保険業界
顧客は勝手に育たない--MAツール導入の心得
「ひとり情シス」の本当のところ
ざっくり解決!SNS担当者お悩み相談室
生産性向上に効くビジネスITツール最前線
ざっくりわかるSNSマーケティング入門
課題解決のためのUI/UX
誰もが開発者になる時代 ~業務システム開発の現場を行く~
「Windows 10」法人導入の手引き
ソフトウェア開発パラダイムの進化
エンタープライズトレンド
10の事情
座談会@ZDNet
Dr.津田のクラウドトップガン対談
Gartner Symposium
IBM World of Watson
de:code
Sapphire Now
VMworld
Microsoft WPC
Microsoft Connect()
HPE Discover
Oracle OpenWorld
Dell Technologies World
AWS re:Invent
AWS Summit
PTC LiveWorx
吉田行男「より賢く活用するためのOSS最新動向」
古賀政純「Dockerがもたらすビジネス変革」
中国ビジネス四方山話
ベトナムでビジネス
日本株展望
企業決算
このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]