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

forkwell.connpass.com

会の概要

以下、connpassのイベントページから引用です。

特にスタートアップやWeb系企業におけるソフトウェア開発で前提とさえなっている「アジャイル開発」。 この開発手法は多くの開発組織で取り入れられ、実践されています。しかし、その一方で他の開発手法と比較すると人間のコミュニケーション能力に依存している側面が多く、人員が増え、コミュニケーションコストが加速度的に高くなる大規模開発での実践は難しいともされています。

今回は昨年4月に発行された「ユニコーン企業のひみつ～Spotifyで学んだソフトウェアづくりと働き～」や「Clean Agile～基本に立ち戻れ～」の翻訳も手掛けられた角谷 信太郎氏をお招きし、アジャイルの基本に立ち返ると共に成長する企業においてスケールするアジャイルについてもお伺いしていきます。

会の内容

タイムテーブルの前から順に、会で話されていた内容を書いていきます。

「『ユニコーン企業のひみつ』とスケーリングの考えかた 」～角谷 信太郎さん～

アジャイルのスケールが難しいわけではない

アジャイルのスケールが難しいと言われているけれども、スケール自体は難しくないし、アジャイルのスケールが難しいのではなく人間がたくさんいるのが難しいのではないか、という話が導入としてありました。

大事にしたい(スケーリングしたい)事柄

アジャイル開発宣言と同じ形式(左の事柄よりも右側の事柄に価値がある)で、大事にしたい事柄が挙げられていました。

• プロジェクトよりもプロダクトを
• アウトプットよりもアウトカムを
• リソース効率よりもフロー効率を
• 効率よりも効果を
• 予測より適応を
• コマンド&コントロールよりもミッションコマンドを

組織文化を変える

スケールするかは組織文化によって決まるので組織文化を変えましょうとよく言われるが、文化というものは捉えにくいものだし、これまでの過程の積み重ねで形成されるもので一朝一夕で変わるものではないという話がありました。

この話で終わってしまうと、じゃあもう組織文化がいい所に転職するしかないのでは？自社で文化を変えることはできないのでは？となってしまうのですが、「理想的な(スケールさせたい)文化で起こるようなふるまいを積み重ねていくことで、文化を変えることが結果的にできる」とリーンエンタープライズにはあり、これをヒントに考えると、「価値のストリームにアラインされたフルサイクルチーム」を増やそうと行動していくことが重要だと角谷さんは考えているそうです。

価値のストリームにアラインされたフルサイクルチーム

チームが自律しており、開発～運用保守を一貫して担当することができて、継続的にテスト(メンテナンス)し続けることができるチームのことを指しているということです。

言葉の詳細な参照はチームトポロジーやフルサイクル開発者チームの話、ホリスティック・テストを確認して欲しいということです。

スケーリングのために"行動"を変える指針の指針

以下の4つの指針が挙げられていました。

1. 自律・熟達・目的(モチベーション3.0にも記載がある通り、内発的動機づけを大切にする)
2. チームファースト(ソフトウェアデリバリーにおける最も効果的な手段はチームであるという考え方)
3. フォーカスの定まったゴールと定まったゴールへのアラインメント(川を渡りたいことだけを伝える、川を渡りたいから橋を作ってくれとは伝えない)
4. 技術的卓越の追求(継続的に学び続ける。高い内部品質があってこそ高速にシステム開発を進めることができる)

具体的な行動例

これらの指針を踏まえて、どのような行動を具体的にするといいのか、というのが最後に紹介されていました。

• ミッションコマンド方式で仕事を定義する(意志決定を部下に任せる)
• "修理技術"の研鑽(技術力を定期的に磨き続ける)
• 1on1ミーティング(チームが重要といっても個人をないがしろにしていいわけではない。個人の想いを汲み取る1on1ミーティングを定期的に行うことが重要)

「実践編：ユニコーン企業のひみつ」～ラクスル株式会社 ラクスル事業本部 VPoE 高橋 一貴さん～

続いて高橋さんから、ラクスルでは実際にどのようにユニコーン企業のひみつを実践しているのか、ラクスルではどのような開発体制を築いているのか、という話を聴いていきました。

スクワッド(スクラムチーム)の構成

自律した少数チーム(5-6名)を形成しているということです。
チームはデリバリまでの権限と責務を持ち、技術面についてはTech leadと呼ばれる役割を持ったエンジニアが技術面の意志決定権を持つということでした。

チームにはPOがいて、デザイナーは組織横断で存在しているということです。

スクワッド(スクラムチーム)とマネジメントライン

フロントエンドとサーバーサイドでマネージャーは分かれており、マネージャーとメンバーの1on1を通して個人個人の想いを汲み取り、チームの異動や成長機会の提供を適宜行っているということです。

EMもいますが、ユニコーン企業のひみつで言う「ボスであってボスでない」状態を体現しているというお話がありました。

チーム組成

コンウェイの法則を参考に、疎結合なチーム構成を目指しているということです。

グローバルチームが存在し、ドキュメントは全て英語が基本ということですが、DeepLを使うことでネイティブでないメンバーも対応しているということでした。

一人で悩まない環境づくり

開発のロードマップや優先順位はPdMやエンジニア...多種多様な役割を持った人たちが全員で話し合って決めているということでした。
また、ペアプロ/モブプロを導入し、オンボーディングや意思決定スピードの向上を図っているということでした。

ユニコーン企業のひみつの内容を体現しているカルチャー

フィーカ(チーム単位のコーヒーブレイク)

ドリンクを飲みながら、リラックスしたムードでふりかえりをチーム単位で行っているということです。

ハックウィーク

1年に1回1週間好きなことをやっていい期間を取っているということです。実際に数理最適化を用いたシステムのリリースなど、ビジネスの利益に繋がるような事例もあるということです。

技術に明るいPO

PdMやPOはエンジニア出身であることがほとんどということで、技術的な話題にも問題なく対応できるということです。

分離されたアーキテクチャ

開発スピードの減退が顕著になりつつあったこともあり、モノリスなアーキテクチャは分離をする取り組みを数年単位で進めているということです。

短距離走ではなくマラソン

チームの持続可能性を維持するために、チームが疲弊しないような工夫をしているということでした。(エンジニアが疲弊しがちなスケジュール遅延は原則的にスケジュールを再調整することで対処するということです)

ユニコーン企業のひみつの内容を体現できていないカルチャー

プロジェクトではなくチームに投資

まだプロジェクトのためにチームを作ることが実態としてはあるというお話でした。

ミッションで目的を与える

ユニコーン企業のひみつで書かれているような、メンバーがわくわくするミッションはまだ形として与えられていないということでした。

トライブ

現在既にトライブを作る議論を始めているようですが、メンバーの人数増加に伴い、認知負荷が高い状態になりつつあるということです。

カンパニーベット

DIBBに準ずる考え方はできているものの、全体にまたがるようなリストは組織で持っていないということでした。

今後高橋さんがやりたいこと

高橋さん個人の想いとしては、スクラムを超えていきたいということです。
具体的には、OSS開発のような、人が個人の興味で集まり、その興味から凄いプロダクトができるような姿を目指しているということでした。

パネルディスカッション

スクラムに取り組んでいますが、プランニング段階での仕様・設計の粒度について悩んでいます。角谷さん講演の『予測よりも適応』というトピックがありましたが、手戻り・負債を減らすために事前に決めておく項目を明文化したいと思っています。

タスクを小さくするのが腕の見せ所だとお話がありました。
また、気が熟していない時に慌てて開発するエンジニアが多い印象もある*1ので、今がソースコードを書くタイミングなのかは意識してあげるといいのではないか？というお話でした。

大規模開発にどのようにアジャイルを適用しているかをお聞きたいです。

(逆説的な回答で申し訳ないという前提はありつつ)いかに規模を小さくしていくのか、主要な人の手が回らなくなっている所を分解して負荷を減らしてあげるか、というのを考えるようにしているということです。

大規模化してもPOの認知負荷を抑える、サポートする方法を知りたいです。

オブジェクト指向設計でいう凝集性を高めるような取り組みをする、要するに小さくすることが重要だというお話でした。
また、PO室やCTO室など、認知負荷が高くなりがちな人をサポートするロールを置くことが重要だというアドバイスもありました。

ユーザー側をアジャイル開発に巻き込む、活動を理解してもらう、時間をとってもらうことが難しい。なにか打開策はあるでしょうか。

ラクスではプロダクトに対する理解が強い人がビジネスメンバーとなっていることが多いため、そこまで難しい実感がないというお話がまず高橋さんからお話がありました。
その上で、もし現状難しいと感じるのであれば、論理的に正しさを突き付けるのではなく、相手の感情を汲み取って仲良くしていくことや相手の不安に寄り添って実際に現場に巻き込んでいくことが重要だというお話がありました。

角谷さんからは、角谷さんの講演でもあったように文化を変えるのは難しいという前提はありつつ、文化が変わった後の行動を現在自分が抱えている制約の範囲内でどのように行うか？というのを考えたり、そもそも本当にその前提は正しいの？ということを考える必要があるというお話がありました。(最終的にはコミュニケーションを継続的に取り続けるのが重要ということでした)

ユニコーン企業のひみつの中では、会社が注力すべき領域を定める際にDIBBを基準としてカンパニーベットする話がありました。このような基準で評価するために、揃えるべき情報の粒度の設定が難しいと感じています。注力するかどうかを決める時に、どこまで事前調査をして比較しているでしょうか。

こちらは、揃えるべき情報の粒度をなぜ揃えないといけないのかが分からないと答えにくい質問だということでした。
分析麻痺に陥っている感覚も質問からは見受けられるため、行動に繋がるデータをDIBBを使う際は意識した方がいいということでした。

今いる人が試行錯誤で文化を熟成するのか、文化に人が集まって人を育てるのかどちらでしょうか。

文化は結果なので、まずは今いる人が作っているはずだということでした。ただし、そうして作られた文化に人が集まって、更に文化を形成していくので、どちらが大事というよりは相互参照的なものだということでした。

よくマネージャー層からは仲良くなる、人間力というところを強調しますが、メンバー層は仲良くなるためにコミュニケーションを取るより仕組み・フォーマット・システム化したがる傾向を感じます。人間力の大事さをメンバー層にどう落とせばいいでしょうか？

やはり対話をしていくしかないということでした。
また、効率を求めることを追求して形から入ったり、フォーマットやシステム化を進め過ぎない方がいいという意見が角谷さんから出ていました。

全体を通した感想

実は初めて角谷さんの話を今回聴いたのですが、文献を幾つも引用しつつも率直に角谷さんが考えていることを伝えてくれる感じに引き込まれて、元気がもらえるようなお話でした。

実際にユニコーン企業のひみつで書かれている内容をどう実践しているかという点で高橋さんの話も興味深くて学びが多かったですし、ラクスルの開発体制や開発メンバーについてちょっと誇らしそうに語る高橋さんの様子は見ていてなんだか幸せになりました。

充実した2時間でとっても楽しかったです！

*1:エンジニアは開発をしてバリューを出すことに意識を強く持つ傾向が強い