開発外注を行う際に抑えておきたい留意点

 t-okadaです。

私は普段ブロックチェーンの基盤を提供しているスタートアップベンチャーに所属し、そこでPMとして活動しています。PMとしてのキャリアは現在(2020年6月)まで1年半 ~ 2年程で、それまでは営業や開発など経験しました。

今回は私が過去に在籍していた組織で一部アプリ開発の外注を行っていたのですが、その際に感じた注意したい点をまとめてみました。

なお、既に外注を行なっている方であれば、役立つ部分は少ないかなと思います。

この記事を読んでもらいたい方

・現在業務でPMをやられている方

・プロジェクトで開発外注を行う可能性のあるPM

・これから開発外注を行う、もしくは検討している方

よく行っていた外注

前述しましたが、私はブロックチェーンの基盤を提供している会社に所属しており、そこで主に決済系のプロジェクトを統括していました。

プロジェクトの各者の役割としては、私たち側は基盤 + APIを提供し、それと連携するUI部分を外注するといった発注です。

今回はそれに関する過去にあったケースとどう対応すればよかったかを書いてみたので、是非参考にしてみてください。

太字で書かれた3つに分けてみました。

提示された受注金額が妥当か？

後に色々と注意したい点を色々記述していますが、個人的にはここが一番重要かつPMが注意を払うべき点かなと思っています。

なぜなら、外注先が提示してくる人月と金額は必ずしも妥当な金額とは言えないという経験をしたからです。

通常、金額はプロジェクトの開発にかかる人月および、その人月単価の掛けた合計額と保守運用の人月の金額、そのほか初期費用などの合計で算出されるかと思います。

その中で一番ポイントは人月の算出であり、どのくらいのコミットで各機能やモジュールを開発できるかというのが、各社の見込みの認識が変わってくる部分です。

1つ例にあげると、私はアプリの開発外注を依頼していたのですが、以前行ったプロジェクトで使用したサービスを横展開するケースがありました。

その際、以前行なったプロジェクトに機能がいくつか追加されたため、その分の金額が上乗せになるのですが、以前開発した機能に関しても変わらず同額の人月が算出されていました。

上記の原因は、主に下記のようなものでした。

・短いスケジュールかつ外注先もスモールなチームでの作業であったので、バッファを多めにとっていた

　-> タイトなスケジュールであったため、各機能単位の見積もりに0.5 ~ 1人月上乗せされていた

・決裁者と金額の整合がとれていなかった　

　(これは会社の本部がエンジニアの人月単価が決まっており、現場担当者がこれを修正できないものと考えていた。これについては、発注側も決済者の確認を早めの段階でとるべきだったなと思います。)

人月に関しては各社設定が違うため、定義が難しいところでもありますが、

例えばアプリケーションサービスの場合、共通機能のAPI連携であれば、単純にいえばソースの使い回しが可能なため、人月の削減が可能です。

よって、PMとしては技術的に前回のプロジェクトで使用した機能を使い回しが出来るかなど、細かいチェック必要と考え、プラスして技術的な観点での交渉も持ち合わせていると強いかと思います。

ここで外注先も詰めすぎない点も重要です。

あまりシビアに交渉してしまうと、折れてしまい、逆に絶対に終わらない量の開発を承諾してしまったり、あるいは厳しいが故に交渉を受け付けないなどの可能性も十分考えられます。

参考までに、これらの開発人月の確認を行った結果、約100万以上削減できたケースがありました。

PMをやられている方でエンジニアのキャリアがなく詳細な技術仕様や開発の手間がどの程度なのかわからないといった方もいるかと思いますが、その場合は各技術に詳しいエンジニアに相談してみても良いかと思います。

開発の優先順位は適切か？

これは、API連携をするときなど特に意識して欲しいのですが、

外注先が常に開発が続いている状態を保てているかという点を意識することが大事かと思います。

いくつか例にあげると・・・

・コイン送金を行うに当たっては、まずアカウント周りの認証のAPIが通らないといけないのであれば、ログイン(アカウント認証) -> 残高確認 -> 送金といったような開発順序が適切となる。

・もしアカウント認証APIに不備がある場合は、ログイン周りの機能とそれ以降のAPI連携ができないため、UIや入力バリデーションに関わる機能を先回りで作成をお願いする。

など、想定される懸案を洗い出し、先回りで外注先に対応策を提示しておくのも重要です。

常に外注先の開発が止まらないようにすることが、余裕を持ったスケジュール管理が可能になるかと思います。

また開発の優先順位の話ではないですが、よく私が行なっていた外注先のスケジュール管理として、アジャイル形式のような形でその日に行なったタスクを退勤前にスラックで共有してもらうといった形式をとっていました。

こうすることで、外注先のエンジニアも小さなことでも進捗を出さなければならないといった意識が芽生えるかと思います。

適切な契約を締結できているか？

システム開発委託契約、アプリ開発委託契約、ラボ契約色々な契約とややこしい名前がありますが、これらは最終的に請負、準委任、委任にのいずれかに分類できます。

上記の点で適切な契約ができているかを確認するのが、重要な点かと思います。

ただし所属会社の意向もあるため、それぞれ要件定義時点でのスコープを適切に決め、契約を締結することが大事です。

例えば、請負の場合は最終的に出来上がった成果物(当然使用要件を満たしている)に対して報酬額を支払うため、無理なスケジュールや開発スコープを設定してしまうと非常にタイトなプロジェクトとなってしまいます。

例えば準委任、委任に関しては、作業に対して報酬額を支払うため、すでにサービス開発など進めていれば、その分は支払われます。

※ ただし、当然ですが成果物を納めなくて良いということではないです。

サービスに対して締結する契約も様々ですが、オンボードプロジェクトに対してお客様が自社と何を締結しているのか把握するのも大切な観点かと思います。

まとめ

上記、3点は簡単に言ってしまえば、コストとスケジューリングの確認、それによる契約の影響度の話かと思いますが、いずれも重要な点かと考えています。

昨今、自社開発だけでなく、いろんな企業に開発を外注するプロジェクトも増えてきましたが、もし外注する機会があれば是非上記の点を注意してみてください。