はじめに 提案活動をはじめとするITコンサルティングを行ううえで、欠かせないのがシステムの見積り（規模/工数/工期/金額）なのですが、お客さま（発注側）からは詳細なRFP（提案依頼書）の提供もあれば、要求仕様（機能要件/非機能要件）等も不明瞭なメモ程度の提案依頼等もあり、その中で発注側及び受注側の双方が納得できる精度の高い見積りを作るのは至難の業です。 この見積もりの精度が低いと工数オーバーで予算が足りなくなり、プロジェクトが炎上したり、逆に、必要以上にリスク費用を見積りに乗せた結果、見積りが競合他社より高額となり、受注に結び付かないことが往々にあります。 また、提案するプロジェクトごとに要求されるシステムの実装形式や開発手法、開発言語等の開発条件の組み合わせも千差万別の中で、精度が高く正確な「見積り」を作成することは、プロジェクトの成否を分けるうえで非常に重要になります。 一般にソフトウ

きっとあなたは、開発工数の見積もりに失敗した事があるでしょう。 もし無い方がいればメッセージください。 もちろんその方は残業をしたことは無いのでしょう、 [残業をしてる]=[あなたの見積もりはまちがっている] 当たり前ですよね、あなたがお客さんに出した見積もりに残業代は含まれていないのですから。 そもそもなぜ見積れるのでしょうか？ ソフトウェア開発だけではなくもっと広いくくりで、なぜあなたが何かを測ることが出来るのかを考えてみましょう。 ・なぜあなたは、自分の身長を測れるのですか？ ・なぜあなたは、自分の体重を測れるのですか？ ・なぜあなたは、自宅から最寄り駅までの距離を測れるのですか？ ・なぜあなたは、そのソフトウェアの開発工数を測れるのですか？ それは物差しがあるからです。 ではソフトウェア開発工数を見積もるための物差しは何でしょうか？ それは過去の経験です。 過去の経験があるから、ソ

はじめに 本稿では、仕事をする上での作業工数の見積もり方法について説明します。 工数とは何か 工数(こうすう1)というのは、仕事において、あるひとつの作業を完了するまでにかかる総累計時間のことです。情報処理技術者試験に出てくるTAT(ターンアラウンドタイム)とは意味合いが異なります2。 例えば、ある作業に40時間(40H3)かかるとした場合、工数は40時間であるといえます。1日8時間勤務だとした場合、40時間は5人日(にんにち)と表現することができます。さらに、1ヶ月20日勤務だとした場合、0.25人月(にんげつ)と表現することもできます。 一般的に工数の単位は「人日」および「人月」で扱います。 学生時代は工数を気にすることはないですが、ITエンジニアとして会社で働くようになると、かならず工数を意識する必要があります。 なぜ工数を意識する必要があるのか なぜ工数を意識する必要があるのかとい

スケジュールについてPMが知っていなければならない、絶対原則。 完了日を1点で見積もるのは絶対にムリだ、ということ このことはエンジニアがタイトル買い、著者買いすべき本 - Fight the Future じゅくのblogでも紹介した本から学んだ。 ソフトウェア見積り―人月の暗黙知を解き明かす 作者: スティーブマコネル,久手堅憲之,Steve McConnell,田沢恵,溝口真理子出版社/メーカー: 日経BPソフトプレス発売日: 2006/10メディア: 単行本購入: 27人 クリック: 372回この商品を含むブログ (88件) を見る もしあなたがマネージャなら、最低でもマコネルの「ソフトウェア見積り」は読んでおいてほしい。 本に書いてあることをそのまま実践してほしいわけじゃない。 こうした英知をベースに見積もりやスケジュールを考えてみてほしいだけだ。 自分のプロジェクトに合わせてア

エンジニアが知っておきたい工数見積もり術！  無理ゲー進行 から脱するために大切なコト エンジニアの仕事に欠かすことのできない、工数見積もり。実際の現場でいくどとなく見積もりを行ってきた筆者が、「健全な進行」にするための工数見積もりのテクニックを伝えます。 アプリエンジニアの池田 惇（ @jun_ikd）です。今回は、エンジニアならば避けられない「工数見積もり」について考えてみたいと思います。若手エンジニアでも自分の作業は自分で見積もるようにするべきです。なぜなら、より正確に計画を立てられるようになれば、自分の時間をコントロールして学びや家族・友人との時間を確保できるからです。また、期日内に完了をさせることは周囲の信頼獲得に繋がります。工数の見極めはエンジニアとして、とても重要なスキルなのです。 なお、本稿での「見積もり」とは開発に必要な期間を予測することとし、見積もりが失敗する原因や対策

最初に、工事進行基準に関して簡単におさらいしておこう。 工事進行基準とは、＠ITのニュースによると「会計基準の変更によって2009年4月にシステムインテグレータ（SIer）など受注ソフトウェア開発業に原則として義務付けられる収益の計上方法。開発期間中にその売り上げと原価（費用）を、工事（ソフトウェア開発、システム開発）の進ちょく度に応じて、分散して計上する仕組み」とあります（「デスマーチがなくなる？ IT業界に義務付け『工事進行基準』ってなんだ」を参照）。 この工事進行基準を適用するためには、「工事収益総額」「工事原価総額」「決算日における進ちょく度」の3つを、信頼性をもって見積もることが必要となります。この3つの条件を工事進行基準適用の3点セットと呼ぶことにしましょう。工事進行基準に関しては、前述の記事のほかに下記の記事を参考にしてください。 この3点セットを見ても分かるように、どれもプ

プロジェクトを進めるうえで、トラブル発生による手戻りを未然に防止するほかに、進ちょくを測ったり、リスクを予測したりするためには、ドキュメントレビューが効果的である。ここでは、主要なドキュメントに対するチェックポイントを紹介する。 仕様書のチェックリスト 以下に仕様書の基本的なチェックポイントを紹介する（なお、第4回の「急がば回れ──質の良い仕様書の作り方」も併せて参考にしていただきたい）。 ソフトウェア開発というのは、意図するところを人間の言葉からいくつかの成果物（ドキュメント）を経て、コンピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水を途中でつぎ足すことは、なかなか難しいもの。早い段階──仕様書には“漏れ”がないようにしたい。 （1）題名は、システム名を明記しているか 仕様書の題名に「?システム仕様書」のように、システム名が明記されているか。“名は体を表す”