「外部組織による不確実性の対処は？」「バッチサイズ分割の基準は？」　アジャイル開発現場の不確実性に対してのQ＆A

タスクの分解をする上で難しかった経験

植田隼人氏（以下、植田）：炭田さん、ありがとうございます。すごくわかりやすい登壇というか、スライドでしたね。不確実性のパターンをパターン化されていましたし、バッチサイズを小さくしましょうというところも、具体的かつ実践的ですごくわかりやすいと思ってお話を聞いていました。

ではみなさん、登壇の中身で気になったことや聞いてみたいこと、疑問に思ったことがあれば質問してもらえたらうれしいです。

「タスクの分解をする上で難しかった経験はありますか？」という質問をいただいています。どうもありがとうございます。

炭田高輝氏（以下、炭田）：そうですね。やはり最初に慣れるまでは難しいかなと思っています。ユーザーストーリーと一言で言っても、どういう観点で（見るか）。例えば切る前に技術的な調査が必要だったり、けっこう複雑な要素をひもといていく場合があったりするので、技術的な制約やリリースタイミングなどを鑑みてタスク分割する時は、難易度が上がるという感じがします。

植田：なるほど。ありがとうございます。ちょっと付け足しになってしまいますが、僕からも1つ聞いていいですか。うまくタスク分割したり、バッチサイズを小さくすることは、誰がやるのかと言ったら変ですが、いわゆるスクラムマスターとか開発メンバーとかPO（Product Owner）とかいろいろあると思いますが、どんな人が集まってやるものなんですか？

炭田：おすすめ（の方法）として、できればステークホルダーも含めて全員でやるのがいいかなと思っています。ユーザーストーリーの良い点の1つは、技術的な細かいところにとらわれずに、全員がユーザー視点でものを考えることができることだと思っています。

例えば、バックエンドのAPIの開発をするとなったら、フロントエンドのエンジニアの人は一歩引いちゃうじゃないですか。そうやって分けていくと、どんどんタスクが人に紐づき、サイロ化が進んでいくと思っています。

そのため、できるだけユーザー視点で、誰もが同じ目線で語れるユーザーストーリーで、チーム全員で分割していくのがいいんじゃないかと僕は思っています。

植田：なるほど、ありがとうございます。特定のロールの人とか、「これはこの人の責任」ということではなくて、みんなでフラットにやるのがいいということですね。「タスクの分割をする上で難しかったなという経験はありますか？」という質問でした。

バッチサイズの基準

植田：ほかにも質問が来ているので取り上げます。「バッチサイズが大きいから小さくしないといけないと判断する基準などありますか？」という質問です。どうもありがとうございます。

炭田：ありがとうございます。そうですね。スクラムとかアジャイル開発でいくと、よくイテレーションやスプリントと言ったりしますが、1週間や2週間という範囲の中で、タイムボックスを決めて収まる範囲で開発するかたちを取ることが多い。そのスプリントの中にちゃんと収まるかが1つの判断基準になると思います。

あとはやはり、先ほどの氷山の一角ではないですが、できるだけ小さくしたほうが不確実性は扱いやすくなるので、自分のチームの場合は、だいたい1日から2日くらいでデプロイまで行けるようなユーザーストーリーに区切って開発を進めていることが多いです。

植田：なるほど。1日か2日くらい。

炭田：はい。そのあたりはチームや実際の開発対象にもよると思いますが、可能な限り小さくしていく。そこにコストを使っても十分ペイできると個人的には思っています。

植田：そうですね、1日から2日くらいだとだいぶ見とおしが立ちやすいというか。

炭田：はい。

植田：サイズということなんですね。なるほど、ありがとうございます。「バッチサイズが大きいから小さくしないといけないと判断する基準などはありますか？」という質問でした。どうもありがとうございました。

外部組織に引っ張られる不確実性はどう対処するべきか

植田：なにか不明点があれば、追加の質問をいただけたらうれしいです。たくさんいただいていますね。ありがとうございます。ヤマモトさまから「社内＆チームでコントロールできない外部組織に引っ張られる不確実性についてアドバイスありますか？」という質問をいただきました。ありがとうございます。

炭田：ありがとうございます。いやあ、難しい質問ですね（笑）。そこは外部組織に引っ張られたりチーム外でコントロールできない。僕はよく「現実は変わらない」と言いますが、それを正しく捉えて「じゃあどうするか」をチームで話していくしかないと思っています。

よくある、外部組織の依存関係みたいなものに対してどうするかという話は、参考文献にあげていた『大規模スクラム（LeSS）』にけっこう載っていたり、Tipsみたいなのに載っていたりするので、機会があればそちらを参考にしてもらえるといいかなと思っています。

一例を挙げると、もうできるだけチームでやり切って、後はレビューしてもらうだけという。できるだけチームの扱う範囲を広くしていって、依存関係を飲み込んで、あとは向こうが判断するだけみたい（な状況）にするのが、チームの能力もどんどん上がるので、僕はおすすめだと思っています。

植田：ありがとうございます。「外部組織に引っ張られる不確実性についてアドバイスありますか？」という質問でした。

本発表の参考になった本・資料

植田：たくさん来ています。大変ありがたいですね。もう1ついきましょうか。ヨウヘイさまから「今回の発表は、基本は実務上の経験を基に作成されていると思いますが、それとは別に、なにか参考になった本や資料などあったりしますか？」という質問をいただきました。どうもありがとうございます。

炭田：ありがとうございます。そうですね。今スライドに映しているものが、僕が読んだ中ではよかった、参考になったというものです。特に『More Effective Agile』や『エッセンシャルスクラム』なんかはすごく詳しく載っているので、そちらを参考にしていただけるといいのかなと。

あとは、ryuzeeさんのブログの「プロダクトバックログアイテムの分割方法」はすごく実践的で参考になると思います。

植田：「なにか参考になった本や資料などありますか？」という質問でした。どうもありがとうございます。

炭田：ありがとうございます。

組織のエンジニアのスキルを上げるための工夫

植田：さらにサカモトさまより質問をいただいています。「開発担当者のナレッジに差がある場合、ユーザーストーリーで区切ると成果物に差が出てきてしまう感じがあるのですが、組織のエンジニアのスキルを上げるために工夫されていることなどありますか？」です。ありがとうございます。

炭田：ありがとうございます。まず前提として、僕がすごく大事なことだなと思っているのは、全員でユーザーストーリーを区切っていくことです。そうすることで、みんなの頭の中が同じ視点になっていくと思うので、その部分で成果物の差みたいなものは吸収していったほうがいいのかなと個人的に思っています。

組織のエンジニアリングスキルの話では、やはり技術的プラクティス、TDDや設計。あとは、ペアプロやモブプロなど。そのあたりは、今日パネラーで登壇予定の弊社の櫛引（櫛引実秀氏）が自分のチームで推進してくれていました。

そういった、一般的にアジャイルやスクラム、XPなどで推奨されているような技術的なプラクティスは、どんどん取り入れて取り組んでいけばいいんじゃないかなと思っています。

植田：ありがとうございます。「開発担当者のナレッジに差がある場合、ユーザーストーリーで区切ると成果物に差が出てきてしまう感じがあるのですが、組織のエンジニアのスキルを上げるために工夫されていることなどありますか？」という質問でした。どうもありがとうございました。

コードのコンフリクトやコミュニケーション増加を防ぐ方法

植田：さらに「1つのストーリーをチームみんなでこなそうとすると、例えば1つの機能を複数人で開発する場面が出てきて、コードのコンフリクトやコミュニケーション増加などで非効率になる場合があるかと思いますが、なにか対策などありますか？」という質問をいただきました。どうもありがとうございます。

炭田：ありがとうございます。これもタフな質問ですね（笑）。私はスクラムマスター、エンジニアリングマネージャーとして関わっていることが多いので、日々そんなにがっちり開発することはありません。ただ、やはりアーキテクチャやコンフリクトは重要かなと思っています。あとは、ぜひここは櫛引さんにも登場していただきたいんですが。

植田：櫛引さん、呼ばれたのでお願いします。

櫛引実秀氏（以下、櫛引）：ご紹介にあずかりました櫛引です。このコミュニケーションコストとコードのコンフリクトなどは、ペアプロ、モブプロと、同期レビューによって解消しています。トランクベースの開発というDevOpsのプラクティスがありますが、その中でペアプロ、モブプロをすることによって、まずコミュニケーションコストが減ります。

コードのコンフリクトも、トランクベース開発ではすぐにトランクにマージするようにするのがいいとされているので、先に小さい単位でマージして、次にコードレビューでの指摘事項の対応やリファクタをしようとなったら、また新しいブランチを切って、1日か2日でまたマージするというように対応していました。

そうすると、コードのコンフリクトもぜんぜん起きなくて、非同期ではなく同期レビューで「ちょっと見てください、お願いします」と言ってZoomをつないで見てもらって、質問があったらすぐ答える。レビューの指摘があったらすぐ対応するということです。

マージ待ちやレビュー待ちをなくすことができて、すぐトランクにマージして、コンフリクトが起きない。コミュニケーションコストも全体的には減っているというやり方でやっていました。なので、ペアプロ、モブプロと同期レビューが基本になると思います。

炭田：ありがとうございます。

植田：ありがとうございます。ペアで回答していただきました。あらためて、今いただいたのが「1つのストーリーをチームで、みんなでこなそうとすると、例えば1つの機能を複数人で開発する場面が出てきて、コードのコンフリクトやコミュニケーション増加などで非効率になる場合があるかと思いますが、なにか対策などありますか？」という質問でした。

植田：たくさん質問をいただいて、大変ありがたいです。うれしいです。

炭田：そうですね。

植田：0件だったらどうしようかなと思ったんですが、たくさんいただいたので、本当にもうお腹いっぱいです。ありがとうございます。

炭田：ドキドキしていました。

植田：もう1件、「本日アーカイブ配信ありますか？」という質問をいただいています。あります。後日、弊社BASEのYouTubeチャンネルと、DMM.comさんのYouTubeチャンネルそれぞれにアーカイブ動画をアップするので、前半を見逃した方はご安心ください。

では、だいぶ質問もいただきましたので、ちょうどよさそうですかね。炭田さんも、もう満足といった感じですかね。

炭田：たくさんいただき、ありがとうございます。

植田：では炭田さんの登壇は以上です。あらためて炭田さん、ありがとうございました。

炭田：ありがとうございました。