C#が企業コストを削減：流行語と無駄な予算の実態を解説

最近ちょっと思ってたんだけど、世の中には「ブーンドグル [boondoggle]」っていう言葉があってね。これ、辞書で引くと「無駄な、あるいは無意味だけど、価値があるように見える仕事や活動」って出てくる。要するに、見栄っ張りなだけのデカいプロジェクト、みたいな感じかな。

なんていうか、問題を解決するのって、切れ味のいい斧みたいなもんだと思うんだ。的確で、効果的で、最小限の力で仕事が終わる。でも、パニックになったり、自分たちのチームを信用できなかったりする組織は、なぜかスカルペルで済むような作業に、巨大なハンマーを持ち出しちゃう。その結果、大金がかかったわりに性能はイマイチで、後には後悔しか残らない…みたいな。そういうのが「ブーンドグル」なんだよね。

もっと悪いことに、こういう失敗って、時代遅れのやり方とか、やたら持ち上げられてる流行りの技術に固執することから来ることが多い。正直、もう役に立たないのに、それにしがみついて組織全体の足を引っ張ってる感じ。『[Accelerate]』の著者、Nicole Forsgrenも言ってるけど、「レガシーなITプラクティスに依存し続ける組織は、長期的にはますます不利になる」って。まさにその通りで。

で、つい最近、僕らがまさにそんな感じの、まあ、盛大な「ブーンドグル」の後始末をする機会があったんだ。これがまた、すごいやつでさ。

クライアントは林業とか伐採業をやってる会社。現場の作業員が、備品とか部品とか、消耗品を探して要求するためのシステムが必要だった。まあ、聞いただけだと簡単そうに聞こえるでしょ？でも、林業の現場って、普通のカタログに載ってるような言葉遣いをしないんだよね。例えば、吸収パッドは「オムツ [Diapers]」って呼ばれてるし、万力は「ホッグクランパー [Hog Clampers]」とか。重機の名前なんて、なんか民話に出てきそうな感じ。「フェラーバンチャー」とか「スキッダー」とか言われても、普通は「木を切る機械」とか「丸太を運ぶやつ」だなんて思わないじゃん。

さらに問題なのが、現場の人たち、スペルがまあまあ苦手でね。「トルクレンチ [torque wrench]」が必要なのに、「tork rinch」みたいに検索しちゃう。これじゃあ、普通の検索エンジンじゃ歯が立たないわけ。

で、僕らが引き継いだのは何かというと…その組織、なんとGoogleに頼っちゃったんだ。Google Search Appliance [GSA]っていう製品に25万ドル。で、その設定とかの専門サービスにさらに25万ドル。合計50万ドル。日本円にしたら…まあ、5000万円以上だよね。おまけに、年間のソフトウェア保守費用が6万ドル。どんだけ金かけるんだっていう。

それだけ払って、結果どうだったか。現場の満足度は70%くらい。まあ、赤点じゃないけど…って感じ。しかも、24時間稼働してる業界なのに、データの更新が遅い。俊敏で反応のいい検索エンジンが必要だったのに、手に入れたのは、泥だらけの林道にスポーツカーで乗り込むみたいに、場違いで、重くて、高くて、のろまなツールだったんだ。

TL;DR：先に結論を言うと

めちゃくちゃ高いお金を払って外部の有名ツールを入れたけど全然ダメで、結局、社内の開発者がC#でサクッと作ったら、爆速で超安上がりで、しかももっと良いものができたって話。内製の力をなめちゃいけない。

どうやったの？そのC#のやつ

僕らが現場に入ってやったことは、アプローチを根本から変えることだった。なんかこう、「エンタープライズ向け」みたいな金ピカのソリューションが必要な問題として捉えるんじゃなくて、彼らが本当に必要としてたのは、彼ら独特の言葉遣いや働き方に合わせた、軽くて高性能な検索システムだって考えたんだ。

で、アーキテクチャを考え直して、もっとスリムで効率的なソリューションを、社内のリソースだけで、しかもほんのわずかなコストで構築した。システムの根幹はシンプルだけど、すごくパワフル。

まず、ERPシステムに入ってる商品カタログとか固定資産のデータを、こっちが決めたい頻度でクラウドストレージに持っていく。構造化されたフォーマットで保存して、超高速で検索できるように準備しておくわけ。これでデータはいつでも使える状態になる。

次に、主役の登場。C# と LINQの力を使って、メモリ内で検索処理を完結させる。これが、前のGSAと比べて、体感で100倍くらい速かった。マジで爆速。

それから、問題の「あいまい検索」と「おすすめ機能」の部分。ここがキモだよね。小さいけど強力なニューラルネットワークを組んで、既存のデータを分析させた。Soundex値っていう、まあ、発音に基づいたキーを使って、似たようなキーワードをマッピングしていく。これで「tork rinch」と「torque wrench」が結びつくわけ。

それだけじゃなくて、さらに精度を上げるために、色々な「あいまいテキスト比較アルゴリズム」を重ねがけしたんだ。具体的には…

• リーベンシュタイン距離：まあ定番だよね。1文字の違いとかを検出するやつ。
• ハミング距離：これも似てるけど、文字数が同じ文字列間の違いを見るのに使う。
• 最長共通部分列：二つの文字列で、共通してる一番長い部分を見つける。
• Ratcliff/Obershelp類似度：これも結構使われるパターンマッチング。
• ジャカード類似度：単語の集合がどれだけ似てるか、とか。
• コサイン類似度：ベクトル空間で向きがどれだけ似てるか見るやつ。文書の類似度とかによく使う。
• ジャロ・ウィンクラー距離：特に人名みたいな短い文字列の打ち間違いに強いって言われてる。

このへんのアルゴリズムを、まあ、片っ端から試したというか…いや、課題に合わせて最適なのを選んで組み合わせたんだ。これで、現場の人が多少スペルを間違えても、「もしかしてこれ？」って賢く候補を出せるようになった。

あ、ちなみに、これは最初のスコープには入ってなかったんだけど、おまけで強化学習の仕組みも入れた。ユーザーが検索結果の修正候補をクリックしたときのデータを捕まえて、それを学習させることで、時間とともにおすすめの精度が上がっていくようにした。こういう「ちょっとしたおまけ」が、後々すごく効いてくるんだよね。

結果、どうなったか。ライセンス費用ゼロ、保守費用ゼロ、特定のベンダーに縛られることもない、超高速で超正確な検索ツールが完成した。現場のクルーが、本当に「使える」ツールだよ。

GSA 対 C#内製、コストと結果を比べてみた

こうやって言葉で説明しても分かりにくいだろうから、ちょっと表にまとめてみた。どんだけ違ったか、一目瞭然だと思う。

この内製システム、開発にかかったのは社内のリソース2.5人分（開発者2人と、アナリストがちょっと手伝ったくらい）で、期間は2ヶ月。開発者の平均給与を仮に10万ドルだとしても、実装コストは全部で7万5000ドルくらい。GSAへの50万ドルの投資と、毎年かかる保守費用と比べたら…もう、笑っちゃうくらいの違いだよね。

なんでこんな無駄遣いが起きるの？

でも、こういう「ブーンドグル」って、マジでどこでも起きてる。なんでだろう？っていつも不思議に思うんだけど、たぶん、多くの組織が自分たちのソフトウェア開発能力を過小評価してるからなんだろうね。

派手な営業資料と、ウン千万円の値札を付けたベンダーだけが自分たちの問題を解決できるって思い込んじゃってる。でも本当は、開発者を単なる「言われたことをやる人」じゃなくて、「戦略的な資産」として巻き込めば、彼らはその期待に応えてくれるんだ。

開発者って、挑戦が好きだし、ビジネスのことも理解しようとする。それに、結果的にもっと効率的で、コストもかからず、そして何より組織の「本当のニーズ」に合った、ゲームチェンジャーになりうるソリューションを生み出せる力を持ってる。

日本だとよく「2025年の崖」とか言われるけど、これって古いシステムの話だけじゃないんだよね。こういう、自分たちのチームを信じないっていうマインドセットこそが、崖から突き落とす原因なんじゃないかなって思う。レガシーなのはシステムだけじゃなくて、経営層の頭の中だったりする。

Mark Schwartzも『[War and Peace and IT]』で言ってるけど、「ITはビジネスそのものであり、ITをコストセンターとして扱うのをやめ、イノベーションエンジンとして扱い始めたときに、デジタルトランスフォーメーションは起こる」んだ。IT部門を単なるサポート部隊じゃなくて、戦略的な推進役として見なさない限り、一番強力な資産、つまり競合他社と差別化できるような、自社に最適化されたインパクトの大きいソリューションを構築する能力を、みすみす逃すことになる。

ベンダーに駆け込んで白紙の小切手を切る前にさ、まず自分たちのチームが何ができるのか、ちゃんと見てみたらどうだろう。最高の解決策は、案外、すぐ目の前に隠れてるかもしれないよ。もし、それでも社内チームを信頼できないなら…それはもう、ソフトウェアの問題じゃない。あなたのマインドセットの問題だ。

皆さんの会社でも、こういう「見栄っ張りなIT投資」って、ありました？もし差し支えなければ、どんなツールだったか、こっそりコメントで教えてください（笑）。