Articles tagged with: PHP

事例:株式会社フラン様


基幹システムと店舗POSレジシステムの刷新にあたって、周辺システムにkintoneを選定

  Topへ↓

株式会社フラン様は、40年以上前の創業時から女性向けランジェリーを扱っておられます。
当初は輸入ランジェリーの販売が主でした。その後、各地のショッピングモールにチェーン展開を始めると同時に商品ラインナップを大幅に見直し、今では豊富なデザイン・機能・サイズのランジェリーを展開しています。
本稿を執筆時点では全国にリアル店舗が19店舗。オンラインショッピングモールに11店舗を出店し、順調に成長しておられます。

フラン様を弊社にご紹介くださったのは株式会社スマレジ様及び大幸パートナーズ株式会社様です。
フラン様と弊社のご縁のきっかけとなったのは、フラン様が各店舗のPOSレジシステムの刷新を行うと決めた時点からです。
フラン様はまず、スマレジ社にお声掛けしました。
スマレジ社の運営するスマレジはPOSレジ機能に特化しています。POSレジ機能を補完するため、スマレジにはアプリストアが用意されています。多くのアプリ群がスマレジの機能を支えています。そのアプリ群の一つにスマレジから請求書を出す「セイキューン」があります。大幸パートナーズ様は、この「セイキューン」を開発・運営されておられます。
ところが、フラン様が望む請求書発行の運用は「セイキューン」で満たせたものの、他の店舗運用を満たすためのアプリがアプリストアにはなく、その解決策をフラン様より相談された大幸パートナーズの五十嵐社長が提案したのがkintoneでした。
そして、kintone側を担うシステム開発会社として弊社を推していただきました。

多種多様の品揃えを管理するための設計

  Topへ↑

スマレジの標準機能では実現できない運用。フラン様の課題は最初から明確でした。

まず、商品管理です。
フラン様が展開するランジェリー商品のラインナップは、上に書いたとおり多種多様にわたります。そのラインアップを支える上で細かい商品管理が欠かせません。ところが、スマレジの備える商品管理機能はフラン様の要望を完全に満たしていませんでした。
例えば、フラン様のランジェリー品目はサイズごと色ごと品番ごとに設けています。それらの商品管理単位(SKU単位)の数はアクティブな点数だけを数えても五万点を超えています。その入力方法はどのように行うのか。データの関連性はどう設定するか。
さらに、SKUの一つ一つにJanCodeを発番する必要があります。スマレジのPOSレジ機能にはその機能がありませんでした。

次に商品物流管理です。
スマレジのリテールビジネスプランには入庫、入荷、出荷、出庫などの機能が備わっています。また、高度な在庫管理機能も備わっています。
ですが、それらの処理をスマレジに指示する際、一店舗ずつ処理を行う必要がありました。
つまり、多店舗×多品種で運用するフラン様の業務上、入力の手間が生じることが予想されていました。

続いて、売上分析機能です。
スマレジが擁する売り上げ分析機能では、経営のかじ取りを行うための分析ができず、分析をkintoneで代替させたいとのご要望もお持ちでした。

あと一つは、オンラインショップの売上データを変換し、そのデータをスマレジの売上データとして登録する機能です。
これもkintoneを経由させ、データを加工させればよいのではという構想をおもちでした。

最後に、ピッキングリストを発行する機能です。これが一番のフラン様のご要望でした。
ピッキングリストとは、倉庫の担当者が商品を棚から選ぶ際のリストの事です。
つまり出荷/出庫予定に対し、迅速に棚から商品を出すリストの出力が喫緊の課題でした。
スマレジはタブレットから簡単に出庫予定を出せます。が、紙のリストを出す機能はありません。SKU点数が多いフラン様の運用上、より運用に即したピッキングリストを出す必要に迫られていました。
望ましいピッキングリストとは、現在の在庫数に加え、入荷・入庫予定を算出してくれるものです。
店舗ごと、SKUごとに設定した在庫定数を下回るか、または指定した任意の期間の売上数に応じた数量を反映したピッキングリストを出すことは、フラン様の各店舗の在庫管理の肝でした。

スマレジはPOSシステムとして優れた機能を持っています。
ですが、それでも上記のようにフラン様のような多品種を扱う業種では補いきれない点がありました。
これらの機能をkintoneで補完し、スマレジのPOSレジ機能の良さを生かす。これが今回の案件のミッションでした。

SKUの多さを克服することが大変

  Topへ↑

開発の期間は約半年。
約半年の間、kintoneのアプリ間の連携や、JanCodeの発番機能の実装など、kintone側で出来ることは順次仕上げていきました。
特に商品管理を実現するため、多くのアプリを組み合わせました。品番やSKU、カラーやサイズなど。そうしたアパレル系のお客様ならではの商品管理を実現することがまず最初の難関でした。
フラン様のご担当者と何度もオンラインで打ち合わせを重ね、kintone自体の癖や特徴もお伝えしながら、より良い商品管理につなげていきました。

また、フラン様が求めるSKU単位で商品管理を行うご要望では、多数のレコードが必要でした。
それは、kintoneのレコード数の増加と、レコード数が多いことによる処理時間の増加に直結します。
処理時間を工夫し、タイムアウトエラーを起こさずに処理を実現する。それが開発上でもっとも苦労した点でした。
どうすれば処理時間を短くし、業務に影響を与えぬように短時間で処理を終わらせられるか。

例えば、新たな商品を登録した場合の処理です。
kintoneには商品データの背後に多くのマスタアプリが連なっています。商品データを登録した際、多くのアプリにデータを連動することが求められました。
さらに、kintoneで作ったデータをスマレジに登録する際も大量データによる問題が発生しました。
そのため、当初はフラン様がCSVを取り込む運用を行う想定でしたがうまく行きませんでした。
そこで、当初は開発範囲外だったkintoneからスマレジへの商品登録の必要が生じました。

また、店舗ごとSKUごとに在庫の定数レコードを作成する処理も必要です。
頻繁に新商品が発生するフラン様の場合、細かいデータの連携が必要となります。
当初はデータを連携するためにkintoneの画面上にボタンを設置していました。ところがボタンを押した後に処理を待つ時間が生じ、さらには大量のデータを処理する間にタイムアウトエラーが生じてしまいました。
これは一件ずつ、追加と更新の判断をしながら、大量のレコードをkintoneで処理する必要があったためです。これをどのように制御するか。処理がタイムアウトしてエラーになる事象をどのようにして回避するか、ここでも開発に腐心しました。
こうした処理はkintone内でJavaScriptに担わせる実装をやめ、サーバー内においたphpプログラムに任せるように処理を変更しました。
その際も、夜間バッチや都度処理の併用を幾パターンも試しました。

大量データに関する課題は、ピッキングリストの発行処理でも生じました。商品データ、在庫定数データ、売り上げデータ、そして入荷/入庫予定データ。ピッキングデータを出すまでにはいくつものアプリで大量のデータを扱う必要がありました。
これらの処理も全てphpに移管しました。しかもkintone画面上でもタイムアウトを生じさせないよう、Ajax処理を時折挟んで制御を行い、タイムアウトが生じないような工夫を行いました。

あと、ご要望としてあったのが、スマレジの各種データをバッチでkintoneに取り込む処理の実装てす。これも何度も調整を重ねました。
バッチ処理を実行するのは一時間おきなのか、それとも一日一回なのか。
スマレジのAPIの条件設定も含めて、その実装にもかなりの創意工夫を凝らしました。

スマレジのデータを追加/更新する際、スマレジ側で処理時間のタイムアウトにならないような工夫も必要でした。
そのエラーを回避する検討にもかなりの時間を掛けました。
ブラウザで制御を行うため、一定期間ごとにAjaxで処理を更新する機構はまさにその一つです。
データ数が何万件にもなる場合、kintoneとスマレジの両方で考慮しなければならない点が多く、それらを満たすための処理にはかなりの時間を掛けました。

お客様にもkintoneに関わっていただきながら運用へ

  Topへ↑

並行してフラン様にもkintoneの理解を深めていただきました。
フラン様のご担当者様は、kintoneのコマンドラインツールであるcli-kintoneの使い方を学び、自力で kintoneからの出力処理を実装するまでになりました。
弊社はこうした実装については助言をし、お客様自身で可能なように支援しました。
その助言をもとにkintoneを使いこなしていただけたのは、今回の開発において手応えを感じたことの一つです。

kintoneアプリの修正も双方で連携をとりながら、破綻させずに少しずつ運用開始に向けてkintoneとスマレジの双方で実装を進めていきました。
各店舗のスタッフ様への操作研修も順次実施していただき、無事に11月に運用が開始できました。

特筆すべきは、初めのご挨拶から運用開始まで、一度もフラン様とはオフラインの対面でお会いしていないことです。
全てをリモート(zoomとチャットワーク、たまに電話)の連絡だけでやり切りました。

これは弊社にとっても大きな自信となりました。フラン様の皆様には感謝です。

フラン様より

フラン社の奥村社長はこう語ってくださいました。

「ここまでクライアントの要望を何度もくみ取り対応頂ける開発会社は初めてです!」

弊社のPOSレジの切り替えに伴い、業界でも注目されているスマレジの利用を検討しておりました。機能を調べたところ弊社の運用において不足している機能が多々あり導入を半ば諦めていたころ、ご縁を頂いたのがアクアビット様になります。弊社ではKintoneの利用経験がなく実際の運用にあたり問題が発生しないか心配しておりましたが、アクアビット様の度重なるヒアリングをベースにした開発や問題発生時の素早い対応などにより、当初の心配が嘘のように無くなっていきました。これからも弊社のパートナーとしてサポート頂きたいと思ってます!

フラン社の小林様はこう語ってくださいました。

「kintoneについての知識がゼロの段階から、
毎回のミーティングを通して弊社側の要望や意図を汲み取り、
個別アプリの作成、アプリ間の連携、そしてスマレジとの連携に至るまで、次々と形にして頂けたこと、
またその後大きなトラブルもなく今日まで運用できているのは、
アクアビット様のお力無くしては出来なかったことだと改めて感じています。
運用開始後もエラー発生時の迅速な対応や、改善するために多くのサポート頂き、絶大な安心感を持って日々の運用が出来ていることにも本当に感謝しています。
引き続きどうぞよろしくお願いします。」

フラン様のご紹介

商号 株式会社フラン
本社 〒488-0044 愛知県尾張旭市南本地ヶ原町3-110
TEL 0561-54-6813
代表者 代表取締役 奥村 聡
設立 1981年1月23日
資本金 1000万円
ウェブサイト https://fran-de-lingerie.com/

アクアビット航海記 vol.45〜航海記 その29


あらためまして、合同会社アクアビットの長井です。
弊社の起業までの航海記を書いていきます。以下の文は2018/5/13にアップした当時の文章が喪われたので、一部を修正しています。
今回は新たな会社でシステムを独学で習得しまくる話です。この時の経験が私を起業に導いてくれました。

オフィス移転で恥をかく


新しい会社の日々は、とても刺激的でした。

まず、私が入社してすぐに社屋の引っ越しがありました。新しい五階建てのビル。すべてが空っぽです。なにもありません。ネットワークどころか電源の場所も考慮されていません。全ては私に任されており、完全に白紙でした。そこでまずレイアウトを検討し、電源やネットワークの位置を設計しました。入社して早々、各部署の方と話を進めながら。

ファシリティ設計もネットワーク設計や電源設計も、当時の私にとって全てが初めての体験てした。やったことがなくてもやらねばなりません。やるのです。結果が良ければ全てがよし。ぶっつけ本番。あたって砕けろ。すると、なんとかなってしまうのではないか。

もちろん、何もなく終わるはずはありません。いくらVisioで図面を書いてみたところで、いざ本番となれば想定外の出来事が起こります。そもそも設計はあくまで机上の計画に過ぎません。物が実際に設置された時、計画とずれるのは当然のことなのです。そもそも私自身がオフィスのレイアウトやネットワーク設定など全くやったことがなく、計画はずさんだったはず。案の定、引っ越し当日は右往左往しました。

例えばモールです。モールってご存じですか?LANケーブルを保護し、しまい込むための塩ビ製の細長いカバーです。
モールは上と下に分離し、カチッとはめ込む構造になっています。ベロンと上下を分け、そこにLanケーブルをしまい込み、最後にパチリと上下をはめ込みます。ところが私はそんなこともすら知りません。
上下に閉じたままのモールのすき間に無理やりLanケーブルを押し込もうとしました。不可能を可能にする男、長井の面目躍如といいたいのですが、そもそも入るわけがありません。この時、来てもらっていた工事業者さんのあ然とした顔は今も思い出せます。
本連載の第十六回で、IMEを切り替える方法を知らなかった私が、半角カタカナでデータを打ち込み「ニイタカヤマノボレじゃないんだから!」と怒られた芦屋市役所でのエピソードは書きました。この時のモールの一件は、その時に負けず劣らず恥ずかしいエピソードです。土壇場で電源の場所が変更になり、それをお願いしたい時の電気業者さんが見せた絶望と諦めの顔も思い出せます。

自分に恥をかきまくって成長する


結局、私の二十代とはそういう恥ずかしい記憶の集まりです。でも今から思うと、恥をかいては捨ててきた積み重ねが私の成長につながっています。全ては血となり肉となりました。
もちろん、成長のやりかたは人によってそれぞれです。一つ一つの作業を丁寧にOJTで教わりながら恥をかかずに成長していく人もいるでしょう。ただし、それはあらかじめ決められたカリキュラムに沿っています。カリキュラムとは、習得の到達度を考慮して設計します。ということはカリキュラムに乗っかっているだけでは、成長の上限もあらかじめ決められています。

私の場合、乗っかっているカリキュラムからはみ出し、一人で突っ走ってばかりでした。そして失敗を繰り返していました。でも、それもよいのではないでしょうか。カリキュラムからはみ出た時、人は急激に成長できるような気がします。少なくとも、この頃の私はそうでした。
私の人生で何が誇れるかって、ほとんどの技術を独学で学び、恥をかきまくってきたことだと思っています。

私にとってこちらの会社で学んだ事はとても大きな財産となりました。情報技術のかなりを独学で習得しました。そして自分に対して恥をかき続けました。
私がかいた恥のほとんどは自分に対しての恥でした。というのも、この会社に私より情報技術スキルを持つ方はいなかったからです。つまり、自分自身がかいた恥は誰にも気づかれず、誰からも指摘されず、ほとんどが私の中で修正され、処理されていきました。その都度、自分の乏しい知識をなげきながら。

でも、そうやって自分の未熟さに毎日赤面しながら、私は会社の情報処理、ファシリティや機器管理やパソコン管理、ネットワーク管理の知識を着々と蓄えていきました。
自らが知らないことを学び、自分の無知に恥をかき続ける。今でもそうです。自分が知っていて安心できる知識の中でのみ仕事をすれば失敗はないでしょう。そのかわり成長は鈍いはずです。失敗の数もまた人生の妙味だと思います。

恥をかきすぎたら成長できた


入社した当初は、私を試そうと圧力をかける方がいました。が、徐々に難癖を付ける方は何も言わなくなりました。やがて私は自分の思うがままに環境を作れる立場になっていました。
もちろん職権の乱用はしません。自分の判断でこの機能が必要と判断し、稟議書を書き、上長に上げます。そのうちの九割方は決裁してもらえたように思います。会社には何社もシステムベンダーの方に来ていただきました。臆せずに自分で展示会にも出かけていき、知見を広げました。

時期は忘れてしまいましたが、自分でサーバーを構築したのもこの時期です。DELLのサーバーを購入してもらい、そこにRed Hat Linuxをインストールしました。さらに自分でSamba(オープンソースのファイルサーバー)を入れました。全ては白紙からの挑戦でした。

そのサーバーには後日、Apache(ウェブサーバー)やMySql(データベース)やPHP(プログラム言語)も自力でインストールしました。そうして自分なりの社内イントラネットを構築していきました。

私が入社した当初、その会社の販売管理はオービック社の商蔵奉行が担っていました。受発注や伝票発行の全てをそれでまかなっていました。そもそも私がこの会社に呼ばれたのも、システムのオペレーションミスによる誤請求があったためです。そこでFAXをOCR変換して取り込む仕組みも作りました。EDIも何パターンか導入しました。夜間バッチでデータを自動で取得し、受注データへ変換する仕組みも構築しました。
その過程で私は社内の受発注の仕組みから勉強し、システムが備えている販売管理に関する機能の理解も深めました。販売管理を行う際は、在庫管理も欠かせません。その二つは表裏一体です。この会社は自社の倉庫も持っていました。となると在庫管理から物流の知識に至るまでの知識も修めなければ。

それらの新たな知識の習得と並行して、社内の全パソコンは私が管理していました。入社までの半年、土曜日に訪問して全パソコンのメンテナンスを行っていたことは書きました。新社屋に移る際、ネットワークや電源の構成やレイアウトも把握しました。そうした日々の中、パソコンのメンテナンス・スキルも身に付き、ネットワーク構築やサーバー設計にも経験を重ねていきます。遅いノートパソコンのメモリ増設ぐらいなら行えるぐらいまでに。

この時期の私がどれだけ充実していたか。今の私からはまぶしく思えるほどです。好きなだけ学び、存分に成長していました。しかもそれが会社の効率の改善につながっていました。とてもやりがいに溢れた時期でした。そして幸せでした。
学べること。成長できること。その成長を自分で実感でき、さらに人に対して目に見える形で貢献できること。

少し前の私は、こうした一連の仕組みを全くしりませんでした。結婚した翌年あたりに友人たちが私の家に来て、自作パソコンを組み立ててくれたことがあります。この時に来てくれたのは、大学の政治学研究部の後輩とスカパー・カスタマーセンターのオペレーターさんと義弟でした。珍しい組み合わせ。そして皆が私より年下。
それなのに、私は彼らがやってくれている作業のほとんどが理解できませんでした。
そんな私が今や、新たな会社で情報統括を行う立場となりました。少し前まではニイタカヤマノボレと怒られていた私が。モールの構造を知らずに無理やり押し込もうとした私が。

これが人生の面白さだと思います。

ただし、私の人生には大きな試練がまだ続きます。
その試練とは家の処分。本連載の第三十七回第三十八回三十九回にも書いた家の処分です。
私が転職した大きな理由の一つは、そもそもこの家を処分するためでした。
次回は家の処分を二回にわたって書いてみます。ゆるく長くお願いします。