個人とチームの習慣化について

「Applibot Advent Calendar 2020」 9日目の記事になります。
前日は@MuuSanさんのUnityプロジェクトでPerforceを扱う方法 という記事でした!

今回の記事は、私が個人的に大事にしている「習慣化」について書きたいと思います。

はじめに

「エンジニアリング組織論への招待」という本を読んで、強く印象に残ったフレーズがあります。

能力は習慣の積分、習慣は行動の積分¹

より良いプロダクトを開発していくためには個人の成長はもちろん、チームの成長も必要になってきます。

成果に繋がるような能力向上を目指して、自分やチームが実践している「個人の行動の習慣化」と「チームの行動の習慣化」についての試みを紹介します。

個人の行動の習慣化

習慣化アプリを使う

まず自分自身の行動については、習慣化アプリを使ってサポートしてもらうのが楽です。
TODO系アプリ全般に言えることですが、外部ツールにTODOを退避させることで「あれをやらなきゃ、これをやらなきゃ」と思い出すコストを削減し、脳内メモリを浮かせます。

私は最初「Momentum」というアプリを使っていましたが、最近は「habitify」というアプリを使っています。使い方はどのアプリもだいたい同じで、「習慣行動を達成したらタップする」だけですので、基本的には何を使ってもいいと思います。

習慣化アプリを使うことを習慣化する

まずオススメしたいのが、「起床する」のような1日の始めに必ず行うであろう行動を登録しておくことです。

これにより、1日の始まりとともに1つの習慣行動が達成できます。
達成行動をタップして消す気持ちよさを感じて、徐々に__習慣化アプリを使うことを習慣化していく__のがスタート地点になります。

いきなり理想を目指さない

習慣化で最も多い失敗は、挫折をすることです。

理想的でハードルの高い習慣行動をデザインするほど、挫折のリスクが上がるトレードオフがあります。

ウサギとカメの寓話でいうところのカメ側をイメージして、少しずつでも着実に進んでいけるように習慣行動を設定します。

起動しただけで成功とする

私の設定例ですが、画像のような「英単語アプリを起動」という起動行動だけを登録して、後はその時の気分に応じて好きなだけ学習するようにしています。

最初は、「英単語を30個覚える」のような回数制の習慣行動にしていたのですが、どんどんそれがノルマに感じられ、画面を見た時に「30個も覚えるのしんどいな・・・」とめんどくさい気持ちになりました。
「今日はしんどいからパス」となる日も増えてしまって習慣化に失敗したため、今は__アプリを起動すれば成功__としています。

回数式にするなら、失敗することが難しい回数にする

腕立て伏せやスクワットなどのそもそも起動という概念が無い行動については、「腕立て伏せを1回する」「スクワットを5回する」など、失敗することすら難しい回数に設定しておきます。
回数を達成した後は、その時の気分に応じて続けるなりやめるなりしています。たいてい、腕立て伏せを1回やったらまだまだ余裕があるので続けて何回か実行することになります。

ここで大事なのは、1度に多くの回数をこなすが挫折して回数=0の日が続きがちな__微分重視の考え方__ではなく、1度の回数は少ないけれどコツコツ継続して合計回数は大きくなる__積分重視の考え方__でいることです。

運動不足を知る

運動習慣の記録を取り始めて感じたのは、「運動をした気になっていること」が多いことでした。

「1~2日前に運動したよな?」と思っていたけれど、記録を見返したら「最後に運動したのは3~4日前だった」なんてことがよくあります。
これがひどくなると、1~2週間に1回軽く運動しただけで「自分は運動しているぞ」と麻痺してしまって、運動不足の自覚がなくなります。

運動は健康の維持だけに限らず、記憶力の向上やストレス解消などにも役立つと言われているので、能力を向上するためにも是非とも習慣化したい行動です。

振り返りを促す

ただ単に習慣行動を増やせばいいというわけではなく、なるべく改善に繋がる行動を習慣化したいので、振り返りは大事にしています。

習慣化アプリでは曜日設定もできるので、毎週月曜日に「先週の振り返りをする」を登録して毎週一人でKPTを実施しています。

また、「日記を書く」と「過去の日記を見返す」という習慣も毎日行っています。
日記ツールは今まで色々変遷してきたのですが、今は Scrapbox に1日1ページで書いています。

Scrapboxのランダムジャンプ機能を使って過去の日記を見返すと、今となってはどうでもいいことで当時重く悩んでいたりしていたことなどが見え、大抵の悩みは数日後にはどうでもよくなるんだなと実感します。

習慣化しないほうがいいこと

逆に習慣化アプリに登録して失敗したという行動もあります。
自分の好きなゲームや、仕事に関係しそうなゲームのデイリーミッションを達成するといった行動です。

失敗の理由としては、

• 本来楽しんでプレイするはずのゲームに義務感が生まれてしまったこと
• 惰性で続けるための理由になってしまうこと
• 達成するために一度プレイし始めてしまったら思ったより時間がかかってしまって睡眠時間を削るハメになること

などが挙げられます。
自分が楽しむための行動を義務化しないほうがいいですし、睡眠時間を削ってでも習慣行動の達成を優先するのは、パフォーマンスを逆に下げてしまって元も子もないのでオススメできません。

チームの行動の習慣化

自分一人だけが行えればよい行動の習慣化と、チームのような複数人で行う行動の習慣化では大きく事情が異なります。

チーム全員が認識でき継続して行動できるようにするのは、個人の習慣化よりも遥かに難易度が高いです。

Slackリマインダーを活用する

チームメンバー全員が日常的に確認できる場として、チャットツール上で通知をするのが最有力候補になります。

例えばWikiに各自の項目を書いておいてほしい定例MTGの事前に、Slackリマインダーで「ページを更新しておいてください」と通知しています。「リマインドされたらWikiを書く」とだけ憶えておけば、個人の習慣化の時と同じく脳内メモリを節約できます。

ただし、Slackのリマインダー通知が増えてくるにしたがって「通知麻痺」なるものが発生し、通知が来ても気付かない人が増えてくるので要注意です。
習慣行動を促せる適度な通知感覚が人によって異なっているのが、チームで習慣化を実践する難しさの１つです。

GitHub Scheduled remindersを活用してpublicチャンネルのノイズを減らす

これは同僚に教えてもらったのですが、GitHubのPull Requestに関する通知をSlackのDMで送ってくれる設定も便利です。
参考: [GitHub] Scheduled remindersでPull Requestのレビュー依頼をSlackに通知してみた

DMなので、Slackのpublicチャンネルを汚染しないのが最大のメリットだと感じています。

テストの自動実行と通知があるからテストを書く習慣ができる

これも同僚のおかげなのですが、UnityでのEditTestをJenkins上で毎日実行し結果をslackに通知する仕組みがあります。これにより、EditTestをちゃんと書くというモチベーションが保てています。

みんなが見えるところに成否の通知が来るから頑張ろうと全員で行動するのが、実質チームの習慣化になるかなと思います。

毎週のチーム振り返り活動

なんだかんだで今の所、「チームで振り返りをすること」がチームで一番習慣化したい活動かなと感じます。

今のエンジニアチームでも毎週KPTを実施する意気込みでやっていたのですが、どんどんKPTで挙がる項目が減ってきて、飽きが発生し、「今週はSkipしましょう」となりがちでした。

そこで、毎週のファシリテーターをローテーション化し、その__ファシリテーターが「何かしらの振り返り方法を考えてきて実施する」というメソッド__になってからは、Skipをすることが少なくなり、チームでの振り返りが習慣化できてきました。

例えば、以下のような振り返りを今まで実施してきました

• YWT(やったこと、わかったこと、つぎやること)
• FDL(楽しかったこと、やったこと、学んだこと)
• それぞれが悩みをぶっちゃける会
• 期待値調整
• モチベーションポーカー
• パーソナルマップ
• 360度評価のライト版
• などなど

習慣は飽きとの戦いでもあるので、「毎週チームで何かしらの振り返り活動をする」という行為だけを習慣化して、実際にやる内容自体をランダム化して飽き対策をしたのが良かったと思います。

まとめ

続かない習慣は色々ありました。
特に、チームにおける習慣化はたくさん試してたくさん継続できずに失敗しました。

とはいえ、習慣化できなかった行動はタイミングが悪かっただけかもしれないので、しばらくして環境が変わったらまた試してみればうまくいくかもしれません。また、惰性で続けているなと感じた習慣はやめてみたり、ちょっとやり方を変えてみることも大事だと思います。

逆に、1日の行動をガチガチに習慣化しすぎてしまうと、柔軟性や余裕がなくなって差し込みや仕様変更に臨機応変な対応ができなくなります。
適度に余白を持たせて、カメのように行動を積み重ねていきたいなと思います。

以上、「Applibot Advent Calendar 2020」 9日目の記事でした！
明日は @yucchiy さんです！

1. 広木 大地. エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング (Japanese Edition) (Kindle の位置No.2334). Kindle 版. より引用 ↩