天才は、Webアプリケーション開発に向かない?
これは、あるWebアプリケーション開発においての、自分の失敗談なのですが。
某企業の、とある支店長から、『売り上げ向上につながるようなホームページの活用方法を考えたい』との相談を受けたことがありました。何度か打ち合わせを繰り返し、結論として特定取引先向け限定の商品をはじめとする各種情報配信サイトを構築することになりました（その結論に至ったプロセスは、ここでは省かせてください)。
この支店長、担当テリトリーとしては、他支店長に比べ、正直痩せた畑を担当させられており、それゆえに『売り上げ向上につながるようなホームページの活用方法を考えたい』と言い出したわけですが。
実に優秀で、かつ発想豊かな方でした。
支店長という管理職でありながら、現場の状況を誰よりも深く理解し、かつ取引先担当者の考え方、嗜好等も細かく把握されていらっしゃる。目的がぶれず、どんな発想も枠にとらわれず、受け入れられる大らかさを持っていて。否定ではなく、常に改善策を模索される、素晴らしい方でした。
こういう方とのお仕事は、非常に楽しく、私も私なりにいろいろなアイディアを考え、ともに検討し、そして件の『特定取引先向け限定の商品をはじめとする各種情報配信サイト』構築に至ったのですが。
結果としては、このWebアプリケーションは、大失敗に終わりました。
残念でしたね...
失敗の理由、それは一言でまとめてしまえば、
『天才の作品に、現場がついていくことができなかった』
ということになるでしょうか....
-『もっと良くしよう』という改善意識が裏目に出た
『特定取引先向け限定の商品をはじめとする各種情報配信サイト』というのは、簡単に言ってしまえば、営業が日々客先を訪問したり、電話/メール等で行う対お客さんへのアプローチをWeb化することで、その効果を最大化かつ効率化しようというものでした。
従来業務を内容を変えずにアプリケーション化、つまり単純移植したのであれば、このような問題は発生しなかったと思います。
しかしながら、本ケースでは、業務改善を同時に目的としてしまったため、従来業務の進め方に対し、大幅なプロセス変更を伴うことになりました。
イメージ的にはこんな感じですね。
新しい行程を追加したり、従来工程の変更を行ったり、結果として『特定取引先向け限定の商品をはじめとする各種情報配信サイト』において完成したプロセスは、従来の業務プロセスとは似ても似つかぬものになったわけです。
つまり、この『特定取引先向け限定の商品をはじめとする各種情報配信サイト』の導入によって、現場はまったく今までと異なったアクションを行うことと等しい状況におかれ、これが大きな導入および運用に対する障壁になったわけですね。
-設計の基本思想が難解すぎた
簡単に言ってしまえば、何のために、どうしてこの『特定取引先向け限定の商品をはじめとする各種情報配信サイト』を作り上げたのか、これによって、お客さんにどのような貢献をしたいのか、そしてその結果としてどのような形で恩恵(売り上げ拡大)につなげていくのか、これを理解していないと、運用が困難なアプリケーションだったわけです。
例えば、商品情報を入力する際、本Webアプリケーションには、『相手にどのようにアピールしたいか』という思想が不可欠で、必ずそのメッセージを入力しなければなりませんでした。そして、そのメッセージが営業戦略と照らし合わせて適当か否かを判断するチェックプロセスを設けました。
営業の立場からすると、これはごく当然のことなんですけどね。
ただ問題は、対面営業ではなく、Webを介した情報発信であるということ。つまり、これまでの判断とは違った判断基準や、商品アピール、伝え方が必要になるわけです。
ある思想、考え方を、あらためて理解し血肉とすることには、当然それなりの困難を伴うわけですが。
運用する方々にとって、この困難が障壁となったわけですね。
-運用ワークボリュームが大きすぎた
あるシステムを導入するということは、そのシステムを運用するための時間が新たに発生するということになります。これは、メールクライアントであろうと、給与システムであろうと、その負担の大小はあれど、避けることのできない事実です。
本アプリケーションの仕様設計の段階で、運用が可能かどうかは、実は常に件の支店長の判断に任せていました。
でも、この人、優秀なんですよね...
だから、普通の人よりも、こなせる仕事量が多いんです...
本アプリケーションには、運用側ユーザーに対し複数の階層を設定、チェックプロセスを設けたのですが、それ故にシステム思想も複雑化、運用プロセスも複雑化、そして運用ワークも大きくなってしまいました。
導入研修を行った際、件の支店長の右腕の方が、『けっきょく、僕がやるんですよね...』としんどそうにつぶやいていたのですが。その右腕は、この運用ワークボリュームをこなすことも、設計思想を理解することも、その方以外の他の方々がこなすことは無理であろうと、即時に悟られたんでしょうね...
お金をかけてアプリケーションを開発する以上、最善のものを望むのは当然の姿勢です。
でも、そのアプリケーションを運用する人間の方も、同じタイミングで最善の状態になれるかどうかは、別な問題なわけですね。
アプリケーションをより良きものとするためには、プログラミングで対応が可能です。
でも、それを運用する人が、より良きレベルを目指そうとすると、その成長のための時間を設ける必要があります。
本件のケースは、大きく分けるとふたつの方法のいずれかを取るべきであったと思います。
- この才能あふれる支店長の思想を、数回にフェイジングして実現する方法
- この才能あふれる支店長の思想は採用するが、実際のアプリケーション仕様設計は、現場の意見を取り入れ、スケールダウンし、構築する方法
恥を忍んで、あえて私の失敗談を書いてみました。
本件、良い勉強はさせていただきましたが、お客さんには申し訳なかったと、今でもつくづく思います。
