動いているものを、止めずに。

お客様

不動産ポータル向けサービス事業者様
賃貸物件のパノラマ画像の収集・保存・表示

領域

クラウド画像基盤の新規構築

担当範囲

要求要件定義 ／ 基本設計 ／ 開発

時期

2025年5月 要求要件書 ― 2025年10月 基本設計

課題

物件のパノラマ画像は、これまで特定メーカーの360度カメラ専用サービスに依存していました。けれども現場で実際に使われている機材は、すでにばらばらです。

• メーカー製以外のカメラで撮った画像が、そのままでは表示できない。Insta360、GoPro MAX、他社製の全天球カメラ、スマートフォンのパノラマ。撮る人はもう、1社の機材だけを使ってはいません
• 対応機材を増やすたびに、表示のしくみを作り直すことになる。機材ごとに表示ロジックを足していけば、いずれ手が付けられなくなります
• すでに公開されている表示URLが、約140万件ある。載せ替えの間、物件ページからパノラマが消えることは許されません

設計したこと

① 機材の違いを、入口で吸収する。撮影機材ごとの差は取り込み口で正規化し、表示は360度／180度の2種類に統一しました。機材が増えても、表示側を作り直さずに済む形です。

② 冪等な連携API。基幹システムから画像を受け取り、変換し、表示URLを返す。同じ画像を二度渡されても結果が壊れないことを前提に設計しています。

③ 無停止移行。約140万件の旧URLを新URLへ移し替えます。変換処理を並列に動かして所要時間を詰め、移行中もパノラマが非表示にならないことを要件として明記しました。

④ 想定規模から、先に構成を決める。月間約60万PV、同時接続 約300台、月間約2.5万件の変換、初期データ量 約15TB・年間約3.6TB増。この数字を先に置いたうえで、配信・防御・スケールアウトの構成を決めています。

規模と構成

この案件で、いちばん時間を使ったところ

変換アルゴリズムではありません。「今、どう動いているか」を確認する作業でした。基本設計書の最後には、お客様への確認事項が6件残っています。既存システムの受付API仕様。現行のFTP取り込み手順。旧サービスからデータを書き出せるのか。誰がどの機能を使うのか。

ここを詰めないまま作ると、動くけれど載せ替えられないシステムができあがります。確認事項は、設計書に残したうえでお渡しします。

お客様

機械装置メーカー様
最終ユーザーは鉄工所様

対象

新規製作機（管端絞り加工機）

担当範囲

PLCプログラム設計 ／ タッチパネル画面設計

時期

2025年12月 ご依頼 ― 2026年1月 納品

内容

新規製作の加工機に載せる制御ソフトを設計しました。お客様から提供されたのは、自動運転フローチャート一式、手動運転フローチャートとアラームリスト、既存機の参考プログラム、そしてタッチパネルの画面レイアウトです。

設計にあたって守ったのは、お客様の標準に合わせることでした。

• 自動運転は、お客様標準の「データレジスタによるステップNo.管理」方式を踏襲する
• 手動運転は、標準的な自己保持回路を使う
• その他の回路も、参考プログラムの書き方に合わせる
• タッチパネルは、支給された画面レイアウトどおりに作る
• 開発環境は、お客様ご指定のツール（PLC側：GX Works2 ／ タッチパネル側：GT Designer3）を使用する

自分たちのやり方で書いたほうが速い場面もあります。それでも合わせるのは、この機械を後で保守するのが、私たちではなくお客様の技術者だからです。読めないプログラムは、納品した瞬間から負債になります。

なぜ、この案件をここに載せるか

DXのご相談をいただくとき、話はたいていクラウドの図から始まります。けれども工場では、データはクラウドから湧いてくるものではありません。機械を動かしているプログラムの中にしか、ありません。

私たちは、そのプログラムを書く側の仕事も引き受けています。フローチャートからステップを起こし、既存機の回路の書き方に合わせ、タッチパネルの画面を作る。現場の信号を「どのアドレスから、どう取るか」という話ができるのは、この経験があるからです。

お客様

生産管理パッケージのベンダー様
販売開始から約25年、導入実績1,700本超

対象

発注管理・在庫管理・生産計画・負荷進捗の各サブシステム

担当範囲

詳細設計書 ／ コーディング ／ 単体テスト

体制・期間

5名 ／ 約2年間

この仕事の性質

25年動いてきたパッケージに機能を足す仕事は、新規開発とは別物です。求められるのは、新しい設計思想ではなく、既存に合わせる精度でした。

• 画面の作法（項目の並び、キー操作、確定のタイミング）を既存機能と揃える
• 帳票・グリッド・バーコードなど、既存で使われている部品と同じものを、同じ使い方で使う
• 1,700社それぞれの運用に影響が出ないよう、既存の挙動を変えない

技術構成：C# ／ .NET Framework ／ 既存パッケージで採用されている帳票・グリッド・バーコードの各コンポーネント

新しく作り直すほうが、書く側は気持ちがいい。けれどもそれをやると、1,700社の現場が「前のバージョンのほうが良かった」と言い始めます。2年間、同じ体制で続いたことが、この案件でいちばん申し上げたい実績です。

お客様

日本のSIer様
ERP（企業資源計画）システムの構築プロジェクト

対象機能

商品管理 ／ 計画管理 ／ 納品管理

担当範囲

詳細設計書 ／ コーディング ／ 単体テスト ／ 結合テスト

技術構成

Windows Server ／ ASP.NET ／ Microsoft SQL Server

内容

元請けのSIer様が定めた設計標準・ドキュメント様式・レビュー手順の中に入って、担当範囲を仕上げる形の案件です。成果物は動くプログラムだけではありません。お客様の様式で書かれた詳細設計書と、テスト結果までが納品物でした。

オフショア開発でつまずくのは、たいてい技術ではなく、この「様式と粒度が合わない」ところです。書き直しが発生すれば、コストも納期も一緒に崩れます。詳細設計から結合テストまでを一括で引き受け、元請け様のレビューに通る形で納めています。

お客様

スポーツビジョン・トレーニングを提供される事業者様

領域

モバイル会員アプリ ＋ 管理画面（Phase 1）

担当範囲

業務仕様の策定（日英併記）／ プロトタイプ

対象読者

お客様（機能合意）と開発者（実装範囲の把握）

Phase 1 の範囲

会員登録・ログイン（顔認証対応）、ホーム、トレーニング入口、トレーニング画面（横向き全画面）、期間を選ぶ購入フロー（アプリ内課金）、購入確認・完了、アカウント、パスワード変更、会社情報・プライバシー・利用規約、退会。管理画面は、トレーニングカードの登録・公開制御、課金商品の価格設定、購入履歴と利用権の管理（有効／保留／返金／失効。返金通知で自動失効）。

「買った会員だけがトレーニングを使える」――この一点を、画面遷移と権利管理の両方で担保する設計です。

有料コンテンツの保護

トレーニングの内容そのものが商品なので、画面の中身が外に出ることが、そのまま損失になります。Phase 1 では2つの対策を入れました。

• 顔がカメラの正面にないとき、内容を表示しない。トレーニング画面ではカメラを起動し、正面の顔を検出できない場合は画面を暗転させてメッセージを出します
• 画面キャプチャを検知したら、画面全体を黒くする。

そして、できないことを書きました

お客様からは「斜め45度から覗かれたときも内容を隠したい」というご要望をいただきました。これに対して、私たちは仕様書の中で技術的に実現できないとお答えしています。理由も併記しました。顔認識と同時に周囲のすべての物体を認識し、それが撮影機器かどうかを判定することは実現できないこと。端末が固定された状態で第三者が横から覗く場合は、そもそも検知のしようがないこと。

できることとできないことを分けて、書面に残す。それ自体が、Phase 1 の成果物の一部だと考えています。あとから「できませんでした」と言われるより、先に線を引いたほうが、次の打ち手を一緒に考えられます。

退会フローと法的情報ページは、アプリストアの審査要件に沿って Phase 1 の必須範囲としています。