システム開発を35年やってきて、いちばん体に染みついている感覚がある。
トラブルになる仕事は、たいてい「受ける」と決めた瞬間に、もう決まっている。
作り方が下手だったからでも、技術が足りなかったからでもない。引き受けた時点で、無理な条件が介在している。今日はその原点になった、若い頃の経験を書いておきたい。
営業さんが持って帰ってきた「できます」
まだ会社勤めのSEだった頃の話だ。
ある信販会社の、キャッシングのシステム案件があった。ATMと接続する部分で、当時のメーカーが「この通信手順は技術保証しない」と明言していた領域だった。要するに、動く保証はどこにもない。
それでも案件は、営業さんが「できます」と言って受注していた。
現場で対応するのには私が選ばれた。「できます」と言った人と、実際に手を動かす人が違う——受託開発をやったことのある人なら、この一行だけで胃のあたりが重くなると思う。あるあるでは済まない。保証されていない通信を、それでも動かさなければ、話が終わらないのだから。
通い詰めた日々
正直に書くと、楽な仕事ではなかった。プレッシャーが大きかった。
保証がないということは、参考にできる資料もないということだ。だから、ありとあらゆる組み合わせを、一つずつ試して潰していくしかない。うまくいかない、原因を探す、また試す。その繰り返しのために、私は、約半年間、その会社に車で一時間半の道を通い詰めて、来る日も来る日も試した。
武勇伝ではないし、望んで始めた仕事ではなかったし、「なんで私が」という感じだった。途中でメーカーの関連会社のCEさんが経過を何度も聞いてくれて相談した。自社の同僚は、対して相談には乗ってくれなかった。その時のCEさんとは今でも電話して話をする。同じ釜の飯を食べたという感じがするのは、この人だ。
そして、最終的には絶対に違うだろうと思っていた組み合わせでつながった。保証されていないと言われた通信は、あらゆる場合を検証し尽くした末に、やっとつながった。
今から思う、二つの反省
ただ、何十年も経ったいま振り返ると、あの仕事には二つの反省がある。当時の自分には見えていなかったことだ。
一つは、営業さんはこの案件を取るべきだったのか、ということだ。
保証されていない通信を、時間をかけて力ずくで動かした。技術的にはやり遂げた。けれども、本当に営業さんは受注すべきだったのだろうか。おそらく、メーカーで在庫として残ったATMを何とか使ってメーカーを助ける、恩を売る、などの気持ちはあっただろうが、時間が掛かりすぎた。
もう一つは、仕事の進め方だ。
私はあのとき、条件をひたすら一つずつ、総当たりで試していった。でも今の私なら、たぶん違うやり方をする。試すべき条件の組み合わせを、コンジョイント分析のような手法で、少ない実験で効率よく当たりを絞り込む。闇雲に全部を潰すのではなく、どの組み合わせを試せば早く核心に近づけるかを、先に考える。当時それができていたら、あの長い通い詰めの日々は、ずいぶん短くできたはずだ。統計分析手法を使うという意識が、当時は全くなかった。
だから私は、「まず整理しましょう」と言い続けている
いま私は、システムを作る前に、会社の業務と情報を整理する仕事をしている。「WITS整理法」と名前をつけて、経営者の方に伴走している。なぜ、そんな遠回りに見えることを勧めるのか。
前提がずれたまま走り出せば、どんなに優秀なチームでも、ゴールは遠ざかる。そもそもやる必要があるのか、やるなら何をどう試すのか。それを先に整理しておくだけで、後の開発は驚くほど静かに進む。若い頃に遠回りして学んだことを、私はいま、「作る前の整理」としてお客さんに渡している。
遠回りに見えて、前提を整えることが、いちばんの近道だ。
35年かけて、それだけは確信している。
コメント