見積もり・発注 の履歴(No.4)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 見積もり・発注 へ行く。
  • 1 (2022-12-28 (水) 21:21:35)
  • 2 (2023-02-18 (土) 16:30:47)
  • 3 (2023-03-02 (木) 13:49:56)
  • 4 (2023-04-17 (月) 09:36:42)
  • 5 (2023-06-23 (金) 15:50:27)
  • 6 (2023-07-15 (土) 12:56:37)
  • 7 (2023-08-01 (火) 10:08:09)

---

→プロジェクト管理

→要件定義・基本設計

→顧客対応

見積もり†

• システム開発の提案における概算見積書の作り方 - Qiita 2023.3

• 三点見積り（三点見積法）の使用方法とメリット・デメリットを解説 | Promapedia（プロマペディア） 2020

• 見積もりは難しい。いつまで経っても難しい。 - Qiita 2022.12

• 技術顧問との1on1で見積もりには3種類あることを教えてもらった - Qiita 2022.12
  • 見積、コミットメント、ターゲット

• 約束は開発を遅らせる - Mitsuyuki.Shiiba 2022.11

• スケジュールの見積もりを適当に答えたらコミットメントにされる問題について｜きゅーい / koyo｜note 2022.11

• 気持ちをちょっと楽にする工数見積もりの技術 - Baseconnect Tech blog 2022.8

• On Estimates - DEV Community 2022.8

• 見積・提案書に書いておくと不幸を減らせる前提条件 2022.7

• 提案依頼書に含まれる無理難題の分類(詳細) 2017
• 提案依頼書に含まれる無理難題の分類(プレゼン資料) 2017

• スクラムと見積り - Google スライド 2022.7

• 10％はバッファを取れ。「仕様変更」は必ず起きる。 - Qiita 2022.6
  • 「仕様変更がない」プロジェクトが75%成功するのに対して、「重大な変更」が合った場合には、工期は3割も守られません「ほぼ失敗する」と確定していい
  • JUASの資料で検証対象となるような”ある程度の規模”のプロジェクトの半数（52.6%）が総予算の10%を設定していることと実際に仕様変更が発生した76%のプロジェクトの超過コストが9.3%であることから総予算の10%がバッファの目安
  • これは費用だけの話ではなく。スケジュール等他のリソース全てに当てはまります。人員や、サーバーリソースなど、あらゆるリソースに10%プロジェクトが膨らんでもいい余裕 を持たせておく必要

• 第2回：良い開発組織では「予定より早く終わりそうです」を聞く。 - Qiita 2022.3
  • システム開発はタスク予定表どおりには進行しません。
  • これは、見積もりの手法や、要件定義の精度、開発プロセスの習熟度、あるいは受注側の誠意の問題ではない
  • 工期が20%以上、遅延する割合は13.3%
  • プロジェクトの13%は大幅な計画予算の超過
  • バッファを積んでなお、これだけリスクが顕在化している
  • 仕様変更は実に80%近いプロジェクトで発生します。「ほぼ確実に発生するプロジェクトリスク」
  • ソフトウェアメトリックス調査2020システム開発・保守調査 2020

• 良い開発組織では「予定より早く終わりそうです」を聞く。 - Qiita 2022.2
  • 3ヶ月後。マネージャーや発注者は「何故、プロジェクトが遅れているのか？」という議題に悩むことになります。
  • それは、貴方自身が削った”バッファ”が原因です。

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

• システムの工数見積とは統計である 2014.1.30

• 「Web制作のリアルな工数と見積もりの話」の話をしようじゃないか！ 2013.6.29

• 【番外編】見積もりミスによるリスクを契約条件で回避する方法（その1） (1/2) 2012.7.25
  • 【番外編】見積もりミスによるリスクを契約条件で回避する方法（その2） 2012.9.20

• プロジェクト管理者が1人でできるデスマーチ・プロジェクトの対処法（その2） (1/2) 2012.6.14

• プロジェクト管理者が1人でできるデスマーチ・プロジェクトの対処法（その1） 2012.5.17
  • 「日程が不可能であることの証明と代替案の模索」が、デスマーチ・プロジェクトにおける、発注側と開発側の双方が共倒れしない（成功する）ための“キー”となります。

• 首相官邸ホームページのリニューアル構築費用に対して製作者側からの考察 2012.4.6
  • 実際このくらいかかるのは妥当、とのこと

• ついに登場！ 究極の見積もり技法（その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などの新技術を取り入れて実装を並行開発する。
  • そして、殆どの画面を作った後も仕様変更が五月雨式に落ちてきては手直しし、結合テストやシステムテストで初めて稼動させた時に、大きな穴に気付く。
  • いくらテストしてもバグが落ち着く傾向も無く、延々と残業と休日出勤が続く。
  • 品質が安定しない状態のまま、最後は納期も遅れてしまい、投入した人員では足りず、火消しやヘルプの人員をどんどん投入して、何とか鎮火させる。

• ２億円が820万

• 前提条件を無視してはいけない 2009.1.30
  • なぜ，不採算プロジェクトとなるのか。それはベンダー，ユーザーお互いが，見積もりに明示されていない前提条件を都合よく解釈するからである。
  • では，どうすればよいか。要件があいまいな部分や決定していない事項については，仮の要件を設定して見積もればよい。仮の部分を「前提条件」として明文化し，前提条件が変われば見積もりも変わることをユーザーとベンダーが合意しておくことがポイントである（表）。

• 見積もりが高いといわれたら。Noという交渉術 2008.7.23
  • おかしな話には「No」といいます。無茶に対しては無理といいます。交渉決裂は重要なカードです。理不尽な客を切れる「コスト」と考えれば妥当です。
  • 交渉結果が必ずしも望むものになるとは限りませんが、「No」により決裂したとしてもそれが最善であれば問題ありません。そして意外に思うかも知れませんが「No」といってまとまる話も多く、「できないこと」を明示する姿勢は高く評価されます。

• ついに登場！ 究極の見積もり技法（その2：実践編） 2012.1.23
• 規模見積もりの王様「LOC見積もり」 〜見積もりの基本技法 その2〜
• 規模見積もりの女王様「FP見積もり」【前編】
• 勘・経験・度胸による「類推法」 〜見積もりの基本技法 その1〜

• ファンクションポイントを過信してはいけない 2008.6.18
  • FP法はユーザーが識別しないものは機能とみなさない
  • PMは，FPの持つ本来の意味を十分理解しておく必要がある。FP値はあくまで規模を表す数値であり，工数ではない。従って，見積もりを提出する際の数値的な根拠として用いる場合には，必ず生産性係数とセットとなることを忘れてはならない。契約で必要となるのはあくまで金額であって，FP値といった指標ではないからである。どんなFP値であっても，生産性係数がなければ，システムの規模を表す指標の一つに過ぎない。
  • ところが，生産性係数の値の決め方一つで，見積もり金額は高くなったり低くなったりする。そのため，見積もりを算定する場合には，この生産性係数がFPと同等以上に重要なファクターとなるのである。しかし，システムの特性に応じて開発難易度を考慮し決定するというのは容易ではない。ベテランのPMですら間違うことがある。

• 値引きに簡単に応じてはいけない 2008.6.17

• WBSを軽視してはいけない 2008.5.7

• 移行は全工程の4割を費やす 2008.3.17
  • 単純なサーバー・マシンのリプレースなどは別として，システム移行には新システム構築に匹敵する工数がかかる。
  • 移行の要件定義・開発（20％）とリハーサル（15〜20％）を合算した移行関連の工数だけで，「全体の35〜40％に達する」
  • →データ移行

• Web制作、高いか安いか、ではない 2008.2.22

• 論点ちがうよ、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日経過しても要件の確定について回答がなければ、要件は自動的に確定するという条項も契約書に入れておくのである。

• 現実的な見積もりアプローチを考える 2006.9.22

• 金額より見積もり条件
  • 要件が曖昧な場合、見積もりの前提となる条件を明確にし、ユーザーと共有すること
  • 機能だけでなく、稼動条件も確認すること
    • 要求される性能
    • 毎日の稼働時間
    • システム事故が起きたときの許容ダウン時間
    • 絶対回避が要求される事故は何か
• 見積もりの精度が上がらないのはなぜか？
  • コンサルタントを入れろとのことだが、そんなの無理なプロジェクトもたくさんあると思われ
• 最適な工期は「投入人月の立方根の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

• IT見積もりの見える化
• 見積もり根拠の提示方法その巧拙で信頼度が変わる

• 人月見積もりでは生産性はあがらない 2006.11.29
  • 第２８回情報産業経営実態調査報告書
  • http://sec.ipa.go.jp/index.php

• ソフトウェア・メトリクス解説@IT
• ファンクション・ポイント法まとめ
• COCOMO解説
  • COCOMO本家
• allabout見積もり
• ソフトウェア定量化用語集

見積もり支援ツール†

• [ChatGPT Hack] Bing Chat を使って、新規アプリ開発の Azure 概算見積もりを作ってみた - Qiita 2023.4

• SEエスト

• Construx

発注／調達†

• システム開発でベンダ任せをやめようとした日本、ベンダに任せた米国 2015.1.28
  • 日本のIT業界は米国の10年後追いと言われる中、なんで米国の後を追って一括発注を採用せず、原則分離調達などという無理ゲーに手を出したのか。
  • 「費用の透明化」と「公平な入札機会」が大きな理由としてあります。
• だからあなたの会社のシステムは動かない〜システム発注担当者の悩みを解決します〜
  • システム開発は、発注側と開発側との共同作業です。いくら優秀な技術者が揃っている開発会社に依頼しても、発注側に問題アリではいいシステムは作れません。
  • 見積もりについて
  • さあ困った 〜突然の仕様変更〜

• WEBシステム開発の値段 2012.2.27

• RFP完全マニュアル 実践編

• 値切ってはいけない 2009.3.6
  • 「値切り」に正直に応じる会社は無い
  • 確かに，プロジェクトには予算が決められており，その予算の枠内でやり遂げる必要がある。どうしても予算と見積もり金額が合わない場合には，入念に価格交渉を行い，発注者と受注者の双方が金額の妥当性について合意した上で確定させるべきなのだ。

• 現場に蔓延する"ひどいRFP" 2008.6.26
  • RFP作成者が信頼性の高いシステムを目指して自分の思いだけで記述
  • 「保証」や「迅速」「柔軟」といった，あいまいなキーワード
  • 画面だけがやたらと詳しく書かれていて，ロジックやDBのことには全く触れられていない
  • 競合他社が導入したシステムの紹介記事を指して『これと同じものを提案してくれ』

• はじめてのRFP 2008.2.4

• 調達用語 RFP,SLCP,SPAとか
  • ＲＦＰ（Request For Proposal：提案依頼書）
  • ＳＬＣＰ−ＪＣＰ９８：Software Life Cycle Process - Japan Common Frame 1998
  • ＳＰＡ（Software Process Assessment）