『認定アジャイルリーダーシップ研修ってどんなの？』〜 スクラム Bar #3 に参加した

『認定アジャイルリーダーシップ研修ってどんなの？』〜 スクラム Bar #3 に参加しました。

chatwork.connpass.com

認定アジャイルリーダーシップ研修を受けた感想を共有してもらえる会でした。気になったこと、心に残ったことをまとめます。

スクラムマスターとアジャイルリーダーの違いは組織を見ていること

「アジャイルリーダーはアジャイル組織を作るリーダーとして意思決定をする」というお話や「ORSC(オースクって読むんですね。)に似ている」というお話がありました。今回のお話を聞いて、スクラムマスターよりも広い範囲にアプローチする人がアジャイルリーダーだと感じました。また、#ScrumMasterWayの第3のレベル と アジャイルリーダー が近いのではないかとも思いました。
ScrumMasterWay - スクラムで卓越した成果を収めグレートスクラムマスターになるための方法

「アジャイルリーダーとして自分は何をするのか」を常に自問する研修のようです。僕も何ができるか、何をするのか考えようと思いました。考えよう。

小さく始める

僕は「組織」という大きなシステムに対してチャレンジを考える時、大きなことを考えがちです。組織をテーマにした今回のお話では小さく始めましょうというメッセージがあったように感じます。組織に対してアプローチするときは上手くいかずに心が折れるというお話もあったので、Fearless Changeの「小さな成功」「やってみる」を思い返して進めていこうと思いました。Fearless Change 改めて読んでみようと思いました。

傾聴の3レベル

傾聴における3段階のレベル（わたし、わたしたち、ワールド）の紹介がありました。以前読んだコーチングバイブルにも3つの傾聴レベル（内的傾聴、集中的傾聴、全方位的傾聴）が紹介されていて、勉強していることがアジャイルリーダーに繋がっていると感じて少し嬉しくなりました。

傾聴の難しいところは傾聴を意識してはいけないことだと思います。傾聴を意識している時点で「わたし」に意識が向いていて低いレベルの傾聴になります。人と話をするときに意識することは「傾聴」じゃなくて、その人の話を聞くことですね。

誰もが正しい。ただし部分的には。

本イベントの最後の方に出てきた言葉です。部分に囚われず全体を俯瞰して見れるように気を付けていきます！
ORSCでは「誰もが正しい、ただし全体からすると一部だけ正しい」と言うようです。

まとめ

認定アジャイルリーダーシップ研修がどんな雰囲気かつかめるイベントでした。組織をより良くしていくために今回の出てきたことは意識したいと思います。また、SCRUMMASTER THE BOOK と Fearless Change は改めて読み直してみようと思います。

運営の皆さん、参加者の皆さん、ありがとうございました！

参考

iucstscui.hatenablog.com
iucstscui.hatenablog.com
iucstscui.hatenablog.com

集中が大事！マンガでよくわかるエッセンシャル思考を読んだ

マンガでよくわかるエッセンシャル思考を読みました。エッセンシャル思考の本は知っていましたが、読むきっかけがありませんでした。ある日、図書館で「マンガでよくわかるエッセンシャル思考」を見つけて①エッセンシャル思考が何か知れそう。②マンガならサクッと全体を把握できそうということで読んでみました。

マンガでよくわかる エッセンシャル思考

「仕事に追われる日々を抜け出したい、やりたいことに時間を使いたい」

そのような、自分の時間を確保したい人のヒントが集まった書籍です。エッセンシャルとは「必要不可欠な、きわめて重要な」という意味の単語です。必要な仕事に集中してより良い効果を出すための考え方が知れます。

99%の無駄を捨て1%に集中する

全部がんばろうとすると努力が分散されて1つ1つの力が弱くなります。本当に大切なことに絞って取り組むべきです。そのためにフレームワークや考え方を使って「あなたにとっての本当に大切なこと」を見つけられるようにする。そして見つけたらそれ以外は断る。ということが書かれていました。

「断る」が個人的には難しいです。そんなこと言っているから非エッセンシャル思考なのですが。。。以前読んだコーチング系の本からヒントをもらうと「1日3回断る」という目標を決めると良さそうです。

「本当に大切なこと」を見つける

「本当に大切なこと」を見つけることも難しいですよね。間違えて大切なことを無駄と判断しないような基準が必要です。本書では判断するための仕組みやフレームワーク、考え方が紹介されていました。「なぜやるのか、いつやるのか、何をやるのか」「考える時間をつくる」「90点ルール」「最低限の基準と理想の基準を3つずつ」「具体的×刺激的な目標」

この中ですぐに参考にしたいと思ったのは「具体的×刺激的な目標」です。「一般的/具体的」「刺激的/平凡」のマトリクスにおいて、具体的×刺激的な目標を設定することをお勧めしています。「毎週欠かさずブログを書く」が良い例でしょう。具体的で刺激的です。エッセンシャル思考以外でも目標を決める時に使えるマトリクスですね。

今、目の前に集中する

本書では目の前に集中するために「今、何が重要かを考える」「未来を頭の中に抱えない」「優先順位をつける」の3つが紹介されていました。

これらを実現するためにポモドーロテクニックを使うと良さそうですね。

まとめ

• エッセンシャル思考を読みました
• 日常の中でも取り入れやすいTipsがたくさんありました
• ほんとうに99%を断ると問題が出る部分がありそうなので、断るにしても慎重にしたいです。

参考記事

iucstscui.hatenablog.com

心理的安全性で学習する組織を作ろう！恐れのない組織「心理的安全性」が学習・イノベーション・成長をもたらす を読んだ

恐れのない組織「心理的安全性」が学習・イノベーション・成長をもたらす を読みました。

ITエンジニア本大賞2022 でベスト10に選ばれていたことと、「チームが機能するとはどういうことか」の著者の新刊ということで興味を持っていました。

恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす

心理的安全性は色々なところで使われるようになりましたね。この言葉を聞いたことがない方は少ないのではないでしょうか。本書は心理的安全性が組織にどう影響するのか、どうやって高めていくのかについて書かれた本です。心理的安全性という言葉の意味は知ってるけど、仕事にどう影響するのか？という疑問を持つ方、リーダーの方にお勧めです。本書を読んで考えたことをまとめていきます。

目次

はじめに
第1部 心理的安全性のパワー
　第1章 土台
　第2章 研究の軌跡
第2部 職場の心理的安全性
　第3章 回避できる失敗
　第4章 危険な沈黙
　第5章 フィアレスな職場
　第6章 無事に
第3部 フィアレスな組織をつくる
　第7章 実現させる
　第8章 次に何が起きるのか
解説　村瀬俊朗

心理的安全性で組織のパフォーマンスを最大にする

本書のメッセージは「心理的安全性を高めて、チームや組織のパフォーマンスを最大化しましょう。」だと思います。本書のタイトルになっている「恐れのない組織」は「対人関係の不安を最小限に抑え、チームや組織のパフォーマンスを最大にできる組織」だと定義されています。

「心理的安全性が高くなれば、ほんとうにパフォーマンスはあがるのか？」「誰がどのように心理的安全性を高めるのか？」この2つ問いに対する答えが詰まった本とも言えます。

心理的安全性が高いと学習が進む

「心理的安全性が高いとなぜパフォーマンスはあがるのか？」それは組織やチームの学習が促されるからだという旨が書かれてます。心理的安全性が低く部下から上司に意見が言えず失敗する事例や、逆に心理的安全性を高める仕組みを作って成功する事例が数多く紹介されています。

心理的安全性が高まると異なる意見を建設的に議論できます。例えば、部下が上司に意見をし採用されたり、A案とB案をぶつけ合ってC案を生むようなことです。1人では得られなかった結果を協力して生むことができます。逆に心理的安全性が低いと部下が上司に意見することはありません。上司の意見と違っても黙っていることは1度や2度、誰でもあることではないでしょうか。

心理的安全性が高まると学習が進む、もう一つの理由はチャレンジしやすくなることです。心理的安全性が高い文化では失敗を許容します。というよりチャレンジを歓迎するようです。同じことを繰り返しても学習は進まないため重要な考え方です。心理的安全性×チャレンジングな目標で学習を進めるのです。

心理的安全性と学習を分かりやすく説明した一文があります。

学習する組織の価値観とその実践を確実にするメッセージはこれだ。「 間違ってもいいし、他人によく思われない意見を持っても構わない。ただし、出てきた結果から積極的に学ぶことが条件だ」。
(p.245). 英治出版株式会社. Kindle 版.

心理的安全性を高める方法

本書ではリーダーがチームの心理的安全性に影響を与えやすいと書かれています。さらに心理的安全性を高めるためにリーダが取るべき行動カテゴリがまとめられています。

• 土台をつくる：期待と意味の伝達(今後取って欲しい行動について伝える)
• 参加を求める：発言が歓迎されるという確信(状況的謙虚さを示すなど)
• 生産的に対応する：絶え間ない学習への方向づけ(感謝を示す)

また、現在の心理的安全性度合いを知ることも大切です。測定する方法はエドモンドソン教授の7つの質問を使うと良さそうです。本書でも説明がありました。7つの質問はGoogle re:Workにまとめられています。
Google re:Work - ガイド: 「効果的なチームとは何か」を知る

良い取り組みだと思ったピクサーのブレイントラスト

本書で心理的安全性の高い事例としてピクサーのブレイントラストが紹介されていました。ブレイントラストはグランドルールも含めて良いなと思った取り組みなので取り入れてみようと思います。少し概要を説明します。ブレイントラストは映画のストーリについてメンバーから監督に意見を言うイベントです。本書では3つのグランドルールがあって、①フィードバックは建設的にし、受け取ったフィードバックは歓迎すること。②意見を採用するかどうかは監督に最終決定があること。③あらさがしではなく、良くなるためにフィードバックすること。です。

参考
グーグルも重視する職場の｢心理的安全性｣とは | リーダーシップ・教養・資格・スキル | 東洋経済オンライン | 社会をよくする経済ニュース

まとめ

• 恐れのない組織「心理的安全性」が学習・イノベーション・成長をもたらすを読みました
• 心理的安全性の必要性が十分にわかります
• 心理的安全性を高める手段が学べます

関連記事

iucstscui.hatenablog.com
iucstscui.hatenablog.com

1年で6倍にメンバーが急増したエンジニアリング組織の変遷と判断に参加して得たこと

1年で6倍にメンバーが急増したエンジニアリング組織の変遷と判断に参加しました。

sansan.connpass.com

「1年で6倍にメンバーが急増したエンジニアリング組織の変遷と判断」というテーマでの講演と、QAコーナーでした。QAコーナーは質問が止まらなくて予定よりも長い時間お話が聞けました。ほとんどの質問について回答されていて、僕の書いた質問も取り上げていただいてありがたかったです。

今回もイベントの内容の詳細ではなく心に残ったことを中心にまとめていきます。

月1の社内OST

月1回の社内OSTを開催されているというお話がありました。最近は月2回に増やしたとQAコーナーで仰ってましたテーマは様々で「最高のエンジニア集団とは？」「セキュリティチェックの負荷を軽減したい」など粒度も範囲もバラバラです。OSTはそれが良いですよね。気になっているテーマに関して、気になっているメンバーで議論できる文化は良いなと思いました。また、OSTをたまに開催するイベントではなくて、月1にすることで各個人が課題を発信する文化が醸成したり、組織的な課題を自分ごととして捉えられるのかなと思いました。

今まで、社外の勉強会やイベントでOSTをする機会があったのですが、最近はオフラインイベントで減ったなーと思いました。社内で定期的なOSTを計画してみようかな。

チームへのラブレター

チームの存在意義や期待などを文章で伝える取り組みです。事業として大きな変化を起こすとき、メンバーにどういう考えで変化を起こしたのかを言語化して伝えることから始まったそうです。ラブレターというネーミングセンスも良いですね。「フィードバックと期待」という感じにすると堅い感じになるので「ラブレター」だと気持ちも載せて届けられそうです。

最近は「なぜ」をドキュメント化する重要性を感じています。目的は伝えたつもりでも伝わりきらないですし、時間がたつとどうしても記憶からは薄れてしまいますよね。ドキュメントはその点を解決する一つの良い方策だと思っています。また、文字にするときに自分の考えも整理できるのでドキュメントは大事です。

そのとき、そのときの課題に向き合っている

直接、こういうお話があったわけではないですが、講演やQAを聞いていて、「今」の課題に向き合って小さく改善しながら大きく成長されたんだと感じました。「チーム分割」、「リーダという役割を用意しない」、「役割を持ったリーダーを用意する」、「ドキュメントを重視する」など、今必要な取り組みや改善をされている印象を受けました。また、取り組んだけどやめたお話もあり、組織で色々な実験をされていると感じました。
社内OSTの仕組みがこの文化を作っているんのではないかと想像します。

1on1の参考になった

QAコーナーは参加者からの質問を中心に、モデレータの西場さんが発表者の大西さんに質問しながら進みました。西場さんの立ち振る舞いが個人的に憧れて、にこやかに、色々な発言を肯定し興味を持ちながら、色々な角度からの質問を繰り出されていて、こういう1on1が出来るようになりたいなーと思いました。

まとめ

1年で6倍にメンバーが急増したエンジニアリング組織の変遷と判断 に参加しました。今の課題に向き合って成長できる組織作りという点で参考になる部分がたくさんありました。OSTやラブレターなどマネしたい取り組みもあったので取り入れてみようと思います。
運営の皆さま、参加者の皆さま、ありがとうございました！

おまけ

マネジメントにお勧めの書籍として紹介されたHIGH OUTPUT MANAGEMENT は面白そうで読んでみようと思いました。

HIGH OUTPUT MANAGEMENT

Windows と Unity の環境で Android 実機テストをする方法

Windows と Unity の環境で Android 実機テストをする方法をまとめます。軽い気持ちで試してみたら色んな場所で詰まりました。慣れないことをすると時間がかかりますね。

大きく分けるとやることは3つです。
Androidデバイス側

• AndroidのUSBデバッグをONにする

PC側

• Google USB DriverとAndroid Composite ADB Interface をインストールする
• UnityでAndroid環境向けにビルドして実行する環境をつくる

環境

Unity：2020.3.29f1
Windows：Windows 11
Android：Android 12

ご注意

インストール方法をまとめますが、公式ブログも参考に進めるのが良いと思います。公式ブログで分からない部分を本ブログや他のブログなどで補いながら進めるのが最短距離だと思います。なぜかというと、Unityバージョンによってインストール方法が違うからです。この記事も古くなっている可能性があります。この記事を参考にする場合は上記環境が近いかどうかご確認ください。
docs.unity3d.com

AndroidのUSBデバッグをONにする

AndroidデバイスとWindowsPCをUSB ケーブルで接続してデバッグするために、デバイス側の開発者向けオプションを有効にします。「ビルド番号」を7回タップすると有効になります。「ビルド番号」の場所は機種によって違うみたいで、Pixel6は「設定」→「デバイス情報」→「ビルド番号」の場所にありました。

開発者向けオプション有効後は開発者向けオプションページの「USBデバッグ」をONにします。開発者向けオプションページは「設定」→「システム」→「開発者向けオプション」にあります。

これで、デバイスの設定は完了です。

Google USB DriverとAndroid Composite ADB Interface をインストールする

Windows から Androidデバイスをデバッグ実行するには、Google USB DriverとAndroid Composite ADB Interface をインストールする必要があります。ドライバーをインストールするとAndroid Debug Bridge（adb）によりデバッグできます。

Google USB Driverのインストール
Google USB DriverはAndroidStudio経由で行いました(遠回りな気がしますが、他の方法が分からなかった)。

AndroidStudioは以下ページからダウンロードできます。
developer.android.com

AndroidStudioインストール後、以下の手順でGoogle USB Driverをインストールします。
1. AndroidStudio起動後、「Project」→「More Actions」→「SDK Manger」

2. 「Android SDK」→「SDK Tools」→「Google USB Driver」

Android Composite ADB Interfaceのインストール
PCとデバイスをUSBで接続してデバイスマネージャーを開きます。接続したデバイス(僕の場合はPixel6)がデバイスマネージャに表示されていますので、右クリックでデバイスの更新をします。「コンピューターを参照してドライバーを検索」を選び、「C:\Users\<ユーザー名>\AppData\Local\Android\」を検索対象にしてドライバーをインストールすると、「Android Composite ADB Interface」がインストールされます。

adb.exeの環境パスを通す
Google USB Driverインストール後、adb.exeの環境パスを通します。
adb.exeはSDK Mangerでインストールした場所の「Sdk\platform-tools」にあります。インストールした場所は以下の部分で確認できます。僕の場合は「C:\Users\<ユーザー名>\AppData\Local\Android\Sdk\platform-tools」です。

上記パスをユーザー環境編集のPATHに登録し、adbコマンドを使えるようにします。

UnityでAndroidをビルドして実行する環境をつくる

この項目では2つのことをします。

• Android Build Support をインストール
• ビルドのプラットフォームをAndroidに変更

Android Build Support をインストール

Unityをインストールするとき、PlatformのAndroid Build Supportにチェックを付けてインストールします。

インストール済みのUnityにAndroid Build Supportを追加する場合はインストール済みのUnityの歯車ボタンから追加できます。

UnityのビルドのプラットフォームをAndroidに変更

Unityを起動し、「File」→「Build Setting」からAndroidを選択して「Switch Platform」を押すと完了です。

これで動きます

「Build And Run」を押すと、接続したデバイスでアプリが実行されます。

詰まった事

「Android device is not responding!」

「Build And Run」を押下すると以下のようなエラーメッセージが表示されました。
「Android device is not responding!」「Make sure USB debbuging has been enabled and that the device has authorized this computerd ・・・」

原因
デバイス側がUSB デバッグを許可していないためです。
解決方法
コマンドプロンプトから「adb devices」を実行してください。デバイス側に「USB デバッグを許可しますか？」とポップアップがでるので、「このパソコンからのUSBデバッグを常に許可する」にチェックを付けて許可ボタンを押します。

それ以外にも「Build And Run」でデバイスとの接続関係でエラーが発生した場合は、手順を見直してみてください。

• USBデバッグが無効になっていないか
• Google USB Driverはインストールしたか
• adb.exeの環境パスは通したか
• Android Composite ADB Interface はインストールしたか

参考

UnityのAndroidビルドで「Android device is not responding!」が出たときの対処

1on1について調べてまとめた

1on1は難しい。雑談がメインになったり、進捗がメインになったり、巷で良くないと言われている状態になることも少なくありません。何とかできないかと思い、色々なブログを読んだり、コーチングの本を読んだりしました。

参考にした情報を整理して自分なりに進めやすそうな形にまとめてみました。

目的

• 相互理解による信頼関係を築くこと
• クライアントの充実した日々がおくれること
  • 課題の確認と支援と解決
  • 重要な情報伝達
• 成長促進

1on1は目的を持って進めることが重要です。基本となる目的は持ちつつ、相手によって目的を変化させるのが良さそうです。また、これらの目的が組織の成長に繋がっていることを理解するという点も重要だと思います。

1on1に対する心構え

• 相手を信頼する
• 相手の幸せと成功を願う
• 嫌われることを恐れない
• 協力して進める
• テクニック先行にならないように気を付ける

1on1に関するテクニックや進め方を整理することも重要ですが、同じぐらい心構えも重要です。「学んだテクニックを使って俺があいつを成長させてやる！」では上から目線の1on1になって上手くいかない気がします。一兆ドルコーチという書籍には「あらゆるマネージャーの最優先課題は部下のしあわせと成功」と書かれていました。相手のしあわせと成功のためにテクニックを使うのです。

1on1の進め方

じゃあ、実際にどうやって進めていくのかまとめていきます。

1on1毎のテーマの決め方

1. 信頼関係を築くことに重きを置く
2. (信頼関係が築けたら)課題や成長支援に重きを置く

1on1を始めて間もないころは信頼関係を築くことに重きを置きます。信頼できない状態で色々な話をしても本質的な気づきなどは起きにくいでしょう。

ミーティングの進め方

ミーティング前

1. アジェンダを共有する

ミーティング中

1. 1on1そのものの目的と今回の1on1の目的を伝える
2. アイスブレイク
3. 状態に関するチェック
4. 相手からの質問や相談
5. 私からの質問や相談
   　(状況によって話す内容を選択する)
   　課題の確認と支援
   　重要な情報の伝達
   　成長促進
   　フィードバック
6. アクションの確認

準備が重要です。準備が出来ていないと雑談だけになったり、進捗確認だけになったりします。事前にアジェンダを共有してどういう話し合いになるのかお互いに把握しておくことが大切ですね。

やり方

• 2人共有の議事録を残す
• 事前の予稿を準備

書いてることはミーティングの進め方と似てますが、とにかく準備が大切です。あと、議事録を2人で共有することも良さそうです。共有すれば、忘れたときに見返せますし、どんなことをメモされているのか不安になりません。

スキル・理論

• 傾聴
  　内的傾聴
  　集中的傾聴
  　全方位的傾聴
• 承認
• 反映
• 明確化
• 俯瞰
• 比喩
• 認知
• 問いかけ
• 自己開示
• フィードバック
• コーチング
• ティーチング
• メンタリング
• ペーシング
  →相手のペースに合わせること
• バックトラッキング
  →オウム返しするテクニック
• キャリブレーション
  →相手を観察する(表情、目線、態度、姿勢、声の状態、雰囲気など)
• リフレーミング
  →物事の見方を変える
• 説明スタイル
  →経験を自分に説明するときの思考の癖
  　永続性、普遍性、個人度（内的・外的）で考える
• 単純接触効果(ザイオンスの法則)
  →1度に長い時間使うよりも、短い時間で何度もあった方が信頼性が高まる
• コルブの経験学習モデル
  →「①経験→②内省→③概念化→④実験」のサイクルを回し学習すること
• ピグマリオン効果
  →他人から期待されることによって学習・作業などの成果が上がる現象。
• アクナレッジメント
  →相手を認めること
• ジョハリの窓
  →自分自身が見た自己と、他者から見た自己の情報を4つのカテゴリで分析する
• SBI情報
  →フィードバックするときの伝える情報
  　S：シチュエーション（どのような状況で、どんな状況のときに）
  　B：ビヘイビア（部下のどんな振る舞い・行動が）
  　I：インパクト（周囲やその仕事に対して、どんな影響をもたらしたのか。）

スキルはこれ以外にもまだまだありそうです。丸暗記することは厳しいと思うので使いながら慣れていくのが良さそうです。単語を知っていると調べられるのでそういった点でまとめておくと良いです。

質問リスト

質問リストを作っておくと1on1の質が安定すると思います。このリストをそのまま使ってもいいですが、相手の状況に合わせてアレンジしていきたいです。

信頼関係の構築

• 最近、嬉しかったことはなんですか？
• 最近、始めたことはありますか？
• 最近、お勧めしたいことはありますか？
• 自分に影響を与えた人っていますか？
• 尊敬する人はどんな人ですか？

成長支援

(言語化を促す)

• 〇〇がうまくいっていたように見えますが、自分なりに良かった行動はありますか？
• 思わず夢中になってしまうことは何ですか？
• 今の役割で成長してる実感はありますか？
• 楽しい仕事、楽しくない仕事を1つずつ上げると何ですか？
• 最近、うまくできたと思う仕事は何ですか？

(チャレンジを促す)

• 1年後、3年後、5年後どうなっていたいですか？
• もっと時間を使いたいことはありますか？
• 理想のあなたが今の自分に声をかけるならどんなことを良いそうですか？
• 組織の目標でワクワクすることはありますか？
• あなたがリーダーなら、何を変えたいと思いますか？

課題の確認と支援

• 些細なことでも困っていることや不安はありますか？
• ほかのメンバーと仕事をする上で、気になること・不安・心配事はありますか？
• 組織の目標や方針に疑問はありませんか？
• 私たちは正しいことに取り組んでいると思いますか？
• 今は100点満点のうち何点ですか？

リーダーへのフィードバック

• 私にやめてほしい/続けてほしいことはありますか？
• 私にできることはありますか？

関連記事

iucstscui.hatenablog.com iucstscui.hatenablog.com iucstscui.hatenablog.com iucstscui.hatenablog.com iucstscui.hatenablog.com iucstscui.hatenablog.com

Agile Lounge #1「大規模アジャイル開発を神話にしない戦略会議」に参加しました

Agile Lounge #1「大規模アジャイル開発を神話にしない戦略会議」に参加しました。

forkwell.connpass.com

本イベントは「ユニコーン企業のひみつ」を翻訳された角谷さん と、「ユニコーン企業のひみつ」を実践されているラクスル株式会社の高橋さんが登壇されました。角谷さんの理論編と高橋さんの実践編という形で面白かったです。本イベントはYouTubeのアーカイブが残っています。connpassに該当チャンネルへのリンクがはられていますので、イベントの内容はそちらをご覧いただければと思います。

スライドも公開されています！ありがたいですね。

スライド

『ユニコーン企業のひみつ』とスケーリングの考えかた

実践編: ユニコーン企業のひみつ

イベントでの気づき

このブログでは参加して特に気づきがあったことを残しておきます。

文化は変えられない。でも、行動を変えることで文化が変わる。

アジャイルをスケールさせるためのベースは良い文化だと紹介がありました。でも、文化というのはそこに属する人々の行動や考えや価値観から作られる結果であり無形のもの、なので、文化は変えようとしても変えられません。だから、理想の文化を作るには「そこに属する一人一人の行動や考えや価値観」が重要ですというお話でした。

文化はシステムとして考えられますね。システム思考のシステムです。システムは要素の繋がりによって生まれます。文化も人の繋がりで生まれます。システムや文化そのものには実態がありません。なのでシステムそのものにアプローチしようとしても手応えはないでしょう。システムを変えるにはフィードバックループです。期待する行動、変えたい行動を強めたり弱めたりするフィードバックによって行動が変わり文化が変わると気付きました。また、組織に対してリーダーシップを取る人たちが率先して目指す文化に沿った行動することで一人一人の行動が少しずつ変わり、文化が変わるのだと思いました。

よく耳にする山本五十六さんの格言が沁みますね。部下の育成で良く聞きますが、組織文化を作る時も同じく大切です。
「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。やっている、姿を感謝で見守って、信頼せねば、人は実らず。」

チームや個人を成長させるミッションコマンド方式

良い文化のままスケーリングする行動の一つとして、「ミッションコマンド方式で仕事を定義する」と紹介がありました。これは「最終状態、目的、最小限の制約」を定義するということです。

良さそうですよね。意識できていることもありますし、できてないこともありました。まず、意識できていたことは「目的」を伝えるです。僕は「目的」に合わせて「背景や経緯」も伝えることが多いです。「背景や経緯」があると目的の納得度が高まると思っています。あと2つは上手くできてません。。。「最終状態」はプロダクトバックログでいう受け入れ基準に近そうですね。あと「最小限の制約」も意識できてなかったです。「最小限の制約」とは例えば予算です。〇〇円まではあなたの権限で使っても良いよってことです。開発だと何でしょうか。スケジュール、設計、実装、言語、仕様など色々ありそうですね。

「ミッションコマンド方式で仕事を定義する」について似た話を思い出しました。Nstock と SmartHR の創業者である宮田さんが書かれた「権限移譲する技術」というブログです。その中に「ToDoではなくイシューを渡す」と書かれていました。また、10XのYamottyさんのZero TopicというPodcastの「#How to delegate」でもイシューを渡すお話をされていました。「イシューを渡す」と「ミッションコマンド方式で仕事を定義する」はどちらもゴールを明確にして、Howは任せるという共通点があります。

チームや個人を成長させるという意味でも「ミッションコマンド方式(最終状態、目的、最小限の制約)」「イシューを渡す」を意識していきます。

blog.shojimiyata.com

open.spotify.com

アジャイルをスケールさせるコツは小さく、小さく、小さく。

お二人の登壇後のQ＆Aコーナーで複数登場した回答があります。それは「スケールさせるには小さくする」ことです。一見矛盾するような回答ですが、全体を見たら大規模だけども1チームで見たら小さくすることだと話されていました。スクラムをスケールさせるときも出来るだけスケールさせないこと、スケールさせる場合は良いチームを作ってからにすることをよく聞きます。

規模が大きくなると調整コストは増えます。開発の難易度も上がります。なので規模は大きくしつつも、チームごとの人数や関りは最小限になるように考えた方が良いですね。粒度に答えはありませんが目安として、チーム内の主要な人の手が回る範囲に抑えるのがコツと話されていました。また、開発チームとは別にサポートチームを作るのも一つのTipsだと紹介がありました。ラクスルの高橋さんも「Management Team/CTO Office」というチームを作られていました。

組織としてはスケールさせつつも一人一人の認知負荷を下げる仕組みの検討はしたほうが良さそうだと感じました。

まとめ

Agile Lounge #1「大規模アジャイル開発を神話にしない戦略会議」に参加しました。とても満足できるイベントでした。ミッションコマンド方式はすぐにでも使える技術なのでさっそく役立てていきます。運営の皆さま、参加者の皆さま、ありがとうございました！

参考記事

登壇に関連のある記事などをまとめておきます。
iucstscui.hatenablog.com

techblog.cartaholdings.co.jp

note.com

workstyle.ricoh.co.jp

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計

１分で話せ　世界のトップが絶賛した大事なことだけシンプルに伝える技術