ある日の打ち合わせで、こんなやり取りがありました。
クライアント「これって、こういう動きできますか？」
僕「はい、それできます！」
即答です。
ちょっと気持ちよく答えています。
場も止まらないし、頼られている感じもあります。
しかも、その場の空気もちょっと良くなります。
「お、話早いですね」みたいな空気が出ます。
ただ、このあとだいたいこうなります。
エンジニア「それ、結構厳しいですね」
ディレクターは静かに思います。
あ、やべ、やったな。
そして、この「やったな」はだいたい夜に効いてきます。
若手のころは「できます！」が気持ちいい
若いころは、わりと反射で言っていました。
「できます！」
「いけます！」
「大丈夫です！」
理由はシンプルです。
止めたくない。
場をよくしたい。
スムーズに進めたい。
頼られている感じがちょっと嬉しい。
あと、正直なところ。
なんとなく、いけそうな気がする。
これが一番危ないです。
Web制作って、似たことが多いです。
前に似たような実装を見た。
他のサイトでできているのを見た。
前の案件で似たことをやった。
だから思うんです。
これ、いけるな。
ただ、ここに一つ抜けています。
今回の条件でいけるかは別。
「いける」は1種類じゃない
現場に出ると、ここで一回混乱します。
「いける」に種類がある。
技術的にいける。
工数的にいける。
スケジュール的にいける。
この3つ、全部違います。
例えばこうです。
技術的には可能です。
でも、実装に3週間かかります。
この時点で、スケジュール的にはいけません。
でもディレクターは言ってしまいます。
「いけます！」
エンジニアは少し止まります。
どの“いける”の話だろう。
そして、ズレが始まります。
技術の「いけます」はだいたい条件付き
ここはちょっとだけはっきり言います。
技術の「いけます」は、だいたい条件付きです。
例えばこういう前提があります。
特定のブラウザでは対応しない。
JSで制御できる範囲に制限がある。
CMSの仕様で実装が変わる。
既存システムとの兼ね合いで制約がある。
全部「いける」に入ります。
ただし、条件付きです。
この条件を言わずに「いけます」と言うと、あとでズレます。
そして、そのズレはだいたいこういう流れで来ます。
昼に「いけます」と言う。
夕方にエンジニアとすり合わせる。
夜に気づく。
これ、普通に無理だな。
ここからが長いです。
説明して。
調整して。
場合によっては謝って。
ちょっと空気が重くなります。
そして思います。
あのとき確認すればよかった。
本当はPOCで止める話
こういうときに本来使う言葉があります。
POC（Proof of Concept）
技術的に成立するかどうかを試す、という意味です。
つまり、「いけるかどうかを一回ちゃんと検証する」ということです。
いけるか微妙なとき。
条件が多いとき。
見た目はできそうだけど中身が怪しいとき。
こういうときに使います。
ただ、現場ではこれが飛ばされがちです。
理由はだいたいこれです。
時間がない。
なんとなくいけそう。
前に似たことやった。
そして、そのまま進めて詰まります。
じゃあどうするか
ここでやることは、そんなに多くありません。
まず、「できます」と言う前に一回止まる。
そしてこう言います。
「一度エンジニアに確認しますね」
これだけです。
これ、遅くなるように見えます。
でも実際は逆です。
あとで戻る時間が減るので、全体は速くなります。
もう一つだけやるといいことがあります。
「いけます」を少しだけ言い換える。
例えばこうです。
「技術的には可能そうなので、詳細確認してから確定します」
少し長いです。
でも、この一文でかなりズレが減ります。
さらに余裕があれば、こうも言えます。
「POC的に一度検証してから判断します」
ここまで言えると、だいぶ安全です。
まとめ
「それ、できます！」は、すごく気持ちいい言葉です。
場も止まらないし、話も進むし、空気も良くなります。
ただ、その裏にある前提を確認しないと、あとでズレます。
そして、そのズレはだいたい夜に来ます。
ディレクターはだんだん変わります。
即答しなくなる。
一呼吸置くようになる。
確認してから返すようになる。
それくらいが、ちょうどいいです。
