失敗に（も）学べ

最近、少し聞く機会がへったワードに「ベストプラクティス」や「成功事例」というものがあります。一時期は成功事例に沿っていくことが正義のように言われていましたが、私は余り同意できませんでした。というのも、自分が成功してきた道のりの中には、私の個性や経験、また偶然や幸運が積み重なった結果だと思っていたからです。とはいえ、小さすぎて他の人からは見つけられない成功体験だと思うのですが。
さて、前置きとしては、ここまで。私の中で大切にしていることは失敗体験です。同じような失敗ばかりを繰り返していますが、それでも一つの失敗を忘れずに少しでも改善しようとすることが大切だと思うのですね。
プリセールス活動などは失敗の連続です。時にはデモ終了と共にスタンディングオベーションを受けたこともありますが、そんな心地よさは本当にレアな体験です。毎度毎度、冷や汗が脇をつたい、声がかすれ、自社に戻っる道すがら善後策を考える事ばかりに終われます。
ただ、そんな苦い経験から
・得意・不得意
・出来ること・できないこと
が判りますし、必要な説明と不必要な「オーバートーク」の違い。時には「嘘」への自戒も出てくるのですね。

「お前、嘘つきなんだな」と言われても仕方ないくらい、現場で方便と思って話すことは少なくありません。ただ、その嘘が「つきっぱなし」にならないよう、善後策を考えるのです。ここが言ってみれば「並みの嘘つき」と私の違いだと思っています。

その善後策を考える中から、気づかされることは少なく有りません。例えば、Aと言う課題に対して80％は自社製品でできることは判っている。けれど100％にするために
1. 開発に問い合わせ後、20％が不足するなら機能改善
2. とにかく20％は後の課題として誤魔化す
3. 機能改善に廻る可能性が高く、解決まで時間が掛かる予想が立つので、社外製品を検討する
4. 社内で知っていそうな人間を捕まえて質問する
などなどのオプションを考えたとき、2は兎も角、他については何らかのインタラクションが発生します。そうすると意外な解決策が生まれてきたり、あるいは別会社の製品情報を交えて開発と会話することで機能改善が早まることもあるのですね。いずれにせよ、何らかの解決策はオプションから様々生まれてきますし、以前にも書いた「コードに逃げる」様なことや「技術的には可能だが現実解ではないこと」を除外することができるはずだと思っています。

これは、だいぶ前の話ですが、ある会社の製品をコアとした提案を書いていたときです。当時は今よりもセキュリティやアクセスコントロールが煩くなく、そういった観点で評価をしてみると、どうしても機能が足りなかったのです。そこでベンダーから出てきた提案は外部プログラムを組んで機能補完をして欲しいということでした。確かに論理的には可能なのですが、実装するとなるとデータ量の把握も難しいですし、パフォーマンスの不安もあります。まさに「技術的には可能だが現実解ではない」ですし「コードに逃げる」内容と想い、頂いた提案は却下せざるを得ない局面に立たされました。提案の途中で判明した大失敗です。そこで打った手は、兎にも角にも類似した機能を持つパッケージを探し、実装の可能性をお願いしつつ、当初検討していた製品との競合情報の提供もお願いしたのです。つまり、単に機能不全な状況をリカバリーするだけではなく、より良い提案に昇華…といっていいのでしょうか…させる努力をしてみたのです。
で、その結果を修正提案として提示してみました。失敗の想いを引きずっているだけにビビリ加減はMAXです。が、意外に提案先の反応は良く、提案内容に現実味を感じて頂く事ができました。
と書くと「ほら、成功体験ジャン！」と言われるのでしょうが、実際には今でも、特定の製品に対する優位性を兎に角見つけると言う以前に、何が求められる機能なのかを現実に置き換えて提案に反映すること、その内容をベンダーと共有する事が必要だ（当時、それができていなかった）と言うことに尽きるのです。
それが出来て初めて、改善ができるのだと思うのです。

ただ私の場合、同じような失敗が多いので…（汗）