ソフトウェア発注の心得
この記事は、これからWEBサービスを作る予定があり、その開発を外注しようと考えている企業に向けて綴ります。
ソフトウェア開発は家を建てる作業に似ています。
どんな工務店でも家は建てるスキルは持っているはずです。なのでお金を払えば、あなたが依頼した通りの壁色や間取りで家を作ってくれるでしょう。引き渡しの段階で工務店の腕に差が出ることはほとんど無いはずです。
工務店の腕の差が現れるのは、引き渡しから数年後です。
雨漏りした。床が傾いた。家の間取りを変えようとしたら「この壁を抜いたら家が崩れます」と言われた。素人目には判断できない水面下の手抜きや低品質が時間をかけて表面化するものです。
しばらく時間が経ってから、何かトラブルが起きた時に初めて「あの工務店はダメだった」と分かることが多いのでは無いでしょうか。
ソフトウェア開発も似たようなものです。サービスをリリースしてから一定期間が経った後、もしくはトラブルが起きた時に、初めてエンジニアの腕の差が現れます。
・追加機能を頼んだら「それは仕様変更なので、改修に数ヶ月かかります」と言われた時
・開発に時間がかかる理由を聞いたら「コードが複雑になってきたので」と言われた時
・バグが多い理由を聞いたら「スピードを優先して、テストを一切書いてないので」と言われた時
などなど・・・
では、トラブルが起きる前にエンジニアの腕を見極めるにはどうすれば良いのでしょうか？これも家づくりに例えて説明してみます。
あなたは一戸建てを建てようと考えました。2つの工務店から提案があったとします。
あなたは何の説明も聞かず、安いからと迷わずA工務店を選ぶでしょうか？
恐らくそんな事はしませんよね。家づくりに関して様々なことを調べた上で、各工務店の提案を吟味するはずです。
家屋の設計、工法、法律などの関連知識を身につけ、工務店の担当者と納得いくまで議論するはずです。
そんな時間をかけず、全てを工務店に丸投げする人もいるでしょう。欲しいものだけ伝えて「細かいことは君たち（工務店）に任せるよ！」と。
良い工務店であれば何も問題は起きないのでしょうが、悪い工務店だったら、おそらくカモにされるでしょう。基礎工事は手を抜かれ、無駄な設備をつけられ、可能な限りお金をむしり取られた上で、数年後に床が傾く欠陥住宅を引き渡されるかもしれません。
家の完成度は完全な運任せ、ということになります。
ソフトウェア開発も全く同じです。
発注側がデータ管理の仕組みやプログラミングの基礎的な知識を何一つ調べずに丸投げすれば、全ては運任せになります。良い開発会社に巡り会えればよし。悪い開発会社に当たってしまった場合・・・・言うまでもありませんね。
テストもろくに書かず、スキーマ設計も滅茶苦茶、負債だらけのサービスを納品されるかもしれません。私が知っている酷い例では、海外の安い受託会社にこっそり再委託して、自分たちは何もせず中抜きしている開発会社がありました。勿論バグだらけで話にならない出来だったそうです。
（ちなみにその開発会社は某案件仲介サイトで「星5をつけない限りは納品しない」と発注側を脅したそうです）
今すぐ発注側が自分たちの事業を止めてまでプログラミングを勉強しろ、とは言いません。プログラミングではなく自分の本業に専念したい気持ちは痛いほどわかります。
ですが自身の身を守るためには知識武装が重要です。
深く理解する必要はありませんが「自分はある程度の知識を持っている」と相手に伝わるだけの知識は備えて欲しいと考えています。
少しだけ自分なりに調べたことを開発会社に質問して、相手の反応を見るだけでも十分効果を発揮するでしょう。
「今回採用するアーキテクチャをホワイトボードに書きながら説明していただけませんか？」
「ER図を見ながら大まかにスキーマの考え方を説明していただけないでしょうか？」
「CI/CDの構築を予定している場合、軽く流れを教えていただけないでしょうか？」
ここで大事なのは、発注側が質問の回答を完全に理解する必要はない事です。
悪質な開発会社は「この人は開発について何も知らない」という無知の香りに集まるものです。「開発を少し理解している」と匂わせるだけで自然と離れていきます。
「トンチンカンなことを質問していたらどうしよう」
「答えられても理解出来ないから、聞いても仕方ないかな」
「しつこく聞いたら怒られないかな」
こんな心配はしないでください。
自分の専門について詳しく聞かれて気分を害する人は居ません。プロであれば知っていることはスラスラ答えるし、知らないことは素直に「わからないので調べます」と言う筈です。
発注側には金銭の対価として「質問する権利」も付随することを忘れず、どんどん質問してください。
（勿論、相手の作業に支障をきたすほどの質問はいけませんが・・・）
最低限の開発知識を身につけることには「悪い開発会社を遠ざける」以外にも「良い開発会社と円滑に働ける」効果があります。
どの開発会社と組んでも開発に失敗する発注者が稀に居ます。こうした発注者は例外なく全員が「開発に関して何も知らない」人でした。
「ECサイトを作りたかったんだけど、やっぱりSNSにしよう！」と言われたら、どんな開発会社でもお手上げです。いかに優れた開発会社でも、明らかな無理難題には対応できません。
無理難題を押し付けた結果、せっかく巡り会えた良い開発会社から「もう付き合えません・・・」と言われてしまっては勿体無いですよね。こうした不幸を防ぐためにも、発注側が最低限の知識を持つことは必要だと感じます。
それでは発注側として最低限勉強しておくべき「ソフトウェアの知識」とは具体的にどのようなものなのでしょうか？
これ以上は話が長くなりそうなので、もしこの記事に多くの方が興味を持ってもらえるようであれば、詳しく説明したいと思います。
・少しでも多くの企業が良いエンジニアとつながる
・良いエンジニアが正当に評価される
・より多くのアイデアが形になる
この記事がこれらの一助となれば幸いです。
