といまち toimachi — まちと出会い、問いが育つ。

1 全体像と目的

地域の個人・団体・企業が「テーマオーナー」として、取り組みたい課題や知りたいことを登録します。生徒は関心に合うテーマを選び、サブテーマごとのチームで探究します。活動記録、対話、予定、成果を一つの場所につなぎます。

目的は、生徒が実社会と関わりながら、自分たちで問いを立て、根拠を集め、考えを更新する経験を支えることです。学校には学習過程を見渡す手がかりを、地域には若者と継続して対話する接点を提供します。

設計で大切にしたいこと

地域の「テーマ」と、生徒の「探究プロジェクト」を分けます。一つのテーマに複数のサブテーマ・チームを紐づけ、同じ課題に異なる視点から取り組める構造を想定します。

問い → 仮説 → 調査 → 発見 → 問いの更新を繰り返します。仮説が外れたこと、問題の捉え方が変わったことも成果として残します。解決策や事業化への到達は一律の必須条件にしません。

学校の既存の授業設計を起点に、必要な部分から取り入れる想定です。上記の効果は試行で確かめます。

2 テーマから成果蓄積までの流れ

地域のテーマオーナーが課題・背景・協力できる内容を登録
↓ 学校・運営が授業との適合性や受入条件を確認
テーマバンクから生徒が関心のあるテーマを選択
↓ サブテーマを設定し、チームごとにプロジェクトを開始
問い → 仮説 → 調査・フィールドワーク → 分析・発見
　　　　　　　　　↖ 問いと仮説を更新 ↙
↓ 中間発表で教員・地域からコメントを受け、追加調査
最終発表 → 振り返り → 地域への共有 → 成果アーカイブ

図は標準的な流れの案です。順序を固定せず、活動途中の問い直しやテーマの見直しを支えます。

一つのテーマから複数の探究へ

Aチームの進め方の例

問いは「高校生が商店街に行かないのはなぜか」。仮説は「店舗情報が届いていないから」。事前調査、生徒へのアンケート、店舗へのインタビュー、現地観察を組み合わせます。

調査で「営業時間と帰宅時間が合わない」可能性が見えたら、問いや調査方法を更新します。中間発表では根拠と未確認点を示し、最終発表では分かったこと・限界・次の問いを共有します。

地域との接点

テーマ説明、質問への回答、現地調査の協力、中間・最終発表へのコメントを想定します。すべてへの参加を必須とせず、協力可能な時期と負担を調整します。訪問は学校の手順に沿って事前に計画します。

3 主な機能と使い方

テーマバンク

テーマ名、課題の背景、これまでの取組、知りたいこと、関連資料、テーマオーナーの紹介を登録します。インタビュー・現地調査の可否、受入時期、協力可能なチーム数、高校生へのメッセージも示し、生徒が選びやすくします。公開前に学校・運営が内容を確認する案です。

探究ワークスペース

チームごとのページに、現在の問い・仮説・活動段階・次の締切を表示します。調査計画、活動記録、資料、質問・コメント、担当と期限のあるToDo、中間・最終発表資料をまとめます。問いや仮説を変えた理由も残します。

活動記録は「実施したこと／得られた根拠／考えたこと／次にすること」を基本に、短く続けられる形を検討します。チーム記録に加え、個人の振り返りを設け、学びへの関わりを見取れるようにします。

LINEは通知　本体はプラットフォーム

質問・回答、資料、活動記録の保存先はプラットフォームに統一します。LINEは更新や締切を知らせ、該当ページへ案内する補助的な入口とします。通知本文に生徒の個人情報や調査内容を載せない案です。

LINEの利用を必須にせず、本体内のお知らせや学校で認められた連絡手段でも確認できるようにします。利用対象、通知時間、連携方式は学校の方針を確認して決定します。

教員ダッシュボード

担当するクラス・チームを一覧し、現在の問い、最終更新、期限、未回答の質問、相談の有無を確認します。更新が止まったチームへの声かけに使い、投稿数や進捗率だけで学習の質を判断しない運用を想定します。評価項目や面談記録との関係は学校と設計します。

成果アーカイブ

年度、テーマ、問い、調査方法、分かったこと、限界、提案、次の問い、発表資料を蓄積します。地域への還元と次年度の参考に使います。成果として共有する版を活動中の記録から分け、公開する範囲を確認して保存します。

4 公開範囲と役割の案

活動中の情報は関係者に限定することを出発点にします。「参加できること」と「すべての情報を見られること」を分け、テーマ・プロジェクト単位で権限を設定する案です。

運用開始前に決めること

氏名・顔写真・連絡先・インタビュー内容の扱い、本人や保護者等への説明と必要な同意、引用・写真等の利用確認、保存期間・削除・卒業時の引継ぎを整理します。地域との連絡は教員が把握できる場で行い、不適切な投稿や困りごとの相談窓口も決めます。

5 小規模試行と年間授業フロー例

MVPは、授業で一連の探究を試すための最小限の機能です。例えば1校・1学年の一部、少数のテーマとチームから始め、対象人数・期間は学校と決めます。

最初は手動調整も活用し、テーマ募集やチーム編成をすべて自動化する前提にしません。LINE連携が初回試行に不可欠かは、連絡方法を確認して判断します。

4月開始の年間例

時期・授業時数は例示です。行事・考査・地域の繁忙期に合わせて調整し、夏季の活動を必須とせず、授業時間内でも実施できる計画にします。

6 学校側と確認したい論点

初回は、教育上のねらい、現状の負担、試せる範囲を優先して伺います。機能の採否は、その条件が見えてから一緒に絞り込みます。

試行で確かめたいこと

生徒が問いを更新した理由を説明できるか、必要な支援につながったか、記録と連絡の負担が許容できるか、地域側が継続して関われるかを振り返ります。利用件数だけで判断せず、授業観察・記録・聞き取りを合わせ、継続・修正・終了を協議します。

打ち合わせ後の進め方

学校の条件を整理 → 対象授業とテーマ候補を選ぶ → 画面・記録様式の簡単な試作を確認 → 小規模試行 → 教員・生徒・地域で振り返る、という順を想定します。開発範囲・日程はこの確認を踏まえて具体化します。