40万プロジェクトの裏側。電波の届かない現場で「絶対止まらない」SaaSを作る、フォトラクションの技術思想

建設現場で日々発生する膨大な「非構造化データ」を、いかに構造化し、活用可能なデータベースにするかという課題を解決しています。というのも、建設プロジェクトでは、1つの現場で数万〜数十万枚もの「写真」や、ギガバイト級の「図面（CAD/BIM）」といった巨大な非構造化データが飛び交います。

これらは従来、個人のPCやファイルサーバーに「ファイル」として散在しており、データとして活用できない状態でした。Photoructionは、こうしたデータをクラウドに集約するだけでなく、独自のレンダリング技術でモバイル等のエッジ端末でも高速に表示させたり、タグ情報や工程と紐づけて構造化したりすることで、「物理的な現場」を「デジタルの資産」へと変換するプラットフォームの役割を担っています。

おっしゃる通りです。リリース当初はまだ「SaaS」という言葉も浸透しておらず、建設業向けの業務アプリで「モダンなUI」や、そもそも「クラウドネイティブ」なものは皆無でした。

だからこそ「マニュアルなしでも直感的に使えるモバイルアプリ」であることと、そして「不安定な通信環境でもストレスなく動く」こと。この2点を徹底したことが、エンジニアリング以前の「使ってもらうための最低要件」であり、当時の圧倒的な競争優位性になりました。

「アナログな物理データ」と「デジタルデータの断絶」です。 建設現場では、壁の中や天井裏など、完成すると見えなくなる部分の証拠として、1つの現場で数万〜数十万枚もの写真を撮影します。

私が現場監督だった頃は、工事情報を書いた「木製の黒板」を置いて撮影し、事務所に戻ってデジカメからPCへ取り込み、Excelで台帳を作り……という作業を毎晩行っていました。

画像データの中に「何の写真か」という情報がないため、人間が目視で仕分けるしかなかったんです。 我々のアプローチは、この「黒板」を電子化し、撮影時にメタデータとして写真に焼き付けることでした。

撮影した瞬間に「工種・場所・撮影者」といった属性情報が構造化データとしてDBに格納されるため、フォルダ分けも台帳作成もすべて自動化できます。もちろん、これには電子小黒板に関する国の基準（CALS/EC等）への準拠も必須で、「法規制をクリアしつつ、データを構造化する」仕組み作りが最大の挑戦でした。

「まずは写真機能に特化すること」と「汎用的な機能は作らないこと」の2点です。建設現場には「図面」「工程表」「書類」など解決すべき課題が山積しており、どれから着手すべきか非常に悩みました。 その中でなぜ写真を選んだかというと、図面や検査は工程の節目でしか使いませんが、写真は現場監督が「毎日」必ず撮るものだからです。

SaaSとしてDaily Active User（DAU）を確保し、現場のオペレーションに深く入り込むためには、写真管理が最適解だと判断しました。また、写真は検査や報告書作成でも必ず使う素材であり、データのハブとして汎用性が高い点も決め手でした。

例えば「チャット機能」です。要望は多いのですが、そこはLINE WORKSやTeams、Slackといった既存の優れたツールとAPI連携すればいい。 我々のリソースは、チャットツールの再発明ではなく、建設業特有のドメイン課題（図面処理や黒板、検査ロジックなど）の解決に100%集中すべきだという思想で開発しています。

データ量がどれだけ増えても、ユーザー体感としての「軽さ」を維持する工夫を徹底しています。 例えば、最も重くなりやすいCAD図面（DWG/DXF形式）は、バックグラウンドでフォトラクション独自の形式に変換しています。

その上で、表示にはいわゆる「タイリング技術」を採用しています。Google マップのように、巨大な画像を分割し、今画面に見えている部分だけをオンデマンドでロードする技術です。これにより、ギガバイト級の図面であっても、モバイル端末でサクサク動かすことができます。

写真に関しては、まずドメイン知識として国の「納品モード（電子納品基準）」という解像度ルールがあるため、アプリでの撮影時にその基準（200KB程度）に合わせてエッジ側（スマホ側）で圧縮・最適化を行っています。

また、プレビュー表示においても、オリジナルファイルをそのまま読み込むのではなく、サーバーサイドで適切に変換・軽量化したアセット（タイリング処理等を含む）を配信することで、高速な表示を実現しています。

はい。不安定な回線を考慮してチャンクアップロードは実装していますし、リアルタイム性が求められない処理（例：大量写真のZIPダウンロードなど）は非同期ジョブとして裏側で処理を行っています。

また、画面表示においては遅延ロード（Lazy Loading）を徹底するなど、「体感速度」を上げるための定石はほぼ全て網羅しています。

非常にシビアです。 なぜなら現場監督は、その場で即座に判断を下さなければならないからです。アプリの動作が重いと、それだけで「仕事に使えない」と判断されてしまいます。

そのため、物理的な処理速度を上げることはもちろんですが、非同期処理などを駆使して体験的な部分でも「いかにスムーズに動いているように見せるか（Perceived Performanceの向上）」というUX上の工夫には、かなり注力しています。

インフラやデータベース周りは負荷が高まりやすいので、必要に応じて計画停止を行い、インスタンスの増強や構成の入れ替えを行っています。

一方、フロントエンドのリファクタリングについては、「デザインシステムの刷新」などの大きな改修タイミングに合わせて、コードベースもついでに綺麗にする、というアプローチをとることが多いですね。

そうですね。ユーザーへの価値提供を最優先し、「クリティカルな影響がない限りは許容する」という方針です。「コードが綺麗かどうか」といった内部的な品質はもちろん重要ですが、それを直すためだけに開発を止めることはしません。

機能追加や大規模改修のタイミングを見計らって、「それに合わせて返済する」という実利的な運用でバランスを取っています。

アプリ側は、サービス初期から「オフラインありき」でアーキテクチャを設計しています。 ロジックとしてはシンプルで、電波が繋がっていればアップロード/ダウンロードし、繋がっていなければローカルDBにキューイング（保存）する。

地下や高層階では本当に電波が繋がらないので、「電波がないから使えない」という仕様は現場では許されません。ユーザーに通信状態を意識させない、「繋がっていてもいなくても同じように動く」シームレスな同期体験を最初から実装しています。

明確に「役割の分離」を行っています。 モバイルはあくまで「工事現場での実行（Execution）」のためのもの。細かい編集や管理業務は、事務所の「PCブラウザ」で行っていただく想定です。 例えば、書類の複雑なレイアウト調整や大量のデータ整理は、現場のスマホではやりませんよね。

そうした機能はブラウザ側に寄せ、モバイルアプリは現場で必要な機能だけに絞り込んでいます。モバイルに機能を詰め込みすぎると、現場でのUXを損なってしまうからです。

現状、建設現場のワークフローでは「同時編集」の要望はそこまで強くないため、データ共有がメインです。 それよりも、技術的にシビアに求められるのは「監査ログ（Audit Log）」などのトレーサビリティです。

おっしゃる通りです。万が一、現場で事故や不具合が起きたときに「この検査は誰が、いつ、どの端末で行ったのか」という証跡が必ず求められます。 また、我々は上場企業のお客様も多いので、内部統制上の要件も厳しいです。

工事保険の適用や国への報告にも関わるため、「普段は参照されないが、有事の際には絶対的な信頼性が求められるデータ」として、厳格に記録・保持する設計にしています。

まず、品質へのコミットとして、一定以上のプランには稼働率を担保するSLA（Service Level Agreement：サービス品質保証制度） を設定し、下回った場合は返金する仕組みを入れています。

また、OSのバージョンについては、大手企業では「新しいOSが出ても、MDM（モバイルデバイス管理）などの関係で全社アップデートに1年かかる」といったケースがよくあります。そのため、モバイルアプリは常に直近2バージョン前（N-2）までサポート対象として開発しています。

はい。iOS/Android/iPadOS間でUIが変わりすぎると、お客様側でマニュアルをOSごとに作り分ける必要が出るなど、「展開コスト（Deployment Cost）」や「教育コスト」が跳ね上がってしまいます。

そのため、OSネイティブの作法を尊重しつつも、アプリとしてのUI/UXは極力統一するように設計しています。これはデスクワークではない、現場作業者が使うSaaS開発特有の難しさであり、面白さだと思っています。

「標準化」がキーワードです。 どんな写真を撮るか、どこを検査するかは、実は建物作りそのものとは直接関係ないけれど、非常に手間がかかっている部分です。 例えば先ほどの黒板も、アナログだと現場ごと、もっと言えば所長さんごとに書く内容がバラバラでした。それではデータが構造化されず、後で分析することもできません。

IT業界ではGitでバージョン管理するのが当たり前で、ファイル名で管理する人に悩むことはもう無いですよね。でも建設業界は、まだまだそうした「標準化」のところで悩んでいるんです。

我々のアプリでは、本社が「この黒板テンプレートを使いなさい」と全現場に配布できます。 ユーザーはアプリの指示通りに写真を撮っていけば、自然と会社の品質管理基準を満たしたデータが出来上がる。使っていただくだけで標準化されるように機能を設計しています。

我々はレガシーなものを否定するのではなく、どううまく活用するかに投資しています。 例えばBIM/CIM（3次元CAD）は、それ自体はクローズドなフォーマットでSaaSでは扱えません。そこで我々は、その3次元CADのデータを解析・変換する技術に力を入れています。

3次元CADのデータの中には、「柱」「梁」「壁」といったオブジェクト情報が入っています。 現場監督は従来、それを見ながら「どの柱を、何を検査すべきか」を自分で考えていました。

でも、データがあるなら、「どこを」「何を」「どの黒板で」検査すべきか、SaaSが自動で指示を出せるはずです。 我々はAIも使い、その構造化データから検査指示を自動生成し、現場のSaaS（アプリ）に流し込む仕組みを作っています。

非常に重要です。 社内では「フォトラクションアカデミア」という教育プログラムを実施していて、「黒板はなぜ必要なのか」「国の基準とは」「ゼネコンとサブコンの違い」などの基礎知識を学べるコンテンツを提供しています。また、お客様の許可を得て、エンジニアが現場訪問をすることもあります。

最初から建設業に強い興味があったエンジニアは実はほとんどいません。ですが、こうした複雑な業務要件をプロダクトに落とし込む力は、他のSaaS開発ではなかなか経験できない、この仕事のやりがいや面白さに直結すると思っています。

活躍の場は、単なる「特定業務の効率化」から「建設プロセス全体の最適化」へと一気に広がっていくはずです。これまでは写真や図面共有といった「点」のデジタル化が中心でしたが、今後は蓄積されたデータを活用したAIによる原価予測、ロボティクスとの連携、さらには建物の完成後まで見据えた維持管理プラットフォームなど、エンジニアが介在すべき工程は無数にあります。

その通りです。自分たちの開発した機能が、実際に巨大な構造物が建つプロセスを支え、その品質を何十年先まで保証する。この社会的意義の大きさは、一般的なWebサービス開発とはまた異なる、エンジニアとしての深い充足感を与えてくれるはずです。

我々はSaaSプロダクトへの組み込み（3D CAD解析など）と、社内活用としての BPO/IPO（Intelligent Process Outsourcing）（※3） の両輪で進めています。

はい。例えば「施工計画書」という書類作成は、図面やカタログからの転記作業が非常に多い。こうした業務を、我々がAIやBPOを組み合わせて代行するサービスを数年前から提供しています。

建設業界は今、中間層（30〜40代）が不在で、職人さんも施工管理者も慢性的な人手不足です。2025年からは残業規制も始まり、仕事はあるのに「人がいないから受注を断らざるを得ない」という深刻な状況です。 ですから、SaaSでツールを提供して効率化するだけでなく、AIやIPOで実質的な労働力を補完することも、我々の重要な役割だと考えています。

私は建築出身なので痛感しているのですが、建設会社の売上の上限は「現場代理人（現場のプロジェクトマネージャー）」の数で決まります。これはIT業界も同じ構造だと感じています。最近は「DX推進」や「イネーブルメント」といった周辺領域を志向する方が増えていますが、建築もITも、最も重要なのは「ど真ん中」でモノを作る人です。

現場代理人がいないと建物が建たないのと同様に、プロダクトそのものを作るエンジニアがいなければ、SaaSは成り立ちません。だからこそ、エンジニアの皆さんにはプロダクト作りの「ど真ん中」をやり抜き、その面白さを感じてほしい。困難な課題を解くことに熱狂できる方にとって、建設業のような社会を根底から支える巨大産業は、エンジニアとして一番輝けるフロンティアだと思います。