前回、「プロジェクトの構造の欠陥」を指摘しました。

ビジネスとシステムの間には時間と空間、双方のギャップが生じるということを認識しておくべきです。

今までの、ウォーターフォール型のシステム開発では、今後のビジネス環境の変化に対応できません。環境の変化がはやく、大きいのでその変化にウォーターフォール型の対応では対応しきれないのです。

では、この構造問題にどう対処すべきでしょうか？。

まず最初にすべきは目的の共有です。「Goal Share」です。ここでも、登場する「Whyから始めよ」ということです。

ゴールを共有した上で、そのゴールにブレはないか、ゴールに向かってシステム構築は進んでいるか？を評価する必要があります。

そのコミュニーケーションの方法論としてアジャイル開発によって、動いているものを確認しながら進めるべきです。単なるスパイラルなプロトタイプの構築ではなく、ゴールの共有としてアジャイルです。

「ゴール共有としてのコミューケーション」
それが、
「なぜアジャイルで構築するのか？」の答えです。


変化が、大きくはやい環境においては、常に変化を捉えてコミニケーションをとり、常にゴールを共有することです。アジャイルを活用するのはあくまでもコミュニケーション手段の一つなのです。

アジャイル開発を行う上での重要な７つのポイントをあげます。

１．発注者、受注者の関係ではなく、ビジネスパートナーの関係へ
発注者、受注者の関係でなく、お客様のビジネスのゴールを共有し、ビジネスパートナーとしてともに実現する。

２．システムありきの開発ではなく、ビジネスの目標をゴールとする
システムの導入を目的とせず、ジネス目標を共有し、その目標を共に実現することを前提とする。発注者、受注者の関係、一括請負契約から脱却し、ビジネス成長に必要なサービスを提供する。

３．経営−業務−システムを分断しない、ワンストップサービス
総合的なサービスをワンストップで提供上流と下流を分断しない。（ベンダーロックインではなくビジネスパートナーとして寄り添う）

４．システム機能主義から、ビジネスプロセス中心主義
一度にシステム全体を作るのではなく、「業務のかたまり」毎にシステムを改善・改修する。変更する要素毎にマイクロサービス化し、カプセル化する。

５．請負型システム開発プロセスのムダを極限まで排除
→ 要件定義は変わることが前提、全てを決めない。要件定義から要件提案へ。
→ 設計書についてもキレイなものは作らない。動いているものが「正」。
→ マイクロサービスとAPIによるモジュール化。
→ プロジェクトの終わりをゴールとしない。
→ベンダーに依存しない、技術に依存しない、パッケージに依存しない。

６．開発プロセス、体制、進め方の改革（One Teamによるコミュニケーションと可視化）
チームを分断しない。要件の提案から実装、テスト、運用・保守を含め、ユーザーと同じゴールを共有したチームを構築する。

７．環境変化への柔軟対応と適切なIT投資の実現
はやいスピード変化する環境に対して適切な投資で構築する。SCRUMのようなアジャイルプラクティスを活用することで、動いているものを見て確認してコミュニケーションを図りながら顧客のゴールに近づけていくことです。顧客は自分の本当に欲しいものを明確にわかっていません。動くモノを見てアイデアが出ることもあるのです。

ベンダー側のアプローチとしては、要件定義ではなく、要求提案という形で進めるべきです。顧客は、要求の10全てを明確に伝えることはできない、”１”聞いたら”10”理解して、”12”くらいの提案をするのです。
【Goal Share! 】

システムの機能ではなく、ビジネス課題、業務課題を実現する方法を考え、そのソリューションを提供する。要件に対して、動いているもの届ける、使えるものをリリースする。要求の本質から、”１”のインプットに対して“10”理解する。そして、目的を達成するための”12”の提案をする。10理解し、12のアウトプットです。

最初から、全ては、決まらないという前提、変化があって当然。変化があって当たり前なのです。新しいアイデアはビジネスを良くするためには、発生すべきで、現在だけでなく未来も見据えることが重要なのです。

失敗しないプロジェクトの本質は、「ゴールの共有：（Goal Share）」に他ならないのです。