【640】要件定義とアジャイル開発 -11- | キットPM奮闘記 改め キットビジネスアナリスト奮闘記

キットPM奮闘記 改め キットビジネスアナリスト奮闘記

PMの世界からビジネスアナリストへ、キットPM2.0を目指して奮闘中です。BAを超上流とか言いますが、当たり前のようで難しいビジネス要件をどうやればちゃんとまとめられるのか、皆さんとご一緒に考えていきます。

週で11月も終わりいよいよ師走が始まります。毎年のことですが10月からの3か月は、一年の中でもやたらと早く過ぎ去るように感じます。またその感が年々強くなって行くのは年を取った証拠でしょうか。

 

  ということで、年も押し詰まって来ましたが、周りの慌ただしさに振りまわされることなく、着実にやるべきことをやってこの一年を締めくくりたいものです。

{2D646560-599C-40C2-8D81-B8F1CCD24343}

ジャイル開発スタイルを、現実のITシステム開発に適用しようとしたとき、幾つかの障害がある事はすでに述べました。

 

     最も大きな課題は、言うまでもなくプロジェクトスポンサーを始めとする多くのステークホルダーのアジャイルに対する理解が不充分な事にあります。ただそれも、ある意味仕方がないことなのです。

 

 

 

ットPMの会社で2年ほど前に実施した調査では、業種にもよりますが、一般企業の中で毎年なんらかのIT投資プロジェクトを行っている企業の売上高は1,000億円以上であり、常に複数の大型プロジェクトが動いている企業規模は、1,500億円~2,000億円を超える企業でした。キ

    逆に1,000億円以下の売上高の企業では、億を超えるITプロジェクトを実施するのは数年から十数年に一度といった状況でした。

 

    もちろん流通業やハイテク製造業、医薬系など情報をどうコントロールして活用するかが、売上高に直結する様な業界もありますが、特にITを高度活用する必要のない(と未だに思い込んでいる)一般的な企業では、おおよそこの様な状況となります。

 

    つまり、多くの中堅、中小企業ではプロジェクト自体に触れる機会が少なく、プロジェクトのスタイルや、方法論について考える必要性がないということになります。余談ですが、この現実を明確に認識したときは、チョット目眩がしてしまいました。

 

 

 

の様な状況の中必然的に多くの企業は、プロジェクトの実行とプロジェクトマネジメントをSIerに任せることになります。

 

    そしてSIerは、顧客企業が予算を確保しやすいような提案と見積もりをするわけですから、どうしても従来型のスタイルを提案することになります。

    かくしてアジャイル開発スタイルは、我が国ではマイナーままであり続けるわけです。

 

閑話休題

 

がいささか逸れてしまいましたが、アジャイルスタイルを一般的にするために、これまで分析してきたような社会構造(ストラクチャー)を新しい構造に切り替えていくのか、それとも既存の構造の中に新しい要素を入れ込んで行くのかは、難しい課題です。

 

     効率から考えると一気に変えていく方が良いのですが、そこに大きなメリットを社会が認知することが必須です。しかもそのためには、プロジェクトの失敗という大きな痛みを伴うこともあり簡単ではありません。

 

    そこで次善の策として、アジャイル開発スタイルをウォーターフォールスタイルに、部分的にでも適用できないかと考えたわけです。やっと本題に戻って来ました。

 

 

 

て前回考えたのは、アジャイルスタイルをレベルで区分して考えるということでした。レベルで考えるという事はいったいどういうことでしょうか。

 

    これを考える前に、キットPMが考えるアジャイル開発スタイルの特徴について、今一度言及しておくことにしましょう。

 

  アジャイルスタイルの開発は開発のための手法ではなく、ソリューションを生み出す行為全体の手法であり、計画からリリース、運用までの行為の全てを包含するものです。特に効果的なのは、どのようなシステムを望んでいるのかを、クライアントもしくはユーザー自身が考え、評価する過程が含まれるということです。

 

  これは、要件定義というイメージで語る世界から脱出し、現実を評価するという手法に変わることで、無駄なく必要とするシステムを構築するということに他なりません。

 

 

 

回は、いよいよアジャイルスタイルと要件定義の関係を掘り下げていくことにします。