エンジニア流・地方創生へのアプローチ
前回の自己紹介を読んでくださった方、ありがとうございます！
自己紹介で「AI駆動開発×地方創生」というテーマを掲げました。
自己紹介記事はこちら↓
そこで「エンジニア（非IT）として働いている」と書いたんですが、今日はもう少しエンジニアっぽい話をさせてください。
Webアプリ開発で身についた「考え方」
自己紹介で書きましたが、僕は副業でWebアプリを開発していた時期があります。
その経験で身についたのが、問題解決のアプローチ。
課題を分解する
仮説を立てる
小さく試す
結果を見て改善する
これ、ソフトウェア開発では「アジャイル開発」と呼ばれる手法に近いんです。
今日は、この「アジャイル」の考え方を地方創生に活かしたい、という話をします。
ウォーターフォールとアジャイル
ソフトウェア開発には、大きく2つの進め方があります。
ウォーターフォール型
最初に全体の計画を立てる
要件定義→設計→開発→テスト→リリースと順番に進む
途中で変更しにくい
大規模プロジェクト向き
アジャイル型
小さく作って、すぐに試す
フィードバックを受けて改善する
変化に柔軟に対応できる
要件が変わりやすいプロジェクト向き
どちらが良い・悪いではなく、状況によって使い分けるものです。
地方創生はどっち向き？
僕は、地方創生はアジャイル向きだと考えています。
理由はシンプル。
要件が変わりやすいから。
なぜ要件が変わりやすいのか
地方創生を進めていく中で、周囲の環境は常に変化し続けます。
人口動態の変化：若者の流出、高齢化の進行
経済環境の変化：産業構造、雇用状況
社会情勢の変化：コロナ禍でリモートワークが普及したように
テクノロジーの変化：AIやDXの進展
住民の意識の変化：何を求めているかは時代で変わる
5年前に立てた計画が、今も有効とは限らない。
むしろ、計画を立てている間に状況が変わることすらある。
ウォーターフォール的なアプローチの限界
従来の地方創生って、こんなイメージがあります（あくまで僕の印象）。
有識者が集まって会議
長期計画を策定（5年計画、10年計画）
予算を確保
計画通りに実行
数年後に効果検証
これ、ウォーターフォール型に近い。
もちろん、大きな予算を動かすには計画が必要です。
でも、こんな課題もあるんじゃないでしょうか。
計画策定に時間がかかりすぎる
途中で状況が変わっても軌道修正しにくい
失敗したときのダメージが大きい
若者の声が届きにくい（会議に呼ばれない）
アジャイル的なアプローチとは
僕が考えるアジャイル的な地方創生は、こんなイメージ。
1. 小さく始める
大きな計画を立てる前に、まず小さく試す。
イベントを1回開催してみる
SNSで発信して反応を見る
地元の人に話を聞いてみる
2. 仮説を持つ
「たぶんこうじゃないか？」という仮説を立てる。
「若者が帰ってこないのは、仕事がないからでは？」
「地元との接点が薄れるから、帰るきっかけがないのでは？」
3. 検証する
仮説を小さな実験で検証する。
実際に若者に聞いてみる
地元イベントに参加して観察する
データを集めて分析する
4. 改善する
検証結果をもとに、次のアクションを決める。
仮説が正しければ、もっと深掘りする
仮説が間違っていれば、別の仮説を立てる
5. サイクルを回す
これを繰り返す。
仮説→実行→検証→改善→仮説→…
変化に追従できる強さ
アジャイルの最大のメリットは、変化に追従できること。
環境が変わったら、すぐに方向修正できる。
失敗しても、小さく失敗するから致命傷にならない。
むしろ、失敗から学べる。
地方創生のように、答えがわからない領域だからこそ、この柔軟さが重要だと思うんです。
僕がやっていくこと
偉そうなことを書きましたが、僕もまだ何もできていません。
でも、この考え方で動いていきます。
noteで発信する → 皆様からの反応やご意見を取り入れながら、自分の思考を整理・検証
地元イベントに参加する → 現場の声を聞いて仮説を検証
仲間を見つける → 一緒に実験できる人を探す
小さく試す → 大きな計画より、まず一歩
一緒にやりませんか？
地方創生に興味がある方。
同じように「小さく試して、改善していく」スタイルが好きな方。
ぜひ繋がりたいです。
一人でできることは限られています。
でも、仲間がいれば、実験の幅が広がる。
コメント、フォロー、お待ちしています！
まとめ
地方創生は「要件が変わりやすい」領域
環境は常に変化するので、変化に追従できる進め方が必要
だからこそアジャイル的アプローチが向いている
小さく試して、仮説検証して、改善していく
一緒にやってくれる仲間を募集中！
地方創生をアジャイルで。一緒に実験しませんか？
