(事例) 公共部門・教育・Polish 3D / Polish AI / Polish+

教師が単一のプラットフォームで施設を検索し、授業の行程計画を完結

台湾全土の教師が野外学習の行程を組む際には、各施設の情報を検索して相互に比較する必要があります。このプラットフォームは台湾全土の野外教育施設を統合し、教師が地図上で施設を探し、距離を見積もり、授業の行程を計画できるようにします。

最初の打ち合わせを予約

教師が単一のプラットフォームで施設を検索し、授業の行程計画を完結
業種
公共部門・教育
サービス
Polish 3D、Polish AI、Polish+
規模
5施設からスタートし、直近では週60以上の施設が参加

(課題)

施設情報が複数のシステムに分かれており、行程の計画には統合した検索が必要

教師が野外学習の行程を組むには、校務の合間に時間を確保し、各種施設の情報を検索して繰り返し比較し、ほかの教師の経験や評判も参考にして、ようやくその施設が適しているかを判断できます。

このプラットフォームは、もともとデータの構築と管理に開発の重点を置いていました。各県市にはそれぞれ野外教育のデータがあり、教師は行程を一つ計画するのに複数のシステムを切り替えて検索する必要があったため、検索と活用の流れの統合が今回の対象でした。

プラットフォームの入口ページの刷新前後の比較。
プラットフォームの入口ページの刷新前後の比較。

(アプローチ)

商用プラットフォームに学び、地図を探索ツールに変える

教師への段階的なインタビューを重ねた結果、野外学習のリソースは従来の行楽施設に限らないことが分かりました。文史館、生態系の現場から地域の小さな店まで、行程に教育的な意義があれば、いずれも適した学習リソースになり得ます。

チームは商用の旅程作成サイトを研究し、現場の教育関係者にもインタビューして、要件を整理しました:教師は、その場所で何を教えるのに適しているのか、学校からどれくらい近いのかを知りたい。過剰な詳細(高速道路でのアクセス方法など)はかえって情報を複雑にする。施設の検索と選定は、ネットでホテルを予約するように簡単でなければならない。

そのため、ユーザーが見て回りやすく、探しやすい、高度にカスタマイズされたインタラクティブマップに重点を置きました。

PC版の録画:単一の県市まで絞り込み、学びの場をクリックして、左欄で向いている教育内容と距離を確認。

(設計の要点)

三つの設計ポイント

インタラクティブマップ

ユーザーは地図サービスを使う感覚で、近隣の学習施設を簡単に見つけて保存でき、自分の野外学習の計画経験もアップロードして共有し、教育現場の状況や対処法を話し合えます。博物館や農場などの施設提供者は、自らイベント情報を掲載して参考に供することができます。

ルート体験:地図上に行程のルートを表示し、左側に施設情報を表示します。
ルート体験:地図上に行程のルートを表示し、左側に施設情報を表示します。

デスクトップ

リストと地図を並べて表示、絞り込みはすぐに反映

施設リストとインタラクティブマップが並んで表示され、テーマ、季節、設備、開放時間、料金、交通、学齢で絞り込むと、リストと地図上の施設も合わせて更新されます。地図を拡大すると、まとまった数字が少しずつ個別の施設へと展開され、画面右下の専用の動物キャラクターがリアルタイムのサポート窓口になっています。

デスクトップの画面録画:施設リストのスクロール、テーマと季節による絞り込み、インタラクティブマップの拡大縮小。

専用キャラクター

プラットフォームのイメージとして、動物をモチーフにした専用キャラクターのシリーズを設計しました。家族みんなで親しめるキャラクターで、欧米や日本などの野外教育分野の成功事例を参考にし、観光PRと施設の展示の両方に使えるよう配慮しています。陸の教育を代表する山林の生き物と、海洋教育を象徴する海の生き物では、筆致、スタイル、体のデザインをそれぞれ作り分けました。

デザイン要素:施設カード、月の切り替え、キャラクター。
デザイン要素:施設カード、月の切り替え、キャラクター。

ブロック式のモジュール

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

会員システムの個人ページ。
会員システムの個人ページ。

(納品・検収)

検収は要件定義書に基づいて行い、運用保守の記録を残します

所管官庁の要求に沿ったスキャン、中・高リスクの修正、誤検知の申し立てに対応し、設計入札から実装入札へと引き継ぎます。

文書名と数量は一字一句そろえてから、見積もりと分担を話し合います。

検収の根拠は要件定義書にあるため、双方の分担は要件定義書の一字一句の整理から始めます。
要件と見積もり
履行と運用保守
検収
機関
開発チーム
1
機関要件定義書に記載された文書名称、数量、形式
2
開発チーム一字一句リストに書き写す構想と照合し、3つの欄すべてに記載がないものは範囲外とする
3
機関監督し、定期的に監査する施行細則第7条
4
開発チームスクリプトで運用保守ファイルを生成整合性、ログ、月報
5
機関初回検収と正式検収検収記録を残す
6
開発チーム文字どおりの名称と数量で提出文書の義務は独立した項目として記載

政府調達法、施行細則、情報セキュリティ法規の委託規定に基づき整理

全文を読む 公共部門プロジェクトの納品・運用の証拠:要求仕様書、確認条文、読み取り専用スクリプト

所管官庁のスキャンに合わせ、開発チームが判読と修正を行います。

スキャン結果は2つに分ける:誤検知は項目ごとに異議申し立て、中・高リスク項目は開発チームが修正します。
  1. ホスト脆弱性スキャンスキャン結果を取得
  2. 人による判読スキャナーの誤検知率が高い
  • 誤検知の項目
    異議申し立て1件ずつ対応
  • 中・高リスク項目
    修正開発チームが担当
全文を読む 脆弱性スキャンとペネトレーションテストの違い

要件定義書と情報セキュリティ上の義務があるプロジェクトは、初回ミーティングで範囲を項目ごとに照合できます。

(成果)

施設は5件からスタートし、直近では週60以上が参加

プラットフォームの立ち上げ当初に入居した施設は、5件だけでした。プラットフォームの整備が進み、教師から設計へのフィードバックが続くなかで、参加度とデータのアップロード量は明らかに増え、直近では週60以上の施設が参加するまでになりました。

プロジェクトには複数の部門と複雑な意思決定の階層が関わり、所管機関と共に新しい働き方を導入しました。メッセージは追跡・分類が可能なコラボレーションプラットフォームでやり取りし、文書はオンラインで共同編集できる形式に全面的に切り替えました。さらにタスクカードを作成し、変更・開発・調整の進捗が一目で分かるようにしています。

これによりコミュニケーションの効率とコラボレーション文化が向上し、協力関係も、外部委託先からプラットフォームのパートナーチームへと変わりました。

プラットフォームのスマートフォン版:マップ、施設ページ、月の切り替え。
プラットフォームのスマートフォン版:マップ、施設ページ、月の切り替え。

スマートフォン

スマートフォンはリストが中心、地図は必要なときに展開

スマートフォンではまずリストで施設を見て、「地図表示」を押すと全画面の地図が開きます。施設のまとまり、名称ラベル、カテゴリーのアイコンは拡大縮小に合わせて更新され、左下の「返回列表」でいつでもリストへ戻れます。

スマートフォンの画面録画:リストから全画面の地図を開き、拡大縮小とドラッグを行う。
スマホの録画:地図と一覧を必要に応じて展開。

(工程記録)

手法と実測、カードごとに展開

脆弱性スキャンとペネトレーションテストの違い

脆弱性スキャンは可能性のある問題を洗い出し、ペネトレーションテストは到達できる範囲を確認します。
脆弱性スキャンは可能性のある問題を洗い出し、ペネトレーションテストは到達できる範囲を確認します。

脆弱性スキャン

  • システムの識別OS、アプリケーション、開放ポート
  • 既知の脆弱性データベースと照合古いバージョン、修正の未適用、設定ミス
  • リストを作成誤検知率が高いため、人による判読が必要
スキャン結果

ペネトレーションテスト

  • 侵入可能な対象を特定多くの場合、脆弱性スキャンの結果から始める
  • 複数の脆弱性を連結実際の攻撃を模擬
  • どこまで到達できるか確認どの程度の権限を取得できるか、防御側が検知できるか

NIST SP 800-115 に基づき意訳してまとめています。

全文を読む
法規で定められた検査頻度
責任レベル脆弱性スキャンペネトレーションテスト
A 級すべての中核情報通信システムを毎年2回実施すべての中核情報通信システムを毎年1回実施
B 級すべての中核情報通信システムを毎年1回実施すべての中核情報通信システムを2年に1回実施
C 級すべての中核情報通信システムを2年に1回実施すべての中核情報通信システムを2年に1回実施
全文を読む

公共部門プロジェクトの納品・運用の証拠:要求仕様書、確認条文、読み取り専用スクリプト

運用保守のチェックには周期があり、毎週2項目、毎月1項目です。
運用保守のチェックには周期があり、毎週2項目、毎月1項目です。
毎週実行毎月作成
1か月目2か月目
  • 整合性チェック
    毎週、前週と比較
  • ログ集計
    毎週、直近1週間分を集計
  • システム月次レポート
    毎月1件

ソースに記載された周期の3項目のみを描画しています。ディスク使用量の警告はしきい値で発動し、復旧訓練は本文で扱うため、いずれも図には含めていません。位置は頻度の目安のみを示します。

全文を読む
所管官庁のスキャンと異議申し立てに対応

脆弱性スキャンレポートを受け取った後:修正の優先順位、誤検知への異議申立て、再テスト

スキャンと再テストは第三者、分類と修正は開発チーム、発注者は中間で確認を行います。
スキャンと再テストは第三者、分類と修正は開発チーム、発注者は中間で確認を行います。
報告書
分類
修正
再テスト
第三者
発注者
開発チーム
1
第三者スキャンと検査を実施し、報告書を発行要件を満たす第三者が実施
2
発注者報告書を受領し、開発チームに引き渡す
3
開発チーム1件ずつ再現し、真の問題と誤検知に分ける各項目に理由を付記
4
発注者分類結果と異議申し立ての内容を確認
5
発注者今回の範囲と、今回は修正しない項目を確認
6
開発チーム悪用可能性の高い順に修正修正前後の比較を保存
7
第三者再テストし、各項目の合否を判定
8
開発チーム各項目の修正内容を説明し、証拠を提出

役割分担の概略図。実際の分担は各プロジェクトの契約と機関の要求によって決まります。

全文を読む
まず本物かどうかを確認し、次に悪用可能かを判断します。各発見事項は必ず以下の3つのいずれかに振り分けられます。
まず本物かどうかを確認し、次に悪用可能かを判断します。各発見事項は必ず以下の3つのいずれかに振り分けられます。
  1. この発見事項を再現テスト環境で、報告書に記載されたリクエストを再送
  2. システムの実際の設定と照合バージョン、パス、既存の緩和策が報告書と一致するか
  • 再現可能で、外部から直接悪用できる
    直ちに修正修正前後のリクエストとレスポンスの比較を保存
  • 再現可能だが、特定の前提条件が必要、または既に緩和策がある
    次回に組み込む前提条件と後回しにした根拠を記録
  • 再現できない、またはシステムの実際の設定と一致しない
    誤検知の異議申し立てを提出再現手順と設定の証拠を添付
全文を読む

ソフトウェア外注ベンダー評価表と契約前の確認事項

想定機能一覧は最後に確認し、範囲は項目ごとの照合で確定します。 関連する手法
想定機能一覧は最後に確認し、範囲は項目ごとの照合で確定します。
順に読む
項目ごとに照合
結果
顧客データ
開発チーム
1
顧客データ義務書類顧客の第三者に対する義務と監査条項
2
顧客データ既存システム
3
顧客データ想定機能一覧通常は妥当な範囲より1.5〜3倍大きくなる
4
開発チーム項目ごとに照合要求の有無、見積もりに含まれるか
5
開発チーム範囲外へ移動両方に含まれない項目
全文を読む
セキュリティと運用保守を監査:実績、再テスト記録、SLA を順に確認 関連する手法
セキュリティと運用保守を監査:実績、再テスト記録、SLA を順に確認
  1. 同種プロジェクトの実績規模と担当した役割
  2. スキャンと再テストの記録検出事項の修正方法
  3. SLA を契約に明記
  • 3項目すべてが一致
    見積もり比較に進む
  • 記録を提示できない
    ベンダーに補足書類の提出を依頼

SLA の内容はプロジェクトごとに取り決め、重要なのは契約に明記することです。

全文を読む
評価表:各行をベンダーに確認 関連する手法

既存システム引き継ぎのための全コード診断:候補の洗い出しから納品可能なレポートまで

候補となる問題は約70件。反証の結果、約1割が棄却され、残りは報告書に記載されます。 関連する手法・数字は他プロジェクトの実績
候補となる問題は約70件。反証の結果、約1割が棄却され、残りは報告書に記載されます。
  1. 候補となる問題約70件7つの観点で並行してスキャンし、統合後、1件ずつコードに照らして検証
  2. 反証の際に棄却約1割その多くは、以前の担当者があえて残したパッチです。
  3. 報告書に記載約60件赤、黄、緑に分類

1回の完全なヘルスチェック。数値は概算値です。

全文を読む
各発見事項は行き先を判定すること:直ちに修正、計画的に修正、または残して記録 関連する手法
各発見事項は行き先を判定すること:直ちに修正、計画的に修正、または残して記録
  1. コードに照らして検証問題が確かに存在することを確認
  2. あえて反証を探す以前の担当者があえて残したパッチかどうかを確認
  • 人に危害を与える、データが失われる、または攻撃を受ける
    直ちに修正赤として記載し、修正担当者と見積もり時間を明記
  • リスクはあるが、赤には至らない
    計画的に修正黄として記載し、引き継ぎ後の運用保守に組み込む
  • 欠陥に見えるが、確認の結果、意図的なパッチ
    残して記録分解できない理由を記載し、後任者の誤った修正を防ぐ
全文を読む
1か月目は現状を把握し、赤を優先して対応。既存の問題は作り直さない 関連する手法
1か月目は現状を把握し、赤を優先して対応。既存の問題は作り直さない
引き継ぎ前
ヘルスチェック
赤
新規プログラム
顧客
開発チーム
1
顧客データの準備ソースコードまたはそのアクセス権、現在のデプロイ方法、直近半年に発生した問題
2
開発チームスキャン、検証、反証7つの観点で並行スキャンし、1件ずつコードに照らして検証、さらにあえて反証を探す
3
顧客報告書を読み、順序を決める修正担当者と見積もり時間は、いずれも赤の項目に記載
4
開発チーム赤を先に修正各修正に、壊れた場合に失敗するチェックを1つ付ける
5
開発チーム新規プログラムはルールを遵守パラメータ化クエリ、所有者チェック、コールバックの署名検証

段階は順序を示すもので、固定日数ではありません。

全文を読む

(Client note)

屋外教育リソースプラットフォームは、POLISH のチームにサイト構築を支援してもらえて幸運でした。過程ではさまざまなツールを活用し、一歩ずつ私たちを導きながら議論し、問題を整理してくれました。特に安心できたのは、表面的な状況への対応にとどまらず、丁寧な議論と分析を通じて私たちを核心の問題へ導いてくれたことです。だからこそ、現在の満足のいくプラットフォームを順調に公開できました。
LaiPlatform PO・NUTC

初回ミーティング(15〜30分)で、手法の方向性、予算帯、スケジュール案を確認できます。

Polish 3DPolish AIPolish+次のプロジェクト:棟・階・住戸から室内の360度まで、1本の内覧ルートに

(お問い合わせ)

Start a project.

三つのステップで、判断に足る進め方と予算帯が得られます。

  1. 01最初の打ち合わせを予約:時間を選びます。完全な仕様は不要です。
  2. 02オンライン相談(15〜30分):進め方の方向性、予算帯、スケジュール案を提示。
  3. 03素材を確認したうえで、約3〜5営業日で見積書兼納品仕様明細書を提出します。
メール
hello@polish-design.com.tw
郵送先住所
(104) 台湾 台北市 中山区 植福路191-1号 3F

最初の打ち合わせを予約

平日 16:00〜18:00オンライン30分

先に時間帯を選び、Google アカウントまたはメールアドレスで確認します。予約が確定するとカレンダーに追加できます。

時間を選ぶ

または、先に内容を送信

まだ時間を決めていない場合は、先にプロジェクトの内容をお送りください。担当者がメールで返信します。送信後に続けて予約することもできます。

補足情報(任意):サービス項目、現在のフェーズ、既存リンク、知ったきっかけ

入力内容は、今回のプロジェクト評価にのみ使用します。

ISO/IEC 27001:2022 認証書

(Certificate)

ISO/IEC 27001:2022

認証機関
ARES International Certification
認証範囲
インタラクティブ没入型3Dシステムの開発プロセス、ならびにネットワークおよびインフラの運用・管理。

認証機関サイトで確認