導入しやすい工数見積もり手法とは
なぜ、モデルによる工数見積もりが普及しないのか 実際のエンタープライズ系ソフトウエア開発では、モデルを使った見積もりは全体の7％にすぎない。なぜモデルを使った見積もりが普及していないのか？今回は2つの理由を考えた上で、amazon.comの「推薦システム」などで採用されている協調フィルタリングの手法をモデルによる工数見積もりに応用し、新しい可能性を探る。 普及を妨げる理由の1つは、個々の見積もりモデルの適用可能範囲が狭く、自分たちのプロジェクトには当てはまらない可能性がある、という開発者の不安である。別の言い方をすれば、多様なソフトウエア開発プロジェクトを、1つのモデルで表現することの難しさである。例えば「モデルによる見積もりを自社プロジェクトに導入しようとする技術者」と「見積もりモデルに懐疑的なプロジェクトリーダー」との間では、図1のような会話が交わされることになる。 従来の工数見積もり
工数見積もりの見える化
なぜ工数の見積もりが必要なのか 最近ソフトウエア業界で話題となっている工事進行基準でも、「工事進ちょく度の計算根拠となる工事原価総額が信頼性を持って見積もられなければ工事進行基準を適用することができない」と述べられているように、ソフトウエア開発における工数見積もりの重要性はますます高くなってきている。 「見積もる」という言葉を広辞苑（こうじえん）で引くと、「1. 目で見て大体を測る。目分量ではかる。2. 物事のあらましを考え計算して予測を立てる。つもる。概算する」とある。ソフトウエアの工数見積もりは、2.の意味、つまり、対象となるソフトウエア開発のあらましを頭に描き、投入されるであろう、あるいは、投入すべき工数を予測する、ということになる。 ソフトウエア開発管理の主な観点はQCD（品質、コスト、納期）である。厳密にいえば、工数（人月）はコストとイコールではない。しかし、工数に基づき算出され
見積もり仮想体験、準備から始めるべし
見積もりを行うための準備 前回の「見積もり、まずはざっくり理解せよ」では、「ソフトウェア開発のプロジェクトとひと口にいっても、（中略）見積もりの対象の要素が異なるソフトがたくさんあります」と書き、「ソフトの特性によって使うべき見積もり手法も分かれるのが普通」と紹介しました。 それらの見積もりの手法を試し、尺度を用いて見積もりを実際に作っていくための準備をしましょう。 今回は、アーキテクチャやシステム特性にあまりこだわらず、少し簡単なプロジェクトを題材にしたいと思います。 機能の広さや、タスクの深さ、品質の重さといった、前回の「見積もり、まずはざっくり理解せよ」の図のように、3次元の軸を考えながら見積もり作業を進めたいと思います（図1）。 今回は、見積もりの対象となるアーキテクチャを絞ります。 読者の中で比較的多くの方が携わっているであろう.NETのWebアーキテクチャを用いたクライアント／
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
