実績から市場を広げる。ケーススタディを積み上げていく

今日は、自分のこれまでの実績を起点にして、市場とつながるための一つの方法を実際に試した。

昨日考えていた「インサイドアウト戦略」を、少しだけ実行に移せたと思う。

市場全体を見ない

仕事を探そうとして市場全体を見ると、自分にはできないことが大量に目に入ってくる。

フロントエンド、バックエンド、クラウド、AI、データ分析、インフラ。

必要とされる技術はいくらでもある。

全部を見ていると、自分には何もできないような感覚になってしまう。

でも、そもそも市場全体を相手にする必要はない。

自分がこれまでやってきたことから始めればいい。

自分の実績から半径数メートルくらいのところにある課題を探して、そこから少しずつ外側へ広げていく。

自分の実績から市場へ接続する

これまでの仕事では、Pythonやpandasを使ったデータ処理、ETL処理、SQLを使ったデータ確認・加工などを経験してきた。

そこで今回は、この経験に近い実案件を探した。

見つけたのが、就労継続支援B型事業所における工賃実績報告を自動化する案件だった。

利用実績や工賃支給実績を取り込み、不備をチェックし、集計して、行政へ提出するExcelを作成する。

福祉業界の業務知識については、正直に言えば最初から理解できていたわけではない。

そこでAIも活用しながら募集内容を一つずつ読み解いていった。

分からないことを全部理解してから始めるのではなく、まず理解できる範囲を具体的な処理へ落としてみた。

実際にサンプルを作った

架空の利用実績、工賃実績、事業所情報を用意して、Pythonで処理するサンプルを作った。

実装したのは主に以下。

• Excelデータの取り込み
• 工賃実績の重複検出
• 利用実績はあるが工賃実績がないケースの検出
• 対象月と支給月が異なるケースの要確認判定
• 月別・年間集計
• 集計明細と元データの出力
• 行政指定Excelへの集計値の転記

名古屋市が公開しているExcel様式も確認し、集計した値を実際の様式へ転記するところまで作った。

ただし、分からない業務ルールを推測して完成させることはしなかった。

遡及支給や訂正、正式な算定条件、複数事業所への対応などは、実際のデータや自治体資料、過年度の報告書などを確認してから決めるべき領域として残した。

「分からないこと」と「実装できたこと」を分けることも大切だと思う。

AIを使って顧客価値に集中する

今回、自分だけですべてを理解して実装したわけではない。

AIをかなり活用した。

募集内容の整理、業務の理解、Excelの確認、実装方法の検討など、分からない部分をAIと一緒に進めた。

ただ、AIを使う目的はコードを書くことそのものではない。

顧客が何に困っているのかを理解して、その問題に対して具体的なものを差し出すこと。

そこに集中するためにAIを使った。

これから重要になるのは、

「全部自分で知っていること」

よりも、

「知らない問題に出会ったときに、必要な情報を集め、AIも使いながら理解し、具体的な成果物まで持っていけること」

なのかもしれない。

もちろん、受注後は実際の業務ルールを顧客に確認して理解する必要がある。

AIで推測した内容を、そのまま本番システムの仕様にするわけにはいかない。

AIで理解と制作を加速しながら、最終的には顧客の業務と事実に合わせる。

その線引きは必要だと思う。

サンプルを作ってから応募する

完成したサンプルはGitHubで公開した。

そして、そのGitHubを提案文に載せて実際に応募した。

これは考えてみれば、2020年にWeb制作をしていた頃にもやっていた方法だった。

当時も案件に応募するとき、依頼内容に合わせた小さなサンプルを先に作って見せていた。

「できます」と文章で説明するだけではなく、

「こういうものを作ってみました」

と実物を出す。

2026年の今は、そこにPythonの実務経験とAIが加わった。

過去にうまくいった方法を、今持っている技術で再び使っている。

これも一つの雪だるまだと思う。

ブログにケーススタディをストックする

そして、今回作ったものを応募だけで終わらせたくない。

これからブログに「CASE STUDY」という入口を作りたい。

ケーススタディでは、単純に制作物を並べるのではなく、

顧客の課題 → どう理解したか → どう解決しようとしたか → 何を作ったか → 本番では何を確認する必要があるか

という流れを残していく。

今回なら、

「就労継続支援B型の工賃実績報告をPythonで自動化する」

という一つ目のケーススタディになる。

すでに作っているExcel / CSVデータの整形・チェックツールなども、顧客の課題という視点から整理し直せるかもしれない。

GitHubとブログの役割を分ける

GitHubは実際のコードやREADMEを確認してもらう場所。

ブログは、その成果物をなぜ作ったのか、どんな問題を想定して、どう考えて作ったのかを伝える場所。

そしてクラウドソーシングなどのプラットフォームは、実際に課題を抱えている人と出会う場所として使う。

つまり、

プラットフォーム = 顧客と出会う

ブログ = 問題解決の考え方を知ってもらう

GitHub = 実際に作れることを確認してもらう

という役割分担になる。

ブログだけで集客しようとする必要もないし、クラウドソーシングのプロフィールだけですべてを説明する必要もない。

それぞれをつなげればいい。

応募して終わりにしない

今回の案件を受注できるかどうかは分からない。

でも、不採用になったとしても、作ったものは残る。

GitHubに一つ成果物が増えた。

ブログには一つケーススタディを残せる。

福祉事業所の業務について少し理解した。

行政向けExcelをPythonで扱う経験も増えた。

次に似た案件を見つけたときには、ゼロから始めなくていい。

これを繰り返していけばいい。

今後の流れ

今後は、自分の実績に近い実案件を一つずつ探す。

そして、

自分の実績

↓

近い顧客課題を見つける

↓

AIも使いながら課題を理解する

↓

小さなサンプルを作る

↓

GitHubで公開する

↓

実際に提案する

↓

ブログにCASE STUDYとして残す

という流れを回してみたい。

市場全体を見る必要はない。

自分がこれまで積み上げてきたものを芯にして、そのすぐ外側にある顧客の課題を一つ解いてみる。

それをケーススタディとして残す。

また次の課題へ進む。

そうやって、自分が解決できる問題の範囲を雪だるま式に少しずつ大きくしていく。

今日、その一周目を回すことができた。