組織と個人が内発的動機により継続的に成長するための施策

/65
Developers Summit 2020 KANSAI / 2020-8-27 / Yusuke Kojima
© DENSO CORPORATION All RightsReserved.
組織と個人が内発的動機により
継続的に成長するための施策
(改訂版)
2020/8/27
Developers Summit 2020 KANSAI
小島優介

/65
自己紹介
2
名前：小島優介
所属：デンソークリエイト
業務：
2005年から15年間ツール開発業務を担当
現在は設計レビュー支援ツール「Lightning Review」の
開発チームのエンジニアリングマネージャーで
毎日メンバーと一緒にプログラミング
Twitter：@kojimadev
https://twitter.com/kojimadev

/65
発表概要
3
プロダクトを開発するために、組織と個人の継続的な成長は
重要ですが、なかなか難しい課題だと思います
本発表では、1年以上の期間をかけて
成長し続けるチームになった方法を紹介します
※本資料は、読んで内容が分かるように、発表時のものに補足説明を加えています

/65
© DENSO CORPORATION All RightsReserved. 4
• 改善方針
• 開発プロセスの改善
• プロダクトの改善
• 育成方法の改善
• まとめ

/65
当初(1年前)のプロジェクト概要
5
自社製品としてリリースしているWindows用のツール(下図)を
継続的に機能追加および改善する業務
既存のソースコードは数十万行(言語はC#)
設計レビュー支援ツール「Lightning Review」

/65
当初(1年前)の開発チーム
6
中堅1名(私)、若手2名、新人1名(予定)
開発チームのメンバーを一新してから半年経過した状態
(つまり全員このプロジェクトでの経験は浅い)
中堅 2年目3年目新人
(新人1名が
後に配属予定)

/65
開発プロダクトの3年後のロードマップ
7
• 様々なツールと連携する機能を作りたい
• Slack
• Teams
• GitHub
• Jira
• Redmine
• Microsoft Outlook
• Markdown Document
• マルチプラットフォームに対応したい
• もっと使いやすくしたい
• etc.

/65
3年後のロードマップの実現性
8
当時(1年前)
一新した開発チームで半年間開発した結果
当時の生産性では
3年後に半分も実現できなさそう
生産性を上げるために、生産性に影響する以下の観点を分析
1. 開発プロセス
2. プロダクト
3. 育成方法

/65
1. 当時の開発プロセス
9
良い点
• 各工程でやるべきことが明記されており、それが守られている
• スクラムで優先度の高い機能から開発してリリースしている
課題
• 開発のやり方が古いまま(新しいことを試さない)
• 分報、ペアプログラミング、モブプログラミング、どれもやったことがない
• 世の中の便利なツールを知らない(Trello、Miroなど)
• 今のやり方を変えようと思っていない
• メンバー間のコミュニケーションが少ない
• 自分の考えをあまり主張しない
• 自分のタスクの内容を他の人と共有しない
※本発表での「開発プロセス」は、開発のやり方全般という広義の意味

/65
2. 当時のプロダクト
10
良い点
• 数十万行のC#のソースコードでリリース後に重大な不具合なし
（ユーザーの品質に対する満足度は高い）
課題
• 10年前のレガシーコードが多数
• 10年前のソースコードが多く、今となっては技術が古い
• エンティティを1つ追加するだけでも、多数の箇所にロジック変更が必要

/65
3. 当時の育成方法
11
良い点
• 新人が戦力になるために必要な学習カリキュラムが
整備されており活用できている
課題
• 2年目以降の成長を加速させる仕組みがない
• 成長するために継続的にアウトプットする仕組みがない
• 業務での経験でしか成長しない
• 個人の仕事の進め方の改善は個人頼み
• 以下のような問題に対する改善が個人頼み
(例)1つの不具合の修正に対して、10時間以上かけて実装したが、
そもそも修正方針が間違っていたため、最初からやり直し

/65
改善方針の検討
12
短期間で生産性を何倍にも向上させることは困難
短期での課題解決でなく、3年後を見据えて
生産性が継続成長するような改善方針を検討
観点課題
開発プロセス • 開発のやり方が古いまま(新しいことを試さない)
• メンバー間のコミュニケーションが少ない
プロダクト • 10年前のレガシーコードが多数
育成方法 • 2年目以降の成長を加速させる仕組みがない
• 個人の仕事の進め方の改善は個人頼み

/65
1. 開発プロセスの改善方針
13
課題：開発のやり方が古いまま(新しいことを試さない)
継続成長するには新しいことをどんどん取り入れていくことが必要
改善方針：新しいものを試行する風土を作る
(もの＝技術・ツール・プラクティス)
課題：メンバー間のコミュニケーションが少ない
継続成長するにはメンバー同士の知見を共有していくことが必要
改善方針：チームのコラボレーションを促進させる
※本発表での「開発プロセス」は、開発のやり方全般という広義の意味

/65
2. プロダクトの改善方針
14
課題：10年前のレガシーコードが多数
生産性の継続成長には、日々の継続的なリファクタリングが必要
しかし、設計の根幹がレガシーコードのため
日々の小さなリファクタリングをしても「焼け石に水」と感じる
(だからリファクタリングしない)
設計の根幹を改善するには、数ヶ月の期間が必要
改善方針：機能開発を中断してリファクタリング

/65
3. 育成方法の改善方針
15
課題：2年目以降の成長を加速させる仕組みがない
継続成長するためには継続的にアウトプットすることが有効と言われているが
それは自分の内なる欲求により動機づけられた方が効果が高い
改善方針：内発的動機づけで成長を加速させる
課題：個人の仕事の進め方の改善は個人頼み
個人の仕事の進め方を継続的に改善するためには、仕組みが必要
改善方針：仕事の進め方を改善する仕組みを作る

/65
継続成長するための改善方針(以降で施策を紹介)
16
観点改善方針施策効果
開発
プロセス
新しいものを試行
する風土を作る
・積極的に試行する価値観を共有
・提案しやすい視点を提供
・とにかく試行して実績作り
・試行件数の見える化
・毎月新しいものを試行して変わり続
けることが当たり前に
チームのコラボレー
ションを促進させる
・ペアプロ/モブプロで楽しむ
・コーチングプログラミング
・ポジティブフィードバック
・心理的安全性が高まり、各自が自
分の考えを話す
プロダクト機能開発を中断
してリファクタリング
・コアドメインのリファクタリング・日々の小さなリファクタリングでプロダ
クトが改善できると感じられる
育成方法内発的動機づけで
成長を加速させる
・毎朝15分のアウトプット勉強会
・毎月の技術記事投稿
・要求からテストまで全てやる
・主体的に学習できる環境を作る
・個人で企画したアプリ開発を勧める
・社外イベントでの発表を勧める
・書籍の内容が身に付き行動が改善
・実装時の初歩的な問題がなくなる
・技術の仕組みを理解しようとする
・自分の考えややりたいことを言う
・技術情報を主体的にキャッチアップ
・社外からの刺激でもっと成長したい
・日々の仕事や成長に達成感
仕事の進め方を
改善する仕組みを
作る
・各自の仕事の進め方を見える化
・日々の指導の観点を絞る
・仕事の進め方の問題は、ほぼ無く
なった

/65
• 改善方針
• まとめ

/65
継続成長するための施策一覧
18
開発
プロセス
作る
なった

/65
新しいものを試行する風土を作る
19
同じ価値観を共有した上で、多くの試行の実績を作って、
活動状況を見える化することを1年以上続ければ、
きっと風土ができると仮定して以下の施策を実施
1
積
極
的
に
試
行
す
る
価
値
観
の
共
有
2
提
案
し
や
す
い
視
点
を
提
供
3
と
に
か
く
試
行
し
て
実
績
作
り
4
試
行
件
数
の
見
え
る
化

/65
1. 積極的に試行する価値観の共有
20
チーム全員でこれからどうなりたいか議論
「世の中の良いプラクティスやツールを全然知らない」
「このままだと世の中から置いてかれそう」
「同じやり方で変わらないのはつまらない」
とにかく新しい技術・ツール・プラクティスを
試行してみたらどうだろう
「それは面白そう」
「自分たちも成長できるし楽しそう」
良い感じのスローガンをつくろう
2. 提案しやすい視点を提供
3. とにかく試行して実績作り
4. 試行件数の見える化

/65
ハピネスチームビルディング
21
「試行→アウトプット→いいね」の無限ループで成長できて楽しそう
この活動をハピネスチームビルディングと名付ける
(この用語は本発表の核となるため、この後に何度も使用)
新しいものの試行が最重要な価値観の共有
世の中の技術
ツール
プラクティス
社内/社外
積極的に試行
得た知見をアウトプット(情報発信)
いいね！でモチベーションアップ

/65
22
若手メンバーは新しい技術・ツール・プラクティスを提案しようにも
どこから何の視点で情報を探せばいいか分からない
提案しやすい具体的な視点を伝える
• 技術
• 設計(クリーンアーキテクチャ、Enterprise Architect、 CQRS など)
• ツール
• 情報共有するためのツール(Trello、Miro など)
• 設計ツール(astah、Cacoo など)
• Visual Studio / VS Code の拡張機能
• プラクティス
• 振り返りのやり方(YWT、Fun! Done! Learn! など)
• 朝会の進め方
• コミュニケーション系のプラクティス(ザッソウなど)

/65
23
思い付きでも、効果見込みが低くても、とにかく皆で提案
提案自体を善として試行
試行して分かったことを社内外に発信
試行した例 (1年で60件以上)
• ペアプログラミング(以降、ペアプロ)
• モブプログラミング(以降、モブプロ)
• 分報
• 毎朝15分のアウトプット勉強会
• インセプションデッキの作成
• ドメインビジョン声明文の作成
• DX Criteriaでの評価
• Lean Coffeeによる振り返り
• Friendlyを用いたテスト自動化
(発信の例)

/65
24
新しいものを試行した件数を見える化
今月も試行できたねと喜び合う
件数の増加が見えると
達成感を感じやすい
0
5
10
15
20
25
30
35
1月 2月 3月 4月 5月 6月 7月
2020年の試行件数の推移(件数)

/65
試行する風土を作る施策の効果(1年後)
25
施策 Before After
積極的に試行する
価値観を共有
現状のやり方を変える
必要性を感じない
ハピネスチームビルディングの
スローガンのもとで
毎月新しいものを試行して
変わり続けることが当たり前に
(毎月数件を試行)
提案しやすい
視点を提供
とにかく試行して
実績作り
試行件数の
見える化
試行した結果、効果があったものは継続し、
効果がないものはやめる
(とにかく試してみることが重要な価値観なので、効果なくてやめることは気にしない)
以降の施策も、ハピネスチームビルディングのスローガンをもとに
皆で提案・試行したもの

/65
26
開発
プロセス
作る
なった

/65
27
開発
プロセス
作る
なった

/65
チームのコラボレーションを促進させる
28
コラボレーション(お互いの知見を出し合い協力して開発加速)
促進のため、コミュニケーションを活発にしたい
コミュニケーションを活発にするには楽しむことが効果的
楽しさや幸福度が生産性を高めるという事実も共有(※1)
コミュニケーションを楽しくするために思いつく施策をどんどん試行
(ハピネスチームビルディングのスローガンによる試行)
1. ペアプロ/モブプロで楽しむ
2. コーチングプログラミング
3. ポジティブフィードバック
4. その他の楽しむ活動
(※1)参考にした記事は以下
「幸せな社員は創造性3倍、労働生産性1.3倍」 https://logmi.jp/business/articles/243410
「組織の生産性を上げる楽しさの作り方」 https://www.itmedia.co.jp/business/series/16164/

/65
29
ペアプロ/モブプロを1日1回以上やることを推奨
• 一緒にワイワイ会話しながら物ができていくことは楽しい(※1)
• 機能が動作した時の達成感を共感できる
• お互いの考え方の理解が深まり、心理的安全性も高まる
やり方のポイント
ペアプロ/モブプロに適したタスクの特性を全員が理解した上で
事前にいつやるかの計画は立てずに柔軟に実施
(例)機能開発の一部、ある不具合の修正、ドキュメントの作成、
ペアプロ/モブプロに出たり入ったりも柔軟に
(※1)ペアプロ/モブプロの楽しさは、以下の記事に書きました
「物語風で分かる、早くて楽しいモブプログラミング」
https://qiita.com/kojimadev/items/e96e89ec80f9b789169c

/65
(補足)気軽にペアプロする関係の構築
30
リモートワークだと気軽に話しかけにくいため、慣れていない頃は
毎日1回はビデオ通話に誰かを誘うルールを実施(※1)
その結果、オフラインで「今ちょっといいですか？」と声をかけるのと
ほぼ同じ感覚で、お互いにビデオ通話に誘える関係を構築
(※1)その他のリモートワークのノウハウは以下の記事に書きました
「今日から使えるリモートワークでのチームビルディングのノウハウ」
https://qiita.com/kojimadev/items/9f54d2d1e67d73ccfecb
直前まで別の人とペアプロ
していた先輩に対して
後輩がペアプロに誘った例
(後輩が先輩の分報に投稿)

/65
31
ティーチング(教える)だけだと、その考え・知識が定着しづらいため
相手に質問して自分で答えにたどり着いてもらう
前提
各自が分報で、タスクをどういう考え方で進めるか、その思考過程を随時書く
その進め方が不適な時に、質問を投げかけて自分で答えにたどり着いてもらう
効果
質問されたことをきっかけに、自分で思い出した知識は定着しやすい(テスト効果)
自ら理解した状況を「自己説得」と呼び、行動の変化に繋がりやすい(※1)
(※1)書籍「エンジニアリング組織論への招待」P86を参照
注意点
答えに辿り着くために必要な知識を、過去に教えていること

/65
(補足)コーチングプログラミングの例
32
分報だけでなく、ペアプロやレビューでも
コーチングプログラミングを活用すると、楽しい上に成長が促進
XmlDataServiceクラスのExportメソッドの不具合修正。
Documentの一部の出力が漏れていたので処理を追加する。
XmlDataServiceクラスって
どういう責務でしたか？
なるほど、わかりました。
XmlDataServiceクラスでなく
Documentクラスに処理を追加しました。
おみごと！
後輩は、質問をヒントに自分でひらめいて
設計の間違いに気付くので
その設計の考え方が定着する(テスト効果)
私が後輩に質問する
後輩は、自分でひらめいて
やりきったので達成感がある
後輩の分報チャンネルで実施した例

/65
33
「日々の行動」に積極的にポジティブフィードバック(※1)
自分が毎日10回くらいメンバーを褒めて、褒め合う風土を作る
褒める行動の例
• 早めに報告・相談された時に毎回褒める
(報告内容がグダグダでも、早めに報告してくれたことは褒める)
• 以前に指導した通りに実行できたら褒める
(複雑な問題を分解して考えようとする、結論から話す、など)
• なんとなく判断したのでなく、ロジカルに判断したら褒める
(メソッドの名前をなんとなくでなく根拠を持って決めた、など)
(※1)自分から考えて動いた結果、それが評価されることで、フィードバックサイクルの中に「自律的に動くことは楽しい」
と言った回路が組み込まれます。これを「自己効力感(self-efficacy)」といいます。
「エンジニアリング組織論への招待」 P81

/65
4. その他の楽しむ活動① 楽しい用語
34
不具合をドラゴンと呼び、
不具合修正者をドラゴンスレイヤーと呼ぶ
(例)
ドラゴン(不具合)が出現！ちょっとドラゴン倒して来るわ！
僕もお供しましょうか？
(ペアプロしましょうか)

/65
4. その他の楽しむ活動② ニックネーム
35
名前は毎日何度も呼ぶため、呼び方で親近感を高める
• 本人が呼ばれたい名前を自分で決める
• ニックネームは後輩から呼ばれる時の呼び方も合わせて決める
(例)先輩からは「まこっちゃん」、後輩からは「まこっさん」
ニックネームで呼び合うメリット(※1)
• メンバー同士の距離感が縮まる
• フラットな関係に感じやすいため、
リーダー任せでなく、各自が主体性を発揮しやすい
(※1) 参考にした記事は以下
「仲間意識を高める呼び方」
https://skg-od.jp/column/1271/

/65
4. その他の楽しむ活動③ 雑談
36
毎日の朝会で、お互いをもっと知るための雑談を入れる
リモートの雑談は、自分のプライベートをカメラで見せられるため
その人をより知ることができる
(例)お気に入りの楽器を見せることも可能

/65
施策 Before After
ペアプロ/モブプロで
楽しむ
・自分の考えをあまり
主張しない
・相談しないため、
手戻りがよく発生する
・自分のタスクの内容を
他の人と共有しない
・心理的安全性が高まり、
各自が考えを主張する
・適切なタイミングで相談
するため大きな手戻りがない
・情報共有する頻度が多くなり、
その中で助言し合うようになる
コーチングプログラミン
グ
ポジティブフィードバック
その他の楽しむ活動
コラボレーションを促進する施策の効果(1年後)
37

/65
38
開発
プロセス
作る
なった

/65
• 改善方針
• まとめ

/65
40
開発
プロセス
作る
なった

/65
当時のソースコード
41
10年前のレガシーコードが多数(言語はC#)
• 10年前のソースコードが多く、今となっては技術が古い
• ドメインモデルのベースクラスでの共通化が乏しく、
エンティティやフィールドの追加時に多数のロジック変更が必要
• 日々の小さなリファクタリングでは設計の根幹は改善できない
生産性向上のために
機能開発を中断してリファクタリング
※本発表では、上記のような保守性に問題あるコードを「レガシーコード」と定義する

/65
リファクタリングの対象範囲の選定
42
すべてのソースコード(数十万行)のリファクタリングは非現実的
今後の開発生産性に大きく寄与する範囲をリファクタリング
あらゆる機能を開発する際のベースとなる
コアドメインを最優先でリファクタリング
（ユーザーインターフェースはリファクタリングしない）

/65
(補足) コアドメインのイメージ
43
UI(Presentation)
Application
Domain
Infrastructure
コアドメイン
プロダクト全体のうち
コアドメイン(約20%)が
リファクタリング対象
＜参考＞
書籍「エリック・エヴァンスのドメイン駆動設計」 P408
現実は厳しいもので、設計のすべての部分が
等しく改良されるわけではない。
優先順位を設定しなければならないのだ。
ドメインモデルを資産化するには、
モデルのきわめて重要なコアを洗練し、
アプリケーションの機能を作り出す上で、
最大限に活用しなければならない。

/65
リファクタリングのゴールを設定
44
開発者はリファクタリングを始めると、すべて直したくなってしまう
（時間がどれだけあっても足りなくなる）
生産性向上に寄与する内容をゴールとして
その範囲だけをリファクタリング
[設定したゴール]
エンティティ追加時に、ロジックを1行もかかずに以下の機能を実現
(ベースクラスを継承したクラスを作成してプロパティ定義するだけ)
• エンティティの複製
• エンティティのファイル出力、ファイル読み込み
• リストまたはツリーの場合は、要素の追加、移動、削除、検索
• エンティティの追加、変更、削除に対するUndo/Redo
• 複数ユーザーが同時編集した際のデータのマージ

/65
さらにコアドメインをnull安全に改修
45
当時の開発言語C#7.3はnull安全に対応していない
null安全でないでないソースコードは保守性が低い
当時、正式リリース前のプレビュー版だったC#8.0を導入し
その新機能を用いてコアドメインをnull安全に改修(※1)
(ハピネスチームビルディングのスローガンにより、新しい技術を試行)
nullポイントアクセスの苦しみが減り
品質と生産性向上
(※1) C# の null安全の機能の詳細は以下の記事に書きました
「C# 8.0 の目玉機能「null許容参照型」で既存プログラムを安全にnull安全にする」
https://qiita.com/kojimadev/items/d2ee29e85c4c0859275a

/65
コアドメインのリファクタリング効果
46
半年間でコアドメインのリファクタリング完了
機能追加時のドメインの変更行数の一例
従来：500行
改善後：100行 (従来の5分の1)
日々の小さなリファクタリングに対する意識が変わる
施策 Before After
コアドメインの
リファクタリング
設計の根幹がレガシーコードのため
日々の小さなリファクタリングをしても
「焼け石に水」と感じる
(だからリファクタリングしない)
設計の根幹が綺麗になったため
日々の小さなリファクタリングで
プロダクトが改善できる
と感じられる
(だからリファクタリングする)

/65
47
開発
プロセス
作る
なった

/65
• 改善方針
• まとめ

/65
49
開発
プロセス
作る
なった

/65
まずアウトプットの経験と習慣づけ
50
理想の状態
学んだことをアウトプットし続けて成長していく
(アウトプット＝人に説明する、技術記事を書く、など)
当初(1年前)の開発チームの状態
自分も含めて全員、技術記事を書いたこともなく
自主的にアウトプットを継続できない
できない理由はおそらく以下(仮説)
• アウトプットで成長を実感した経験がないから
• 学んだことをアウトプットする習慣がないから
まずは、経験と習慣づけに取り組む(半年程度)

/65
経験と習慣づけのための施策一覧
51
アウトプットする頻度(毎日/毎月)で分類
(ハピネスチームビルディングのスローガンにより、思いついたものから、どんどん試行)
• 毎日
• 毎朝15分のアウトプット勉強会 – 書籍編
• 毎朝15分のアウトプット勉強会 – 設計・実装編
• 毎月
• 毎月の技術記事投稿

/65
毎朝15分のアウトプット勉強会 – 書籍編
52
学んだことは人に説明(アウトプット)した方が身につくため
事前に全員が書籍を30ページ程度読んできた上で
その重要ポイントを各自が自分の言葉で説明(※1)
(毎朝、学んだことをアウトプットする習慣づけ)
(※1)勉強会の実施方法は以下の記事に書きました
「毎朝15分の勉強会で若手の行動が驚くほど改善した話」
https://qiita.com/kojimadev/items/cd5dd5332e33b3ef46a6
オフラインで実施時の様子
(現在はZoomで実施)
私はこの部分が
重要だと思いました
なぜかというと・・・

/65
(補足)書籍の選定方法と他社の事例
53
読む書籍は、チームで価値観を共有したいものが良い
私のチームで効果的だった書籍は以下
• 「報・連・相の技術がみるみる上達する!」
• 「リーダブルコード」
• 「SCRUM BOOT CAMP THE BOOK」
• 「ロジカル・シンキング論理的な思考と構成のスキル」
• 「エリック・エヴァンスのドメイン駆動設計」
勉強会のやり方をQiitaに投稿した結果、他社でも導入される
他社での導入事例は以下の記事参照
https://www.wantedly.com/companies/ceres-inc/post_articles/179815
https://qiita.com/k_yoshikawa/items/66dfc5de2c0e3346e382

/65
設計・実装の経験が少ないうちは
初歩的な問題を含んだ設計書やソースコードをよく作成する
(例)責務が分かれていない設計、正常系が動作しない実装
設計・実装の経験を効率的に積むために
事前に、デザインパターンを用いた自分なりのサンプルプログラムの
クラス図とコードを書いてきてもらい、15分でレビューする(※1)
Gofの23パターンすべて実施で完了
3000行程度の設計・実装の経験値が得られる
毎朝15分のアウトプット勉強会 - 設計・実装編
54
(※1)勉強会の実施方法は以下の記事に書きました
「毎朝15分の勉強会で若手の設計力がメキメキアップした話」
https://qiita.com/kojimadev/items/99d2aa1c9bc67a835480

/65
経験と習慣づけのための施策一覧
55
アウトプットする頻度(毎日/毎月)で分類
• 毎日
• 毎朝15分のアウトプット勉強会 – 書籍編
• 毎朝15分のアウトプット勉強会 – 設計・実装編
• 毎月
• 毎月の技術記事投稿

/65
技術記事に対してメンバーから上がった不安の声
56
「書こうと思った記事内容はすでに世の中にあるからネタがない」
世間の見解を調べた上で、内容が重複しても、
自分なりの視点で自分の理解を書けば十分に価値があるという考え方を伝える
初心者の視点で書いた記事は、同じ初心者に刺さる場合もある(※1)
(※1)詳細は以下の記事に書きました。
「技術記事を投稿してみたいけどネタがない人のハードルが下がる話」
https://note.com/kojimadev/n/n9e5c9ea0ca65
「1件書くだけでも時間がかかりそう」
アウトプットして成長する方が、長期的には生産性が高まると判断し
技術記事を書くなどの学習工数を踏まえて業務の計画を立てるように調整
また、記事を書くことで、その技術の理解が曖昧だったことに気付くことが多く
遠回りのようでいて、必要な取り組みということを共有

/65
投稿できるようになるまでサポート
57
• 記事のネタを一緒に考える
• 下書きの記事を見せてもらって助言
• 記事の質は求めない
• 投稿したらポジティブフィードバック
(自分も記事投稿の初心者だったが、頑張ってサポート)
自分も含めて全員が
毎月2件、技術記事を投稿できるようになる

/65
経験と習慣づけのための施策の効果(半年経過後)
58
施策 Before After
毎朝15分の
アウトプット
勉強会
- 書籍編
自発的に行動が改善されることは
少ない
書籍に書いてある内容が
しっかり身につき、行動が改善
(まず結論、その後に根拠を話すなど)
毎朝15分の
アウトプット
勉強会
- 設計・実装編
初歩的な問題多数
(責務が分かれていない、
正常系が動作しない)
初歩的な問題が
ほぼなくなる
毎月の
技術記事投稿
実装方法を調べる際に
仕組みを理解していない
(コピペで実装することがある)
記事投稿で、どういう仕組みなのか
考える習慣が付いたため、
新しい技術を学ぶ時に
仕組みを理解しようとする
• アウトプットで成長を実感する経験
• アウトプットの習慣づけ
上記を達成し、次のステップへ

/65
内発的動機づけの施策(チームの若手3人が対象)
59
現代の職場ではモチベーション 3.0 が必要と言われている(※1)
以下の要素による内発的動機づけが重要
• 自律性：自ら方向を決定したい
• 熟達：価値があることを上達させたい
• 目的：社会に貢献したい
モチベーション 3.0 を促進する施策を実施 (右に関連要素を記載)
① 要求からテストまで全てやる
② 主体的に学習できる環境を作る
③ 個人で企画したアプリ開発を勧める
④ 社外イベントでの発表を勧める
(※1)詳細は書籍「モチベーション 3.0」を参照
自律性
自律性
自律性
熟達
熟達目的
目的自律性

/65
①要求からテストまで全てやる
60
裁量を与えることで、自律性を発揮しやすくする
• プロダクトにどんな機能を追加するかの要求を検討する場に
開発チーム全員が各自のアイデアを持って参加
(自分のアイデアがプロダクトに反映できる)
• 仕様書、設計書、プログラムの作成からテスト実施まで
すべての工程を全員が担当
(新人でも、仕様や設計に提案できる)
• 各タスクのゴールは事前に決めるが、やり方は任せる
(自分なりに工夫できる余地が多い)
②主体的に学習できる環境を作る
③個人で企画したアプリ開発を勧める
④社外イベントでの発表を勧める

/65
61
学習は「やらされる」状態では捗らない
興味がある技術に対して主体的に学習する方が効率的
• 自由な学習を毎日1H確保を勧める
(プロジェクトの進捗にかかわらず業務時間内で確保)
• 学んだことを随時アウトプットする場を作る
• Slackに学びをアウトプットするチャンネルを作成(次スライド参照)
• 朝会で学んだことを皆に話す時間を作る
<参考>
脳科学者の茂木健一郎氏は、書籍「脳を最高に活かせる人の朝時間」にて
Googleの20%ルールにふれた後、以下のように述べている。
「たとえ仕事の時間を削ってでも、心にゆとりの時間を与えることで、仕事のクオリティは格段にアップします」

/65
(補足)学んだことを書くチャンネル
62
技術記事などで学んだことを随時Slackに投稿
各自の学習内容をチームで共有でき、お互いに刺激し合う効果あり

/65
63
「作りたいものを作るために必要な知識を調べる」ことは楽しい
個人開発を趣味にできるとプライベートで楽しみながら成長できる
企画から考えることでアプリ開発者としての視座が高まる
1. 書籍「個人開発をはじめよう！」(こちらを参照)のいくつかのエピソードの
要約を説明したり、一部のエピソードを読んでもらう
2. 「Web1Week」(こちらを参照)という1週間でWebサービスを作るイベントの
作品を紹介し、誰でも簡単に作れることを伝える
3. 何が作りたいか聞き出して、MVP(Minimum Viable Product)を一緒に考える
4. 作りたいアプリの技術選定と公開手順を教える(簡単にできそうと感じてもらう)
5. 週に1時間「個人開発タイム」を作って、少しずつでも進める
6. つまった所はペアプロで解消
7. MVPが出来上がったら皆に見てもらう場を設けて褒める
新しい技術を学びながら、自分で企画して作る楽しさを経験

/65
64
顔が見える人から直接いいねと言ってもらう嬉しさを経験できる
社外のエンジニアから良い刺激をもらえる
初めての社外発表は、敷居が高くて踏み出せない人が多いため
敷居を下げるために、発表初心者向けコミュニティを立ち上げる
参加人数が少なく、発表初心者が集まるLT大会を毎月開催
発表初心者向けの発表資料テンプレートと
発表準備のやり方も公開(こちらの記事参照)
コミュニティの詳細は以下のURL参照 (どなたでも、ご参加、大歓迎)
https://serverlesslt.connpass.com/

/65
内発的動機づけの施策の効果(若手3人が対象)
65
施策 Before After
要求からテストまで
全てやる
与えられたタスクをやる
という姿勢
自分の考えや自分がやりたいこと
を主張する
主体的に学習
できる環境を作る
業務で必要でない限り、
新しい技術を調べない
興味のある技術情報を主体的に
キャッチアップする
個人で企画した
アプリ開発を勧める
プライベートでの学習は
「頑張るもの」という意識
(続けるのはしんどい)
全員が個人開発アプリを作成した結果、
若手3人中1人はプライベートでも
個人開発を続けて楽しんでいる
社外イベントでの
発表を勧める
社外のエンジニアと自分を
比較しようと考えたことがない
全員が社外イベントで発表し、
社外の同世代のエンジニアから刺激を
受けてもっと成長したいと感じた
これらの施策の結果、
日々の仕事や成長に達成感を感じやすくなった
(この変化は、モチベーション3.0に近づいている兆し)

/65
66
開発
プロセス
作る
なった

/65
67
開発
プロセス
作る
なった

/65
仕事の進め方のよくある問題
68
• 1つの不具合の修正に対して、10時間以上かけて実装したが、
そもそも修正方針が間違っていたため、最初からやり直し
• レビュー指摘の修正時に、類似の問題が他にないか
横展開調査をしないため、何度も差し戻しが発生
• 設計時に、クラスの分割方針、クラスやメソッドの命名、
処理順序などをなんとなく決めてしまい、
レビュー時になぜそれが妥当なのか説明できず、手戻りが発生
• タスクを進めているうちに、本来の目的を忘れてしまい、
目的を達成できない成果を作ってしまった
• etc.
これらを仕事の進め方の問題と定義する

/65
問題を改善するために問題を見えるようにする
69
過去10年間、仕事の進め方の問題で
大きな手戻りが発生した原因を記録してきた
その記録を元に、
問題を防止するための仕事の進め方を記した文書を作成
「仕事の進め方チェックシート」

/65
仕事の進め方チェックシート(7項目)
70
チェックシートは以下の記事で公開中
「仕事の進め方の良し悪しを見える化したら、各自が自分で行動を改善してくれた話」
https://qiita.com/kojimadev/items/912f12c55542b795b60f
左の列は、
問題を防止するための観点
右の列は、
過去に起きた具体的な問題

/65
仕事の進め方を改善する施策
71
各自の仕事の進め方を見える化
• チェックシートの自己評価結果を全員で共有する
定期的に(1～3ヶ月に1回)評価を実施
• 「自分の問題点を認識」→「行動を改善してチェックシートに反映」
このサイクルで、各自が行動を改善する傾向が現れる
• 評価結果に対してリーダーが必ずフィードバックする
(この手の活動は、フィードバックをしないと形骸化する)
日々の業務の中での指導の観点を絞る
• まずは仕事の進め方チェックシートの観点だけに絞って日々の指導をする
• それ以外の観点について、あれもこれもと発散して指導しても
それは見える化されていないため、定着せず効果が低い

/65
仕事の進め方を改善する施策の効果(1年後)
72
チェック項目に対して、最初は×(あまりできていない)が多かったが
1年後は×が無くなった
実際、仕事の進め方の問題はほぼ無くなった
(問題が無くなった頃が、チェックシート運用の辞め時)
0
20
40
60
80
100
1Q 2Q 3Q 4Q
メンバーA
メンバーB
仕事の進め方チェックシートの点数(100点満点)の推移

/65
(補足) 視座を高く持ってもらうための工夫点
73
「自分の作業範囲を考えるのみでなく、プロジェクト全体を効率よく進めようと考える」
上記チェック項目は、リーダー的な役割を経験しないと改善しづらい
準備を経てから視座の高い役割を任せる
1. 考え方を身に着ける（～半年）
プロジェクトの意思決定時(タスクの優先度、不具合の判断要否など)に、
その判断ロジックを説明することで、どういう考え方で意思決定するのか
理解してもらう
2. 意思決定を訓練する（半年～1年）
上記の意思決定時の一次判断をメンバーにしてもらうことで
判断経験を積んでもらう
3. 1つ上の役割を経験する（1年後～）
メンバーに交代で視座の高い役割を任せる
具体的には、スクラムマスター兼チームリーダーをスプリントごとに交代し、
チーム全体の進捗や見通しを考えざるを得ない状況にすることで、
視座を高く持ってもらう経験をしてもらう

/65
74
開発
プロセス
作る
なった

/65
• 改善方針
• まとめ

/65
76
開発
プロセス
作る
なった

/65
1年前との生産性の比較
77
工数1人月(160時間)当たりでの新規・変更のコード行数で評価
（仕様書の作成～テスト実施まで、すべて開発チームで行うため
工数はそれらすべての工程の合算値）
1年前現在
人月当たりの開発生産性(LOC/人月)
昨年の2.04倍に増加
(具体的な値が公開できず、すみません)
3年間でどこまで
生産性が上がるか楽しみ
コード行数では生産性を正しく計測できないと言われているため
別の方法でも計測し、その計測方法でも生産性は2倍に増加。詳細は以下の記事参照。
「ユーザーにとってどれだけ価値を提供できたかで生産性をお手軽に計測した話」
https://qiita.com/kojimadev/items/f116e6647c4e9d5fdf42

/65
施策に対する社内外の評価
78
社外の評価
施策の実施方法と効果を書いた記事をQiitaに随時投稿
25万PV、4500LGTM、月間ユーザーランキング1位
社内の評価
活動内容が評価されて、金一封と表彰状をもらう(半年前)
他チームからのコメント
「良い風土作りだと思った」
「会社レベルに拡げたいですね」
「世の中に貢献できている」
「伸ばしていきたい風土」
「素晴らしい活動だと思いました」
「発信の風土を作ってくれて
ありがとうございます」

/65
自分を育成してくれたコミュニティ
79
運営者ギルド
https://qiita.com/organizations/admin-guild
Webサービスの運営者が知見を共有するためのコミュニティ
皆が新しいチャレンジを楽しみながらどんどん行い、そこで得た知見が皆に共有される
自分のチャレンジにも皆が背中を押してくれて、やる気が上がる最高のコミュニティ
Engineering Manager Meetup
https://engineering-manager-meetup.connpass.com/
エンジニアリングマネージャーの知見を共有するためのコミュニティ
マネジメントについて困っていることを相談すると皆から助言してもらえる
エンジニアと人生コミュニティ
https://community.camp-fire.jp/projects/view/280040
発信に対する知見や刺激が多く、発信することの背中を押してくれるコミュニティ
メンバーの発信や発信による成功を見ることで、発信のモチベーションが上がる

/65
当初(1年前)の開発チームの状態
80
全員、技術記事を書いたこと無し、社外イベント参加経験なし
開発知識は、業務で教えてもらったことしか知らない
中堅 2年目3年目新人
デザインパターン
すら知らない
SOLID原則
すら知らない
技術記事などの
情報発信経験ゼロ
プログラム未経験の
新人が配属予定

/65
そんなチームでも継続成長するチームになった
81
全員、技術記事を毎月投稿、社外イベントで発表
全社員に熱意ある宣言をするほどのモチベーション
中堅 3年目4年目 2年目
全社員に宣言
この技術のことなら
私に聞けば大丈夫だと
周知されるくらい、技術力
向上に勤しみます！
全社員に宣言
皆さんから一目置かれる
チームとなれるよう
今後も技術情報発信に
取り組みます！

/65
最後に
82
本発表で紹介している施策は
きっと多くのプロジェクトで活用できる部分がある
と思います
チームと個人の継続的な成長のために
活用していただければ幸いです
本発表の施策を実施して以下の製品を開発中
「設計レビュー支援ツール Lightning Review」
https://www.lightning-review.com/

組織と個人が内発的動機により継続的に成長するための施策

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 組織と個人が内発的動機により継続的に成長するための施策

Similaire à 組織と個人が内発的動機により継続的に成長するための施策 (20)

組織と個人が内発的動機により継続的に成長するための施策