KPTとリソース調整会を導入してエンジニアのワークスタイルを改善した話
こんにちは遠藤です。
前回の私の記事では、co-meetingでは毎週水曜にエンジニアメンバーで勉強会を開いているという話をしました。
今回は、その中から第３週のKPTと毎週月曜日に実施しているリソース調整会について紹介します。
co-meetingでのKPTの活用について
co-meetingのエンジニアチームでは、毎月第３水曜日にKPT会を実施しています。KTPを導入したのは2022年4月くらいですのでこれまで半年くらい実施しており、振り返る機会を定期的に持つことによってワークスタイルはかなり改善してきています。
KPTとは
そもそもKPTとはですが、KPTはKeep・Problem・Tryの頭文字で、振り返りをするためのフレームワークの一つです。
Keepは継続したい良い行い
Problemは発生した課題や問題点
Tryは明日以降に新しく取り入れた取り組み
を整理します。
co-meetingのKPTの様子
co-meetingは全社員リモートワークですのでKTPはオンラインの付箋ツール？のmiranoteを利用してまとめています。
以下は前回11月に実施した実際のKPTの様子です。
KPTを実施する目的
co-meetingのエンジニアチームが実施するKPTは、どちらかというとワークスタイルに関することを対象としています。
KPTを導入した当初の目的は、漠然と振り返りの時間をちゃんと確保しようということでした。
基本的には、今も大きくは変わりませんが、日々仕事をするにあたって気持ちよく効果的に仕事ができるような改善案を挙げ、それを実施することを目的としています。
KPTでよく議論する内容には、以下のようなものがあります。
効率的に作業時間が確保できているか？それを阻害するものは何か？
作業を進めているにあたって困っていることは無いか？改善可能か？
毎週水曜の勉強会やコピペテックなど継続的に活動できているか？そのためにはどうするか？
プロダクトもくもく会が効果的に実施できていない。どうする？
コミュニケーションや情報共有方法に問題はないか？改善すべき施策は
チームの一体感が薄い。どう解決するか？
改善案が実際に実施されたかの振り返り
内容は、エンジニアチーム全体が対象のものが中心ですが、メンバーは4人と少ないので個人的な内容も挙がったもします。他にも、エンジニアチーム内のことに関わらず会社全体についてもよく話題があがります。
KPTより生まれた改善点
実際にKPTによってこの半年ほどで改善したことをいくつか紹介してみます。
各勉強会の宿題などふわっとしたタスクの廃止 < なんとなくTodoリストに残り続けている終わらないタスクが減った
「コピペテック」や「プロダクトもくもく会」の進め方の改善
リソース調整会の導入とその改善
その他の時間の把握と、削れるところは削った
全社定例が短くなった
最近ではだいぶProblemが減り、KPTは15分程度の時間で終わるようになってきています。
勉強会は一度始めるとなんとなく継続してしまうものがあります。「プロダクトもくもく会」はチームの一体感をもっと出したいという課題を解決するために月1回で1日かける形で始まりました。しかし、掛けている時間の割には効率的な運営ができなかったこと、終日の勉強会は他に「コピペテックもくもく会」もあり業務を圧迫しすぎること。が課題となり、改めて水曜日に2時間のみに短縮してみるというTRYをしています。今の所、短い時間でも集中して良いアウトプットが出ているのでこのまま継続できそうです。
TRYを実施した後にKeepかProblemか継続的に観測できるところがKPTの良いところです。
また、「ふわっとしたタスクの廃止」の例では、担当するプロジェクトの作業もそれなりにある中、弊社は残業なしを推奨していますし、各自の判断で作業の合間に勉強会の宿題などを入れ込んでこなしていくことは結構難易度が高く、各自のToDoリストに残ったままとなってしまうような状況がありました。
例の一つは「フロントエンド勉強会」です。今は水曜の2時間に限定していますが、以前は次回までに合間を見つけて実装をすることにしていました。そうすると、勉強会の宿題はToDoリストに残り続けて、リソース調整会のたびに「先週はToDoに挙げていたけど時間が取れなかった」という報告が上がることになります。業務の状況などに応じて取れる勉強会の作業にあてる時間に差も生まれてしまうので仕方ない面もありますが、精神衛生上も良くないという問題点もありました。そこで今の形にKPTで話し合い今の形、フロントエンド勉強会に関わる作業と学習は第4水曜日の2時間で完結するように実施することになりました。
リソース調整会について
次に、毎週月曜日に行っているリソース調整会について紹介します。（こちらは簡単に）
リソース調整会は、いわゆるチームの定例会のようなものですが、各メンバーの業務調整のみに絞って15分程度で行っています。
リソース調整会の前に各メンバーはQuip文書に「先週やったこと」と「今週やること」とそれに掛ける・掛けたざっくりの時間を書き出しておきます。
会本体では、主に調整が必要なトピックについて相談し合います。
リソース調整会の目的
弊社の働き方の特徴の一つですが、各メンバーは製品とクライアントワークを複数掛け持ちし担当します。
リソース調整会を始める前は各プロジェクトの状況に合わせたリソースの配分を各自または関わる人のみで判断しながら作業を進めていました。
しかし、各プロジェクトの時間配分は決まっており、祝日やもくもく会のある週、トラブル対応などの突発的な業務があった場合にはプロジェクトにかける時間が圧迫されます。その調整を、各自で判断するのは難しく、また、よく発生することなので都度相談する時間を設けるのも手間です。それを解消するため定期的に相談する時間を設けたいというのが一番の目的です。
あとは、新しい技術のキャッチアップや各勉強会の準備といった1ヶ月くらい少し長めの期間を掛けて行う作業が必要な場合の業務調整にも利用しています。
さらに、弊社は基本的には残業はしない方針なので限られた時間でどうタスクを回していくかという課題はより切実です。
そこで、各メンバーが現在持っているタスクを共有してチーム全体で話し合い調整を行うという機会を設けるための会を週一回定期的に行うことにしました。
何を調整しているのか？
例えば、以下のような調整を行っています。
プロジェクトにかける時間の調整
公開イベント「ゆるっとSalesforce」の発表担当者の業務調整
新しい技術の調査の時間確保
その他、イベント発生時の業務調整
など
効果としては、実際に勉強会の準備やコピペテックの活動などをちゃんと業務時間内で確保できるようになったこと、各自が持っているタスクが以前より把握しやすくなったことなどがあります。
KPTほど効果が見える形では現れないですが、各メンバーの精神的負担は軽減されていることとは思っています。
リソース調整会についてはまだ改善の余地がありそうですが、そのあたりはKPTで議題になることでしょう。
ふりかえり（個人的な所感）
以上、co-meetingエンジニアチームの取り組みの中からKPTとリソース調整会について説明してみました。
KPTは、遠藤個人的には各プロダクトごとのエンジニアリングについても将来的に実施できればと考えています。
現在は、すべてのメンバーが製品とクライアントワークの掛け持ちで動いていることもありプロダクト開発に安定したリソース確保できていないため定期的な振り返りを効果的に行うことが難しそうなのでやっていないですが、製品開発に関わる時間とメンバーが増えた際には必要になってくるのではと思っています。
ところで、co-meetingではエンジニア勉強会に力を入れていますが、それはエンジニアは実作業以外の時間にある程度は学習をし続けないと新しい技術のキャッチアップができずに腕が落ちてしましまうものなのと（これは一般論かと）、エンジニアにとって学習はそもそも楽しいものですのでその時間を大切にしたいと考えているからです。
私も含め子供が居るエンジニアあるあるですが、子供が帰ってくると集中して仕事は出来なくなりますし、土日は自分の時間は無いので平日昼間に学習の時間もちゃんと確保しながら仕事をこなしておくのが望ましいです。
自分は役員なので時間的縛りはゆるいですが、そうではない場合に業務時間である程度学習時間をカバーできるようにしたいものです。それを模索し続けるているわけですが、KPTはそれに一役買っていそうです。
また、今期の当初に上がっていた課題としては各メンバーが一体感がないといったところは、各勉強会の継続的な実施で改善しつつも実業務ではなかなか解決できていないかもしれません。
これはリモートワークだからというよりは仕事内容、組織の構成に依るもので、CalsketもMatchingMapもそれほど大きい製品ではないことと、なによりSalesforceプラットフォームを利用している恩恵もあり一般的なプロダクト開発より小さいリソースで開発ができてしまうので全員で製品開発する必要はなく、現在のビジネスを継続している限りは仕方ないのかなとも思います。
とはいえ、その割には一緒にしている感もだいぶ改善できています。
以上です、KPTは手軽にはじめられ継続しやすいフレームワークなのでお勧めです。まだやっていないチームはぜひ取り入れてみてはいかがでしょうか？
次は、「プロダクトもくもく会」か「ゆるっとSalesforce」について書きたいと思います。