「あのとき、なぜSFAとBIをスクラッチ開発したんだろう？」を振り返ってみる

15年ぐらい前の話ですが、異動になったことをきっかけに社内向けのSFAとBIのシステムをゼロからソロ開発したことがあり、いまさらですが「なんであんなに無謀な挑戦だったのに、結果的に成功できたのだろう？😅」を振り返ってみたいと思います。

なぜ？わざわざスクラッチ開発？

イマドキそう思いますよね。世はクラウド全盛☁️ですし。
でも最初からSFAとBIを作ろうとしていたわけじゃないんです。欲しいものと必要なものを徐々に作っていったら、最後はSFAとBIになっていたという…。その上、その頃SFAやBIがどんなものか、触ったこともなくて、だいぶ後になってから「あ、あれSFAとBIじゃん」って感じでした。(笑)

モノづくりの会社でしたので、自作文化だったのもあります。自社のシステムとかツールは大体スクラッチ開発でした。それが当たり前かな？というのもありました。私も最初はソフトウェア製品開発のプログラマーとして入社してましたので。

完成してから10年間使われるシステム

ありがたいことに、完成してから10年間しっかり営業さん中心に使ってもらいました。10年経って会社の決算月が変わるということになって、私もそのときポジションが大きく変わっていたので、「流石に10年もほぼメンテなしで使ってまだ必要なら、新しいのにするか、改修コスト外でかけなよ」って話をしてましたが、結局クローズになってパッケージ製品に置き換わりました。その後も「あれがいいんですけど」って話を営業現場からちらほら聞いて、密かに嬉しかったですね。(´∀｀*)

使われ続ける秘訣は何だったか

一つは、システムの構築スキルを持った上で営業の現場部門に配属になったことです。自分でも欲しい機能を考え、現場にある目の前の課題を直に聞きながら、都度要件をさらって実装し、すぐにフィードバックもらって、機能に反映してまた拡大する。

よくよく考えるとリーン・スタートアップの開発手法そのままでした。

もう一つは、欲しいと言われた機能をそのまま実装しなかったこと。

よく、製品開発で言われることですが「顧客の言う通りそのままに作っても良い製品にはならない」という考え方です。なんかこう書くと聞く耳持ってない人みたいに聞こえますが、そうじゃなくて、散々現場の課題とか必死に作ってる帳票とかレポートを教えてもらって調べまくって、何にどう役立ててるのかを聞くんです。

そうすると「あれ？あのレポートってあれと結局同じじゃない？」とか「あのデータの出元って同じなのに転記作業が複数回発生してるよね」ってことがわかってくる。それを頭の中とか紙に書いてつなげ、表面で見せたいレポートのイメージとそれに必要な中のデータ構造を想像し、最適化してそげ落として、プロトタイピングして…ってやってるうちに自分が欲しいものとみんなが欲しいものが見えてくる感じですね。

どういうものができたのか？【SFA】

まずSFAについては、社内のGoogleにしようと思ったのがきっかけです。

自分が畑違いから営業部署に来たこともあって、得意先やら製品の状況がすぐにわからない。名前ぐらいは知っていても、今何が売れてるのか、どこに売れてるのかいちいち調べないとわからなかった。これが自分には異様に面倒で。しかも、取引先が常時1,000以上、数千の製品が現行で取り扱われているので、とにかく頭に入れなくちゃいけないスピードより調べる時間が上回ってて。でも営業現場の人たちは肌感覚でわかってるんですよ。そりゃそうですよね。何年もその専門でメシ食ってるわけですから。「これはまずい。デクの坊じゃん俺」って思ったのが最初です。

そこで、基幹システムから出力されている参照用のDBにアクセスして、Googleみたいにテキスト一つで検索すると、属性情報やら売上を参照できるWebプログラムを作ってみました。Googleっぽさにこだわって、機種コードだろうが電話番号だろうが名称だろうが、何入れてもいい感じに引っかかるようにして。これが実は後から考えるとめちゃくちゃ大事なインターフェースでした。

それから、この仕組みと相性が良かったのが、自社が新規開拓型の企業じゃなかったことです。楽器業界はほぼ成熟したマーケットだったのと、割と老舗だったこともあり、新しい楽器店さんがわさわさ取引先として増えるってことはなく、注文もコンスタントに入っていました。なので、Salesforceのような開拓型のシステムとはあまり相性が良くなかった。
それで、参照型に徹して、とにかくマスターに入っている情報を検索したら、それに関連する情報をクリックするだけでどんどん知れるようにしようと。
誰が担当で、所在地はどこで、過去何をよく売っていて、最近何を仕入れているのか。目標売上予算を入れる仕組みも別途作ったので、どの部署、担当がどのぐらい達成していて、得意先の割合がどうとかもすぐ表示できました。リンクを辿れば、知りたいことが体系的にわかる導線にしたおかげで、営業部全体から個々の活動を直感的に追いかけることができました。

しかも、半期に一回の予算入力を除けば、営業マンがデータ入力することがほとんどない仕組みでした。だからSalesforceでよく言われる「営業マン入力してくれないあるある」とか、そういうことは一切なくそのまま100%精度のデータが参照できました。

どういうものができたか？【BI】

BIっぽいものについては、みんながEXCEL転記地獄で苦しんでいたので、それならば作ろう！と。
よく使われる軸を3つ（1. 得意先・販売店、2. 部署・担当、3. カテゴリ・製品）に絞り込んで、それをドリルダウンしたら年間の予実がずらっと並ぶようにしました。自動的に下の階層に誘導できるようリンクにして、断面もすぐに1→2、2→3のようにスイッチできるようにして。

さらに、レポートの断面を全てユニークなURLパラメータで開けるようにしておいて、上でご紹介した社内版Googleでダイレクトに辿れるようにしたんです。

これで、営業1年目社員でも、Googleライクに調べれば一発で属性情報と売上の状況がわかる、という仕組みが出来上がります。

その後、需要予測やら生産状況やらが見えるようにしたり、受注窓口の人たちの支援システム作ったり、いろいろやりましたね…。プログラマーは私ひとりでしたけど。(笑)

今のSFAやBIに欠けている視点

最近は、SalesforceやMS Dynamics、tableau、QlikViewやQuickSightなどを使う機会に恵まれましたが、振り返ってみるとまだまだこの辺りの製品にも改善の余地があるように思います。

・検索してからすぐに知りたい情報が網羅できるか

Salesforceでは検索すると、すぐに属性情報や活動履歴には行き当たります。ですが、レポートやダッシュボードには別な導線が必要です。（しっかりカスタム開発している会社さんはできるかもしれないですが、デフォルト機能の設定レベルではできないですよね。）

大量の商品を抱えていたり多数の取引先とお付き合いしている企業であれば、検索してすぐに現半期や過去の数字にたどり着きたいこともあると思います。このあたりがBIと完全統合されず分断されているのが気になります。（と言いつつ、各CRMベンダーが主要BIツールを取り込んだので、徐々にシームレスになってくると思いますが、自分からすると15年遅いぞと。えらそーに言っちゃいますが。ｗ）

・データの断面に連続性を持たせることができるか

もう一つは、レポートやダッシュボード 、BIのドリルダウンでデータの断面自体はたくさん作れますが、すぐに軸をスイッチできるツールがまだ少ないように思います。厳密に言えば、BIのモデルを作る権限を持っている人には可能ですけど、使う側は割とドリルダウン一方向に限られていて、軸を縦横無尽に変えながら、時に掘ったり上に行ったり、ということができるツールにはまだ出会ったことがありません。（もしかしたら私がたくさんのBIをみられていないので既に存在するのかもしれませんけど…）

・業務に長けた人だけに偏ったヒアリングをしてはいけない

これはアプリケーションというよりは、SIやインプリで気をつけることですが、よくある導入プロジェクトの一幕では、もう何年もその業務を行っている人に対してヒアリングするのが普通なんですよね。そうすると、往年の技というか、ある程度面倒なことや熟練しないとできないことを受け入れてしまっていて、システムの要件にそのスキルが前提条件として盛り込まれてしまうことがある。ですが、それを当たり前と思わない方が業務全体のイノベーションが起こることがあります。（例えば会計系のアプリだと、MoneyForwardクラウド≒主に経理担当経験者向けと、freee≒スタートアップ経営で経理未経験者向けの違いみたいな？）
畑違いの私みたいな人間が配属になったことで、往年の営業スキルがなくてもすぐに直感的に使えるようなツールが生み出されることもある、ということですね。実装する時に素人でもいきなり生産性を上げられるかどうかの観点は盛り込んだ方が良いです。そういう意味ではまだまだSalesforceとかは素人がいきなり使いこなすのは難しいです。

開発の裏方

「おひとりさま開発って、それあんたどうやって作ってたの」って聞きたい人いますか？…まいっか、独り言だと思って書いちゃいます。(笑)

プログラムは、ColdFusionです。DBは、SQL Server。

え？ColdFusion知らないですか？　デスヨネ…😎
ColdFusionは、Adobeさんの扱っているサーバー言語で、HTMLライクなCFMLって文法でDBアクセスやらけっこう便利なJSライブラリやらを呼び出せるマークアップランゲージなんですよ。何せ開発スピードが速い。今でこそマイナーですけど、私は習得速度と開発速度を考えると、業界最速のプログラム言語だと思ってます。
チャートのモジュールがショボかったのでカスタムタグを自作したりもしました。一般公開してましたけど、今はもうだいぶ古くなっちゃいました。

DBの方ですが、こちらは実は基幹システム側が出してきたデータをほぼそのまま参照してます。中間で汎用構造のデータを一旦キャッシュして高速化してたりはしますが、アプリのために巨大なデータを別途DWHにストックして、みたいなことは一切しておりません。でも、何だかうまくいったんですよね…

開発期間は、汎用モジュールの実験やPoCで3ヶ月ぐらい。だいだい大枠が完成するまで3ヶ月ぐらい。あとは併走で徐々に拡張って感じですね。完全に固めるまでに2年ぐらいかな…。

最後までご高覧いただきましてありがとうございました。

というわけで、長文でございましたが、楽しんでいただけましたでしょうか？いつもながらおっさんの戯事だらけでしたが、お読みいただいてありがとうございました。また何か思いついたら書きます。ではでは