tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

2022年1〜3月に社内で共有したアジャイル開発関連の記事

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。

ノウハウ・知見

フィーチャーファクトリーにならないように注意

www.seleqt.net

有名なMVP図の解説

www.ankr.design

デュアルトラックアジャイルの実践

note.com

フィーチャーフラグの分類

kakakakakku.hatenablog.com

ユニコーン企業の秘密をベースとしたスケーリングの考え方

落合博満に学ぶ

技術負債に立ち向かう前の話

poohsunny.hatenablog.com

TDDの考察

yattom.hatenablog.com

スクラムチームを生産的にするパターンランゲージ

note.com

プロダクトバックログの整理の秘訣

捨てましょう。

www.ryuzee.com

30分で分かった気になるチームトポロジー

www.ryuzee.com

他社事例

メルカリCAMPシステム

現在はCamp単位でLeSS(Large-Scale Scrum)を入れるように推奨しています。そして必要があればAgileコーチやScrum Masterをアサインしています。

engineering.mercari.com

LIFULL

LeSSっぽいけどLeSSと明言してないので何か大きな違いがあるのかも。

www.lifull.blog

GitLabで学んだ最高の働き方

learn.gitlab.com

atama+ LeSS事例

Regional Scrum Gathering Tokyo 2022

スライドまとめ

scrummasudar.hatenablog.com

後日公開された動画

www.youtube.com

いい感じのチームを作る考え方

www.docswell.com

ChatworkのScrum@Scale事例

永和システムでの学び直し・スキルアップの取り組み

学びのサイクルを繰り返しながら機械学習など新領域を習得してもらうの言われるとすごく良さそうだけどこれまでみたことなかった気がするので新鮮

www2.slideshare.net

プロダクトゴールについて

www.servantworks.co.jp

スプリントゴールについて

Agile Fluencyモデル

RSGT 2022 2日目の基調講演より。うちは今Optimizationかなーと思いながら聞いていました。

martinfowler.com

プロダクトバックログについて

これは教科書

www.ryuzee.com

Yahoo LeSS事例

ブルシットプロダクト

その他

Women in Agileコミュニティ

izumii19.hatenablog.com

Twitter

CircleCIの開発の雰囲気

リモートペアプロを扱った書籍

「プロダクトバックログが降ってくる」という表現は危険の兆候

速さにはベロシティとアジリティがある

MVPには名前をつけておく

「Googleのソフトウェアエンジニアリング」の感想

2021年11月末に発売されてからすぐに入手したはずですが、少しずつしか読み進められず、先日ようやく読み終わりました。

25章ある書籍の内容をざっくり分類すると

  1. トップ層のエンジニアを集め、実業務を通じてGoogleが分析・見出したベストプラクティス
  2. Googleの規模でないと起こらないであろうスケール問題
  3. Googleにしかなさそうな謎内製ツール/謎内製ソフトウェアの紹介

かなと思います。

中堅以上のソフトウェアエンジニアなら技術的にも思想的にも面白いと感じるポイントが必ず見つけられ、頭から読み進めずとも気になる章をつまみ食いして読むこともできる面白い書籍です。

以下気になったトピックを順不同で紹介します。

Hyrumの法則が面白い

Hyrumさんはこの書籍の著者で、こんな考えを披露しています。

あるAPIに十分な数のユーザーがいるとき、APIを作った者自身が契約仕様として何を約束しているかは重要ではない。 作られたシステムが持つあらゆる観察可能(observable)な挙動に関して、それに依存するユーザーが出てくるものである。

「要件として合意した」「仕様として明記している」とかに関わらず、暗黙的な挙動に依存した実装になってしまっていることはよくあります。 有名なところだとハッシュの順序問題とか。「OSSライブラリを更新するとテストが通らなくなった」も同種の問題かと思います。

実装だけで起きるのではなく、組織のあらゆるレベル・コミュニケーションでこのような暗黙的な依存が発生するのが、法則としてよくできているなと感じます。

マネジメントについて

・自分が居合わせなかったとしても組織自体がその問題を解けるようにすることも、自分の仕事である

・優れたマネジメントの95%は観察と傾聴で、5%はちょうど正しい場所に決定的に重要な調整を加えることである

GoogleのマネジメントスタイルはGoogle re:Workとしてもまとまっていますが、エッセンスが短くまとまっている上記の書籍表現が気に入りました。 マネージャーとしてチームやメンバーと伴走することも時にあるかもしれませんが、自分がいなくても同じように物事が動くよう仕組みを作るのが一番効果的ですよね。

テストコードの読みやすさ

・テストは後からの付け足しであってはならない。

・テストコード自体のテストはかかれないため、テストコードでは分岐・繰り返しなどの制御構文を使うべきではない。

・なるべくモック使うな

Googleの開発規模・エンジニア数ともなると、不安定なテストが少量でも入ると、他の開発者の時間を奪ったりリリースブロックとなり得たりと与える影響がものすごく大きいことが心に残っています。なので当初からテストをきちんと書くし、テストコード自体も読みやすさを重視するし、なんならモックをなるべく使わずテストすることを考えるそうです。

テストをしっかり書こうとするほどモックの書き方に時間が取られているような気がしていたので、「モックを使いこなすことが必ずしも良いことではない」という意見があることが知れてよかったです。

レビューは設計を議論する場ではない

・コードレビューは、過去に既に行われた設計上の決定について討議するための時間ではない。

・コードレビューは提案されるAPIの設計を紹介するための時間ではない。

コードレビューの目的が事前に擦り合わせられていないと、つい設計方針や実装技巧の議論をしがちではありますが、レビューはそういう時間ではないと一刀両断してくれました。そうですよね。

ドキュメントは読み手を意識して書く

・(ドキュメントは)読者に向けて最適化せよ。

ドキュメント整備について、Googleは他社よりも時間・工数をかけているのだろうと思っていて、書籍を読み終わった今もその認識ですが、それでも完璧ではないと感じているそうです。ドキュメントは「Googleでも一級市民として扱われていない」だとか。

ドキュメント管理は定期的に新しいツールが出てきますが自分の中ではこれといった決定版と受け取ることができず、内容が古びたものを見直し・淘汰できる仕組みが入っているといいのかなーと思ったりしました。

ソフトウェア開発に関する意識の持ち方

コードは債務であり資産ではない。

「技術的負債」という言葉が広く使われるようになったせいか、負債でないなら資産なのだろうと私とかは考えてしまいがちですが、本書では運用・メンテナンスが必要なことから「債務」と表現していました。利用者が使い続けられるように考慮・サポートが必要なことからですが、先に紹介したHyrumの法則にもつながる考え方かと思います。

定期的な再デプロイの強制化

本番環境には半年ごとに再ビルド・再デプロイされなければならない

だそうです。

開発がひと段落したサービスだとライブラリ更新を怠ったり、頻繁に更新されないサービスだとビルド・デプロイの自動化を後回しにしてしまいがちですが、こういうルールを決めておくことで問題を軽減することができそうです。外部環境の変化でいつのまにかデプロイできなくなった/動かなくなったというのも避けやすくできそうです。

Bazel / アーティファクトベースのビルドシステム

モノレポ(全てのコードを1つのリポジトリにまとめて管理する)とセットで導入するビルドシステムとしてよく名前を聞いていましたが、アーティファクトの依存関係を宣言的に定義しておくことでツール側で再ビルドの必要性を正しく判断でき、ビルドに要する時間を短縮できると知り、仕組みにとても感心しました。Bazelについて調べてみると、現実は「Bazel職人」のようなノウハウを蓄えている人が生まれてしまう負の側面もあるようですが、それでも機会があれば一度は触ってみたいなと思うように考えが変わりました。

おわりに

少しずつ読み進めていたため、Twitter#Googleのソフトウェアエンジニアリングのタグで感想を呟いていましたが、書籍で推奨しているハッシュタグ#swebookjpだということを一番最後に知りました。ぜひ両方のハッシュタグを眺めてみて、書籍を手に取ってみてください。

Regional Scrum Gathering Tokyo 2022に参加してきました #RSGT2022

f:id:tune:20220109175931j:plain

はじめに

2019年が初回で、通算4回目の参加でした。

参加者(2019)→スポンサー(2020)→参加者(2021)ときて、今年は登壇機会がいただけ新しい楽しみ方ができました。 登壇に関しては来週あたりに会社のブログで別途書きます。

聞いてきた話など

「録画で後で見れるし、他のオフライン参加者と親交を深めるか」と考えて発表を聞いたのは半分くらいです。 3日目は家族都合 & 会社都合で不参加でした、後日録画で見ます。

Agile Program Management: Scaling Collaboration Across the Organization

f:id:tune:20220105101953j:plain

「スケールする際にコラボレーションを増やしてスケールしよう」というのはわかる。LeSSだと「ただ話す」とかなのかな?

f:id:tune:20220105104151j:plain

Software Program Teamはよくわからなかった。コラボレーションを絞る方向の仕組みだと思うけど、でも何かを決める仕組みが時に必要なのは同意。

Leading Skilled Agile Teams: Investing in Team Outcomes with the Agile Fluency® Model

f:id:tune:20220108220623p:plain
https://martinfowler.com/articles/agileFluency.html より転載

Agile Fluencyの図がなるほどなーと思って聞いていました。 チーム文化を変える→チームスキルを上げる→組織構造を変える→組織文化を変える の中で、自社の今はOptimizeのあたりかなーと思いあたります。 「アジャイルである」領域を広げる際に、気持ちではなく仕組みで工夫する必要があり、とっかかりを試行錯誤していた自分にとってはしっくりきた図でした。

martinfowler.com

今年の感想

ゴールに関する発表が多い

プロダクトビジョン・プロダクトゴール・スプリントゴールなど、目標やゴールに関する話が多かったし、講演後も議論しているのを良く見かけた気がします。

1チームのスクラム・立ち上げはできるところが増えてきて、LeSS / Scrum@Scale / Spotify Modelなどスケール手法を試すところが出てきて、「複数チームの方向性を束ねて力を引き出すにはゴール設定で認識揃えるのが大事だと考える人たちが増えてきた」とかかなーと思っています。 自社でもプロダクトゴールが明確に作れてなかったり、スプリントゴールをフワッと決めてしまうところがあり、今ひとつしっくりきてない感じがあったので長沢さん・稲野さんの発表を踏まえて試行錯誤します。

建設的な議論をカンファレンス中にやりたい

コロナ禍となり、オンラインカンファレンスになってからテキストチャットで感想を伝えるからか「いい話」のようなコメントが増えたような気がしています。

どんなことを言っても受け止めてもらえる場は大事だけど、議論して課題を見つけていく・考えることはもっとやった方が良いんじゃないかなと感じました。気心の知れたメンバーと個別に行っていたり、自社・自分の現場に持ち帰ってあーでもない・こうでもないと話しているような気がします。 できることなら会期中に「こんな意見もあるんだ」という観点を得てもらうのに見える形でできた方が良いなと。単にDiscordに撒き散らしていると荒らしっぽく攻撃しているように見えちゃうけど、RSGTの参加者ならうまくやれる方法を見出せるような気がしたり。

全体として前進できているかな?

プロダクト・現場を良くするため、知見を持ち寄って協力するギャザリングだと思うので、数年単位で見たら変化が感じられるような場であってほしいなと思うようになりました。もちろん新規参加の裾野は広がり続けるし、うまくいったり・いかなかったりを繰り返しながら螺旋のように改善が進んでいくと思うのですが、全体としてどうなんだろうと。一部の人は成功体験を積んで前進しているけど、個人に紐づいている割合が大きいような気がします。

その意味で伊藤さんの発表は考えさせられるポイントがいろいろあるなと感じました。この講演を聞いた人が次世代の社内アジャイルコーチとして業界全体のレベルを引き上げたり、伊藤さんが新たな視点を経てRSGTに戻ってきたりとか、そんな瞬間に立ち合えるといいなと思っています。

自分の4年前を思い出すとできていることが増え・フェーズが変わってきた実感がありますが、参加者全体で見ると参加者・登壇者が開発・アジャイルコーチに寄りすぎていて、もっとステークホルダー(経営層・幹部層)やプロダクトマネージャーなどが増えると良さそうだし、基調講演の反応が変わってきたりするのかなと思いました。

「モノリスからマイクロサービスへ」を読んで考えたこと

2021年に会社で読書会をし、社外の方とも別途読書会をしたほどの本でしたが、タイミングを逃して感想を書いてなかったので残しておきます。

マイクロサービスに取り組む上での基礎や重要事項が丁寧に説明されている

1章と5章が特に良かったです。

  • なぜマイクロサービスに取り組むのか。
  • 3つの疑問。1. 達成したいこと、2. 代替案がないか、3. 成功の基準。
  • マイクロサービスで守るべきこと

などなど。

3章と4章はテコ入れの界面を見定めて徐々に新しステムに切り替えていくストラングラーパターンをサービス内・DBで行うような似た話が続いており、ここを工夫できればもっと短く上手くまとめられそうなのになと感じました。

書籍全体の印象としてはマイクロサービスを考え始めたぐらいの時期から、実際に進めていて壁にぶつかったあたりまでに読むのが良さそうです。 関係者の知識や思想を揃えるにはいい本でした。マイクロサービスを推進していく上での実践テクニックはそこまでカバーされていません。

モジュラモノリスそんなにいいものだろうか

書籍ではマイクロサービスが一押しというわけではなく、なぜマイクロサービスに取り組むのか・モノリスではダメなのかという話も同じくらい重きを置いて説明されています。 デプロイ単位としてまとまっているが、内部の作りは分けられたモジュラモノリスも書籍で触れられていますが、読書会でもモジュラモノリスに惹かれるメンバーがいました。個人の感想としてはモジュラモノリスフレームワークの後押しが欠かせないと感じていて、知っている限りだと取り組むのに向いているフレームワークはあまりないかなという印象です。強いて言えばRails Engineなのかな?

自社でも一つ、小さなサービスの寄り合いになっているサービスをモジュラモノリスのように作ってみましたが、内部で知らず知らずのうちに依存関係を持ってしまったことが後日わかり、切り離す判断が遅れていたらもっと結びつきが強くなってただろうなと思います。フレームワークで依存関係を防止できるか検出できるようになってないと厳しい印象です。 モジュラモノリスに取り組んでいるところがあればぜひ話を聞いてみたいなと思いました。

マイクロサービス移行は文化の変革である

自社のマイクロサービス移行は数年かけた計画になっており、早くともあと3〜4年かかるかなという見立てですが、書籍でもマイクロサービス移行は文化を変える必要があり、長い時間がかかるとはっきりと書かれています。 自社の力不足や怠慢で時間がかかっているのではなく、開発文化を変えながら進める必要があるためこれぐらいかかるのが当たり前だという時間軸の認識を揃えられたのが良かったです。

異なるプロダクトに取り組んでいる人同士で話すと違った気づきがある

冒頭で触れた通り社内読書会と社外読書会で2回読みましたが、それぞれ違った気づきがありました。

社内メンバーとの読書会は会社のプロダクトの歴史を踏まえ深く議論することができますが、経験が似ているからか観点は偏りがちで、書籍で意図が汲み取れなかった箇所が社内メンバー全員わからずといったこともありました。

社外メンバーとの読書会では、経験・背景が異なるので、「こういう経験があった」「こういうことかと受け取った」といった話を広く聞くことができ、いろんな視点から本の内容を考えることができました。2022年も何かの本を選んで社外の方と話をすると面白いかも。

他に気になっているマイクロサービス本

会社でマイクロサービス導入を始めた2019年に読んでこれは完走しました。だいぶ前の本ですが、内容が大きく古びていることもなく今でもおすすめかと。

まだ未読ですが、「モノリスからマイクロサービスへ」よりも実践的な内容がカバーされている印象を持っています。

2021年11〜12月に社内で共有したアジャイル開発関連の記事

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。次回からは3ヶ月に1回のまとめに変えてみます。

ノウハウ・知見

ハックマンに学ぶ良いチームの作り方

speakerdeck.com

アジャイルなソフトウェア開発に使えるかもしれないメトリクス

iucstscui.hatenablog.com

スプリントレビューでコンテキストをきちんと共有する

callas1900.net

アリスター・コーバーン再考

話が引き継がれるにつれて変わっていくのあるあるですね。

www.agile-studio.jp

他社事例

ChatworkのScrum@Scale

開発体制、スケジュール、自己採点の仕組みなどが興味深い

www.youtube.com

はてな MackerelのLeSS事例

hktngch.hatenablog.com

マッハバイト(LIVESENSE)のスクラム導入と廃止

よく見る失敗談で、新天地でスクラム入れようと奮闘する人も何割かは直面することになるものばかりだなーと思いました。

made.livesense.co.jp

Mobility TechnoglogiesのLeSS事例

now.mo-t.com

その他

Women in Agile Japan

いい取り組みだなー、貢献できることあるかなーと思っている間にDiscord招待リンクが切れてしまっていた><

note.com

Twitter

スクラムマスターの一人相撲

顧客に予算を持たせて、何を作るか投票させる

スレッドの情報含めて面白い。

アジャイル浸透が頓挫する組織の風土

作り方がわかる人がいないのに決めたがる不思議

不確実性を人に押し込めるのがアジャイル?

知的コンバットできていますか?

qiita.com

この記事はAdvent Calendar for upcoming Regional Scrum Gathering Tokyo 2022 Advent Calendar 2021 25日目の記事です。自分がRegional Scrum Gathering Tokyoに初めて参加したのが2019年のこと。2020年は会社でスポンサーでき、2021年は同僚が登壇して、2022年は自分が登壇できることになりました。今所属しているRettyアジャイルに・大規模スクラム(LeSS)に取り組む会社としてある程度認知いただけるようになった感触がありますが、年初にRSGTでエネルギーを貰えているのが助けになっている気がします。

知的コンバットによりイノベーションを生み出す

www.youtube.com

※ 注 : RSGT2021での野中先生基調講演動画はRSGT2022開催までの期間限定公開だそうです。

RSGT2021の最終日の基調講演で野中先生から投げかけられた言葉「知的コンバット」。これまで自分が探究していきたいことを「顧客にとって価値のあるプロダクトを、チーム一丸となって協力し、短期間にリリースする開発体制のあり方」と表現していましたが、もっと端的に短く・もっと情熱がこもった言葉を聞くことができ、この1年間自分の頭から離れないキーワードとなりました。

全身全霊で向き合うためには二人、ペアであることが最適です。同時に、双方の目線が上向きや下向きではなく、真っ当に向き合っていることが大事です。それでもそう簡単にはコンセプトは出てきません。「知的コンバット」を何度も繰り返す必要があります。双方が感じた異なる直観を、真剣勝負で何度もぶつけ合いながら、ようやく「こうとしかいえないよね」というコンセプトにつながっていくという感じです。この「共同化」のプロセスがない限り、組織で「知」を生み出す、イノベーションが起こるということはあり得ません。

【野中郁次郎氏対談】第2章 徹底的な対話による「知的コンバット」なくして、イノベーションは生まれないより引用

「プロダクトオーナーが決めたプロダクトバックログの優先順位に従って開発を行う。開発チームは固定期間で区切ったスプリント内でインクリメントを作成し、リリースして得られた学びから次に何をしていくべきかを改めて考える。」こうして不確実なプロダクト開発に挑戦してくのがスクラムですが、真に優れたプロダクトを作る・イノベーションを生み出していくにはもっと真剣に自分たちが取り組む対象に向き合い、議論を戦わせていかなければなりません。

知的コンバットは難しい

「議論が大事だから意見を戦わせよう。職責やロールにこだわらずやっていこう。」と言うのは簡単ですが、実際に起きるのはレベルが低いケンカとトラブルです。 「セールス・企画・開発で納得のいく計画・プロダクトを作りたいのでお互いに意見を伝え合おう」と言うと、率直な意見が攻撃と受け取られ、職責を超えた提言が信頼感の欠如として受け取られてしまいます。「なぜ取り組むのか」「なぜ今なのか」「もっとよい打ち手はないのか」「何を学ぼうとしているのか」、プロダクト開発に真摯に向き合い本質に迫ろうとする問いほど、その山を知らなかったり、登り始めたばかりの当人にとっては致命傷となるマサカリになります。

HRT(Humility, Respect, Trust)を心がけた発言に、ドメインの理解や背景の共有、相手との信頼感を醸成し、人・相手ではなく問題・ゴールに目を向けて話す。ここまで段取りを整えてようやく知的コンバットの入り口に立てそうというのが私の正直な感想です。

RettyのAdventCalendarでプロダクトマネジメント組織で浸透した7つのキーワード(①PMスキル定義・評価制度, ②アウトカム, ③ロードマップ, ④事前検証, ⑤問いを立てる力, ⑥既知と未知, ⑦因果ループ)を野口がまとめてくれていますが、知的コンバットの土台となるこれらを浸透させるだけで1年です。長い道のりです。

note.com

知的コンバットの実現に手応えを感じた出来事

知的コンバットと呼べるような議論の成功を目指し、うまくいったりいかなかったりを繰り返しながらの開発でしたが、「知的コンバットとはこう言う状態なのでは?」と手応えを感じたことがありました。その出来事の直前は1ヶ月弱ほど中規模プロジェクトの開発に取り組んでおり、その振り返りで「実はプロジェクトの序盤からうまくいってないもやもやを抱えていて、良くないと思っていました」という告白を複数人から聞いたことがきっかけです。「その時言っておけばもっと違った今があるかもしれないのに」と静かな怒りを覚えたのをとてもよく覚えています。

その次のスプリントではスプリントプランニングにいつも以上の時間と熱量をかけました。「次のスプリントに何を取り組むべきか」「プロダクトオーナーの優先順位に質問はないか」「開発観点で先に取り組むべきことはないのか」「言うならこのタイミングだぞ、終わってから意見の後出しだめだぞ!」「本当に納得したか?」とかなり口すっぱく確認し、そこからチームの動きや成果が大きく改善された気がします。

本当に足りなかったのは熱量なのかも。

この記事を書きながら思い返してみると、タイミングやプロセス、知識の問題もあったかもしれませんが、それ以上に熱量が足りてなかったのかもしれません。 その後のメンバーとの1on1で気持ちを込めたアドバイスを多く送った気がします。

  • 相手に言っても聞いてくれないじゃない、聞いてもらえるように言うんだ。
  • 聞いてもらえるために「背景を説明する」「費用対効果を説明する」「時には感情を込める」「めげずに何度も言う」など色々試す。
  • 「コミュニケーションが足りない」とはどういうことなのか。真の問題から目を背けているのではないか。
  • あとでふりかえりをしたらダメだったことが良かったことに出来るわけではない。勇気を出していつでも言うべき。

終わりに

「真剣勝負で意見をぶつけながら、こうとしか言えないコンセプトを作り上げる」を達成した瞬間の楽しさは何ものにも代えられません。 「知的コンバット」の実現に必要な土台は準備は簡単ではありませんが、こうした経験が積める場を作れつつあることがマネージャーとしての今年の成果かと思います。

今日の話は「協働でゴールに向かう"チーム環境"」に関する話ですが、RSGT2022では「高速に石橋を叩いて渡る"開発環境"」の話をします。来年もRSGTでエネルギーを補充し、イノベーションを産む原動力を養っていきましょう。

心理的安全性をもたらすには

この記事はEngineering Manager Advent Calendar 2021 4日目の記事です。

f:id:tune:20211122101448p:plain

心理的安全性という言葉が一般的になり、その重要性も、誤解(心理的安全性=ぬるま湯とか)も、訂正(心理的安全性は当人が決めるもの)も広まった状況かと思います。

心理的安全性を扱った記事はたくさん見かけるものの、「心理的安全性を高めるに具体的にどう行動したら良いのか?」という疑問に正面から答えた事例は少ないように感じます。ということで自分が普段行なっている行動や背景にある考えを紹介します。

ただ話す

チーム間の調整にもっとも良い方法は単純に、ただチーム間の調整をすることです。課題があれば自己管理されたチームの誰もが他チームの所に行って議論することが期待されています。もし、「ただ話す」ことが出来ない状況なのであれば、電話したり、最悪の場合にはメールを送れば良いわけです。調整の為に形式張った場は不要で、調整が遅れるだけです。立ち上がって話に行ってください。

これは大規模スクラムフレームワークの一つ、LeSSで紹介されているプラクティスの1つです。 何か相談しないといけない時にマネージャーやリーダーに相談したり、定例会議を設けたり、調整役を設定したりすることをよくしますが、LeSSでは調整が必要になった時にただ立ち上がって相手のところに行き話すことを推奨しています。

チーム同士で調整が必要な項目はマネージャーを介さず話してもらっていますし、チームに対してのもやもやを相談された時は直接当人に伝えてみてはと話しています。マネージャーが間に入った方がうまくいくケースは少ないですからね

調整と統合 - Large Scale Scrum (LeSS)

"誰"の話をしているのかを明確にする。

「チームに言いずらい」という悩み相談を1on1で聞くことがありますが、その時は「言いづらい相手はAさんのことですか? それともBさん? それともCさんのことですか?」と名指しで聞くようにしています。1人1人の顔を思い出して考えてもらうと個別の人に言いづらいということはほとんどなく、大抵はチームや組織といったボヤッとした対象に対してなんとなく受け入れられないんじゃないかという不安感を抱いているケースがほとんどです。

対象をぼやかして話すと、さも抽象度の高い難問に取り組んでいる感じが出てしまうので、具体的に掘り下げてみましょう。 似たような話ですが「組織は話さない」というブログ記事が切れ味鋭くて好きです。

組織は話さないですよ|qsona|note

個人の問題ではなくプロセスの問題として扱う

「ただ話す」を実施してもらい、「誰の話か明確」にしても解決しない問題はあります。 1個人の望ましくない振る舞いが槍玉に挙げられることは少なくありませんが、この手の問題は「個人のコミュニケーションの問題」としてしまいがちです。 ですが一緒に働くメンバーを信じるならば、これは個人の問題ではなく「問題を生み出す背景プロセスの問題」なのではないでしょうか。

プロセスの問題を炙り出すには事例を複数集めて共通する背景要因を時間をかけて考える工数が発生しますが、個人の問題として安易に断じない姿勢をとり続けることで、問題をエスカレーションしても正しく議論されるという安心感が醸成できるのではないかと考えます。

聞きにくいことを率先して聞く

皆にしてほしい振る舞いを率先して行い、背中で見せることはよくあると思います。 私は言葉足らずだなと感じた説明があったら、意図を明確にするためにあえて聞くことを意図的に行なっています。

例えばあるルールが「"従業員"を対象に実施」と説明された場合、正社員の自分が対象者に含まれることは自明ですが、アルバイト・業務委託・インターン契約社員のメンバーは悩むかもしれません。こんな時は「従業員にアルバイト・業務委託・インターン契約社員は含まれますか?」とSlackチャンネルでオープンに聞いたりします。「マネージャーなので質問しやすいんでしょう」と思われているかもしれませんが、投稿する時はドキドキしています。役職者になってもそんなものです。

心理的安全性があるかのように振る舞う

心理的安全性の話が出るといつも引用してくる好きなスライドです。 マネージャーだからドキドキしても聞きにくいことを聞く、マネージャーだからメンバーを信じてプロセスの問題を探す、マネージャーだから皆が自律的に動けると信じて後ろで見守る。皆も同じような振る舞いを続けて自信がついてきた結果の先に心理的に安全な職場が実現できる。私はそう考えています。

おわりに

心理的安全かどうかは各々が感じる・決める話ではありますが、2021年夏に勉強会を開催した際に「今の会社は心理的に安全か?」とファイブフィンガー (指1本:安全でない〜指5本安全である)で回答してもらったことがありました。私は指4本を出しましたが他のメンバーは指5本出していたので、そこそこ安全な職場が作れているのだと考えています。

そんなエンジニアリングマネージャーが考えていることの紹介でした。