建設業界では、技能者が自分の経験を証明することが難しく、企業も適切な人材を見つけにくい。この構造的な課題を、行政書士が介在することで解決するサービスを、9ヶ月でゼロから立ち上げた。
Read the Story
建設業界には、構造的なミスマッチが存在する。技能者の経験は「見えない」し、企業のニーズも「伝わらない」。
建設業界には、長年解決されない問題がある。
技能者（大工・左官・電気工事士など）は、長年の経験と技術を持っている。しかし、その経験を第三者に証明する手段が限られている。履歴書に書ける資格や経験年数だけでは、実際の技術力は伝わらない。
企業側も困っている。
「即戦力の電気工事士が欲しい」「特定の設備に詳しい人が必要」——こういったニーズは、一般的な求人サイトでは伝わりにくい。マッチングの精度が低く、採用してみると「想定と違った」というケースが多発していた。
「建設業の採用は、出会う前から諦めていることが多い。『どうせいい人は来ない』という諦め感が、業界全体にある。」——プロジェクト関係者の証言（匿名）
この課題を、別の角度から解決しようとした行政書士法人があった。
行政書士は、建設業の許可申請を専門に扱う。つまり、建設業者の詳細な情報（工事実績・保有資格・財務状況）を、許可申請の過程で把握している。この情報を活用すれば、より精度の高いマッチングができる——という発想だ。
行政書士法人は、法務のプロだ。しかし、サービス開発のプロではない。
担当したエキスパートは、新規サービス・事業の立ち上げ支援経験を持つPM専門家だ。
このプロジェクトで特徴的だったのは、「クライアント自身がサービス開発に不慣れ」という点だ。行政書士法人は、法的手続きのプロだ。しかし、デジタルサービスを開発したことはなく、プロジェクト管理の経験も限られていた。
「何をどの順番でやるか」「ベンダーに何を依頼するか」「スコープをどう管理するか」——これらの「サービス開発の常識」を、プロジェクトを進めながら伝えることが、エキスパートの役割のひとつだった。
「クライアントが『プロジェクトとは何か』を学びながら、プロジェクトを動かす。これが、新規事業支援の難しさであり、面白さです。」
新規サービス開発は、最初から全てを決めることができない。どこを固めて、どこを柔軟にするかの判断が、プロジェクトを左右する。
担当エキスパートが最初にやったことは、「固定すべき要件」と「後で決めていい要件」の仕分けだった。
行政書士法人の担当者は、最初から全てを完璧に設計しようとしていた。「こういう機能も欲しい」「あの場合はどうする」——要件が膨らみ続け、開発が始まらない状態だった。
「全てを決めてから始めようとすると、永遠に始まらない。まず動くものを作って、そこから改善する——この発想の転換が、最初の壁でした。」
彼が設計したのは、「MVP（Minimum Viable Product: 最小限の機能で動くサービス）ファースト」のアプローチだった。
まず最小限の機能で動くサービスを作り、実際のユーザー（技能者・企業）に使ってもらい、フィードバックを得て改善する。この「作りながら考える」サイクルを、9ヶ月のプロジェクトで3回回した。
新規サービス開発は、計画通りに進まない。でも、前に進み続けることが大事だ。
最初の3ヶ月は、「何を作るか」の明確化に費やされた。
行政書士法人の持つ建設業者情報と、マッチングサービスとして必要な機能を整理した。同時に、MVPとして最初にリリースする機能の範囲を絞った。
ベンダー選定では、「IT未経験の組織と一緒に開発できるベンダー」という条件を最重視した。技術力だけでなく、「伴走してくれるか」「わからないことを丁寧に教えてくれるか」——これらを評価基準に含めた。
「ベンダーを選ぶとき、技術力より『コミュニケーション力』を見た。IT未経験のクライアントに寄り添えるベンダーでないと、プロジェクトは壊れる。」
開発が始まると、「想定外」が連発した。
技能者が求める情報と、企業が求める情報のミスマッチ。UIの分かりにくさ。行政書士が保有する建設業者データの整理コスト——これらが次々と課題として浮かび上がった。
エキスパートは、課題を「ブロッカー」と「後回しでいいもの」に分類し、プロジェクトを前に進め続けた。
最終フェーズは、実際のユーザーへのローンチ準備だった。
パイロットユーザー（技能者10名・企業5社）を対象にベータテストを実施。フィードバックを反映し、ローンチ版の完成に向けた最終調整を行った。
9ヶ月目、サービスはローンチした。
ゼロから始めたプロジェクトの答えは、「動くサービスが存在すること」だ。
9ヶ月で、行政書士法人はデジタルサービスの提供者になった。
最初は「ITは専門外」と言っていた担当者が、9ヶ月後にはサービスの仕様を議論し、ベンダーと直接コミュニケーションを取り、次の改善アイデアを提案できるようになっていた。
「サービスができたことより、社内にITサービスを運営できる文化ができたことが、一番の成果だと思っています。」——プロジェクト関係者の証言（匿名）
サービスローンチ後、行政書士法人の代表からこう言われた。「このプロジェクトで、うちの事務所の可能性が広がった。」
IT未経験の組織がデジタルサービスを作ることは、今や珍しくない。成功のための原則を整理する。
新規サービス開発で最もよくある失敗は、「完璧な計画を作ってから動こうとする」ことだ。
サービス開発は、動かしてみて初めてわかることがある。ユーザーが何を求めるか、どのUIが分かりやすいか——これらは、作る前には予測できない。「まず動くものを作る」という発想の転換が、プロジェクトを動かす第一歩だ。
IT未経験の組織がデジタルサービスを作る場合、ベンダーの技術力だけでは不十分だ。
「わからないことを丁寧に説明してくれるか」「一緒に考えてくれるか」「進捗を正直に報告してくれるか」——これらのコミュニケーション特性が、プロジェクトの成否を左右する。
プロジェクトを前に進めるためには、「今解決しなければならない課題」と「後回しにしていい課題」を分ける判断が必要だ。
全ての課題を解決しようとすると、プロジェクトは止まる。「完璧を求めない」というマインドセットが、新規サービス立ち上げでは特に重要だ。
新規デジタルサービスの立ち上げを検討している組織に向けて。
ひとつでも当てはまる方へ
新規デジタルサービスの立ち上げは、IT未経験の組織にとって、最も難しいプロジェクトのひとつだ。
技術的な問題より、「何を作るか」「どう進めるか」「誰に頼むか」という判断の連続が、最大の壁になる。
ExpertMatchを通じて、新規サービス立ち上げの経験を持つPM型エキスパートをアサインできる。初回相談は無料。