はじめる前に
よくあるやつですが書いておきます。
以下の話はあくまで僕個人の見解であり、所属する組織の見解ではありません。
はじめに
GitLabに代表されるように、世界を見渡せばオフィスを構えずフルリモートが前提の組織は多くあります。
日本においても、コロナをきっかけとしてフルリモートの分化が半ば強制的に根付いてきました。
かくいう僕自身も、フルリモート生活が続いています。
フルリモートでは、「閉塞感」「孤独感」といったネガティブなワードも飛び交いますし、実際僕自身もそんな感情を感じたこともありました。
閉塞感は、生産性の低下に直結します。そもそもやる気が起こらなくなりますから。
だけど、実際には完全な個人プレーで日々の開発を進めている人なんてほとんどいなくて、大小関わらず複数人のチームで開発は進みます。
チームの強さは、所属するメンバー個人の生産性・開発効率に影響しますし、これはGoogleが提唱する心理的安全性においても言えることです。
心理的安全性の高いチームのメンバーは、Google からの離職率が低く、他のチームメンバーが発案した多様なアイデアをうまく利用することができ、収益性が高く、「効果的に働く」とマネージャーから評価される機会が 2 倍多い (Google re:Work, 「心理的安全性を高める」より)
僕は、インフラエンジニアですが社内にはインフラエンジニアは僕しかいません(社内ではCCoEのポジションです)。
そんな事情もあり、普段の業務はベンダさんと一緒に切磋琢磨しながら行っています。
会社を超えた組織ですが、僕らは自分たちのことを「チーム」と当たり前のように呼んでいますし、生産性や開発効率についても定期的に測定・改善を行っています。
地道な努力ですが、確実に強いチームになったと自負していることもあり、何をやったのかご紹介します。
やったこと
強いチームにするためには、チームの心理的安全性の確保が大事です。
これを一つのテーマに以下のようなことを、現在進行系で続けています。
- 全員で共通認識を持つ（ルールづくり）
- 可視化
- ふりかえり
全員で共通認識を持つ（ルールづくり）
Google re:Workでも、冒頭にビジョンを共有することについて説かれています。
全員が共通認識を持つことを第一に考え、こんなビジョンを掲げました。
「このチームが解散できる状態にする」
インフラエンジニアが不在でも、組織のクラウド利用に関するガバナンスが整っており、開発チームが自走できる状態が理想です。
会社内でも自分の目標は「この会社を退職すること」と宣言しています。
ただまぁ、実際には色んなタイミングで色んな仕事があって、リソースは不足するものですので実現はほぼ不可能なのですが笑
このビジョンとは別に、チームの運営に関してこんなルールを取り決めました。
これらは上から順に重要度が高いものというのが共通認識です。
- 我々は「チーム」である。業務とビジネス上の関係とは別物なので発注者/受注者の関係ではなく全員がいちエンジニアとしてフラットな関係であること
- お互いを「さん」付けで呼ぶ。「様」や「お世話になっております」などのビジネスライクな言葉は禁止
- 失敗をネガティブ要素と捉えない。改善アイテムであり、学びにつなげること
我々は「チーム」である
日本人は奥ゆかしいので、建前や肩書を気にしがちです。
どうしても、他者から自分の見られ方を意識してしまうので、枕詞に「初歩的な質問で申し訳ないのですが…」「見当違いであれば申し訳ないのですが…」のようにワンクッション置いてしまいがち。
ただ、これは上司/部下、先輩/後輩のように立場が違うことを前提に話をしているから生まれるように思うので、フラットな関係であることを第一のルールとしました。
そうは言っても、意識してしまうのは仕方ないので言葉にしておくことがとっても重要です。
言語化されていると、「フラットに考えないといけない」という義務感が出てきます。これも日本人ならではの行動かもしれませんね。
第一のルールにしているのはもう一つ大きな理由があって、それは「そうは言っても会社の垣根を超えている」からです。
この時点で無意識の壁はかなり高いので、壁を取っ払うためにも第一のルールとしています。
ビジネスライクな言葉は禁止
２つ目の「ビジネスライクな言葉は禁止」も、このフラットな関係性を目指すためのルールです。
こういう細かなところから無意識の壁が出来上がりますからね。
失敗をネガティブ要素と捉えない
これは、心理的安全性を担保する要素に情報がオープンであることが重要だからです。
当たり前ですが、失敗はその人に原因があるのではなく、仕組みに原因があるのだという意識が大事です。
もちろん、その前提にはチームメンバーは責任感を持って真面目に仕事をしており、その努力は疑わないことがありますが。
Bad news firstなんてよく言われますが、ここで失敗を責めずにあくまで次に活かすためにどうするか？を考える意識を付けるためにも言語化しました。
可視化
成果やチームの成長を全員が感じるためには、色々なものを可視化することが必要です。
この観点で、色々なものを可視化してきました。
- 各種ドキュメント、ノウハウ
- 週次のタスク進行状況
- プロジェクト全体の今の進行状況
各種ドキュメント、ノウハウ
僕らは手軽にドキュメントやノウハウを蓄積する場所として Docbase を活用しています。
ここには、各種リリース手順書はもちろん、日々の業務の中で見つけたちょっとした小ネタやトラブルシュートについて、その思考過程を含めてすべて言語化しています。
はじめは、「人が見るものなので体裁を整えないといけない」、とか「こんなレベルの話は書いても意味がない」のようなことが頭に浮かび、なかなかドキュメント数は増えてきませんでした。
ただ、これの良いところは何も誰かの役に立つ情報を残すためにドキュメントがあるわけではないという点です。
個人的には、このQiitaで投稿する行動にしてもそうですが、「自分の思考を整理する」ことが一番のメリットだと思っています。
つまりは、自分のためにドキュメントを書いているにすぎない。
たまたま、それを自分以外の誰かが見て、ありがたいことに、役に立ててくれたというだけなんだと思います。
書いているうちにだんだんとそのことをみんなが実感していき、息をするようにドキュメントを書けるようになっていきました。
正直、これは年単位の時間がかかることですが、どこかのタイミングで皆気付くはずです。
週次のタスク進行状況
全員がリモートですし、プロジェクト管理はBacklogで行っているものの、ガントチャートやチケットの締切を見ても正直どれくらい進んでいるのか分かりません。
カレンダーに、今週どのタスクに手を付けたか、また終わったかを記録するようにしました。
（タスク全部黒塗りしていますが、Backlogの課題キー+タイトルをそれぞれ書いてます）
これは、Miroのカンバンボードを使っています。本来の使い方とは違いますが、各レーンを週に見立てて記録しています。
これの良いところは、たとえ「進行中」のステータスであっても、その週に手を付けているタスクがいくつあるのか？が見えることです。
週ごとにばらつきがあれば、営業日数が少なかったのか、タスク自体の粒度が大きかったり難易度が高いのか、誰かが困っているのか？などが見えます。
何より、ここに現れるタスクの数が多いと、「進んでいる感」があってモチベーションの向上に繋がります。これが一番大事なのかもしれません。
もちろん、進んでいる感に溺れて、本当は何も成果が出ていないのにやった気でいるような状態には注意する必要がありますが。
個人の責任感も試されますね。
プロジェクト全体の今の進行状況
上記の最後で書きましたが、スイムレーンを週次に見立てたタスク進行状況の見える化は、進んでいる感が出るので本当は成果が出ていないのだけれど……という半ば詐欺のような状況も生まれやすくなります。
そこで、実際にタスクが予定通りに終わっているのかどうか？も確認することにしました。
これはBacklogのバーンダウンチャート機能を使っています。
開発であれば、マイルストーンはイベントごとになるのだと思いますが、僕らの場合はそういうわけではないのでクォータ単位で成果を確認しています。
参考までに、もう少し過去のバーンダウンチャートを見てみます。
炎上マークの数は同じですが、タスクの進み具合がぜんぜん違いますよね。
そもそも計画線も平坦な部分があったり。
タスク自体の進行具合も1Qよりも3Qの方がスムーズに進んでいることが見てとれます。
チームメンバーそれぞれの意識がだんだんと変わっていったこともありますが、きちんと進捗が見えるようにタスクの粒度を改善していったことも違いの一つです。
ふりかえり
月次で必ずふりかえりを実施することにしています。
またふりかえりで出た意見については、月次で双方の管理職も含めた定例会があるのですがその場で共有しています。
黒塗りばかりで申し訳ないですが、実際のボードはこんな感じです。
ふりかえりと言うと、ネガティブなキーワードが飛び交うイメージを持ちがちなので、左側にはグラウンドルールを記載しています。
大事なポイントとしては以下のあたりです。
- What was good? は良かったことを書きます
- 個人の良かった取組はチーム全体へ横展開しましょう
- 誰かにされて嬉しかったことは賞賛しましょう
- What was bad? は良くなかったことを書きます
- 個人攻撃 / 責任を問う ような表現にならないように気をつけましょう
- 「改善アイテム」の抽出なので、あくまで前向きに
- コメントを書くときには「出来事」と「感情」をセットで書くようにしましょう。特に、感情はチームの他のメンバーの気付きに繋がります
- 誰かにしてもらって嬉しかったことや、困ったことはバイネームを使いましょう。ベンダさんのことを書くときも会社名はNGです
- badな内容を書くときには表現を気をつけて（攻撃にならないように前向きに捉えた表現を心がける）
- 原因の追求はしても、責任の追求はNGです
- ふりかえりは「前向き」な場です。個人攻撃や責任を問う場ではありません
- とにかくたくさん付箋を貼りましょう。付箋を貼った数がその人のふりかえりの成果です
- goodの付箋が多くなることが目標ですが、はじめはbadが多くても構いません。badが多いということは、そのチームの「伸びしろ」が多いということです
ここでも重要なのは、ルールとして決めることで奥ゆかしさを取っ払うこと。
そして、内容ではなく付箋の数が重要であること。
特にgoodに関しては、誰が一番たくさん付箋を貼れるか？の勝負だとまで言ってふりかえりをすすめています。
こうすることで、副次効果としてプライベートなことにまで波及してコメントが飛び出すので、雑談の場にもなります。
そうなると、より一層「腹を割って話している」ことを実感できるのでチームの垣根が知らない間に無くなります。
結局色々とふりかえってみると、このふりかえりが最もチームを強くする要因になったのではないかなとも思いますね。
実際、いつも力になっていただいているベンダさんでも、僕らの取組をきっかけに社内でもふりかえりをやってみよう、という話になったようでさっそく良い効果が出始めているみたいです！！
これも続けていると、付箋に書かれる内容に深みが出てくるようになりました。
はじめは、「◯◯が終わって嬉しい」「◯◯ができなくて悔しい」くらいのレベル感でしたが（この感想が出るのも大事）、今では「◯◯に関して、△△さんの協力が助かった」「◯◯で事前に△△をしていれば、もっと早くタスクを完了することができた」などより具体的にgoodやbadな項目が出るようになりました。
そして、badに書かれる表現も前向きな言葉が多くなってきたように思います。
さいごに
奥ゆかしい日本人は、どんな場でも謙遜してしまいがちです。
「人を褒める」ことで、上から目線に思われてしまうかもしれない、とか「自分を認める」ことが素直にできなかったり。
だけど、やっぱり日々感謝の心はあるし、それを言葉にしないと伝わらないし。
たとえ小さくても成功体験はやっぱり自分自身の糧になるし。
分かっていてもできないのだから、強制的に意識できるようにまずはルール作り。
これが定着するようになんでも見える状態にして、日々この意識がアウトプットにあらわれているかを確認できるような仕組みづくり。
さらには、強制的にこれらができているか？をふりかえる時間を取ることで「言葉にする」ことに対する抵抗をなくす。
僕らはこういう取組を積み重ねることに寄って会社の垣根を超えて自分たちのことを「チーム」と呼べるようになりましたし、発注者/受注者という意識は全く持つこと無く日々の業務に邁進することができています。
バーンダウンチャートも、徐々に予定通りタスク消化されているのが見えるようになり、生産性が上がってきており、自分たちのスケジュール管理の目利き力も上がっていることを実感できています。
今日明日で出来ることでは決してありませんが、どなたかのチームビルディングの参考になれば幸いです。