ピンポジ+（ピンポジプラス）は紙・FAX運用と属人化が課題となっているゴルフ場のピン位置決定業務を、 配置ルールに基づく自動提案・PDF出力・メール送信で一貫してデジタル化する業務用Webアプリケーションです。
私は現在ゴルフ場でコース管理の仕事をしています。コース管理とは、ゴルフプレーヤーが快適にプレーできる環境を維持する仕事です。具体的には芝刈り、散水、施肥、剪定など多岐にわたります。その中にピン位置決定という業務があります。
ピン位置を決めるには、外周から4ヤード以上離す、過去2日間の位置から7ヤード以上離す、急傾斜や芝の傷みを避ける、9ホール全体のバランスを取る——といった複数のルールを頭の中で同時に処理する必要があります。
日々この業務をやりながら、「これってプログラムにやらせた方が正確で速いんじゃないか」「この時間を他の作業に回せるんじゃないか」と感じていました。
さらに現場では以下の課題も抱えていました。
- 判断基準が人によってバラバラ（属人化）
- 手書き → 清書 → FAX → 印刷という非効率なフロー（紙媒体）
- ピンの履歴や雨天禁止エリアなどの紙データが散在しており、一度に参照できない（データ散在）
- 芝の傷み箇所の認識が上司とスタッフ間で共有できていない（情報共有不足）
既存のツールも調べましたが、海外製で日本の現場には合わないものばかり。「無いなら自分で作ろう」と思い、独学でこのアプリの開発を始めました。
ゴルフ場のコース管理は、芝刈り・散水・施肥・カップ切り・バンカー均し・配管工事など多岐にわたる。 パッティンググリーンはコースの中で最も重要なエリアであり、その日のカップ位置（ピン位置）を毎朝決定する業務がある。
ピン位置を決めるには、複数のルールを同時に満たす必要がある。
- 外周から4yd以上離す
- 過去2日間のピン位置から7yd以上離す
- 急傾斜エリアを避ける
- 芝が傷んでいる箇所を避ける
- 9ホール全体で上段・中段・下段、左・中央・右のバランスを取る
これらを毎朝、頭の中で同時に処理しながら決めている。最終判断は人が行うべきだが、そこに至るまでの工程はプログラムの方が精度が高い。
| 課題 | 内容 |
|---|---|
| 属人化 | 人によって判断ロジックがバラバラ |
| 紙媒体 | 手書き → 清書 → FAXという運用 |
| データ散在 | 過去ピン・禁止エリア等がまとまっていない |
| 情報共有不足 | 傷み箇所の認識が上司とスタッフ間で共有できていない |
勤務していたゴルフ場の平均年齢は50歳（上は75歳）。30代は自分一人だった。人手不足・高齢化が進む中、少ない人数でよりよい運用ができるようにしたいと考え、このアプリを開発した。
- 属人化 → ルールをシステム化し、誰でも同じ判断ができる
- 紙媒体 → 手書き・FAXを廃止し、デジタルで完結
- データ散在 → 過去ピン・禁止エリア・傷み情報を一元管理
| 利用者 | デバイス | 利用場所 |
|---|---|---|
| 管理者（グリーンキーパー） | PC | コース管理事務所 |
| 作業スタッフ | タブレット | 現場（グリーン上） |
| マスター室 | PC | マスター室 |
- グリーン上でピン位置をメモ
- 事務所に帰って本番用紙に清書
- 上司が確認・紙の切り貼りによる修正
- FAXでマスター室へ送信
- マスター室の人が印刷
- プレイヤーやキャディーに配布
- 管理者が事務所のPCでピン位置を自動提案 → 確認・調整 → スタッフに公開
- スタッフがタブレットで確認・グリーンの状態に応じて微調整 → 管理者に完了報告
- 管理者が最終確認、再調整 → マスター室に自動メール送信
- マスター室の人がPDFで確認、印刷
- プレイヤーやキャディーに配布
入力から共有まで同一データで行い、再入力・伝達作業を削減する。
条件（雨天・難易度）を設定し、18ホール分のピン位置を一括自動提案。提案後は個別に手動調整が可能。
グリーン上のセルをタップして傷みエリア・禁止エリア・雨天禁止エリアを登録。自動提案時にこれらのエリアを回避する。
ピン位置をPDFで確認し、マスター室にPDFを添付して自動メール送信。
スタッフはタブレットを使い、グリーン上でピン位置（管理者が自動提案したもの）を確認、修正。ホールごとのピン位置調整と管理者に完了報告が可能。
季節や大会などで早朝4時頃から暗い中作業する場合があるのでダークモード対応。
| カテゴリ | 技術 |
|---|---|
| フロントエンド | Next.js 15 / TypeScript / React 19 |
| バックエンド | Laravel 12 / PHP 8.4 |
| UI | Tailwind CSS v4 / shadcn/ui |
| グリーン描画 | react-konva |
| データベース | MySQL 8.0（AWS RDS） |
| 認証 | Laravel Sanctum |
| ストレージ | Amazon S3 |
| メール | Amazon SES |
| テスト | PHPUnit / Vitest |
| インフラ | AWS EC2 / Cloudflare |
| IaC | Terraform |
| 環境構築 | Docker |
| CI/CD | GitHub Actions |
| PDF生成 | @react-pdf/renderer |
グリーン形状・セル・制限エリアなどをレイヤーとして重ねて描画する必要があり、DOM/SVGよりもパフォーマンスと制御性に優れるCanvasベースのライブラリとして採用。
グリーン外周からの距離制限や禁止エリア生成において、ポリゴンのオフセット処理が必要となるため採用。
既存の紙フォーマットを再現する必要があり、Reactコンポーネントベースでレイアウトを構築できる点を評価して採用。
画面遷移なしで操作が完結する二画面構成を採用。コース全体を俯瞰しながらピン位置を検討できる、紙運用に近い操作感を実現。
精密な測量データに依存せず、傾斜情報を現場の作業者が手動入力できる設計とし、定期的な測量が必要となる導入障壁を解消。
広範囲の情報は曲線、局所的な情報はセルで表現するなど、情報の性質に応じて描画方法を使い分け、レイヤー重畳時の視認性を確保。
複数条件（過去の配置履歴・芝の傷み・傾斜など）で候補を絞る第1段階と、コース全体のバランス（難易度配分・奥行き分散）を考慮する第2段階に分けて実装。
開発中に使用した外部ライブラリ（clipper-lib）の型定義不足を発見し、TypeScript型定義の公開リポジトリ「DefinitelyTyped」へPull Requestを提出し、マージされました。
- PDFフォーマット複数対応（ゴルフ場ごとの差分吸収）
- キャディー携行用ポケットサイズ印刷フォーマット作成（現場での携帯性・視認性を考慮したレイアウト最適化）
- ピン・セル入力画面のズーム機能（操作性向上）
- 難易度パラメータ調整機能（既存ロジックの調整機能）
- 複数ゴルフ場対応（コースごとの設定切り替え）
- 9ホール / 27ホール / 36ホール対応（ホール構成の可変化）
- ツーグリーン対応（1ホール2グリーンの切り替え管理）
- 練習場パッティンググリーン対応
- MVP版は勤務しているゴルフ場の実際のマップを使用して作成した。セキュリティのため本リポジトリに含まれるマップデータはすべて架空のサンプルデータである。
- 本アプリは現場での運用を想定して開発しましたが、導入を上司に相談した結果、現在勤務している会社はゴルフ場からコース管理を受託している立場であり、本アプリを導入するには施主（ゴルフ場）側との契約上の問題があるため、導入は難しく断念しました。現在は、紙の出力や送信機能を除き、ピン位置決定に関する機能に特化した形で再設計し、開発を進めています。
Natsu
福岡在住 / Web系エンジニアを目指して転職活動中
| 項目 | 内容 |
|---|---|
| 学習期間 | 約9ヶ月（2025年7月〜現在） |
| 総学習時間 | 約1,000時間以上 （内アプリ開発約400時間） |
| 学習形態 | 独学 |
| 前職 | ゴルフ場コース管理（約2年） |
業務中に「この作業、プログラムにやらせた方が効率がいい」と感じていた。「無いんだったら自分で作ろう！」と思い独学でアプリ開発を始めた。大学卒業後はものづくりから離れていたが、開発を進める中で、子どもの頃から感じていたものづくりへの没頭感を再び味わった。課題を見つけ、構造化し、解決策を考え、すぐに形にできる——このサイクルに強く惹かれた。このワクワクを仕事にしたいと思い、エンジニアへの転職を決意。現在はWeb系エンジニアを目指し転職活動中。