イシダテック、基幹システムを導入する。
石田です。
農林水産省が運営するニッポンフードシフトの公式note様にインタビュー記事を掲載いただきました！
今回も「秘密兵器」のキーワードは「国のメディアで兵器はちょっと。。。」という理由で、X（旧Twitter）に続き禁じ手扱いされてしまいましたが、素敵にまとめていただいています。ぜひご覧ください。
・・・はい、本当に食品製造の機械を作っています。
さて、システム導入の話題はかねてよりの強い想いがありまして、こやまの入替検討編を引き継いでお伝えします。決してこやまがインフルエンザでダウンしているわけではありません。
なぜシステムを入れ替えるのか（決断編）
上述の前回記事でこやまがきれいにまとめてくれました。
さすがこやま。建前要素も含むため、ここで経営者として踏み切った理由をお話します。理由は2つで積もり積もった違和感とお断り見積でした。
「オフラインこそ鉄壁説」への違和感
触らぬ神に祟りなし。君子危うきに近寄らず。
そんな諺と並んで、弊社の受発注システムにはキーワードがありました。
インターネットに繋がなければ、安心
インターネットに繋いでおらず、社内ネットワークのみなので、バックアップはもちろん手元の記憶端末（USBフラッシュメモリ）へ。
では手元の記憶端末が強盗に襲われたらどうするのか？保管している事業所が地震や火事に見舞われたらどうするのか？
これらを解決するために以前の総務部長は、業務終了後ひたすら古いサーバーがうなりをあげてバックアップするのを待ちました。
そして手元のノートPCにデータを保管し、さらに手持ちのUSBにもぬかりなくコピー。
データが入ったノートPCは会社の金庫へ、手持ちのUSBは自宅へ持ち替える・・・これで静岡県中部が広範囲攻撃が行われない限り安心安心・・・。
取締役総務部長の業務後の時間、ひたすらPCの前で待つだけ。そうひたすら・・・いつくるかわからないブラックスワンに備えて・・・。
そ れ は 違 う と 思 う 。
私は知っていました。社内ネットワークで繋がれている、他のシステムユーザーがファイルのPC間移動ができないからと、一日何度もUSBフラッシュメモリを抜き差ししているのを。
それも、そのメモリはほかのインターネットが使用できる数多の端末で使われちゃっていることを。
ただし、ここは20年間手塩にかけてカスタマイズしたレガシーシステムと、それを支えてきたパーフェクトオフライン運用、そして会社の守備周りをすべて担ってきた取締役総務部長。それを違うというのは、まるで20歳になる娘を、赤の他人から「Yo！違うと思うぞ」と言われるようなもの。何がどう違うかという話ではなく、何のことを違うかと言われることにアナフィラキシーショックがあります。
プライドにかけて、そうも簡単に違和感に共感するわけにはいかないですよね。わかりますわかります・・・。
お断り見積り
だったら、少しずつでもこのバックアップ運用を変えていきましょう。このシステムを20年前に開発し、ここまでメンテナンスしてくれた会社様にカスタマイズのご依頼をいたしましょう。
ついでに、面倒な帳票入力を解消するため、帳票をExcel形式やCSV形式で出力するためのご依頼もいたしましょう。そうしましょう。
・
・・
・・・
そうして取得した見積り、ハイプライス。
エクストリームリーハイプライス。
そうです。このシステムを現代風にアレンジする必要があり、アレンジするには基盤となる部分から変えなければならないのです。そのため、バックアップの運用変更するという目的のためには、かなりのコストが伴います。帳票のExcel化も同じです。かなりのコストが伴います。
・・・帳票も同じ・・・？
本当にそうなのか。私は知っています。データベースにAcessを使用しており、印刷する直前、一瞬Excelの画面が開いてから印刷されるのを。すでにあるではありませんかExcel。技術的にそこまで難しいこともｎ・・・
はっ！！！！
ああ、そうか。そうだったのか。これがお断り見積りなのか。
お断り見積り：プロジェクト自体が面倒、社内リソースをそんなプロジェクトに割きたくないなどの理由で、意図的に通常の2倍～3倍程度のお見積りを出して、角が立たないように断るための、奥ゆかしい伝統芸。
これはシステム自体を更新しなければならないタイミング・・・
これが決断の裏側です。
だったら変えてやろうじゃないか。やらまいか精神よ焼津人に力をおくれ。
どういう手順で実施したのか。何を参考にしたのか。
そもそもどの業務をシステムで行いたいのか。情報の連結はどうしたいのか？を一通り妄想します。
その後、かなり真面目にセオリー通りにプロセスを組みます。各フェーズ（区切り）に分けて、どうやって管理していくか？を決めました。もちろん、Redmineを使用します。
とにかく教科書通りのタスクを大体作成して、担当者を任命してしまうというトップダウンしぐさです。エイヤと南無三で構成される昭和しぐさなのです。
- 00_プロジェクト準備
- 01_要件定義
- 02_方式検討
- 03_設計・開発
- 04_テスト実施
- 05_運用準備
- 06_データ移行・並行稼働
- 07_運用
「セオリー」は昔一度読み込んだことがある書籍を参照しました。ITパスポートの書籍でも（簡略化されてますが）だいたい同じことを書いています。近道はないものの、先人の知恵を大いに拝借作戦です。
業務知識との関連性をおすすめするときには、今でもシステムx基幹業務を考える上で最高にまとまっていると個人的に考えている書籍はこちらです。その昔、前職の先輩からも「まずこれ教科書ね！」と渡された記憶があります。
メンバーを紹介します。
ところで誰が担当メンバーだったのかというと、主に次の3人です。
こちらに登場している泣く子も黙る、スピードと効率化の鬼。でも夜泣きは経験、中田さん。
石田のサイコパス声掛け期間から入社、静かに焦り、静かにやり切る男、金澤さん。
そして、MBAホルダーこやま。
すなわち、社内ICT推進会議のチームメンバーです。ハードウェアのエース渡邊さんは、もちろんちゃんとハードウェアを担当していましたが、今回はシステム周りなので割愛します。でも可哀想なのでやっぱりここで紹介しちゃいます。
そして忘れてはならないのが、社内以外にも協働いただいたシステム開発会社の皆様がいらっしゃること。ありがとうございます。
各フェーズでやったこと・思い出・教訓
ここからは、40人規模の中小x製造業企業が、20年前のオンプレ・スクラッチシステムから、SaaS型のクラウドシステムに移行する際に、実際にやったこととその思い出、教訓などを生々しく振り返ります。
なかなかこの規模のシステム入れ替えの記録は世の中に出てこない気もしており、どこかの誰かに響け私達の思い出！
00_プロジェクト準備
準備段階では、だいたい次のようなことを行いました。
最も期間（所要時間ではなく）がかかったのは、新システムの選定にあたる「移行先販売管理Sysのサービス・パッケージの調査」で、開始日22/04/21、終了日22/12/09と、8ヶ月程度。使い勝手に加えて、次が主な選定の基準でした。
決算書でこれまで会計事務所に提出してきた書類と同様の切り口で帳票が出せるか
仕掛品一覧の出力ができるか。弊社は仕掛品で月次決算を締めているため
工数データのインポートはどのようにできるか
受注から売上までの処理の流れ
当時の思い出を振り返ります。
データ自体は無事に抽出でき安心、DBの知識も前職のおかげである程度あったためよかった。（中田）
システム選定は、コンサルにお願いできないか聞いてみましょうか？と社長から言われ、その後コンサルと打合せを実施も、中小企業向けという事で取り扱っていない領域、かつ、費用感の問題もあり、結局自力で選定する事に。
主にネットでリサーチを続けるも、中々システムが見つからない。。。
IT導入補助金の申請期限も迫っているし、焦りが募る。
そんな中、旧販売システムの端末が動かない(壊れた？)という報告があがってくる度、どうしよう！！と困惑 → 渡邊さんがどうにか修復してくれて、心が落ち着く というループ（金澤）
そして土壇場で毎回頼りになる現場、という中間管理職あるある地獄絵図。
ちなみに、旧システムの中身を調査し、周到に中田さんが準備してくれたおかげで「なんとかなった」感じです。このなんとかするスキルと能力は崇めなければいけません。以下に奮闘感のある中田メモを掲載しておきます。
現行システムのデータをどう抜き取れるかを確認。現行システムの大半のシステムにエクスポート機能がなかったが、最大33万件ほどあるデータもあり、手動移行は現実的ではない。
現行システムの開発ベンダーに頼れば抽出はできそうだが、並行稼働も考えると抽出も1回ではすまず、かなりの金額がかかりそう。
定期的に総務で取得していたサーバーのバックアップデータを見るとメンテナンス用のAccessファイルがあり、バックアップ用PCにODBC設定もされていたため、無事全DBデータを抽出できた。
01_要件定義
プロジェクト準備でだいたいベンダー様の選定はできていたため、この段階では、要件をどのように定義するか、というよりはどのシステムにするかの最終選定、ぐらいの実質的な意味合いでした。
製造業向け（の実績がある）
クラウド
使い勝手
カスタマイズ性
コスㇳ
実際には、このフェーズは金澤さんがほとんど担当してくれました。ただし、この段階で業務側の確認ももっとしっかり行っておけばよかったという反省点もあります。
どのベンダー様のどのシステムにしようか、と日々探す中で、意外と「対応地域」が限られる現実も興味深く見ていました。
結局、弊社の場合はCMA様の提供する「オセロコネクト（以下OC）」に決定しました。
02_方式検討、03_設計・開発
このあたりはまとめて記載します。
OCにシステムが決定し、OCシステムそのままでどこまで対応できるか、そのままでは現状業務が満たせない場合には業務を変えてシステムに合わせられるか、またはシステムのカスタマイズが必要かを整理しました。
現行システムとDBのデータと実務者からのヒアリング内容を比較。システム会社（CMA）にも必要カスタマイズの仕様を伝達しました。
カスタマイズの内容は、TeamSpiritの勤怠データインポート機能や、発注データインポート機能（元々ある機能では製番と紐づけられないなど要件を満たせなかったため）などです。
ここから一気にしみじみ感が噴き出します。
使い慣れたフローを変えたくないという実務者側と、あるべき姿（新システムに存在する機能はできるだけ使うなど）を追いたいシステム導入者側のせめぎあい。これまでのシステム導入でもそうだが、毎度のことながら神経が疲れた思い出。
カスタマイズ仕様を伝えるためにシステム会社のCMAとも打ち合わせ等をしていたが、システム屋さんとは話が通じやすいため気持ちが楽だった。
ヒアリングを行って現状システムを理解したつもりでも解析を進めれば進めるほど次から次へと知らないことが出てきて、徹底した現状分析の重要性を認識。（中田）
一方、金澤さんの思い出は・・・
金澤「オセロコネクトにシステムは決定したものの、使用する人が敬遠しないよう旧販売システムに近づけようとすると、カスタマイズ費用がかさんでしまう。。。
中田「汎用的なシステムなので、カスタマイズではなく当社の運用を変えるという考えですすめた方が良いと思います」
金澤「なるほど！！！」
04_テスト実施
システム開発会社である、CMA様が作成したカスタマイズの設計書の確認や、カスタマイズ後のテストを行います。
中身がほとんどないチケットばかり。セオリー通りとは全然いきません。
カスタマイズの内容を伝えたつもりでも認識相違が何点かあった。普段使っているシステムや業務が違う相手とは共通言語も異なるため、認識を合わせることが難しいことを感じた。（中田）
コミュニケーションをされていたのが印象的でした。
05_運用準備、06_データ移行・並行稼働
この2つは時系列的に並列だったのでまとめて記録しています。
もっとも重く、最も手のかかったフェーズでした。
新システムの操作方法の説明会の実施
データ移行後に発生したいろいろな課題の対応
ユーザーや科目等新システムで使用するIDの定義
新システム側で旧システム側の過去データ全てを参照できるようにデータを移行
を主に行いましたが、記録上はかなり細かく丁寧に行っています。
中田さんも約50人日かかっており、印象に残っていた感情も多かったようです。まずは、運用準備フェーズにおいて。（50人日のうち10人日）
説明会で一通り説明してみんな理解したつもりになっても、実際に運用開始日が近づいたり、実運用が始まると何も知らないとなって焦る人が多数。実際に当事者意識をもって、システムを触ることの重要性を痛感。
システム提供者側とも運用開始に向けた残課題が増えてきて、当初はメールで管理していたが、何が残っているかわからなくなったため、スプレッドシートに移行。ただ、スプレッドシートも1行に対するラリーが多くなるとコメントが増えて誰がボールを持っているかもわからなくなり、最終的にRedmineにCMA様のメンバーを招待。その後はスムーズに残課題・TODO管理を行えた。これぐらいの規模の課題・残務管理になるとメールやスプレッドシートでは限界がある。（中田）
そして、データ移行と並行稼働。これが最重量のフェーズでした。（50人日のうち40人日）
基幹システムのデータ移行を正直なめていた。こんなに大変だったとは。結果2度のシステム導入延期となり申し訳ないが、同時によくやりきれたとも思う。他業務の片手間ではなく、本当は専任の担当者をつけてやるべき規模だった。
1996年ごろのデータからDBにあったが、途中で使用区分が変更されていたりした。
移行データを作ってインポート機能で移行して不備を見つけての繰り返し。AccessとVBAをひたすら操作（今思えばAccessに苦慮した部分もあるためPythonやC#で書けばよかったかも）。自分が現行システムを使っているわけではなく、担当者からヒアリングした内容を元に各値を推測したりしながら進めたため、具体的なイメージが持てずに何度もヒアリングしたり、現行システムを眺めたり。
現行システムと新システム側でDBのデータの持ち方が違う項目（現行では物件明細が2階層だったのに対し、新システムは1階層のみなど）があり、そのコンバージョンなどに苦慮。
新システムのインポート機能は最新税率のみだが、過去データは当時の税率を適用する必要があった。
正しいデータ入力、管理、メンテナンスがどれだけ重要か・・・気をつけます。
このあたりから、CMA様側とは、チケットを用いて多くのやり取りを行いました。これが本当に助かりました。例えばこんな感じ。
各フェーズを通じて、確認事項など合わせて109チケット。CMA様には、素早く誠意を持ってご対応いただきました。ありがとうございました。
このあたり、金澤さんもプレッシャーを感じたよう。
5月導入/6月導入と2度延期をしたため、次の延期は絶対に許されないというプレッシャー。総合的に判断し、導入時期を8月に決定。
中田さんも記載していますが、CMAとのやり取りにRedmineを導入してから、事がスムーズにすすんだと感じました。反面、もう少し早くRedmineを使用していれば良かったという後悔も。
※余談※
並行して導入準備をしていたBqeyも8月開始で問題ないです、と中田さんが平常運行の感じで回答しており、金澤は内心では、”大丈夫かな？”と少し心配になったが、同時に超人ぶりも垣間見た。
（金澤）
07_運用
このフェーズでは、実際に使い始めてユーザーから上がった課題の対応を主に行いました。
導入後、中田さんもポジティブな変化を感じていたよう。
実際に使い始めると思い通り帳票が出なかったり、課題は出てくる。しかし、思ったよりも課題も少なく、スムーズに運用できた。事前の説明会やデータ移行の試行錯誤をしてよかったと感じた。
最初は前のシステムを惜しむ人も多かったが、徐々に誰でもどこから出アクセスできて、使い勝手も近代的な新システムのメリットを感じて好んで使う人が増えてきた印象。
実行予算経過表など、必要に応じて外部ツールも作成し、データも活用。元のローカルの閉じたシステムではできなかった。
（中田）
おわりに
まず、1996年から日々蓄積されてきた受発注、在庫、会計データを寸分の狂いもなく移行し、新しいシステムで参照可能としていること。業務上、混乱をもたらすことなく、円滑にシステムを移行したこと。そして、これらを日常業務で大変ななか、責任感を持ってやり遂げていただけたことに、心より感謝します。
特に、中田さん、金澤さんにおいては比較的社歴もあたらしく、自身の領域以外の業務はヒアリングベースで解き明かしながら、根気強く進めてくださり、ありがとうございました。
おかげで、今まで見ることができなかったような環境で、素早く、効率的に業務データにアクセスすることができています。
さらに、データ活用という面では、担当者個人個人が、任意の切り口でデータを分析することで、より競争力が高まった製品づくりの助けになる、と確信しています。
次回は、業務上利用している側のインタビューを予定しています！どうぞご期待くださいませ！