2015.09.06

KPTを開始。CDもついてるよ

キーワード：KPT , TechBlog

週1参戦要員tbpgr（てぃーびー）です。
今回は改善を慣習化するためのKPTを導入しました。

私のプロジェクト参画当初からKPT（ケプト）をやる、ということは決めていたのですが
今週ようやくプロジェクトが１つの節目を迎えたのでこれから
2週間に1回KPTを行うことになりました。

KPTとは？

Keep, Problem, Tryの略で、これらを定期的に見直すことで
チーム・組織・個人を持続的に振り返り、改善させるための手法です。

KPTについては、既に様々なブログなどで情報を集める事が可能なので
詳細は割愛します。

Keep

続けること。
継続してKPTを行っている場合は、Problemを解決するためのTryとして
挙げた内容のうち実際に実施・継続している内容になります。

Problem

改善、解決すべき問題点です。

Try

問題点を解消するために次に挑戦することです。

前提条件

チームは全員KPT未経験者です。
私は個人でのKPTの利用経験がありますが、組織での利用経験はありません。

このような経緯から、私がファシリテーターをつとめました。
KPTの概念自体は事前に説明済みです。
ファシリテーターの立ち位置なので、基本的には進行中に個別の意見は出しませんが
全員の意見を出し終わった段階ででていない意見については最後に加える形をとりました。

ホワイトボードを利用してKPTを行い、
若手のTさんにesaにリアルタイムで議事録を作成してもらいました。

esaにまとめてもらった内容をもとに荒目の粒度で
TrelloにKPTの内容を反映し、管理しています。

ファシリテーターとして意識したこと

順序

まずはKeepから話すことにしました。
KPTによる振り返りは、Keepしている良い点を喜ぶことができる側面もありますが、
できていないダメなこと、不足していることを洗い出すことでマイナス面もできてます。
これが前面に出てしまうと「できていない感」や「ストレス」が膨らんでしまうおそれがあります。
そのため、明るい話題が期待できるKeepから挙げることにしました。

粒度

今回はプロジェクト単位でのKPTだったので、
粒度が細かくなりすぎないように気をつけました。

例えば

Problem「新規フィーチャーの追加速度が遅れている」
=> Try「システム全体の保守性の向上と、開発環境の整備を行う」

くらいの粒度です。

細かくなりすぎそうな場合は、途中で話を止めようと思っていましたが
今回はその必要がありませんでした。
ただし、発想が広がる場でもあるため、せっかく広がりそうな発想の邪魔をしないためにも
ある程度は詳細についても話してもらいその内容は議事録に残す形にしました。

以下、どんなKPTがあったか抜粋して紹介します。

Keep

持続できている導入内容について話しました。

GitHub Issue, Trelloの導入による課題管理
esaの導入による情報共有
数理的分析を利用して、システムが生成するレポートの質を継続的に改善する

などが挙げられました。
6月末の私の参入以降GitHub, Trello, esaなどが導入され
ワークフロー、情報共有などがかなり改善されました。

また、このプロジェクトは、東京工業大学の河瀬康志先生に監修していただき、
最適化の分野のプロフェッショナルと共に開発を行っています。
そのため開発初期から継続して数理的分析による改善を継続しています。

Problem

Issueの消化率アップが必要
メンバーの兼業があるため、生産性が落ちている
仕様の齟齬が少なからず発生している

などが挙げられました。

今回の開発は外部APIとの連携部が複数あり、そういった部分で想定外の作業コストが
発生しました。結果として想定よりも開発工数が多く、現状積み残しているIssueが多めになっています。

また、一部機能については外部の開発者の方にもリモートで開発にご協力いただいています。
その際にどうしても非同期、チャットのテキストベースのコミュニケーションが中心となるため、
仕様の齟齬が発生することが多くありました。

Try

Problemを受けての内容です

開発環境を整備し、開発チームをスケールしやすくする
開発体制の強化を行う
リモート開発支援ツールの検証・導入
ユーザーストーリーの導入、受け入れ基準の作成

などが挙げられました。

想定よりも開発工数が多く必要だということがわかったため、開発体制の強化が必要です。
ただし、闇雲に強化すればむしろ作業効率落ちてしまいます。
そのため、インフラ・開発環境・その他を含み開発チーム自体をスケールしやすくします。
Vagrantによる開発環境構築、インフラ自動化、etc..など優先順位をつけて継続的に改善します。
これらの改善が実施されれば、自然と兼任は減るという想定です。

仕様齟齬の改善索として、リモート支援ツールの選定・導入やユーザーストーリー、
厳密な受け入れ基準の作成を行います。

CDとは？

私が個人ブログで紹介した概念としてKPT-CDという独自の概念があります。

個人での KPT の活用開始と KPT-CD という独自概念について – Tbpgr Blog

KPTについては多くの場でブログエントリなどを見かけますが、Keepのうまくいったことや
うまくいかなかったことを情報としてどう残すか？という話題をあまりみかけません。

そのため、私は個人KPTで行った内容のうち慣習化したもの、そうではないものを
esaに履歴として残すようにしています。
これを残すことでKPT自体に対する振り返りの材料とします。
前回行ったKeepのうち、Disposalにいったものは何故失敗したのか？
Conventionにいったものは何故成功したのか？
KeepすべきTryやProblemの対応策としてのTry自体の質に
ついて考えるための材料になります。
この部分も振り返りによって改善することで、振り返り自体の質も改善することが狙いです。