
Geoアプリ9本構想 — 個人開発のプロダクトポートフォリオ設計
GeoDiveExa(GDE)の座標変換エンジンを GeoCoreJP として切り出してから、そのエンジンを使うアプリは1本、また1本と増えてきました。すでに配信中の GeoConverterPro(座標変換専用)・GeoPrism JP(測地系の可視化・学習)に続き、現在は次期アプリを含めて全9本のポートフォリオとして構想を進めています。1人開発でなぜ複数アプリに広げるのか、開発順や技術振り分けをどう決めているかをまとめます。
※本記事では、まだ発売前の次期アプリの名称は伏せ、GeoC〜GeoJという仮称で表記しています。機能・仕様は企画段階のものであり、実際のリリース時に変更される可能性があります。
なぜ1本でなく9本なのか — 共通エンジンの再利用経済
そもそもの発端は、GDEというRTK-GNSS測位アプリの中に埋もれていた座標変換ロジックを、独立したエンジン(GeoCoreJP)として切り出したことでした。エンジンを独立させると、「変換ロジックを必要とする別のアプリを作るコスト」が一気に下がります。実際、GeoConverterProとGeoPrism JPは同じGeoCoreJPを土台にしながら、前者は「変換に特化した実務ツール」、後者は「ズレやジオイドを可視化して学ぶ教育アプリ」という、まったく違う価値提供の仕方をしています。
同じエンジンを再利用しつつ、UIとターゲット層を変えるだけで新しい価値を作れるなら、1本の巨大アプリに機能を詰め込むよりも、用途ごとに独立したアプリへ分けたほうが、ストアでの見つけやすさも、価格設計の自由度も高くなります。これが「9本構想」の出発点です。
ラインナップの全体像
現時点の構想では、GeoCoreJP(またはその考え方)を土台にした9つのプロダクトを想定しています。
| 開発順 | プロダクト | 技術 | 状態 |
|---|---|---|---|
| 1 | GeoPrism JP(測地系の可視化・学習) | Swift | 配信中 |
| 2 | GeoC(RTK杭打ちナビ+基準点チェッカー) | .NET MAUI | 企画・開発中 |
| 3 | GeoD(工事写真の位置情報検証・補正) | .NET MAUI | 企画中 |
| 4 | GeoE(測量図面ビューア) | Swift | 雛形作成済み |
| 5 | GeoF(RTK受信品質の可視化) | .NET MAUI | 企画中 |
| 6 | GeoG(図面とARの照合・出来形管理) | Swift | 雛形作成済み |
| 7 | GeoH(境界復元・杭打ちナビ) | Swift | 雛形作成済み |
| 8 | GeoI(浸水・地盤高のAR可視化) | Swift | 雛形作成済み |
| 9 | GeoJ(RTKと3Dスキャンによる証拠保全) | Swift | 雛形作成済み |
(別枠で、座標変換専用の GeoConverterPro は GeoPrism JP と並行して先行配信済みです。)
Swift側6本・.NET MAUI側3本という内訳になっているのは、後述する技術の振り分け方針によるものです。
開発順の決定基準
9本を一度に作るわけにはいかないので、開発順には基準を設けています。
- 市場の空白があるか: 既存の類似アプリが少ない・日本の測地系に特化していない分野を優先する
- 難易度と検証コスト: GeoCoreJPを流用できる範囲が広いものから着手し、AR表示やハードウェア連携が絡む難易度の高いものは後回しにする
- 依存関係: 例えばAR系の企画は、先行するアプリで得たユーザーの反応や技術検証を踏まえてから着手したいものが多い
現状、Swift側は雛形(filesystem-synchronized形式のxcodeproj、GeoApps.xcworkspaceに追加済み)まで作成済みのものが多く、MAUI側は企画・要件整理の段階にあります。
Swift/.NET MAUIの振り分け理由
技術選定は「作り手の慣れ」だけでなく、各アプリの性質に合わせて決めています。
- .NET MAUI側(3本): GDEと同じRTK通信コード・現場向けUIの資産を再利用しやすいものを割り当てています。杭打ちナビや受信品質の可視化など、GDEの「現場でRTK機材と直接やり取りする」実装に近いアプリがここに入ります
- Swift側(6本): iOS専用機能(ARKit・カメラ制御)を使うもの、あるいはGeoConverterPro・GeoPrism JPと同じXcodeワークスペースで管理したほうが効率がよいものをここに割り当てています
同じ開発者が両方の技術を使い分けている背景には、「共同開発リポでMAUI資産を触れる」という事情と、「Swiftの方がiOS専用機能に強い」という技術特性の両方があります。共同開発リポと個人リポを分けた判断も、この技術振り分けと表裏一体の話です。
C#版GeoCoreJPという共通基盤
.NET MAUI側の3本は、C#版GeoCoreJPの設計を共有ライブラリとして使う構想です。Swift版・C#版それぞれ独立して実装していますが、変換結果が一致するよう検証値ドリブンでテストしており、「エンジン1つ・アプリ9本」という構成は、実際にはSwift実装とC#実装の2系統で支えられている形になります。
ロードマップと読者への予告
現時点でSwift側の6本は雛形まで、.NET MAUI側の3本は企画整理の段階まで進んでいます。今後、各アプリの開発が具体化するタイミングで、GDE・GCVP・GPRMそれぞれのブログで個別の企画背景記事を出していく予定です。仕様が確定していない機能については、記事化時点で「未定」「企画段階」と明記し、期待だけが先行しないようにします。
まとめ
- GeoCoreJPという共通エンジンを土台に、GeoConverterPro・GeoPrism JPに続く7本の次期アプリを含めた9本構想を進めている
- 開発順は市場の空白・難易度・依存関係で決め、技術はSwift 6本・.NET MAUI 3本に振り分けている
- 未発売アプリの名称は現時点では伏せ、開発が具体化してから個別記事で紹介する
関連記事
- 座標変換エンジンをSwiftとC#で二重実装する(GeoDiveExa)
- C#版GeoCoreJPの設計 — MAUIアプリ群の共通ライブラリ化(GeoDiveExa)
- 実務者必見・日本の測量・ドローン現場の課題をスマホで解決する「Geoアプリ」群のすべて(GeoConverterPro)
- GeoPrism JP 配信開始(GeoPrism JP)
開発者より: アプリ・Kindle本・オープンソースの一覧は GitHub: amru195704 にまとめています。
お願い
本記事の情報は参考目的で掲載しており、正確性・完全性を保証するものではありません。誤記・不正確な情報がございましたら、コメント欄よりご指摘いただければ、確認のうえ修正いたします。

コメントを残す