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

はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる

[rgfx]

via:"PMBOK/ISO9001 に従ってプロジェクト計画書を軽く書いておくと各項目を網羅できるのでお勧め／建築屋さんのリフォーム見積もりに沿うとよいです" https://twitter.com/moonmile/status/1553905759683248133

[strawberryhunter]

「これを書いておけば、すべての不幸を避けられるというものではありません」要するにこういう事なんだろうなという事を予期させる素晴らしい予防線だった。

[sucelie]

・振込手数料等は御社でご負担ください

[moromoro]

“貴社内にて、プロジェクトを遂行する上で必要な裁量をもった担当者を選定いただける前提とします” うっ

[xlc]

これだけ書いても「予算がなくなったので何とかしろ！」と言い出すのがお客様である。最終的には喧嘩別れや訴訟も辞さない胆力が必要になってくる。嫌な世界ですな。

[rryu]

逆に言うとこれら全てがお客が無邪気に言ってくる可能性があるものということで、なかなか大変である。

[deep_one]

これを見ると相手が「君は今までどれほど不幸なプロジェクトにかかわってきたのか」って目で見てくれる気もする。ハードボイルド。（まぁ真のハードボイルドは「相手は協力的ではないと覚悟している」だが。）

[toubanjanny]

この辺は基本で書いときましょうという話で、これにプラスして案件事情に応じて文言差し込むべきという話だと思ってる。▼発注側としても見積もり前提がスカスカな提案書はそれなりに怖い。

[remonoil]

これ最後まで満たし続けられるケースあんまり無いのが問題

[Chisei]

最悪裁判になったとして負けない条項になっているかが重要だと思っている。この記事の内容は読んでない。

[myfirm]

貴社内にて、プロジェクトを遂行する上で必要な裁量をもった担当者を選定いただける前提とします業務運用マニュアル・操作手順書などの作成、利用にあたっての教育などは対象外といたします（必要となるレベルが対象

[daaaaaai]

すごい

[yabu_kyu]

「本プロジェクトにて作成するすべてのドキュメントは、弊社書式といたします（相手書式に合わせると大幅なコスト増になる可能性が高い）」うむうむ。

[ducktoon]

必要な裁量を持った担当者を選定いただける前提、ってそれだー！

[harumomo2006]

契約書で今までで一番効果が高かったのは「本製品はソフトウェアですのでいかなる保証もいたしません」かな。それでもビビりながら電話かけてきたことが1回あったけど

[gonta616]

見積もりの技術

[orangehalf]

「プロジェクトの打ち合わせは基本的にリモートとし、オンサイトでは原則実施いたしません」「感染症等の状況が変化した場合、スケジュールについて見直しいただく場合があります」このあたり追加しておくべきなのか

[rck10]

正しいが、基本と言えば基本。現実的にはこれを（裁判も辞さない覚悟で）押し通せるかどうか、という話で、その点だけでも、法務部が仕事をする大手に勤めるべき。中小の悲哀は契約書がアテにならない所。

[arakash]

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

[secseek]

そもそもコストやスケジュールが変更になるってのがもっともスムーズだと思うんですが、それが現実的じゃないのが大問題ですよね。ダメなら黙って飲み込んでやり続けるか中止するかって二択になっちゃうのが…

[lorenz_sys]

内容については妥当であり賛同するが見積・提案書に書いておけば安心というわけでもないので当該案件 PM はこれら前提条件が担保された上での契約締結～要件定義書作成～合意となるようにすべきと少々言い換えたい。

[orangeno8]

こんな多くの但し書きを付けるよりも、予備費20%確保をお願いしておけば、話はもっとスムーズになりますよ。

[dorokei]

一応メモしとこ

[nonono-notch]

見積もり、見積り、見積書、項目

[toaruR]

MAXの費用が知りたい顧客に、不確定なものは確定できない事実を共有することよなー

[ysync]

受託ITは建設と同じく一品モノを作る作業なんだけど、設計と施工がほぼ一体なのも客側の権力が強くなりすぎる不幸かなとも。設計事務所というクッション無いからな。

[inuinumandx]

スゴーい小さい字で印刷してあるやつだ！老眼には読めない！

[kemononeko]

大学のゼミで契約書を自作するときあれ入れろこれ入れろここはこうしとけ言われたのを思い出して懐かしい。そう言えば契約書の作り方なんか義務教育でやらんもんな。

[sun330]

要件定義以降の作業…誤字はさておき日本語として以降だと要件定義が入るような…。うーん。

[shion214]

“です”

[zooms]

メモ

[gwmp0000]

"書いてない機能は別見積 非機能超えたら保証外 ドキュメント弊社書式 運用マニュアル作成しません 受入れテストやって 貴社理由遅延は追加料金 社内関係者の充分な協力を得られるよう調整よろ 成果物は共同著作"

[awawawann]

こういう配慮が必要なシーンはままある。

[dogusare]

https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A3%E3%82%B8%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3%E3%82%B9%E3%82%BF%E3%83%87%E3%82%A3　初めて知る言葉（汗、文言中身もノウハウなんだけどなぁ（遠い目

[kazu_k_adv]

わ

[asakiri4177]

"本書に記載された非機能要件を超えた場合、動作などを保障することはできかねます"SI側もユーザー側も経験してる上で個人的にこれが特に大事な要素だと思ってる。

[stealthinu]

見積もりに書いておいたほうがよい内容。なるほどだった。

[sirobu]

"正式見積もりのスコープ"と"要件定義移行の作業は、要件定義完了後に改めて再見積もりする前提”これ、結構な大企業でもほわほわっとしたRFPで一括見積もりしろって会社あるんだよなぁ…

[sambmetta]

見積り条件なんて反故にされるのが常だけどな。書いといて減らせる不幸は非常に限られてる。大手であればあるほど見積り条件ガン無視の契約書様式寄こしてくるし。

[shiyo_no]

ある程度ちゃんと、自分も前提事項書けてたんだなぁ(白目)