Culture

TOP

>

Culture

アジャイル開発を内製で始めるために ~変化に強い組織を作るための第一歩~

更新日: 2025年6月4日

アジャイル開発を内製で始めるために ~変化に強い組織を作るための第一歩~

現代において、ビジネス環境はかつてないスピードで変化しています。このような状況下でも企業が持続的に成長するためには、変化への柔軟な対応力迅速な意思決定が不可欠です。アジャイル開発は、まさにこれらの要求に応えるための開発手法、組織運営の考え方として、近年多くの企業からの注目を集めています。


アジャイル開発を導入したいけど、何からどう始めたらいいかわからない―――そんな声をよく耳にします。そこで、Sun*は「まずは内製でアジャイル開発をやってみたい」という方に向けて、失敗しにくいアプローチをご紹介するウェビナーを開催しました。解説を担当したのは、Sun*の開発組織でGeneral Managerを務め、戦略策定・実行を管轄している船木大郎さんです。

ウェビナーの参加者の中には、新規事業のアイディアやビジネス化に課題を抱えており、その解決手法としてアジャイル開発に興味を持っているがよくわからない……という方が多くいました。

 

本記事ではウェビナーの内容から、実践に役立つポイントなどを抜粋してお届けします。

アジャイル開発とは何なのか?

アジャイル開発とは、短い開発サイクルを繰り返しながら、顧客や利用者のフィードバックを迅速に取り入れ、継続的に改善していく開発手法のこと。従来のウォーターフォール型開発のように、計画段階で全てを決定するのではなく、変化に柔軟に対応し、価値の高い成果物を早期に提供することを目的とします。

アジャイル開発の定義は、2001年に提唱されたアジャイルソフトウェア開発宣言に示されている通りです。

 

アジャイル開発は、単なる開発手法ではなく、自己組織化やチームのコラボレーション、継続的な改善といったマインドセットや文化を重視し、トップダウン型の管理からボトムアップ型組織へ変革を促します。変化への対応と人を重視する価値観は、開発プロセスだけでなく、組織全体の意思決定や運営にも影響を与えます。

アジャイル開発の代表的なフレームワーク

アジャイル開発の代表的なフレームワークの一つが「スクラム」です。スクラムは、自律的なチームが短い期間(スプリント)で成果物を開発し、定期的な振り返りを通じて改善を繰り返すのが特徴です。スクラムには以下のような、アジャイルを実現するための包括的かつ具体的な要素が含まれており、アジャイルの代名詞的な存在と言えます。

  • 短いイテレート(スプリント)でのリリース
  • プロダクトオーナー、スクラムマスターといった役割定義
  • プロダクトバックログ(長期的)、スプリントバックログ(短期的)の2つのバックログによるタスク管理
  • スプリントプランニングやデイリースクラムなど、定期的なイベントの定義

その他にも、技術的なプラクティスに重点を置き、テスト駆動開発やペアプログラミング、継続的インテグレーションなどを行うXP(エクストリームプログラミング)、トヨタの生産方式から着想を得て、不必要なものを捨てて本質的なものに向き合う時間を多く取るという抽象度の高い思考・原則を持つリーン、タスクの流れを視覚化するボードを使用するカンバンなどがあります。カンバンは他の方式と衝突しないものであり、スクラムなどの他のアジャイル手法と組み合わせて使用されることも多くあります。

ウォーターフォール型開発との違いは?

デジタルトランスフォーメーション(DX)は大きく2種類に分けることができます。デジタイゼーション(業務プロセスのデジタル化によるコスト最適化や効率化)とデジタライゼーション(事業自体のデジタル化による新たな市場や収益の成長、デジタル企業へのアップデート)です。

デジタイゼーションのように、すでに明確に価値のある業務フローが確立しており、それを再現・改善することが目的である場合は、計画に基づいて段階的に開発を進めるウォーターフォール型開発が適しています。

一方で、デジタライゼーションのように、市場がその価値を受け入れるかどうかが不明確なプロダクトや、新たな価値創造を目指す場合は、短期のリリースを繰り返し、市場のフィードバックを得ながら改善していくアジャイル開発を通したアプローチが適しています。

アジャイル開発は、市場から価値を認められるか分からない、利用するユーザーが抱えるペインが多様でどの機能が解決策となるか分からないなど、明確な答えがない中で市場投入により答えを見出したい場合に強みを発揮します。

 

自社でアジャイルを始めるには?

スタートはチーム作りの前にある

開発を『小さく始める』ためには、まずプロダクトオーナーを決定することが重要です。

プロダクトオーナーは、プロダクトのビジョン、価値、機能について意思決定を行う責任者であり、効果的なプロダクトバックログ(※)管理にも責任を持ちます。

(※中長期のプロダクトについて、今後のロードマップや機能展望を優先度順に並べたもの。次の期間・スプリントでなにのユーザー価値提供・機能追加をするかを並べたものは「スプリントバックログ」といい、スクラムをベースにした場合のプロセス管理の方法として用いる)

スクラムを公式に定義した教科書「スクラムガイド」では、プロダクトオーナーは一人の人間であり、委員会ではないと明記されています。プロダクトオーナーは、全てのタスクを把握し、タスクについて決裁ができる唯一の人物であり、それを実現するためには現場に立つ必要があります。

 

アジャイル開発の実現にあたって、組織としてどうあるべきか?

アジャイル開発を成功させるには、プロダクトの価値に投資判断をする決裁者と、プロダクトの価値を最大化するための決裁者(プロダクトオーナー)を分離することが推奨されます。なぜなら、これはスタートアップとベンチャーキャピタルの意思決定フローと構造として、新規事業立ち上げの方法論として淘汰された結果、生き残っている重要な形だからです。

初期段階(0⇒1時点)ではプロダクトの具体的な価値が定まっていないことが多く、市場のバリューを判断することは困難です。市場の変化が激しい環境下では、投資判断をする決裁者が現場を把握することは難しいため、現場のスピード感に対応してプロダクトの価値を最大化できるプロダクトオーナーに日々の意思決定を委ねるのがよいでしょう。

新規事業のほとんどは失敗する可能性が高いため、投資判断を行う決裁者は、失敗を前提としてリスクマネジメントした投資計画を立て、撤退ライン決めておくことが重要です。

 

最適なチームづくりは、役割とワークフローの柔軟な定義がカギ

前述した「スクラムガイド」では、開発者が担うべき具体的なスキルやワークフローが規定されていません。

アジャイル開発を曖昧にせず、効果的に進めるためには、各人の役割とワークフローをチームの状況に合わせて具体的に規定することが重要です。

具体的なケーススタディの一例

 

スクラムマスターは、スクラムチームが自己組織化し、スプリントを円滑に進められるよう支援し、障害を取り除くファシリテーターです。スクラムマスターには、多様な知識と高いコミュニケーション能力が求められるため、内部でのアサインが難しい場合は、短期的な改善は難しいですが、外部のリソースを活用することも有効です。

アジャイル開発においては、各人の役割やワークフローに決まった一般化できるものはありません。チームの状況に合わせて適切に設定し、変化に対応できる体制とマインドセットを持つことが重要なのです。

要件定義の考え方の転換 – 抽象的な成果物によるディレクション

アジャイルソフトウェア開発宣言にある「計画に従うことよりも変化への対応」という価値観に基づくと、従来の詳細な要件定義はアジャイル開発に適していないように感じるかもしれません。では、いったいどのように定義していけばいいのでしょうか?

以下に挙げるような、より抽象的な成果物をもって、プロダクトとチームのディレクションを決定するという前提の大きな流れを作る必要があります。

  • How Might We? (HMW): 「どうすれば○○できるか?」という問いの形で課題を再定義し、アイデア創出を促します。前向きな問いかけにより、困難な課題に対しても解決策を模索しやすくなります。
  • カスタマージャーニーマップ: 顧客が商品やサービスを認知してから利用・継続するまでの一連の体験や行動を可視化する手法です。顧客視点で全体体験を捉え、マーケティングや開発など様々な役割の人が共通認識を持ちやすくなります。
  • ユーザーストーリーマッピング: ユーザーがプロダクトを使う一連の流れを「ストーリー」として俯瞰し、必要な機能やタスクを整理する手法です。機能が利用されるタイミングや目的を理解しやすく、MVP(Minimum Viable Product)や各リリースの範囲を決定しやすくなります。

これらの成果物は、デザインシンキングのプロセスを通じて生まれることが多く、アジャイル開発におけるプロダクトとチームのディレクション決定に非常に有効です。デザインシンキングは、ユーザーにフォーカスし、技術的・ビジネス的に実現可能な形で課題を解決するアプローチです。観察・共感から始まり、機会発見、アイディア創出、デザインへと進むプロセスを通じて、機能的な価値だけでなく感情的な価値も創造できるため、明確な答えがない問題や人の体験に関わる課題の解決に向いているといえます。

アジャイルな組織が変化を乗りこなし、成長を実現する

いかがでしたか?

本ウェビナーでは、上記の内容にくわえて、参加者と音声会話で進む質疑応答の時間がありました。アジャイル開発の「動くソフトウェア」は、本来は依頼者側で動作する状態を指すべきだが、現場では開発チーム内の確認で完結してしまうことがあるという参加者からの指摘に対して、登壇者の船木さんは「アジャイル導入には依頼者も含めた短いサイクルでの確認とフィードバックが必要であり、「言われた通りに作る」型のプロジェクトはアジャイルには適さない」と返答。

発生した疑問点もその場で解決することができ、参加者の満足度も高い時間となりました。

 

アジャイル開発は、変化の激しい現代において、企業が柔軟かつ迅速に対応し、持続的な成長を実現するための強力な武器となります。現場で対応するメンバーだけでなく、決裁者もアジャイル開発の理念を理解し、自社の状況に合わせてそのエッセンスを取り入れることができれば、より変化に強く、価値を最大化できる組織の実現に向けて、リーダーシップを発揮することができるかもしれません。

アジャイル開発の導入や組織変革に関して、より具体的な課題や疑問がありましたら、ぜひSun*にご相談ください。過去に数多くのスタートアップ・エンタープライズの新規事業を支援してきたスペシャリストが、現状の課題に対する具体的な解決策を提案いたします。

アジャイル開発で最低限抑えておきたいポイントをチェックリスト化いたしました。

Sun Asteriskがこれまで手がけてきたプロジェクトを多数ご紹介しております。