Hatena::ブログ(Diary)

株式会社エム・システム オフィシャルブログ このページをアンテナに追加 RSSフィード

2018-05-12

モダナイゼーション 〜 なぜ今、必要なのか ? - 後編

モダナイゼーション 〜 なぜ今、必要なのか ? - 後編

f:id:msystem:20180311182712j:image:w360


前回の「IT系お役立ち情報」は、「モダナイゼーション」の前篇として、次の内容を紹介しました。

●モダナイゼーションとは ?

レガシーマイグレーションとの違いは?

●何故、今、モダナイゼーションが必要なのか ?

「モダナイゼーションとは、どのようなムーブメントなのか」から始めて、「何故、モダナイゼーションが必要なのか」までの情報を紹介しました。

★過去ブログモダナイゼーション 〜 なぜ今、必要なのか ? - 前編


その中で「レガシーマイグレーション」と「モダナイゼーション」の違いも触れましたが、両者は微妙な関係で、本来の目的は異なるのですが、結果的には、同じ様な作業を行うケースが多いので、「レガシーマイグレーション」も、「モダナイゼーション」の一種としてとらえても問題は無いのではないか、と言う事としました。

そこで、今回は、「モダナイゼーション」の手法を紹介すると共に、そのメリット/デメリットも紹介し、最後に、「モダナイゼーションの罠」として、実際に「モダナイゼーション」に取り組む際に、陥りやすい罠や間違いを紹介します。

●モダナイゼーションの手法

●メリット・デメリット

●モダナイゼーションの罠


「モダナイゼーション」の手法は、細かく分類すると9種類もありますので、少し説明が面倒ですが、最後までお読み頂ければと思っています。

それでは今回も宜しくお願いします。

---------------------------------------------------------------------

■モダナイゼーションの手法

f:id:msystem:20180311182805j:image:w150:left

さて、前回ブログで紹介したような経緯で注目されよう様になった「モダナイゼーション」ですが、その対応方法は、単純なシステム再学習から、提供機能はそのままでも、システム実現方法の見直しを行うまで、様々な方法があります。

そこで、本ブログでは、紙面の関係で詳しくは紹介出来ませんが、「モダナイゼーション」の種類を、作業工数が少ないと思われる手法から紹介します。

なお、これから紹介する手法は、説明する人により内容が異なりますので、その点、ご了承下さい。

---------------------------------------------------------------------

(1)リラーン:システムの再学習

・システムには直接手は入れず、システムの再学習を行う手法

・「再学習」と一言に言っても、次の様な項目を再学習する。

1)オペレーション

2)運用方法

3)稼働環境

(2)リドキュメント:ドキュメントの再整備

上記(1)同様、システムには手を入れず、ドキュメントの整備を行う手法

・ドキュメントの再整備には、存在しない開発ドキュメントの再作成も含む。

・開発関連ドキュメント以外にも、システム運用全般に関するドキュメントも含まれる。

(3)リファクター:既存ソースコード設計改善

・本作業では、ソースコードの改修を行うが、あくまでも保守レベルとなる。

保守レベルのソース修正なので、機能追加は行わない。

保守レベルとは、主に、障害対応のための修正となる。

(4)リホスト:ITインフラ刷新

・システムに関わる各種インフラを最新の物に入れ替える手法

・古くなったハードウェアOSなどのプラットフォーム(基盤)部分を新しいものに置き換える。

ソフトウェアやデータにはほとんど手を加えずに移行する。

(5)リインターフェイスUI改良による新デバイス/新ブラウザー対応

・新型デバイスに対応するためにシステムとデバイスのユーザインターフェイス(UI)を修正する手法

・こちらも基本機能に対しては、基本的に手を加えず、現行の機能のままUIのみを修正する。

(6)ラッピング:インターフェイス/プロトコル変換用の連携モジュール追加

上記(5)と似た手法であるが、どちらかと言うと、システム全体をラッピング(覆う)する手法となる。

・既存システムと外部ソフトを連携させるために、新規の連携インターフェイスを作成する手法

・主に、外部とのアクセス対象を増やしたり、あるいは変更したりする時に用いる手法

(7)リライト:旧言語から新言語へのソースコード変換/書き換え

ツール、あるいは人手により、現行の開発言語を、最新のプログラム言語に書き換える手法

・前章で説明した「レガシーマイグレーション」も、この手法となる。

・言語の変更が主目的なので、機能追加等の作業は行わない。

(8)リプレース:システムの新環境移行

・パッケージ・ソフトウェアを使用している場合、新しいパッケージに切り替える手法

・機能追加や機能修正を伴う「リプレース」とは区別するが、パッケージ自体に新機能が含まれている場合は、このリプレースとなる。

(9)リビルドアーキテクチャー再構築

・現行システムの設計書を元に、ハードウェアソフトウェア等を部分的に、あるいは順次、現在主流のものに置き換えて行く手法

・これも、上記「リプレース」と同様、新規機能追加等は行なわない。

---------------------------------------------------------------------

今回紹介した9つの手法とは別に、6個程度の手法を紹介しているケースもありますが、その場合、今回紹介した複数の手法を、1個の手法として紹介しているだけです。

また、今回、9個の手法に分類しましたが、IBM社等では、次の3種類に分類しているケースもあります。

【 準備的モダナイゼーション 】

・リラーン :システムの再学習

・リドキュメント :ドキュメントの再整備

リファクター :コードの設計改善

【 中核的モダナイゼーション 】

・リホスト :ITインフラ刷新

・リインターフェイス :ユーザーインタフェースの改良

・ラッピング :アクセス性の向上

リライト :新言語への書き換え

【 再構築的モダナイゼーション 】

・リプレース :新パッケージへの移行

・リビルド :再構築

---------------------------------------------------------------------

また、前述の通り、ケースによっては、上記の「準備的モダナイゼーション」を、「モダナイゼーション」に含んでいないケースもあります。


一言で「モダナイゼーション」と言っても、様々な手法がありますし、また、それぞれの手法毎に、デメリットも抱えています。

さらに、「モダナイゼーション」を行った企業では、別の問題も浮上していますので、これらも合わせて次章で紹介します。


---------------------------------------------------------------------

■メリット/デメリット

ここまで、「モダナイゼーション」の必要性や手法等を紹介してきましたが、これだけ読んでいると、最初にも記載した通り、何か、良いことだらけの様に思えますよね !?

『 そんなに、良いことだらけなら、ウチの会社も、モダナイゼーションとか言う代物で、オンプレミスなんちゃら環境とかから、クラウドなんちゃらに移行したいので、その方法を教えてくれ !! 』


しかし・・・世の中、「良いこと尽くめ」の事など絶対にありません。メリットもあれば、必ずデメリットも存在します。

f:id:msystem:20180311182808j:image:w200:left

今回ご紹介している「モダナイゼーション」のメリットは、これまでも説明して来た通り、大きくは、次の様な内容となります。

要件設計作業が不要になる。

要件設計が不要なので、作業工数を大幅に短縮する事が出来る。

作業工数が大幅に減るので、開発費用も削減する事が出来る。

確かに、システム開発の「要(かなめ)」となる要件設計フェーズが不要となれば、工数/費用とも、かなり削減する事が可能となります。

しかし、私は、世間一般のIT企業やメーカーが説明しているように、そう単純に「要件設計フェーズ」が削除出来るとは思っていません。

私は、世間一般で言っている通り、「モダナイゼーションでは要件設計が不要」とは全く考えていません。絶対に、どのような形になるにせよ「要件設計フェーズ」は必要だと思っています。

そこで、まず本章で、「モダナイゼーション」のデメリットを紹介し、次章で、「モダナイゼーション」を行う際に、注意すべき事柄を紹介したいと思います。

---------------------------------------------------------------------

「モダナイゼーション」のデメリットですが、前述の9個の手法に関して、こちらも簡単にですが、デメリットを紹介します。

(1)リラーン:システムの再学習

・現行システムには、一切手を付けないので、モダナイゼーションの効果は限定的となる。

・別の分類手法にもある通り、準備段階なので、実際の効果はゼロ。

・社内システムの再学習だけなので、関係者に対する負荷も、それほどは掛からない。

(2)リドキュメント:ドキュメントの再整備

・こちらもモダナイゼーションの効果は限定的となる。

・しかし、「リラーン」とは異なり、ドキュメントが存在しない場合、システムを解析してドキュメントを作成する必要があるので、関係者への負荷は、かなり掛かると推測される。

(3)リファクター:既存ソースコード設計改善

保守のため、実際にソースを変更する必要があるので、関係者に技術スキルが必要になる。

・実際に、プログラムが変更されるので、設計フェーズ以降の作業が必要になる。

1)基本設計

2)詳細設計

3)製造/単体試験

4)結合試験

・これ以降の手法に関しては、全て、これら作業が必要になる。

(4)リホスト:ITインフラ刷新

・ITインフラの刷新は、ツール等によるソース・コンバージョンが主流になっているが、ツールだけでは対応できないケースも多発している。

ツールで対応出来ない場合、人手によるソース修正も必要になるので、スキル保持者を確保して置く必要もある。

・これも、ほとんど開発作業なので、上記同様の作業フェーズが必要になる。

(5)リインターフェイスUI改良による新デバイス/新ブラウザー対応

・新型デバイス対応のためにユーザーインタフェースを修正するので、当然、開発スキルが必要になる。

・開発作業なので、当然、上記作業フェーズが必要になる。

(6)ラッピング:インターフェイス/プロトコル変換用の連携モジュール追加

・既存システムには手を付ける事無く、既存システムを覆うように、外部とのインターフェイス機能を付け加えるので、作業が複雑になる可能性が高い。

・既存システム、および外部システム双方の知識が必要になる。

・正しく設計を行わないと、パフォーマンスが低下する可能性がある。

(7)リライト:旧言語から新言語へのソースコード変換/書き換え

・これも、現在では、コンバージョンツールを用いてソースコードを書き換えるケースが多いが、全てをツールで賄うことは不可能となっている。

・また、ツールに依存し過ぎると、パフォーマンス低下等の問題が発生した時に、調査/対応が出来なくなってしまう。

(8)リプレース:システムの新環境移行

・主に、パッケージ・ソフトウェアの入替えを想定した手法なので、それほど作業工数は掛からないと思い込みがちだが、パッケージのカスタマイズを行っていると、とんでもナイ事になる可能性が高い。

・既存パッケージをカスタマイズしていると、新規パッケージにも、同等の機能が必要になるケースが多いが、そうなると、カスタマイズ部分を、全て、再作成しなければならなくなる可能性が高い。

(9)リビルドアーキテクチャー再構築

・「アーキテクチャーを再構築する」とは、既存システムに対する設計思想全体を再構築する事を意味しているので、結局の所、既存の要件設計書を基準に、全てを再作成する事になる。

・ほぼ「全取っ替え」となるので、作り直しと思って取り掛かった方が良い。

・「要件はそのまま」等と、ナメて取り掛かると、必ず失敗する。

---------------------------------------------------------------------

f:id:msystem:20180311182811j:image:w200:right

結局の所、「モダナイゼーション」に於いても、ソースコードには手を付けるので、通常の開発と同じ事となります。

世間一般では、「要件設計書は現行通り」とは言え、「基本設計フェーズ」以降の作業は必要になりますので、Webに紹介されている「モダナイゼーション事例」を鵜呑みにはせず、ちゃんとスケジュールや予算を確保しないと、とんでもナイ事になります。


それと、近頃は、「モダナイゼーション」よりも、「AI」や「IoT」と言う言葉を見かける事が多くなり、政府も「Society 5.0」とか「超スマート社会」等と叫びだしています。

そして、その結果、これまで脚光を浴びていた「モダナイゼーション」によるクラウド化やホスティングには、「AIoT」を妨げる問題があることが明らかになってしまった様です。

f:id:msystem:20180202164148j:image:w200:left

「AIoT」とは、台湾資本の「鴻海(ホンハイ)精密工業」に買収された「SHARP(シャープ)」が唱え始めた造語で、「AI」と「IoT」を合体させ、次の様な意味合いで使っている言葉です。

→ モノのAI化、モノの人工知能

つまり、「Society 5.0 = 超スマート社会」を実現するためには、クラウド環境に蓄積されているビッグデータAIが解析して、その解析結果を、迅速に人間やロボットフィードバックしなければならないとしています。

ところが、ビッグデータクラウド環境にあると、AIに求められる「リアルタイム性」が損なわれる事が明らかになり、AIを導入するのであれば、データは、やはり「オンプレミス環境」にあるべきだ、と言う意見が多数を占めるようになって来ています。

詳しくは、過去ブログで、「Society 5.0」を紹介していますので、そちらをご覧下さい。

★過去ブログSociety 5.0って何 ?

それにしても、何か、「先祖返り」の様な現象が起きていますが、このような事は、IT業界では日常茶飯事です。

---------------------------------------------------------------------

以前も、「システムを改善するならERPだ !! 」と言うSIerやメーカーの言葉に踊らされて、多くの日本企業が、何億円も掛けて「ERP(Enterprise Resource Planning)」と言うシステムを導入しました。

ところが、ERPを使い始めて4〜5年もすると、「やっぱ使えね〜」と言う事になり、ERPを止めて、元のシステムに戻す企業が多発しました。

また、本ブログでは、「モダナイゼーション」の一種となる「レガシーマイグレーション」も紹介していますが、これも問題有りでした。

マシンの保守費用全般が安くなる、と言うSIer/メーカーの言葉に踊らされて、将来の事は何も考えずに、多くの企業が、メインフレームからオープン系システムに切り替えたのは良いのですが、その後が最悪です。

価格が安いと言う事で、部署毎にサーバーを無秩序に導入した結果、折角、規模を小さくしたマシンルームにサーバーが置けなくなったり、あるいはサーバーの排気熱でマシンルームが熱くなり過ぎて、サーバーがダウンしたりとか、様々な問題が起きています。

さらに、部署毎に勝手にサーバーを購入するので、メーカーも品質もバラバラ、バックアップも取れず、データの紛失が続発し、情報システム部も、お手上げになる事態となってしまいました。

f:id:msystem:20180311182813j:image:w200:right

そして、その結果、自社のマシンルームでサーバーを管理出来ないので、ホスティングする事になっているのが実情です。

私も含めて、どうして日本人と言うのは、「新しもの好き」が多いのか、困ってしまいます。

やはり、日本人は、「遣隋使/遣唐使」、それに「黒船」に始まり、海外から来る物には、直ぐに影響を受けてしまうDNAを持っているのだと思います。

それでは、次章で、「モダナイゼーション」を行う際に、気を付ける点を紹介します。

---------------------------------------------------------------------

■モダナイゼーションの罠

f:id:msystem:20180311182817j:image:w200:left

それでは最後に、「モダナイゼーション」を行う際に陥りがちな「罠」を紹介したいと思います。

本章では、主に、弊社のお客様でもある「IPA(独立行政法人情報処理推進機構)」が提供している資料を元に、その内容を紹介したいと思います。

この資料は、下記サイトからダウンロード出来ます。本ブログでは、ポイントしか紹介しません。

興味がある方は、サイトから直接ダウンロードして、詳しくご覧下さい。

IPA様サイト:https://www.ipa.go.jp/sec/reports/20180214.html

しかし、この資料「デジタル変革に向けたITモダナイゼーション企画のポイント集〜注意すべき7つの落とし穴とその対策」・・・何とも長いタイトルになっていますが、実は、この資料は、別の資料の活用を促すための資料となっているようです。

f:id:msystem:20180311182820j:image:w150:right

その資料は、本としての購入も、PDFデータとしてのダウンロードも可能な資料となっているようです。

「システム再構築を成功に導くユーザガイド 第2版」

購入するとなると「1,759円(税抜)」とかなり高額な書籍です。ダウンロードは無料ですので、こちらの方が良いかもしれませんが・・・全部で216ページにも及ぶ大作です。

しかし、本気で「モダナイゼーション」の実施を検討しているのであれば、是非、読んでおいた方が良いと思います。

それと、最初に言っておきますが、世間一般では、「モダナイゼーションを行う場合、要件設計の作成は不要」と言っていますが、このIPAの資料では、「要件設計は必要」となっています。

私も、前章に記載した通り、「モダナイゼーションでも要件設計は必要」だと思っていますので、その点を留意して読み下さい。

---------------------------------------------------------------------

【 罠 - その1 】:「再構築だから」と企画/要件定義フェーズを軽視していないか ?

f:id:msystem:20180311182823j:image:w200:left

これは、システム開発の根底を成す問題です。

とにかく、システム開発を行う場合、最初に、要求事項を分析し、その要求事項への対応を、正しく精査しておかないと、後工程となる基本設計フェーズ以降で、何らかの問題が発生します。

「こんなはずじゃ」とか「想定外」とか言う言葉は、当初の問題を正しく認識していない者が言う言葉です。

何度も繰り返しますが、「モダナイゼーション」でも要求分析は絶対に必要です。


【 罠 - その2 】:「今と同じ」という要件定義になっていないか ?

f:id:msystem:20180311182826j:image:w200:right

これも、「罠 - その1」を、言葉を変えて表しているだけです。

「今回の開発は、現行システムを開発する時の要件と同じだから・・・」だけでは、システム開発は必ず失敗します。「何が、現行システムと同じ」なのかを、文章として、明確に定義する必要があります。

また、「モダナイゼーション」では、現在と、全く同じ環境にシステムを構築する訳ではありません。絶対に、何かが異なリます。

何かが異なる環境にシステムを構築する訳ですから、現行システムと、何が同じで、何が異なるのかを明確にし、その差が、システム開発に与える影響を分析し、文章として残し、関係者に説明する必要があります。

そうしないと、「そんな事、聞いてません〜」等と言う輩が、必ず現れます。


【 罠 - その3 】:現行システムの調査が「表面的」になっていないか ?

f:id:msystem:20180311182828j:image:w200:left

これも、システム開発に取り掛かる前段階の調査不足を危惧する内容です。

つまり、「モダナイゼーション」では、現行システムに手を入れて開発を行う訳ですから、きちんと現行システムのロジックなり仕様なりを理解した上で手を入れないと、とんでもない事が発生します。

例えば、「A機能」の処理を変更しなければならないケースで、当初の調査では、「A機能」は、他の機能とは連携していない、と言う調査結果になっていたとします。

ところが、実際にロジックを見てみると、「A機能」は、多くの機能と連携しており、「A機能」を修正する場合、、他の機能への影響も調査する必要がある事が判明したと言うような事が起こるケースが良くあります。

そうなると、当初予定していたスケジュールは大幅に変更になるので、工数も費用も追加しなければならなくなり、このプロジェクトは、これだけで、もう失敗と言う事になります。


【 罠 - その4 】:業務部門はメンバの一員として上流工程から参加しているか ?

f:id:msystem:20180311182831j:image:w200:right

この点は、現場と作成者の意識統一が図れているか、と言う点を問題視した内容になっています。

つまり、「モダナイゼーション」を行うのは、社内であれば情報システム部となりますが、実際にシステムを使っているのは、現場担当者です。

この両者の意識統一やコンセンサスが統一されていないとシステム開発は失敗します。

例えば、「A業務」に関して、システムが提供する機能が不足しているので、現場では独自作業を行う事で対応を取っていたとします。

そうなると、折角、モダナイゼーションを行っても、何の意味もないシステム改修になる可能性があります。

また、パフォーマンス要件も重要ですが、業務の処理パフォーマンスを熟知しているのは、情報システム部ではなく、現場担当です。

モダナイゼーションを行う場合、現場担当を巻き込んで要求事項を、「紙ベース」から「実務ベース」にする必要があります。


【 罠 - その5 】:システムの品質や業務の継続を、どうやって担保するのか ?

f:id:msystem:20180311182834j:image:w200:left

これは、システム開発を行った結果、「何を以ってシステム開発を完了とするのか」を明確にする必要ある、という点に関して問題を提起した内容です。

弊社もお客様からシステム開発を請け負っていますが、その際、契約書に「検収条件」と言う項目を設けています。

そして、この「検収条件」では、『 受入試験/受入検収で、どのような項目を満足したら、試験完了となるのか』を明記しています。

システム開発の場合、この点を明確にした上で作業を始めないと、成果物を納品した後で、当初の要求事項に含まれていない機能に関して、「あの機能が実装されていない」とか「この機能の処理結果が違う」と言う、クレームを付けられ、成果物を受け取ってもらえないケースがあります。

このような点は、社内システムでも同様です。

当初から、どのような品質を満たすシステムを開発するのか、あるいは、業務が、どこまで継続できれば合格とみなすのかを、正しく、そして客観的に判断する事が出来るようにした上で、開発作業を進めないと、どこまで行っても、開発作業が終わらないという悲劇が生まれてしまいます。

---------------------------------------------------------------------

とにかく、「モダナイゼーションは楽勝 !!」等と、何の根拠もなく開発に突き進んでしまうと、絶対に失敗します。

「モダナイゼーション」も通常の社内システム構築と同じです。

私などは、逆に、新規にシステムを作成するよりも、モダナイゼーションの方が、面倒だと思っています。

それは何故かと言うと、既存システムを分析し、既存システムで、どのような処理を行っているのかを、正しく分析した上で開発を行わなければならないからです。

新規システム開発の場合、既存システムなど存在しませんので、要求事項を積み上げて、それを満足するシステムを作成するだけです。既存システムの分析など行う必要もありません。

故に、私は、お客様から既存システムの改修の問合せがあると、「新規開発よりも面倒ですよ。」と申し上げています。

f:id:msystem:20180311182837j:image:w200:right

さらに、モダナイゼーションの場合、10数年も昔に作成されたシステムを改修する事になりますが、恐らく、その当時、システムを開発した担当者は、もう社内に在籍していないと思います。

加えて、当時の開発ドキュメントは残っていないと思いますし、残っていたとしても・・・恐らく、書かれている内容が正しいのか、それとも間違いなのかは、誰も判断できないと思います。

結局の所は、実際にロジック、つまりプログラムを解析しなければならないので、本当に、「地獄の様な日々」が続くと思います。


「地獄」と言えば、技術者と言う人種は、他人の作ったプログラムを解析するのが「大っ嫌い」です。

私も、その昔、障害対応の部署に在籍していたので、過去の先輩方が作成したプログラムを解析して、バグを修正していたのですが・・・もう、他人のプログラムを見ただけで、ムカムカしました。

・何で、ここで、そんな処理してんだよ !!

・コイツは、構造化って言う言葉を知らねえのか !!

・馬鹿みたいに同じ処理を繰り返してんじゃねえよ !!

・こんな汚えプログラムしか組めねえのに、よく課長なんかに成れたな !!

当時の私を知る人からは、「お前は、いつも怒ってばかり居たよな〜」とよく言われますが、この事が原因だったと思います。

このようにモダナイゼーションには、様々なリスクが潜んでいますので、決して「ナメて」取り掛からない様に注意して下さい。

---------------------------------------------------------------------

今回、前編と後編の2回に分けて、「モダナイゼーション」に関して、次の様な内容を紹介しましたが、如何でしたか ?

●モダナイゼーションとは ?

レガシーマイグレーションとの違いは?

●何故、今、モダナイゼーションが必要なのか ?

●モダナイゼーションの手法

●メリット・デメリット

●モダナイゼーションの罠


世間一般で言われている「モダナイゼーション」に関しては、正直な所、私としては、次の様な感じとしてとらえています。

f:id:msystem:20180311182802j:image:w200:right

SIer/メーカーが、残り少なくなったメインフレーム企業をターゲットにして、新しい言葉を用いて、言葉巧みにオープン化を行おうとしている。

・既にオープン化を実施した企業に対して、費用を掛けずに、新しいシステムに刷新出来ると、言葉巧みに誘導して、システム開発を行わせようとしている。


要は、「モダナイゼーションは費用が掛からない」と言う嘘を言いふらして、「詐欺まがい」の行為を行っているようにしか見えません。

---------------------------------------------------------------------

確かに、「基本仕様は、現行システムと同様」だとは思いますが、それで「要件設計不要」になるとは絶対に思えません。

絶対に、何らかの「要件設計」作業は必要です。

今回紹介した「モダナイゼーション」を含め、IT系Webサイトや雑誌に掲載されているのは、当然の事ながら「成功事例」だけです。

全ての企業が、この「成功事例」の様に成功する訳がありません。

何らかの「モダナイゼーション」を行おうとした場合、先に紹介したIPA様の書籍や資料を精読してから営業の話を聞かないと、失敗する可能性が高いと思います。

何かを行う場合、全て、SIer/メーカー営業の言いなりでは、「ぼられる」ばかりです。

日々の業務で忙しいとは思いますが、これも仕事です。ちゃんと、自らも調査/学習した上で、事に臨むようにして下さい。

それでは次回も宜しくお願いします。

以上


【画像・情報提供先】

Wikipedia(http://ja.wikipedia.org/)

日経クロステック(http://tech.nikkeibp.co.jp/)

独立行政法人 情報処理推進機構(https://www.ipa.go.jp/)

株式会社 エム・システム】
本      社  :〒124-0023 東京都葛飾区東新小岩8-5-5 5F
           TEL : 03-5671-2360 / FAX : 03-5671-2361
盛岡事業所  :〒020-0022 岩手県盛岡市大通3-2-8 3F
           TEL : 019-656-1530 / FAX : 019-656-1531
E-mail    : info@msystm.co.jp 
URL     : http://msystm.co.jp/
        : http://msystm.co.jp/excel_top.html
ブログhttp://d.hatena.ne.jp/msystem/ 
Facebook   : http://www.facebook.com/msysteminc

投稿したコメントは管理者が承認するまで公開されません。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/msystem/20180512/1526169658