1. はじめに
本稿は、私が1年以上の期間をかけて、成長し続けるチームに変わることができた施策を紹介します。
本稿は長文なので、忙しい人は太字だけを拾い読みして、興味をもった施策だけを詳しく読んでいただければと思います。
なお、本稿の内容で「Developers Summit 2020 KANSAI」というカンファレンスで発表した結果、ベストスピーカー賞1位をいただきました。発表を視聴してくださった方々に感謝しております。
発表資料と発表動画はコチラ
2. 施策の効果
私の開発チームは当初(1年と数ヶ月前)は、以下の状態でした。
- あまり積極的に今のやり方を変えようと思っていないチーム
- メンバーは、中堅(私)が1名と入社2年目と3年目の3人(後に新人が配属して途中から4名に)
- 全員、技術記事を書いたことがない
- 全員、社外の勉強会などのイベントに参加したことがない
- 全員、開発知識は、業務で教えてもらったことしか知らない
- 2年目と3年目の若手はSOLID原則やデザインパターンを知らない
- 後に配属される新人は、プログラム未経験で入社した新卒
それが現在は、以下の状態になりました。
- 毎月、新しい技術かツールかプラクティスを施行し、成長し続けるチーム
- 全員、技術記事を毎月投稿
- 全員、社外の勉強会での発表経験あり
- 全員が全社員に熱意ある宣言をするほどのモチベーション
- (例)この技術のことなら私に聞けば大丈夫だと周知されるくらい、技術力向上に勤しみます！
- チームの生産性は1年前から倍増
一番大きな効果は、チームと個人が成長し続ける状態になったことだと思います。
どんなチームでも、成長し続けていけば、数年後は良いチームになると思うので、長期を見据えて良いチームを作るために、本稿の施策を活用いただけると幸いです。
3. 新しいものを試行する風土を作る
成長し続けるチームになるために一番重要だと思ったことは 「現状のやり方を変える必要性をあまり感じない」というチームの姿勢を変えることでした。
当時(1年前)の私のチームは、目立った問題は起きておらず、着実に決められたことを決められた通りに開発することはできていたように思います。
だから「問題を解消する」というスタンスでなく、「もっともっと成長する」というスタンスで、以下の施策を実施して、新しいものを試行する風土を作り、変わり続けることが当たり前のチームになることを目指しました。
3.1 ハピネスチームビルディング
まず最初にやったことは、新しい技術・ツール・プラクティスを思いつくものから、どんどんやってみようという方針を決めたことでした。
なぜかというと、その方が「面白そう」だし「楽しそう」だったからです。
チームみんなで議論して、そういう方針でやってみることにしました。
具体的には、上図のように、新しい技術・ツール・プラクティスを積極的に施行して、得た知見を社内や社外にアウトプット(技術記事で情報発信)し、いいねをもらってモチベーションアップするという活動です。
「試行→アウトプット→いいね」の無限ループで成長できて楽しそうということで、この活動を 「ハピネスチームビルディング」 という名前のスローガンにしました。
3.2 提案しやすい視点を提供
私の開発チームは、若手メンバーが多いのですが、若手メンバーは、新しい技術・ツール・プラクティスを提案しようにも、どこから何の視点で情報を探せばいいか分からないという問題があります。
ということで、若手メンバーに提案してもらいやすくするために、ググるためのキーワードになるような具体的な視点をいくつか伝えました(当時の私も、あまり知らなかったので、頑張って調べました)。
以下に例を記します。
- 技術
- 設計(クリーンアーキテクチャ、Enterprise Architect、 CQRS など)
- ツール
- 情報共有するためのツール(Trello、Miro など)
- 設計ツール(astah、Cacoo など)
- Visual Studio / VS Code の拡張機能
- プラクティス
- 振り返りのやり方(YWT、Fun! Done! Learn! など)
- 朝会の進め方
- コミュニケーション系のプラクティス(ザッソウ など)
3.3 とにかく試行して実績作り
思い付きでも、効果見込みが低くても、とにかく皆で新しいものを試行してました。
新しいものを提案すること自体を善として、どんどん試行して実績を作りました。
そして、試行して分かったことを社内外に発信(技術記事などに投稿)しました。
以下は試行した一例です(この他にも50件以上)。
- ペアプログラミング(以降、ペアプロ)
- モブプログラミング(以降、モブプロ)
- 分報
- 毎朝15分のアウトプット勉強会(詳細を後述)
- インセプションデッキの作成
- ドメインビジョン声明文の作成
- DX Criteriaでの評価
- Lean Coffeeによる振り返り
- Friendlyを用いたテスト自動化
- etc.
ちなみに、試行した結果、効果があったものは継続しますが、効果がないものはやめます。
とにかく試してみることが重要という価値観なので、効果がなくてやめることになっても気にせずに、どんどん試行しました。
3.4 施行件数の見える化
試行を促進するために、新しいものを試行した件数を下図のようにグラフで見える化しました。
グラフで件数の増加が見える状態で、「今月もいろいろ試行できたね」という感じに喜び合うことで、達成感を感じやすいと思います。
4. チームのコラボレーションを促進
ここからは、ハピネスチームビルディングで思いついた施策をどんどん試行してみた結果、効果の大きかった施策を紹介します。
まず、チームのコラボレーションを促進する系の施策を紹介します。
4.1 楽しむことが良いことだという認識を共有
アジャイル開発において、コミュニケーションを活発に行うことで、お互いの知見を共有して開発を加速させるという「チームのコラボレーション」は重要だと言われています。
その促進のために、私は「楽しむこと」が効果的だと考えました。楽しくコミュニケーションできれば、チームのコラボレーションも促進されると考えて、皆で楽しくなるためのプラクティスをどんどん試行してみることにしました。
また、楽しさや幸福度が生産性を高めるという事実もチーム全員で共有しました(参考にした記事は以下)。
幸せな社員は創造性3倍、労働生産性1.3倍
組織の生産性を上げる楽しさの作り方
真面目なメンバーは「仕事中に雑談をしちゃいけない」とか「仕事中にへらへら笑ってちゃいけない」とか思ったりするんです(実際、過去の私はそう思っていました)。
だから、楽しんだ方がトータルの生産性が上がるから、むしろ積極的に楽しもうという姿勢を、明確にチームで共有することは意味があると思います。
4.2 ペアプロ/モブプロで楽しむ
私のチームでは、ペアプロ/モブプロのどちらかを1日1回以上やることを推奨しています(オフラインで働いていた時もリモートワークになった後も同じように推奨しています)。理由は以下です。
- 一緒にワイワイ会話しながら物ができていくことは楽しい
- 機能が動作した時の達成感を共感できる
- 楽しい時間は集中して取り組むため、高い充実感が得られる
- お互いの考え方の理解が深まり、心理的安全性も高まる
やり方のポイントとして、事前にいつやるかの計画は立てずに柔軟に実施しています(会議案内などで予定の確保も面倒なので行っていません)。ペアプロ/モブプロに出たり入ったりも柔軟にやっています。
(例)機能開発の一部、ある不具合の修正、ドキュメントの作成などでペアプロ/モブプロ
柔軟に実施する上で、ペアプロ/モブプロが効果的なタスクをチーム全員が理解している必要があります。
具体的には、「対応方針が複数あり、手戻りが発生しやすいタスク」は効果的ですが、「対応方針が決まっており、手戻りが発生しづらいタスク」には不向きです。
ペアプロ/モブプロがどれだけ楽しいかと、その効果については、以下の記事に書いています。
物語風で分かる、早くて楽しいモブプログラミング
ペアプロ・モブプロでメンバーが驚くほど成長した話
4.3 気軽にビデオ通話に誘える関係性の構築
オフラインで同じフロアにいる時はお互いに気軽に話しかけられましたが、リモートワークになったばかりの頃は、気軽に話しかけにくいという問題がありました。
それを解消するために、最初のうちは毎日1回以上ビデオ通話に誰かを誘うことをルールにしました。リモートワーク対応の施策は、これが一番効果的だったと思います。
このルールによって、ビデオ通話に誘う敷居が凄く下がりました。同じフロアで「今ちょっと良いですか？」と話す感覚とほぼ同じ感覚になりました。ペアプロ/モブプロは、この関係性が構築できている上で、やると良いと思います。
以下は例です。tsuzuki_t くんの分報チャンネルで、後輩(新人)の minoura_a さんが、別の人とのペアプロが終わったばかりの先輩(tsuzuki_t)をペアプロに誘っている所です。
その他のリモートワークでのノウハウについては、以下の記事に書いています。
今日から使えるリモートワークでのチームビルディングのノウハウ
4.4 コーチングプログラミング
ティーチング(教える)だけだと、その考え・知識が定着しづらいと言われています。
ということで、相手に質問して自分で答えにたどり着いてもらうという手法を「コーチングプログラミング」と名付けて実施しています。
前提として、各自が分報で、タスクをどういう考え方で進めるか、その思考過程を随時書いてもらいます。
その分報の内容を確認し、進め方が不適な時に、質問を投げかけて、それをヒントに自分で答えにたどり着いてもらいます。
なお、基本的な分報のやり方については、以下の記事に書いています。
分報で各自の作業を可視化したら、メンバー間の協力が加速された話
質問するのは面倒で時間がかかると思うかもしれませんが、約10人の若手育成をした経験から言うと、これをやらないときと比べてやった方が格段に成長速度が速かったです。以下の効果があります。
- 質問されたことをきっかけに、自分で思い出した知識は定着しやすい([テスト効果]と呼ばれています)
- 自ら理解した状況を「自己説得」と呼び、行動の変化に繋がりやすい(書籍「エンジニアリング組織論への招待」P86を参照)
実施する上での注意点としては「答えに辿り着くために必要な知識を、過去に教えていること」です(コーチングは、相手の中にある答えを引き出すというものなので)。
例として、後輩の分報チャンネルで実施した例を以下に挙げます。
ポイントは「ヒントになるような質問」によって「後輩が自分でひらめいたこと」 です。
自分でひらめくことで、上記に書いた効果が得られる上に、達成感があって楽しいです。
だから、この手法は、分報だけでなく、ペアプロやレビューでも活用すると、楽しい上に成長が加速するのでお勧めです。
4.5 ポジティブフィードバック
「日々の行動」に積極的にポジティブフィードバックし合っています。
ポイントは「結果」に対してでなく「行動」を褒めることです。
書籍「エンジニアリング組織論への招待」のP81には、以下のように書いてあります。
自分から考えて動いた結果、それが評価されることで、フィードバックサイクルの中に「自律的に動くことは楽しい」と言った回路が組み込まれます。これを「自己効力感(self-efficacy)」といいます。
ということで、私は毎日10回くらいメンバーの行動を褒めています。
行動を褒めることで、その行動が定着し、やる気も上がるので、生産性が向上します。
逆に、行動を褒めないと、その行動をすることに価値を感じなくなって行われなくなることがありました(数年前に実際にありました)。
いろんな意味で、この施策が一番大事だと思います。
褒める行動の例をいくつか紹介します。
-
早めに報告・相談された時に毎回褒める
- 報告内容がグダグダでも、早めに報告してくれたことは必ず褒める。そうすると、早めに報告・相談する行動が定着して、手戻りが無くなる。
- 以前に指導した通りに実行できたら褒める
- 複雑な問題を分解して考えようとする、結論から話すなど、行動が改善された時は必ず褒める。
- なんとなく判断したのでなく、ロジカルに判断したら褒める
- メソッドの名前をなんとなくでなく根拠を持って決めた、など。判断結果が間違っていても、自分なりに根拠を持ってロジカルに判断したならば褒める。
4.6 その他の楽しむ活動
チームのコラボレーションを促進するための「楽しむための活動」として、いくつか小ネタを紹介します。
小ネタ① 楽しい用語
不具合をドラゴンと呼び、不具合修正者をドラゴンスレイヤーと呼びます。
以下のような楽しい会話を繰り広げます。
「ドラゴン(不具合)が出現したぞー！」
「ちょっとドラゴン倒してくるわ！」
「僕もお供しましょうか？(ペアプロしましょうか？)」
小ネタ② ニックネーム
名前は毎日何度も呼ぶため、呼び方で親近感を高めます。
ポイントは2つあります。
1つ目は、本人が呼ばれたい名前を自分で決めことです。
2つ目は、ニックネームは後輩から呼ばれる時の呼び方も合わせて決めることです。後輩からしたら先輩を「呼び捨て」や「ちゃん付け」するニックネームは呼びづらいので、ちゃんとそこを決めないと呼び方が定着しません。
(例) 先輩からは「まこっちゃん」、後輩からは「まこっさん」
ニックネームで呼び合うメリットは2つあります。
1つ目は、メンバー同士の距離感が縮まることです。
2つ目は、フラットな関係に感じやすいため、リーダー任せでなく、各自が主体性を発揮しやすいことです。
以下の記事を参考にしています。
仲間意識を高める呼び方
小ネタ③ 雑談
昨今、雑談が重要だと様々な所で言われていることもあり、毎日の朝会で、お互いをもっと知るための雑談を入れています。
リモートワークでの雑談は、自分のプライベートをカメラで見せることで、その人をより知ることができます。
(例)お気に入りの楽器を見せることも可能
4.7 コラボレーション促進の施策の効果
以下の効果がありました。
| Before | After(1年後) |
|---|---|
| 自分の考えをあまり主張しない | 心理的安全性が高まり、各自が自分の考えを主張する |
| 相談しないため、手戻りがよく発生する | 適切なタイミングで相談するため大きな手戻りがない |
| 自分のタスクの内容を他の人と共有しない | 情報共有する頻度が多くなり、その中で助言し合うようになる |
5. アウトプットの経験と習慣づけ
書籍や記事などで、成長するためには、学んだことを随時アウトプットし続けていくことが良いと書かれています(アウトプット＝人に説明する、技術記事を書く、など)。
だから、個人が成長するための施策として、アウトプットを継続する方針を考えました。
しかし、当時(1年前)の開発チームは、自分も含めて全員、技術記事を書いたこともなく、自主的にアウトプットを継続できない状態でした。「アウトプットで成長を実感した経験」と「学んだことをアウトプットする習慣」がない状態でした。
ということで、まずは、その経験と習慣づけを得るために、思い付く施策をやってみました。
(ハピネスチームビルディングにより、思いついた施策をどんどん試行)
5.1 毎朝15分のアウトプット勉強会 - 書籍編
学んだことは人に説明(アウトプット)した方が身につくと言われています。
だから、事前に全員が書籍を30ページ程度 読んできた上で、その重要ポイントを各自が自分の言葉で説明するという勉強会を考案して実施しました。
(例)「私はこの部分が重要だと思いました。なぜかというと・・・」
つまり、毎朝15分の勉強会で、学んだことをアウトプットする習慣づけを行うわけです。
とにかくポイントは「自分の考えをアウトプット」して、その考えを定着させる点です。
例えば「報・連・相」の書籍で、「悪い報告ほど早くする」ことが重要だと自分で話したメンバーは、明らかにその点に対する意識と行動が変わりました。
読む書籍は、チームで価値観を共有したいものが良いと思います。
私のチームで特に効果的だった書籍は以下です。
「報・連・相の技術がみるみる上達する!」
「リーダブルコード」
「SCRUM BOOT CAMP THE BOOK」
「ロジカル・シンキング 論理的な思考と構成のスキル」
「エリック・エヴァンスのドメイン駆動設計」
この勉強会で以下の効果がありました。
- 過去の新人にも同じ書籍を読んでもらったことがありましたが、それと比べて、書籍の内容がしっかり身に付き、行動も変わりました。
- 「報・連・相」の書籍を読んで、報告・相談される相手の立場を考えて、必要な詳細度で報告・相談をしようとする姿勢がとても強くなりました。
- 「リーダブルコード」の書籍を読んで、他人が読んで分かりやすいコードを自分が考える最善を尽くして書く姿勢がとても強くなりました。
- 入社1年目のメンバーは 「得た知識を他人に説明することで、その知識がより定着することも身をもって体験できた」 と言っていました。
この勉強会の実施方法の詳細は、以下の記事に書いています。
毎朝15分の勉強会で若手の行動が驚くほど改善した話
上記の記事はQiitaのトレンド1位になったこともあって、この勉強会は他社でも導入されています(以下の記事参照)。
毎日開催の社内勉強会に潜入してきました！ - 株式会社セレス
Qiitaでバズった「毎朝15分の勉強会」を実際にやってみた！
5.2 毎朝15分のアウトプット勉強会 - 設計・実装編
設計・実装の経験が少ないうちは、経験者視点では思ってもみないような「初歩的な問題」を含んだ設計書やソースコードをよく作成してしまいます。
(例)責務が分かれていない設計書、正常系が動作しないプログラム
これは、経験が少ないことによる特有の問題で、経験を積むことで解消されます。
当時(1年前)の私のチームは設計・実装の経験が少ないメンバーが多いため、設計・実装の経験を積むために、事前に設計と実装をしてもらって、15分でそのレビューをするという勉強会を実施しました。
具体的には、事前準備として、GoFのデザインパターンを題材に、学習対象者はクラス図作成とコーディングを事前に行います。作成するプログラムは、対象のデザインパターンを適用した自分なりのサンプルプログラムです。
当日は、発表担当者が、作成したプログラムのクラス図とソースコードを説明します。ここで重要なのは「そのパターンのメリットと用途」を自分なりの言葉で説明することです。他のメンバーは、成果を見て、パターンに適していない所の指摘や自分なりの考えを発言します。
Gofの23パターンすべて実施することで、3000LOC程度の設計・実装の経験値が得られます。
その頃になると、「初歩的な問題」はほとんどなくなります。
勉強会の実施方法の詳細は以下の記事に書いています(上記は概要をかいつまんで説明しただけなので、実際に実施する際は以下の記事の内容を参照ください)。
毎朝15分の勉強会で若手の設計力がメキメキアップした話
5.3 毎月の技術記事投稿
毎月のアウトプットとして、技術記事を書いてみようと思ったのですが、メンバーから不安の声が2つ上がりました。
不安の声①「書こうと思った記事内容はすでに世の中にあるからネタがない」
これに対しては、まず世間の見解を調べました。その上で、内容が重複しても、自分なりの視点で自分の理解を書けば十分に価値があるという考え方を伝えました。
初心者の視点で書いた記事は、同じ初心者に刺さるかもしれません。
詳細は以下の記事に書いています。
技術記事を投稿してみたいけどネタがない人のハードルが下がる話
不安の声②「1件書くだけでも時間がかかりそう」
これに対しては、アウトプットして成長する方が、長期的には生産性が高まると判断して、技術記事を書くなどの学習工数を踏まえて業務の計画を立てるように調整しました。
また、記事を書くことで、その技術の理解が曖昧だったことに気付くことが多く、あやうく間違った実装をしてしまう可能性もあったため、遠回りのようでいて、必要な取り組みということを共有しました。
あとは、投稿できるようになるまで、丁寧にサポートしました。
記事のネタを一緒に考えて、下書きの記事を見せてもらって助言して、記事の質は求めずに、投稿したらポジティブフィードバックという感じで、サポートしました。
(自分も記事投稿の初心者でしたが、頑張ってサポートしました)
その結果、自分も含めて全員が、毎月2件、技術記事を投稿できるようになりました。
5.4 アウトプットの経験と習慣づけの施策の効果
アウトプットする施策を半年くらい続けたことで、「アウトプットで成長を実感する経験」と「アウトプットの習慣づけ」を得ることができました。
6. 内発的動機づけで成長を加速させる
学んだことをアウトプットする習慣が身に付いた後の次のステップとして、さらに成長を加速させる方法を検討しました。
それが、現代の職場で必要と言われている「モチベーション 3.0」です(書籍「モチベーション 3.0」を参照)。
モチベーション 3.0 とは、以下の3つの要素による内発的動機づけで行動することです。
・自律性：自ら方向を決定したい
・熟達：価値があることを上達させたい
・目的：社会に貢献したい
ということで、上記の要素を刺激するような施策を試行しました。
(ハピネスチームビルディングにより、思いついた施策をどんどん試行)
6.1 要求からテストまで全てやる
裁量を与えることで、自律性を発揮しやすくなると思います。
そこで、なるべく色んなことにチャレンジしたり、工夫したりできるようにしました。
具体的には以下の3つです。
- プロダクトにどんな機能を追加するかの要求を検討する場に開発チーム全員が各自のアイデアを持って参加
- →自分のアイデアがプロダクトに反映できるチャンスが得られる
- 仕様書、設計書、プログラムの作成からテスト実施まですべての工程を全員が担当
- →新人でも、自分の考えやアイデアを仕様や設計に提案できるチャンスが得られる
- 各タスクのゴールは事前に決めるが、やり方は任せる
- →自分なりに工夫できる余地が多い
これを実施した結果、それまでは「与えられたタスクをやるという姿勢」だったメンバーが「自分の考えや自分がやりたいことを主張する」ようになりました。
6.2 主体的に学習できる環境を作る
学習は「やらされる」状態では捗りません。
興味がある技術に対して主体的に学習する方が効率的と思います。
そこで、自由な学習を毎日1時間、業務時間内で確保することを勧めました。ポイントは、プロジェクトの進捗が遅れていても、この時間を確保していいことを明確にしたことです(プロジェクトはだいたい遅れることが多いので、そうじゃないと結局時間を確保できない)。
ただし、インプットするだけでは身にならないので、学んだことを随時アウトプットする場を作りました。
具体的には、Slackに学びをアウトプットするチャンネルを作成し、技術記事などで学んだことを随時Slackに投稿してもらうようにしました(下図参照)。
各自の学習内容をチームで共有できる上に、お互いに刺激し合う効果もあるのでお勧めです。
なお、学んだ内容が複雑だったり、ボリュームがある場合は、朝会で「学んだことを皆に話す時間」を作って皆で共有しています(学んだことは人に説明した方が定着しやすい)。
ちなみに、脳科学者の茂木健一郎氏は、書籍「脳を最高に活かせる人の朝時間」にてGoogleの20%ルールにふれた後、「たとえ仕事の時間を削ってでも、心にゆとりの時間を与えることで、仕事のクオリティは格段にアップします」と言っています。なので、この施策は脳科学的にも、わりと有効なんじゃないかと思います。
6.3 個人で企画したアプリ開発を勧める
いつ使うか分からないような技術を調べるのに比べて、「自分が作りたいものを作るために必要な知識を調べる」ことは楽しいと思います。
「作りたいものを作る」という個人開発を、もし趣味にできれば、プライベートでも趣味として楽しみながら成長できると考えました。
また、企画から考えることでアプリ開発者としての視座が高まると思います。
従って、以下の手順でメンバーに個人開発を勧めました。
- 書籍「個人開発をはじめよう！」のいくつかのエピソードの要約を説明したり、一部のエピソードを読んでもらう
- 「Web1Week」という1週間でWebサービスを作るイベントの作品を紹介し、誰でも簡単に作れることを伝える
- 何が作りたいか聞き出して、MVP(Minimum Viable Product)を一緒に考える
- 作りたいアプリの技術選定と公開手順を教える(簡単にできそうと感じてもらう)
- 週に1時間「個人開発タイム」を作って、少しずつでも進める
- つまった所はペアプロで解消
- MVPが出来上がったら皆に見てもらう場を設けて褒める
上記の手順で全員に個人開発アプリを作成してもらいました。
新しい技術を学びながら、自分で企画して作る楽しさを経験してもらいました。
その結果、プライベートでの学習は「頑張るもの」という意識(続けるのはしんどい)だったものが、若手3人中1人はプライベートでも個人開発を続けて楽しんでいる状態になりました。
こちらは、まだ始めたばかりなので、今後、他のメンバーも個人開発が好きになるといいなと思います。
6.4 社外イベントでの発表を勧める
顔が見える人から直接いいねと言ってもらう嬉しさを経験できると、内発的動機づけの「社会に貢献」の楽しさや嬉しさを、体験できるんじゃないかと思いました。
また、社外イベントで、社外のエンジニアから良い刺激をもらえるんじゃないかと思いました。
その考えのもと、社外イベントでの発表を勧めました。
しかし、初めての社外発表は、敷居が高くてなかなか踏み出せないという問題がありました。
そういう人は世の中にも多いと考えたため、その敷居を下げるために、「Serverless LT初心者向け」という発表初心者向けコミュニティを立ち上げました。
このコミュニティでは、参加人数が少なく、発表初心者が集まるLT大会を毎月開催しています。
発表初心者向けの発表資料テンプレートと発表準備のやり方も、以下の記事で公開しています。
LT初心者向けコミュニティを立ち上げたので、LTの準備方法とテンプレートを紹介
コミュニティの詳細は以下を参照ください。
(発表に少しでも興味のある方、ぜひご参加ください、どなたでも大歓迎です）
Serverless LT初心者向け
このコミュニティのLT大会で、私のチームの若手メンバー3人全員が発表してくれました。
その結果、それまでは「社外のエンジニアと自分を比較しようと考えたことがない」という状態だったのが、社外の同世代のエンジニアから刺激を受けてもっと成長したいと感じるようになってくれました。
6.5 内発的動機づけの施策の効果
それぞれの施策の欄に個別に効果を書きましたが、これらの施策を色々実施した結果、メンバーにヒアリングしたところ、日々の仕事や成長に達成感を感じやすくなったとのことです。
この変化は、モチベーション3.0に近づいている兆しと言えます。
7. 仕事の進め方を改善する仕組みを作る
個人の仕事の進め方についても、改善する仕組みを検討しました。
まず前提として、以下のような問題を 「仕事の進め方の問題」 と定義します。
- 1つの不具合の修正に対して、10時間以上かけて実装したが、そもそも修正方針が間違っていたため、最初からやり直し
- レビュー指摘の修正時に、類似の問題が他にないか、横展開調査をしないため、何度も差し戻しが発生
- 設計時に、クラスの分割方針、クラスやメソッドの命名、処理順序などをなんとなく決めてしまい、レビュー時になぜそれが妥当なのか説明できず、手戻りが発生
- タスクを進めているうちに、本来の目的を忘れてしまい、目的を達成できない成果を作ってしまった
これらの問題を改善するためには、問題を見えるようにする必要があると考えました。
私は過去10年間、「仕事の進め方の問題」で大きな手戻りが発生した時に、その原因を記録していました。
その記録を元に、問題を防止するための仕事の進め方を記した文書として「仕事の進め方チェックシート」というものを作成しました。
10年間記録していましたが、チェック項目は7項目に集約しました(項目が多すぎると運用が難しくなるため厳選しました)。下図のような帳票で、○、△、×で自己評価します。
チェックシートの詳細は、以下の記事に書いています(ダウンロードもできます)。
仕事の進め方の良し悪しを見える化したら、各自が自分で行動を改善してくれた話
この「仕事の進め方チェックシート」を利用した施策を以降で紹介します。
7.1 各自の仕事の進め方を見える化
まず、チェックシートの自己評価結果を全員で共有します。定期的に(1～3ヶ月に1回)評価を実施します。
(皆に見られる帳票なので、できていないのに○にする人はなく、みんなちょっと厳しめに自己評価する傾向があります)
そうすると、「自分の問題点を認識」→「自分の行動を改善すると帳票に反映」というサイクルにより、自分で行動を改善する傾向が現れ始めます。
ポイントは、評価結果に対して、リーダーが必ずフィードバックをすることです。
この手の活動は、フィードバックをしないと形骸化します。
(例)「今月はA君とB君が目的意識の評価項目が上がりましたね！」
7.2 日々の業務の中での指導の観点を絞る
まずはチェックシートの7つの項目に絞って日々の指導をします。
それ以外の観点について、あれもこれもと発散して指導しても、それは見える化されていないため、定着せず効果が低いためです。
7.3 準備を経てから視座の高い役割を任せる
チェックシートの項目には、以下があります。
「自分の作業範囲を考えるのみでなく、プロジェクト全体を効率よく進めようと考える」
しかし、この項目は、実際にリーダー的な役割を経験しないと、なかなか改善しづらいと思います。
そこで、以下のように、色々な準備を経てから視座の高い役割を任せてみました。
①考え方を身に着ける（～半年）
プロジェクトの意思決定時(タスクの優先度、不具合の判断要否など)に、その判断ロジックを説明することで、どういう考え方で意思決定するのか、まずは理解してもらいます。
②意思決定を訓練する（半年～1年）
上記の意思決定時の一次判断をメンバーにふってみて、自分で判断する経験を積んでもらいます。
③1つ上の役割を経験する（1年後～）
メンバーに交代で視座の高い役割を任せます。
具体的には、スクラムマスター兼チームリーダーをスプリントごとに交代し、チーム全体の進捗や見通しを考えざるを得ない状況にすることで、視座を高く持ってもらう経験をしてもらいます。
7.4 仕事の進め方を改善する施策の効果
最初はチェックシートの項目は、×(あまりできていない)が多くありましたが、1年後は×が無くなりました。下図は1年間でのチェックシートの点数の推移です。
実際、仕事の進め方の問題はほぼ無くなりました。
ちなみに、問題が無くなった頃が、チェックシート運用の辞め時になります。
8. まとめ
本稿の施策を実施したことによる一番大きな効果は、本稿の最初に書いた通り、チームと個人が成長し続ける状態になったことです。
以下に、それ以外に得た結果を紹介します。
これらのおかげで、さらに高いモチベーションで取り組むことができるようになりました。
8.1 生産性の増加
工数1人月(160時間)当たりでの新規・変更のコード行数で、1年前と生産性を比較しました。
(仕様書の作成～テスト実施まで、すべて開発チームで行うため、工数はそれらすべての工程の合算値)
上図の通り、1年前と比較して生産性は倍増しました。
なお、コード行数では生産性を正しく計測できないと言われているため、別の方法でも計測し、その計測方法でも生産性は2倍に増加しました。詳細は以下の記事に書いています。
ユーザーにとってどれだけ価値を提供できたかで生産性をお手軽に計測した話
8.2 社外からの評価
施策の実施方法と効果を書いた記事をQiitaに随時投稿した結果、そこそこ見ていただけました(25万PV、4500LGTM)。
8.3 社内からの評価
半年くらい前に、活動内容が評価されて、金一封と表彰状をもらいました。
社内の他チームから以下のような嬉しいコメントもいただけました。
「良い風土作りだと思った」
「会社レベルに拡げたいですね」
「世の中に貢献できている」
「伸ばしていきたい風土」
「素晴らしい活動だと思いました」
「発信の風土を作ってくれてありがとうございます」
8.4 自分自身のモチベーションを高めるために
私がここで紹介した施策を、モチベーション高く実施できたのがなぜかというと、私が所属しているコミュニティから多くの知見や刺激をもらって、私自身のモチベーションを高めてもらったからです。
逆説的に言えば、コミュニティに所属していなければ、私は自分の小さなチームの中だけでお山の大将を気取って、あまり成長できなかったと思います。
だから、これらのコミュニティには本当に感謝しています。私を育成してくれたコミュニティを3つ紹介します。
運営者ギルド
Webサービスの運営者が知見を共有するためのコミュニティです。
皆が新しいチャレンジを楽しみながらどんどん行い、そこで得た知見が皆に共有されます。
自分のチャレンジにも皆が背中を押してくれて、やる気が上がる最高のコミュニティです。
Engineering Manager Meetup
エンジニアリングマネージャーの知見を共有するためのコミュニティです。
マネジメントについて困っていることを相談すると皆から助言してもらえます。
エンジニアと人生コミュニティ
発信に対する知見や刺激が多く、発信することの背中を押してくれるコミュニティです。
メンバーの発信や発信による成功を見ることで、発信のモチベーションが上がります。
8.5. 最後に
本稿で紹介している施策は、きっと多くのプロジェクトで活用できる部分があると思います。
チームと個人の継続的な成長のために、活用していただければ幸いです。
ITエンジニア向け情報誌「Software Design」の2022年5月号から「ハピネスチームビルディング」を題材に連載記事を書いています。以下で公開していますので、よろしければ、そちらも参照ください。
Twitterでも開発に役立つ情報を発信しています → @kojimadev