預かったものを、止めない。

お客様

機械装置メーカー様
曲げ加工機（パイプベンダー）など

領域

機械の制御・管理ソフトの改修と保守（7案件）

担当範囲

仕様変更 ／ OS移行 ／ 機能追加 ／ 不具合対応 ／ 制御基板の設計・実装

期間

2024年7月 ― 継続中

課題

工場の機械は、長く使われます。10年、20年と現役です。ところが、その機械を動かしているPCとWindowsは、そうはいきません。OSのサポートは終わり、接続の方式は変わり、当時の開発環境はもう手に入りません。

機械は元気なのに、まわりだけが先に古くなる。この2年でお預かりしてきたのは、その差を埋め続ける仕事です。

2年で7案件

OSの世代交代に、機械を合わせる

Windows 11への移行を、複数の機種で行いました。このとき守るのは、画面と操作を変えないことです。動く場所だけを移します。毎日その機械に向かう作業者にとって、操作が変わることは事故のもとだからです。

接続の方式が変わっても、つなぎ続ける

PLCとPCの接続を、シリアル（COM）からLANへ移しました。通信のしかたは変わりますが、機械の動きは変えません。タッチパネルからの保存、座標データの送信といった、PLCとのやりとりそのものの整備も続けています。

昔のデータを、捨てない

機械の管理ソフトには、独自形式のファイルが残っています。過去の加工データは、お客様の資産です。作り直すのではなく、読めるようにする。旧形式を変換し、現行の環境で読み書きできる状態にしました。

ソフトの外まで

2025年からは、制御基板の設計・実装・組み込みもお引き受けしています。ソフトウェア会社の守備範囲を、少しはみ出す仕事です。それでも機械を止めないためには、どちらも必要でした。

動いている機械を止めずに、その上のソフトだけを現代に合わせていく。派手ではありませんが、工場にとっては、止まらないことがすべてです。

同じ分野の新規開発として、PLCプログラムとタッチパネル画面の設計も手がけています（DX導入事例 CASE 02）。

お客様

複数の事業を展開される事業会社様

領域

新規開発・改修・保守（11システム）

期間

2021年1月 ― 継続中

現況

うち3システムが現在も運用中

何を預かってきたか

不動産の売買・修繕管理、社内の申請承認、店舗販売とPOS連携、在庫管理（2系統）、進路検索ツール、帳票のPDF出力、レース大会の運営アプリ、霊園の契約管理、店舗のライブカメラ配信。業種も規模も、そのつど変わりました。

構成も同じではありません。Ruby on Rails、Laravel、Java Struts、Vue、React、Node.js・TypeScript。お客様の事業が増えるたび、そのとき最適な形で作り、そのまま預かってきました。

たとえば ― 霊園の契約管理

この案件は、一般的な業務システムとは登場人物が違います。

• 霊園・墓地の区画情報と、そこに紐づく契約情報・顧客情報を一元管理する
• 顧客情報と区画を管理されている寺院、墓石を彫る石材店まで、関係先を含めて扱う
• 役割ごとに、請求情報の見え方を分ける

「どの業界のシステムをやっていますか」と聞かれることがあります。この5年でお預かりしたものを並べると、答えは「そのつど覚えました」になります。業務を教えていただければ、作れますし、預かれます。

11システムのうち、いまも動いているのは3つです。役目を終えたものは、終えたと申し上げます。動いていないものまで実績の数に入れることはしません。

お客様

システム開発会社様
最終利用者は運送事業者様

領域

運転者の点呼管理システム

担当範囲

基本設計 ／ 実装 ／ 単体テスト ／ 結合テスト ／ リリース後の改修・保守

期間

2025年6月 設計着手 ― 同年9月リリース ― 継続中

どんなシステムか

乗務前後の点呼記録を管理するシステムです。設計から結合テストまで一貫して当社が担当し、リリース後もそのまま預かっています。

運送事業では、乗務の前後に点呼を行い、その記録を残すことが運輸規則で義務づけられています。社内ルールではなく、法令上の手続きです。つまりこのシステムは、「あると便利なもの」ではありません。点呼が記録できなければ、その車は出せません。

構成は React、PHP、MySQL。派手な技術は使っていません。毎日必ず使われる業務なので、奇をてらわないことのほうが大事です。ご契約はシステム開発会社様と結んでいますが、実際に動かすのは運送の現場です。そこを見ずに作れる業務ではありませんでした。

運用してみて分かった、この業務の時間割

保守の難しさは、機能の多さではありませんでした。使われる時間が決まっていることでした。

• 点呼は、早朝と夜に集中します。日中に直せばいい、という前提が立ちません。メンテナンスの時間は、業務の時間割に合わせて決めます
• 締めの時期は、支払通知が出ます。その週は、出力まわりに触れません
• 止まると、その先で車が出せません。画面がひとつ表示されない、では済みません。法令上の手続きが止まる、ということです

作った人間が、そのまま見ています

障害のご連絡をいただいたとき、「仕様を確認します」から始まりません。設計した本人たちが見ているので、どこを直せば何に波及するかが、調べなくても分かります。

毎日止められない業務ほど、作った相手がそのまま見ているほうが速い。この案件は、その形になっています。

お客様

新規事業を次々に立ち上げられる事業者様

領域

新規開発と、その後の改修・運用（4システム）

期間

2024年12月 ― 継続中

特徴

現物の機械が現場にある案件を含む

何をご一緒しているか

スマートロッカーの話を、もう少し

このシステムには、現物の機械が現場にあります。ソフトウェアだけの案件とは、止まったときの意味が違います。

• 画面が重い、ではありません。扉が開かないのです
• そしてそのとき、お客様は機械の前に立っています。あとで謝る、が効きません
• 決済は通ったのに解錠されなかった、という状態を残してはいけません。だから販売の記録と通知は、決済と切り離さずに設計しています

無人で売るということは、その場に人がいないということです。現場に立っているのは、機械と、お客様だけです。

作ったあとも、直し続けています

最初の版をお納めしたあとも、改修のご依頼をいただきながら、運用を継続しています。売っている機械の上で直す、という点がこの案件の難しさです。止めていい時間が限られていますし、直したつもりが決済まわりに触れていた、では済みません。ですから、

• 変更の範囲は、決済・解錠・記録のどこに触れるかで先に切り分けます
• 触れる場合は、実機に出す前に、解錠までの一連を通して確認します
• 通知は「届かなかった」が分からない作りにしません。記録と突き合わせます

「作って終わり」と「作ってから預かる」では、設計の慎重さが変わります。私たちは、あとで自分が直すことを前提に書いています。

新規事業は、毎回ゼロから相手を探せません

立ち上げたあと、「これは誰が見続けるのか」を毎回決め直すことにもなります。会議要約、無人販売、視聴データ、医薬品の販売基盤——分野はまったく違いますが、立ち上げから運用まで、同じ相手に渡せる状態にしてあります。

たとえば、ある学術文書リポジトリでは、旧バージョンから現行バージョンへの移行をお引き受けしました。条件は「機能は落とさない、見た目は前のまま」。利用者にとっては何も変わらないのに、中身は別物になっている——移行とは、そういう仕事です。都道府県・市区町村での絞り込みや、PDFの表紙生成といった、そのお客様固有のつくり込みまで移しました。私たちが作ったものではありません。

引き取りでは、新機能から始めません。まず動く環境を取り戻し、ソースを読んで構成を書き起こし、すぐ直すべき箇所を一覧にしてお見せする。次に何を作るかは、そのあとのご相談です。

「引き取れません」という結論になることもあります。そのときも、理由を文書でお伝えします。判断までに費用はいただきません。