提案も見積もりも設計に基づくという話
先日先輩が、某お客様への提案書に大変苦労なさっていたので及ばずながらお手伝いさせていただいたときに感じたことです。
根拠のフロー
先輩は提案書のレビュー指摘を直しても直しても新たな指摘を受ける状態でした。 よく話を聞いてみると、想定（提案）するワークフローが弱い気がしました。
提案＝何かを解決する手段
提案するということは、相手は何かしらの課題を持っているか、気付いてないけど改善の余地があるということです。 誰も得しない提案というのはありません。
それはつまり、現在のワークフローを置き換える新しいワークフロー、と言えます。
管理対象の扱い方
ワークフローが変わるということは管理する情報にも変化が生じます。 情報をどう扱うか、というのがソフトウェアの肝になる部分ですね。
情報を処理する、それはつまり仕様です。ITそのものです。
目に見える変化
内部的なデータ項目と扱い方が決まった後、外部的な扱い方も考えます。
提案される側つまりお客様にとって違いが分かりやすい部分です。
出揃った根拠と見せ方
ワークフロー・仕様・UIが出揃って、根拠のある提案を行う準備ができました。
提案書は変化をアピールしたいので、画面多めで構成されます。 注意が必要なのは、提案書に現れない部分も準備が必要だということです。 これってもう設計ですよね。
見積もりも同じ
同じことが見積もりにも言えます。 見せ方は違えど、何をどう作るかを決めておかないと値段のつけようがありません。 （フェーズごとに粒度の違いはあると思います）
提案や見積もりで手が止まった時、表面的な画面イメージとにらめっこしてもそこに答えはありません。 先のフローをさかのぼって、土台となる根拠に立ち返ると良いと思います。
- 謝辞
- 画像は Unsplash 様より使わせていただきました。
Explore more like this
リモートワーク下でもチャットの返信を意識することであなたは成長できる
リモートワーク下では雑談が減り、ちょっとした情報交換や（いい意味での）おせっかいなアドバイスもできにくくなりました。 こんな状況下でもチャットの返信を意識するだけで成長できるコツがあります。
Dockerは魔法のコマンド、と考えるとしっくりくる
仮想化という文脈ではイマイチDockerを理解できませんでしたが、（魔法の）コマンドと考えるとすんなり理解できましたので、今更ですが紹介したいと思います。
