→プロジェクト管理
→要件定義・基本設計
→顧客対応
見積もり †
- ついに登場！ 究極の見積もり技法（その4：最短開発期間の算出） 2012.3.14
- SLIMと最短開発期間。
- “開発エンジニアを何千人・何万人投入したとしても、『この期間』よりも絶対に短く開発することはできない”という「最短開発期間」の計算方法を解説します。開発規模（例えば、ソースコードのステップ数）が予測できていれば、ほんのわずかの時間で最短開発期間を算出できます。
- Web制作の見積もりの出し方について改めて考えてみました。 2012.1.17
- 正確な見積もりはデスマーチ・プロジェクトを救うか？ 2011.5.24
- 実際に必要な開発期間の半分しか割り当ててもらえないプロジェクトを「デスマーチ・プロジェクト」と言います。
- デスマーチ・プロジェクトの無理難題の前では、正確な見積もりは予想外に無力なのです。
- 相手の提示条件に対し、説得力のあるデータを示して「ノー」と言うこと。提示された条件では開発が不可能であることを客観的に証明する必要がある。このためには、非常に高度な見積もり能力が不可欠
- 相手の条件内でできる作業を提案すること。このためには、開発規模を動的に変更できるようにしておく必要がある
- WBSを学び、見積もり・進ちょくに役立てよ！ 2009.10.13
- プロジェクトマネジメントの現状
- その1：中規模以上では4割以上のプロジェクトで納期遅れが発生
- その2：中規模以上では約3割のプロジェクトで品質に不満
- その3：大規模プロジェクトの5割近くでコスト超過が発生
- （【感想】最近のプロジェクトの失敗の多くは技術的、能力的な問題ではないのでは？そもそも最初に「これならばできる」っていう見積もりやスケジュールや予算ではないのにプロジェクトが強行されているでしょ？なんで皆そこに触れない？）
- プロジェクトの失敗は見積もりの失敗 2009.2.28
- 失敗に至るプロジェクトのパターンはいつもワンパターン。
- 要件定義、設計と進みながらも、システムのスコープや細部を詰め切れず、裏ではRailsやSeasarなどの新技術を取り入れて実装を並行開発する。
- そして、殆どの画面を作った後も仕様変更が五月雨式に落ちてきては手直しし、結合テストやシステムテストで初めて稼動させた時に、大きな穴に気付く。
- いくらテストしてもバグが落ち着く傾向も無く、延々と残業と休日出勤が続く。
- 品質が安定しない状態のまま、最後は納期も遅れてしまい、投入した人員では足りず、火消しやヘルプの人員をどんどん投入して、何とか鎮火させる。
- 前提条件を無視してはいけない 2009.1.30
- なぜ，不採算プロジェクトとなるのか。それはベンダー，ユーザーお互いが，見積もりに明示されていない前提条件を都合よく解釈するからである。
- では，どうすればよいか。要件があいまいな部分や決定していない事項については，仮の要件を設定して見積もればよい。仮の部分を「前提条件」として明文化し，前提条件が変われば見積もりも変わることをユーザーとベンダーが合意しておくことがポイントである（表）。
- 見積もりが高いといわれたら。Noという交渉術 2008.7.23
- おかしな話には「No」といいます。無茶に対しては無理といいます。交渉決裂は重要なカードです。理不尽な客を切れる「コスト」と考えれば妥当です。
- 交渉結果が必ずしも望むものになるとは限りませんが、「No」により決裂したとしてもそれが最善であれば問題ありません。そして意外に思うかも知れませんが「No」といってまとまる話も多く、「できないこと」を明示する姿勢は高く評価されます。
- ファンクションポイントを過信してはいけない 2008.6.18
- FP法はユーザーが識別しないものは機能とみなさない
- PMは，FPの持つ本来の意味を十分理解しておく必要がある。FP値はあくまで規模を表す数値であり，工数ではない。従って，見積もりを提出する際の数値的な根拠として用いる場合には，必ず生産性係数とセットとなることを忘れてはならない。契約で必要となるのはあくまで金額であって，FP値といった指標ではないからである。どんなFP値であっても，生産性係数がなければ，システムの規模を表す指標の一つに過ぎない。
- ところが，生産性係数の値の決め方一つで，見積もり金額は高くなったり低くなったりする。そのため，見積もりを算定する場合には，この生産性係数がFPと同等以上に重要なファクターとなるのである。しかし，システムの特性に応じて開発難易度を考慮し決定するというのは容易ではない。ベテランのPMですら間違うことがある。
- 移行は全工程の4割を費やす 2008.3.17
- 単純なサーバー・マシンのリプレースなどは別として，システム移行には新システム構築に匹敵する工数がかかる。
- 移行の要件定義・開発（20％）とリハーサル（15〜20％）を合算した移行関連の工数だけで，「全体の35〜40％に達する」
- →データ移行
- 論点ちがうよ、web屋さんたち 2008.2.22
- Web屋さんお願いしたい１０個のこと。
- 1. Web製作の全体の流れについての説明を省略しない
- 2. どういったときに追加コストがあるのか明確に決めておく
- 3. リスクやトレードオフになっている事項を細かく洗い出しておく
- 4. 見積もりの明細を超細かく説明する（←これに１日かけた方がいい）
- 5. 価格に含まれていないものを細かく説明する
- 6. 作業の切り分け（素材の用意はもちろん、レビューとか受け入れテストとか）について説明する
- 7. 要件定義コストとドキュメント製作コストについて事前に相談する
- 8. 段階的に要件をフィックスするポイントを明確にする。この説明を怠らない。
- 9. フィックスしても絶対にひっくり返るのでｗリソース確保の相談をしておく。
- 10. 嘘をつかない、キレないｗ、誠意をもって説明する
- 11. できないことは「技術的に」「コスト的に」等できない理由を明確にする
- ウェブ制作価格を相場以下で受けている企業が覚えておいて損のない5つの防衛手段 2008.2.22
- 必ず最初にデザイン性、配色、配置などを決定しておきます。後から言われても修正できないむねをきっちり伝える勇気を持つ事
- Flash作成という見積もりではなく詳細項目見積もり
- 完成後は住宅と同じで、リフォームと同じように価格が発生する事を確実に伝え、その細分化した価格表を作っておくべき
- 制作フェイズを必ず作ること.このフェイズを導入する事によって、一度作成しきったものは、なかなか修正できないのですよという無言の圧力
- 自分の身を守る為にも細かいサービス価格表を作るべき
- Web屋の相場が公開。高いとか安いとか、まったく議論にならない本当の理由 2008.2.21
- 『AjaxやAPIを使った少し高度な仕組みの作成』なんかは典型的で、『少し高度』という定義が全く意味不明です。
- 最重要項目は、予定外の注文や、度重なる変更、そして公開後の手直しです。
- これらを打開する為に、まずこの相場表をクライアントに見てもらうと同時に、きっちりとしたサービス価格の提示が、弱中小企業のWEB制作現場には必要なんだと思い記事にいたしました。
- 破綻した見積もりはプロジェクト失敗への近道 2007.12.18
- 一般的に、この最頻値を積み上げた見積もりが守れる確率は、10〜15％程度といわれている。
- つまり、予備を持たない最頻値を使った通常の見積もりをしているとすれば、それは10〜15％程度しか守れる確率がない見積もりを作っていることになる。
- システム化範囲がぶれていたら失敗する 2007.11.12
- 要件定義までは委任契約で
- そうできない場合、
- 1つは、リスク分を上乗せした金額(100%up)で契約
- もう一つは、請け負った作業を要件定義フェイズとその後のフェイズに分け、要件定義終了時に再度見積価格を見直す権利を契約で留保しておく
- ○○システム一式という書きかたはだめ
- 提案書や当初の見積もり書が根拠になるのは、要件定義フェーズまでであることを明確にしておく
- 要件を決定する人が誰であるかを契約書に明記しておくことも非常に重要である。このときに注意が必要なのは、この決定の期限を明記しておくことである。このように責任を明確にしておくと、その責任者はその決定に関して慎重になる可能性が高い。その結果、要件の確定が遅れれば、全体の進ちょくが遅れてしまうことになる。これを防ぐために、要件の決定期限を明確にしておけばよい。例えば、要件を提示してから10日経過しても要件の確定について回答がなければ、要件は自動的に確定するという条項も契約書に入れておくのである。
- 金額より見積もり条件
- 要件が曖昧な場合、見積もりの前提となる条件を明確にし、ユーザーと共有すること
- 機能だけでなく、稼動条件も確認すること
- 要求される性能
- 毎日の稼働時間
- システム事故が起きたときの許容ダウン時間
- 絶対回避が要求される事故は何か
- 見積もりの精度が上がらないのはなぜか？
- コンサルタントを入れろとのことだが、そんなの無理なプロジェクトもたくさんあると思われ
- 最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 2007.7.5
- 調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。
- この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。
- 事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。
- だが「（短縮率が）30％以上の短い期間での開発は無謀である」（JUAS）としている。
- 工数（人月）の設定ではシステムの画面数やファイル数も使える。調査から導き出されたのは
- 「必要工数＝0.1×ファイル数＋1.3×画面数＋0.3×バッチ数」という数式。
- その中でも工数と最も高い相関を示すのは画面数で、「必要工数＝画面数×1.55」との数式も示された。
- システムを自社で開発した場合、5年間の総保守費用は初期開発費用の2倍。
- パッケージソフトウェアを使った場合は本体保守が年間に本体金額の20％前後、アドオン開発が10％前後というのが平均の値だった。
- ソフトウェアメトリクス2007
見積もり支援ツール †
発注／調達 †
- 値切ってはいけない 2009.3.6
- 「値切り」に正直に応じる会社は無い
- 確かに，プロジェクトには予算が決められており，その予算の枠内でやり遂げる必要がある。どうしても予算と見積もり金額が合わない場合には，入念に価格交渉を行い，発注者と受注者の双方が金額の妥当性について合意した上で確定させるべきなのだ。
- 現場に蔓延する"ひどいRFP" 2008.6.26
- RFP作成者が信頼性の高いシステムを目指して自分の思いだけで記述
- 「保証」や「迅速」「柔軟」といった，あいまいなキーワード
- 画面だけがやたらと詳しく書かれていて，ロジックやDBのことには全く触れられていない
- 競合他社が導入したシステムの紹介記事を指して『これと同じものを提案してくれ』
- 調達用語 RFP,SLCP,SPAとか
- ＲＦＰ（Request For Proposal：提案依頼書）
- ＳＬＣＰ−ＪＣＰ９８：Software Life Cycle Process - Japan Common Frame 1998
- ＳＰＡ（Software Process Assessment）
|
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
