こんにちは。BPS㈱の渡辺です。新宿で３０人程度の開発会社を運営してます。Railsの開発会社として多少知られているかと思います。少し前から電子書籍関係の商材を扱っている企業としても知られているかと思います。今まで社内で概ね開発を完結させてきたけど、需要にたいして社内供給が間に合わないとき、パートナーを探すしかないですよね。外注を検討していると、弊社の開発者から”これ自分達で作りたかったな...”、と言われるので、後で迷惑かけちゃったときの沸点の低さを鑑みてしっかりと外注先選定をしなければ、と常々思っております。ちなみに僕は、むかーしは開発していましたが、今は立場上マネジメントに近いことをしています。自分への戒めの念も込めて、経験をもとに注意点を列挙してみました。何かの参考になれば幸いです。
発注前に気をつけたほうがいいこと
発注前に９割くらいのリスクは軽減できますもんね。何事も計画が大事。とはいえ、発注後にどうリカバリするかも非常に大きな破壊力をもつ決断を強いられるので、これはこれでまた今度まとめてみようかなと思います。同僚に、執筆は勢いが大事、というアドバイスをもらいました。打ち合わせまでの時間内で書ききれるところまでを目標にします。ということで今回は発注前。発注後に関してはまた今度。さて、本題です。
技術わかりそうだけど受託開発経験や共同開発が殆どない
さすがに技術もダメで受託開発経験ないところは皆さまお断りしますよね。つい数年前まではこういった業者がわんさかいましたよね。SIer×ブラックといったテーマで文章書いている人が増えたのもこの時期でしょうか。最近では発注側の担当も注意深くなったのか、僕らもベンダーとしてお客様のところにお伺いすると、とても技術に詳しい方や技術部門を統括している方が対応してくださることが増えました。弊社にも開発会社さんがいらっしゃる時も、技術に詳しい方が提案営業にきてくれるようになってきました。技術詳しいし、話せる。そんな人が増えた印象です。とりあえず今目の前にいる人が開発を見てくれるなら大丈夫かもしれない、といった信用ラインは突破してくれる。まだまだ貧乏暇無しな状態で毎日右往左往しているので、おかげで完全に時間の無駄になることが減ったですね。
ですが、会った方が直接案件を担当してくれないこともありますし、担当してくれたとしてもその方やその方が属する会社に仕事としての開発経験が少ないこともあります。前者の問題点はわかりやすいし問題にならないこともありますし、今回は割愛します。後者の問題は、技術的ハードルは超えていても、仕事として開発を全うできない可能性にあります。僕には、短距離走に自信がある陸上選手がトライアスロンに挑戦するように見えます。走る（技術）だけだと時間内に完走できないんです。そもそも長距離だから完走できないかもしれない。それに、自転車も水泳もある。プロマネ業とか、プロジェクト後のソースコード保守制とか、いろいろ。結果、想定（見積）通りに全然進まずプロジェクト自体が消滅するか、良くて大幅な延納に繋がります。経験も悪気もない企業さんは、それでも付き合うか考えれば良いですよね。逆に、完走できないリスクを発注側に過度に押し付けるような会社さんは注意が必要と思います。個人的に注視しているのは以下です。
何でも別途見積
もちろん想定外のことがおきて正当な別途見積が発生するのはしょうがないと思います。同じ開発会社ですからわかります。でも、経験があればある程度事前にリスクは想定できますし、織り込み済みで見積が可能で、そのリスクの情報共有によって双方で対処できることがあります。なので、開発者同士で不自然なほど序盤で別途見積をプッシュしてくるようだと要注意と思っています。あるいは、自社のRFPや事前の要件定義がダメすぎるか、ですね。
アジャイルだからドキュメント書かないぜ的な開発スタンス
最近流行ってますよね、CTOや開発チーム貸し。正しく開発すれば正しくアウトプットはでます。アジャイルが適していて、かつ経済的なば場面もいっぱいあります。だからそれがダメとは全く思ってません。ただ、この流行りを使ってお客さんをロックインしたりスケジュールをないがしろにする動きが最近多いですね。弊社に既存システムの改修を依頼してくるお客様のなかの一定割合は、信頼してシステムを創ってもらっていたけれど、全然進んでいるようにみえないし、見せてもらったものは欲しかったものと異なるし、もう期日が差し迫っているのでどうにかしてほしくて困っている、というケースです。最低でも期日までに必要な機能が動いていることを保証してほしいケースが殆どなため、それに合わせた契約形態を真剣に考えるべきですよね。
別業務の合間程度に受託開発している
個人的にこれが一番癇に障ります。自社サービスなどを持っていてそれを会社として最優先されることは、とても良いことだと思いますし、応援したいです。最近は自社サービス開発と受託開発の両方に力をいれてる開発会社さんとても多いですし、うちもそうですし、共感するところが多いです。さすがに自分の子よりも他人の子を愛してくれとは言えないし、契約前に何を書かせてもその事実はかわらないし、あとからお金で精算しても気分が悪い事にはかわりないし、どこまで頑張ってくれるかは事前に目処をつけておくべきですよね。なので発注前に気にしているのは主に下記の２点。
やりきってくれそうか
１つ目は、その会社や担当の風土から仕事をやりきってくれそうか、です。目の前にいるやつが性善説で生きてるやつかどうか、など。問題を起こしたときに正す気概があるか。自信だけじゃなくて覚悟もありそうか。僕も性善説で生きている人間なので見極められていないんですけどね☆
開発体制と計画
２つ目はもうちょっと現実的です。別業務に専念している会社さんほど、規模の割に大人数は開発体制を提案してくることがあります。それも、あまり余裕のないスケジュールで。欲しいのは、他人の子供でもこうこうこういうふうにしっかり守って育てていきますよ、という計画書ですよね。その計画書に抱えてもいない大量の担当者とパツパツのスケジュールを組み合わせた線表がひかれていると、とっても不安になりますよね。この辺の整合性の確認が必要です。
請負か準委任か
請負でも準委任でも、ウォーターフォールでもアジャイルでも、正しく適切に遂行すればどちらも成果はでます。プロジェクトがどちらに適しているか、というだけの話しですよね。請負は請ける側からするとリスクが高く収益も高い。準委任は逆ですね。でもこれは正しく業務を遂行した場合の話です。エースを投入してしっかりプロジェクトマネジメントをしていないチームなら、準委任のほうが請ける側からするとリスクは低く収益性が高い。小規模な案件ならエース投入で速攻終わる可能性がありますね。開発量が多い案件なら安定した計画があったほうがいいですね。案件の性質と、外注先開発会社と担当者の特性の相性を見てから判断すべきですよね。
自社担当者との相性
以外と忘れがちなのかなと思うのがこれです。最後に気合でやりきってくれるほうが嬉しいのか、計画を立ててちびちび前に進めてくれたほうが嬉しいのか。僕は人付き合いが苦手なのでなるべく少ないコミュニケーション量でまるなげしておいたら適当に適切にいい感じに知らない間に完了していることが嬉しいのですが（笑）、仕事方法に想い入れや拘りをもって取り組んでくれる人を発注担当にするでしょうから、組合せは大事ですよね。
ソースコード品質という成果物
予め要求していた機能があり、要望に答えられるシステムが期日までに完成する。それも、中小の小回りと（低）価格で。弊社でも受託開発を行っているので、これだけでも笑っちゃうくらい大変なのは重々理解しています。ただ、追加開発や改修が必要になったときにつくり直しレベルのものを受け取っているとけっこう辛くなっちゃうのでソースコード品質含めた過去実績の確認や、ソースコード品質に関する基準などは事前にすり合わせてほうが幸せです。品質は、ちゃんと話せば、コストやスケジュールみたいなふわっとしたものと違い、できるかできないかの話し合いがしやすいです。
技術力が高く価値観のあう開発会社さんを探しています
弊社業務をご覧いただきもし協業の余地ございましたらぜひご連絡ください。弊社のやっていることと今後の目標についてはこちらまたは下のバナーをみて詳細ご覧いただけたらと思います。今後ともよろしくお願い申し上げます。
関連記事
40名：増床の費用対効果改善と社員満足度向上のための個別指導教室
35名：拡大と社員満足度向上を見据えた人事・採用担当の仕事と迎え入れ方
30名：拡大と収益率改善のための大量採用の実現と社内平均値の上げ方
25名：今後の開発体制強化を意図したウィングドア社株式取得
25名：引き受けられる案件難易度向上を実現するバーサタイルウェイ社株式取得
25名：今後の拡大を支える仕組みづくりを開始、まずは社員研修から
20名：拡大に応じて残す外注先とそうでないところの選定基準
20名：経営能力と資源確保のための第三者割当増資を実施
20名：拡大を決意し2015年度振り返り改善点を洗い出す