見積もり
諸情報
見積りから一般に見落とされるソフトウェア開発アクティビティ
１ 新しいチームメンバーの立ち上げに必要な起動時間
２ 新しいチームメンバーの指導
３ マネジメントとの調整／マネージャミーティング
４ カットオーバー／配置
５ データ変換
６ インストール
７ カスタマイズ
８ 要求の明確化
９ リビジョン（版）管理システムの保守
１０ ビルドのサポート
１１ デイリービルドを実行するために必要なスクリプトの保守
１２ デイリービルドと合わせて使われる自動スモークテストの保守
１３ ユーザサイトでのテストビルドのインストール
１４ テストデータの作成
１５ ベータ版テストプログラムの管理
１６ テクニカルレビューへの参加
１７ 統合作業
１８ 変更要求の処理
１９ 変更の調整／優先順位決定ミーティングへの参加
２０ サブコンストラクタとの調整
２１ プロジェクト期間中の既存システムへのテクニカルサポート
２２ プロジェクト期間中の前システムへのメンテナンス作業
２３ 欠陥修正作業
２４ パフォーマンスのチューニング
２５ 新しい開発ツールの学習
２６ 欠陥追跡に関する管理業務
２７ テストの調整（開発者に対して）
２８ 開発者の調整（テストに対して）
２９ 品質保証部門からの質問への回答
３０ ユーザードキュメントへの入力およびユーザードキュメントのレビュー
３１ テクニカルドキュメントのレビュー
３２ 顧客やユーザーに対するソフトウェアのデモ
３３ 展示会でのソフトウェアのデモ
３４ 経営上層部、クライアント、エンドユーザーに対するソフトウェアやソフトウェアのプロトタイプのデモ
３５ クライアントやエンドユーザーとのやりとり、クライアントサイトでのベータ版インストールのサポート
３６ 計画、見積り、アーキテクチャ、詳細設計、段階計画、コード、テストケースのレビュー
ソフトウェア開発アクティビティ以外で見積りから見落とされがちなもの
１ 休暇
２ 祝日
３ 病欠（、忌引）
４ トレーニング
５ 週末
６ 全社ミーティング
７ 部署ミーティング
８ 新しいパソコンのセットアップ
９ パソコン用の新しいバージョンのツールのインストール
１０ ハードウェア問題およびソフトウェア問題のトラブルシューティング
スケジュール
・納期を100%守るため、プロジェクトメンバー各自が大きくバッファのある期限を申告する。
・早めに終わった人でもギリギリまで時間を使ってしまうため、どこかの工程で遅れが出ると、結局それがそのままプロジェクトの遅れになる。
改善するためには
プロジェクトメンバーは個別にバッファをかなりとった期限を申告するのではなく、「できるかどうかわからない、ギリギリの期限」を申告する。
バッファは、プロジェクト全体の共有バッファと、クリティカルパスへの合流地点での共有バッファにのみ取っておく。（バッファは、個別の作業者でそれぞれ分けるのではなく、プロジェクト全体で共有する）
スケジュール見積もりの幅
例えば、今から始まる製品開発プロジェクトがある。顧客への販売は12ヵ月後とする。プロジェクト責任者が製品完成までの納期を見積もらせたところ、見積は、「11ヵ月で製品開発終了しますので、1ヵ月程度の余裕があります」ということだった。
実は、12ヵ月後に予定通り顧客に納品できる確率は５０％程度である。
下のリンクにある、IBMの資料によれば、11ヵ月で終わります、と見積担当が言う時は、実際には次のようなことを言っているにすぎない。
”11ヵ月で完了するという見積もりは、正しくは「11ヵ月で完了する可能性がピークにある確率分布である」と理解すべきなのです。”
”11月より前に完成する可能性は約１０％です。11月中に完成する可能性は約３０％。12月中に完成する可能性で４８％です。ちなみに８０％の確率で終わる日付は、来年の2月です”
仕事を確実に、予定どおり終わらせるための条件
1.不確定要素を出来るだけ少なくする。（そうすれば、見積の幅は狭くて済む）
2.タスクの時間見積は確率分布であることを認識する。
3.見積を幅で示し、リスクを織り込んだスケジュールを作成する。
普通に見積もった問題点
・見積もりが自己流。研修などは受けていないし、そもそも組織内で開催されていない。
・どうやって見積もったらいいかわからない。とりあえず人月や人日は出すが、自信が持てない。
・過去データからの推測しての見積もりや、単純にタスクを積み上げて見積もるくらいしかできない。
・見積もりの正確性が低い。タスクの見落としや過小評価のせいで、見積もりと実績が乖離している。
・見積もりの有用性が低いので、計画を立案しにくく、変更にも弱い。結果、作業効率が落ちる。
・見積もりと実績についてどのように効果測定をしたらいいかわからない。また、その時間もない。
経営陣は「見積もった結果、間に合わないと思われます」という情報が欲しいのではなく、「間に合わせるための計画」や、「間に合わせるために諦める機能を選ぶための判断材料」や「そのための追加コスト」などの情報
納品のない受託開発
http://www.slideshare.net/kuranuki/sg-management
受託開発の問題
発注者と受注者でのゴールの違い
あとで直せないからと詰め込む要求
使う価値よりも、要件定義に従う
生産性が低いほど、高くなる見積もり
インターネット時代の開発
小さく初めてから大きく育てる
事業の成長にあわせて改修
外注は柔軟性が低くて金額が高い
内政は開発者の採用と育成が困難
これからの受託開発
要件の予測は困難で日々変化する
ユーザが使い始めてからがスタートとなる
システムの完成を目指していない
長期的視野と経営視点を持つ
納品のない受託開発とは
⽉額定額で、開発と運⽤用を続ける
顧問として全ての工程を担当する
働く時間でなく、成果を提供する
ビジネスの成長をITで⽀支えていく
納品のない受託開発で得られる顧客のメリット
「要件定義」をしなくてもよい
「仕様変更更」はいつでも出来る
直接エンジニアに相談しても良い
「作らない提案」をしてもらえる
プロフェッショナルの仕事
「納品のない受託開発」でやっていないこと
ドキュメントは⼀切、作りません
お客様のところには訪問しません
なんでもする営業担当はいません
納期を死守する約束はできません
圧倒的な費⽤対効果を実現
顧客プログラマ
プログラミングで問題解決をする
コンサルティングができる開発者
分業の効率化よりも属⼈性を重視
個⼈の集まりでなくチームを重視
ナレッジワーカーとして働く
「直感」ではなく「価値観」に従って経営する
論理的 ： 理にかなっていること
堅実さ ： 一か八かをしないこと
迅速さ ： ⼩さく試してみること
本質的 ： 形にこだわらないこと
公平さ：全員が幸せになること
プランニングポーカー
Last updated