スタートアップCEOは、エンジニアリングとどう付き合うべきか？

これまでシステム開発会社を経営してきて、周りの経営者からこんなシステム開発にまつわる相談やしくじりを聞くことがあります。

自社に定着してくれるエンジニアを採用したいが、募集が来ない

外注すると怖い、自社にノウハウを貯めたいけど、エンジニアの採用がわからない。

良いエンジニアの見極め方がわからない・・以前経歴を見て採用したけどパフォーマンスが全然出なかった。。

これまでインターンを受け入れてきたけど、入社につながらない。。

今回はそんな悩みへの回答をまとめてみました。

主に立ち上げたばかりのスタートアップ、設立数年のベンチャーを対象として書いています。

よくあるシステム開発周りのトラブル

その１：優秀そうなエンジニアに来てほしいからCTOポジションでオファーしたけど、期待に全くそぐわなかった。。

CTOの役割は組織の大きさによって変わってきます。

特に設立まもないベンチャーの場合には、プレイヤーとして高速に実装をすることを求めていることが多いかと思います。

ですが、CTOという名前からマネジメントに注力し、開発は外注すれば良い、という考えをするエンジニアもいます。

このあたりの期待値が揃っていないまま、エンジニアが入社してくれたことを喜んでしまうと、後から期待値のギャップが明らかになり、険悪なムードになりCTOが退職していく、、ということになりがちです。

その２：外注が怖いから、知り合いのエンジニアにお願いする。

知り合いだからこそ、裏切らない、信頼関係が置ける、というところから発注されることが多いのですが

納品されたシステムに問題がある際に強く言えない、責任を追求できない、と、人間関係があるからこそいうべきことが言いづらい、ということがあります。
お金を積んででも、組織である法人に依頼し、開発に関わる部分はお互いにフェアな状態で会話できる関係性のほうが良いかと思います。

その３：インターン生や大学生などを雇ってとりあえず作ってもらう

コストもかけられないし、作るシステムもツールレベルの簡単なものだから大丈夫、といってやりがちななのがこちらのパターン

そのインターン生が抜けた後、そのシステムを保守する人がいなくなり、メンテに困ることが非常に多いです。

既存システムの保守運用は、割と難易度が高いので敬遠されがちでブラックボックス化されたシステムだけが残される、、という感じになります。

その４：自分でプログラミングを勉強する。

起業したての起業家がやりたがるのがこちら。
気持ちはわかる、、が、学ぶべきことが多いので、最低３ヶ月から６ヶ月はガッツリ勉強する時間を取らないと実運用に耐えられるシステムは作れないんじゃないかと思います。

それでは何が大事か？

システム開発の本質を押さえて、適切にエンジニアと付き合うこと。

１つ目：「システムとはつまり、仕組み化のことである」

最も安く発注する方法は、すでに業務が回っており、仕組みができる領域に限って開発をする、こと。

新規事業の際に、この機能がないと回らない、動かない、と言われることが多々ありますが、もしその業務を一度も回したことがなければ
ぜひ一度、手動で回せるところまで回してほしいです。
そうすると、定形業務と非定形業務が見えてきます。

定形業務とは、マニュアルしたとえばアルバイトでも誰でもできる業務の部分を指します。

まず最初に、これをシステム化しましょう。

いきなりすべての業務をシステム化しようとするから、費用が高くなり、バグが増え、リリースが伸びるのです。

なので、コストを抑え、利益を生むシステムを作るためには、上記の業務→仕組み化→システム化のステップを踏む必要があるのです。

まとめ＝＞人が通ったところに道ができる、人が通る道を舗装したほうが喜ばれます。

２つ目：「エンジニアの見極めはこうしよう」

色々諸説あるかと思いますが、インターンやフリーランスなど直接エンジニアとやりとりできる場合には仕様ではなく、どのように使いたいか、なぜその機能が必要なのか、ビジネス的なバックグラウンドから話すと良いと思います。

一定のレベルのエンジニアであれば、相手のビジネスモデルを理解し、それを仕組みに落とす力を有しています。
逆に仕様しか伝えないと、仕様通りにしか出てこない（またはそれ以下）ので、都度都度開発内容を確認し、細かく仕様を確認する必要が出てきます。

逆に法人に発注する際には、依頼内容に対して、どれだけ突っ込んでくるのか、Noを言うのかを見てみると良いかと思います。
つまり、依頼者の仕様をそのまま受け止めて、細かい仕様を確認してくる、

それよりも、そのビジネスならば、このような仕様が良い、こういう作りにするほうが良い、と依頼を元に提案が出てきたり、リリースの進め方なども提案してくれる会社がベターかと思います。

まとめ=>エンジニアは仕様を知りたがっていると思われがちですが、ビジネス背景から話したほうがエンジニアのパフォーマンスを１２０％引き出すことができますよ！

３つ目：「システムは３回生まれ変わる」

外注すると会社にシステムを握られるのが怖い、法人取引なので冷たくされるのが怖い
フリーランスなどよりも、自社にエンジニアをおいてコントロールできるようにしたい

周りの経営者からもよく聞く声です。
気持ち、よーくわかります。

ですが、社内にエンジニアを採用するために、どれだけの時間＆コストをかけていますか？

採用コストも意外と高いので、それであれば、その採用コストでシステムを作り、それで上がった売上で採用するほうが良いと私は考えます。

システムの構造を最初からわかっているエンジニアが社内にいるほうが安心できるという声が聞こえてきますが、システムはビジネスのステージに合わせて変化し、時には作り直すことも出てきます。

起業初期のシステムは、ビジネスの急成長とともに急速に拡張する必要が生まれ、追加改修や作り直しなどが発生する事が多いので、途中からのキャッチアップでも問題ないことが多いです（特に初期のシステムはそこまで複雑なものではないので、数ヶ月も触っていればフォローできるでしょう）

まとめ=>見えないお化けより、存在する人間のほうが怖い、とはよく言ったもので、将来の不安よりも売上を１日も早く上げるようにシステムを組むのが経営上は良いかと。

最後に

立ち上げ初期のシステムは、なるべくミニマムに作る

システムの開発は、ビジネスサイドからシステムを捉えられる人/法人に依頼する

石橋を叩くよりも渡ってみる、それこそがベンチャーではないでしょうか。