「この仕様を満たす能力があるよ」ということを知るのは技術の一部である。これは営業職には特に求められることではないか。営業職が実装まで行うことはない。知っているけれどもそれを使ってモノを作ることはない。だから、スペックシートをよく読み込んだり、事例研究し活用例を知る。そこまでである。実際に顧客に買ってもらったら、技術部門に引き渡し、実装する上で必要な情報の詰めを技術者が行っていく。
この流れの中で面白いのが、営業は知っているだけということだ。じゃあ、本当にそれがそのとおり動くの？ということについては営業の独断は無理だ。技術者に顧客の要望を伝え、そしてその製品を適用したときにどういうふうに実装するのか、問題はないのかの裏付けがないといけない。
もし、営業が「できます！」と言って実際に受注し、技術者に仕事が降ってきたときに実はできませんでした、となるとこれは分が悪い。もしできなかったばあい、損害賠償ものだ。請負っておいてできません、だと顧客は困る。できなかったことで発生する顧客の損失は、できなかった請負側が背負わなければいけない。
プロはできないとは言えない、というのはこの仕組みが前提だ。一度受けてしまった案件にできないはないのだ。だからこそ、受注する前が勝負である。できないものを受けるのは負け同然だ。プロならば、できることとできないことの区別を明確に判断しなければいけない。
巷の炎上プロジェクトはたいていこの仕組みで起こる。お客様から請け負った以上はやりきらなければいけない。しかし、受注後、お客様から話を聴いてみると、おやおやおかしいことを言っている。営業時は上席と話をしていて丸くまとまっていたのに、実装時には現場が出てきて、えらく複雑なことを言い始めている。しかも非協力的だ。あまりにもできない要素が多すぎる場合は、そこでプロジェクトを止めて、それまでの損金を両者で話し合う係争に発展することも、よくこの業界では目にする。
大きな目線で見れば、できるか、できないか、を見定めるのが技術である。営業はスペックシートと技術の意見をエビデンスにする。しかし技術者は何をエビデンスにするのか。技術者は技術者には聴けないのだから。それが動くとどうやったらわかる？。
それが、検証、である。本当に動くのかを実際の環境でシミュレートし、裏取りする。実際に動くということは非常に強い。どんなに技術資料に書いてあったって動かないものはたくさんある。細かい仕様が隠れていたり前提条件があったりと、様々なのだが、それを検証なしで見抜ける人などほぼいない。いろんな仕事をやったことがあるが、もう、最近は検証なしでは何も答えない。それぐらい、いろんなソフトウェアに裏切られている。受注してしまってから裏切られると、かなり厳しい。時間も限られている中で、費用も確定してしまっている中で、代替策を繰り出さなければいけないが、これが技術者として最も試練を強いられると私は考える。
この検証を行う作業、そしてその積み重ねこそが、技術の真髄じゃないだろうか。資格を取ったり最新技術に詳しかったりと、いろいろ技術があることをアピールする方法はあるが、全部本質じゃない。自分の手でその技術を動かし、そして絶対に問題無く動くと断言できるその経験を、たくさん持っている人。そしてその言ったことを確実に本番の実装時に再現できること。それを顧客や営業が確認し満足すること。このフローこそが、技術なのではないか、と思う。
私の仕事も、昨今は「検証」の連続にシフトしつつあり、これはとても幸せなことだと考える。技術の本体そのものであるから。できるらしいよ、ではなく、できると断言すること。そしてその仕事を請負い完成させ、信頼を得ること。技術の本質を知りたいならば、検証にある、と言いたい。
