著者: 野原琉海（株式会社ラズリ代表）
僕はエンジニアとして開発の仕事を受ける側の人間だ。
「開発会社の選び方」みたいな記事はネットにたくさんある。でも、書いているのはだいたいライターかコンサルで、実際にコードを書いている人間の目線で書かれたものは少ない。
今日は受注側のエンジニアとして、発注側に知っておいてほしいことを本音で書く。「いい開発会社の見分け方」ではなく、「エンジニアから見た現場のリアル」の話だ。
正直、この案件受けたくないなと思う瞬間
いきなり失礼な話から始めるけど、受注側にも「これは受けたくないな」と思う瞬間がある。
一番きついのは、発注側が自分たちの欲しいものを分かっていないケースだ。
「なんかいい感じのシステムを作ってほしい」「とりあえずDXしたい」「競合がアプリを出したからうちも」。こういう発注が来ると、正直身構える。
なぜかというと、欲しいものが曖昧なまま作り始めると、完成した時に「思ってたのと違う」と言われるからだ。
これはエンジニアにとってかなり辛い。仕様通りに作った。打ち合わせで合意した。でも「なんか違う」と言われる。じゃあ何が正解なのかと聞くと、発注側も分からない。
結果、作り直しが発生して、お互いに不幸になる。
だから僕が発注する立場だったら、まず自分たちが「何に困っているか」を言葉にする。システムの機能じゃなくて、業務の課題を。「毎月の請求書処理に3日かかっていて、それを短くしたい」。これだけでいい。具体的な解決策はエンジニアが考える。
エンジニアがやる気になるクライアントの特徴
逆に、「このクライアントの仕事はいいものを作りたい」と思う瞬間もある。
反応がいいクライアントだ。
打ち合わせで提案した時に、「お、それいいですね」とか「そこ気になってたんです」とか、ちゃんとリアクションがある。質問してくれる。一緒に考えてくれる。
当たり前のことに聞こえるかもしれないけど、これができないクライアントは結構多い。
ありがちなのが「お金を払ってるんだから、全部ちゃんとやってよ」というスタンス。気持ちは分かる。お金を払っているのは事実だ。でも、このスタンスだといいものは作りづらい。
なぜなら、システム開発はエンジニアだけでは完結しないからだ。業務のことを一番知っているのは発注側だ。「この画面、実際の業務ではどう使いますか？」「この例外ケースはどのくらいの頻度で発生しますか？」。こういう質問に答えられるのは発注側だけだ。
一緒にシステムを作っているという感覚があるクライアントとの仕事は、結果的にいいものが出来上がる。丸投げされた仕事より、一緒に考えた仕事の方が品質が高い。これは間違いない。
愛想がいいとか、ミーティングの雰囲気がいいとか、そういう些細なことでエンジニアのモチベーションは変わる。人間だから。
この発注の仕方は危ないな、と思うパターン
受注側から見て「これは危ないな」と感じる発注のパターンがいくつかある。
ざっくり丸投げ
「いい感じに作ってください」「お任せします」。
これは先に書いた通り、「思ってたのと違う」の原因になる。任せてもらえるのはありがたいけど、要所要所で確認させてほしい。
完成してから「全然違う」と言われるのは、お互いにとって最悪の結末だ。
いきなり大規模システムの導入
「社内の業務を全部管理できるシステムを作りたい」。
気持ちは分かるけど、いきなり全部を作ると費用も期間も膨らむ。そして、最初に決めた要件が途中で変わる。大きければ大きいほど、変更の影響範囲が広がって、プロジェクトが破綻するリスクが上がる。
僕だったら「それ、既存のツールで代替できませんか？」と聞く。Excelやスプレッドシートで十分なこともあるし、月額数千円のSaaSで解決することも多い。
それでも作る必要があるなら、「まず最小限の機能だけ作ってみませんか」と提案する。最小限を使ってみて、本当に必要な機能が見えてから拡張する。この方が圧倒的に失敗しにくい。
価格だけで選ぶ
3社に見積もりを取って、一番安い会社に頼む。これ自体は悪くないけど、エンジニアの立場から言うと、極端に安い見積もりは品質が相当やばいと思った方がいい。
腕のあるエンジニアなら、少なくとも相場以上の価格にする。自分のスキルに自信があるから、安売りする必要がない。
逆に言えば、相場より大幅に安い会社は「安くしないと仕事が取れない」ということだ。なぜ安くしないと取れないのか。経験が浅い、実績が少ない、過去にトラブルを起こした。理由はいろいろあるけど、どれもいい理由ではない。
安い=お得、ではない。安い=それなりの理由がある。ここは発注側に知っておいてほしい。
受注側が本当に困ること
ここからはエンジニアの愚痴に近い話をする。
仕様変更の連続
「やっぱりこの機能も追加してほしい」「この画面のレイアウト、変えられますか？」
開発中の仕様変更は、ある程度は仕方ない。使ってみて気づくことはある。でも、毎週のように仕様が変わると、エンジニアは「また作り直しか」となる。
仕様変更が多いプロジェクトは、納期が遅れる。費用も増える。品質も落ちる。三重苦だ。
対策は、最初の要件定義にしっかり時間を使うこと。「急いで作り始めたい」という気持ちは分かるけど、「何を作るか」を詰めてから作り始めた方が、結果的にプロジェクト全体は早く終わる。
連絡が返ってこない
受注側が連絡取れなくなるパターンはよく話題になるけど、実は発注側の連絡が遅いケースも結構ある。
「この仕様、どちらにしますか？」と確認メールを送って、1週間返事がない。その間、開発は止まる。でも納期は変わらない。
エンジニアとしては「返事をもらえれば進められるのに」ともどかしい。忙しいのは分かるけど、開発中は確認事項への返信を優先してもらえると助かる。
いい関係を作るために
最後に、発注側と受注側がいい関係を作るために大事だと思うことを書く。
お互いにプロとして尊重する。これに尽きる。
発注側は業務のプロ。受注側は技術のプロ。どちらか一方が偉いわけではない。お互いの専門領域を尊重して、一緒にいいものを作る。
「お金を払っているから偉い」でもないし、「技術があるから偉い」でもない。
この前提が共有できているプロジェクトは、だいたいうまくいく。
この記事を読んで「うちの発注の仕方、大丈夫かな」と思った方は、こちらからご相談ください。開発の外注に限らず、業務の効率化について受注側の目線からアドバイスできます。