Author Archives: ギガ・システム

第2回:釣りサークル活動報告

昨年に続き、第2回太刀魚釣り(淡路島沖)を開催しました。

淡路島ICに集合し、全員で早めの昼食。

気合・意気込み・希望を語りつつ、いざ、釣りへ。

今年度は、昼からの出船という事もあり釣果も心配でしたが、
メンバー全員が釣りあげ、
仕事の疲れも忘れ満面の笑みで、
半日釣りを楽しみました。

また、今年度から新たなメンバーも増え、
ますます釣りサークルは、
盛り上がってます。




Posted in お知らせ |

【先輩社員の声】Pさん(3年目)

■自己紹介 / Introduction
こんにちは!開発者として3年目のオーストラリア人です。
Australian software developer here, in my third year of working for Giga System.

 ● 日本滞在5年目
 ● 中国系オーストラリア人
 ● 旅行業界から IT 業界へ
  ○ 2年間の社会人経験あり
 ● ハローワークをきっかけに、ギガ・システムに入社
 ● ほぼ未経験
 ● 2021年6月入社

 ● 5th year of working in Japan
 ● Chinese Australia background
 ● Changed career from Tourism to IT
  ○ 2 years working experience
 ● Found Giga System via HelloWork (MHLW)
 ● Minimal experience in IT industry
 ● Joined from June 2021

■現在の業務 / Current responsibilities
1. Android/iOS (Flutter) アプリの開発、保守
2. Web システム(Laravel, Java)の開発、保守
3. 新人社員と後輩社員のフォロー
4. 社内ライブラリの作成

1. Android/iOS (Flutter) application development, maintenance
2. Web system (Laravel, Java) application development, maintenance
3. Supporting new and junior employees
4. In-house library development

■一日の流れ / Schedule

① 09:00:勤務開始、新人フォロー、メール確認
② 09:30:プログラミング、プロジェクト内ミーティング
③ 12:00:昼休憩
④ 12:45:クライアント定例ミーティング
⑤ 13:45:プログラミング、テスト
⑥ 17:45:退勤、プライベート

① 09:00:Start workday, follow-up on new/junior employees, check email etc
② 09:30:Development, project meeting
③ 12:00:Lunch break
④ 12:45:Client meeting
⑤ 13:45:Development, testing
⑥ 17:45:End workday

■ギガ・システムの良い点 / What I like about Giga System
私は、ギガ・システムで最初の Global 人材として採用されました。
他業種から転職、未経験且つ外国籍の私を採用し、社内研修にて教育して頂いたギガ・システムは、
挑戦的で前向きな姿勢と感じました。
日々、先輩・上司が、丁寧に指導してくださり、様々な知識を身につけることができます。
チームに配属後は、メンバー間で協力し合い、開発案件を対応していく中で、
作業内容が不安な時に相談できる仲間がいることに大変助かりました。
とても風通しが良いと思っております。
同僚や上司とは、気軽に相談ができる関係になり、
普段のコミュニケーションの中から私の思いを理解してくれていると感じています。

Opportunity for a career change, and options within Giga System are provided.
Training/education in Japanese is provided by an active teacher, which greatly improved my programming knowledge. Senior members will actively assist and provide guidance in all fields, which allows for easy transition into new projects.
Colleagues and management who are easy to socialise with greatly improved the experience at Giga System.

■ギガでの挑戦 / Current challenges
日本語は話せますが、ネイティブレベルではないので、
コミュニケーションをとることは時に難しいことがあります。
仕事上、 伝達ミスが発生しないように細心の注意をはらっています。
日々のミーティングやチャットツールを通した連絡事項については、
まずは相手に正確に内容が伝わるように気をつけています。
また、チーム内の同僚も、私の伝えたいことや仕事の進捗状況について常に気にかけてくれており、
とても有り難く思っています。

Communication is the biggest obstacle when it comes to working in a Japanese team environment. Sometimes, source code/algorithm becomes the only common language in solving problems. Luckily I have great colleagues who look out for each other.

■今後のビジョン / Future vision
主にアプリケーション開発と Web System 開発のプログラミングレベルを向上していきたいと思います。
合わせて、クラウド開発もできるように新たな資格を取得していきます。
将来、グローバルに活躍できるよう複数言語開発チームを作りたい。

I aim to reach a full stack developer level in experience, and back it up with certifications.
Hopefully I leave a good impression for future international developers here.

■メッセージ / Message
私が、日本で未経験の分野で働くことは、数年前には予想していないことでした!
しかし、現在は周りの人に恵まれ、エンジニアとしてギガ・システムにて充実した日々を送っています。
ギガ・システムの仕事内容にご興味のある方(特に外国籍の方)は、ぜひご連絡ください!
お会いできることを楽しみにしております。

If you are confident in Japanese communication and interested in programming, have confidence in your ability to learn and improve along with your peers and you will do great here.

Posted in スタッフから皆さんへ, 採用情報 |

業務システムの保守について

今回は契約先企業に常駐し、社内システムを保守する仕事について、お話しいたします。

社内システムを利用する利用者には様々なニーズがあります。
一般的に、そのニーズを取りまとめする担当は、社内情報システム部門となります。

情報システム部門には、多くの相談が寄せられます。
・画面に項目を増やしてほしい
・画面の操作を簡略化してほしい
・入力する文字数を増やしたい
・チェック機能を追加したい     etc…


他にも業務のやり方の変更や規定見直しによるものなど、様々な話があります。
システム保守担当者の仕事は、利用者のニーズを聞くところから始まります。
システム開発は設計・開発・テストをする事が仕事と思われがちですが、
実はその工程に入るまでにも、重要なステップをいくつも踏んでいます。
今回はその件に少し触れたいと思います。


社内システムは、部門別又は専門性のある業務に特化した機能が多く
別のシステムやデータベースと連携させている場合が多い。

利用者から見えているシステムは、氷山の一角。
実はシステムの裏側に複数の処理や制約が入っています。
場合によってはそのシステムだけでは完結しない別システムの仕様も存在します。
それらは、当然システム仕様書に記載されていますが、
利用者がそれらを理解しているわけではありません。

■要望の背景の確認
スタートは利用者の声から始まります。
利用者から「ボタンを増やして欲しい」とニーズが出てきます。
システム保守担当者は、利用者のニーズが、社内システムに対して、
理にかなっているのか、ヒアリングします。
・「ボタンを増やしたいのはなぜか」
・「それをすることで誰がどう助かるのか」
・「どうしてそんな要望を出されているのか」

すると徐々に利用者のニーズが「ボタンが欲しい」のは、
「誤操作の抑制」や「新たな業務の追加、変更」である等、
「ボタンが欲しい」本当の理由が浮き彫りになってきます。

ニーズの理由を聞き出す作業が、案件化の前準備になります。

■改修すべきかどうかの判断材料の作成
利用者の「本当の理由」を聞き出した後に進めるのは、
「改修要否の判断材料集め」になります。
現場によって様々ですが、大きく以下のポイントを押さえます。
① 改修することで得られる効果
② 改修に掛かる時間(工数)の算出
③ 上記①と②を比較した上での費用対効果の算出

少し難しい話ではありますが、
「改修することで得られる削減費用」と「改修することで発生する費用」を比較。
※削減時間と改修にかける費用が見合っているかどうかを数値化する作業。

一般的に「定量効果」と呼ばれるものですが、とにかく比較できるようにします。
これらもシステム保守担当一人では作成できませんので、
利用者やシステム開発担当と相談し、時間を確認していきます。

場合によっては今の現場の環境だけでは対応出来ず、
新たなソフトやサーバーを構築する可能性もあります。
全てを自身で算出する必要はありませんが、いかに根拠のある数字にするかが、
技術者の腕の見せ所と言ったところでしょうか。
なお、「定量効果」が少ない場合も、
数字に表せない効果(法令対応やチェック処理強化による誤記入抑制等)は、
「定性効果」といい、こちらを提示することもあります。

■現場の空き状況や納期の確認
上記の試算で効果があると見越した場合、
次に考慮すべきは納期や現場の空き状況になります。
場合によってはこちらを先に進める場合もありますが、
どれだけ効果があったとしても、それを対応できるシステム開発担当者が
居なければ対応はできません。効果が高く是非とも対応すべきとなれば、
現在進めている案件を調整して本案件を進める等、調整が必要になります。
これらも判断材料として検討した上で資料化します。

■システム保守担当者の仕事 (案件化に至るまで)
これら全ての情報を資料化して、
ようやく、判断材料を情報システム部門へ提供できる流れとなります。

情報システム部門担当者は、
私たちが準備した資料(判断材料)と、システム保守担当者の補足説明を聞きながら、
対応すべきか否かの判断を行います。
一度で終わる場合もあれば、何度も資料の修正、打合せを繰り返す場合もあります。

幾度の判断の後、システム開発が必要となり初めて、顧客ニーズが案件化しスタート
されます。

■最後に
上記はシステム開発案件に至るまでの一例です。いかがだったでしょうか?
企画提案に近い流れではありますが、システム保守担当者の仕事(一部)であり、
あまり知られていない仕事の一つです。
ここまでの間にプログラムを触ることは一切ありません。
※解析や仕様書の読込はありますが。

技術はあるに越したことはありません。
けれどそれが全てではない、そんな風に思っていただければ幸いです。

Posted in エンジニアブログ |

オンサイトという働き方

お客様先に常駐してシステム開発の要望に応える形です。
そのため様々な業務に携わることができます。

お客様が困っていることについて、

  • ・何に困っていて
  • ・どうしたいと考えられているか
  • ・何が出来れば満足されるか
  • ・どうやって実現していくか

など予算・工期・環境などのお客様内の制約の中で
様々な角度から検討・議論してシステム開発を行いリリースします。

無事にリリースされると利用者の反応を直接感じられることが多く、
仕事のやりがいを感じることができると思います。
その分トラブルなどの厳しさについても感じられることが多いため、
身が引き締まる思いをすることがあるのも事実です。

なお、様々な業務に携わることが出来るため
業務ごとの変化に対応する必要があり大変だとは思いますが、
聞いて理解し、考えを提案する楽しみがあり、対応力が鍛えられます。

また、お客様だけでなく常駐先の社員や同業他社の方など
様々な立場の人と仕事をするため、
いろいろな考え方を吸収できる機会や刺激を受けることが多く成長につながります。

特に一緒にプロジェクトに携わった方々とは苦労を共にすることから、
プロジェクトが終わった後に良い関係性が出来上がっており、
別の仕事に声をかけていただけることもあります。

ここまで書くと中々求められるスキルが高そうだと尻込みするかもしれませんが、
仕事に取り組む姿勢など結果だけではなく過程も評価していただけることから
経験の浅い若手なども成長を見越してチャレンジさせてもらえますので安心してください。

他にも魅力はいろいろとあると思いますが「オンサイト」という働き方いかがでしょうか。

Posted in エンジニアブログ |

【先輩社員の声】Nさん(研修を終えて)

■入社の決め手
もともと調理師免許を取得し飲食業界で働いていましたが、
新型コロナウイルス感染症の影響で業界に不安を感じたため、
これから益々発展していくIT業界の仕事への就職を目指し、職業訓練を受講しました。

約半年の知識だけで仕事が出来るか不安を抱きながら就職活動を行っていたところ、
研修で実際に教鞭を取られている方から研修を受けられるという事と、
代表取締役社長の山本さんがとても親しみやすく感じたので、
ここならば現在の不安を解決しつつ徐々にステップアップしながら働いていけると思い、
入社を決めました。

■研修内容
1ヶ月目 サーバ管理実技
データベース基本実技
Java基本実技
Web/Java応用実技(基本実技)
2ヶ月目 Web/Java応用実技(模擬プロジェクト)
3か月目 精算書システム製造

■ギガ・システムのいいところ
入社時点の経験値に合わせた研修制度があり、
その上現役で講師をしている方から教わる事が出来ます。
業務に入る頃には、経験と勉強を兼ねた資格取得を推奨していて、
取得した資格に対し資格援助金があるので、会社で資格取得をサポートして頂けます。
社内の雰囲気は家族的ですが、業務には堅実な取組姿勢にて取り組んでおり、
業務終了後には、定期的に若手だけでのオンラインの飲み会が開催され、
普段顔を合わせられない方とも話す機会が設けられています。
また、研修中に取り組んでいた模擬プロジェクトの製造中にて、
調べても思ったような検索結果が出てこない事も多々ありましたが、
煮詰まっている際には、すかさず先輩や上司の方々が話をきいてくださり、
疑問点を私自身で解決出来るように説明やフォローをいれて頂いております。

■今後のビジョン
まだ得意な言語もなく経験値も不足しているので、
これから業務に携わる上での知識や経験を積ませて頂きつつ、
スキルアップしていき、3年後にはPGからSEへステップアップし、
お客様には頼られるような幅広い知識をもった技術者になる事を現在の目標としています。

■メッセージ
研修中に上司や先輩には、
「聞けるうちにわからない事は、わからないとはっきり聞いて疑問解決を図ったほうがいい」と
お声がけ頂きました。
皆さん業務でお忙しい最中、疑問点を聞くことに気が引けていたので、
そう言って頂けて安心いたしました。
未経験という立場から入社したので、きちんと成長出来るか不安な気持ちでいっぱいだったのですが、
疑問解決のため、先輩方に温かいご支援をいただいているおかげで、
日々少なからず成長を感じています。
研修を終えて今は実務に入っていますが、目まぐるしく次々と新しい技術・用語が出てくるので、
日々勉強が欠かせません。
駆け出しではありますが、会社の発展のため、日々一生懸命学んで精進を重ねていく所存です。

Posted in スタッフから皆さんへ, 採用情報 |

電話自動音声案内基盤の構築

電話自動音声案内基盤の構築

〜 ヘルプデスクの問い合わせ負荷改善 〜

事例:ヘルプデスク(代表番号)にお問い合わせが集中する

undefined

 

ヘルプデスク(代表番号)の課題例

例1)「ヘルプデスク」=「困った時の問い合わせ先」というイメージが一般的で、簡単に解決できる様な内容でも問い合わせが入り、本来、問い合わせるべき内容や緊急性・重要度の高い(クリティカルな)問題の問い合わせが滞ったり、対応が遅れる場合がある。

例2)問い合わせ内容とヘルプデスク担当者のスキル(担当分野)がアンマッチで、適切な解決に導くまでに時間が掛かる場合がある。

例3)在宅勤務で、ヘルプデスク(電話設置場所)に人がいない場合、受電できない場合がある。
不在前日に電話転送の設定を実施すれば受話可能だが、(例2)の状況が発生する。
※転送先を複数割り当てられないなどの課題も残る。

例4)災害時や停電時など、物理的に受電できない場合、復旧に時間が掛かる可能性がある。

 

AWS を活用した音声案内基盤

AWS が提供している「コネクトセンター」サービスである「Amazon Connect」を利用します。
「Amazon Connect」では、AWSの電話回線契約を新規締結するか、既存回線の移管(※1)も可能です。
音声案内やコンタクトフローの作成は、Web画面上にフローを配置したり、ガイダンス内容はキーボードで入力可能です。
また、プッシュダイアルの入力にも対応可能で、入力内容を元に振り分け先の紐付けも比較的容易に作成が可能です。

※1:既存回線の移管に関しては、AWSの規定や移管元の回線業者の規約により、実施可否が異なります。

 

Amazon Connect を使用するメリット

①お問合せの切り分けに掛かるヘルプデスクのコスト(時間ロス)軽減が見込める。

②コンタクトセンターの立ち上げが短期間で実現できる。

③従来のコンタクトセンターの構築・運用に掛かるコストよりも費用を抑えられる可能性がある。

④申請すれば、同時接続数(回線数)の上限を比較的容易に変更できる。

⑤ヘルプデスクの拠点(会社)で障害・災害が発生した場合でも、問い合わせが止まらない。
転送先が拠点(会社)の場合は、Web画面上で転送先の変更が可能なため、ヘルプデスクの業務・機能が短期間で復旧できる可能性がある。

⑥すでに保有している電話番号を移管・流用することができる。(可否に条件あり)

 

Amazon Connect の課題

課題1)Amazon Connect で取得する日本国番号(+81)の電話番号は、個人では取得不可能。
電話番号の取得は、会社・団体など組織であることの証明書類を提出する必要があります。
2023年4月28日現在、個人では日本国番号を取得することはできません。

課題2)日本局番で取得できる電話番号には、下記のとおり制限がある。
・直通ダイヤル(DID)番号:
「050」プレフィックス番号
「03」東京都のプレフィックス番号(日本の他の都市の電話番号を提供していません)
・通話無料番号:
「0120」プレフィックス番号
「0800」プレフィックス番号

課題3)Amazon Connect から別回線への転送には、別途追加料金(転送通話分の追加料金)が掛かる可能性がある。
Amazon Connect 内部のユーザー間で転送した場合、追加料金は掛かりません。

課題4)Amazon Connect に移管した電話番号は、移管前の状態には戻せない。
Amazon Connect の設定で、電話番号の解除・開放(デタッチ)を実施した場合、同じ番号を自由に設定(アタッチ)できません。
※電話番号の管理がAWS側に依存するため、一度開放した電話番号は、他社に使用(アタッチ)される可能性があります。

 

Amazon Connect 導入時の注意点

既存の電話番号を移管して、Amazon Connect 環境を構築する場合は、いきなり既存の番号を移管するのではなく、AWS(Amazon Connect)が提供している「050」などの電話番号を使用し、環境構築と動作確認を実施してください。
動作確認の結果、想定通りの運用が実現可能と判断できた上で、既存の電話番号を移管する手続きに進むことをオススメします。
※(課題4)で触れたリスクを回避する意図があります。

主に活用するAWSサービス:

    • ・Amazon Connect
    • AWSが提供するクラウド環境のコネクトセンターサービスです。
      メリット:導入・運用が容易で、一般のコネクトセンターよりコスト軽減の可能性がある。
      課  題:日本局番(+81)の取得は、組織のみ可能という制約がある。(個人取得不可)
Posted in エンジニアブログ |

開発事例:コミュニケーション不足改善ツール開発

■全体構成

■概要
テレワーク環境下において、所属組織メンバーの勤務状況確認や
コミュニケーション不足を解決するDXの一環として、
MS365のTeams環境にアドオンする形でグループウェアツールを作成。
所属組織メンバーの仕事状況の確認できることや、ライトなコミュニケーション手段が主な機能。

 

■ポイント
リアルタイム通信:
リアルタイムに利用者の状態の表示、グループチャットを実現。
1対1、1対多のライトなコミュニケーション手段を用意。

顔画像分析ライブラリを用いた集中力判定:
テレワーク環境の際、他者へ「声をかけるタイミング」の目安として、
カメラを介して得られる利用者の顔画像を利用し、集中力の状態を判定。
声をかけることができる状況の目安とする。

導入ハードルの低さ:
Teams環境へのアドオンであるため、すでにTeams運用されている場合は、
新たにソフトウェア、サービスなどを利用者側にインストールすることは不要となっている。
また、Active Directoryに連携してあるため、組織情報などは既存の情報を活用できている。

Posted in 開発事例 |

自社開発環境構築:IoTプラットフォームを用いた開発

■全体構成

■概要
Flutter及びPHP Laravelを用いたIoT開発のプラットフォームを開発。
エッジ環境に左右されない提案を行うことを可能とした。

 

■ポイント
Flutter:
Google社提供のモバイルアプリ用のフレームワーク。
iOS/Androidのライブラリを一つのプログラムから作り出すことができるため、
機能追加などのリリースを手早く行うことが可能となる。

マルチプラットフォーム:
従来のiOS/Androidの開発と違いFlutterがマルチプラットフォームのため
両OS同時期に確認が可能。
また、豊富な開発実績のため、画面作成など社内ライブラリ化しており、
本来数ヶ月かかる実機での検証を大幅に短縮することが可能。

BLE通信:
IoT開発に欠かせないBluetooth連携機能も社内ライブラリ化。
様々な機器での実績があり、日々更新を行い精度アップを実現している。

マテリアルデザイン:
ユーザーのプラットフォーム環境に左右されることなく、
共通のUIを備えた使いやすいアプリをユーザーに提供可能とした。

Posted in 開発事例 |

DDoS(DoS)なんかに負けないぞ!!

DDoS(DoS)なんかに負けないぞ!!

〜 クラウドをうまく活用したDDoS(DoS)攻撃の撃退方法 〜

 

事例:オンプレミス環境のWebサーバがDDoS(DoS)攻撃を受けている

 

DDoS(DoS)攻撃とは?

DDoS(DoS)とは、Webサイトに対して、短時間に大量のアクセスが送られることにより、
Webサーバの想定キャパを超えるリクエストを処理しきれず負荷が高くなった結果、
通常のアクセスが不可能になったり、リクエスト結果が返ってこなくなるWeb攻撃です。
Webサーバの負荷が限界を超えた場合は、サービス停止やサーバーダウンも発生します。

 

オンプレミスのDDoS(DoS)攻撃対策

オンプレミス環境のWebサーバが、DDoS(DoS)攻撃に対して取れる策はいくつかあります。

  1. 想定外の大量アクセス(サーバ負荷)に耐えられる様、CPUやメモリなどのスペックをUPさせる。
  2. DDoS(DoS)攻撃の送信元IPアドレス(国単位IP or 個別IP)に対する
    アクセスの拒否設定を追加する。

デメリット:
DDoS(DoS)攻撃に備えてスペックをUPした場合、一時的にはサーバ負荷に耐えることが可能です。
ですが、DDoS(DoS)攻撃自体を防いでいるわけではないため、より大量のアクセスが発生した場合、
対策がイタチごっことなりランニングコストが上がる結果、サイト運営の売上利益・コストパフォーマンスが低下、さらには、サイト運営自体の継続が困難になります。

特定の国単位のIPアドレスやDDoS(DoS)攻撃の送信元である個別IPアドレスに対して、
サーバー側でアクセスの拒否対象として設定すれば、攻撃自体を防ぐことはできます。
ただし、同じIPアドレス帯からアクセスしてくる一般ユーザからのアクセスも拒否するため、
サイト運営としての機会損失に繋がる場合もあります。

 

クラウドを活用したDDoS(DoS)攻撃対策


弊社では、AWSクラウドをうまく活用(いいとこ取り)して、オンプレミス環境の構成を変えずに
DDoS(DoS)攻撃に対する恒久的な対応と、DDoS攻撃に伴う損失の軽減実現を提案しています。

今回の対策事例では、
オンプレミスのWebサイトに割り当てているドメインをAWSの公開ドメインに移管し、
AWS側からオンプレミスのWebサイトに転送するためのドメインを新規で発行・割り当てる形となります。
公開ドメインと転送ドメインの間にはCDNサービスを設けることで、
AWS内部にWebサイトのキャッシュが保持されるため、
キャッシュされたアクセスに対しては、オンプレミスのWebサイトにアクセスを
転送することなくAWSからレスポンスを行います。
オンプレミスのWebサイトは、AWSがキャッシュしていないアクセスのみが転送されるため、
サーバ負荷の軽減も期待できます。

主に活用するAWSサービス:

    • AWS Shield Standard
    • AWSアカウントを登録すれば無料で使えるDDoS(DoS)攻撃の防御サービスです。
      メリット:DDoS攻撃の自動で検知し、Webサーバへのアクセスを遮断する。
      課  題:無料枠のため、DDoS攻撃のアクセスに対する従量課金は発生する。
    • AWS Shield Advanced
    • 追加料金(有料)で使えるDDoS(DoS9攻撃の防御サービスです。
      メリット:DDoS攻撃のアクセスに対して発生する従量課金分は請求されない。
      課  題:ひと月3,000USDの定額制、かつ、1年間のサブスクリプション契約が必要。
    • Route53(DNS)
    • AWSサービス内のWebサイトのドメインを登録・管理するサービスです。
      メリット:ドメイン取得からドメイン登録設定までが簡単に実施できる。
      課  題:有料サービスしか選べないこと。(無料枠が存在しない)
    • AWS Certificate Manager(ACM)
    • AWSサービス内のWebサイトに対するSSL証明書を発行・管理するサービスです。
      メリット:有効期限の自動更新が可能。外部のSSL証明書の取り込み・移管も可能。
      課  題:無料枠で提供される証明書は、ドメイン証明のみ。
    • Cloudfront(CDN)
    • AWSサービス内のWebサイトに対するCDNを提供するサービスです。
      メリット:CDNにより、レスポンス性能の向上とオンプレミス自体のサーバ負荷が軽減。
      課  題:設定・運用に関する知識が必要。(誰でも簡単に設定できる訳ではない)
Posted in エンジニアブログ |

メンテナンスのお知らせ

平素は、当社をご利用いただき、誠にありがとうございます。
下記の日程においてホームページのメンテナンスを実施いたします。

メンテナンス期間中はホームページが一時的に正しく表示されない場合がござい ますので、
ご了承ください。
ご不便、ご迷惑をおかけいたしますが、何とぞご理解いただきますようお願い申 し上げます。

【ホームページメンテナンス期間】
 2021年11月10日(水曜日)9:00~正午

※ホームページのメンテナンス時間については前後する場合がございます。
予め ご了承ください。

お客さまにはご迷惑をおかけいたしますが、ご理解いただきますようお願いいた します。

Posted in お知らせ |