足つぼマッサージ店が業務システムを外販?！ グローバル化による新たなビジネス展開

ソフトウェアグローバリゼーション入門 国際化I18Nと地域化L10Nによる多言語対応

Globalization(G11N)の基本から具体的な手法やツールまで基礎的な知識を集約！

この記事は、書籍『ソフトウェアグローバリゼーション入門 国際化I18Nと地域化L10Nによる多言語対応』の内容を、Think IT向けに特別にオンラインで公開しています。詳しくは記事末尾の書籍紹介欄をご覧ください。

取材協力：株式会社ドクターフット　鈴木 雅喜氏、株式会社オイアクス　黒田 努氏

特定の企業内で利用される「業務システム」は、外部向けに公開されるWebサービスやアプリに比べて、ユーザー数や対応端末は限定されます。ただしその使い勝手は業務成果に直結するため、効率化を求める声は常に大きくなります。今回紹介する店舗予約／顧客管理システムもその最たる例です。少し状況が異なるのは、自社の使い勝手"だけ"に注力するのではなく汎用性とカスタマイズ性を重視した点にあります。リフレクソロジーサロンを運営するドクターフットの鈴木氏と、システム開発を担当したオイアクスの黒田氏の両名に、グローバル化に向けた開発を進めている同社業務システムの狙いを聞きました。

鈴木：株式会社ドクターフットは創業23年目、都内にフットマッサージサロン5店舗とオーダーシューズ専門店2店舗を運営しています。

黒田：いま開発を進めているのが、ドクターフットの各店舗の予約と顧客管理のシステムです。会計機能も含んでいます。既存のシステムは2000年台初頭にPerlで作られたもので、10年以上運用してきましたが、これをリニューアルしようとしています*1。

鈴木：リニューアルは5年くらい前から考えていました。もともと顧客管理は紙ベースから始まったのですが、多店舗展開をしていく中でコンピューター管理に切り替えたのが最初のPerlのシステムです。ただ、時代が変わってタブレット端末が主流になり、より速くよりきれいに使いやすく、使い勝手を重視したものに作り変えたかったのです。

リニューアル要件におけるグローバル化の重要度は60％

鈴木：私が台湾に長く住んでいた*2こともあり、良いシステムができたのであれば日本だけに留まらず、中国やアメリカでも使えたらより良いのではないかという思いがあって、多言語対応を念頭に開発を進めてもらいました。

ドクターフットの鈴木氏

黒田：現状でも店舗には外国人のお客さんもいらっしゃいますし、東京オリンピックも控えているので、英語対応は必要ですね。中韓からの観光客も多い。また、スタッフも今後は日本語以外がメインの人が増えていく可能性もあります。

鈴木：グローバル化にあたって、直近ではドクターフットの海外展開の予定はありませんが、同業他社や他業種でも同じように店舗運営をする人たちに対して我々が開発したシステムを貸し出したり、カスタマイズして使用料をいただくようなモデルを考えています。また、例えば予約画面から商品購入などに結びつけそこから利益を出すような方法もあると思っています。

もちろん世の中には似たようなシステムは存在します。ただ、たくさんあるなかで調べてみましたがどれも使い勝手が今ひとつだったため、市販製品ではなく自社開発の道を選びました。もともとは自店舗向けに国内の多言語ユーザー*3が使えることが前提だったシステムですが、それを海外に持っていけるのが理想的だと思っています。

黒田：旅館・ホテル業でも同じように、同業者向けのシステムを横展開している話を聞いたことがあります。今回のシステムを使って海外展開を目指すパートナーが出てくるかもしれません。

鈴木：先日、台湾に行ったときに友人にこのシステムを紹介したのですが、非常に興味を示してぜひ使いたいと言ってくれました。今回のリニューアルにおけるグローバル化のモチベーションは、開発全体の6割くらいを占めています。海外展開のビジネスも踏まえて考えていたため、しっかりとカスタマイズできるものが必要だと判断したのです。

文脈がわからないと翻訳はできない

黒田：機能については具体的な画面を見ていただくのが早いと思います。ドクターフットではお客さん（実際に店舗を利用するエンドユーザー）は30分単位で予約できるのですが、管理画面では15分ごとコマが分かれています。ここでスタッフのスキルなどに応じて細かくシフトを調整できるようになっています*4。汎用のシステムでここまで作り込むのは難しいので、マッサージ店ならではの制約に対応して開発しました。

開発中の予約管理画面（左：日本語、右：英語）

国際化について、現状は日本語と英語の切り替えができます。タブレットを前提に設計しているためスペースが限られ、文字の切り替えによるUIの調整が難しかったです。例えば「顧客」を「Customers」に切り替えると、文字があふれてしまいますよね。ボタンの文字列を可変長にすることもできますが、デザインに影響するためここではラベルを「Cust」に省略することで対応しました。タブレット・サイズをターゲットにした場合、文字数はギリギリまで削っていったほうが良いと思います。泥臭く細かく調整して行く必要があります。

鈴木：ネイティブの人は英語を略して使うのでフルスペルで記述することはあまりありません。また、例えば日本人はクレジットカードですが海外では"Charge"一言、Youは"U"一文字で済ませるなどの違いもあります。どういったラベルで表現するかは現場で調整する必要があります。

黒田：英語は社内で翻訳していますが、ラベルについては他のサイトを調べるなどして、一般的にどんな略語を使うのが良いのかをかなり調査しながら開発している状態です。単純な翻訳では処理できない部分ですね。「足もみ」という単語の場合は、英語に切り替えるときにどういったラベルを付けるのかは非常に悩ましいところです（"f-mas"など）。場合によっては開発側ではラベルまでは提供せず、ユーザーに翻訳を入れてもらうことを想定しています。最後は知り合いのネイテイブの人にチェックしてもらうなどして、伝わるものからナチュラルなものに切り替えていきます。

ただ、文脈がわからないと翻訳は難しく、外部に依頼してしまうとそこで分断してしまうこともあります。別件でAPIドキュメントを英語化するときにクラウドソーシングを活用したことがあります。翻訳の質は良かったのですが、開発側のニュアンスを伝えるのに苦労しました。ソフトウェアの専門家でないとピッタリと英語はこないです。内製化とはちょっと異なるのですが、（身近な）知人や家族に頼むというのも現実的な解ではあります。

鈴木：英語の他には、私が中国に住んでいたことや現地に（ビジネスに繋がるような）知り合いがたくさんいることもあり中国語対応は必須だと考えています。市場的には、その次はスペイン語やフランス語になるでしょうか、話者数が多いですから。

黒田：優先順位としてはひとまず日本語と英語を用意しておいて、必要になったらオンデマンドに翻訳データを用意すれば良いのではないでしょうか。業務システムということもあり、アラビア語のような特殊なものがない限りすべて完璧でなくともいったん英語になっていればだいたい使えるといった見込みもあります。ただし、3ヶ国語以上になったときも使えるように予め準備は必要です、ここは初めに設計した部分でもあります。

鈴木：でも中国語はすぐにやりたいですね（笑）。

開発はアジャイル風に。実装にはRailsとVue.jsを活用

黒田：今は原則として1週間のイテレーションでアジャイル開発的なプロセス（要件、設計、実装、テスト）を繰り返しています。面談による打ち合わせを毎週行い、その中で完了させたい課題をリストアップし、次のイテレーションに進むというイメージです。要件と設計と実装がほぼ同時進行、テストはクライアント（ドクターフット）に受け入れをしてもらっています。教科書通りではないですがアジャイルを意識して、鈴木社長とは2週間、システムの実担当者とは1週間に1回打ち合わせを実施し、その都度要望を聞いて開発を進めている状況です。

オイアクスの黒田氏

グローバル化への対応は一手間増えるので開発はやや煩雑になります。日本語だけに限ればコード内で直書きできる部分もタグを埋め込むなど処理する必要がありますから。エンジニアによってはI18Nの設計を後回しにしてしまうケースもあります、Ruby on Rails（以降、Rails）ではテスト環境ですべてのkeyが一致しているかなどを予めチェックする必要があるため、テストを通すために仮の翻訳データを入れておくといった回避策をしてしまいがちです。

グローバリゼーションに関して専用のフレームワークは特に使用していません。サーバーサイドではRailsの標準のI18N機構を使っていて、対訳のデータの有無をチェックするのにRSpecのプラグインを自作しました。フロントエンド開発にはVue.jsを採用し、I18Nプラグイン*5を使って、コンポーネントの中に翻訳データを格納できるようにしています。Vue.jsはReactやAngularなどと比較して選択肢しました。本格的に使うのは初めてだったのですが、開発はここまで概ね順調に進んでいます。

翻訳メモリーのようなツールも特に使っていません、訳語はymlファイルで管理しています。予めマッサージ業界に関する用語を事前に勉強しておいたのですが、その英語の用語集までは準備していませんでした。そのため、プログラマーによる訳語のゆらぎなどが出てしまっている部分は最後にチェックして直す必要があります、ここはあまりシステマティックではないですね。翻訳会社へアウトソースすることできちんと管理する方法もありますが、文脈がわからないと訳語自体がおかしくなってしまうもあり、一長一短な部分になってきます。

翻訳データの分断、天候や祝日、税率対応など課題は多い

黒田：今後予見される課題としては翻訳漏れが挙げられます。翻訳をやりながらだとどうしても開発が遅れてしまうのでまずは日本語として使えるものを目指して後回しにしてしまいました。また、業務アプリケーションということもあり翻訳量はそこまで多くありませんが、サーバーサイド（Rails）とクライアントサイド（Vue.js）の翻訳データが別れてしまうのは問題に感じています。今後はクライアント側のデータを削除し、サーバーサイドから翻訳データをAjaxで処理することも検討しています。

機能面では、例えば天気予報への対応をグローバルで提供しようとすると、国際化は難点になってきます。各国で天候の定義が異なってきますし日本ほど明確ではないからです、これまで意識してこなかった部分ですが今後問題なる可能性はあります。

鈴木：店舗運営をするうえでは天候データは非常に重要ですし、それを運営に活かせれば仕掛けていくことができます。例えば台風のときは一般的に客足が止まるのですが、割引クーポンをメールで配信したら予約がいっぱい埋まったという経験があります。

黒田：他に、インターフェースを作る上での問題として時刻や気温の表示なども各国の表記に従う必要があります。また、タイムゾーンや祝日対応、税率対応など考えればきりがないのですが、都度対応していくことになると思います。ウォーターフォール型はそれはそれで辛いものがあるので、頭のなかにあるものをアウトプットしてすぐフィードバックを得られる、今の開発体制はやりがいがあって、楽しく開発ができています。クライアント側（ドクターフット）も進んでいく過程がみえるのは大きいと思います。

現場のフィードバックをすぐに反映できる開発体制

グローバル化はすでにソフトウェア開発の大前提

黒田：皆さんグローバル化についてハードルを高く考え過ぎている気がします、もちろん細かな問題は直面しますが一つ一つはそこまでは難しくはないです。全部をやろうとすると大変ですが、メニューの変更だけでも十分な国際化です。グローバル化されていないのはむしろ今の時代ではおかしいので、対応をはじめてみてはどうでしょうか。Railsのようにモダンなフレームワークであればすでに基盤ができています、難しく考えないで挑戦してみるのがいいと思います。

鈴木：経営的には、（言語に関する制約がなくなることで）人件費削減に繋がりますし、間違いが起きにくくなる。海外ではこういったシステムがないので使っていただけるのであれば良いことだと思いますし、今後はそういったビジネスを伸ばしていきたいです。スマホやタブレットから予約ができるほうが絶対に便利だし、言語の選択ができただけでも印象が違ってきます。歓迎されている気がしますね。次のステップではスマホアプリなどでも多言語展開を仕掛けていきたいと考えています。あとは良い開発会社に出会うことも重要ですね。

この記事のもとになった書籍
西野 竜太郎 著 価格：2,400円＋税 発売日：2017年10月16日発売 ISBN：978-4-295-00255-0 発行：インプレス	ソフトウェアグローバリゼーション入門 国際化I18Nと地域化L10Nによる多言語対応 Webアプリケーションやスマートフォンが広く使われる現在、世界中で使われるソフトウェアを開発・配布するための障壁は薄まりつつあります。しかし、多くの人たちに使ってもらうには、さまざまな言語や文化に対応した、グローバルなソフトウェアを開発しなければなりません。本書はソフトウェア開発におけるグローバリゼーション(Globalization, G11N)をテーマにしています。その概要と開発プロセスについて触れた後、二つの大きな分類である国際化(I18N)と地域化(L10N)について、それぞれ詳しく解説しています。