仕様変更を抑えるコツ（廃版:日経SYSTEM）
変化の早い今の時代、プロジェクト推進する立場であると仕様変更をお願いする時もあればお願いされる時もあります。
どうしても仕様変更が困難な場合、いきなりNGというのではなくて条件が異なる複数案を出す事で相手へのその仕様変更インパクトを伝えつつ、判断を仰ぐやり方があるようです。
oicos.co.jp/wp/wp-content/uploads/2016/12/nikkei_systems_201612.pdf
＃無料公開されているので引用。
複数案掲示の例
①松：相手の仕様変更を全て実装するパターン
→予算も納期もオーバする
②梅：予算も納期も予定内で実装可能な機能に限定したパターン
③竹：エンジニア側が最適解だと想定するパターン
④竹：③から機能追加or納期を少し早めるなどバリエーションパターン
こうする事で、2つの狙いがある。
1点目：すべての要望を満たす①は相当厳しい事を相手方にも理解してもらう。
2点目：どの機能が実装するかしないかで予算や納期がどう変化する理解してもらう
との事です。
よく「結論から答えるように」と習う事が多いですが、無理があるなという話の返した方の1つとしてこのようなやり方があるようですね。
価格交渉ガイドブック（中小企業庁）
写真は大事（日本政策金融公庫の売り上げUPにつながる写真の撮り方ガイド）
標題の通りのガイドブックを組織的に公開している組織をたまたま見つけたのと、
資料作成時に写真を使う事はあると思いますが、その時に参考になりそうなので備忘こめてここに残しておきます
phototech_guide_restaurant.pdf
交渉のコツ（争点を増やす：誰でもなれる名講師より）
ビジネスにおいて交渉事は多くあります。お客様相手にいつまでに納品が必要なのか、社内の製造部にいつまでに生産完了するようにお願いするなど、通常どおりでならない時には交渉が必要です。
交渉必要にならないようにするのが一番ですが、それでもリカバリ策として必要な時に何かコツがないか探してみた所、「争点を増やす」という観点がよさそうだったので、残しておきます。
単純に納期だけだと早いか遅いかで得するか損するかだけになりますが、代わりに価格を上げる、保証を緩くするとか、次の購入につなげるとか、別論点があると交渉しやすくなるとのはその通りなので相手方に交渉するとき・されるとかに厳しいとおもったら争点を増やすといいかもしれませんね。
農業農村工学会 誰でもなれる名講師より。
交換交渉のポイントは、争点を複数にすることだ
互いにほしがっているものが同じで、１つだけだというのは、幻想かもしれません。
交換交渉のポイントは、「固定パイ幻想」がないことです。「パイ」は１枚ではなく何
枚もあり、さらに「それぞれ好むパイが違う」。これが「利益の差」を利用する交換交渉の考え方ですーー中略ーー
手持ちのパイが多いほど、交渉の幅は交渉の争点が１つしかない交渉を「単一争点交渉」、複数にわたる交渉を「複数争点交渉」と呼びます。
単一争点交渉は分配交渉に、複数争点交渉は交換交渉に適しています。
交換交渉では、「相手と自分とで利益の感じ方が違う部分」をなるべく多く見つけ出す
ことが交渉成功の鍵になります。そのためには、出来る限り争点の数が多い方がよいのです。
そこで、交換交渉の重要な準備として、「争点を複数化すること」があげられます。
どれほど単純に見える交渉であっても、背後にはいくつかの交渉可能な争点があるものです。先ほどの「オーディオ機器売買交渉」のケースでも、ヘッドホンだけでなく、保証支払方法、購買量の増加（将来購入予定のものをまとめて買うかわりに割引）なども争点いできる可能性があります。
ここで使っている「争点」という言葉は交渉用語で、実際には交渉材料のことを指しています。
交渉前の準備として、こちらが提案できるものの中から、相手が興味を持ちそうなものをリストアップしておきましょう。相手の情報をなるべく多く集め興味対象を明確にできれば、正確で長いリストをつくることができます。争点を複数化するためには情報収集も欠かせません。
「争点を複数化する」というのは、交換交渉の成否を握る重要なプロセスなのです。ーー中略ーー
提供することでさらに変動費がかかる点や、他の顧客に影響を与えるような点は、できる限り譲りたくない材料です。
一方、固定費がメインになっていて、譲ったところでさして全体には影響がない点は、はじめのうちに提供できる交渉材料だといえます
ダッシュボード画面の作成ポイント（デジタル庁、ガイドブック）
DXを進めるために、内製でアプリ作成や使用するケースが増えていると思います。
しっかりと使用されていくためには最初のダッシュボード画面が非常に重要です。
そのダッシュボード画面をどう作成するとよいのか、デジタル庁がガイドブックだしているので紹介しておきます。
※データがそろった後の可視化部分に焦点をあてている資料と明記されてます。
ダッシュボードデザインの実践ガイドブックとチャート・コンポーネントライブラリ（ベータ版）｜デジタル庁
進め方もそうですが、第三者に難しさを伝える上で制約条件をまとめていただけているのがありがたいですね。
【IT】SLAの検討ポイント
【IPA資料】 経営に活かすIT投資の最適化(車選びで非機能要件の説明）
システム開発や更改をする必要はあるが、そのためのリソース確保に苦労する事はあると思います。また明らかに必要な新機能のためであれば周囲の理解は得やすいですが、信頼性や拡張性などの非機能要件部分はなかなか理解されにくい所です。
わかりやすく説明する方法がないか調べてみると以下のページが見つかり、のこしておきます。
アーカイブですが見つけられたのでこちらも。
