メインコンテンツにスキップ

Linnoedge

Linnoedge
実績一覧へ戻る
Works — Platform Development

専門家は、いた。
探している人に、届いていなかった。

士業(専門家)と相談者をつなぐ、検索・相談プラットフォーム

Webプラットフォーム マッチング 検索 リアルタイムチャット 記事CMS 一貫構築
30+ 画面
ユーザー・専門家・管理者に
またがって設計・実装
6 つの中核機能
検索・予約・Q&A・チャット・
レビュー・記事CMS
約5 ヶ月
キックオフから
Phase 1 ローンチまで
Context

専門家を探すのは、本来こんなに大変なことじゃない。

専門家に相談したい悩みを抱えたとき、いちばん難しいのは「質問の中身」ではないことが多いんです。難しいのは、誰に聞けばいいのかを見つけること。そして、その人を信頼していいのか判断することです。

専門家は、ちゃんといます。けれど一般の人から見ると、たどり着く道は口コミと、中身のよくわからない名簿サイトと、勇気のいる最初の一本の電話に散らばっている。一方で、合う案件なら喜んで受けたい専門家のほうにも、必要としている人に見つけてもらう簡単な手段がありませんでした。

クライアントが埋めたかったのは、この溝でした。専門家を探し、公開の場で質問し、個別に相談し、まず読んで知り、根拠を持って選ぶ——それを1つのプラットフォームの中で。連絡先を貼っただけの名簿ではなく、「探す・聞く・選ぶ」がひとつながりになった場所です。

専門家は、いた。探している人に、届いていなかっただけなんです。

Challenge

「検索サイト」に見えて、検索サイトではなかった。

最初の依頼は「専門家の検索サイト」に近い形で届きました。表面だけ見れば、シンプルな話です。

まったく性質の違う2人に、同じプロダクトの中で居心地よくいてもらう必要がありました。信頼できる助けを探している不安な相談者と、このプラットフォームに時間を使う価値があるか見極めている専門家です。

その両方を本気で受け止めた瞬間、「名簿」では足りなくなります。初めて使う不安な人は、申し込む前に検索し、読み、公開の場で聞き、個別にメッセージしたい。専門家は、評価に値するプロフィールと、質問をさばく整った導線と、意味のあるレビューが要る。

これは1つのシステムを共有する2つのプロダクトなんです。だから設計は、後から継ぎ足すのではなく、最初からそれを前提にしておく必要があったんです。同時に、Phase 1はあえて絞り込みました。重い機能を足す前に、まず中心の体験——探す・聞く・相談する——が回ることを確かめるためです。

Craft

この構築の裏にあった判断

リノエッジが担当したのは、まるごとです。要件定義、デザイン、設計、実装、テスト、納品。一部分ではなく、全部。2つの公開ロールと管理コンソール、30以上の画面を、まるごと。

始まりは、コードを1行書く前でした。何を作るのかの認識を揃えるところから。完成形イメージの動画、要件定義書、WBS。クライアントが具体的に反応できる材料を渡したことで、「これで合っていますか?」が受け入れテストの時ではなく初週に答えられた。週次の打ち合わせと、共有ボードで進捗をオープンに追える状態が、全員に同じ現実を見せ続けました。

正直に言うと、いちばん難しかったのはコードではなく「距離」でした。この案件は受注の連なりの何層か下にあって、プロダクトの本当の姿を知っている人は、僕たちが毎日やり取りする相手とは限らない。プロジェクトが静かに壊れるのは、たいていこの隙間です。誰もが当然だと思って口に出さなかった前提が、受け入れテストの時になって初めて表に出てくる。だから僕たちは、意図して過剰に伝えました。完成形イメージの動画、要件定義書、WBS、オープンな進捗ボード——整って見せるためではなく、口に出されない前提を、手戻りになる前に全部、表に出すためです。

2つの役割を、1つのシステムで

一般ユーザーと専門家は、見える画面は違っても、同じデータを土台にします。アカウントの設計を工夫して、役割ごとに最適な体験——ユーザーには検索と相談、専門家にはプロフィールと届く質問——を、1つのLaravelコードベースの中で実現しました。並行する2つのアプリを保守するのではなく、です。公開Q&A掲示板と個別のリアルタイムチャットも同じ認証・権限基盤で動くので、メッセージは常に正しい相手・正しい文脈に紐づきます。そして両者の背後では、管理コンソールがQ&A・レビュー・ユーザー・専門家のモデレーションを1つのダッシュボードでさばきます。

「答え」にたどり着く検索

ここでの検索の目的は「一覧を返すこと」ではありません。「不安な人が、声をかけられる相手まで絞り込めること」です。地域での絞り込み、読めるプロフィール、レビューが噛み合って働くように設計したので、検索の結果が「さらに選別すべき選択肢の山」ではなく「この人に連絡してみよう」という納得につながります。

Phase 1を、あえて小さく

Phase 1はあえて絞り込みました。これは意図した判断です。まず中心の体験——探す・読む・聞く・相談する——を固める。それが回ることを確かめてから、予約相談のような有料機能や管理ツール、残りの部分を土台の上に積む。使われない盛りだくさんの初版より、絞り込んだ初版を出すほうがいいんです。

一般ユーザー向け

地域から専門家を探して、
選ぶところまで

ユーザーは地域で検索し、その専門家がどんな人なのかまで書いてあるプロフィールを見比べます。絞り込みで対象を狭め、レビューの評価が二つ目の手がかりになる。どの検索もゴールは同じ——「誰に聞けばいいかわからない」を「この人に連絡してみよう」に変えることです。

聞く・相談する

公開の場で聞く。
あるいは、個別に話す。

専門家に届く方法が2つ。公開のQ&A掲示板では、誰でも質問でき、過去の回答も読めます——誰に声をかけるか決める前に役立ちます。公開掲示板は申し込む前に読める。個別チャットと、予約した相談枠が、その先を引き受けます。最初のメッセージが「申し込み」のように重くならないんです。

読んで、選ぶ

まず読んで知る。
そして、根拠を持って選ぶ。

カテゴリで整理され絞り込める専門記事のライブラリが、連絡する前に状況を整理する助けになります。専門家へのレビューは、ただの名簿には足りない「他者の評価」という手がかりを足す。この2つが揃うと、冷たい検索が、納得のある選択に変わります。専門家にとっては、見つけてもらう価値のあるプロフィールと実績の蓄積になるんです。

Change

Before → After

BeforeAfter
専門家を探す口コミ、中身の薄い名簿掲載読めるプロフィール付きの地域検索
最初の接触勇気のいる電話、ゼロか百か公開Q&A・個別チャット・予約相談
誰を信頼するか名前以外に手がかりがない学べる記事と、判断材料になるレビュー
専門家にとって必要な人に見つけてもらいにくい見つけてもらう前提のプロフィールと受信箱

Phase 1 は受け入れまで完了し、中心となる体験が意図どおりに動く状態で納品しました。プラットフォームは育てる前提で設計してあり、次のフェーズはしっかりした土台の上から始められます。

リノエッジ

要件定義・デザイン・構築・テスト・納品

Process

プロジェクトの進め方

1
Kickoff
体制とスコープの合意
顔ぶれ・役割・進め方を、最初に揃える。
2
Define
要件定義
完成イメージ動画・要件定義書・WBSで認識を合わせる。
3
Build
デザインと開発
2つの役割を1つのシステムに。進捗はオープンに。
4
Test
受け入れテスト
クライアントのフィードバックを1件ずつ反映。
5
Ship
納品
Phase 1 を納品・受け入れ完了。
Tech Stack

使用技術

PHP Laravel MySQL Redis Laravel Echo(WebSockets) Laravel Scout(検索) Blade Docker

2つの側面を持つプラットフォームを作りたい方へ

あなたの「これ」を、一度話しませんか。

30分。無料。次の一歩をまとめた文書付きです。