![見出し画像](https://assets.st-note.com/production/uploads/images/54354212/rectangle_large_type_2_6beeb795b8f012f3c5735c6d90d33d32.png?width=1200)
#13.2.2.【DXの本質】 なぜ、アジャイルで開発するのか?
前回、「プロジェクトの構造の欠陥」を指摘しました。
ビジネスとシステムの間には時間と空間、双方のギャップが生じるということを認識しておくべきです。
今までの、ウォーターフォール型のシステム開発では、今後のビジネス環境の変化に対応できません。環境の変化がはやく、大きいのでその変化にウォーターフォール型の対応では対応しきれないのです。
では、この構造問題にどう対処すべきでしょうか?。
まず最初にすべきは目的の共有です。「Goal Share」です。ここでも、登場する「Whyから始めよ」ということです。
ゴールを共有した上で、そのゴールにブレはないか、ゴールに向かってシステム構築は進んでいるか?を評価する必要があります。
そのコミュニーケーションの方法論としてアジャイル開発によって、動いているものを確認しながら進めるべきです。単なるスパイラルなプロトタイプの構築ではなく、ゴールの共有としてアジャイルです。
「ゴール共有としてのコミューケーション」
それが、
「なぜアジャイルで構築するのか?」の答えです。
変化が、大きくはやい環境においては、常に変化を捉えてコミニケーションをとり、常にゴールを共有することです。アジャイルを活用するのはあくまでもコミュニケーション手段の一つなのです。
アジャイル開発を行う上での重要な7つのポイントをあげます。
1.発注者、受注者の関係ではなく、ビジネスパートナーの関係へ
発注者、受注者の関係でなく、お客様のビジネスのゴールを共有し、ビジネスパートナーとしてともに実現する。
2.システムありきの開発ではなく、ビジネスの目標をゴールとする
システムの導入を目的とせず、ジネス目標を共有し、その目標を共に実現することを前提とする。発注者、受注者の関係、一括請負契約から脱却し、ビジネス成長に必要なサービスを提供する。
3.経営−業務−システムを分断しない、ワンストップサービス
総合的なサービスをワンストップで提供上流と下流を分断しない。(ベンダーロックインではなくビジネスパートナーとして寄り添う)
4.システム機能主義から、ビジネスプロセス中心主義
一度にシステム全体を作るのではなく、「業務のかたまり」毎にシステムを改善・改修する。変更する要素毎にマイクロサービス化し、カプセル化する。
5.請負型システム開発プロセスのムダを極限まで排除
→ 要件定義は変わることが前提、全てを決めない。要件定義から要件提案へ。
→ 設計書についてもキレイなものは作らない。動いているものが「正」。
→ マイクロサービスとAPIによるモジュール化。
→ プロジェクトの終わりをゴールとしない。
→ベンダーに依存しない、技術に依存しない、パッケージに依存しない。
6.開発プロセス、体制、進め方の改革(One Teamによるコミュニケーションと可視化)
チームを分断しない。要件の提案から実装、テスト、運用・保守を含め、ユーザーと同じゴールを共有したチームを構築する。
7.環境変化への柔軟対応と適切なIT投資の実現
はやいスピード変化する環境に対して適切な投資で構築する。SCRUMのようなアジャイルプラクティスを活用することで、動いているものを見て確認してコミュニケーションを図りながら顧客のゴールに近づけていくことです。顧客は自分の本当に欲しいものを明確にわかっていません。動くモノを見てアイデアが出ることもあるのです。
ベンダー側のアプローチとしては、要件定義ではなく、要求提案という形で進めるべきです。顧客は、要求の10全てを明確に伝えることはできない、”1”聞いたら”10”理解して、”12”くらいの提案をするのです。
【Goal Share! 】
システムの機能ではなく、ビジネス課題、業務課題を実現する方法を考え、そのソリューションを提供する。要件に対して、動いているもの届ける、使えるものをリリースする。要求の本質から、”1”のインプットに対して“10”理解する。そして、目的を達成するための”12”の提案をする。10理解し、12のアウトプットです。
最初から、全ては、決まらないという前提、変化があって当然。変化があって当たり前なのです。新しいアイデアはビジネスを良くするためには、発生すべきで、現在だけでなく未来も見据えることが重要なのです。
失敗しないプロジェクトの本質は、「ゴールの共有:(Goal Share)」に他ならないのです。
この記事が気に入ったらサポートをしてみませんか?