社内技術セミナーでチームビルドっぽい話をしたのでまとめ
先日、社内の技術セミナーに登壇してきました。セミナーの内容は「自社のソフトウェア開発の現状を知り、未来に向けて何をすればよいのか考える」と言う意識高めなもので、パネリストには最近行ったソフトウェア開発改善の取り組みを紹介せよとのお題が与えられました。技術レイヤーの話は他のパネリストがしてくれそうだったので、僕はチームビルドみたいな人とかチームに向けた取り組みの話をしてきました。当日話した内容と感想をざっくりとこのエントリにまとめておきます。
コンプライアンス的にアレなスライド・画像を除いた発表資料はこちら。
話したこと
話したことは4つ。
- スキルが伝播する仕組み作り
- プロジェクトの問題検知と解決の習慣化
- 主体的に動けるチーム作り
- 俺達駆動改善
始めの3つはここ1~2年で取り組んだ課題のこと。4つめは改善のモチベーションを上げる方法についての話。
スキルが伝播する仕組み作り
プリンシプルオブプログラミング読書会
このエントリで紹介した読書会の話です。 tomota-tar-gz.hatenablog.com
プリンシプルオブプログラミングは良いコードを書くために必要な原理原則を紹介してくれる本です。この本を題材に読書会を開催していますが、そこでは本を読む時間だけではなく、読んだ内容について周辺の知識と関連する経験を会話する時間を設けています。こうすることで知識と経験の伝播を狙っています。
全コードレビュー
チームの設計とコーディングのスキルを高める方法のひとつにコードレビューがあります。コードレビューを習慣化するために、バージョン管理ツールをSubversionからGitに移行、GitLabを導入してMergeRequestによる手軽なコードレビューができるようにしました。
プロジェクトの問題検知と解決の習慣化
このエントリの内容そのままです。 tomota-tar-gz.hatenablog.com
主体的に動けるチームを作る
Mattermost
メンバーが主体的に判断し行動できるためには、プロジェクトの情報がチーム内で適切に共有されている必要があります。情報共有のハードルを下げ、また速度を上げるためにSlackクローンのMattermostを導入しました。
タスクをアサインしない
メンバーが状況をみて柔軟に仕事の進め方を変えられる状態を目指そうとすると、固定化されたタスクアサインは行動を制限してしまうので邪魔になります。そのため、タスクはプールするだけにしアサインはメンバー各自で自身でするようにしてもらっています。この運用は「プロジェクトの状況を俯瞰できる」「状況をみて適切な行動を選択できる」スキルがチームに必要になるため「今やるべきでないことを自分にアサインしてしまう」ようなミスも起こります。このようなミスはデイリーミーティングで互いにフォローするようにしています。
俺達駆動改善
俺達駆動開発は改善のモチベーションを上げるための方法です。やり方は簡単で不満の主語を「俺達」に変えるだけ。こうすることで自己肯定感を失う代わりに強い当事者意識を得ることができます。例えば
- あいつの書くコードはクソ！
- 上司が技術的負債の返済に消極的！
みたいなものはこうなります。
- 俺達の書くコードはクソ…
- 俺達は技術的負債の返済に消極的…
とても辛いですが、同時に「やらなきゃ」「やれるかも」という前向きな気持ちも湧いてきます。半分ふさげた方法ですが効果がある人もいるかと思うので是非試してみてください。
感想
- モチベーションが上がったと伝えてくれた人が何人かいた
- 偉い人がGitLabやらMattermostの全社運用を考えて動き始めてくれた
など収穫があったみたい。よかった。後者はセキュリティにビビらずGitHubとかSlackとかクラウドなサービスを使わせてもらえると昼休みに鯖管業務しなくてすｍ(ry
