「いいエンジニアおらん？」という相談はよく受けますが、なかなかいいエンジニアは簡単に採用できない昨今、ソフトウェア開発を外注する会社もたくさんあると思います。

ただエンジニアいない会社が開発を他社に丸投げして、なかなか思うように成果物が上がってこなかったり、出来上がったものが思ってたのと全然違うみたいな話もよく聞きます。

そこで、発注側に開発の知識がなくてもこういう風に開発会社と付き合えば失敗する確率を減らせるんじゃないかという方法を書いてみます。

SPONSERD LINK

開発フロー

ぼくはずっと自社サービスの会社で仕事をしているのですが、内製する場合のフローをベースに、発注する側のタスクと受注する側のタスクに分ければわかりやすいかと思います。

全体のフローはこんな感じです。

  1. [発注側] やりたいこと、解決したい課題を明確にする
  2. [受注側] 要件を元に、できるだけ小さい、かつ意味のある単位に分割する
  3. [受注側] 各タスクに対して概算の見積もりを出す
  4. [発注側] 各タスクの優先順位を決める
  5. [受注側] 各タスクごとにアサイン→実装
  6. [発注側] 各タスクごとに受け入れテスト
  7. 問題なければ次のタスクへ
  8. [発注側] 新しい要件は思いついたら都度追加
  9. [発注側] 定期的に残タスクの優先順位見直し

プロジェクト開始前に1〜4を実施、開始したら5〜7をぐるぐる回しつつ、定期or不定期で8・9を実施します。

普通の丸投げと一番違うのは、確認の頻度だと思います。

全部作り終わるまで待って最後に確認するからズレが大きくなるのであって、画面ごと、機能ごとに確認を入れれば同じ期間開発した後のクオリティは格段によくなるやろうという発想です。

優先順位について

4と9の優先順位ですが、これはタスクごとに優先度高〜低をつける「ラベリング」ではなく、どの順番で作るかという「並べ替え」です。ラベリングは結局優先度高ばっかりになりがちなので全然意味ないです。

受け入れテストについて

最初の要件定義でどれだけイメージが出来上がってても、実際に作ったものを触ってみると「やっぱここはこうしたい」とか「これがあるならこれも必要ちゃう？」みたいなのは往々にして出てきます。

なのでタスクごとの受け入れテストでは、要件通りに実装されてるかという点と、そもそも要件変えたり追加要件を足したりする必要がないかという両面でチェックするといいと思います。

契約形態

ぼく自身は受託開発の会社で仕事したこともなければ受託開発の会社に丸投げしたこともないので実際こういうフローで進めさせてくれる会社がどれぐらいあるのかわからないですが、頻繁な要件の追加・変更とか優先順位の変更を受け入れてもらおうと思ったら、プロジェクト全体でいくらじゃなくて、毎月いくらで延長するかどうかは都度考えるみたいな形態じゃないと成り立たないと思います。

エンジニア採用して毎月給料払う代わりに、よその会社に毎月委託費用払うイメージですね。

先ほど「ラベリング」ではなく「並べ替え」をするという書き方をしましたが、きちんと並べ替えができてれば最後の方はどうでもいいタスクばっかりになってるはずなので、「もうこのタスクしか残ってないなら今月で終了でいいや」っていう線引きをするのに重要になってきます。

確認とか優先順位見直しの頻度はケースバイケースだと思いますが、例えば最初の見積もりで3ヶ月のプロジェクトなら毎週〜隔週ぐらいで定例MTGをセットして、前回の定例から実装が終わったところをその場で確認しつつ次の定例までにやることを決めるみたいな流れが現実的かと思います。

あとそもそもどの会社と契約するかという段階では、2・3の最初のタスク洗い出しと概算見積もりを詳細にやろうとするとその時点である程度の設計が必要になってそれなりの工数が発生したりするので、無料でどれぐらいちゃんとやってくれるかとか見積もりだけでいくらぐらい取るかとかは会社によって色々あるんじゃないかと思います。

最後に

弊社ではぼくが唯一のフルコミットエンジニアなので、上記1〜9のうち発注側タスクは社長と一緒にやる、受注側タスクは基本全部ぼくがやりつつ実装の一部を業務委託の方にお願いしてぼくがコードレビューするという感じでやっています。

これが実際にエンジニアじゃない人だけでこのフローがうまくいくかは実績がないのでわからないですが、ソニックガーデンさんとかは実際にこれに近いフローでやってもらうように受注側から提案してはるんちゃうかなあと思っています。別に回し者でもなければ中の人と知り合いなわけでもないですが。

参考： 納品のない受託開発

ということで、少しでも外注で失敗したくない方の参考になれば幸いです。