外部の技術顧問/技術アドバイザー/技術コンサルタントなどをアサインするときに考えること
まえがき
新しい技術や、技術的な課題を解決する際に、外部の有識者をアサインするのは良い方法だと思います。
ただ、正しくチームのスキル状態を把握していないと 「何も変わらない…」 となってしまうことも多いです。
最悪の場合 「前よりも悪くなってる…」 というパターンも発生するでしょう。
弊社が技術アドバイザーをアサインする際に、検討したことを書きます。
外注はお金以外のコストが掛かる[1]
金銭的な人件費原価の他に、サンクコスト（見えないコスト)が発生します。
主に３つの区分があり、総称して取引コストと言われます。
DevOpsの言葉を借りれば、「外注のスキルだけに頼るプロダクト開発はコラボレーションコストが溜まりやすい」となるでしょうか。[2]
これらの取引コストを考慮して、それ以上の価値が発生するかどうか見極めることが大切だと思います。
探索コスト
外注先の選定に掛かるコストです。
技術コンサルをいれるときって、どういう人がつよつよなのかわかっていない事が多いため見極めるが大変難しいです。
交渉コスト
ちゃんとした外注であれば、契約書/NDAを巻くため、条件交渉をします。
また双方でリーガルチェックをする時間も発生します。
監督コスト
納品物の検品や、クオリティがちゃんと維持されているか
クオリティ維持のための矯正など
技術アドバイザーは銀の弾丸ではない[3]
上記の監修コストで要約していますが、技術アドバイザーをアサインして
「勝手にいろいろ問題を分析して、経営/プロダクト/技術/チームスキルを考慮した上で適切な技術アドバイスをしてくれる」
ということは基本ありません。発注した我々がリソースを割いてマネジメントする必要があります。
本当に困っているのか？ 課題を言語化できるか？[3:1]
- 手を動かす人が足りない
- 根本的に課題がわかっていない。なんかやばい感じ
- 機能実装が遅いから技術アドバイザーを入れたい
これらのような課題であれば、技術アドバイザーのアサインをせずに、社内で一度ビジネスレイヤーから考え直す必要があるかと思います。
ドキュメント(仕様書等)は揃っているのか？
スタートアップのPMFフェーズ前は、ドキュメント書くよりとにかくコードを書くことが多いと思います。
仕様書が全くないと、仕様の確認をするコミュニケーションが多くなります。
ある程度のドキュメントが揃っていない場合、コミュニケーションの不確実性が高いため、発注前にドキュメントの整理をすることをおすすめします。
技術アドバイザーは社員ではないので、課題が解決したら即解約する[3:2]
あくまで知見を得るためにアサインするものだと私は思っています。
契約書に再委託の条項があれば消してもらう
リーガルチェック時に再委託の記載があれば消してもらったほうが良いと思います。
もちろん双方同意であればいいですが、多重下請けや、ジュニアがアサインされるリスクは考慮すべきです。
初期で長期契約を求めてきたら黄色信号[3:3]
できれば最初の1~2ヶ月は、即時解約できる契約をすると良いです。
万が一、スキルフィットやコミュニケーションが取りにくそうと思った場合に即解約できます。
技術アドバイザーとしての実績があるか？
可能であれば知り合いから紹介してもらった技術アドバイザーなどをアサインするのが良いと思います。
本人から実際のワークスタイルや、雰囲気も確認できます。
実績の調査が難しそうな場合、よっぽどの理由がなければ別の技術アドバイザーにすることで失敗のリスクを下げられます。
ビジネスの理解があるか？
スタートアップであれば、「PMF」「シードラウンド」「シリーズA」「資金調達」「MVP」「リーン」
など最低限の用語理解があり、そのフェーズに適した技術提案ができるかどうか確認する必要があります。
-
広木 大地 / エンジニアリング組織論への招待 P.275 5-4.取引コストと技術組織 ↩︎
-
O'Reilly Japan / Effective DevOps ―4本柱による持続可能な組織文化の育て方 P.92 ８．１ コラボレーションの誤解 - 8.1.2 急成長したいときにはロックスターを採用しなければいけない ↩︎
Discussion