見出し画像

小さいけど1ヶ月で成果が出せるようになったチームビルド【エンジニアチーム編】

あれっくす / 株式会社マンハッタンコード

ネタの元となったツイート


社内チーム発足

マンハッタンコードでは2022年2月から会社のノウハウやナレッジなどの技術資産の形成を目的としたエンジニアによるチームが2つ設立されました。
新分野開拓チームと共通基盤チームです。

新分野開拓チームの目的

スマホアプリサービスの開発に特化している弊社は更なる進化を遂げるため、フロントエンド領域の専門会社になることを掲げて現在は活動しています。
会社の方針としてWEBアプリ開発にも力を入れることになりましたので、新分野開拓として技術資産を増やすためにチームを発足しました。
メンバーは現在は弊社社員4名です。
よりスキルの高い社外の方に指南や顧問をお願いすることがあると思いますが、現在は社員オンリーで小さく始めようということでスタートしました。

新分野開拓チームの目的は以下の2つです。

【新分野開拓チームの目的】
1.「わかってない、やれない」を「わかってる、やれる」に変えること
2.「わかってない、やれない」を「わかってる、やれない」に変えること


共通基盤チームの目的

共通基盤チームの役割は社内で利用する、または利用している技術ノウハウやナレッジの整理だったり更新だったりです。
開発プロジェクトに応じてやり方やツールを選ぶのですが、基準となるやり方やツール選定がないと、会社の技術資産にならないと経営側で判断してチームを発足しました。

共通基盤チームの目的は以下の2つです。

【共通基盤チームの目的】
1.「わかってない、やれる」を「わかってる、やれる」に変えること
2.「わかってる、やれない」を「わかってる、やれる」に変えること

チームの活動

弊社は開発会社ですので、日々クライアントワークをしています。
クライアントワークをしながら1日30分ほどは状況や手順整理の時間を取れますが、この時間を研究活動と呼んで行動することにしました。
研究活動をした結果や成果は、お客様への作業、自分たちが開発する成果物にフィードバックされます。

派遣業に比べて業務委託型のお仕事ではこのような好循環サイクルを作り出せるメリットが存在します。特に弊社は技術者個人の成長にフォーカスしているのではなく、マンハッタンコードという企業のノウハウやナレッジにフォーカスしているので、会社間取引でお客様が恩恵を受けられる仕組みが存在しています。
そしてこの取り組みを実施してもらうことで、担当するエンジニア個人の能力も必然的に引き上げることが可能になります。
お客様、自社、担当エンジニアの三方がメリットを享受できる強い仕組みです。

良いことばかり言っているような気がするかもしれませんが、とはいえ1日30分程度なので作業リソースは少ないと思います。
どんな開発プロジェクトでもリソースは無限にあるわけではないので、当たり前と言えば当たり前ですが、これがチームと活動のルールであり、制約でもあります。

研究活動の仕組み

【リーダーとメンバー】
両チームのリーダーはそれぞれ10年ほどキャリアを持つ能力の高いエンジニアにお願いしました。メンバーのキャリアは全員4年未満です。
弊社の社員としては業務を1年以上経験している者が85%以上なので、業務遂行能力にも問題ありません。

【イテレーション / 作業期間】
現在弊社は四半期ごとの目標設定をして全社が活動をしているので、2022年2月〜3月をチームの準備期間とし、2022年4月〜6月を最初の活動期間としました。
毎月1回全社会を開催しているので、そこで活動内容と成果報告をしてもらうことを仕組みとして設定しました。

【コミュニケーション】
Slackで新しくチャネルを設定し、情報の蓄積はコンフルで行いました。
弊社は原則オフラインワークで全員出社しています。
リリース前で作業に集中したい時や本人やご家族がコロナ罹患などの例外時はオンラインワークも許可しています。

【意思決定フロー】

マンハッタンコードという会社は「会社は社員が作る」をモットーにしていますので、やることリストはチームで作ってリーダーが管理してもらうことにしました。
会社の方向性は経営陣が作成し管理してますので、経営陣とリーダーにより協議と決定を行い、四半期ごとにチームに取り組んでもらうというフローを選択しました。


結果が出ないチームで行っていたこと

2022年2〜3月の取り組み

結果から言うと、この2ヶ月間で各チームが次の四半期で取り組むべき内容が決まりませんでした。
意思決定フローとして設定した、「チームが作ったやることリスト」を基に会社の方針との突合は2022年3月の末になっても実現しませんでした。

【話し合いがメイン】
認識のすり合わせなどがメインとなっており、出てくる成果物は議事録が多かった。
当然、話し合いを行ってはいけないというルールはないが、作業時間の大多数がチーム内の話し合いに割かれており、手を動かす時間がほとんど取れないという状況が続いていた。

【会社じゃなくて個人にスコープが当たってる】
目的は「会社の技術資産を作ること」だったが、実態は個人の能力開発に作業時間が割かれていた。検証のため個人の時間を取ること自体は何も問題ないのだが、検証時の効果測定項目などが特に設定されておらず、検証している本人たちが「何が効果的なのか」というのがわからないままに期間が過ぎていた。

2022年4〜6月の取り組み

各チームでやることが決まってませんので、会社からの依頼は変わらず「やることを決めること」からスタートでした。そしてこの3ヶ月間の活動結果は、話し合いは行われるが成果物が会社の資産になることはほぼありませんでした。悲しいけど事実なので受け止めないと前に進みません。

【やることを決めずにやりたいことをやっていた】
行き当たりばったりでやることを決めていたため目的とズレることになり、効果測定ができない状態であった。3ヶ月全体のスケジュールもなく、計画やプラン、実行するためのスケジュール調整、タスクの明確化や情報の共有化など、チームで行動するための仕組みや環境が作れていなかった。

【発生していた問題が解消されないまま作業を続けている】
振り返りをしてもらい、再調整してから作業を行なってもらうように依頼していたが、振り返りが行われていなかった。
「成長は振り返り無くして成らず」だが、振り返りが行われないため問題に対しての対処が行われず、解消されずに長引いていた。
結果報告と合わせて振り返りと改善行動も教えてもらえば良かったと反省。

【リーダーにチームが依存していた】
知識不足や経験不足からなのかチームでの話し合いはメンバーが「リーダーの意向に合わせる」に目的を変えてしまっていた。
チームの目的がどこかに行ってしまい、リーダーだけがチームの目的を追っている状態になっていた。
メンバーはリーダーのタイムスケジュールに合わせるが、リーダーが合わない時は「やらない」という選択が自然と発生し、時間的なリソースはあったけど使用しないという状態に発展していた。

結果、作業チケットはあるもののイテレーションごとの達成率はほぼ0%に近く、良くて30%程度となっていた。理由は「リーダーが忙しそうだから」が大半を占めていた。リーダーがやる時はやるけど、リーダーがやれない時はやらないというチームになっていた。


結果が出せるチームをビルドするためにやったこと

結論から言うとチームビルドのやり直しです。

（１）チームの目的を再認識する

ゴールデンサークル

なぜチームが発足したのかを再認識してもらうことから始めました。
マンハッタンコードでは会社のマニュアルとしてゴールデンサークルを使って、目的を創造しています。
新分野開拓チームも、共通基盤チームもWHYは同じで「会社の技術資産を作ること」です。
ここからそれぞれのチームで出来るHWY・HOWTO・WHATを考えて行動計画やスケジュールを立てていきます。
結果として両チームは以下のゴールデンサークルが出来上がりました。

【新分野開拓チーム】
WHY：会社の技術資産を作ること
HOWTO：React.jsを使ってWEBフロントの開発技術ノウハウを得る
WHAT：React.jsに関する情報整理、JavaScriptやTypeScriptの情報整理、React.jsでサンプルアプリ開発を行いノウハウを可視化する、など

【共通基盤チーム】
WHY：会社の技術資産を作ること
HOWTO：システム開発に必要なドキュメントの体型化を行い、共通認識を得る
WHAT：V字モデルをベースとした開発フローの可視化、開発セクションごとに必要なドキュメントの可視化、各ドキュメントの目的や効果の可視化、各ドキュメントの作成手順の制定、など

（２）チームの目的に向かう行動をチームで判別する

目的の再認識を行った後は、チームメンバー全員で作業チケットを作成してもらいました。ここまでの流れはきっと一般的で、どこでも、誰でもやっていると思います。しかし、ここで前回の反省を活かして工夫を加えました。

【工夫】
・メンバーが作成した作業チケットを「会社の技術資産を作る」ことを基準にして、作業後に技術資産が実現しているかを判別してチームの判断基準を構築

目的から逸れた作業チケットの優先度は下げ、目的に対して効果的な作業チケットの優先度を上げる。
これはチームメンバーが作業チケットの消化を目的にしないように、会話によって言語化、チケットの優先度付けによって判断基準を構築するために行いました。
これにより「作業はしているけど上手くいってるように思えない」ということは発生しづらくなります。反面、続けることで「チームが目的を達成しようとしている」という実感を得ることができるようになります。

加えてこの方式では、メンバーがリーダーではなくチームやチームの目的に依存してくれます。依存というと言葉が適切ではないかもしれませんが、「なぜ我々はここに集まっているのか？」という理由をチケットを作成する工程で確認しながら行うことができる環境を作ることができます。

（３）チームの作業・成果物の品質を合わせる

チームの構成はエンジニア経験10年以上もいれば、経験3年程度、始めたばかりの1年未満など、バックグラウンドは均一ではありませんでした。
品質の基準は自然と経験年数が高い人に依存していくようになります。
今回の両チームの目的はメンバーの経験値を上げることではなく、会社の技術資産を作ることなので、間違えないように作業品質についても再度明確にしました。

品質は原則的に時間をかければ良くなりますが、時間をかけなければ良くならないという法則性を持っています（品質に対しては諸説・諸論ありますが、話が進められないので割愛します）
今回使えるリソースはチームが使用できる作業時間は1日30分程度です。
一定の品質を目指そうとすると時間は消え、生産量が落ちます。
そこでチームでは「掛けた時間通りの品質を受け入れる」というルールを設定しました。

【品質ルール】：掛けた時間通りの品質を受け入れる
・1時間の作業なら1時間でできるもの、1週間の期間なら1週間でできるもの
・品質を向上させたいなら、それ用の作業チケットを切って作業すること
・レビューは必ず実施するが、修正が発生したら修正用作業チケットを作成すること

短い作業時間で作業に集中してもらうためには雑念のようなものを出来る限り排除します。作業の邪魔をするものは全部シャットアウトです。
ドキュメントでもソースコードでもモノを作れば、品質向上の名目で後からブラッシュアップすることは可能です。逆にモノがなければ品質を測定することもできませんし、ブラッシュアップなんて夢のまた夢です。

プロジェクトやプロダクトの完成度が上がってくれば品質向上フェーズは必ず発生します。最初から品質と生産量を追うことができる十分な作業時間がないのであればと、両チームとも生産量に全振りすることにしました。

（４）作業時間とルールを徹底的に守ってもらう

人間は気まぐれな生き物なので「一定の時間、作業をする」ということは難しいことでもあったりします。天候が悪い、体調が優れない、別の作業でトラブルが発生する、気分が乗らないなど我々の一定作業を邪魔してくるものは枚挙に遑がありません。

チームメンバーには「作業をすれば生産できる」ということを徹底的に覚えてもらいました。そのために作業チケットは何を作るのかというアウトプットと、品質なども出来るだけ明確に記述してもらいました。

作業チケット例１
作業チケット例２

もし仮に何かトラブルなどで作業ができない場合は、Slackで「xxにより予定していた作業ができないです！助けて！」などと連絡してもらうルールを徹底しました。

【作業ルール】
・作業、ミーティングの時間は守る
・作業予定はカレンダーに入れて時間が来たら実施する
・実施ができない場合はSlackでチームメンバーに連絡する
・1週間をイテレーション単位とする
・1週間に1度の定例会を実施する

賛否両論ありますがミーティングに出席する際の「誰々はxxの作業で遅れるそうです」的なことは認めないようにしました。小さいことかもしれませんが仕事としてこれを認めてしまえば、お客様へのお仕事も段々となあなあになっていってしまい、最後には大きなトラブルに発展するからです（多分な経験則）

（５）チームの理想、目標を共有する

我々のチームは最終的にはこうなりたい、この作業の目指す先はこうしていきたいなど、理想を伝えるようにしました。
ルールや制限などがある中で、得られるものは目的の達成だけでもありません。叶えたい願望や理想像に近づくという実感も忘れてはいけないと考えています。

例えばミーティングにしても「進捗確認をさっさと終わらせて、行動してみて新しくわかったことを共有する時間も設けたい」などの理想について必ず伝えるようにしました。
作業についても「xxという情報が整理されていたら楽になるよね」などの理想を伝えます。人間はイメージしたことは実現できますが、イメージできないことは実現できない習性があります。

四半期の取り組みなので会社からすると3ヶ月の期間があります。
「技術資産を作る」という目的は設定しましたので、各月ごとの目標も設定します。7月はこうなっていたい、8月にはこうしていたい、9月にはこうなっているだろうと、目標を明文化してチームメンバーがいつでも触れるようにしておきます。
進捗次第ではこの目標を上方・下方修正することも伝えて、チームのステータスが常にわかるようにしました。


チームをリビルドした結果（2022年7月〜8月の取り組み）

1.成果物の生産量

新分野開拓チームは情報をまとめたwikiページを19ページも生成することに成功しました。同じく共通基盤チームは20以上もページを生成しています。
wikiだけでなく、様々なプロジェクトで使用できるようにコーディング規約やLintの設定、実際のサンプルソースコード生成、ドキュメントの雛形や検証結果など様々なモノが生み出されるようになりました。

2.作業チケット消化量と消化率

作業チケットは基本的に0.5〜1時間程度で設定していますが、平均的に1週間に8枚ほどのチケットを消化するようになりました。
始めた当初は1週間で終わらないということもあったのですが、徹底的に1週間で終わらせることを習慣付けしてもらうように伝えました。

今では1週間で予定していた作業チケットの消化率は80%を超え、100％達成することも目にするようになりました。
さらに体調不良などでメンバーに欠員が出た際なども、代替をうまく行い達成率は下がりませんでした。

3.目標の達成と修正

両チームともに各月ごとの目標達成をし、上方修正に次ぐ上方修正をしています。
当初は目標を低めに設定していたというのもありますが、「技術資産を作る」という目的に対して、リーダーだけでなくメンバーも自分で考えてくれるようになり、話し合いが生まれるようになりました。
その結果、もっとこういうことができそうだという仮説が誕生し、その検証のためのチケットが生まれ始めています。

4.振り返り実施と成長

振り返りを行っていた当初は悪いことばかりが目立っていましたが、1ヶ月も経つと良かったことも出てくるようになりました。
今では良かったことを小さな成功体験として、様々な作業に活かせるようになりました。
成長曲線は理想通りにいきませんが、見事に理想と現実のギャップ差を是正しながら前に進んでいることが実感できるようになりました。

また自分たちではできないことを明確にして、他のチームの助力を仰ぐということを早期に行うこともできるようになってきました。
エンジニアなのでデザイナーの力が必要になった時や、マニュアルや手順を作成している弊社オペレーションチームの力を借りるということも出来るようになってきました。

始めた当初は定例会も1時間をオーバーすることもあったのですが、理想を伝えてからは工夫を重ね、30分で振り返りと進捗確認を終わらせ、30分は新しい発見の話ができるようになりました。
理想が現実になってしまいました。

5.想定していなかった影響

自分たちで作成した成果物を元にお客様に見せて、現場に導入できないかなどの交渉なども始めてくれるようになりました。
会社としては次の四半期で挑戦しようと思っていたことなのですが、圧倒的に前倒しして達成してくれるようになりました。
お話を聞いてくれるお客様にも非常に感謝しているのですが、社内の業務を早くも現場の業務に活かしてくれるようになっているのは驚きました。


まとめ

たった1ヶ月程度でここまでの成果が出るようになるとは私自身も驚きましたが、全てはチームメンバーとリーダーの力です。
各チームのメンバーは業務遂行能力が高い人たちではあったので、結果や成果が出せないことに私自身も不思議に思っていました。

私が今回チームのリビルドでやったことに特別なスキルはありませんでした。おそらく誰もが理解できることで、誰もが実行できることです。
結果を出すことでチームに良いリズムやモチベーションが生まれ、結果を出すための試行錯誤や工夫が生まれるようになりました。
成果物を生産し、振り返りを行うことで修正や品質向上も行うようになりました。

ルールを守って行動することで、悪いものは悪い、良いものは良いとメンバー間で言い合える環境も作ることができました。
今までのようにリーダーからメンバーに「違うと思う」と伝える会話だけでなく、リーダーもメンバーから「違うと思います」と伝えられるようになった相互通信の会話が増えています。
個人攻撃や人格否定ではなく、チームが持つ目的、会社の方針、顧客への価値提供のために情報のやり取りを行ってくれているのです。

正直なところここまで劇的な変化があるものだと思っていなかったので、私自身もびっくりしているところです。
今では定例会で新しい発見を教えてもらうことが楽しみで仕方ありません。
この成功体験の積み重ねは、弊社からお客様へ提供するサービスの中でも具現化していけたらと考えています。

この記事が参加している募集

振り返りnote

82,073件

この記事が気に入ったらサポートをしてみませんか？