(事例) 公共部門・教育・Polish 3D / Polish AI / Polish+
教師が単一のプラットフォームで施設を検索し、授業の行程計画を完結
台湾全土の教師が野外学習の行程を組む際には、各施設の情報を検索して相互に比較する必要があります。このプラットフォームは台湾全土の野外教育施設を統合し、教師が地図上で施設を探し、距離を見積もり、授業の行程を計画できるようにします。

(課題)
施設情報が複数のシステムに分かれており、行程の計画には統合した検索が必要
教師が野外学習の行程を組むには、校務の合間に時間を確保し、各種施設の情報を検索して繰り返し比較し、ほかの教師の経験や評判も参考にして、ようやくその施設が適しているかを判断できます。
このプラットフォームは、もともとデータの構築と管理に開発の重点を置いていました。各県市にはそれぞれ野外教育のデータがあり、教師は行程を一つ計画するのに複数のシステムを切り替えて検索する必要があったため、検索と活用の流れの統合が今回の対象でした。

(アプローチ)
商用プラットフォームに学び、地図を探索ツールに変える
教師への段階的なインタビューを重ねた結果、野外学習のリソースは従来の行楽施設に限らないことが分かりました。文史館、生態系の現場から地域の小さな店まで、行程に教育的な意義があれば、いずれも適した学習リソースになり得ます。
チームは商用の旅程作成サイトを研究し、現場の教育関係者にもインタビューして、要件を整理しました:教師は、その場所で何を教えるのに適しているのか、学校からどれくらい近いのかを知りたい。過剰な詳細(高速道路でのアクセス方法など)はかえって情報を複雑にする。施設の検索と選定は、ネットでホテルを予約するように簡単でなければならない。
そのため、ユーザーが見て回りやすく、探しやすい、高度にカスタマイズされたインタラクティブマップに重点を置きました。
(設計の要点)
三つの設計ポイント
インタラクティブマップ
ユーザーは地図サービスを使う感覚で、近隣の学習施設を簡単に見つけて保存でき、自分の野外学習の計画経験もアップロードして共有し、教育現場の状況や対処法を話し合えます。博物館や農場などの施設提供者は、自らイベント情報を掲載して参考に供することができます。

デスクトップ
リストと地図を並べて表示、絞り込みはすぐに反映
施設リストとインタラクティブマップが並んで表示され、テーマ、季節、設備、開放時間、料金、交通、学齢で絞り込むと、リストと地図上の施設も合わせて更新されます。地図を拡大すると、まとまった数字が少しずつ個別の施設へと展開され、画面右下の専用の動物キャラクターがリアルタイムのサポート窓口になっています。
専用キャラクター
プラットフォームのイメージとして、動物をモチーフにした専用キャラクターのシリーズを設計しました。家族みんなで親しめるキャラクターで、欧米や日本などの野外教育分野の成功事例を参考にし、観光PRと施設の展示の両方に使えるよう配慮しています。陸の教育を代表する山林の生き物と、海洋教育を象徴する海の生き物では、筆致、スタイル、体のデザインをそれぞれ作り分けました。

ブロック式のモジュール
システムは、再利用可能なモジュールに分割しています:複数ロールのログインと権限システム、リアルタイムで更新されるインタラクティブマップのテンプレート、自動化されたデータエディター(数百件のデータを一度にアップロードし、形式を自動チェック)、そして公文書業務とアジャイル開発を組み合わせたワークフロー。要件が変わった場合は、優先順位に従ってモジュールを調整・デプロイするだけで済み、コミュニケーションの時間と開発コストを削減できます。

(納品・検収)
検収は要件定義書に基づいて行い、運用保守の記録を残します
所管官庁の要求に沿ったスキャン、中・高リスクの修正、誤検知の申し立てに対応し、設計入札から実装入札へと引き継ぎます。
文書名と数量は一字一句そろえてから、見積もりと分担を話し合います。
政府調達法、施行細則、情報セキュリティ法規の委託規定に基づき整理
所管官庁のスキャンに合わせ、開発チームが判読と修正を行います。
- ホスト脆弱性スキャンスキャン結果を取得
- 人による判読スキャナーの誤検知率が高い
- 誤検知の項目異議申し立て1件ずつ対応
- 中・高リスク項目修正開発チームが担当
要件定義書と情報セキュリティ上の義務があるプロジェクトは、初回ミーティングで範囲を項目ごとに照合できます。
(成果)
施設は5件からスタートし、直近では週60以上が参加
プラットフォームの立ち上げ当初に入居した施設は、5件だけでした。プラットフォームの整備が進み、教師から設計へのフィードバックが続くなかで、参加度とデータのアップロード量は明らかに増え、直近では週60以上の施設が参加するまでになりました。
プロジェクトには複数の部門と複雑な意思決定の階層が関わり、所管機関と共に新しい働き方を導入しました。メッセージは追跡・分類が可能なコラボレーションプラットフォームでやり取りし、文書はオンラインで共同編集できる形式に全面的に切り替えました。さらにタスクカードを作成し、変更・開発・調整の進捗が一目で分かるようにしています。
これによりコミュニケーションの効率とコラボレーション文化が向上し、協力関係も、外部委託先からプラットフォームのパートナーチームへと変わりました。

スマートフォン
スマートフォンはリストが中心、地図は必要なときに展開
スマートフォンではまずリストで施設を見て、「地図表示」を押すと全画面の地図が開きます。施設のまとまり、名称ラベル、カテゴリーのアイコンは拡大縮小に合わせて更新され、左下の「返回列表」でいつでもリストへ戻れます。
(工程記録)
手法と実測、カードごとに展開
脆弱性スキャンとペネトレーションテストの違い
脆弱性スキャンは可能性のある問題を洗い出し、ペネトレーションテストは到達できる範囲を確認します。
脆弱性スキャン
- システムの識別OS、アプリケーション、開放ポート
- 既知の脆弱性データベースと照合古いバージョン、修正の未適用、設定ミス
- リストを作成誤検知率が高いため、人による判読が必要
ペネトレーションテスト
- 侵入可能な対象を特定多くの場合、脆弱性スキャンの結果から始める
- 複数の脆弱性を連結実際の攻撃を模擬
- どこまで到達できるか確認どの程度の権限を取得できるか、防御側が検知できるか
NIST SP 800-115 に基づき意訳してまとめています。
法規で定められた検査頻度
| 責任レベル | 脆弱性スキャン | ペネトレーションテスト |
|---|---|---|
| A 級 | すべての中核情報通信システムを毎年2回実施 | すべての中核情報通信システムを毎年1回実施 |
| B 級 | すべての中核情報通信システムを毎年1回実施 | すべての中核情報通信システムを2年に1回実施 |
| C 級 | すべての中核情報通信システムを2年に1回実施 | すべての中核情報通信システムを2年に1回実施 |
公共部門プロジェクトの納品・運用の証拠:要求仕様書、確認条文、読み取り専用スクリプト
運用保守のチェックには周期があり、毎週2項目、毎月1項目です。
- 整合性チェック毎週、前週と比較
- ログ集計毎週、直近1週間分を集計
- システム月次レポート毎月1件
ソースに記載された周期の3項目のみを描画しています。ディスク使用量の警告はしきい値で発動し、復旧訓練は本文で扱うため、いずれも図には含めていません。位置は頻度の目安のみを示します。
脆弱性スキャンレポートを受け取った後:修正の優先順位、誤検知への異議申立て、再テスト
スキャンと再テストは第三者、分類と修正は開発チーム、発注者は中間で確認を行います。
役割分担の概略図。実際の分担は各プロジェクトの契約と機関の要求によって決まります。
まず本物かどうかを確認し、次に悪用可能かを判断します。各発見事項は必ず以下の3つのいずれかに振り分けられます。
- この発見事項を再現テスト環境で、報告書に記載されたリクエストを再送
- システムの実際の設定と照合バージョン、パス、既存の緩和策が報告書と一致するか
- 再現可能で、外部から直接悪用できる直ちに修正修正前後のリクエストとレスポンスの比較を保存
- 再現可能だが、特定の前提条件が必要、または既に緩和策がある次回に組み込む前提条件と後回しにした根拠を記録
- 再現できない、またはシステムの実際の設定と一致しない誤検知の異議申し立てを提出再現手順と設定の証拠を添付
ソフトウェア外注ベンダー評価表と契約前の確認事項
想定機能一覧は最後に確認し、範囲は項目ごとの照合で確定します。 関連する手法
セキュリティと運用保守を監査:実績、再テスト記録、SLA を順に確認 関連する手法
- 同種プロジェクトの実績規模と担当した役割
- スキャンと再テストの記録検出事項の修正方法
- SLA を契約に明記
- 3項目すべてが一致見積もり比較に進む
- 記録を提示できないベンダーに補足書類の提出を依頼
SLA の内容はプロジェクトごとに取り決め、重要なのは契約に明記することです。
既存システム引き継ぎのための全コード診断:候補の洗い出しから納品可能なレポートまで
候補となる問題は約70件。反証の結果、約1割が棄却され、残りは報告書に記載されます。 関連する手法・数字は他プロジェクトの実績
- 候補となる問題約70件7つの観点で並行してスキャンし、統合後、1件ずつコードに照らして検証
- 反証の際に棄却約1割その多くは、以前の担当者があえて残したパッチです。
- 報告書に記載約60件赤、黄、緑に分類
1回の完全なヘルスチェック。数値は概算値です。
各発見事項は行き先を判定すること:直ちに修正、計画的に修正、または残して記録 関連する手法
- コードに照らして検証問題が確かに存在することを確認
- あえて反証を探す以前の担当者があえて残したパッチかどうかを確認
- 人に危害を与える、データが失われる、または攻撃を受ける直ちに修正赤として記載し、修正担当者と見積もり時間を明記
- リスクはあるが、赤には至らない計画的に修正黄として記載し、引き継ぎ後の運用保守に組み込む
- 欠陥に見えるが、確認の結果、意図的なパッチ残して記録分解できない理由を記載し、後任者の誤った修正を防ぐ
1か月目は現状を把握し、赤を優先して対応。既存の問題は作り直さない 関連する手法
段階は順序を示すもので、固定日数ではありません。
顧客の目標を検収に組み込む:要件から成果指標まで
協業の初期に示した目標が、アンケート草案とテストタスクを経て、検収プレゼンテーションとテスト結果報告へとつながる報告書で引用するデータは、GA4で取れない部分を管理画面のアクセス分析とエクスポートした表で補う長期アウトソーシング協業の二つの軸:契約条項と関係的ガバナンス
契約に書かれていない事項は、性質に応じてそれぞれ対応する処理方法があるイベント終了後、分析とフィードバックをそれぞれ一往復させ、翌年度の計画へのインプットとする設計案件の入札から開発案件の入札へ:公共部門のプロジェクトはシステムの知見をどう引き継ぐか
既存システムのデータは、あらかじめ代替の取り出し方法を用意しておき、最悪の場合でも管理画面から表をエクスポートできる既成のリストがないときは、POLISHが先にルールを定め、プロジェクトチームが表にまとめ、POLISHが引き継いで処理する役に立つSLAの書き方:重大度の区分、未達成時の扱い、プロジェクトごとに取り決める目標
サービス目標に未達成時の扱いが明確に定められているかどうかで、SLAかSLOかが決まる見積書を契約前に二つの欄に分けておくと、以降の報告はどれも先に分類してから処理できるリリース後の定例運用保守:報告対応、定期点検、運用保守レポートの進め方
すべての報告に登録と担当者があり、同じ返信の中で完了とする毎月のレポートとスキャン、毎年のペネトレーションテストは、頻度が固定されており、それぞれ記録を残すリリース後に運用保守を続ける理由:ソフトウェアの進化、情報セキュリティ更新、技術的負債
リリース後の作業はまず定例作業と例外作業に分け、どちらも当月の運用保守レポートに書き込む毎月のサーバースキャンレポートの指摘事項は規定の期限までに修正し、対応内容の説明はプロジェクトチームが所管機関に報告する(Client note)
屋外教育リソースプラットフォームは、POLISH のチームにサイト構築を支援してもらえて幸運でした。過程ではさまざまなツールを活用し、一歩ずつ私たちを導きながら議論し、問題を整理してくれました。特に安心できたのは、表面的な状況への対応にとどまらず、丁寧な議論と分析を通じて私たちを核心の問題へ導いてくれたことです。だからこそ、現在の満足のいくプラットフォームを順調に公開できました。
LaiPlatform PO・NUTC初回ミーティング(15〜30分)で、手法の方向性、予算帯、スケジュール案を確認できます。
Polish 3DPolish AIPolish+次のプロジェクト:棟・階・住戸から室内の360度まで、1本の内覧ルートに
(お問い合わせ)
Start a project.
三つのステップで、判断に足る進め方と予算帯が得られます。
- 01最初の打ち合わせを予約:時間を選びます。完全な仕様は不要です。
- 02オンライン相談(15〜30分):進め方の方向性、予算帯、スケジュール案を提示。
- 03素材を確認したうえで、約3〜5営業日で見積書兼納品仕様明細書を提出します。
- メール
- hello@polish-design.com.tw
- 郵送先住所
- (104) 台湾 台北市 中山区 植福路191-1号 3F




