Edited at

WordPressでマッチングサービスを3日で作ってリリースした話


第1章 はじめに


1-1.Webサービス開発に必要な3つの要素

はじめまして。加藤泰明です。

東京都内でインフラエンジニアとして働きながらWebサービスを個人開発したり技術系同人誌を頒布しています。

このエントリーでは、僕が2017年7月に、3日間でマッチングサービス「先輩エンジニアサーチ」を開発するも、アクティブユーザーが1人もおらず大失敗をした失敗談をお伝えします。

第1章では、著者である僕自身について書いています。

第2章では、僕がWebサービスを開発してリリースしようと思ったきっかけについて書いています。

第3章では、これから開発するWebサービスで解決したい課題の見つけ方やビジネスモデルの組み立て方、Webサービス開発に必要なマインドについて書いています。

第4章では、3日間でWebサービスを開発した方法について書いています。

第5章では、僕が開発したWebサービス(先輩エンジニアサーチ)にアクティブユーザーがつかなかった理由を解説し、

第6章では、

第7章では、

この1冊を通じて、多くの人に利用されるWebサービスを1から開発して、世の中にリリースできるようになります。

あなたがもしも、オリジナルのWebサービスをリリースして起業し、技術書典3に参加しているようなイケイケのIT企業に成長させて大儲けしようと考えられているのでしたら、あなたも大失敗する可能性が高いです。

あなたが面白いと感じたり、たくさんの人から必要とされると感じているそのアイディアは、所詮あなたの妄想でしかありません。

面白いと思っているのはあなただけかもしれませんし、Webサービスは誰からも見向きもされないかもしれません。売上なんて、最初は全然ありません。

でも、それでも、自分のWebサービスを作って世の中に出したいんだと思えたのなら、僕があなたに、妄想を現実にシフトさせる勇気を届けます。

僕も応援しますので、一緒に頑張りましょう。

さて、Webサービスを自分で開発してリリースまで行うために、必要不可欠な要素が3つあります。

・自分で手を動かし、動くものを素早く作るのが楽しい

・幅広い領域の知識やスキルを得るための学習意欲が旺盛

・試行錯誤が好き

最低限の機能を持ったプロトタイプを作って動かしてみること、また、それを公開する事に喜びを感じられる人は伸びます。高度なプログラミング知識は、必要ありません。

また、フロントエンドやバックエンド、インフラ、セキュリティなどの技術面の知識やスキルはもとより、Webサービスに関連する法律や会計などの知識も必要なため、学習意欲が高い方が伸びます。

開発段階でもそうですが、リリースしたあとも、ユーザーの反応や売上推移を見ながら、試行錯誤してWebサービスを改良していく必要があります。

僕の失敗を反面教師として、世の中で大人気となるWebサービスをあなたに開発してほしいと切に願っています。

この同人誌を購入されたあなたなら、それができると信じています。


1-2.著者の経歴

某一部上場企業グループの人材派遣会社のエンジニア。

働き方は客先常駐8割、業務委託契約の案件2割。

・インフラエンジニア歴4年1か月(2017年10月時点)

 運用設計 5ヶ月

 サーバ構築(オンプレミス・AWS) 1年6ヶ月

 サーバ運用監視 2年3ヶ月

 SKYSEA Client View 導入 3ヶ月

 VMware ESXi 導入 6ヶ月

 社内SE 6ヶ月

 ※同時並行で行っているものもあり

・常駐した業界

 ASPサービス(メールセキュリティ・アクセス制御)

 DSP(Web広告配信)

 オンラインゲーム

 官公庁

 通信キャリア(第一種・第二種通信事業者)

・使用OS

 Windows Server (2008 R2 / 2012 R2)

 Red Hat Enterprise Linux (2008 R2 / 2012 R2)

 CentOS (6.6~8 / 7.1)

・使用データベース

 MySQL (5.1~5.5)

 Oracle Database 11g R2

 Microsoft SQL Server (2014 SP1 / 2008 R2 SP2)

・使用製品、ツール

 クラウド

  AWS(EC2 / S3 / RDS / DynamoDB / ELB / SES)

 オンプレミスサーバ

  HP BL c7000 Enclosure

  HP ProLiant BL460c Gen9

  HP ProLiant DL360 Gen9

  NEC Express5800

  DELL PowerEdge R300

  Supermicro 5018D-FN4T

 ルータ・FW

  Cisco(1800 series / Catalyst 2950 series)

  ARUBA Instant AP RAP-109

  NetScreen 5XT

  FortiGate (60C / 60D)

 仮想化基盤

  VMware (ESXi / vCenter Server) 6.0.0

 セキュリティ

  SKYSEA Client View

  Nessus

 その他

  GitHub

  Jenkins(CIツール)

  Serverspec(テストツール)

 Webサービス開発:WordPress(プライベート)

  https://senpai-engineer-search.tokyo/

  WordPress

  MySQL

 Webサービス開発:Ruby on Rails(プライベート)

  https://github.com/curryperformer-kato

  HTML / CSS・Bootstrap / CoffeeScript

  Ruby 2.3.0

  Rails 5.0.3

  CRUD機能

  ログイン機能(devise)

  メール送信機能(SendGrid)

  画像アップロード(CarrierWave)

  OAuth(Facebook / Twitter)

  外部API利用

  Ajax

  お知らせ機能(Pusher)

  自動デプロイ(Capistrano)

  Unicorn(Rack Webサーバ)

  テスト(RSpec)

  GitHub

  heroku

・使用ミドルウェア

 Apache 2.2.15

 Nginx 1.7.7

 Tomcat 7.0.53

 Nagios 4.0.1

 Postfix 2.6.6

 Xymon 4.3.18

・使用言語

 Ruby 2.3.0 6ヶ月

 PHP 5.3.3~7.0.18 1年

・保有資格

 LPIC Level 1

 ITIL Foundation

 マイナンバー対応個人情報保護士

 第三級陸上特殊無線技士

 Ruby技術者認定試験 Silver

・受講歴

 デジタルハリウッドSTUDIO渋谷 WordPress講座・PHP講座 修了

 Dive into Code 即戦力コース(Ruby on Rails) 卒業

 ノンエンジニアがマッチングサービスを作るための日帰り強化合宿 修了


1-3.スペシャルサンクス

 ・僕のマッチングサービス開発の師匠

  イノベーションハック株式会社 代表取締役副社長 CTO 深谷正人氏

   ノンエンジニアがマッチングサービスを作るための日帰り強化合宿 講師

    https://peraichi.com/landing_pages/view/create-service

   ワードプレス・レスキュー 運営

    https://wp-rescue.com/ 

   ブログ「ヨンイチワイ」運営

    https://41y.me/


1-4.免責事項

この同人誌および著者が発信する情報を基にWebサービスを作成し、その結果、損害等を負ったとしても、著者は一切責任を負いません。


第2章 Webサービスを開発してエンジニアを辞めたい


2-1.会社に縛られずに生きるための収入源がほしい

僕は、東証一部上場企業グループの人材派遣会社の社員として、インフラエンジニアのキャリアをスタートしました。

客先常駐で(特定派遣やSESなどの契約で)働いていましたが、楽しいことよりも辛いことの方が圧倒的に多かったです。

常駐先のプロパー社員からは「ゴミくず」「こんなこともできないの?」と言われたり、炎上プロジェクトでは残業や休日出勤を命じられて月間300時間近く働いたりと、人権もなく人間らしい生活ができない現場が続いてげんなりしていました。

自社の上司は何もしてくれず、ただただ客先のプロパー社員の言う通りに働き、機嫌を損ねないようにとしか言いいません。我慢して頑張っても、そんな上司が僕を高く評価することもなく、エンジニアとして働く情熱を失っていました。

そんな生活を送る中で、2017年の5月に、胃炎、大腸炎、逆流性食道炎にかかったことがきっかけで、「僕はもう、サラリーマンとして組織に所属して、誰かに命令されて働くことはできない」という結論に至りました。

もう、エンジニアとして生きていくための情熱も、体力も、何もかもがなくなってしまったんです。

そして、自分でWebサービスをリリースして、その収益で生活して生きたいと考えるようになりました。

「自分で仮説を立て、Webサービスを開発し、市場の反応を見ながら改良を加え続けることで、より大きな価値を世の中に届け、感謝とお金を得ていく」生き方を送りたいという想いが、僕の中でマグマのように湧き上がるのを感じました。

また、これまでの働き方では、常駐先の社員から指示されたインフラを構築する御用聞きの発想から抜け出すことはできませんし、上司を見ていると「客先の言いなりになってエンジニアの手配をするだけの人間」にしかなれないことがわかりきっています。

だからこそ、御用聞きではなく、自分で価値とお金を生み出していく働き方にシフトしなければ生き残れないという危機感も生まれていました。


2-2.オンラインゲームのリリースに携わり「世の中の反応をダイレクトに感じる面白さとやりがい」が忘れられない

僕はインフラエンジニアなのに、なぜWebサービス(しかもBtoC)を開発しようと考えたのかというと、オンラインゲーム会社に常駐していた時に感じた、「自分たちのサービスをリリースして、世の中の反応をダイレクトに感じる面白さとやりがい」が忘れられなかったからです。

当時、僕は大手ゲーム会社に常駐し、オンラインゲームの公式HP用Webサーバを構築・運用していました。

とあるオンラインゲームの公式HPをオープンした時に、Twitterでエゴサーチしていたのですが、「遊べるのを待ってました」「さっそくプレイしたら、めっちゃ楽しい!」というような好意的な声にあふれているのを見て、たまらなく嬉しかったのを覚えています。

僕が仕事を頑張った結果が、多くのプレイヤーの喜びにつながったのだなと感じられて、脳内でドーパミンがドバドバ出たのを覚えています。

この瞬間、僕はBtoCのWebサービスの魔力にはまりました。

その現場は訳あって離れたのですが、その後、BtoCのWebサービスを提供している企業に常駐する機会を熱望するも叶うことはありませんでした。

転職もスキル的に難しかったので、それならいっそ自分でBtoCのWebサービスを立ち上げちゃおうと考えた次第です。


第3章 エンジニア転職支援マッチングサービスはこうやって生まれた

Webサービスを開発しようと考えたのはいいですが、どんなwebサービスにしようか悩む日々が続きました。

アイディアが浮かんでは、「ユーザーは集まるのか、集められるのか」「誰にニーズがあるのか」「儲かるのか」「既存サービスにはない強みはどこにあるのか」などを考えて息詰まることの繰り返しです。

そんな中で、せっかくWebサービスを作るなら、自分が今一番直面している課題を解決できるものにしようと思い立ちました。

それが、「IT業界未経験から転職したい人と、転職活動を支援してくれる先輩エンジニアとのマッチングサービス」誕生のきっかけです。


3-1.プログラミングスクールに通ってもエンジニアになれないという課題

私は、Dive into Code(以下、DiC)というプログラミングスクールでRuby on RailsによるWebアプリケーション開発を学び、2017年9月に卒業しました。

インフラエンジニアとしてのベースはありつつも、卒業までに約500時間勉強して、単元ごとの19の課題と、SNSのクローンアプリを作る実習を3つこなし、オリジナルアプリを開発する卒業課題に合格しても、Webアプリケーションエンジニアとして転職するスタートラインにも立てません。

IT業界未経験からエンジニアへの転職を目指す仲間も転職活動を行っていますが、苦戦していたり、運よく転職できても開発言語がPHPの会社だったりと、望み通りの転職ができていないケースが多くみられました。

また、僕は「未経験からRailsエンジニアを目指すもくもく会」を運営しているのですが、そこでも「エンジニアに転職したくてRuby on Rails チュートリアルを終わらせたが、どのように転職活動を進めたらよいのかわからない。」「転職エージェントは頼りにならない。IT業界未経験から転職したい人の相談に親身にのってくれない。」という声を聴きました。

僕も、IT業界未経験(CADの法人営業など)からインフラエンジニアとして転職しましたので、この課題は他人ごとではないと感じています。

個人的な体験からも、IT業界未経験からエンジニアになりたい人の転職成功に必要なのは「人間として信頼できて、自分の転職成功体験をシェアしたり、エンジニアを採用する企業の目線からアドバイスをくれたり、自分に足りない技術や知識を授けてくれる相談相手」になってくれるエンジニアであると感じました。

その想いから、マッチングサービスの開発に着手しました。


3-2.マッチングサービスの名前は「先輩エンジニアサーチ」

まずは、マッチングサービスを利用することで得られる価値を、マッチングする両者の視点で考えます。

このマッチングサービスは、IT業界未経験からエンジニアに転職したい人と、プロとして活躍する先輩エンジニアをマッチングするサービスです。

IT業界未経験から転職したい人が得られる価値は、『先輩エンジニアサーチを通じて出会った、若手育成に熱心で、かつ、優れた技術をもつ先輩エンジニアが親身に相談にのってくれることで、転職活動を効率的に進めることができるようになること』です。

対して、エンジニアが得られる価値は、ずばり『現金収入』です。自分の就職・転職活動経験や培った技術などが収入につながります。

また、僕のマッチングサービスを通じて転職相談に乗った結果、プログラミングスクールのメンターなど、教育者としてのキャリアが開ける可能性もあります。

これが、僕のマッチングサービスの基本的なコンセプトになります。

僕がマッチングサービスを通じて解決したい課題は、IT業界未経験から転職したい人が抱える課題なので、彼らが転職相談ができる先輩エンジニアを探すためのサービスという意味を込めて「先輩エンジニアサーチ」と名づけました。


3-3.ビジネスモデルはオンラインサロンを参考に設計

僕のマッチングサービスには、登場人物が三種類登場します。

・ユーザー(相談する側:IT業界未経験から転職したい人)

・先輩エンジニア(相談にのる側:プロのエンジニア)

・運営事務局(サービスの開発・運営=僕)

先輩エンジニアとして登録したいエンジニアは、必要事項を明記のうえ、運営事務局のメールアドレスあてに、登録希望のメールを送ります。

その後、所定の審査を経て、先輩エンジニアとしての登録が行われます。

ユーザーは、先輩エンジニアの紹介ページにアクセスし、それぞれの顔写真や得意な言語・スキル、働き方(正社員、フリーランスなど)、ジャンル(インフラ、Webアプリケーション開発など)が記されたプロフィールを確認します。

先輩エンジニアは、それぞれ任意の相談料を設定することができます。

(先輩エンジニアがユーザーの相談にのる期間を一律6ヶ月と定めているので、6ヶ月分の相談料を設定します)

その後、相談したいと感じた先輩エンジニアが見つかったユーザーは、先輩エンジニアの名前を明記して、申し込みフォームから運営事務局に申し込みをします。

その後、ユーザーは、自分が選んだ先輩エンジニアが定めた相談料を、運営事務局が指定した銀行口座に入金します。

(先輩エンジニアに代わって、運営事務局が、相談料の請求と入金確認を行います)

入金確認後、運営事務局が、ユーザーが選んだ先輩エンジニアに直接相談できる非公開のSNS(別途、僕が開発したもの)に、ユーザーを招待します。

6ヶ月間の有効期間内であれば、ユーザーが好きな時間に好きな回数だけ相談することができます。

また、運営事務局は、先輩エンジニアが設定した相談料の10%を、手数料として徴収します。

ユーザーから入金された金額のうち、その10%と振込手数料を差し引いた金額を、先輩エンジニアが指定する銀行口座に入金します。

このようなビジネスモデルは、著名人などが提供しているオンラインサロンを参考にして、設計しました。

ちなみに、ビジネスモデルの設計で一番気を付けたのが、「お金を前払いでいただく仕組みにすることで、回収漏れをなくす」ことです。

サービス(転職相談)を提供した後で支払いを受ける場合、ユーザーが支払いを拒否したり、連絡を絶ってしまうリスクがあります。

1人でサービス開発・運営している場合、それは致命的なリスクですし、支払いを促す労力も大きいので、代金を支払ってからでなければサービス(転職相談)を受けられないようにしています。

ただし、詳しくは後述しますが、このビジネスモデルが、特定商取引法に規定される7つの取引類型(訪問販売・通信販売・電話勧誘販売・連鎖販売取引・特定継続的役務提供・業務提供誘引販売取引・訪問購入)のうちの通信販売にあたると考えられることから、現在は先輩エンジニアが設定する相談料および運営事務局がいただく手数料は無料としています。


3-4.必要ない機能は作らず人力にすることで早くリリースして、生の声を聞く

ビジネスモデルの説明の時点でお気づきと思いますが、先輩エンジニアサーチは、かなりの部分が人力です。

人力の部分をまとめると、以下の通りになります。

・登録を希望する先輩エンジニアからのメールを受け付け、所定の審査を行う

・ユーザーからの申し込みを受け付け、相談料の入金用銀行口座を案内する

・ユーザーからの入金確認を行う

・ユーザーと先輩エンジニアをSNSに追加する

・先輩エンジニアの銀行口座に相談料(手数料差引後)を振り込む

・先輩エンジニアがユーザーに選ばれやすいよう、プロフィール作成方法等のアドバイスを行う

・先輩エンジニアがユーザーに対してよりよいサポートが行えるよう、研修等を提供

・ユーザーの転職活動状況のヒアリング等を行う

・その他必要に応じたサポートや質問・お問い合わせへの回答等を行う

・利用規約違反のユーザーや先輩エンジニアがいた場合は注意をし、改善しない場合は利用停止にする

マッチングサービスを開発するなら、全てをWebサイト内で完結させたくなるのがエンジニアの性なのですが、あえて大部分を人力にしたことで、以下のようなメリットが生まれます。

・時間とお金の投資を抑えることができる

先輩エンジニアサーチで提供する全てをWebサイト内で完結させられるレベルで作りこむには、かなりの時間がかかります。

また、僕にはスキルが足りない部分もあるので、開発を一部外注する必要が出てきます。

いくらβ版でテストを重ねてみても、リリースしてみるまで、ニーズがあるのか、売り上げがどれくらい伸びるのかは、正直分かりません。

ニーズがあるか否かが分かる前から、時間やお金をつぎ込むのはリスクが高いため、あえて大部分を人力にすることで、開発にかける時間とお金を節約しています。

・PDCAサイクルを爆速で回したいから

先ほど述べたとおり、リリースしてみないと、ニーズがあるのか、売り上げがどれくらい伸びるのかは分かりません。

僕は「答えは市場にある」が信条なので、さっさとリリースして、市場の反応やユーザーの声を聴いて、より早く、より効果的な改善を加えていくことで、先輩エンジニアサーチを成長させていきたいと考えています。

そこで、あえて大部分を人力にしてでも、さっさとリリースしようと思いました。

市場の反応やユーザーの声を聴いた結果、人力で対応するのではなく、先輩エンジニアサーチの機能として追加する方がいいと分かった時点で、はじめてその機能の開発をはじめようと考えています。

・ユーザーや先輩エンジニアとの接点をあえて作り、生の声を聴きたいから

全てをWebサイト内で完結させると、先輩エンジニアサーチを使うユーザーや先輩エンジニアとの接点がなくなり、生の声を聴く機会がなくなってしまいます。

使う側からの、先輩エンジニアサーチに対するフィードバックがたくさんほしいですし、ユーザーや先輩エンジニアが抱える課題やニーズが、僕の仮説とあっているか検証するためにたくさん話を聴きたいと思っています。

そのため、あえて運営事務局(=僕)とメール等でやりとりする機会を作っています。


3-5.エンジニアが陥りやすい「完璧主義」という罠

僕が卒業したDiCでは「DEMODAY」という、外部の審査員や一般の観客の前で、自分のアプリケーションを発表するイベントを開催しています。

そのDEMODAYの登壇者を見ていて感じるのですが、Webサービスを開発する人たちは大抵の場合、自分のWebサービスが絶対に世の中に受け入れられると信じて開発を行います。

そして、自分たちが完璧だと感じるWebサービスに仕上げるために、自分の理想の機能を盛り込み、どこに出しても恥ずかしくない品質になるまで、多くの時間をかけてブラッシュアップします。

そのため、出来上がったWebサービスは技術者視点で見れば立派ではありますが、対象ユーザーにとっては必要のない機能が多くあったり、そもそもそのWebサービスは誰にニーズがあるのか微妙なものがあったりします。

また、ニーズがあったとしても、あなたのWebサービスを利用したいと思うとは限りません。

リリースしたあとで、自分の仮説(ユーザーのニーズ、必要な機能等)の間違いに気づくことほど、気持ちも萎えますし時間も無駄になります。

完璧主義は捨てましょう。

また、リリース当初から技術的な視点で、「Webサービスとしてのあるべき姿」を求めるのは辞めましょう。

(競合のWebサービスが実装している機能が、必ずしもすべて必要とは限らない)

大事なのは、Webサービスのアイディアが浮かんだら、必要な機能を「コア機能」と「後から追加すればいい機能」に分けて、コア機能に絞って最速で開発してリリースし、爆速でPDCAサイクルを回しまくって、仮説と検証を繰り返すことです。

ここでいうコア機能とは、あなたのWebサービスを「このサービスは、○○をするサービスです。」と第三者に紹介するとしたときに、○○に入る言葉を実現する機能を指します。


3-6.知り合いや同僚に声をかけてユーザーを集めようとする

マッチングサービスで収益をあげるために必要なことは、ユーザー獲得です。

先輩エンジニアサーチにお金を支払ってくれそうなユーザーを、どのような方法で、どのくらいの期間で獲得するのかを決めて、達成していく必要があります。

僕の場合、先輩エンジニアサーチを使うユーザー候補も、先輩エンジニア候補も、それぞれが身近にいましたし、彼ら彼女らが集まっているコミュニティや会社に所属していますので、個別に声をかけるなりslackなどで周知すれば使ってもらえると思っていました。

この考えの甘さが、のちに大失敗につながるとは………。


3-7.僕が社長 兼 技術部長 兼 営業部長 兼 経理部長 兼 法務部長 兼 CS部長

先輩エンジニアサーチを開発・運用するのは僕だけなので、全ての役割が僕の担当になります。

・社長

・技術部長

 ・プロジェクトマネージャー

 ・インフラ担当

  ・サーバ構築・運用

  ・ネットワーク構築・運用

  ・データベース構築・運用

  ・ディザスタリカバリ

 ・Webフロントエンド担当

  ・UI/UX改善

 ・Webアプリケーション開発担当

  ・バグ改修

  ・機能追加

  ・テスト

 ・セキュリティ担当

  ・パッチ適用、バージョンアップ

  ・サイバー攻撃対策

  ・情報漏えい対策

  ・個人情報管理

 ・外注管理担当

・営業部長

 ・個人営業担当

  ・先輩エンジニア向け

  ・ユーザー向け

 ・広告担当

  ・先輩エンジニア向け

  ・ユーザー向け

 ・マーケティング担当

  ・KPI分析

  ・CV(コンバージョン)改善

  ・ユーザーヒアリング

  ・SEO対策

 ・サービス企画担当

  ・ユーザーヒアリング

・経理部長

 ・相談料の入金、振込担当

 ・経費(サーバ代金等)振込担当

・法務部長

 ・利用規約、プライバシーポリシー作成担当

・人事部長

 ・先輩エンジニア登録審査担当

 ・採用担当

 ・研修担当

・CS(カスタマーサービス)部長

 ・各種お問い合わせ窓口担当

 ・先輩エンジニア利用サポート担当

・品質管理・品質保証部長

 ・品質管理・品質保証担当

・広報部長

 ・広報担当

オンラインゲーム会社に常駐していた時に、新しいゲームがリリースされるときは各部署からメンバーが集まってプロジェクトチームを組んでいたので、その際のチームメンバーの役割をもとに洗い出しました。

自分1人でWebサービスの開発・運用をする場合でも、こうして役割を洗い出して「この作業はどの役割に当てはまるんだろう」と常に考える癖をつけると、後々仕事を別の人と役割分担して行う必要が出たときに、作業内容や手順を説明しやすくなります。


3-8.WordPressを選んで設計・構築・テストの工数をがっつり削減

オリジナルのWebサービスを開発するためには、以下の工程が必要となります。

・要件定義

 ・どのようなサービスを提供するのかを決める。

 ・ユーザーが最終的にどのようなアクションをすればいいのかを決める。

  (商品やサービスの購入、広告のクリック、資料請求など)

 ・どのようなページが必要なのかを決める。

  それぞれのページをどのように移動させるのかを決める。

 ・管理画面は用意するのかを決める。

  どのような権限を用意し、それぞれにどこまで管理させるのかを決める。

 ・どのようにページや管理画面を移動するのかを決める。

 ・どのような機能を実装する必要があるのかを決める。

・設計

 ・データベースのテーブルとデータ型を決める

 ・実現したい機能を盛り込む方法を決める

 ・運用(パッチ適用、バックアップ取得など)フローを決める

・構築

 ・サーバとデータベースを用意する

 ・必要なページを作成する

 ・(必要な場合)管理画面を作成する

 ・必要な機能を実装する

・テスト

 ・実装した機能がそれぞれ正常に動くことを確認する。

 ・実装した機能が全て正常に動き、サービスが正常に使用できることを確認する。

 ・想定していない使い方をした時、どのような挙動になるかを確認する。

WordPressを用いることで、これらの工数を圧倒的に短縮することができます。

レンタルサーバを利用すればWordPressのインストールやデータベースのテーブル作成がマニュアルに従って操作するだけでできます。

プラグインをインストールするだけでコードを書くことなく、必要な機能が実装されます。

また、必要なデータベースのテーブルが自動的に用意されます。

さらに、管理画面は元々用意されていますし、運用も簡単に行うことができるので、非エンジニアでも管理が楽です。

WordPressのバージョンアップやプラグインの更新はワンクリックでできますし、バックアップも簡単な設定で取得できます。

ドキュメントも先生も豊富なので、わからないことがあっても、ググれば大抵解決できます。

ググってもわからない場合、WordPressを使っている人が数多くいるので、勉強会に参加したり、terateilなどの質問サイトで質問することで、比較的簡単に解決方法を得ることができます。

ちなみに、僕の師匠の深谷さんが「ワードプレス・レスキュー」というサービスを運営されており、有料ですがWordPressの問題解決を行われています。

WordPressで作ったWebサービスをリリース後、問題が起きた場合は、こちらを利用するのもよいと思います。


第4章 3日間でマッチングサービスを開発した爆速開発法


4-1.レンタルサーバーを借ります

平日はフルタイムでインフラエンジニアとして働いているため、サーバ運用監視の工数を削減するためにレンタルサーバーを借りました。

先輩エンジニアサーチには申し込みフォームやログインページがあるため、無料独自SSLが使えるXSERVERにしています。

また、国外IPからのアクセスを制限したり、不正なログインを制限する等のセキュリティ対策(※)も、設定をONにするだけで簡単に行うことができます。

リリース最初期は、インフラに極力コストをかけたくないですし、失敗した場合は撤退しやすいように、最短の契約期間で始めました。

XSERVER X10(スタンダード)プラン

契約期間:3ヶ月

初期費用:3,000円+消費税240円

ご利用料金:(1,200円+消費税96円)×3ヶ月

合計:6,600円(税込7,128円)

(※)WordPressは利用者が多いために、ハッカーの攻撃対象になりやすいです。

特に、Kali LinuxというDebianベースのLinuxディストリビューションにデフォルトでインストールされている「WPScan」という脆弱性診断ツールを使うと、ポートスキャンやログインユーザ一覧の取得、ブルートフォースアタックによるログインパスワードの取得が簡単にできてしまいます。

特に、WordPressは、管理画面URLの設定がデフォルトのままになっていると、そのWebサービスのURLの末尾に/wp-admin/もしくは/wp-login.php/をつけてアクセスことで管理画面のログインページが表示されます。

そのため、管理画面のURLは、Webサービス開発前に、必ず変更しましょう。

(先輩エンジニアサーチでは、Login rebuilderというプラグインを使用して変更しました)

また、管理者となるユーザー名は、adminなどの、管理者として特定されやすいものは避けるようにしましょう。

ブルートフォースアタックによってパスワードを特定されやすくなります。

ユーザー名とパスワードは、8文字以上で、かつ、英小文字・英大文字・記号・数字のうち任意のものを3つ組み合わせて作成すると特定されにくくなります。

ちなみに、ブルートフォースアタックとは、Webサービスのユーザーのパスワードを特定するために、よく使われるパスワードがまとめられた辞書ファイルなどを用いて、ユーザー名とそこに記載されているパスワードを組み合わせてしらみつぶしにログインを試行するサイバー攻撃のことです。


4-2.お名前.comで独自ドメインを取得します

ドメイン名:senpai-engineer-search.tokyo

登録年数:1年

.tokyo 1年登録×1:107円(税込)

Whois情報公開代行×1:0円

合計:107円(税込)

オリジナルのWebアプリケーションやサービスを公開するなら、独自ドメインの設定は必須です。

ここにもコストをかけたくないので、登録料が一番安い金額のドメイン(.tokyo)で始めました。


4-3.WordPressをセットアップしてテーマとプラグインをインストールする

使用するテーマは、デザインがシンプルで見やすく、Webサービスに適したレイアウトのOnePressにしました。

無料で使えて、しかもPCでもスマホでも見やすいレスポンシブ対応なので、とても助かります。

プラグインは、以下のものを使用しています。

・Cool Tag Cloud

 タグのデザインをカスタマイズできるプラグイン

・Pods

 カスタム投稿タイプを作成できるプラグイン

・WP Multibyte Patch

 デフォルトでインストールされている日本語処理改善用プラグイン

・WP-Menbers

 ユーザー登録やログイン機能を追加できる

・Custom Post Type Permalinks

 パーマリンク(URL)をカスタマイズできるプラグイン

・footer-putter

 フッターを設定できるプラグイン

・Archivist - Custom Archive Templates

 投稿の一覧ページ(運営事務局ブログとして使用)を作成するプラグイン

・Contact Form 7

 お問い合わせフォームを作成するプラグイン

・Login rebuilder

 独自のログインページを配置するプラグイン

XSERVERにWordPressをインストールしたのち、これらのテーマとプラグインをインストールします。


4-4.WordPressで必要なページを作成する

WordPressで作成できるページには、大きく分けて3つのタイプがあります。

・投稿ページ

 ブログなどの日々更新が行われるページで使用する。

 カテゴリやタグを設定してグループ分けをしたり、アーカイブ(まとめ)ページを作成できる。

・固定ページ

 会社概要、商品紹介、アクセスなど、更新頻度が少ないページで使用する。

 固定ページ同士で親子関係を作ることができる。

 

・カスタム投稿タイプ(自動で生成されるページ)

 データベースの登録内容に応じて自動生成されるページ

Webサービスのそれぞれのページの役割に基づいて、どのタイプで作成するのかを決定します。

先輩エンジニアサーチでは、以下のように使い分けています。

・投稿ページ

 運営事務局ブログ(各種お知らせ、転職成功事例紹介など)

・固定ページ

 トップページ、登録ページ、利用規約など

・カスタム投稿タイプ(自動で生成されるページ)

 先輩エンジニア一覧ページ、得意な言語など


4-5.ページで使用する画像を用意する

商用利用可能な無料写真素材サイトを利用して、ヘッダーや各ページなどで使用する写真を入手します。

先輩エンジニアサーチの場合、PAKUTASOと写真ACで提供されている画像に目を通し、先輩エンジニアサーチのイメージに合いそうなものを入手しました。

なお、入手した画像を加工してヘッダーなどを作成する場合、無料で使える「Pixlr Editor」を利用しました。


4-6.利用規約とプライバシーポリシーの作成

利用規約は、類似したサービスの利用規約を参考に作成するのをオススメします。

先輩エンジニアサーチの場合、僕のWordPressの師匠である深谷さんが開発を行った「PVモンスター」の利用規約を参考に作成しました。

プライバシーポリシーに関しては、「プライバシーポリシー テンプレート」などでGoogle検索すると、テンプレートが見つかるのでそれをもとに作成するのがオススメです。

僕は「マイナンバー対応個人情報保護士」という資格を保有していて、個人情報保護法の知識があったため、先輩エンジニアサーチの場合はほぼオリジナルで作成しました。


4-7.関連する法律の確認とそれに対する対応

先輩エンジニアサーチが提供しているサービスは、利用規約において「当事務局は、本サービスにおいて、ユーザーと、先輩エンジニアとのマッチングを補助し、先輩エンジニアからユーザーへの転職活動の相談およびその回答を円滑化するプラットフォームを提供します。」と定めていました。

運営事務局側(=僕)が行うのは、具体的には以下の通りです。

・ユーザーに対して、先輩エンジニアを先輩エンジニアサーチ内で紹介し、転職相談の申し込みを受け付ける。

・先輩エンジニアが各々定めた相談料を、先輩エンジニアに代わってユーザーに請求する。

・ユーザーからの入金確認を行う。

・ユーザーから入金された金額のうち、所定の手数料(10%)と振込手数料を差し引いた金額を先輩エンジニアの銀行口座に入金する。

・先輩エンジニアが、ユーザーに対して、ユーザーの転職活動の相談にのるというサービスを行うためのプラットフォーム(非公開のSNSグループ)を提供する。

このようなサービス形態は特定商取引法の対象となる、特定商取引法に規定される7つの取引類型(訪問販売・通信販売・電話勧誘販売・連鎖販売取引・特定継続的役務提供・業務提供誘引販売取引・訪問購入)に該当するのかを調査しました。

調査には、消費者庁のHP内の特定商取引法に関するページや、特定商取引ガイドを使用しました。

調査の結果、先輩エンジニアサーチは、先輩エンジニアがユーザーに対してサービスを行うためのプラットフォーム提供と、先輩エンジニアが設定した相談料の請求・回収の代行を行うもので、商品を直接販売していないという認識でいました。

しかし、法務実務経験のある方に相談しところ、先輩エンジニアサーチは通信販売にあたると考えられるそうです。

先輩エンジニアとユーザーとの間の直接契約であり、運営事務局(=僕)がプラットフォーマーに過ぎないという形式をとっていたとしてもこの結論となるとのこと。

先輩エンジニアとユーザーによるCtoCの直接契約であって、先輩エンジニアサーチは単なるプラットフォーマーであるという形であれば、運営事務局(=僕)自身がユーザーに対するサービスの提供者にはならないそうです。

ただし、結局、先輩エンジニアサーチは両者をマッチングするというサービスを提供し、その対価として先輩エンジニアから手数料を得ているため、この点から、特定商取引法に基づく表示が必要になるとのことでした。

なお、ユーザー間の取引の仲介を行うCtoCサービス(ココナラ、メルカリ、BUYMAなど)やマッチングサービス(肉会、pairsなど)では、特定商取引法に基づく表示はあります。

特定商取引法に基づく表示においては、事業者所在地を記載する必要がありますが、個人で開発したWebサービスの場合、オフィスなどを持っていない限りは自宅の住所を記載することになります。

自宅の住所を記載することに抵抗がある場合、レンタルオフィスを契約してそこの住所を載せる方法もありますが、先輩エンジニアサーチの場合、初期費用を抑える観点から、レンタルオフィスを契約するのではなく無料にする(通信販売に該当しないようにする)ことで対応しました。


4-8.独自ドメイン設定と無料独自SSL設定

お名前.comで取得した独自ドメインをXSERVERに設定し、独自ドメインで先輩エンジニアサーチにアクセスできるようにします。

お名前.comで取得したドメインをXSERVERで使うための設定方法は、ググると画像付きで詳しく説明しているWebサイトが見つかりますので、それを参考に設定します。

無料独自SSL設定は、XSERVERがHP内でマニュアルを公開していますので、それを参考に設定します。


4-9.アクセス解析を設定する

先輩エンジニアサーチを運用していくうえで、ユーザー数や売上向上のために、以下のような情報を収集する必要があります。

・どのように先輩エンジニアサーチにアクセスしてきたのか

 ・検索エンジン(Google / Yahoo / Bing / goo など)経由

 ・SNS(Facebook / Twitter など)経由

 ・Webサイト(ブログ・Qiita・2ch・Naverまとめ など)経由

・どのようなキーワードで先輩エンジニアサーチを見つけたのか

・滞在時間や直帰率(1ページだけ見て離脱する割合)

・アクセスしてきた地域や曜日、時間帯ごとのページビュー数やユニークユーザー数

・コンバージョン(先輩エンジニアへの相談申し込み)数

これらの情報を収集し、分析する事で、先輩エンジニアサーチの改善点が見えてきます。

アクセス解析であれば、収集できる情報量を鑑みるとGoogle Analyticsを使うのが一番だと思いますが、ときどき画面が変わっていて、どこを見たら欲しい情報が確認できるのかわからなくなることがあります。

そのために、先輩エンジニアサーチでは、アクセス元やアクセス数などは「THK Analytics」を、検索キーワードは「Googleのサーチコンソールを利用」を利用しています。

THK Analytics

Google Search Console


4-9.動作テスト

正常に画面が表示できるか、各ページに遷移できるか、ログインや申し込みフォームからの申し込みが正常にできるか等、動作確認を行って問題がないことを確認します。


先輩エンジニアサーチをリリース

SNSでシェアしたり、前職の同僚や知り合いのエンジニアに個別に声をかけたり、DiCのSlackチームなどで共有します。


第4章 大失敗した5つの理由

先輩エンジニアサーチは9月末時点で、アクティブユーザー0人です。

先輩エンジニアの登録申し込みもなく、ユーザーが活用した形跡もなく、マッチングも成立していません。

その原因を自己分析した結果、以下の5つが原因だと感じました。

この章では、原因の分析とともに、次回Webサービスを作るとしたらこうするというアクションを考察しました。


4-1.経営者としてのビジネスセンスがない


4-1-1.要件に従ってインフラを作るだけの発想から抜け出せない

僕のエンジニアとしての働き方は、客先常駐で(特定派遣やSESなどの契約で)働くスタイルが大半です。

そのため、常駐先で提示される要件に沿って、インフラ(Webサーバや仮想化基盤など)を構築するだけで、構築したインフラがどのように常駐先のビジネスで活用され、お金を生み出すのかまでは踏み込むことはありませんでした。

その結果、どのように事業を起こし、どのようにお金を生み出すのかを創造する力が鍛えられていないと感じています。

これは、Webサービスを運営して収益を上げようと考えている人間にとっては致命的だと感じています。

そこで、その力を鍛えるために、小さな範囲で「ビジネスの流れを全部経験する」ことにしました。

僕は「カレーパフォーマー加藤」という名義で、はてなブログを運営しているのですが、ココナラというサイトにて、スパイスからカレーを作るためのレシピを教えるサービスを提供しています。

これにより、「企画」→「営業」→「顧客対応・ニーズのヒアリング」→「商品(レシピ)開発・提供」→「代金請求」→「アンケートの分析」というビジネスの流れを経験することができます。

その結果、多くの人に購入され、喜ばれるサービスの作り方や、お金の生み出し方を学んでいます。


4-1-2.売上計画が練られていない

・いつまでに、どれくらいの売上金額を達成したいのか。

・損益分岐点となる売上金額はいくらか。

・その売上金額を達成するためには、いつまでに何をすればよいのか(これがKPIになる)。

・登録ユーザーのうち、何%のユーザーが転職相談を行う(課金する)のか。

 売上金額を鑑みて、ユーザー登録数をどこまで伸ばす必要があるのか。

これらのことを考える時間を用意していませんでした。

僕は感覚派なので「やってみなければわからない!」と考え、先輩エンジニアサーチをリリースしてから考えようとしていましたが、今考えると、売上計画を練っていなかったことが、リリース後に売上をあげるために必要なアクションの明確化を妨げたと感じています。

今後は、類似のWebサービスのユーザー数や売上規模等を参考に、出来うる範囲で売上計画を作成します。


4-1-3.ユーザーが申し込むまでの導線の設計が甘い

これを明確にすることで、先輩エンジニアおよびユーザーを獲得するための計画を立案できますし、どこを改善していけばよいのかが明確になります。

これを行うための方法として、カスタマージャーニーマップがあります。

先輩エンジニアサーチを例にして説明しますと、先輩エンジニアおよびユーザーが、先輩エンジニアの登録申し込みまたは転職相談の申し込みを行うまでに、どのように接点を持ち、どのような体験をしてもらうのかを定義して時系列にまとめたものです。

そして、これはリリース後に気づいたのですが、先輩エンジニアサーチは、1人1人のユーザーが訪れる頻度は決して高くなりません。

もともと、エンジニアに転職するための相談先を探したくなる頻度自体が、月に1回もない程度の頻度だと思います。

そして、最初に訪れたときに、先輩エンジニアサーチを利用するメリットを感じなかったら、あるいは、登録している先輩エンジニア数やユーザー数が少なかったら、その人はおそらくもう二度と訪問することはないと思います。

これについては、カスタマージャーニーマップを作成していたら、事前に気づけたと思います。

先輩エンジニアサーチを訪れる頻度が日ごろから高ければ高いほど、ユーザーにとってそれが日常となり、身近な存在となって、人に薦めたり自分で利用してみたくなると思います。

しかし、日ごろから先輩エンジニアサーチを訪れたくなる仕掛けを、用意しておりませんでした。

先輩エンジニアサーチでは、カスタマージャーニーマップを作成していなかったので、今後は工数がかかったとしても事前に作成します。


4-1-4.マッチングサービスは僕の強みが活かせないビジネスだった

4-1-1でも触れましたが、僕は「カレーパフォーマー加藤」という名義ではてなブログを運営し、関東圏の名店やインドカレーの作り方、カレーの豆知識について執筆しています。

その結果、出張料理人としてカレーを作りに行ったり、複数のWebメディアに、カレーについての寄稿記事を提供しました。

また、某PR会社からテレビ出演の打診、某グルメ雑誌から寄稿の打診をいただくなど、各種メディアからお仕事のお問い合わせをいただく機会が増えています。

このように、僕自身のキャラクターを前面に出して、僕自身が価値を生み出して届ける(専門知識を教えたり、成果物(カレー)を納品するなど)仕事はニーズがあり、僕の得意分野です。

マッチングサービスのように、自分自身が前に出ず、出会いの機会だけをシステム(大部分は人力ですが)を通じて提供するようなビジネスモデルは、僕の強みが活かせないのだということに、運営してみて初めて気が付きました。


4-1-5.マッチングサービスを運営した経験がない

マッチングサービスを運営した経験があり、成功させるためのノウハウが豊富にあれば、大失敗の理由として挙げた大半の理由は回避できた(もしくはダメージが少なかった)と思います。

これについては、マッチングサービスを運営している企業の勉強会(ATND、connpass、Doorkeeper、TECH PLAYなどを活用して探す)に参加して社員にヒアリングする、運営者に直接アポイントを取って会いに行くなどの方法で、情報収集に行くことで対応します。


4-2.事前調査が不十分


4-2-1.何となくニーズがありそうだから作ってしまった

4-2-2で書いているような驕りもあり、僕の脳内で勝手に「ニーズがありそうだ」と感じて、先輩エンジニアサーチの開発に着手してしましました。

次回からは、ターゲットに当てはまる人たち複数人に、事前にヒアリングを重ねて、僕の仮説とどこが合致していどこがずれているのかをすり合わせる機会を設けます。


4-2-2.ターゲットに当てはまる人に事前にヒアリングをしていなかった

当初想定したターゲットは、このような人たちでした。

・ユーザー候補

 IT業界未経験からエンジニアへの転職を目指す社会人

 Webアプリケーション開発職に転職したいエンジニア

・先輩エンジニア候補

 DiCなどのプログラミングスクールでメンターを務めている人

 人に教えるポジションを目指しているエンジニア

 ITエンジニアに特化した人材系企業に勤める、元エンジニアのキャリアカウンセラー

 エンジニアとして自社の後輩・新卒のメンターを務めている人

ぶっちゃけると、僕の中で驕りがありました。

ユーザー候補にも、先輩エンジニア候補にも、僕自身が当てはまりますし、周りにもそういう人たちがたくさんいたことで、「自分はこの人たちのことをよくわかっている」と思いこんじゃっていたのです。

次回からは、ターゲットに当てはまる人たち複数人に、事前にヒアリングを重ねて、僕の仮説とどこが合致していどこがずれているのかをすり合わせる機会を設けます。


4-2-3.β版で公開し、ユーザーの感想をもらって改良していなかった

先輩エンジニアサーチをリリースする前に、β版としてリリースして、限られたユーザーに無料で使っていただくことで、運用実績作りとノウハウ蓄積を行うとともに、彼ら彼女らが抱えている課題や感想のヒアリングを行うべきでした。

確かに、コア機能に絞って最速で開発してリリースし、爆速でPDCAサイクルを回しまくって、仮説と検証を繰り返すことが大事と書きましたが、正式にリリースしたあとで誰もりようしてくれなかったなんて結果になっては本末転倒です。

機能を作りこむよりさっさとリリースして、ユーザーからフィードバックをもらって改善していこうという方針に変わりはありませんが、正式にリリースする前にもフィードバックをもらう機会を設ける必要があるなと感じます。

次回からは、最初はβ版としてリリースして、運用実績作りとノウハウ蓄積、ユーザーへのヒアリングを行って、十分に僕のWebサービスがビジネスとして成立しそうだと確信が持ててから、正式にリリースを行うようにします。


4-2-4.転職支援サービスは競合が多いレッドオーシャンだった

IT業界未経験から転職したい人向けの相談会やイベントは、DiCをはじめとしたプログラミングスクールや人材系企業(紹介・派遣など)が開催していたりします。

プログラミングスクールや人材系企業は、転職支援サービス(自分たちが扱っている求人の紹介や企業への推薦、職務経歴書添削・面接指導など)を行っていたり、それを通じた転職活動ノウハウも持っていたりします。

そこが競合他社となりますが、エンジニアが売り手市場なこともあり、そのようなスクールや人材系企業が増えていて(僕の肌感覚ですが)、レッドオーシャンとなっています。

個人が開発したWebサービスでレッドオーシャンを戦い抜くのは大変なので、今後は倨傲他社が少ない市場を選択するよう、開発前にリサーチを怠らないようにします。

また、レッドオーシャンの市場に参入するのであれば、自分のWebサービスでしか提供できない強みを確立できないのであれば参入しないことにします。


4-3. 集客が不十分


4-3-1.ターゲット層が属する母集団へのアプローチ方法がなかった

僕が接触できる、ターゲット層が属する母集団は、以下の通りです。


4-3-2.転職支援の専門家としての知見もノウハウがなかった

何故 "僕" が転職支援ビジネスを、"今" やるのか。

この問いに対する答えを、僕は未だに出せずにいます。

先輩エンジニアサーチと同じようなコンセプトのマッチングサービスを、リクルートグループの企業をはじめとした人材系企業、paiza(ギノ株式会社)、プログラミングスクールが展開していたら、その豊富なノウハウを活かしたサービスや情報提供を行うことができ、ユーザーを転職成功に導けると思います。

次回、Webサービスを開発するとしたら、僕がこれまでの業界経験や業務経験から培ってきた、専門家としての知見やノウハウを活かしたものにします。


4-3-3.マッチングサービスが軌道にのるまでのKPIの設定が不十分

ユーザーが先輩エンジニアサーチというサービスを認知し、訪問し、転職相談の申し込みを行い、相談料を入金し、転職相談が開始されるまでの一連の流れが存在しますが、その流れの中のどの段階までたどり着いたのかは、ユーザーごとに異なっています。

ここでいうKPIとは、転職相談が開始される(売上があがる)段階まで、全ユーザーの何%が到達すれば、目標の売上金額に到達するのかを計算し、そこから逆算して、それぞれの段階に全ユーザーの何%が到達すればよいかを定めた目標値を指します。

次回は、KPIの設定を事前に行うようにします。


4-3-4.効果が出るSNS活用方法・広告出稿ノウハウがない

先輩エンジニアおよびユーザーを効果的に集めるための、SNS活用方法や、Facebook広告などへの広告出稿ノウハウがありません。

次回は、類似したWebサービスが、どのようにSNSを活用し、広告を出稿しているのかを調査して、参考にします。


4-4.ユーザーが登録・利用したくなる仕組みがない


4-4-1.サービスが過疎っている

想像してみてください。

あなたが訪れたマッチングサービスを利用している人が皆無だったとしたら。

そんなマッチングサービス、使ってみたいとは思えませんよね。

4-2-3とも被りますが、まずはβ版としてリリースするなりして、先輩エンジニアとユーザーをある程度集めておいてから正式にリリースした方がよかったと感じます。


4-4-2.先輩エンジニアのインセンティブがない

特に、先輩エンジニアのインセンティブがないなと感じます。

当初は現金収入(相談料)の予定でしたが、それも特定商取引の関係で無料にしていますし……。

例えば、転職相談にのった実績が可視化されて、信用として蓄積される仕組みなどが用意できればよかったと思います。

先輩エンジニアの信用の蓄積の多さが、指導力の証だと認定され、講師やプログラミングスクールのメンターとしての採用時に有利に働くなどのメリットがあれば、先輩エンジニアにとってのインセンティブになりうると考えています。

次回は、Webサービスを利用したくなるインセンティブを、類似サービスを調査しながら設計していきます。


4-4-3.先輩エンジニアの人柄がわかりづらいから相談しようと思えない

先輩エンジニアの顔写真とプロフィールページは存在しますが、人柄まではわかりません。

しかし、ユーザーとしては、転職相談をする相手を決める上で、人柄が一番気になると思います。

プロフィールページ以外にも、先輩エンジニアごとのブログページを用意するなど、人柄がわかる仕掛けを用意する必要があったと思います。


4-4-4.チュートリアル(先輩エンジニアサーチを利用するときの説明書)が不親切

先輩エンジニアおよびユーザーに、先輩エンジニアサーチを活用してもらう上で必要となるのがチュートリアルだと思います。

せっかく先輩エンジニアサーチに魅力を感じても、利用の仕方がわからないと、その時点で離れていってしまうからです。

チュートリアルを用意して、先輩エンジニアサーチを利用するときの最初の1歩のハードルを下げることで、実際に利用してもらいやすくなりますし、最初の1歩がスムーズにいけば、継続して利用してもらいやすくなります。

(チュートリアルは、Webサービスよりもゲームなどでよく見かけると思います)

しかし、先輩エンジニアサーチでは、先輩エンジニアとしての登録申し込みまでの流れや、ユーザーが転職相談をするまでの流れは記載しましたが、それらを行うときの手順を詳細にまとめて、チュートリアルとして用意することはしていませんでした。

次回からは、チュートリアルも事前に用意しておきます。


4-4-5.チュートリアルを進めるモチベーションを高める工夫がない

よほどメリットがなければ、初めて触れるWebサービスのチュートリアルを進めていく時間や手間をかけることはしたがらないと思います。

次回、チュートリアルを用意する際は、チュートリアルを進めるごとに得られるご褒美と、それを乗り越えた先にあるメリットを提示して、モチベーションを高めるように工夫します。


4-4-6.チュートリアルでつまづいたときにそれを助ける仕組みがない

チュートリアルで躓いたとき、気軽に聞ける相手や、簡単に答えが分かるページがなければ、先輩エンジニアやユーザーは離脱していくと思います。

次回からは、FAQの用意や、24時間以内に返信するサポート窓口の用意をします。


4-4-7.運営事務局が信用できない

先輩エンジニアやユーザーの目線に立って考えると、個人が運用している、実績のないWebサービスは、安心して利用できないと思います。

・まずはβ版でリリースして、運用実績を残してから正式リリースをする。

・運営事務局(=僕)がブログやSNSなどで何者かを開示し、かつ、先輩エンジニアサーチについての情報発信をしていく(顔出しで)。

・特定商取引法に基づく表記を、Webサービス内で明記する。

これらを行うことで、信用を得ていきます。


4-5. サービス運営の仕組みが不十分


4-5-1.起こり得るトラブルの想定とその対処マニュアルの用意が不十分

・先輩エンジニアとユーザー間

・先輩エンジニアと運営事務局間

・ユーザーと運営事務局間

・先輩エンジニアとユーザーと運営事務局間

これらの間で起こりうるトラブルについては、想定しうる限り洗い出し、利用規約にてそのトラブルが起きた場合の対応を定めています。

しかし、実際に先輩エンジニアサーチを運営するなかで、当初は想定していなかったトラブルが起きることもあると考えています。

実際にWebサービス(特にマッチングサービス)を運営した経験のある会社や運営者にとっては、よくある話だとしても、経験がなければ想定もできず、マニュアルの用意もできません。

これについては、類似したWebサービスを運営している企業の勉強会(ATND、connpass、Doorkeeper、TECH PLAYなどを活用して探す)に参加して社員にヒアリングする、運営者に直接アポイントを取って会いに行くなどの方法で、情報収集に行くことで対応します。


4-5-2.先輩エンジニアの人間性・スキルの査定・評価方法が不十分

先輩エンジニアは転職相談に乗る側ですから、技術者として一流のスキルや知識を持っていることよりも、IT業界未経験者の目線に立てることや相談相手の話をきちんと受け止められることなどの、優れた人間性や高いコミュニケーションスキルが必要とされます。

それを適切に査定・評価して公開することが、新規の申し込みやリピートにつながると考えています。

このための仕組みを構築できていないですし、先輩エンジニアへの登録申し込みがないので、先輩エンジニアと接する経験を経て徐々に構築していくこともできずにいます。

これは今後も向き合う課題だと感じています。


4-5-3.先輩エンジニアのサービス品質の維持と向上策が不十分

これは4-5-2とは違い、先輩エンジニアが転職相談に乗る上で必要となるスキル・知識を高めるトレーニングや研修制度の話です。

このための仕組みを構築できていないですし、先輩エンジニアへの登録申し込みがないので、先輩エンジニアと接する経験を経て徐々に構築していくこともできずにいます。

これは今後も向き合う課題だと感じています。


4-5-4.顧客管理の仕組みが不十分

これはCS(カスタマーサービス)の話で、先輩エンジニアやユーザーは、どのような属性(性別・年齢・職業・住んでいる地域・抱えている課題など)を持っていて、どのくらいの頻度で先輩エンジニアサーチを活用してくれているのか、運営事務局とどのようなコミュニケーションを取ってきたのかを管理しておく必要があると感じます。

これを管理しておくことで、よりその人にぴったりにサービスが提供できますし、どのような人たちがメインターゲットとなるのか理解を深めることができます。

先輩エンジニアもユーザーもいない段階でこれを行う優先度は低いですが、まずは、ExcelやGoogle スプレットシートなどでの簡易的な台帳を作成します。


第5章 これは終わりではなく始まり


5-1.コア機能でWebサービスをスクラップ&ビルドを繰り返せ

僕はこの同人誌で、先輩エンジニアサーチというマッチングサービスで大失敗した経験をお話ししましたが、全く凹んではいません。

先輩エンジニアサーチのリリースを通じて、「Webサービスを作りきる」という経験と「先輩エンジニアサーチはターゲットに刺さらない」という学びを得ました。

これからも僕は、ターゲット(IT業界未経験から転職したい人)に刺さるWebサービスを企画してはヒアリングを重ねて、β版をリリースしてフィードバックを受け、正式にリリースしては打ちのめされて、またゼロから作り直して………とスクラップ&ビルドの毎日を送ると思います。

この大失敗は、終わりではなく始まり。

エンジニアとしての大いなるネタ作り。

そのように捉えています。


第6章 自社でもマッチングサービスを始めたくなったら

「私の会社でもマッチングサービスをはじめようと考えています。」

「つきましては加藤さんに一度御相談したいor開発を依頼したいのですが……」

という連絡をこの記事をご覧くださった方がくださるケースが増えてきました。

大変恐縮なのですが、私も本業があるため、お寄せくださるすべてのご要望にお応えすることが難しい状況です。

そこで、マッチングサービスを自社でもはじめたくなったときにおすすめの方法を2つご紹介します。


6-1.プロブロガーのマナブさんに依頼する

ブログやYoutubeで稼いでおり、プログラミング経験も豊富な「マナブ」さんをご存知でしょうか。

マナブさんは「ノマドワーカー向けの出会い系サービス」開発に取り組まれており、その裏側をSlackで公開されています。

https://manablog.org/nomad-couple02/

また、それ以外にも「留学経験者に〝直接相談できる〟マッチングサイト」を開発されています。

マナブさんにあなたのマッチングサービスの企画を提案したら、出資開発のサポートが受けられるかもしれませんのでまずは彼に相談してみるといいでしょう。


6-2.WordPressで私のように開発する

WordPressでの開発手順を丁寧に解説した記事をQiitaで公開しました。

https://qiita.com/curryperformer-kato/items/6342fddc181e4d1df53f

WordPress製なのでそのまま商用利用するのはおすすめできないですが、そのサービスに需要があるかをテストするためのベータ版としてご活用いただけることでしょう。

(※)ハッカーに攻撃を受けやすい、機能が十分ではないなどの理由から。


6-3.モール型CMSやASPを活用する

モール型CMSのマレントやASPのマッチングサイトPlusを活用することであなたの会社でもマッチングサービスを始めることができます。

それらは当然有料ですが、エンジニアを雇う必要もプログラミングを覚える必要もありません。