【DXの難しさ：ベンダー選定編】なぜアプリ開発会社の選定は難しいのか？

サービス

2022年11月16日 09:00

アプリやWebサービスの開発は本当に難しく、良く失敗しがちですよね。。
今回はDXの難しさ、特に「ベンダー（開発会社）の選定の難しさ」についてです。
DXが進まない理由は多々あります。コスト、要件定義の難しさ、各ステークホルダーとの合意形成の難しさ、社内や決裁者のITスキル・判断力、既得権益者の反発など多々ありますが、今回はそのうちの開発会社を選定する難しさについて書いていきたいと思います。
DXだ！と上司が言い出して任命された担当者が最初に困るハードルですね。
少しでも初めての担当者のベンダー選定の参考になれば嬉しいです。

ベンダー（アプリ開発会社）の選定が難しい理由

なぜ、ベンダー（開発会社・発注先）の選定はそんなに難しいのでしょう？
ボールペンを仕入れたいのなら、１本手に取り紙に何か書いて使ってみて、良い感じであれば、あとは「何本でいくら？」の金額と納期だけですよね？
しかし、アプリ開発はそう簡単にいきません。
いくつか理由があります。

要件を詰めない限り何がいくらでできるか分からない。
どの会社も見積もり金額がバラバラ。
作ってみないと何ができるか分からない。

一つずつ解説していきましょう。

最速・格安のアプリ開発のご相談はこちら

要件を詰めない限り何がいくらでできるか分からない。

どういうことでしょう？
ボールペンなら完成系をあらかじめ触って試せるので購入に躊躇はありません。
しかしアプリ開発はそうはいきません。
本当に動いて触れるようになるのは開発の終盤の終盤であることが殆どです。
じゃあ要件を詰めるってどういうことでしょう？
例えば「メルカリみたいなアプリを作りたい、いくらですか？」だと全然分かりません。
大きなところでいうと、業務がどんな流れになるのかを示す「業務フロー」が分かりません。それによって必要な機能が変わってきます。管理画面が必要なのか、Webだけなのかアプリもあるのか、iOS/Android両方か、なども重要な情報です。
もう少し具体的なると、「予約機能」とか「チャット機能」とかざっくりではまだ不明で、予約にはキャンセルがあるのか、ある場合キャンセルルールはどうなっているのか、予約を管理者が編集できるのか、する場合はどんなフローか、イレギュラーなフローはあるのか、・・・だったり、チャットには既読機能やグループチャット機能、画像は送付できるのか、リアクションやフォロー・ブロック・ミュート機能は必要か、などなど・・・話すとキリがありません。
上記はあくまで一例です。
もちろん聞かれれば答えられるものもあるかと思いますが、聞かれていない状態で「今週中に要件をまとめてください」と言われてもできない担当者が殆どかと思います。
そして、全部言われると「あったら便利」な機能は「全部入れたい」と思うと思います。
そうするととても大きな見積もりが出てきます。
それだと予算を超えてしまう、ということは良くありますね。
なのでそれらを詰める作業を何度も各ベンダーと擦り合わせる必要があります。
候補のベンダーが数社いれば数社ごとに・・・とても大変な作業になります。。

どの会社も見積もり金額がバラバラ。

上記の通り要件定義は大変です。
アプリやWebシステムの開発・発注に慣れていないと簡単ではありません。
慣れていないと明確な要件定義はできず、曖昧なものになります。
すると、解釈によって違う金額感の見積もりが出てきます。
極端な例をあげると、A社が1000万円の見積もりだったりB社が7000万円の見積もりだったりします。
「え？どういうこと？」
と思いますよね。
もちろん、A社が小さい会社で安すぎる会社である可能性も、B社が大きい会社で単価が高い会社である可能性もあります。
ただそれだけではなく、「見積もりの解釈の仕方によってブレ幅がある」ということです。
A社はシンプルなアプリを作ってMVP・リーンスタートアップなプロトタイプをイメージし、B社はかっちりした本格的なサービスをイメージしているかもしれません。
例えば「チャット機能」とかかれた機能は、A社の場合は要件に書いている「チャットができればいい」というミニマムの要件しかイメージしていなく、B社はLINEやFacebookメッセンジャーのような売れてるアプリにある一通りの機能・パフォーマンスをイメージしているかもしれません。
それを元にベンダーを判断する・・・大変ですよね💦

作ってみないと何ができるか分からない。

ここが最大の難しいポイントです。
ボールペンを買うときは売り手も書いても完成イメージが明確ですが、アプリ開発は誰もがイメージが漠然としている状態から始まります。
発注側にスキルがないと想いを明確に伝えられません。（前述の要件定義のスキルにも当たります）
また、受注側（開発ベンダー）に提案スキルが無いと、発注側の意図を汲みきれません。
これがまた難しいところで、プログラミングのスキルが高いからと言って提案スキルも高いわけではありません。そこの見極めも難しいポイントの一つです。

ベンダーを決め、アプリ開発を数千万円で発注し、数ヶ月かけて開発し、いよいよ発注者がアプリを動かしてみる・・・となった際に、蓋を開けてみたら「あれ、こーゆーつもりじゃなかったのに！？」
なんてことは本当によくある話です。

こんな時は揉めに揉めますし、責任問題になることも多々あります。

ベンダー設定の失敗パターン

ここでは発注に失敗するパターンを書いていきましょう。

安いだけの会社に発注してしまうケース

やはり、アプリ開発・システム開発は内容が難しく比較しにくいので結局安いところに発注しがちです。値段で決めるしかないからです。
そうなると、安いエンジニアばかりの会社、優秀なエンジニアが少ない会社に発注することになります。
結果は火を見るより明らかで、当然良いものはできてきません。
しかし相手としても、この金額だからこのくらいで仕方ないでしょ、という思いもあり、中々思い通りにならず、結局作り直すこともしばしばあります。

「営業担当」ができると言ってるだけで中のエンジニアたちは無理だと思ってるケース

このケースは非常に良くあります。
営業担当、つまり発注者が直接やりとりしている相手は「とにかく受注したい」のです。
なので、無理なことを無理だと言わず仕事をとりにきます。
しかし、その営業は実際に「アプリを作る」わけではありません。

真に優秀な営業は、受注したあとのお客様の満足度まで考えて誠実な営業を行いますが、
往々にしてそうではない営業担当の方が多いです。

自分で作るわけでは無いので、多少無理かもと思っても「できる」と言って受注し、あとはプロジェクトマネージャやエンジニアに丸投げしようと思っているタイプの営業担当には本当に注意が必要です。
実際に開発が始まった時に案件を担当することになるプロジェクトマネージャやエンジニアと話をすることは非常に大事ですね。
※営業フェーズで話をしているプロジェクトマネージャやエンジニアが実際にはアサインされないこともよくあるのでこれも注意が必要です。

開発（プログラミング）スキルはあっても提案スキルはないケース

このケースも良くあります。
発注側に開発経験・ITスキルが無い場合、とにかく提案して欲しいですよね？
「御社のサービスの場合はこういう業務の流れになるのでこういう機能が必要です」
など提案してくれることを求めるはずです。
ですが、開発スキルも高くて提案スキルも高い会社（あるいは人）なんてそうそうありません。
開発スキルが高くきっちり言われた仕事を正確にこなせるチームでも、相手のサービスの真意を汲み取り提案するところまではできない（あるいはしない）こともよくあります。
逆に、それを両方できる人材・会社ということは、当然金額もそれなりに高くなるのです。
ここが開発コストをケチってはいけない理由だと私は思っています。安物買いの銭失いになりかねません。
とはいえ、高いだけで何もやってくれない会社に発注してしまうミスは犯したく無いので・・・ベンダー選定は難しいですよね💦

技術力とデザイン力は別の話

良い提案力・技術力はあるけどデザインはイケてない会社はたくさんあります。
逆に、デザイン力はあるけど技術力はイマイチな会社ももちろんあります。
この辺のバランスも難しいところです。
ちゃんとした不具合がない要件通りに作ってくれるのはありがたいですが、見た目がイマイチだとそれだけで残念ですよね。

でも見た目だけが良くてもシステムは動きません。非常に細かいユーザーからは分からないようなところにプロのエンジニアのスキルが活かされています。
如何に良いデザインでも、プロのエンジニアがいなければシステムは不具合という名の大きな爆弾を抱えてしまいます。

ベンダー（開発会社）の選び方

ではどのように選んだら良いでしょう？
正直本当に難しく、正解はありません。
ただ、リスクを小さくする方法はあります。
リスクをガッツリ小さくするためには、「まずは小さく発注する」ことです。
スモールスタートが一番大事です。

MVP開発とか、PoCとか、リーンスタートアップなどの言葉がずっと言われてきましたが、
それを本当に理解し実践している会社は思いのほか少ないものです。

まずは小さく、素早く作り、試すこと。

例えば社内システムなら特定の部署限定で。
例えば各店舗で使うシステムなら特定の店舗だけの前提で。
機能もあれもこれもと追加するのではなく、一番目玉となる機能のみに注力してまずそれに効果がホントにあるのかを試す。
その前提であれば複雑な機能は要りません。
であれば複雑な要件定義も要らず、ベンダー選定自体のリスクも激減します。
また、一度これを作ってしまえば、この後の追加開発するにしてもゼロから大きく作り直すにしても、既に動いているものがある状態なので要件定義もしやすくなります。
MVPについては詳しくはこちら

MVP、小さく素早く始めるためには？

開発を小さく素早く作り、市場で試すには、ノーコードが有効でしょう。
Adalo、bubble、shopifyといったノーコードツール群を利用することで、圧倒的にコストを抑えつつ超短期間でリリースまで持っていくことができます。
その分できることに限りはありますが、前述の通り機能や目的を絞る前提であれば問題はありません。
まずはノーコードで作り市場で試し、それを元に本格的に開発する。これが今のトレンドになっています。
ベンダー選定にもアプリ開発にも正解はありません。
できることは「コストを抑えて早く試す」ことだけです。
スピードが競合との差別化になりますし、コストを抑えることがリスクを大幅に下げることにつながります。