たった2名のメンバーで上流工程を指揮、ベンダとの強力なタッグが成功を後押し - (page 2)

小林 正宗(月刊ソリューションIT編集部)

2005-06-15 17:17

調理マニュアルを
ストリーミングで配信可能に

 2003年10月のプログラミングフェーズ以降は、応援としてガストやバーミヤンにいた情報システム担当3名を召集した。2004年1月からは試作システムを稼働させてテストを重ね、同6月には一部店舗へ実験的に投入した。同9月から全国の店舗への導入を開始し、12月にすべてをカットオーバーした。

 完成したシステムの全体像は図2のとおりだ。センターDBには、サン・マイクロシステムズの「Sun Fire6800」サーバーと、Oracle9iを採用。本部と店舗を結ぶネットワークには、NTT東西の「Bフレッツ」を利用している。同システムの導入で、以下の6つの機能が利用できるようになった。

図2 センターDBシステムのネットワーク構成

  1. QUOカード
  2.  レストランやガソリンスタンド、コンビニエンスストアで利用できるプリペイドカード「QUOカード」を、POSシステムの刷新に併せて導入した。

  3. IP電話
  4.  すかいらーくの本部や工場などは、店舗との通話が大半で、その他への外線電話はほとんどなかった。そこで、本部や店舗、工場を結ぶIP網を構築し、内線化することで、通信費を従来比12%下げた(図3参照)。

    図3 IP電話導入のメリット

  5. Web給与明細
  6.  これまでは、本部のホストコンピュータにある約10万人分の給与データを印刷し、封入した上で社内便で各店舗に配布していた。これを廃止し、従業員がWebブラウザから給与明細を確認できるようにした。ペーパレス化と輸送費の削減によるコストダウンが実現した。

  7. 印紙税申告納付
  8.  3万円以上の飲食について、本部のサーバーが自動的に集計するようにした。これにより店舗は、事前に印紙を買う必要がなくなった上、張り忘れ等のオペレーションミスを減らせるようになった。

  9. 双方向文書
  10.  従来は、本部から店舗へ電子文書を送付できたが、それを返信する機能がなかった。そのため、各申請書やアンケート用紙をいったん紙に印刷して記入し、FAXで本部に送り返していた。これを、ストア・コントローラー(ストコン:用語解説参照)の帳票に直接入力できる仕組みにした(図4参照)。

    図4 双方向文書の仕組み

     店舗が記入済みの電子帳票を本部宛に送信すると、用紙の種類別に当該部署に自動振分される。

  11. 動画配信
  12.  新メニューの発売時に、調理スタッフは火加減や色合い、調理手順などを詳しく見る必要がある。そのため、紙で調理マニュアルに加えて、一部ISDN経由で動画配信していた。だが、動画配信にまつわる全体の通信費が、月額数百万円にも及ぶ問題があった。

     Bフレッツの導入により、調理マニュアルをストリーミングで配信できるようシステムを改変。従業員向けの教育ビデオや経営層のメッセージ等も動画で配信できるようになった(図5参照)。今のところバーミヤンでの利用に留まっているが、近く全店舗で利用できる見込みだ。

    図5 光回線による動画配信

  13. ルームサービスの統合
  14.  また、従来はガスト等で利用している宅配サービス「ルームサービス」の提供に際し、ISDNによるデータ通信を利用していた。これを店舗のBフレッツで吸収し、通信コストを大幅に下げた。

テストを実行しても 想定しない問題が残る

 プロジェクトを通して、大きな混乱はなかった。だが三瓶氏は完成したシステムを「70点」と厳しく評価する。その理由は、以下の3点で不満があるからだ。

  1. ハードの性能差:アプリケーションのみを交換したAP改造店舗は、ハードを含めて交換した店舗に比べて性能が劣ってしまった。CPUの性能は、それぞれ128ビットと256ビットで大きな違いはないが、エンドユーザーの体感レスポンスタイムは7〜8秒異なる。特にバーミヤンではレスポンスが遅くなってしまった。
  2. 同時アクセスによるレスポンスの遅延:センターDBに、3000店舗から一斉にアクセスがあると、食材などを発注するストア・コントローラーのレスポンスが落ちてしまう。ひどい時には、システム自体がダウンしたこともあった。
  3. バックアップのホットスタンバイ:DBアクセスが集中すると、バックアップシステムがすぐに立ち上がる仕組みにしていた。だが当初、それが5〜6時間立ち上がらないことがあった。

 これらの問題は、業務に与えるインパクトが大きい。たとえば、工場に材料などを発注する深夜にシステムがダウンした場合、店舗の翌日の営業に差し支えるからだ。

 一見、テストツールなどを使ってきちんと負荷テストを実施することで回避できるかに見えるが、三瓶氏はそれを否定する。「3000店舗以上の負荷をかけたテストはしていますが、それでも想定できなかった負荷がかかることがあります。本番稼働しないと分からない問題も多々あります」と話す。

 これらの問題に対し、まずレスポンスが遅いハードを交換。センターDBを月に一度メンテナンスして、データ容量を2テラバイト程度にまで落とし込んだ。これらの改善活動により、バックアップの立ち上げ時間は15分にまで短縮。ストア・コントローラーのレスポンスも大幅に向上したと言う。2005年6月までには、これらすべての問題を解決できる見込みも立った。

 三瓶氏は、これらのシステムを基盤とした、次期システムに目を向け始めた。DBに貯まったデータを活用し、リアルタイムSCMシステムや分析系システムなどの構築を視野に入れている。すかいらーくのIT戦略は、これからが本番だといえる。

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ホワイトペーパー

新着

ランキング

  1. セキュリティ

    「デジタル・フォレンジック」から始まるセキュリティ災禍論--活用したいIT業界の防災マニュアル

  2. 運用管理

    「無線LANがつながらない」という問い合わせにAIで対応、トラブル解決の切り札とは

  3. 運用管理

    Oracle DatabaseのAzure移行時におけるポイント、移行前に確認しておきたい障害対策

  4. 運用管理

    Google Chrome ブラウザ がセキュリティを強化、ゼロトラスト移行で高まるブラウザの重要性

  5. ビジネスアプリケーション

    技術進化でさらに発展するデータサイエンス/アナリティクス、最新の6大トレンドを解説

ZDNET Japan クイックポール

自社にとって最大のセキュリティ脅威は何ですか

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]