2025年1月22日開催ウェビナー｜旭化成は新規事業開発にどうやってアジャイル手法を導入したのか

[#1]

2025年1月22日(水)に、アトラシアン主催の無料ウェビナー『旭化成は新規事業開発にどうやってアジャイル手法を導入したのか』を開催いたします。

本ウェビナーでは、旭化成株式会社より西野大介様をお迎えし、アトラシアン製品を活用し、アジャイル手法を用いた新規事業開発の事例をご紹介いたします。

ご関心のある方は、事前登録の上、ぜひご参加ください。

後日、本投稿に当日のQ&Aでいただいたご質問とそれに対する回答を追記させていただきます。

（以下、1月30日追記）

当日のウェビナーの内容については、こちらからアーカイブ配信を視聴いただけます。
Q&Aの内容については、以下よりご確認ください。

#	質問	回答
1	体制について プロダクトチームの場合は、プロダクトマネージャ、デザイナー、デベロッパーなどでチームを構成しますが、今回の新規事業開発においてはどういう役割の方で何人くらいの体制を組んだのでしょうか？	タイミングによりますが全体としては10名前後で、事業部側にはスクラムの役割である「PO（プロダクトオーナー）」にメインで立ってもらい、その他で事業性評価や知財などのスペシャリスト数名、担当者として一緒に実作業を行うメンバーが数名でした。 デジタル部門側は、実質的にPOを補佐する役割としてPdM、開発担当、スクラムマスター、デザイン担当など。UIデザインについては他プロジェクトの有識者に評価してもらうなど、チーム外のメンバーにも一部参画もらっています。
2	お話しいただいた事例において、西野様はスクラムマスター的な役割を担っておられたのですか？ スクラム初心者がチーム内にいた際にコミュニケーションやメンバーのスキル向上に気をつけた点があればアドバイスいただきたい。	たくさんありますが、以下は重要であると考えます。 スクラム用語を多用しない：分かりづらい用語が多いため、それだけで脳のキャパをオーバーして話についていけない人が出てきます。それを避けるために、わかりやすい言葉に置き換えたり、一部の要素だけに区切ってじっくり説明する（たくさん用語が必要な内容を一気に話さない）など工夫が必要です。 実務と理論をバランスよく伝える：初心者には少しずつスクラムの要素を適用していくべきですが、その場合、途中段階で満足してしまいがちです。一部要素を削って適用していると本来の価値が出し切れないため、本来的なスクラムを目指すべきですので、その点を勉強会等で説明して理解してもらい、徐々に現場実務に適用していくことが求められます。 運営に初心者の意見も取り入れる：スクラムのべき論を押し付けるのではなく、チームにとって最適な形にどんどん変えていくべきで、初心者でも自分の意見を言って改善していく実感を得られるように立ち回るべきです。ただし、スクラムの良さを潰すような変更は避ける必要がります（その場合も理由を明確化して納得してもらったうえで不適用とするなど、対話が重要です）。
3	JiraやConfluenceを使っていてよかった点とこういう点が使いにくかった（改善してほしかった）などあれば教えてください。	Good：スクラムで必要な要素が揃っており、また慣れるほど柔軟なカスタマイズができるので、自分たちにあわせた使い方ができる。 More：一方でテンプレートや使い方が多様であるため、慣れていない状態で使ってうまく活用できていないケースもままある。まずは使ってみつつ、ある程度詳しい人に相談しながら改善していける環境があると望ましい。
4	スクラム開発のチーム組成ですが、原則は、チームメンバーは専任が基本と思います。ただし、新規事業となりますと、スクラムメンバーは、縦割り組織から兼任で参加される可能性が高いと思います。各イベント、イベントのための準備、イベントへのコミットは、スクラムを始める前（Sprint0)で認識合わせ、合意形成を取ってますでしょうか？さらに	YESです。私自身も他のメンバーも、ほとんどが常に兼任で参加しています。誰が何を担うべきかという役割や責務の合意、マイルストンの設定、プロダクトゴールの合意など、事前に整理すべき重要なポイントは網羅する必要があり、我々はそれを計画書の体裁で型にしています。その中には挙げていただいた要素はいずれも入っており、決済権限者含めて計画説明時に合意したうえで進めています。そのうえで細かく申し上げますと、Sprint 0はチームにとっての準備期間として扱うことが多く、これらはSprint 0よりもっと前に合意することも多いです（ステークホルダーが多く時間がかかるため）。
5	さらに、参加されるメンバーのアジャイル開発、スクラム開発に関する知識、スキルセットのレベル感が違うかと思います。そのレベル感を合わせてからプロジェクトをスタートされますでしょうか？	実態はNOです。ある程度事前に合わせたい気持ちはありますが、実際はその余裕がないことがほとんどです。ですので、スクラムを（スクラムと呼ばずに）段階的に取り入れながらこの手法の価値を理解してもらい、十分に乗り気になっていただいたあとにスクラムの基礎を学習してもらうというステップを踏んでいます。
6	各タスクを作成する際のタスクの大きさ（粒度）で悩むことが多いです。ここに関して良いアプローチがあれば教えて欲しいです。	原則としては、チームでそのタスクを管理しながら、状況が良いか悪いかを適切に評価し、適応（軌道修正）できるならサイズは自由であると考えます。ただ実態としては、最低限日次で状況を検査・適応できるサイズ（つまり朝から定時までで、余裕を持つとせいぜい6h前後）が1タスクの最大サイズと考えるのが一つのやり方としてよいと思います（実務ではもう少し小さいサイズも使うとタスクが切りやすいです）。 最初から6h以下のタスクを切ろうとするとタスク整理（Sprint　Planning）の場が硬直する可能性があるので、まずはサイズを気にせず挙げていって、大きすぎるものは他所に弾いておいて、そのあと個別に時間をとってサイズを分割するアプローチがおすすめです。
7	従業員のレベル設定（スキルレベル）についてですがどのようにおこなっていきましたか？（特に中途の方など）	各種スクラムイベント（タスク整理：Sprint Planningや振り返り：Retrospective等）は、全体のレベルを確認したあとに、知識がない人がいればそれでも問題なく参加できるようにファシリをします。そのうえで、知識の底上げをしていく（上を伸ばすのではなく下をあわせる）をしていきます。 知識の底上げは実務に加えて、当社のオープンバッジというDX人材育成のアセットを使って学んでもらうということをしています。
8	新規事業開発におけるアジャイル手法のバッドプラックティスの例を教えて頂けますでしょうか？	こちらもたくさんあるかと思いますが、以下は重要であると考えます。 スクラムを絶対の型として捉える：重要なのはスクラムをもとに自分たちにとって快適なチーム運営をしていくことであると認識し、積極的に意見交換して色々と変えたり戻したり施行していくことであると、皆が理解しておくべきです。 ビジネスやUX担当の流動的なやり方が、開発チームを苦しめる構造になっている（スプリントゴールに影響する変更を無理やり入れ込む）：スクラムだからといってビジネスやUX担当が、リサーチ結果や上層部の意見によりやり方をころころ変えると、その後に作業が発生する開発チームばかり疲弊してしまいます。といって無駄になる開発とわかっていながら継続するのはよくないので、疲弊せずかつ柔軟な対応をとる必要があります。具体的には、スプリントゴールが変わるような変更がある場合はスプリント自体を一度中止して仕切り直すことや、開発とビジネス・UXを融合しやすい発展型のスクラムを適用する（デュアルトラックアジャイル等）といったことが考えられます。
9	アジャイルを組織に展開する時にどのように始めたのでしょうか。ボトムアップ、トップダウンだとどちらでしょうか。いずれにしても経営陣の理解も重要だと思いますが、その辺で工夫した点があれば教えてください。	大企業の場合はあらゆるアプローチをとっていく必要があると考えます。 デジタル組織（当社で言えばデジタル共創本部）を設立し、そこからプロジェクト単位で浸透させていく。これはプロジェクトごとに異なる事業部門を変革していくというボトムアップ目線です。 社内研修や認定の仕組み（当社で言えばオープンバッジ）を作り、全社でその認定の促進活動を行う。当社はオープンバッジを含めた人材育成や人数目標を中期計画書などにも盛り込んでおり、トップダウンで行っている施策と言えます。一方でこのオープンバッジは、社内説明会などを用いて、生産性向上に意欲的な人に向けて受講の営業活動を行っており、これは自主的に変革する社員を生み出す活動としてボトムアップの施策とも言えます。
10	ご講演ありがとうございます。まだ新入社員なのですが、入社した会社が口頭で進捗を確認するようなウォーターフォール型の開発をしています。上司の方にこのようなスクラムで開発を進めていただきたいと考えているのですが、何から進めれば良いかアドバイスいただけないでしょうか。	上司の方の関心事からずれると提案は通らないため、①関心事が何かを情報収集し、②その実現を邪魔する課題を整理し、③それに対する解決策として提案する、というのがよいのではと考えます。 ①については例えば所属部署の組織ミッションを見てみて、特定のプロジェクトの成功であるとか、売上の数値目標などのようにスクラムが有効そうなものがないかを確認するなど。また所属長が残業時間を削減せよなどメッセージをメンバーの方に発していたらそれは確実に関心事です。 ②として、次に、例えば残業の原因は今のプロジェクトの管理が冗長でうまくいかないなどの関連する課題を整理する。 ③としてはスクラムでその部分に特に効く要素に特化した説明資料を作って、①②③セットで提案する、などが考えられます。
11	スクラムで社内に理解してもらうための「生産性」というものはどのように定義していましたでしょうか？	チーム内でどのように管理するかというのは「ベロシティ」という基準があるため、それを用いるのが一般的です。ただこれは生産性が上がる/下がるというより、事前予測と事後の結果について乖離を減らしていくためのものなので、チーム内でしか活用しにくいものです。 チーム外向けにはなかなか難しいもので、ソフトウェア開発であればFour Keysのような指針があるのですが、事業開発となると数値化しにくいのが実感です。ですので定量的には示すかわりに、プロジェクト計画の中で、期間、活動内容、体制や工数を説明しながら、他の類似プロジェクトに比べてそれらをこれぐらいの数字でできます（それはスクラムがこういう仕組みなので、生産性がこういうふうに上がるためです）というような説明をしていました。