サービス開発を外注する際に１社に依頼するのはかなり危険だと思う。というのも最近airteamで開発の相談に乗るようになって多い相談が１社に外注しているけどその会社の提案、見積もりが妥当か分からないから見てくれというものだったりする。
１社だけに依頼してブラックボックス化されてしまい、見積もりだったりを言われ放題になっている会社って結構あるんじゃないかなと思う。今回はそもそも座組みの何が問題なのかと対策について考えてみた。これは開発をする際の座組みや業界構造など仕組みの問題なんかなと思っている。
実際にあった炎上案件
実際に相談であった案件だが
- 1年近く続けているwebサービスの開発、保守
- クライアント側にはエンジニアがいない
- １社にのみ外注
- 現在は保守で定額で取り、新規開発時は別途見積もり
という状態だった。で、これですごいのが開発会社がちょっとした開発でも物凄い金額を要求してきてクライアントが本当にこれが妥当なのか見て欲しいというものだった。
例えば一箇所デザインを変えるというものでcssを二、三行変えるもので40万請求されたりしていてそれはさすがにおかしくない？ということで他社に乗り換えて1,2時間ですんでしまったりした。
保守もちょっとバグが出た際にかなりの金額を別途求められて保守すらかなりの金額になっている状態だった。
しかし、クライアント側には技術的に言い返せる人がいないし、他社にレビューもしてもらっていなかったので言われ放題だった。
レビューを入れることでなんとか対処
で、そこでairteamで開発の進め方の相談や開発会社の提案のレビューを行っていった。クライアント側もおかしいなと思っていたけど色々話していく中でついに堪忍袋の尾がきれて契約を切って違う会社に引き継ぐことになったが今度はその引き継ぎ資料をなかなか作らなかったりでそこでも結構揉めにもめた。。。
だが、こちらが見積もりのレビューができるようになり、色々突っ込むようになったので向こうもあまり美味しくない案件と思ったのか引き継ぎを段々してくれるようになり、無事に引き継ぎが完了しつつある。
web開発を一社独占にする怖さ
上記の案件って実は結構色んな所で起きているよなと思う。というのもwebサービスの開発って継続するほどブラックボックス化するし、そのブラックボックスの中身を土台にして開発していくのでどんどん開発会社の立場が強くなる。
例えばバナーを継続的に作っている場合、別に前のデータがなくても新しいバナーを作ることはできる。ただwebサービス開発は前のコードがないと開発できないし、その中の全容を把握するのは結構たいへんだったりする。
もちろん開発会社にも誠実な会社はたくさんあるが、こういう状態になった場合にいいたい放題したくなる会社もやはりいるのだ。
開発会社に外注にした時点で１社独占になりがち
ただ難しいことにこの状況をさけるのも厳しい。というのもよほど予算が潤沢にない限り、基本的に開発会社に依頼したら一社になるだろう。そもそも開発会社に依頼するメリットって窓口を集約することでコミュニケーションコストが減ることもあるので最初はできるだけ集約したいもの。
また２社に例えしてもコミュニケーションコスト、役割分担が難しい。
なので開発会社に依頼した場合、多くの場合、一社独占になり、継続していくと上記の事例のように誰もレビューできなくなり、開発会社の立場が強くなってしまうのだ。
つまり
- web開発は仕様の共有など精密に行う必要がある
- 二社にまたがるとその共有が難しい
- よって１社に窓口をまとめがち
- しかし一社にまとめるとブラックボックス化してその開発会社の立場が強くなりすぎる
という条件のせいで泥沼化しやすい。
対策
とまあ、問題点を述べていったが実は問題の本質は開発会社に依頼することではなく、一社独占で外注してしまうことであり、開発会社に依頼するとその状況になりやすいという話である。
つまりちゃんとレビューする体制になっていいなと考えていて、対策は下記２つあると思っている。
- 開発会社に依頼しつつ、クライアント側でレビューできる人材を少ない稼働時間でいいので確保する
- 開発会社ではなく業務委託で複数人のエンジニアを入れる
開発会社に依頼しつつ、クライアント側でレビューできる人材を少ない稼働時間でいいので確保する
２社入れるのは大変なので実装を開発会社一社にしつつ、第三者機関としてその会社とは別に技術のわかる人間を入れる。これは稼働が少なすぎても流れがわからず、なんも答えられないとなるので定例などに継続的に入ってもらうのが良さそう。
airteamでエンジニアに月２回定例に入ってもらうのを試している会社があって、定例で実装の設計を話したりしている。見積もりのレビュー、みたいな大層な感じにすると開発会社の人にも悪いのであからさまにレビューをしていないが同じmtgに技術的な事がわかる人間が自分たち以外にいたら良いプレッシャーにはなっていると思う。
開発会社ではなく業務委託で複数人のエンジニアを入れる
もう一つの方法がそもそも開発会社に依頼しないで業務委託の人を集め、内製するというもの。そもそも直でエンジニアとやり取りできないから開発会社に依頼しているんだよという声が聞こえそうだが、そのとおりでこのやり方は発注側にある程度のディレクションスキルが必要になってくる。
現実解としてはそもそも人数を増やさない技術構成にするというのがあって例えばこれも実際にairteamであった事例だがSPAでreact+goでwebサービスを開発しようとしたクライアントがいた。
ただそのサービスは正直SPAにするメリットそんなにないよなと思ったのでrailsでフロントエンドはSPAじゃなく、普通にviewにhtmlを書いて実装するのを提案した。
内製化を考えた際にこの技術構成が滅茶苦茶影響を与える。例えば
- バックエンドをgo
- フロントエンドをreact
これ両方をプロレベルでかけるエンジニアよりrailsでフロントエンドもかけるエンジニアを探してくるほうが難易度は低い。もし上記でSPA化すると実際に内製化しようとしたときにgoとreactのエンジニアを一人ずつ、レビュー体制、バックアップを考え、もうひとりずつで合計4人になるが、railsならレビュー入れて二人になる。
おそらくrailsエンジニア二人のほうが集めやすいと思う。
また実装時にある程度一人で一通り終えられるようにしていれば発注側が繋ぐ必要はなくなる。これがSPAでバックエンドとフロントエンドが別で発注側がディレクションしないといけなくなると難易度はあがる。
内製化する場合、
- できるだけ一人で実装が完結するような技術構成にする
- 集めやすい開発言語、スキルにする
が重要になってくる。
webサービスの外注の体制を考え直す
という感じでwebサービスの開発の外注体制について考えていった。今までクライアント側に技術的なことをわかる人間をいれるというのが高コスト過ぎて現実的ではなかった。airteamで月数時間からピンポイントで入れることを一般化してこの構造を変えていけたら良いなと思っています。
airteamサービスサイト
開発会社側の負担も減るかも
上記でクライアント目線で話をしているがクライアント側に技術のわかる人間がいないというのは開発会社にとっても大変なので開発会社のコミュニケーションコストを減らす役割としてもピンポイントな第三者エンジニアの参画を推し進めたい。
