DXで注目されるアジャイル開発の成功ポイントは?
- DXリーダー育成
- システム設計
- アジャイル開発
はじめに
多くの企業にDX推進が広まって以降、従来のウォーターフォール開発よりも
状況に合わせて柔軟に動けるアジャイル開発に注目が集まってきました。
しかしアジャイル開発はメリットばかりではなく、
開発マネジメントが難しい側面を含んでおり、導入に苦戦するケースが多いです。
そこで、従来から採用されるウォーターフォール開発との比較を通じて
アジャイル開発を成功させるポイントを解説していきます。
- アジャイル開発とウォーターフォール開発は何が違うのか?
- どういったケースでアジャイル開発が有効なのか?
- アジャイル開発のマネジメント手法
※以降、「WF開発」と書いたら「ウォーターフォール開発」を指します
まずはウォーターフォール開発(WF開発)が基本
まず大前提として、システム開発はWF開発が基本となっています。
というのも、アジャイル開発では柔軟性を重視する反面、
途中でプロジェクトが迷子になってしまうリスクを含んでいます。
それを回避するために、まずはWF開発の特徴である
「最初に全体の見通しを立てて、計画通りに進める流れ」を理解しておくと良いです。
ウォーターフォール開発のポイント
全体の流れ
WF開発の1番の特徴として
「開発スタートする前に全体の見通しを立てる」ことが挙げられます。
大きな流れとしては3つに区分できます。
1)上流工程:「どんなシステムを開発するのか?」を決める
- 要件定義
- 基本設計
- 詳細設計
2)実装:実際にシステムを開発する
- コーディング
3)テスト工程:「開発要件を満たしているか?」をチェック
- 単体テスト(詳細設計の内容をチェック)
- 結合テスト(基本設計の内容をチェック)
- ユーザーテスト(要件定義の内容をチェック)
企業ごとに方針の違いはありますが、
基本的には前の工程に戻らない(後から変更しない)前提で進めるので
最初の計画がとても大事です。
メリット・デメリット
昨今の変化スピードが早いビジネス環境では、
「後から変更できない」と聞くと不自由を感じるかもしれません。
しかし、
「変化が少ない=管理しやすい・開発チームの負担が少ない」
こう考える事も可能です。
このメリットを重視する場合にはWF開発を採用するし、
デメリットを避ける場合にはアジャイル開発を採用することになります。
では、どういったケースでWF開発のメリットを活用できるのでしょうか?
重宝された歴史的な背景
ほんの15年前は、ほとんどのシステムはWF開発で作られていました。
背景として、システムと言えば「会計システム、人事・労務システム」などの
業務システムがメインでした。
そうすると、すでに既存業務が存在するので、
最初からシステム要件(守るべき法律・業務プロセスなど)を決める事が可能でした。
つまり、WF開発の強みは
「既存業務の効率化」を目的とするケースで有効だと言えます。
どういった資料が必要か?
こういった要件が明確なシステム開発は
「既存業務をモレなく・正確にシステム実装する」ことが重要視されます。
そうすると、ビジネス関係者・エンジニアなど
多くの関係者とヌケ・モレのない確実なコミュニケーションが必要なので
3フェーズに分けて確実な情報整理を行います。
- 要件定義:システム開発の目的をビジネス関係者と調整する
- 基本設計:ビジネス側・エンジニア間のゴール認識を揃える
- 詳細設計:プログラマに開発依頼する
以上が古くから活用されるWF開発の全体像でした。
続いて、WF開発の弱点である「ビジネス変化に柔軟な開発」を実現するために登場した、
アジャイル開発を見ていきましょう。
アジャイル開発のポイント
全体の流れ
まずアジャイル開発を一言で表現すると
「小さいリリースを繰り返して、ニーズを探りながら開発する手法」です。
大まかな方向性はありつつも、詳細まで見通しが立てにくい開発で有効です。
6〜18ヶ月のプロジェクト期間を細かく分割して、
「イテレーション」と呼ばれる2週間サイクルで開発計画を立てます。
ウォーターフォール開発との違い
下図を見ても分かるとおり、WF開発とアジャイル開発の最も大きな違いは
「1回の開発計画のスパン」をどの程度の長さで認識するか?です。
- WF開発:数ヶ月〜数年(プロジェクト期間を丸ごと使う)
- アジャイル開発:2〜3週間(プロジェクト期間を細分化する)
メリット・デメリット
そうすると、2〜3週間サイクルで細かく開発計画を作るので
当然ながら開発の柔軟性は飛躍的にアップします。
その反面、プロジェクトの方向性を見失って迷子になるケースや、
開発メンバーの自走スキルが強く求められるので難易度が高くなる傾向があります。
そのため冒頭の繰り返しとなりますが、
「まずは全体の見通しを立てるFW開発を理解してからアジャイル開発にチャレンジする
この順序立てが重要です。
続いて、アジャイル開発はどういったケースで有効なのか見ていきましょう。
アジャイルが登場してきた背景
アジャイル開発の有効性を知るには、
図に整理したようなビジネス背景を理解すると良いです。
- なぜWF開発が使いにくくなったのか?
- アジャイル開発はどんな問題を解決したのか?
簡単に整理すると、WF開発は「既存業務のシステム化」に効果的で、
アジャイル開発は「前提となる業務がない未知の問題」に効果的です
ポイントは「ビジョン設定」
繰り返しとなりますが、
DXプロジェクトでは「前提となる業務がない未知の問題」に対処するので
どんなシステム開発が必要なのか全くイメージが無い状態からスタートします。
そんな状況下では、細かなシステム要件よりも
目指すゴールを決める「ビジョン設定」が最重要です。
そしてビジョンの方向性が正しければ、一定数のユーザーが使ってくれるので
ユーザー意見を集めて改善を繰り返していく流れが作れます。
そして、もっとも避けたい失敗としては
「表面的なニーズに引っ張られて1発で当てに行く」パターン
が有名です。
例えば図に書いたように、未知の問題に対処するDXプロジェクトでは、
「本当は安くて快適な移動手段なら何でもOK」な状況下であっても、
「長い時間かけて高級車を開発してしまう失敗」が非常に多いです。
そのため、2〜3週間サイクルで小まめに開発・リリースを繰り返して
ユーザーの反応を見ながら微調整を繰り返すアジャイル開発のメリットが効果的です。
どういった資料が必要か?
アジャイル開発では「ビジョン」を重要視したスピード開発を行うので
細かな設計書などは用意しません。
しかし、完全に資料がない状況では開発チームの運営が困難です。
そこで「バックログ」と呼ばれるシステム要件をリスト化した資料が活躍します。
バックログには2種類あります。
- プロダクトバックログ:プロジェクト全体のシステム要件
- スプリントバックログ:次の2〜3週間で開発するシステム要件
そして、スプリントバックログの中でも開発の難易度が高い場合に限って
簡素化した設計ドキュメントを用意します。
まとめ
以上が、DX推進で注目されるアジャイル開発と、
従来から重宝されるWF開発の違いです。
繰り返しになりますが、いきなりアジャイル開発をやっても
開発チームが混乱してマネジメントが困難になります。
まずはWF開発で「最初に見通しを立てて、計画通りに開発する」ことを理解してから
柔軟性を高めるアジャイル開発にシフトしていく事がオススメです。
以上、本記事がDX推進にチャレンジする皆さまのお役に立つと幸いです。
最後までお読みいただき誠にありがとうございました。