この半年間、久しぶりに開発チームのマネージャ的な立場もやることになったので、「ふつうの受託開発チームのつくりかた」以来、工夫したことをまとめておきます。「ふつうの受託開発チームのつくりかた」未見のかたはぜひそちらも見てみてください!
チームに名前を付ける
私の受け持つチームは伝統的に「ラスカル」の名を付けるようにし、チームのアイデンティティを保つようにしています。チームメンバも本当は出来るだけ長く担当してもらいたいのですが、大きなSIerだとそれが難しいこともあります。
通常のプロジェクトチームだと、サブシステム名くらいで呼ばれることでしょう。これは、そのプロジェクトが終わったらチームも終わり、で帰る場所も無くなることを意味しますし、愛着をもって働くことは難しくなります。
メンバが多少入れ替わっても、チームは継続する"モーニング娘。方式"であれば、またいつか戻ってくることもできるし、OBとしての矜持も持てるというものです。
質問力を鍛える
チーム開発のコミュニケーションのほとんどは誰かから誰かへの"質問"です。つまり、ここをトレーニングするのが円滑なコミュニケーションの必要条件で、近道です。
色々持論はあって、これまで指導してきたのですが、それを分かりやすく@seki_uk くんがまとめてくれましたので、そちらをご参照いただければ！
権限委譲レベルを明らかにする
強いチームづくりには、権限委譲が不可欠ですが、そうはいっても「ここだけは、方向性をブラさないようにしたい！」というものもあります。Delegation Boardsを使って、事前にマネージャとチームで意思決定のための権限委譲レベルを決めておくとよいでしょう。
すべての意思決定に介入するマイクロマネジメントマネージャや、何でもアドバイスをもとめる人には、そもそも権限にはレベルがあることを知らないと思われるので、認識させるとこから始めましょう。
チームのチャットに人工無能ボットを入れる
チーム内でいじる側といじられる側に、それぞれポジションが分かれるのは、メンバー間の距離を縮めるのには役に立ちます。ただ、これを放っておくと度を過ぎたいじりが目に付くようになります。
これを防ぐためには、いじりの矛先をボットに向かわせるのがオススメです。
チームを象徴するrascalくんが、雑談チャンネルに常駐し、癒やしを提供します。
しまいにはボットにいじられるようにもなるようです…
期待をすり合わせする
チームでの開発は、楽しいと感じることも多い半面、「思ったとおりの仕事をしてくれない」「言ったもん負けになるので、タスク漏れありそうな気がしても、誰かが言い出すまでは黙っておく」などの軋轢も多いものです。チームメンバ間でのギクシャクした感じは、メンバ間のお互いに期待することがすりあっていないことに起因します。
そこでまず、チームメンバにWill(やりたいこと)とCan(できること/できないこと)を書いてもらうことにしました。
このシートをもとに、チームメンバで話し合い、チーム貢献のスタンスを明らかにしていきます。「ビルドまわりに関することならこの人」とか「コードベースの負債返済に責任をもつのはこの人」とか決めておけば、新たにタスクが発生しても「みんな忙しい状態で誰がやるんだよ…」みたいな空気感にならず、自然と担当が決まっていくようになりますし、Will/Canがハッキリしているので、やらされ感もスキルミスマッチも少なくなります。
このWill-Canは、チーム内からひろげて、部内のメンター制度としても使うようにしてみています。
https://github.com/kawasima/mentr
このとき問題になるのは、Will(何をやりたいか)を言えない人が多いということです。いろんな角度から質問しても「うーん」「難しいですね」「今は与えられた仕事を一生懸命やるだけです」みたいな受け答えになっちゃうケースでは、その人の仕事に対する価値観からアプローチするのがよいかもしれません。
ムービングモチベータは、その一つの手段で、Curiosity, Honor, Acceptance, Mastery, Power, Freedom, Relatedness, Order, Goal, Statusの10個のモチベーションの源泉について、カードを使って優先順位を明らかにしていくというものです。
http://nuworks.jp/ja/2016/10/26/moving-motivators/
何度かムービングモチベータのナビゲータ役をやった@blackawaによると、当人でも自分が何によってモチベーションを得ているかが、実はハッキリしていない状態とのことなので、これやってみる価値はあるかと思います。
すげぇ会を開催する
これは以前のラスカルチームふりかえりからチームメンバだけで自発的に始まった、すばらしい施策です。
ただのチーム内の勉強会なのですが、メンバ持ち回りで、業務内外で学んだことを、ただただ発表し、聞いている人たちは「知らんかった、すげぇ!」「〇〇くん、すげぇ!」などと言うのがキマリです。
発表者の承認欲求を満たすだけでなく、副次的効果もあります。
中途入社がWeb系企業と比べて少ないSIerでは、先輩・後輩の関係が強く残っているところがあります。とかく先輩から後輩へ教えるばかりになりがちなチーム内コミュニケーションに、後輩から先輩へ教えるというルートを作為的に作り出すので、チームメンバの関係性をフラットにする効果があります。
情報共有のためのミーティングをやめメルマガにする
ただ偉い人がしゃべるのを聞くだけの会議は退屈です。部内のそうしたチームごとの情報共有みたいな会議が週次であったのですが、チームメンバの顔に「こんな時間があったらプログラミングしたいぜ」と書いてあったので、その会議を廃止し、メルマガにするようにしました。
10分くらいで読めるので、はるかに時間の節約になります。
それから最後には、お祝いごとやイベントの告知などを付けておけば、読後のチーム間の会話も誘発できるかもしれません。
良いことがあったらくす玉を割る
これは多くの現場でやられていると思うのですが、そうでもないところもあったので導入しました。
リリースしたときや、チームメンバが書いた記事が2,000ブクマを越えたときなど、お祝いごとがあればくす玉を割ります。立派なものは必要ありません。何度でも再利用できるやつが安く売っているので、それを使いましょう。
これは、会議室ではなくオフィスフロアでやるのがよいです。他のプロジェクトの人たちにもいつリリースしたのか知ってもらう効果があるためです。
ただ、昨今のDevOpsのような１日に何度もリリースだと、くす玉が傷んでしまうので、何回分かまとめて割るバッチくす玉方式にしたほうがよいでしょう。
LTフリースタイルバトル
チーム内で受けることのできる刺激は限られたものでマンネリ化したり、自信過剰をひきおこしたりしがちになります。「チームの外の世界に触れよう」といっても皆がみんなそういう行動がとれなかったりします。
ということで発案したのが、組織対抗でLightning Talksしあうことによるチーム外との交流です。これは企画のDJ @syobochimによって、LTフリースタイルバトルという立派なイベントになり大成功を収めました。
LT FREE STYLE BATTLEという取り組みと挑戦者大募集
組織対抗にしたのは、広く募集かけるイベントだとだいたい同じようなメンツしか参加しないし、ローカル過ぎるイベントでは刺激が少なすぎるので、その中間くらいを目指した策となっております。思うようなメンバが参加してくれないとお悩みの方は、ぜひLTフリースタイルバトルやってみてはいかがでしょうか。というか、是非われわれと対戦しましょう！
クリスマスパーティー
年末の社会人のイベントは「忘年会」ですが、時短の人がいることもあるので、日中に何か楽しいイベントができると良いですねー、と考え今年はクリスマスパーティーをやってみることにしました。
厳正なる抽選の結果、
これまた@syobochim 企画になったわけです。
メインイベントは、当然ながらプレゼント交換です。
プレゼントは「知りたいけど、今年はなかなか着手できずにいた技術 (来年こそは！)」」を各人が書いたカードです。これをジングルベル♪にのせて、隣へ渡していき、曲がストップしたところで、そのカードを持っている人が書いた人に、来年代わりに勉強して教える、という取り組みです。
私のところには、このカードが届きました。がんばります。
チームメンバをプロデュースする
チームメンバに役割を与えるのに「適材適所」というのが、どのマネージャの頭にもまっさきに思い浮かびますが、現実にそうなってないケースがあるのは、メンバそれぞれの長所を活かすポジションが、チーム内に必要とされている役割として存在しないためです。
したがって、チームメンバ各位を一番輝かせる役割を、チーム内外に作りだしミッションを与えることも、マネジメントの重要な仕事です。@syobochim を広報エンジニアなるものを新設し、話し合いながらミッションを与えているのもその一環です。
まとめ
と、いろいろチャレンジしてみていますが、もう少し経ってからふりかえると、想定どおり上手くいくこともあれば、そうでないものも出てくるとは思います。それは組織の性質によるものもあるかもしれません。なので、「真似してみたら、こうなったよー」みたいなフィードバックをいただけると大変ありがたいので、みなさまよろしくお願いします。