「not 緊急 but 重要」に取り組む1週間 / Kaizen Week #7を開催しました

こんにちは、つくばからリモートワークしている池田(@ikedaosushi)です。 Kaizen Platformでは定期的に「Kaizen Week」という取り組みをしています。 これは、 日常のプロジェクトを一時停止し、普段の業務では優先度を上げずらい「リファクタリング」「新しいツールの導入」などのタスクに1週間取り組もう、というイベントです。最近では3ヶ月に一度開催されています。

この記事ではKaizen Platformではなぜ「Kaizen Week」に取り組み、どんな工夫をしているのか、どんな成果が得られたのかを書きます。

Kaizen Weekをする理由「not 緊急 but 重要」

Kaizen Weekの目的は「緊急ではないが重要なタスクをする」ことだと思います。下の図は有名な「7つの習慣」に登場する優先度のマトリックスです。普段の業務では重要度に関わらず緊急度の高い「第Ⅰ領域」「第Ⅲ領域」の仕事をやってしまいがちです。

f:id:kaizenplatform:20190815213945p:plain

そのまま緊急度はないが重要度の高い「第Ⅱ領域」を放置していると、長期的な視点で考えたときに大きなリスクを負ったり機会損失をしてしまいます。「リファクタリング」は最たる例です。

「Kaizen Week」を定期的に開催することで意識的に「第Ⅱ領域」のタスクに取り組むことができます。 また個人的に大事だと思っているのが「『個人的に興味があるタスク』をするわけではなく『重要度の高いタスク』をする」ということです。この類のイベントをすると誤解されやすいポイントだと思います。

工夫とその結果

さて前置きが長くなってしまいましたが、今回の「Kaizen Week」の話に移ります。 効果的な「Kaizen Week」にするために以下のようなことを工夫しました。

  • 運営をエンジニア持ち回りに変更
  • 「事前調整会」の実施
  • 投票制度/表彰制度の廃止

1つずつ簡単に説明します。

運営をエンジニア持ち回りに変更

直近の数回の運営はマネージャーが行っていたのですが、今回から参加者であるエンジニアが運営を行うことにしました。理由は、参加中の気づきや改善点をより効果的に「Kaizen Week」の運営に反映するためです。今回は木暮と池田(自分)の2人で行いました。

実際に、これ以降で説明する2つの工夫はエンジニア視点から生まれたものだったので、良い効果があったのではないかと思います。ただ懸念として一部のエンジニアに負担が集中する可能性がある一方、毎回運営者が変わると知見を引き継げないという観点から、今後は開催の度に2人中1人が入れ替わっていくシステムに落ち着きました。

「事前調整会」の実施

2つ目の工夫として「事前調整会」を実施しました。 「事前調整会」とは何かを説明する前に何が課題だったか書きます。

前回までの「Kaizen Week」で以下のような事件が発生しました。

  • 発表会でほぼ同じテーマに別々の人間が別々に取り組んでいたことがわかる
  • 発表会で別のメンバーから「この方法使えば、それしなくてよいよ」とちゃぶ台返しを受ける

このような悲しい事件を解消するために「取り組みたい内容や普段困っていること」を共有する「事前調整会」を開催しました。

開催にあたって事前に、「Asanaにやりたいこと/困っていることをそれぞれ2つ以上書き出す」という準備を行い、それを元に話し合いました。 書き出された内容が下の図です。ノルマは「2つ以上」だったのですが、想像以上に集まりました。これでも載せきれていないです。

f:id:kaizenplatform:20190815185519p:plain ※社内プロジェクト名等はぼかしています。

「事前調整会」前にAsanaの機能を使って「コメント」や「いいね」で反応し合いました。画像をよく見てもらえるとその様子が確認できます。 それにより、そのタスクをメンバーがどのくらい重要に感じているかがわかり、テーマの選択に非常に役に立ちました。

また「直近入ったメンバーがそもそも『Kaizen Week』で何に取り組んでいいのかわからない」という課題もあったのですが、この「事前調整会」で新しいメンバーに社内の課題が共有でき、(それだけでも価値があるのですが)「Kaizen Week」にスムーズに取り組んでもらうことができました。

投票制度/表彰制度の廃止

最後は投票制度/表彰制度の廃止です。これは実施するにあたって一番悩んだ内容です。

Kaizen Weekでは最終日に発表を行うのですが、元々は「よかった発表」に投票し、「1位だった発表者は表彰される」というルールがありました。 「お互いに褒め合うこと」や「競争意識がモチベーションに繋がる」ことは良いことなのですが、一方で「テーマを選ぶ際に『投票ウケ』が良さそうなものを選んでしまうバイアスが生じやすい」という問題点を感じているメンバーがいました。

自分も同感だったのと、個人的には「モチベーション3.0」で語られている「外的な報酬を与えることで内発的動機を失ってしまう」ケースが引き起こされる可能性もあるかもしれないと感じていて、今回試験的になくしてみました。

モチベーション3.0 持続する「やる気!」をいかに引き出すか (講談社+α文庫)

モチベーション3.0 持続する「やる気!」をいかに引き出すか (講談社+α文庫)

ただ、正直実際にやってみて「表彰がないと盛り上がらない」や「あったほうがモチベーションが上がる」という意見も一部あるかと思ったのですが、事後アンケート取ったところネガティブな意見はなく、下記のようにポジティブな意見をもらえたのでやってよかったと思いました。

Aさん(事後アンケートより)

評価制度がなくなったのがマインドフリーになってよかった

Bさん(事後アンケートより)

投票制でランクがなくなったので好きなことできる開放感

とは言え、一回やってみただけで結果を判断するのは時期尚早なので、他にもパターンを試してみたいと思います。

以上が今回取り組んだ工夫でした。

今回のKaizen Weekの成果

最終日にそれぞれが取り組んだテーマを発表しました。

f:id:kaizenplatform:20190815183951p:plain

各々が意義のあるテーマに取り組んでいて、大変刺激になりました。 一部を抜粋すると今回は次のようなテーマに取り組みました。

  • SP対応がまだだったプロダクトのSP対応
  • 社内用Chrome Extensionの改善
  • PaperclipからActive Storageへの移行
  • AWS検証環境、開発環境の整備
  • スケジュール調整アプリ開発
  • Amazon Personalizeを使ったPoCサービス開発

また今回は人事がRails開発やってみたという挑戦的な試みもあって面白かったです。

さいごに

Kaizen Platformで取り組んでいる「Kaizen Week」と、工夫していることを紹介しました。 同様の取り組みされている企業も多いと思いますので、ブログや勉強会等でお互いの知見を共有できたら幸いです。

Kaizen Platformでは「Kaizen Week」以外にも様々な取り組みをしていますので興味ある方はチェックしてみてください!

developer.kaizenplatform.com

developer.kaizenplatform.com

developer.kaizenplatform.com