今日は僕が6年以上、エンジニア問題に苦闘して学んだ「エンジニア採用」「エンジニア問題」の解決法についてのお話。これを読めば、エンジニア問題が３倍早く解決すると思います。

僕の会社でいえば、開発が絡む事業をやり始めて、4～5年目くらいから、スムーズに開発が進んだなーと思っています。（マジ、大変だった…）

※10～50名規模のベンチャー経営者の方が参考になる記事です。

※僕が携わった開発案件は「AIアプリの開発」「ニュースアプリ（IOS・Android）」「マッチングアプリ（IOS・Android）」「WEBツール・サイト」等、多岐にわたります。

補足：僕の紹介・実績

コツ１．結局、PMが全て。PM採用に投資する

結論、開発案件がスムーズに進むかどうかは、8割方、PM（もしくはCTO）が優秀かどうかにつきます。いくら優秀なエンジニアが複数いようが、PMのスキルが低いと開発案件はスムーズに進みません。

僕の場合も、PMを入れ替えることで3倍以上のスピードで開発が進んだことがあります（バグも激減）。また、優秀なPMの周りには、優秀なエンジニアがいるので、芋づる式で優秀なエンジニアを獲得できます。

結局、どんなプロジェクトであっても責任者が優秀かどうかで、ほぼ決まるということです。

コツ２．上場してる開発会社を選ぶ（と、失敗が少なかった）

オフショア会社を利用する際は「上場してる会社」を選ぶことで失敗を少なくすることができます。なんだかんだ、上場してる会社は、しっかりしているので、外れをひきづらいというのが僕の体感です。（上場してない会社が、全て微妙というわけではないです。あくまで失敗確率を下げる方法と考えてください）

特にオフショア会社を選定する際は、上場してる会社（グループ会社でもOK）を目安に選ぶというのは、1つの有効な手段だと思います。

費用はその分あがるケースも多いですが、会社選びを失敗し、2〜3倍開発スピードが遅れる可能性を加味すると安いものです。

コツ３．仕様書（要件定義）を完ぺきにつくれ！

開発の問題は、仕様書を丁寧に作るだけで、大きく改善します。

「仕様書を雑に書いて、あと出しで修正」は、とにかく最悪。「たった1個、あと出しするだけで100万損する」くらいの気持ちで仕様書は丁寧に書き、PMとのすり合わせも丁寧に行いましょう。

ココをさぼると、そのプロジェクトに関わる全員に迷惑がかかります。結果、プロジェクトの開発期間も長引き、コストも増えてしまいます。

ビジネスサイドの人からしたら「どうやって仕様書書くんだよ！」ってなると思います。が、2〜3個仕様書の例をみれば、優秀な人なら「だいたいこんな感じね」ってわかります。あとは1回1回本気で書いてみて、経験をつむしかありません。

僕も我流で仕様書を書いていましたが、最終的にはエンジニアとの認識のズレは、ほぼなくなり、スムーズに進むようになりました。要は「エンジニアにやりたいことが、正しく漏れなく伝わればOK」「全体の設計がロジカルになっていればOK（※ロジカルじゃないことはシステムで実現できない）」です。

※　実際の仕様書の実例は、公の場だと公開できないので、もし興味あればFacebookメッセンジャーで個別にご連絡ください。僕が書いた仕様書を渡せる範囲でお渡しします。

https://www.facebook.com/yuuki.kurokawa.50/

仕様書の実例って、ググっても出てこなくて困るんですよね。一度見てもらえれば、参考になるとは思います。

※　経営者向けのエンジニア短期スクールもあるので、僕は絶対行ったほうがいいと思います。コードは書けなくてもいいですが、「構造を理解して、エンジニアと議論ができる」レベルには、到達すべきです。

補足：仕様書作成のポイント

• 仕様書は『図』でも書く（特に、ユーザー遷移図）。視覚的に説明できたほうが勘違いが減る。

• エンジニアに説明する前に、仕様書を3回はチェックする。誤字脱字も、漏れもゼロに。端的に。

• 迷う機能はいったん省く。とにかくシンプルに設計。（そのほうがユーザー体験もよくなる）

• 海外のエンジニアがチームにいる場合、そのエンジニアがビジネスレベルで話せる言語に仕様書を翻訳。翻訳したものを見て、意味を間違えて翻訳されてないか自分でもチェック（エンジニアの間で勝手に翻訳してくれるが、翻訳を間違えてるケースがあるので、必ず自分でもチェックすること）。

• 「PM＋QC（品質管理担当※バグチェックとかする人）」と必ず仕様書の読み合わせをする。2回は読み合わせをする機会を設けたほうがいい（※1回説明するだけだと、意外に伝わってなかったりする。再確認した際に「そこ、そういう意味じゃないよ」という勘違いが発生してたりする）

補足：PM（もしくはCTO）候補が優秀かどうか、どう判断する？

以下を聞いて判断してください。

※各項目に対して、具体的にどういう基準を設けるかは、知人の優秀なPM（かCTO）に相談して決めるといいです。見るべき項目としては上記でよいと思います。

※「抽象的な考え方の質」については、ビジネスサイドの方が判断するのは難しいので、知人の優秀なPM（かCTO）に、PM候補と話をしてもらい判断するのがベターです。

※ 可能なら、直近で携わったサービスも見せてもらってください。

補足：PM（もしくはCTO）候補を、結局どうやって採用する？

結局、その優秀なPMをどうやって採用するのか。これは、根気強く探し続けるしかないです。ここの採用に裏ワザはない気はします。

そのプロジェクト自体が技術的にも、内容的にも面白いものであれば、興味を持ってくれるエンジニアの方は多いです。あとはタイミングの問題です。

優秀なPMの方を探し続け、出会ったら、連絡先を交換し「手が空いたら必ず一緒にやりましょう」と口説いて定期的に連絡を取り続けることです。「必ず手が空く」タイミングはくるので。

仮に10人の「優秀なPMの方」と連絡先を交換でき、全員がプロジェクトに興味を持ってくれたとしたら半年以内に手が空いて、プロジェクトに参加してくれる方が1名はいると思います。

その間に仕様書作成、デザイン作成、その他できるテスト（例：事前申込ページを簡易的に作り、CPAテスト etc.）をやっておけばいいんです。ここは急ぎたい気持ちもわかりますが、焦ってはダメです。微妙なPMとプロジェクトをスタートしたら、お金もムダに浪費し、プロジェクトも前に進まないです。めちゃくちゃなコードを、書き直すことほど、大変なことはありません。結局、遠回りをすることになります。

優秀なPMさえ見つかれば、その下についてくれるエンジニアや外注もすぐ見つかるケースが多いです。とにかく優秀なPMを1人探すことに注力してください。そこが崩れると開発はうまくいきません。

※PMを探してる間にやるとよいテスト
１．「LINEの事前登録ページ」を作り、広告を出してCPAテスト
（※「こういうサービス作ります。LINEで事前登録してくれたら、こんな特典つきます」といったようなページ。そもそものニーズがあるかのテスト）
２．（可能ならモックアップを作り）ユーザーインタビューをしてUIUXの改善
⇒　上記やっておくだけで、開発のムダな工数を激減できます。「つくってみたけど、全然CPA合わず、ダメだこりゃ」ってこともよくある。「作ってみて、実際、触ってみたら、使いづらすぎ！仕様変更だ！」ってこともよくある。この2点を先に潰しておくだけでも、開発のムダな工数は激減します（開発コストも下がる）。PMを探してる間に、こういったことをやっておけばいいんです。結果、近道になりますよ。

まとめ

以下３つを意識して、とにかく焦らないことです。

ベンチャーは「スピードが命」なことは僕もわかります。ただし、開発案件は「PM（もしくはCTO）」で最高の人が見つかるか次第で、ほぼすべてが決まります。そこを雑に選定したら、必ず泥沼にはまります。

最後に…人事をもっと進化させたい

人事は、経営インパクトが大きい。でも、世の中に体系的なセオリーは存在しない。だから、我流でやるしかないし、本や、ネットを調べても「良いフレームワーク」や「使える戦略・戦術」も、中々見つからない。

だから、エンジニア採用の攻略に、4～5年かかったり、評価の仕組みをゼロから作って、ちゃんとワークするようになるまで結局、1年かかったり。

人事、非効率すぎ…！

人事のセオリーが体系的にまとめられてたら…もっと効率よくできたのに。そんな悩み、絶対ありますよね？

何かよい解決策ないかなーとずっと考えてました。

で、こんなのどうかなと。

人事に本気で向き合う経営者（5～100名規模のベンチャー限定）が集まって
人事を経営＆マーケティング視点で体系的に学べる会みたいなのを創りたいなーと思ってます。

ベンチャー経営者って部分部分での「人事の成功ノウハウ」は持ってると思うので、同じ壁にぶつかった人に相談できるだけでも、一気に問題解決スピードがあがるのかなと。

つまり、自分で我流でやっていたら、半年かかった採用・組織の問題が、５分で解決することをメリットにした会。

もし、そういったことに興味ある方いれば、ぜひFacebookにメッセージください。一緒に効率的に人事の問題解決しましょう。

https://www.facebook.com/yuuki.kurokawa.50/