業務システムとスプレッドシートの連携

この記事で弊社で動いているシステムについてざっくりと概要は把握できるようになりました。

もちろんこのシステムは現役バリバリで利用されているようですが、機能追加や修正の要望はだしても外注先が忙しいようでなかなか対応してもらえないようです。

営業からの要望

既存のシステムの受注・生産管理において、製造予定の情報を持たせることができないため、受注した商品がいつ頃製造されるのかを知るためには製造に問い合わせをしないとわからず苦労しているとのこと。

製造側の課題

製造のスケジュールは予定しているものに加えて、差し込みもあるため、1週間のスケジュールは週に何回か変更があり、製造全体のスケジュールを把握しているのは製造のマネージャーだけという状態でした。

この状態だとマネージャーが急遽出社できないような場合に、製造全体が機能停止してしまうためあまり健全とは言えず、製造全体のスケジュールを事前に共有するための方法が必要でした。

初期対応

既存のシステムに対してこちらの方で手を入れてしまうというのも一つの方法ではありますが、外注先の運用保守の対象外になるので何かあった時に面倒です。

以前導入したG Suiteのスプレッドシートで受注情報を営業側で入力し、製造側でその受注に対する生産予定を入力する製造予定表を作成して、営業・製造事務で閲覧・編集できるようにしてやりました。

また、製造予定日等が変更された場合は、変更されたこととその内容を営業・製造双方が把握しておく必要があります。これまでは、それらの情報は電話で行われていましたが、以前導入したSlackが使われるようになってきているので、変更を検知したいカラムの値が更新された場合は、Slackで変更内容を通知する仕組みをGASで作成してやりました。

これらの初期対応によって、営業側の要望と製造側の課題はある程度解決することができるようになりました。

初期対応の課題

生産予定表は営業が入力した受注に対して、製造がその製造予定を入力する形式となっています。

受注情報は既存の業務システムにも入力していることから、生産予定表ができたことによって受注情報を業務システムとスプレッドシートの双方に手動で入力する手間が増えてしまいました。また受注情報における受注数量や納期といった情報も度々変更されるため、その場合にも都度、業務システムとスプレッドシートを更新する必要があります。

このようなデータの二重管理はそのうちデータの不整合が発生し、どっちのデータが正しいのかわからなくなってしまうため、早めに対処してやるべきです。

業務システムとの連携

受注情報は業務システムに入力されることが前提となっているため、業務システムに入力された受注情報を正とし、その情報に紐づける形で製造予定を入力できるようにしてやることにしました。

ただ先にも述べた通り、業務システム自体に手を入れると面倒なので、製造予定表のスプレッドシートに、業務システムのDBから取得した受注情報を流し込む形で実現することにしました。

バッチは、sqlcmdで生産予定表に必要なデータをCSVで取得しG Suiteのドライブにアップロードします。アップロード処理はPythonで実装しライブラリにPyDriveを利用しました。

バッチはタスクスケジューラで5分ごとにデータの取得・アップロードを行います。

アップロードはドライブ上にファイルのIDを指定し、CSVをスプレッドシートに変換してアップロードを行います。

f = drive.CreateFile({
  'id': 'xxxxxxxxxxxxxxxxxx',
  'title': 'hoge.csv',
  'mimeType': 'text/csv'
})
f.SetContentFile('hoge.csv')
f.Upload({'convert': True})

この際、Google Drive APIの方でエラーが吐かれていたのですが、アップロードするCSVの文字コードが原因でした。

sqlcmdで生成されたCSVのエンコードはCP932なのですが、アップロード前にnkfでUTF-8にエンコードしてからアップロードすることでエラーが出なくなるようになりました。

生産予定表の方はIMPORTRANGE()で受注情報を引っ張ってきているのですが、元のシートが更新されても反映までにラグが多少あるようです。

バッチの実行間隔が5分、受注情報から生産予定表への反映へのラグで最大で10分程度、業務システムから生産予定表への反映に時間がかかっている状態ではありますが、一旦これで受注情報の二重管理状態が無事解消されるようになりました。よかった。

今後

生産予定が入力できるようになったのですが、製造予定はそれなりの頻度で差し込みが発生し、生産予定の変更がされます。

差し込みが発生するとその後に控える予定が全て後ろ倒しに変更されることになり、生産予定の変更箇所が多いため入力負荷が高くなっています。

入力が面倒になってくると使われなくなってしまい、結局元の状態になってしまうためなんとかしたいところです。

差し込みや後ろ倒しであれば機械的に一括でスケジュールを変更するインターフェースがあればこの辺の問題は解消できそうなので次はそこらへんに手をつけていきたいなと考えています。

既存の業務システムのヒアリング

こちらの記事でも書きましたが、紙による情報共有が現役バリバリの弊社。

そんな弊社にも外注して作った業務システムがあると聞き、早速外注先とコンタクトを取り、概要を教えていただきました。

システムとしてカバーしている業務は以下の通り。

• 受注管理
• 売掛管理
• 買掛管理
• 生産計画
• 製造管理
• 在庫管理
• 発注管理
• 原価管理

でかいな・・・。

そしてこれ全部フルスクラッチで作る必要に本当にあったんだろうかと色々思うところはありますがそこは一旦置いておきます。

開発はDelphiを使い、サーバは弊社内にオンプレミスで設置しているとのこと。

サーバは事務所内の隅のデスクにポンと置いてあり、特にロックとかもしていない状態。無停電装置つけて、1日1回HDDをまるっとバックアップしているのですが、なんかそれ以前に色々やるべきことがありそうな・・。

もともと2人で開発をしていたがメインで動いていた1人が突然辞め残りは1人で開発、弊社側にはシステム担当などは当時おらず、ヒアリング等も全て外注先の方が1人でやり、最終的に納期は2年弱ほど遅れたとのこと。

聞くだけでしんどー。お疲れ様です。

仕様書とか何かドキュメントが欲しかったのですが、そういうものは一切なく、仕様を知りたければ実装を見るしかないという感じです。

データベースでテーブルやらカラムやら一通り見るとなんとなく雰囲気つかめるかなと思い、社内のサーバでテーブル一覧を見て見るとT_SAF_01, T_SAF_02・・・と120近い連番のテーブル達、T_SAF_02, T_SAF_02Bとかもあるし全く中身がわかりません。

先方のエンジニアに聞いて見ても当然わからず対応表的なものを見て作業しているとのこと。そんなテーブル名誰得なんだ・・・。

テーブルもわからず仕様もコードみないとわからずだと何もわからないので、テーブル名の対応表を作っていただくのと、ソースコードを送っていただくことにしました。

ソースコードを渡すことはちょっと渋られましたが、仕様書がなく仕様は実装という以上見せてもらわないとどうしようもないとゴネて送っていただくことに。

外注した際契約書に特に明記がない場合、ソースコードの著作権は受託者に帰属するとの判例も出ており、確認してないですが契約書に多分そんな項目も入れていないだろうから、ゴネられたら面倒だなーと思いましたが、なんだかんだだしてもらえてよかったです。

Delphiは触ったことがないのでどんなもんなんだろうと思っていたらMacだと開発環境そもそも作れない。仮想環境でWindows立ち上げてやればそこで動かせますが、雰囲気つかむのにそこまでしたくないので、ソースコードだけ見れればいいやと割り切り。

送っていただいたソースを見ると一つのディレクトリに500個近い連番ファイル名が。

まじかよ・・・。これ誰がメンテできるんだ・・・。

ほとんどのファイルが*.pasと*.dfmで構成されていて調べて見ると*.pasがPascalで書かれたソースコードで、*.dfmがそれのバイナリファイルらしい。

Pascalのファイルだけでも対応表が欲しいけれどそもそもそういう対応表がなさそうな雰囲気なのでちょっと気が引けます。

ソースコードの中をチラ見して見ると画面ごとにソースコードが分かれていてそれぞれのファイル内にViewっぽいことやSQLなんかも色々書いてある。ふむー。

正直今すぐこれをどうこうする気は全くおきないですが、とりあえず現状がしれたということで一歩前進。

紙での情報共有やめてく

バリバリ現役の紙の資料

前職では入社時に渡された資料や年末調整くらいしか紙の資料をもらうことはなかったのですが、転職してからはそこかしらにプリントアウトされた資料や手書きの資料がありほほーという気持ちになってました。

紙媒体で情報共有って改めて考えてみるとデメリットばかりです

• 複数の人に共有するためには共有する人数分のコピーを作成する必要がある
• 情報にアクセスするには紙がある場所に物理的に移動する必要がある
• 情報のアップデートがめんどくさいため、最新でない情報になりがち
• 情報が不要になった瞬間に紙はゴミになる
• 保管するのに物理的な場所を必要とする
• 検索ができないため必要な情報を探すのに手間がかかる

一度会議に出席すると数十枚の資料が手渡され、それらのほとんどはちらっとみる程度役目を終わるものばかりでげんなりとします。

会議以外でも検査においては検査台帳なる紙の表がバリバリ使われていました。

検査台帳は製造された製品の検査結果をまとめているものでざっくり以下のようなアクセスがされます

製造事務、製造、検査は離れた場所にあり、検査台帳は検査室にあるためここに出てくる全員が頻繁に検査室へ来て検査台帳へ書き込みをしたり結果を確認したり必要があります。

また、検査では月ごとに検査数といった各種数値の集計を行うのですが、その集計もこの台帳を元に手動で計算しており集計だけでも毎月数時間がかかっている状態です。

デジタル化の検討

この検査台帳を紙媒体からデジタル媒体に変更する目的は主に以下になります

• 物理的な移動をしなくても検査台帳の情報にアクセスできるようにする
• 集計作業を簡易化する

この要件を満たす手段はパッと思いつくものだと、

• 検査台帳システムを作成
• 共有サーバに検査台帳のエクセルファイルを置く
• グループウェアの表計算ソフトに検査台帳を作成する

などが上げられます。検査台帳システムは後々あったらいいかもしれませんが、現状だと自分自身が本当に必要なものが見えていない部分もあるはずなので、まずは少ない工数である程度の効果が出せるものを動かし、しばらく運用してみて必要になったタイミングでシステム化は検討することにします。

共有サーバにエクセルファイルを置くのもなくはないですが、同時編集がしんどかったりネットワークの設定が面倒だったりとあまりコスパがよくなさそうです。

G SuiteやOffice365などのグループウェアであればインターネットにつながるデバイスさえあれば検査台帳をどこでも見れるようになります。

ということでグループウェアで検査台帳を共有できるようにことにし、どのグループウェアを使うかは自分が慣れていることもあってG Suiteで実現することにしました。

G Suiteの導入

G SuiteはGoogleが提供しているグループウェアサービスで、ざっくり言うとWord、Excel、PowerPointなどのOffice製品をブラウザ上で作成・編集・共有できるサービスです。他にも色々できることはあるのですが細かいことはここでは割愛します。

料金がかかるものなので、G Suiteってなんぞ？入れるとどんなことできるん？ということを噛み砕いた資料を作成し、役員陣を説得して決済をもらいました。

元の検査台帳はこんな感じで、ほぼ同じ内容の表をスプレッドシートで作成

作成したスプレッドシートを検査と製造事務のPCで閲覧・編集できるようにしました。

本来ならば検査結果を参照する製造でも見れるようにしたいところだったのですが、工場内にはまだインターネット環境がなく、また粉塵といった電子機器にはしんどい環境なのでそこは後回しにすることにしました。

スプレッドシート作成時の考慮

せっかく電子化するのであればいつかシステム化する際に使えるデータにしてやりたいところです。

単純にスプレッドシートの表を作ってしまうと、表記揺れや、紙の名残で同上を意味する「〃」を記入されてしまったりとデータとしては使いにくいものが入力されてしまいます。

そこで、スプレッドシートの入力規則でフォーマットを制限したり、納入先などの項目はフリーテキストではなく、マスターデータを作成し選択して入力するようにしました。

また検査日付などはGASで検査結果の列が合格になったタイミングで自動で日付を入力するようにして入力負担を下げられるところは下げるようにしてやりました。

電子化の効果

これまでに利用していた表とほぼ同じフォーマットでスプレッドシートを作成したため、媒体が紙からPCに変わっただけという感覚でみなさん利用することができたので特にトラブルもなくすんなりと運用が回るようになりました。

検査台帳は月ごとに集計をしていたため、導入月は紙の検査台帳とスプレッドシートの検査台帳の両方を利用していましたが、翌月からは紙の検査台帳は完全になくなり、スプレッドシートのみを利用するようになりました。やったね。

こんな感じのファイルが50年分以上社内に眠っているようです。誰が一体いつ見るのか・・、見たいものは見つけられるのか不安になりますが、もうこのファイルが増えていくことはないと思うと嬉しいです。

狙った通り、製造事務はデスクから離れることなく検査台帳への書き込みができるようになり、また検査においてもこれまで数時間かけていた集計も集計シートによって秒で集計が終わるようになり、作業効率をぐっとあげることができるようになりました。

スプレッドシートの検査台帳の運用が回り出すと、営業側からも見れるようにしてほしいとの話を聞き、どういうことか聞きにいくと、納品先から納期について聞かれた際、これまでは製造の進捗が製造事務や検査に問い合わせしないとわからなかったが、このシートを見れば検査待ち、検査終了といった製造進捗がすぐにわかるようになるので助かるとのこと。

すぐに営業でも検査台帳を見れるようにしたところ、営業側もだいぶ助かるようになったようです。

社内の情報をオープンにしてやると副次的な効果が生まれるのでそういうのもできるといいなーと思っていたので、まさにそういうの欲しかった的な効果もでてきました。

弊社の本社は大阪にあるのですが、東京にも営業所があり、そちらでも同様に検査台帳が見れるようになると東京の営業が助かるということなので、東京営業所にも出向きそちらでも同様に検査台帳を見れるようにしました。物理的に距離が離れていてもインターネットさえあれば簡単に共有ができるのはG Suiteならではというところです。

今後

第一歩として紙媒体からデジタル化を行いましたが、スプレッドシートで頑張っていくと表が複雑化して行ったり、行に色をつけて何かしらの意味を持たせると行った謎の運用ルールがはびこりだしたりと徐々にしんどさが出てきます。

運用後も利用者に定期的にヒアリングをして必要な情報の追加等を行いつつ、何処かのタイミングでシステム化すると良さそうな気配があるので、その辺も徐々に進めていこうかなと思います。

また、今回は検査台帳についてデジタル化を進めましたが、同じようなものは社内にいくらでもありそうなので色々な部署を転々とし目についたものは一つ残らず駆逐してやろうと思っています。

Slackを導入するぞい

前職では空気のごとく当たり前に存在していたSlack

いなくなって初めてありがたさが感じるものですね

転職して感じたのが社内電話の多さ。電話はしょっちゅう鳴り響いていて、

「○○さんいますかー？」「今いないのであとで折り返しますー」

みたいなことや、製品名の聞き直しとか全部電話をかけてやりとりしています。

構内放送もあって、電話繋がらないときは社内全体に放送が行き渡っていて最初はだいぶびっくりしました。

電話は基本的に相手の仕事を強制的に中断させてしまいますし、言った言わない、聞き間違え等々の問題があるので、よっぽど緊急性があるときに限って電話を利用するようにして行きたいです。

Slackの料金体系はフリーでもインテグレーションが10個までという制限以外はそこまで不便しない形なのでとりあえずフリーで進めることにしました。

導入の壁

いきなり全社導入じゃ！とかやっても滑るのが目に見えてるので、とりあえずバックオフィスと検査を担当している部署に試しにSlackを導入してみることにしましたが、早速課題が出てきました

個人PCがない社員

社内にはPCがあることはあるのですが、ごく一部の社員が個人用PCを持っているだけで、基本的には共用PCです。

特にロックとかもかけられていないし、誰でも個人宛のメールが読めててすごい・・・

Slackはワークスペースの切り替えはサクサクできますがアカウントの切り替えはそもそもユースケースとして想定していない作りなので、共用PCでSlackをどう使うかが悩ましいです。

ここは開き直って共有用PCには共有用のSlackアカウントを作成して使うことにしました。

メールアドレスがない社員

個人PCを持っていない社員がいることはなんとなく把握していたんですが、個人のメールアドレスも持っていない社員が結構いることが判明。普段の業務でメール使わないから持ってないよって言われると、まぁ確かにとなってしまう。

本当はワークスペースに登録できるメールアドレスのドメインに制限を入れたいところだけれど、一旦そういう場合はgmail使ってもらうことに。

電話のが早い社員

普段PC使わない人からするとタイピングやPCの画面を見るっていうのは結構面倒なことでついつい電話をかけてしまいがちです。

時間はかかりますが、こちらからの連絡はSlackで行い、返信がない場合には電話なり直接会って、Slackにメッセージ入れたので確認お願いしますと連絡を入れてSlackを開いてもらう頻度を徐々に上げてもらい慣れていってもらうしかないです。

導入して数ヶ月

パイロットケース的に導入した検査とバックオフィスとの連絡は100%電話であったものから、急ぎの問い合わせ以外はSlackでされるようになって来ました。

その様子を見て他の部署でもSlack見れるようにしたいとなってきたので少しずつではありますがSlackが浸透して来ました。

Slackの強みであるインテグレーション周りが仕事で活きてくるようになってくると更に便利さがわかって来てもらえると思うので今後はその辺を手を入れていこうと考え中です。

ドメイン管理をNTTビズリンクからお名前.comにする

今すぐやるわけではないけれど、コーポレートサイトのホスティングをNetlifyにしていくにはドメイン周りの設定もいじらないといけない

NTTビズリンクの管理画面でDNSレコードの編集どこからやるのかと探してみても見当たらない

サポートにメールを投げてみたところ

■DNSレコードについて
　DNSレコードの設定は弊社へ依頼いただく必要がございます。
　ドメインを他社へ移管する場合のお申込方法につきまして、
　ご案内いたします。
　
　下記URLより「オプションサービス追加・変更・廃止申込書」をダウンロードし、
必要事項をご記入ご捺印の上、 弊社サポートデスクまでお申込ください。

　「オプションサービス 追加・変更・廃止申込書 」
→http://www.nttbiz.jp/download/pdf/option_1-1.pdf
※「お客様情報」及び「３. ドメイン名関連」のドメイン名の
移転にチェックを入れていただき、移管先の指定事業者をご記入ください。

PDF印刷して、色々書いて郵送してくれだと・・・。
追加で、設定にどれくらい時間かかるかを質問すると

→変更希望日の3営業日前までにお申込みいただく必要がございます。

※弊社稼働状況により、変更希望日に沿えない場合がございます。
　その際は、弊社よりご連絡させていただき、変更希望日の日程を
　調整させていただければと存じます。
　予めご了承ください。

DNSレコードいじるのってこんな大変なんだっけ・・・
ドメイン管理を定番のお名前.comに移そうと決意。

移管も例の申込書を印刷して郵送する必要があるのですが、もうこれはしょうがない。
DNSレコードいじるたびにこのやりとりしなくて済むなら1回くらいは我慢しましょう。

しばらくするとメールで「ドメイン移管に伴うご案内」という件名のメールが届く。

尚、お名前ID付替え処理となるため以下FAQをご参照くださいますようお願い申し上げます。

・既存のお名前IDに付け替え
→https://www.onamae.com/guide/p/32#01

　①弊社がお渡ししたお名前IDでログイン
　②今後ドメインを管理される方が普段利用しているお名前ID、パスワ
　　－ドを入力後、お名前IDに付け替え設定

 一瞬混乱したけど、NTTビズさんもお名前.comでドメイン管理しているから、こっち側でお名前.comのアカウント作って、ドメインをそのアカウントに紐づけるってことか。

ということで無事にドメインをお名前.comで管理できるようになりました。

この段階ではまだネームサーバはNTTビズリンクさんのものをつかっているので、DNSレコードとかをいじるにはネームサーバをお名前.comのものに変更してやる必要があります。

また、ネームサーバを変更する際には既存のDNSレコードの設定を引き継がないと、サイトにアクセスできなくなったりメールが使えなくなったり問題が起きてしまうので、NTTビズリンクに問い合わせをして現在のネームサーバに登録しているDNSレコードの一覧を送っていただきました。

ここまでいったら、あとはお名前.comでもらった既存のDNSレコードをぽちぽち設定していきます。設定する際に、ネームサーバも変更する設定があるのでそこにチェックをいれて設定完了です。

あとはDNSの浸透待ちをすればネームサーバの切り替えも完了となります。

無料になったGithubのプライベートリポジトリでNetlifyをデプロイする

この記事の続きです

前回の記事でNetlifyをホスティングに使ってGitlabからデプロイするみたいなことを考えていたのですが、ちょうどいいタイミングでGithubから嬉しいニュースが。

Githubでもプライベートリポジトリが無料で使えるようになったとのこと。

Gitlabでも良かったですが、使い慣れたGithubを使うことにします。

リポジトリ作る画面でprivate選べるようになってますね。やったね！

Netlifyの方では、New Site from Git からデプロイするGitのリポジトリを選択します。

2019年1月だとGithub、GitLab、Bitbucketに対応しているみたいです。

Githubをクリックしてぽちぽちしてデプロイするリポジトリを選びます。リポジトリが空の状態で選択すると怒られるので先に何かしらGithubのほうにはpushしておきましょう

リポジトリを選択すると、デプロイの設定をオプションでしておしまいです。

GitリポジトリのルートディレクトリにはREADME.mdや.gitignoreやら色々おくことが多いのでpublicディレクトリを公開ディレクトリにするためにPublish directoryだけ設定をしました。

Deploy siteをクリックしたら、あっというまにデプロイされます。便利ー。

デフォルトだとURLにも使われる、Nelitfy上のサイト名がランダムに割り当てられているので、必要であればSite Settingsからサイト名を変更してください。

コーポレートサイトをあれする

手始めに弊社のコーポレートサイトがどんなもんなのか覗いてみた

コーポレートサイトキャプチャ

とりあえずソースを見てみると懐かしきホームページビルダー！

<meta name="GENERATOR" content="JustSystems Homepage Builder Version 16.0.10.0 for Windows">

 ホームページビルダーってtableでゴリゴリレイアウト組むやつでしょって思ってたら今のやつはそんなことないんですね。

コーポレートサイトキャプチャ(スマホ表示)

レスポンシブではないよね。まあスマホからみる必要があるようなページでもないしまあいっか。

お問い合わせページ

お問い合わせページ発見！保護されていない通信！お問い合わせしたくない！

google先生も本気出し始めてるし、SSL化は最低限したいなー。

<Form action="/cgi-bin/mailform.cgi" method="POST">

フォームは何で送信してるんだろうと見てみると、cgi-binディレクトリ！懐かしい！

フォームのエラー画面

とりあえず送信押してみると懐かしい雰囲気のエラー画面。

ページ自体の内容は一旦置いておいて、まずはSSL化するところから始めよう。

ホスティングはNTTビズリンクっていうところのを使っているけれど、せっかくだからNetlifyに乗り替えよ。

Netlifyは静的コンテンツのホスティングサービスでありながらリポジトリとの連携やCIなんかもできて、Let's encryptでSSL化もできるしフォームもサクッと作ることができるらしく弊社にはちょうど良さそう。無料だし。

www.netlify.com

ソースコードもバージョン管理されていないから、これを機にGitlabに入れる。Gitlabってprivateリポジトリでも無料で作れるのね。知らなんだ。

ドメインのこととかSSLのことは一旦後回しにして、まるまる同じものをGitlabにpushしたらデプロイされるところから手をつけてこ。