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

1 全体像と目的

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

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

設計で大切にしたいこと

地域の「テーマ」と、生徒の「探究プロジェクト」を分けます。テーマは地域側が登録する課題、サブテーマはそこから生徒が切り出す問いの単位で、一つのサブテーマを一つのチームが担当します。この「サブテーマ×チーム」の活動単位を探究プロジェクトと呼びます。一つのテーマに複数のサブテーマを紐づけ、同じ課題に異なる視点から取り組める構造を想定します。

調査を進めるうちに、問いが元のテーマから離れることもあります。テーマとの紐付けは履歴として残したうえで、紐付けの変更や、テーマに紐づかない探究も認める案です。

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

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

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

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

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

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

Aチームの進め方の例

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

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

地域との接点

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

3 主な機能と使い方

テーマバンク

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

あわせて、質問への返答の目安（例　二週間以内、週に一度まとめて）をテーマオーナーに示してもらい、生徒と教員が見られるようにします。一つのテーマに複数チームが紐づくため、既に出た質問と回答はテーマ単位で共有し、重複した問い合わせを減らします。返答が届かない場合にも進められるよう、調査計画には地域への質問以外の方法も併せて用意します。

探究ワークスペース

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

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

取材先と、氏名・発言・写真を記録や発表に載せてよいかの確認状況も残せるようにします。

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

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

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

テーマオーナーへの連絡は、本体内のお知らせに加えてメールなど確実に届く手段を用意し、未回答の質問が滞らないようにします。

教員ダッシュボード

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

成果アーカイブ

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

4 公開範囲と役割の案

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

地域側の画面では、生徒を実名ではなくチーム名と表示名で示す案です。実名の共有は校内に限ります。生徒と地域の人が一対一で個別にやり取りする機能は設けず、質問と回答は担当教員が把握できる場所に残します。

運用開始前に決めること

生徒の氏名・顔写真・連絡先・インタビュー内容の扱い、本人や保護者等への説明と必要な同意を整理します。取材先がテーマオーナー以外の場合も、氏名・発言・写真を記録や発表に載せてよいかを確認し、その記録を残します。保存期間・削除・卒業時の引継ぎに加え、生徒が自分の記録を卒業後に持ち出せるかも決めます。地域との連絡は教員が把握できる場で行い、不適切な投稿や困りごとの相談窓口も決めます。

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

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

初期に備える機能は、6章「試行で確かめたいこと」と対応させています。とくに問いをどう更新したかを後から振り返れるよう、問い・仮説の版と変更理由を残すことを中心に置きます。ToDoや発表日程、年度別のアーカイブは、既存の手段で代替できるか、初年度に必要かを試行のなかで判断します。

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

初回の試行では既存システムとの自動連携を行わないため、記録の一部が現在の手段と重なります。どの作業を止められるかを学校と決めたうえで、記録する範囲を絞ります。

4月開始の年間例

時期・授業時数は例示です。行事・考査・地域の繁忙期に合わせて調整し、夏季の活動を必須とせず、授業時間内でも実施できる計画にします。テーマの募集と受入条件の調整には数か月かかるため、前年度のうちに着手する想定です。11〜1月は考査や進路と重なるため、この期間の活動量は学校と相談して決めます。

この年間例は1〜2年生での実施を想定しています。3年生を対象とする場合は、進路日程に合わせて期間を短くする必要があります。

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

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

初回に伺いたいこと

次回以降に整理したいこと

試行で確かめたいこと

生徒が問いを更新した理由を説明できるか、必要な支援につながったか、記録と連絡の負担が許容できるか、地域側が継続して関われるかを振り返ります。負担の変化を比べられるよう、導入前の記録・連絡の手順と所要時間も事前に把握しておきます。利用件数だけで判断せず、授業観察・記録・聞き取りを合わせ、継続・修正・終了を協議します。

打ち合わせ後の進め方

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