もんさん見せる

もんさんがいろんなところで拾ってきた情報をみんなに見せるブログです。

アジャイルな見積りと計画づくりから見えてきた事



広告:

Gear
Gear / avrene

 

昨日読んだこのブログ記事がとても興味深かったので、インスパイアされてみようと思います。

なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;

 

このブログで紹介されている本自体は、結構昔にたまたま読んだ事があります。今では細部までは思い出せませんが。Amazonでレビューを見てみても、レビュー件数こそ多くありませんが、非常に評価が高くなっています。

見積り作成に興味のある方は読んでみると面白いと思います。

 

今回このブログでは、シバさんの記事から見えてきた、それぞれの立場ごとの「見積り失敗」を見ていきたいと思います。

 

今回も物語形式で行ってみます。

 

1.見積り依頼者から見た「見積り失敗」

20XX年に作られたA社の経理システムは、ハードウェアとソフトウェアのライセンスサポート切れを目前に、再構築をするプロジェクトが立ち上がりました。

 

社内の情報システム部に所属する遠藤さん(仮名)は、このプロジェクトに参画し、社内の要件のとりまとめとSierの選定をまかされる事になりました。とは言っても、このプロジェクトは再構築プロジェクトであるため、基本的な要件は既存のシステムに従えば良く1から要件をまとめる必要はありませんでした。

 

ただ、一点だけ懸念があるとすれば、3年前に合併を行った関連会社B社の経理システムも取り込んで1つのシステムとする事でした。合併後もB社分の経理システムは現在まで使い続けており、A社のシステムとはオフラインでデータを統合するという手間が発生していました。

 

遠藤さんはそういった点を要件に盛り込み、Sier3社に対して入札を行う事にしました。入札にかける時間は2ヶ月ほどです。各Sierの見積りの特徴としては、提案書の内容が非常に良く、価格がそこそこのX社、提案書の内容は必要最低限満たしていて、価格が一番安いY社、提案書は可もなく不可もなく、価格は一番高いZ社という形でした。

 

遠藤さんは社内で検討を重ねた結果、価格に換えられる物はないという判断のもとY社の提案を受け入れることにしました。

 

 

要件定義の終盤に差し掛かった頃、Y社より工数とスケジュールの見直しができないかという提案が出てきました。遠藤さんはY社の提案を簡単には受け入れられないと思いながら、まずは内容を確認しました。

 

工数とスケジュール見直しの理由としては、A社B社間で共通と思われていた同じ機能名の仕様を確認すると、同じ機能でも処理内容に多くの違いがあり、簡単に統合する事はできないからと言う事でした。

 

遠藤さんは要件を取りまとめるときに、A社とB社で機能名が違うところは問題なくまとめていたのですが、同じ機能名のところはA社の機能をそのまま使えるだろうと思い、省略して取りまとめていました。

 

しかし、実際にはB社のまとめられてしまった機能の中には、B社独自の処理が含まれており、また、そこでの処理結果が別の機能に引き渡されるため、矛盾がおきることが明らかになっていました。

 

遠藤さんは社内調整の上、工数とスケジュール、そしてそれに伴うトータルコストの見直しを行う事になりました。

 

dayafterchristmas
dayafterchristmas / marissa
 

2.見積り作成者から見た「見積り失敗」

Sierのプロジェクトマネージャーの東さん(仮名)は、A社の社内経理システムを見積る上で、過去の知見からまずは概算のあたりをつけていきました。

 

東さんは過去にも経理システムを立ち上げた経験があるため、プロジェクトに潜在するリスクについては十分に理解しています。また、このプロジェクトが受注できれば、過去のプロジェクトで同じチームのキーパーソンだったメンバーの原さん(仮名)を参画させることができそうでした。彼がまた同じチームとなれば、作業効率は非常に高くなりそうな予感がありました。

 

東さんは、メンバー育成も兼ねて、原さんに見積りのたたき台を作ってもらう事にしました。原さんは見積り作成を行った事はありませんでしたが、過去の類似案件での見積り方について東さんからレクチャーを受け、A社の遠藤さんがまとめた仕様から見積りのたたき台を作成しました。

 

東さんは原さんの作った見積りのたたき台を見て、若干工数が少ない気がしましたが、作業効率が上がりそうなことと、東さん自身が考えていた概算コストから大きく離れていないことから、想定されるリスク分を多少上乗せした以外は、ほぼ原さんの見積りベースで勧める事としました。

 

その結果、めでたくA社の経理システムを受注する事ができました。

 

 

要件定義を進めていく中で、遠藤さんのまとめている仕様にいくつかの穴がある事がわかって来ました。しかし、要件定義がある程度締めの段階までくる前に、工数やスケジュールに跳ね返すのは東さんとしては時期尚早と考えていました。それは、これまでの経験上 想像以上に工数が必要となるケースもあれば、逆に工数を削る事ができるケースもあるからです。

 

しかし、残念ながら、要件定義が終盤まで差し掛かっても、工数を削る方向には進みませんでした。B社の経理システムを統合する事に関しての仕様の穴がだいぶ大きかった為です。

 

東さんはプロジェクト全体に大きな影響を及ぼす前に、まだこの段階であれば多少の傷ですむと思い、工数とスケジュールの見直しを遠藤さんに伝える事を決意しました。

 

3.プロジェクトメンバーから見た「見積り失敗」

プロジェクトマネージャの東さんは、要件定義の後のフェーズでは工数とスケジュールが変更する必要があり、それをA社の情報システム部につたえたこと、それによりこの後の受注がどうなるか、白紙となる可能性もあることをプロジェクトメンバーに伝えました。

 

原さんを含めたプロジェクトメンバーは、要件定義の中ですでに工数とスケジュールの見直しに付いて検討を行っていたため、内容としては理解していました。しかし、プロジェクトの設計段階から急に仕事が無くなってしまう事に危機を感じていました

 

プロジェクトメンバーは、仮に変更の提案が通り今後の受注が取れたとしても、プロジェクトは厳しいものになるだろうと考えていました。変更提案に盛り込んだ内容は、いくつかの機能の実装を見送るか、設計ができたところから開発に入る五月雨式に進めるというものでした。実施する上でローリスクとは言えません。

 

高負荷の状態が数ヶ月は続きそうな状況に、暗雲が立ちこめます。

 

Blocks
Blocks / karimian
 

まとめ?

今回のケースは遠藤さんに発端し、プロジェクトに暗雲が立ちこめるという少し暗い展開となってしまいました。ただ、原因はさておき実際に起こりそうなレベルではないでしょうか。

 

ここで、改めて「アジャイルな見積りと計画づくり」について考えてみます。Sierが先に決まっている様な状態ではアジャイルな見積りができるかもしれませんが、複数社から見積りを取るような状況では、そういったことは出来ず、要求を満たしている中での最安値を取るということになると思います。

 

仮にアジャイル的な要素を入れるとすると、

  • 要件定義、設計、開発等のフェーズごとに入札を繰り返し、その都度最適なSierと見積りを選定する
  • 入札期間を通常より2、3ヶ月長めに取り、複数回の提案とフィードバックにより最適な見積りを提出させる

のどちらかの形になるかと思います。後者の方が少し実現性は高いかもしれません。

この本が遠藤さんのデスクに置いてあれば、話は変わっていたかもしれません。


おしまい。

 

※この話はフィクションです。氏名や会社名は全て実際とは関係ありまへん。

 

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

 

 

広告を非表示にする