外注するなら実装・要件変更の可能性は両者で共有しておこう

変更を依頼するのは想像以上に工数がかかる＆申し訳ない

依頼者（自分）：どベンチャー

営業するのにLPほしいな〜と思って、知り合いに紹介して頂いたデザイナーさんとLPの実装をすることにした。

流れとしてはざっくりと

打ち合わせ➔要件定義➔ワイヤー作成➔デザインカンプ作成➔コーディング

となっていた。

そして僕はユーザーヒアリングと同時にLPの実装も進めていた。つまり「デザイン要件の変更が急に必要になってくる」ということだ。「あやっぱこれこんな感じでお願いします」「ここの要素がユーザーヒアリングの結果大事ってわかったんで追加してもらえますか？」等々のやり取りが出てくるのだ。（超具体的には、ワイヤー作成後のコンプのfb段階で、「web完結と明瞭会計の要素追加して」とか「〇〇コースの料金表じゃなくて1食〇〇円のシュミレーション表にして」という具合だ。）

実装上の変更が必要になった時、気軽に頼めることが大事

しかし正直、どベンチャーのフェーズにおいてこの現象は仕方ないことだと思う。

当然仮説の精度は低いし構造レベルで変えなければいけない大きな実装も時として必要だ。だから大事なのは「そういった急な変更を気軽に頼めるような同意をとっておく」ことだ。

事前に合意をとっていないと、こちらが提示する変更内容が急＆大きいという場合が多々あり、そのたびに雰囲気が悪くなっていった気がする。

なので事前に「いま僕らはどベンチャーでユーザーヒアリング同時にしてるからたぶん急な戻しめっちゃありますよ！？それでもいいですか！？」と確認をとっておく。

それだけでもお願いのしやすさはまるで違う。そうじゃないと今回のように「え？なんでこんな変更多いの？」みたいな状態で「すみませんやっぱここも変えて・・・」みたいに心苦しい思いをしなくて済む。デザイナーさんだって別に追加料金が欲しいとか面倒くさいとかじゃなくて、いいモノを作りたくてゼロから設計したいのに対応しきれなくなってしまう。急な実装の変更依頼はその想いを逐一裏切っていることになる。

あわよくば契約書に「めっちゃ変更してもいいよ」って入れ込む

今回の例で言うと、契約書には「依頼者（＝僕）のコンプ承認時点で大きな修正はきかない」「それ以外の変更については話し合いで決める」と記載されていた。

それだと弱いので「ワイヤー提出後であっても、コンプ承認前であれば変更は新たな要素の追加・変更は原則可能とする」くらいにしてしまうと良い。もちろん「原則」ってなんやねんというツッコミはあるが、このくらいを許可してくれるイメージでないと対応できない。

もちろん基本は依頼者側はお願いする立場なので「契約書にこう書いてあるんだしゼロから全部作りなおせや！」という態度は論外だ。検証できる部分は早めに検証し、可能な限り全ての要素の不確実性を減らし、実装を依頼すべきだ。

しかし全てを予想・検証できるわけではないので、どうしても急＆大きな変更依頼というのは出てくる。

どうなった時に、お互い気持ちよく同意できるスキームを予め用意しておく必要がある。誰も悪意を持っていないのだから、誰も気まずい思いをしなくて済むよう、せめて依頼者側が努力しそのスキームは気づいておくべきだ。

ーーーーーーーーーーーーーー

※これは全て情けない自分に向けて書いています。自分の中で滅茶苦茶になっている思考を吐き出して、一刻も早くこのモヤモヤから抜け出すために。そして将来これを振り返った時に、「俺が20の時はこんなレベル低いことで悩んでたんだぜ！だからお前らも余裕だよ！！」と堂々と後輩に見せて励ませるように。

がんばろう。