Agile Lounge #1「大規模アジャイル開発を神話にしない戦略会議」に参加しました。
本イベントは「ユニコーン企業のひみつ」を翻訳された角谷さん と、「ユニコーン企業のひみつ」を実践されているラクスル株式会社の高橋さんが登壇されました。角谷さんの理論編と高橋さんの実践編という形で面白かったです。本イベントはYouTubeのアーカイブが残っています。connpassに該当チャンネルへのリンクがはられていますので、イベントの内容はそちらをご覧いただければと思います。
スライドも公開されています！ありがたいですね。
イベントでの気づき
このブログでは参加して特に気づきがあったことを残しておきます。
文化は変えられない。でも、行動を変えることで文化が変わる。
アジャイルをスケールさせるためのベースは良い文化だと紹介がありました。でも、文化というのはそこに属する人々の行動や考えや価値観から作られる結果であり無形のもの、なので、文化は変えようとしても変えられません。だから、理想の文化を作るには「そこに属する一人一人の行動や考えや価値観」が重要ですというお話でした。
文化はシステムとして考えられますね。システム思考のシステムです。システムは要素の繋がりによって生まれます。文化も人の繋がりで生まれます。システムや文化そのものには実態がありません。なのでシステムそのものにアプローチしようとしても手応えはないでしょう。システムを変えるにはフィードバックループです。期待する行動、変えたい行動を強めたり弱めたりするフィードバックによって行動が変わり文化が変わると気付きました。また、組織に対してリーダーシップを取る人たちが率先して目指す文化に沿った行動することで一人一人の行動が少しずつ変わり、文化が変わるのだと思いました。
よく耳にする山本五十六さんの格言が沁みますね。部下の育成で良く聞きますが、組織文化を作る時も同じく大切です。
「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。やっている、姿を感謝で見守って、信頼せねば、人は実らず。」
チームや個人を成長させるミッションコマンド方式
良い文化のままスケーリングする行動の一つとして、「ミッションコマンド方式で仕事を定義する」と紹介がありました。これは「最終状態、目的、最小限の制約」を定義するということです。
良さそうですよね。意識できていることもありますし、できてないこともありました。まず、意識できていたことは「目的」を伝えるです。僕は「目的」に合わせて「背景や経緯」も伝えることが多いです。「背景や経緯」があると目的の納得度が高まると思っています。あと2つは上手くできてません。。。「最終状態」はプロダクトバックログでいう受け入れ基準に近そうですね。あと「最小限の制約」も意識できてなかったです。「最小限の制約」とは例えば予算です。〇〇円まではあなたの権限で使っても良いよってことです。開発だと何でしょうか。スケジュール、設計、実装、言語、仕様など色々ありそうですね。
「ミッションコマンド方式で仕事を定義する」について似た話を思い出しました。Nstock と SmartHR の創業者である宮田さんが書かれた「権限移譲する技術」というブログです。その中に「ToDoではなくイシューを渡す」と書かれていました。また、10XのYamottyさんのZero TopicというPodcastの「#How to delegate」でもイシューを渡すお話をされていました。「イシューを渡す」と「ミッションコマンド方式で仕事を定義する」はどちらもゴールを明確にして、Howは任せるという共通点があります。
チームや個人を成長させるという意味でも「ミッションコマンド方式(最終状態、目的、最小限の制約)」「イシューを渡す」を意識していきます。
アジャイルをスケールさせるコツは小さく、小さく、小さく。
お二人の登壇後のQ＆Aコーナーで複数登場した回答があります。それは「スケールさせるには小さくする」ことです。一見矛盾するような回答ですが、全体を見たら大規模だけども1チームで見たら小さくすることだと話されていました。スクラムをスケールさせるときも出来るだけスケールさせないこと、スケールさせる場合は良いチームを作ってからにすることをよく聞きます。
規模が大きくなると調整コストは増えます。開発の難易度も上がります。なので規模は大きくしつつも、チームごとの人数や関りは最小限になるように考えた方が良いですね。粒度に答えはありませんが目安として、チーム内の主要な人の手が回る範囲に抑えるのがコツと話されていました。また、開発チームとは別にサポートチームを作るのも一つのTipsだと紹介がありました。ラクスルの高橋さんも「Management Team/CTO Office」というチームを作られていました。
組織としてはスケールさせつつも一人一人の認知負荷を下げる仕組みの検討はしたほうが良さそうだと感じました。
