1. 前提

・お金をもらってやったプロジェクトではないので、そんなにシビアではなかった(手弁当)
・結局データが足りず、思うような結果は出なかった(先方も納得してくれていた)

2.やったほうがいいこと

(1) 着手時
　・目的
・追加コストをかけてまでやる余力があるか
→制約をここで確認
・スケジュール(決めておかないとズルズルに)
・一緒にやりましょうね！の意気投合
　→一部署だけのデータでは不足していることが多い。
　　他部署に話をしてもらえるかぐらいの熱量があるか見極めておく。
　・雲行きが怪しくなった場合についての認識合わせ

(2) 分析時
　・相手がエンジニアでないと、細かいコードとか出しても理解できない。
　ただそれっぽくも見えるので、一瞬出して、あとは図とかで説明する。
・相手は業務知識が豊富なので、こちらからも仮説は持って行って、それを叩いてもらいつつ、意見を引き出す。そのときに目の前でぱぱっとジャストアイディアで出てきたものの分析ができると好感度アップ。
　・可視化だけでも喜ばれるのでどんどん見せに行く。

(3) 雲行きが怪しくなってきたとき
　・早めに打診
・原因と対応策(実現が難しくても)を整理し、議論できるようにする。
　→ワークアラウンドが出てくるかもしれないし、なければクローズの方向にも持って行ける。
　口頭での報告だけでは腹落ちもしにくいので、きちんと資料化する。

ウォーターフォール型でインフラ構築をずっとやってきたので、まだまだ進め方は試行錯誤です。
来年の自分に期待です！