外注さんに失敗なく仕事をお願いする単純で画期的な方法を考えたった
基本的にほぼ100％、社内のプログラマだけで開発を行っている弊社ではありますが、時折どうしてもリソース不足を起こすことがあります。
特にここ1年ほどは、消費税増税に伴ってシステムをフルリニューアルしようというようなお話が多く慢性的な製造力不足に悩まされております。
そんな時は外注の開発会社さんにお仕事をお願いするのですが、これがまあなかなか難しく、これまで結構失敗を重ねてきました。
今回、不肖わたくしめが「たぶんこれが正解じゃないか？？」という案を考えましたので、ここにご提案します。同業者の方々にとりまして何かヒントになれば幸いにございます。
□外注さんとうまくやるという定義からして間違っていないか？
外注会社に仕事をお願いするとき、普通に考えるのは「要件出しをしっかりして、相互にきちんと認識を合わせ、なるべく安い見積もり金額で発注し、納期通り開発を完了してもらい、納品後も1年間はしっかり瑕疵担保をしてもらおう」という方向性だと思います。これがうまく行けば「成功」、うまく行かないと「失敗」と定義してよいのではないでしょうか。
しかし、現実的にこんなことが可能なのでしょうか？
まず「要件出しをしっかりやる」というところからして私は不可能だと思います。そもそも元請である弊社からしてお客さんと要件を完全には詰めていません。
もちろん要件定義書は作ってありますが、そこには例えば「ファームバンキング連動」とかいう項目があったりするわけです。しかしそれをどんなUIやアルゴリズムで実装するかは、初期段階では決まっていません。
業務フロー的にその前段階にある｢請求締めをどうやるのか｣、｢請求書をどう出すのか｣、｢入金消し込み処理はどうやるのか｣等々が確定してからじゃないと考えられませんので、発注を頂く段階ではまったくもって曖昧です。
そんな状態でご発注いただくのも恐縮ではあるのですが、逆にいうとそういうように順番に足場を固めていくような作り方をしないと、使い勝手のよいシステムはできないと思っています。契約前に細かい機能の定義まで決めて、そこに書かれているものは実装するし、無いものは実装しない、みたいなVモデルチックなことをするとロクなものになりません。
で、そういう仕様の不確実性があると、外注さんはリスクバッファを見ますので大抵見積もりは高めになっていきますね。
これは仕方ないことで、これを回避しようとするとウォーターフォールの滝壺が頭をよぎりますが、そっちだけは絶対に進んではいけないと思います。
□開発は八合目からが一番大変
また「納期通り開発をしていただく」というこの当たり前のこともなかなかに難しいです。特に業務システムなどではβ版をお客さん（現場）に公開し、そこからフィードバックを受けて最終的な理想の形に直していくというのが一番大変です。
システム開発のプロジェクトを登山に喩えるなら、確かにβ版納品は八合目に当たるのでしょうが、そこから山頂までがとても険しい道のりで、精神的にはちょうど半分くらいといった感じでしょうか。
社内のリソースでやっているのであれば、わっしょいわっしょいで乗り切ってしまうのですが、そこが外部の会社さんを使っているとそうも行きません。外注さん的にはその頃からだんだん｢そろそろ終わりでいいんじゃね？｣｢もうここから有償だとユーザーさんに言ってくれよ｣という雰囲気が漂い始めます。
しかしここで手を抜くと、何となく正解に近いんだけど全く使えないという残念なシステムになり、顧客満足度も大きくダウンしてしまいます。
□外注さんとうまくやっていく画期的方策
で、こうならないために考えた画期的方策を考えました！
外注さんにはβ版まで付き合っていただいて、あとは社内で巻き取る
これです。とても単純なことですが。
逆に言うとこの方策しか、社内で作るのと同じくらいの価格で、ちゃんと使えるシステムを円満かつスピーディーに開発し、納品後のアフターフォローも責任をもって行う方法はないのではないでしょうか？
しかし、この方策は単純ではありますが実際やろうとすると容易なことではありません。開発の一番忙しいβ納品の頃に引き継ぐわけですから、それがスムーズにできなければ、スケジュールに大きく響きますしコスト的なロスも発生してしまいます。
ということで、もうちょっと考えました。
まず弊社できちんと開発フレームワークを整備し、それをすべて外注さんにお渡しして、サンプルソースとチュートリアル用意して、質問受付担当者もアサインして、「これで作ってください」ということにしようと。
長年培ってきた技術は流出してしまいますが、それを頑なに守っても大したメリットはなく、それよりも逆に外注の方に積極的に使っていただいて「ここおかしくないですか？」「こうしたらどうですか？」とフィードバックをもらった方が絶対によいはずです。
先日のシゴトビトのインタビューでも再認識しましたが、ものづくりの会社というのは基本的に小規模であるべきで、そういった会社が案件によってくっついたり離れたりして、リソースを融通しあい、またノウハウを提供し合うべきだと思います。スクラッチ開発の会社は、一社で市場のすべてを食べきってしまうことなど出来るはずがないのですから。
実はこれはすでに去年末から実際に始めた方式なのですが、まだ一件も完了していませんので、最終的に「思った通りこれ良かったね！」という結論になるかどうかはわかりません。でも今のところはなかなかいい感じですね。
ということで、弊社では、このような開発スタイルにご賛同いただける外注会社を募集しております。
ご連絡は partner{アットマーク}plumsa.co.jp までお願いします。フレームワークとチュートリアルとお茶とお菓子を用意してお待ちしております。
株式会社plumsa(プラムザ)では、システム開発に関するお悩みを受付中です↓