第1部　SHIFT×アジャイル開発

村瀬：SHIFTはソフトウェアテストだけでなく、自社事業のアジャイル開発・お客様に対するアジャイル支援も積極的に取り組んでいます。

後者の“アジャイル支援”を担っているのが、私たちが所属するアジャイルサービス部です。 

名前の通り、アジャイル専門部隊で約300名が所属（2024年5月時点）。アジャイル開発をやりたい、もっと広めていきたい、と考える多種多様なバックグラウンド、スキルをもつメンバーが揃っています。 

次は具体的なサービス内容にうつります。スクラムマスターやアジャイルコーチ、開発エンジニア、アジャイルQAなど、基本的にアジャイル開発に必要とされるものは、SHIFTのサービスとして提供しています。 

村瀬： 最近ではQAだけでなくプロダクト開発のご支援も行っており、SHIFTワンチームで対応をしています。 

また、アジャイル教育支援にも積極的で、お客様の組織のなかでの成功事例を横に広げていく取り組みも行っています。

QAだけでなく、そういった部分にも強みがあるということをぜひ覚えていただけたらと思います！ 

第2部　トークセッション

司会者：この解決策として「理由を明確にしてみんなが腹落ちしている状態にする」ということですがどういうことでしょうか？ 

三品：基本的なことですが、アジャイル開発は手段であり「なぜアジャイル開発をやるのか？」という点を明確にして、トップの人間だけでなく現場の人も納得している状態にしないと導入してもうまくいきません。 

いままでのやり方を変えるのにはエネルギーもいるので、納得感がないままでは現場は「なんで変える必要があるのか？」となってしまいます。全員が腹落ちしている状態にするのが、進めるうえでの基本かなと思います。 

村瀬：そうですね。アジャイル開発がうまくいっていない企業様は「どうしてアジャイルをやっているのか」が徐々に忘れられてしまい本質的な課題が見えなくなっていることがけっこうありますよね。 

三品さんはこのような案件ではアジャイルコーチとしてどのようにコーチングをするんですか？ 

三品：理由が明確になっていないとどこかで停滞してしまうので、そのときに「どうしてアジャイルがやりたかったんだっけ？」「したかったことができてるんだっけ？」と、改めて確認をして初心に立ち返ってもらえるようにしています。 

村瀬：なるほど。私がアジャイル開発で困っている企業様に最初に話すのはウォーターフォール、アジャイルそれぞれ良し悪しがあり、そこをステークホルダー含め理解してやっていますか？ということです。そこができていないというのが、本質的な課題に感じています。 

司会者：解決策として「POは専任を置く。むずかしい場合は、権限がある人を巻き込む」とのことですが、これはどういう状況のことでしょうか？ 

三品：スクラムにおいて、いいアウトプットを出すためにはPOがいいプロダクトバックログを作成することが必要です。

そのためにはPOに権限やビジネスセンスが必要なのですが、いざふたを開けるとPOにその権限や能力がないことがあるんです。 

その場合、POとは別に権限をもっている人がいたりするのでその人をうまく巻き込んでいきます。

その人がPOをやるのが一番はやいのですが組織上できないこともありますから、POにブリッジ的に対応してもらうなど、工夫しながら進めていきます。 

村瀬：なるほど。PO専任っていままでありましたか？ 

三品：ありましたよ。POの大変さを理解している企業は専任ですね。

POはさまざまなステークホルダーの調整をしながら中長期的に戦略的にバックログをつくっていく必要があるので、本来は専任でないとできないと思います。兼任でPOをやっているところは微妙なバックログになっていきますね。 

村瀬：アジャイル開発でも目先のスプリントだけでなく、中長期的にプロダクトの戦略をつくっておけばチームメンバーも目指す先が見えるので、それを指し示すことにもなる点でバックログは重要ですよね。 

もし、POがバックログをつくれない、権限がある人も巻き込めないとなった場合どうしますか？ 

三品：むずかしいですね。SHIFTにもPO支援サービスはありますが、例えばPOが対応できない場合は、最終の意思決定者をひとり決めておき複数人でPOチームとしてやるのもいいかなと思います。

司会者：解決策「従来のやり方から切り離す」とありますが、こちらもお願いします。 

三品：ウォーターフォール的なやり方が残っていると、チームでスピーディーにやっていこうというアジャイル開発においては支障がでてしまいます。 

例えばスクラムにおいてPMという役割はありません。進捗管理は開発チーム、方向性を示すのはPO、チーム運営はスクラムマスターです。

仮にここにPMが入ってきてしまうと自己組織化ができないなどの弊害がでてきます。 

従来のPMのやり方しかできない人は役割がなくなってしまうので、そこをどうフォローするかも重要です。自分の役割がなくなってしまうのを受け入れるのはむずかしいですからね。 

村瀬：もし組織構造を変えるとなった場合、大規模に一気に変えてしまうのか、ワンチームスクラムでスタートしてうまくいったら波及させていく方法だとどちらがいいと思いますか？ 

三品：まずは新しくアジャイル開発をやるところを従来の組織から切り離すのが一番いいのかなと。

いきなりすべてをアジャイル開発に変えるとなるとリスキリングみたいなことをしなければいけないのでむずかしいんじゃないでしょうか。 

第3部　質疑応答

ここからは参加者から寄せられた質問のなかから、いくつか紹介します。 

―――設計・企画段階で開発タスクがつくりにくい状況でのアジャイル開発のいい進め方を知りたいです。 

村瀬：時間をしっかりとれるのであればデザインスプリントをまわすことですね。デザインスプリントってしっかりやると5日間くらいかかったりするんですが、開発の前段階として企画を巻き込んでアジャイルのマインドをインプットできるいい期間になるので。

そのあとにアジャイル開発に進むのがいいと思います。 

三品：そもそもプロダクトバックログにはタスク（作業）を書くものではないと思っています。

「どういう状態にしたい」という理想の姿をプロダクトバックログとして描けば、そこから自然とやるべきタスクも見えてくるかなと。  

―――すべてのバックログをユーザーストーリーで書くのはむずかしいと感じます。軽微な修正や調査、ドキュメント作成などはバックログとして扱わない方がいいでしょうか？ 

三品：私としては製品・サービスに関わるものは軽微なものでもバックログに載せるのが方針です。

スプリント単位でちゃんと完了して、できればレビューできるといいですね。みんなからフィードバックがもらえる書き方になっているとよりよいかと思います。 

村瀬：その通りですね。結局レビューで修正報告だけになってしまうと微妙だなと思います。自分たちが何をつくっているのか、ゴールをイメージしてバックログを書くのがいいのかなと思います。 

―――「信頼性」「安定性」が求められるシステム開発ではアジャイル開発はあわない気がしています。実際はどうでしょうか？ 

三品：一般的に、信頼性が重要なお金や命が関わるシステムはあわないとはいわれますね。アジャイル開発は「はやく失敗して学びを得ること」が重視される場合があるので。 

アジャイル開発だからといって品質が著しく下がるわけではないですが、信頼性などを重視する場合はウォーターフォールの方が安全ではあります。 

小さくはやく市場に出してすぐにフィードバックをもらうことを重視するのであればアジャイル開発でもいいと思いますが、村瀬さん実際のところどうでしょうか？ 

村瀬：途中までアジャイルでやって、最後のプロセスはきっちり仕上げていくというような、折りあいをつけてハイブリッド開発でやっている企業が多い印象ですね。 

―――開発として事業側に認識してほしいことは？ 

村瀬：いかに巻き込めるかでしょうか。スプリントイベントに事業側の人を呼んで、アジャイルのよさを実感してもらうことが重要かなと思います。 

三品：本来は事業側がPOをやっていっしょのチームとして動くのが理想ですがむずかしいこともあるので、一番いいのは定期的に成果物を見せ、フィードバックをもらうことでしょうか。

事業側としっかりとコミュニケーションをとり信頼関係を構築していくことが重要だと思います。 

このほかにもたくさん質問いただき、多くの参加者にSHIFTのアジャイルサービス部に興味をもってもらえたのかと思います！ 

この記事を読んだあなたも、SHIFTについてもっと知りたいと思われましたら、募集職種一覧をチェックしてみてください。 

（※本記事の内容は、イベント開催当時のものです） 

▼イベント動画もぜひご視聴ください▼