株式会社デザインフィル様 導入事例

デザインを通じて生活を楽しくするデザインカンパニーを掲げる株式会社デザインフィル（以下、デザイフィル）。ステーショナリーを中心としたプロダクトの企画開発、製造販売やライフスタイル提案などを行っており、日記や便箋などの紙製品や機能文具を提供する「ミドリ」のほか、システム手帳の「KNOX（ノックス）」、革製カバーのノートなどの「トラベラーズカンパニー」といったブランドで、生活を彩っている。さらにOEM／ODMなどで企業のPR商品や販売品をプロデュースするコマーシャルデザイン事業にも取り組む。企業や美術館などのオリジナルのクリアファイルや付箋紙、クリップといったノベルティ、グッズなども、同社が手掛けたものは少なくない。

ミドリの文具が主要製品だった時代を経て、2007年にデザインフィルへと社名を変更する前後から事業は変革している。製品分野やブランドが増えただけでなく、卸売主体のビジネスから小売やEC、海外への輸出など販売方式も多様化が進んだ。デザインフィル 管理本部ICT部 マネージャーの今村貴明氏は、「基幹システムは20年ほど使い続けてきましたが、Internet Explorerでしか動かないといった課題がありました。その上、製品や販売経路、協力会社の国際化などのビジネス環境の変化に対して、機能の不足も明らかになっていました。そこで2022年頃から基幹システムのリプレースのプロジェクトが動き出しました」と語る。

生産管理改革を視野に、新しい基幹システムを選定

基幹システムの刷新では、RFPを複数のベンダーに提示して、提案を求めた。ほとんどのベンダーは、既存の基幹システムの置き換えという正攻法の提案をしてきた。その中で1社だけ、既存のシステムを捨てて生産機能を刷新する提案をしてきたベンダーがあった。製造業向け基幹業務システム の「STRAMMIC」を提供する株式会社アミック（以下、アミック）だった。

最終コンペの後で、プロジェクトのメンバーは全員がSTRAMMICに手を挙げるという一致した意見の下、導入を進めることになった。

AWS移行で問われたデータベースの可用性確保

デザインフィルは、STRAMMICを構築するプラットフォームとして、機能やコストを精査してAWSを選んだ。ただしAWSの利用は同社として初めての経験であり、漠然とした不安はあった。その1つが、当たり前のものとして考えていたデータベースの可用性の問題だった。基幹システムとして、業務を止めない仕組みを構築する必要があると考えていた。

アミックからの提案では、STRAMMICが採用するデータベース、SQL Serverの可用性を保つために、サイオステクノロジーの高可用性クラスターソフト「LifeKeeper」が含まれていた。提案を受けた当時、今村氏は「データレプリケーションソフトのDataKeeperの知識しかなく、LifeKeeperというツールがあるのだという印象でした。アミックからは、LifeKeeperにこだわる必要はないと話をもらっていたので、複数方式で検討を始めました」と語る。

最初に検討したのが、AWSがマネージドサービスとして提供するAmazon RDS（Amazon Relational Database Service）の利用だった。しかしRDSではSQLサーバーの照合順序が対応していなかったことなどの制約から採用を見送った。

次に検討したのが、AWSにSQL Server Always On 可用性グループクラスターを作成する方法だった。しかし、AWSのSQL Server Standard Editionではデータベースが1つしか利用できない。一方、デザインフィルの求める機能を実現するためには複数のSQL Serverが必要だった。「すると、SQL Server Enterprise Editionが必要になり、コストが大幅に高くなります。そこで当初提案にあったLifeKeeperと比較したところ、機能面では差異がなく、コスト的には圧倒的にLifeKeeperにメリットがあることがわかりました。アミックからの勧めもあり、LifeKeeperを選択することにしました」（今村氏）。

【システム全体構成イメージ図】

【AWSにおける構成イメージ図】

AWS×LifeKeeper構築を支えたインテグレーターの知見

STRAMMICをAWS上に構築し、LifeKeeperで可用性を担保する新基幹システムは、システムインテグレーションを手掛けるエスエイティーティー株式会社（以下、SATT）が担当した。「製造業の生産管理システムに強みを持つアミックと、AWSやLifeKeeperの構築経験が豊富なSATTの知見を合わせて、スムーズに構築は進みました。LifeKeeperについてもSATT側でマニュアルをしっかり用意してくれたほか、疑問にわかりやすく回答してくれたことから安心して実装できました」（今村氏）。

SQL Serverの構成は、アミックの提案を受ける形でAWSのインフラ単位であるAZ（Availability Zone）をまたいで構築することにした。「AZ間のサーバーに対して、LifeKeeperが疎通できるようにセキュリティグループのDNSの名前解決のための設定が必要になるといったことを学ばせてもらいました」と今村氏が語るように、SATTが持つAWSとLifeKeeperの知見を生かしながら実装を進めていった。インフラとしてはトラブルもなく2023年初頭に構築が終わり、アプリケーションの実装のステップに進んだ。

STRAMMICの本番稼働は、2025年5月に決まった。それまでの間、インフラ側にとっては検証期間が多く取れることになった。ここで、不幸中の幸いと言える状況が訪れた。加藤氏は、「早くインフラの構築ができたことで、本番稼働前にAWSが実際にAZ障害を起こして、LifeKeeperの動作を確認できました」と語る。

障害は2回起きた。1回はAZ障害で、LifeKeeperが自動的にスタンバイ側のサーバーに切り替える事象を確認できた。「AZが復旧したので戻してみようといった手順を実際に確認できました。仕様書通りに動き、切り替わる安心感を得られました」（今村氏）。もう1回は、AWSのRoute53と呼ぶDNSサーバーのアクセスポートに障害が起きたときのこと。DNSによる名前解決ができないため、LifeKeeper自体が動かない状況に陥った。今村氏は、「DNS障害を本番稼働前に安全に経験できたことで運用知識が蓄積されました。LifeKeeperに頼れない事象があるという線引きが事前にわかったことは、ありがたい経験でした」という。

加藤氏はこうした経験を踏まえて、「AWSのようなクラウドサービスに100％の安定を求めてはいけないことを実感しました。一方で、AWSの障害が丸一日以上続くことは非常に稀だと感じています。アナログに業務の手戻しをする手順を構築して訓練するくらいならば、復旧を待てばいいという考え方の整理ができました」と語る。

本番稼働後は安定運用、次はAI活用フェーズへ

2025年5月の本番稼働以降は、検証期間中のようなAWS障害は起きていない。「幸いなことに、LifeKeeperによる切り替えが発動するような障害は起きていません。それでも検証期間に偶然の障害で切り替えが起こったことで、きちんとLifeKeeperが動作することがわかっているため、大きな安心感があります」（今村氏）。

5月のSTRAMMIC本番稼働の後、カットオーバーまでに対処できなかった課題や、稼働後に見えてきた課題について、アプリケーション側で対処する導入第2フェーズに入った。LifeKeeperの導入でインフラに不安を持たずにアプリケーションに注力できる状況が、次のフェーズへの後押しになっている。さらに、「データベースに蓄積されていくデータを、どう活用していくかという次のフェーズについても検討を始めています。Google Workspaceを採用していることから、生成AIのGeminiを使って製品の仕様と製造法の関係の洞察を得たり、需要予測をしたりといった活用を考えています」（加藤氏）。

今後の新しい業務システムは、クラウドサービスを中心に展開するというデザインフィル。基幹システムにおいてはデータをLifeKeeperで守る体制を作りながら、さらに新しいデータの活用やツールの利用についても目を向ける。「インプットがあって新しいアウトプットが生まれます。日々の業務管理だけでなく、新しいアウトプットに向けてもデータの安全性が担保されるインフラが構築できたことに価値があると感じています」と、加藤氏は語る。日々の業務データを新しい価値創出につなげるためにも、その基盤を支えるLifeKeeperの重要性を実感しているようだ。

導入事例PDF版はこちら

関連ユースケースのご案内

本事例に関連したユースケースを、以下の「ユースケースを見る」からご覧いただけます。

STRAMMICのユースケースを見る