ヤッホーブルーイング株式会社
“思いを変えた瞬間があった” システム開発の内製化を決意した理由
株式会社ヤッホーブルーイング
システム管制塔（情報システムユニット）
ユニットディレクター
木村 壮氏（写真左）、岸 拓郎氏（写真右）
ヤッホーブルーイング様は、事業拡大に伴い社内システムの一角である需給管理システムを刷新する際、悩んだ末に内製化を決意されました。自社のビジネスのコア領域を活かすためにどの様な判断基準で意思決定し、どう課題を解決して行ったのか、この事例から社内システム開発のヒントを得ていただければと思います。
プロジェクトの概要
(木村氏)今回のプロジェクトで取り扱ったのは、主に需給管理システムです。
私たちはクラフトビールを製造している会社なので、商品を製造した上でお店にご提供するのですが、実際にビールを製造してから消費者の皆様にご購入頂けるお店に届くまでに、大体 1 ヶ月から 2 ヶ月ぐらい時間がかかります。製造してからお届けするまでにリードタイムがかかる為、「お店で売れたのですぐ用意してください」と言われても、その時点で在庫がなければ間に合いません。一方で賞味期限がある商品ですので、大量に作りすぎてしまうと、在庫が余ってしまい廃棄ということにもなりかねません。
メディアに取り上げられた時など、需要が急激に増えた時の供給量を担保しつつ、廃棄が出ないように適切な在庫のコントロールをどうしていくのかというところが、弊社の需給管理の大きなテーマでした。弊社では上記のような需給管理を、専門チームが分析をしながら在庫管理を徹底しています。
このような管理を徹底してきたのですが、最近の出荷量の伸び方から、数年以内に現行の 1 箇所の倉庫から出荷する方法では限界に達するため、数年前から出荷倉庫の増設を検討し始めました。
しかし、複数の倉庫から出荷となると、在庫の管理が非常に複雑化し、様々な問題が出てきました。それを人の頭で全部やるには限界があり、現場からの相談もあって、情報システムの部署と現場が一緒になって IT の力をかりて解決していこうということになりました。
Google Cloud 導入経緯
(木村氏)昨年の秋頃から、要件定義書を自社で作成した上で、何社か声がけをしてシステム更改をしてくれるパートナー企業を探し始めました。需給管理の仕組み自体が、各企業独自のルールやノウハウがたくさん詰まっている世界なので、パッケージを前提とした一般的なシステムがなかったんです。色々な IT ベンダーの方に相談してみましたが、どこからもスクラッチ開発を推奨されてしまいました。結局、実現したいシステムの開発を専門家であるIT ベンダーへアウトソーシングしようと思うと、開発コストが合わなかったんです。
(岸氏)現状利用しているシステムは、Google スプレッドシート で作ったものがありました。ただ、importrange 関数というスプレッドシート間でデータを参照できる機能をフル活用して、様々な業務との連携を自動的に引き継がれるように作ってしまったため、非常に複雑なシステム構成になってしまっていました。そして最終的に、それの開発を担っていた社員が退職してしまったことで完全にブラックボックス化してしまっているのも課題でした。
(木村氏)元々 IT の知識をそれほど持っていないユーザ企業である我々が、Google Workspace(旧 G Suite™) を活用して業務に必要なツールを作れていた現状を考えると、 Google スプレッドシートをユーザインタフェースとして活用しつつ、データベースの部分をうまくGoogle Cloud™ に移行するように作り直す部分を自社で実現出来るのであれば、業務を理解している分だけ迅速・柔軟性を担保しつつ、コストを抑えることができるのではないかと考えました。そこでクラウドエースに依頼するとどのようなかんじになるのか伺ったところ、「簡単に出来ると思いますよ」とサラっと言われて、スタートしていった感じです。ただ、開発したシステムを自分たちで保守しきれるのか、という不安はありました。その点も含めて相談したのですが、今回実現したいシステムがそこまで複雑なアーキテクチャを組まなくても実現できそうだったのと、「業務を一番良く理解されているのはヤッホーブルーイングさんじゃないんですか」という話をいただき、やはり開発から保守まで全てをお任せするよりは、保守しやすい仕組みで作り上げ、自社で適宜機能を改変していけるほうが、自社の市場競争力の向上にも繋がるのではないかと思い直しました。そのサポートをクラウドエースにしてもらえないかな、と考えました。
元々自社で要件定義自体をかなり細かく決めていて、出来上がったシステムをどのように使っていくのか、どんなものを作っていきたいか、というイメージはできていました。ただ、自社で Google Cloud を使用しての開発経験がある社員がほとんどいなかったので、どのようにそれを実現していけばいいのか分からなかったんです。それをクラウドエースと話していく中で、実現できそうな手段を提案して頂き、イメージが固まっていったかたちです。
システム構成について
アーキテクチャのポイントとしては、BigQuery と Google Workspace(旧 G Suite™) のスプレッドシートを組み合わせたシステムになっています。
これまでのシステムは、スプレッドシートの中にデータベースと画面UIの両方の機能をもたせており、様々な関数の組み合わせたり、スプレッドシート間を参照し合うような形で出来た仕組みになっていました。そのため、スプレッドシートをまたいだデータを利用した分析がしにくかったり、関数が崩れるとシステム全体が壊れてしまうリスクを抱えていました。そこで、現行システムを一度棚卸した上で、データベースを BigQuery に持たせ、実際にユーザが触る画面 UI 部分をスプレッドシートに持たせるように分解をしていきました。ユーザーが触る画面とデータを分離したことで保守性や拡張性も高まったと感じています。また、データが複数のスプレッドシートに散在していて分析等に活用できていなかったデータを BigQuery に集約できたことで、将来的なデータ基盤実現に向けた未来への投資にもなったと思っています。社内に散在している他のデータも、将来的には BigQuery に集約していきたいですね。
成果と気付き
(木村氏)やはり、自分たちが作りたいものは自分たちが一番分かっているので、自社でシステムを作ることにトライすることがいかに重要であるかに気づけたところが一番の成果です。自社のビジネス的な強みを持つコア領域の業務の IT 化については、可能な限り内製化してこうという指針はあったのですが、それを実現できるんだと確信できたのが大きかったです。今の時代、SaaS 型のクラウドサービスも多く揃っていますし、ローコーディングやノンコーディングのプラットフォームも沢山出てきているので、ユーザ企業としては自社で開発が非常にしやすくなったと思います。
とはいえ、自社で作ったものに関しては品質面で不安がないとは言い切れませんので、何もかも自社で実現していくということではなく、仕様が確定するまではプロトタイプを作る感覚で、まずは自分たちで作ってみて、自分たちの手に負えなくなるぐらいの規模感になってきそうであれば、IT ベンダの方にサポートいただいていく必要は引き続きあると思います。ただ、主導権をユーザー企業側が持てるようになったところは、すごく大きな変化だと思います。
(岸氏)現場で実際にシステムを活用するスタッフを開発メンバーに加えた上で、開発を進められたので、業務にマッチしたものが出来てきました。自分たちで作れたとしても、運用方法まで意識した細かい部分の作り込みが十分に出来る自信はあまりなかったので、そこをクラウドエースに支援して頂けたのは大きかったです。
IT の専門家ではない業務メンバーが開発をするということは開発がうまくいかなくなるリスクもありますが、それ以上に業務として実現したいことを作り上げられる点は大きいと思います。開発を通じて自分たちの業務におけるコア領域がどこにあるのかが明らかなったので、どの部分は自分たちでこだわりをもって作り上げていくべきなのか、コア領域ではないどの部分を思い切って簡素化したり、自動化していくかを考えるきっかけになったのも良かったです。
今後の展望
(木村氏)正直、開発が始まった当初は失敗するリスクも半分くらいあるなという感覚でした。ですが、クラウドエースの手厚いサポートを受けながら開発メンバーが積極的に取り組んでくれたおかげで、やっとチームも立ち上がってきて、これはなんとかなりそうだぞ！というスタート地点に立てたと思っています。
現行システムは、開発を担っていた社員しかシステム改修ができないという属人化が大きな課題の一つでしたので、今回作ったシステムは属人化しないように、継続的にシステムの改善や運用を担える人材の育成にも力を入れていきたいと考えています。
自分たちだけでも Google Cloud を上手く使えば自社で使いやすいようなシステム開発ができるということが分かったので、需給管理システムに限らず自社の競争力につながる業務領域は、積極的に SI 2.0 を取り入れたやり方で IT 化を推進していきたいです。
この記事を共有する
