今日の南関東の天気予報は晴れ時々曇りだったのですが、この時間だんだん曇ってきて今にも降り出しそうな塩梅となっています。午前中素晴らしい天気だったので、残念です。

さて、プロジェクトの要件定義フェーズについて考えています。

　　要件定義作業の前提となる現状業務について、整理し全体を理解する行為を継続的に行っている企業はキットＰＭの経験(限られたものですが)から言うと、それほど多くは無さそうです。”継続的に”というのは、常に変化していく業務をタイムリーにかつ的確に把握しているということです。

　　そのため、部門を横断するようなＩＴシステムの開発プロジェクト（つまり、基幹系システム開発、更新プロジェクトのことです）であっても、開発プロジェクトが現状分析に責任を負うことがあります。

少しテーマからはそれてしまいますが、重要なので少しひも解くことにします。

現状業務分析とシステム開発という、性質（目的と手法と責任範囲）が異なる行為を、一括りにしてプロジェクト化するのは無理があります。

これは、発注者側の責任と請負側の責任を曖昧にすることで、双方がメリットを得ていたという日本のシステム作りの歴史的な経緯を考えると、それもいた仕方ない部分もあるのですが、さすがに最近ではこのことが問題として捉えられるようになりました。かといって社内で問題を解決する仕組みを構築するのは、結構大変なことになるようです。

そのため、現状分析から課題を抽出し改善策を立案するとこまでをコンサルティング会社に委託し、その結果をSIerが実現するというステップを踏む場合が増えて来ました。

ところが正しく見えるこのアプローチには大きな落とし穴が潜んでいます。それは、２つの行為が完全に分離した状態で実行されるということです。先ほどの話しと矛盾するようですが、全く性質の異なる作業でありながら、この2つにはとても密接な関係があるのは明らかです。

キットPMは、この明確でありながら見落としがちな事実のため、ITシステム開発プロジェクトがトラブルに巻き込まれ、頓挫することを何度か経験したことがあります。

最上流と呼ばれる、プロジェクトスポンサーのビジネスを理解し、分析し、課題を抽出し、それを解消するアイデアを提示するという一連の行為は、当然のことながら経営者の視点で行なわなければいけません。何故なら組織の活動をその目的のために最適化することが役割だからです。

ところが、それこからのアウトプットを受け取って具体化するステップで必要になるのは、要求をシステム的な視点で捉え、具体的で確かに動くシステムを効率良く実現することです。

このとき、前者で検討された内容を後者が十分に咀嚼し理解することがとても重要なことになります。つまり、開発者にとって理解するための時間(=費用)が必要だということですが、先に述べたようにそこに時間とお金をかけることはなかなか許されないことが多いのです。

では、経営視点と開発者視点の接着剤となるものとはあるのでしょうか？次回はこれを考えて行くことにします。

【632】要件定義とアジャイル開発 -4-

【632】要件定義とアジャイル開発　-4-