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

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

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

挙に朝晩の冷え込みが厳しくなってきました。夏物衣料と冬物衣料の間で揺れ動いていたキットPMですが、自分の考えの甘さを嘆いている今日この頃です。

 

  でもこの冷え込みで、来週からは何の心配もなく衣替えができるというものです。

 

image

回、要件定義と呼ばれるITシステム開発におけるフェーズの2重階層について考えました。一つは経営視点で業務の効率を考えるもので、もう一つはそれをシステム開発視点で捉えるものでした。この2つは目的も思考も異なるので、基本的に分離すべきものであると考えを進めました。

 

  そのため最近では、この異なる2つの領域を開発者がすべて担うのではなく、コンサルティングと開発という2つの機能で分担することが多くなってきています。つまり、プレイヤーが全く違うということです。

 

  前者が経営コンサルタントであり、後者がシステム開発者となります。

 

 

 

ころが、分離したために別の問題が起きるようになりました。コンサルタントが作成したアウトプットが開発者に正確に伝わらないのです。

 

  原因はコンサルタントが作成した膨大な資料を、開発者に伝えるコストをちゃんと用意しなかったことにあると、キットPMは考えています。

 

  プロジェクトスポンサーから見ると、その作業自体の必要性を事前に理解し、計画されていないということ、引き継ぎというある意味何も生み出さない作業にかなりの予算をつぎ込まないといけないということなどの条件が重なり、つい見過ごされその結果しわ寄せが後工程である開発者に及ぶことになります。

 

 

 

の結果、開発者は説明不十分な資料を元に、自分が納得できる資料を再構築するか甚だしい場合は、一から要件定義を始めてしまいます。ユーザーから見ると2重投資ですね。

 

  開発者(多くは外部ベンダー)は最終的に動いてユーザーの業務が支障なく遂行できることを”保証”しなくてはいけないので、ある意味納得が行く話だと思います。

  コンサルタントは、ちゃんとスポンサーに内容を説明して引き継ぎを済ませたのだから、自己の責任は果たしたと考えます。これも納得が行きます。

 

  とすると、この引き継ぎ部分を意識して、適切な対応をとれなかったスポンサーに問題があるということになります。でもこの指摘をそれまで誰もしてこなかったのです。これで上手くいくわけありません。

 

  蛇足ですが、キットPMが経験したのは、コンサルタント会社と開発会社が同じグループの企業であったにもかかわらず、全くと言っていいほど引き継ぎが行われず、結果としてプロジェクトの予算が大幅に増えてしまったというものでした。まっ、それほど難しいというか、認知されていない分野だったわけです。

 

  ただ、弁護するわけではないのですが、先に述べたように2つの作業は、その観点が異なり、作業の目的も違うわけです。相手が何を考えているのか、何を意図しているのかなど間に立って翻訳する役割の人がいないと、例え引き継ぎのための予算と時間をとっても、あまり良い結果を得ることはできなかったでしょう。

 

 

 

れを解決するためには、両者の接着剤となる役割が必要となります。それがBA(ビジネスアナリシス)だと、きっとPMは考えています。

 

  BAは役職や能力を指す言葉ではなく、機能を表すものです。また、一人の個人がその機能を果たせるものでもありません。なぜならBAが持つ業務範囲はとても広いため、集団で期待される機能を果たすしかないからです。

 

 

 

回もBAの業務について簡単に触れてから、テーマである「要件定義とアジャイル開発」に話を戻すことにします。