アジャイル開発に適している要件は??
3月決算の企業も多く、来年度の予算や施策を練りに練っている企業も多いかと思います。
限られたリソースの中で、積み上げで考えるフォアキャスティングと、
あるべき姿から逆算したバックキャスティングで戦略・戦術に落とし込んでいくのですが、これがまた至難の技ですよね。
私自身も毎年、戦略や戦術を立てる際、理屈では理解しつつも、
至難の技に悩まされながら、
現在軸と未来軸の思考を行ったり来たりしております・・・。
これまで通りの施策を前提に予算計上していくパターンもあれば、
前年度の施策を修正し、リソースの再分配を思案しながら、取組みを検討しています。
出来れば、これまでの前提や前例にはない施策も盛り込みながら、失敗も一定は許容しながらも修正し前進していく施策も盛り込んで、これまでの延長の1年とは違う年にしたいと妄想しております。
※あくまでも妄想です。
さて、本日はビジネスのシーンで良く聞く様になった「アジャイル開発」についてワークスアイディ株式会社の奥西が、皆さまと一緒に考えていきます。
言葉の定義「アジャイル」とは
まずは言葉の定義から確認しておきたいのですが、
「アジャイル」とは、
俊敏であるさま。機敏な。敏捷な。と書いてありました。
「俊敏な」「すばやい」という意味の英単語で、要求仕様の変更などに対して、機敏かつ柔軟に対応するためのソフトウェア開発手法。
もう少し分かりやすく表現してみると。
ソフトウェア開発の課題の一つでもあった、開発期間の短縮化や低コスト化。
そして、柔軟で迅速な対応などを実現するための取り組みとして提唱された手法とのことです。
うーん。何となくここまでは理解されていますかね。
もう少し詳しく見ていきます。
「アジャイルソフトウェア開発宣言」には下記の様な記載がありました。
普段、皆さまが推進されているDXプロジェクトのシステム開発プロセスは、
アジャイル開発が適しているのか、それともウォーターフォール型で開発すべきか悩ましいですよね。
部分的にアジャイル開発を適用することもあると思います。
ではアジャイル開発に適している要件を考えてみたいと思います。
アジャイル開発に適している要件とは
アジャイルソフトウェア開発宣言の中のキーワードから読み解いて、
私なりにアジャイル開発に適しているケースを探っていきます。
1、「個人と対話」
開発規模が大きくないものが望ましい。
プロジェクト人数も5人〜7人ぐらいが目安でコミュニケーションコストが
発生しない規模が望ましい。
例)RPA開発、単機能のAI、製品プロトタイプ、新規事業開発など
2、「包括的なドキュメント」
高品質が求められるバックエンド側のシステム。
既存システムと連携する様なサービスシステムの場合は、高いレベルの品
質が求められますので不向きということですね。
プロトタイプ開発はアジャイルでもよいと考えますが、テストや評価、品
質からウォーターフォール開発になりやすいです。
3、「顧客との協調」
プロダクトオーナーが近くにいてすぐに判断できる距離が重要とのいうこ
とです。
素早く判断し、改良するためにも、お伺いや根回し、会議調整が必要な仕
組みではアジャイルの良さが活かされないです。
意思決定プロセスがそもそも適しているのかも、確認ポイントですね。
4、「変化への対応」
はじめから「こうあるべき」という要件がない場合に、アジャイル開発
が適している。
企画段階ではイラストぐらいのイメージから、サービスがデザインされて
いきブラッシュアップしていくパターン。
ここは、私の真骨頂の部分かもしれないです!!
(言い切って大丈夫か!?)
なんでもかんでもアジャイルという事ではなくて、
開発の進め方には、それぞれ向き不向きがあることを理解しておくことが重要ですね。
二択に縛られない選択を
組織体制やコミュニケーションの在り方がプロジェクトを進める上で大切なポイントですので、
プロダクトだけに目がいきがちですが、組織やチーム、仕事の進め方にも気をつけましょう。
事業計画の策定についても、既存事業で要件が明確な場合は、
ウォーターフォールの様な確実性の高い計画を立案していくことが向いているのかもしれませんね。
新たに取組む要素があり、まだ企画段階で改良を繰り返しながらサービスをデザインする場合は、
アジャイル型の計画や体制、進め方を加味しておくと良いのかもしれないですね。
決して、ウォーターフォールかアジャイルかのどちらか二択ということではないです。
双方の良さを組み込みながら、適している体制かどうかも点検しつつ、DXプロジェクトを推進していきましょう。
それでは、皆さま本日もグッジョブ!!
ワークスアイディ株式会社
ビジネスデザイナー 奥西