制作物ポートフォリオ

なぜ作ったか

指針が改訂された背景には、令和7年に公表された全国調査がある。 3年半ほどの期間で公園樹木に起因する事故・障害が931件、うち人身事故が77件。つまりこの記録は、後から「危険だと分かっていたのではないか」と問われる可能性のある書類になる。

そこで一番力を入れたのが「記録としての信頼性」だった。

未評価の項目が1つでも残っていると保存できない。空欄を自動でＡ(健全)で埋めることは絶対にしない。危険木を健全と書いた記録を行政に出すのが最悪の事故だから
点検者の欄はログイン中の利用者で固定され、氏名を打ち替えられない
規則が出した判定と違う判定を最終判定にする場合、理由(5文字以上)と実行者と時刻が必須。これはアプリ側の確認ではなくDBの制約として置いてあり、画面を通さず直接DBを触っても抜けられない
提出済みの記録は書き換えも削除もできない(DBのトリガーで拒否。管理者権限でも拒否されることを実際に試して確認済み)

同時に、現場が楽をする道を塞ぐだけでは別の抜け道を探されるので、「未評価の項目をまとめてＡにする」を明示ボタンとして用意し、押した事実と時刻を記録に残すという設計にした。記録に残るなら抜け道にならない。

もう一つの前提が、公園には電波が届かないことがある点。記録はまず端末の中に保存され、電波が戻ったときに自動で送られる。同じ記録が二重に登録されたり、送ったつもりで消えたりしないよう、記録1件ごとに固有の番号を持たせ、 サーバーの返事に自分の記録が載るまで端末側のデータを消さない作りにした。

どういう場面で使うか

朝、現場に向かう前にスマホで「今日の巡回」を開くところから始まる。今日行く公園と、先に見ておくべきもの(直近の判定がＤの木、まだ対応していない指摘)が先頭に出る。

公園に着いたら巡回の記録を1件付ける。天気を選び、気づいたこと(遊具の破損、倒木のおそれ、フェンスの破損など)を登録する。手袋のまま片手で押せるよう、タップ対象は56px以上、長押し・スワイプ削除は全面禁止、選択状態は太枠＋塗り＋チェックの3重表現にしている(直射日光下では色相が飛ぶため色だけに頼らない)。

樹木の点検が必要なときは、その木を選んで点検票を付ける。事務所に戻ったらPCで「報告資料」を開き、提出する形にまとめる。電波が悪くて送れていない記録は「未送信」の画面で確認できる。

自動化されているポイント

外観13項目と活力度を入れると、総合判定(Ａ〜Ｄ)が指針の規則に沿って自動で出る。判定表を見ながら人が考える必要がない
「今日の巡回」画面が、曜日ごとの巡回予定から今日行く公園を自動で出す。あわせて直近の判定がＤの木と未対応の指摘を自動で先頭に集める。朝いちばんに見る順番になっている
電波が無い場所での記録が自動で端末に保存され、電波が戻ると自動で送信される。現場の人は送信を意識しなくてよい
同じ記録の二重登録を自動で防ぐ(記録1件ごとの固有番号で判別)。同時に、送信が確認できるまで端末のデータを消さないので、記録が消える方向の事故も起きない
判定Ｃ・Ｄを付けた項目は、所見の入力が自動で必須になる。「要注意と書いたのに理由が無い」記録が残らない
提出済みの記録の書き換え・削除をDB側で自動的に拒否する
報告資料は期間と公園を選ぶだけで自動集計され、印刷／PDF保存とCSV書き出しができる

使い方(画面の流れ)

①朝いちばんに開く「今日の巡回」。見るべき順に情報が並ぶ。

今日の巡回画面(架空データ)

上に今日の件数と進捗、その下の「先に見るもの」に直近の判定がＤの樹木とまだ対応していない指摘が集まる。さらに下に今日行く公園が並ぶ。「記録はログイン中の『demo』として残ります」と、誰の名前で記録されるかが最初に明示される。

②現場の記録画面。手袋のまま片手で押せる大きさにしている。

現場スマホでの巡回記録画面(架空データ)

公園の選択はプルダウンではなく大きなボタン。天気もアイコン付きの4択で、キーボードを出さずに済む。巡回者は「ログイン中の利用者として記録します。氏名の打ち替えはできません」と固定されている。必要な入力が欠けている間は保存ボタンが押せず、その理由(「公園を選んでください」)が直上に出る。ボタンの下には「この端末に保存します。電波が戻ったら自動で送ります」と書かれている。

③樹木台帳。公園ごと・判定ごとに絞り込め、出典と免責が画面に常設されている。

樹木台帳画面(架空データ)

樹種・位置・植栽年・最終点検日・総合判定が一覧になり、Ａ:健全／Ｂ:経過観察／Ｃ:要注意／Ｄ:緊急対応が色と文字の両方で区別される。下部に「本記録は指針に基づく外観目視点検の結果であり、樹木医等による精密診断に代わるものではありません」という免責と、出典(国土交通省「都市公園の樹木の点検・診断に関する指針(案)」(令和8年3月30日改訂))、様式バージョンが必ず表示される。

④事務所で作る報告資料。期間と公園を選ぶと自動で集計される。

報告資料画面(架空データ)

巡回回数・指摘件数・未対応の指摘・樹木点検票の枚数・判定Ｃ／Ｄの件数が集計され、公園別の実施状況(巡回・清掃・散水・異常あり・指摘・未対応)が表になる。印刷／PDF保存のほか、巡回のCSVと点検票のCSVを書き出せる。

訴求ポイント

提出した記録が後から争えない形になっていること。「未入力を自動でＡ(健全)で埋めない」「提出済みは書き換えられない」「判定を上書きしたら理由と実行者と時刻が必ず残る」を、アプリの画面ではなくDBの制約として実装している。事故後に記録の正当性を問われたとき、改ざんされていないことを構造で説明できる
既存の公園樹木点検向けサービスはタブレット前提で、準拠様式も一世代前のものが見受けられる。こちらは最新の改訂版様式に合わせ、スマホでの片手入力とオフラインを前提にしている。様式が新しいことは発注者側への説明材料になる
手袋のまま片手で押せる操作(56px以上のボタン、長押し・スワイプ削除の全面禁止、キーボードを出さない定型選択、色だけに頼らない選択表現)は、実際の現場を前提にしないと出てこない仕様
電波の無い公園での記録が、二重にも欠落にもならない設計になっている。「送ったつもりで消えた」が起きない
ID数で課金しない前提なので現場の全員に配れる。この種のツールが定着しない典型が「ID課金で全員に配れず、結局紙に戻る」

現時点でやっていないこと