こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
「アジャイル開発は企業で実際にどう生かされているか」の具体例を知りたい皆さまに向けて、Speee社、アルダグラム社、Tebikiの3社のエンジニアが登壇して各社の取り組みを紹介します！特別ゲストに「アジャイル開発にくわしい」角谷さん(@kakutani)をお迎えし、それぞれの企業が技術面や組織面で「アジャイル」をどのように取り入れているのか、そこで発生している今後の課題などを一緒に考えます。会場からのご質問にもどんどんお答えします。ぜひ、皆さまのご参加お待ちしております！
会の様子
Speeeさんの発表
セッション
スクラムをしばらく進めて*1いく中で、ある程度チームとしての練度が高まってきた中で生まれた課題感*2に対してどのように対応していったのか？というお話を聞いていきました。
Speeeさんでは、より長い時間の事業目標に対して、「プロダクトがどういった状態だと目標を達成できたと言えそうか？」を明確にするためにプロダクトロードマップを描いたということで、エンジニアがPOや事業責任者と同じ視座で開発できるようにしているということです。
このプロダクトロードマップはまだ作りたてではあるものの、今のチーム/アーキテクチャで達成可能か？や技術的に障害となるポイントが、より解像度高く分かるようになることを目指しているというお話でした。
SpeeeさんからのQ&A
Q&Aでは、最初に「時間軸が伸びれば伸びるほど実現するかどうかの不確実性が上がっていくと思うが、どこまで未来を見据えておけばいいのか？」という質問がありました。(もちろん状況によるだろうという前提)
角谷さんからは、発表の中であったプロダクトロードマップでは、1年を一つの区切りとして置いていましたが、この期間はいい感じ(よくある話)じゃないかという話がありました。
大事なのは、こういった期間を決めてロードマップ上で想定できていなかった部分が出てきたときにどう対応をしていくとよいのか？という話で、ここの部分をチームメンバー全員で話し合っていくのが重要だということです。
次に、「サービスとしては同じだが、toC/toB側に向けて開発として追う目標が異なるが、チームを分けるわけないの判断ってどういう軸ですると良いのか？」という質問がありました。
角谷さんは、チームトポロジーを参考にするのが良いんじゃないかということで、チームの認知負荷が高いかどうか？やMTGで地蔵みたいな人が増えていないか？という観点で、チームのメンバーに聞くことが大切だと考えているそうです。
また、分けることは簡単だけれど分けた後が大変になってくるので、メインターゲットとなるユーザーを見続けること(チームの構造に目を向けすぎないこと)が大切だということでした。
視聴者や角谷さんからのQ&A
「ここまで想定されていて、実際にどれくらい開発ロードマップに影響をあたえられているのか？」という質問がありました。
現在はまだ実施し始めたばかりのフェーズだということですが、プロダクトロードマップを作ったことで技術的負債の解消をどうしていくかの戦略が決めやすくなり、技術者の説明責任をはたしやすくなったということです。
また、「PdMやPOとの関係性やコミュニケーション頻度は？」という質問が角谷さんからありました。
これは、スプリント単位(毎週)では会話をしている+プロダクトロードマップを考えるタイミングでは密にがっと数日集まるようにしている、ということでした。
アルダグラムさんの発表
セッション
開発チームの人数が増えてきた中で、組織と技術の両面で対応を進めているお話を聞いていきました。
具体的には、組織面での対策として
- チームを分割
- Design Docで全チームがプロジェクト内容を把握できるようにする
- PdMとの連携を増やして仕様を決めるところからエンジニアが参加する
ということをしていて、技術面では
- デプロイフローを4 keysで改善
- デプロイ回数の増大
に取り組んでいるということでした。
ただし、こういった取り組みを進めていく中でエンジニアが仕様を決めるようになった結果、コミュニケーションコストが非常に高くなる場面が出てきたそうで、このあたりは今後の課題として考えているということでした。
アルダグラムさんからのQ&A
「プランニングで仕様やタスクをどこまで詰めるべきかが難しい」という質問がありました。
角谷さんからは「近い未来に関しては詳細に/遠い未来に関してはざっくりと」決めておくことがいいよね、という話があり、事前に詳細に詰めないことで議論が空中戦になってしまうような場合は詳細度高くゴールの設定をするポイントをより近く持ってくるといいのではないか？ということでした。(1年のゴールに同意できているのであれば、半年のゴールや状態を合意してみる...)
次に、「設計に関する問題は一人でゆっくりと考えたくなるのだが、どこまで一人でじっくり考える時間を取っていいのか？」という話がありました。
角谷さんは、リーン製品開発のラストレスポンシブルモーメントの考え方が参考になるんじゃないか？ということで、技術的意思決定ができる一番遅い地点から逆算して考えてみるとよいのでは？ということでした。
視聴者や角谷さんからのQ&A
「スクラムイベントにステークホルダー(利益を受け取る人)がいないように見受けられたのだがこれはなんでか？」という話がありました。
これは、
- 価値を届けるユーザーの距離がもともと遠くて段階的にスクラムへ移行をしていること
- 今はPdMがユーザーから要望を吸収して、開発者に伝えられていること(直近はエンジニアがユーザーヒアリングに同行する場面もあり)
が理由だということでした。
また、「(スクラムマスターがいないなどという理由から)スクラムのプラクティスを取り入れている状態でスクラムはやっていないんですね」という質問も出ていました。
これは、
の2つが理由だということでした。
Tebikiさんの発表
セッション
最後にTebikiさんの発表を聞いていきました。
Tebikiさんでは、ユーザーに早く価値を届けるために、モブ開発/トランクベース開発/Feature Togglesなどを活用してフロー効率の向上に目を向けているそうで、4 keysを活用しながら実際にリリース速度を早めることを検討し、実際にサイクルタイムを早めることもできているというお話でした。
ただ、大きいバックログになるとsprint単位で開発するのが難しかったり、ユーザーの反応を得る速度がサイクルタイムに比べて遅いといった悩みはあるということです。
アルダグラムさんからのQ&A
まず、「大きめのEpicの際にリリースまで数スプリントかかることがある」という質問がありました。
角谷さんからは、開発が上手になるしかないという元も子もない話はありつつ、まずはshippableな状態(=リリースしろと言われればいつでもリリースしますよ)にしていくことが重要だというお話がありました。
また、短くすればするほどいいようなものでもないので、とにかく期間を短くすることだけにフォーカスするのではなく、ユーザーに見てもらうことすらできないような状態にしないことを考えておくのがよいのでは？ということでした。
次に、「ユーザーの反応を得る速度がサイクルタイムに比べて遅いがどうしたらいいのか？」という話がありました。
こちらは、割とどうしようもない部分もあるし、ユーザーの反応を得た後にいかに早く変化に適応していくかが重要なのでは？ということでした。
最後に、「1sprintに満たないサイズのEpicの際にはスプリントゴールをどう設定するのか？」という話がありました。
これは、チェックリストにならないように、なぜこのPBIを選んでいるんだっけ？というのを書くことや、MECE的な感じで目標を漏れなくダブりなく分解しようとしないように気をつけることが重要だというお話がありました。
全体的に、Googleとかで調べて簡単に答えが出るような話ではChatGPTだってできてしまうし、苦心しながら考えるのは当然なのでは？ということでした笑
視聴者や角谷さんからのQ&A
時間の関係で、TebikiさんのTwitterで回答を発信するということでした。
おまけ〜アジャイルってなんだっけ？〜
会の本題である「アジャイルってなんだっけ？」からずれていないか？という質問に対して、角谷さんが答えてくれました。
角谷さん的には、それぞれがそれぞれのペースでアジャイルを実践しようとしている取り組みの事例を聞くことができたので、会の本題からずれていたようには感じなかったということです。
全体を通した感想
それぞれの現場の事例を聞くことができた上で、実際に角谷さんがどのようにコメントをしてくのか？を見ることができて学びが多かったです。
Twitterのタイムラインも大盛りあがりで、楽しいイベントでした。
