いわゆる「ふりかえり」にKPT（Keep, Problem, Try）というフォーマットを使うことはよくあると思います。KPTって何？という方はこちらの書籍をどうぞ！
エンジニアはKPTのProblemに知識の無さを挙げがち
ことエンジニアの職場だと、KPTのProblemに「◯◯がよく分かっていない」みたいな項目を挙げがちなのかなー、と思います。
例えば、
- ActiveRecordがよく分かっていない（ので、作業に時間がかかった）
- 正規表現がよく分かっていない（ので、プルリクを差し戻されまくって時間がかかった）
- Rubyがよく分かっていない（ので、既存コードが上手く読めなくて時間がかかった）
みたいな感じ。
これでTryが「もっと勉強する」・・・みたいな感じになるのですが、そのTryはゴールが全然見えないのでTryになっていないし、そもそもこれが「問題」だとは思えないんですよねー。
そもそも問題とは何か
そもそもKPTのProblemには「起きてしまった問題」を挙げるのがコツです。
参考：
自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ
例えばActiveRecordがよく分かっていなくて作業に時間がかかって結局チケットが一つも消化できないまま1日を過ごしてしまったのなら、それは確かに問題なのですが、その理由はActiveRecordというより、何で自分でその問題を抱え込んだの？という事になると思います。つまりこの場合の問題は「問題を抱え込んでしまったこと」なんですね。
だから知識の無さが直接問題に結びつくのかというと、そうではないと思います。
◯◯がよく分かっていない、ということに気付けたのは、逆に良いこと
逆に知識の無さに気付けたのは良いことなのではないか、とすら思います。
世の中「正規表現を使えばもっと上手くコード書ける？ いやいやいや、動いてるんだから良いじゃないっスかｗｗｗｗｗ」という人はザラにいるんですよ。
でも知識の無さをProblemに挙げる人は、正規表現を使えばもっと上手くコードを書けることに気付いた。ちゃんとこういう感度を持って仕事にあたれていた。これは僕的にはKeepなんです。日々の作業の中で「もっとこうすれば上手くいく」という気付き、これが継続していけば、どんどん自分のやり方が改善されていきますよね。
逆に感度がない人はProblem。1週間を通して気付きがないなんて、ちょっとつらいなと思います。
だから気付けたことをKeepに挙げましょうよ。そうやって気付きが得られるような日をどんどん増やしていけば、技術力だってガンガン伸びますよ。知識の無さに気付けたことをProblemにしてしまうなんてもったいない、と僕は思うのです。
