うまくいったシステム開発に共通していたのは何か｜金額でも規模でもなく関係性だった

システム開発が成功する条件として語られるのは、たいてい要件定義の精度や進行管理の仕組みです。それらは確かに大事なのですが、FUNBREWがこれまでの案件を振り返っていちばんはっきりと差が出ていたのは別のところでした。この記事は、その話です。精神論に聞こえるかもしれませんが、発注する側にとって実利のある話として書きます。

うまくいった案件に共通していたもの

結論から書きます。金額の大小ではありませんでした。規模でも、業種でも、技術的な難易度でもありません。共通していたのは、発注側と開発側の関係性です。

二つの条件が同時に成り立っているとき

具体的には、次の二つが同時に成り立っている状態です。

• 発注側が、開発会社を「業者」として割り切っていない
• 開発側が、顧客を「一緒にビジネスを成長させるパートナー」だと思っている

片方だけでは足りません。どちらか一方が事務的な取引として扱っていると、もう一方も自然とそこに合わせます。この関係が築けた案件は、例外なくうまくいっています。逆に言えば、これほど例外の無い共通点は他にありませんでした。

なぜ関係性が結果に出るのか

ここが本題です。「仲良くやりましょう」という話ではなく、関係性が仕事の中身を変えるという話です。

お互いにリスペクトがあると、何が変わるか

お互いをリスペクトできる関係になると、発注側は開発会社を専門家として見て、頼ってくださるようになります。「これはどう思いますか」と判断を相談していただけるようになる、と言い換えてもいいかもしれません。

すると開発側は、言われたものを作るだけの立場ではなくなります。顧客のビジネスをより良くしようと燃えることができる——実際、そういう案件では自然と提案が増えます。指示されていないところで気づいたことを言うようになりますし、言われる前に調べるようになります。

逆の関係だと何が起きるか

発注側が「仕様どおりに作ってくれればいい」という姿勢だと、開発側の仕事も仕様を満たすところで止まります。これは手を抜いているのではなく、そこから先の提案を持ち込む場が無いということです。「余計なことを言われた」と受け取られる関係では、気づいたことを言いにくくなります。

結果として、同じ金額を払っても返ってくるものが違います。値下げを飲んだ案件で提案の余地が削られた話（値下げを受け入れた開発会社に何が起きたか）と、構造としては同じです。削られるのはいつも、仕様の外側にある部分です。

発注側から見て、何をすればよいのか

とはいえ「リスペクトしましょう」では実務になりません。関係が立ち上がりやすい進め方を、具体的に挙げます。

判断を相談してみる

仕様を伝えるだけでなく、「どちらがいいと思いますか」と聞いてみてください。専門家として意見を求められると、開発側は自分の判断に責任を持つようになります。指示を受け取るだけの立場から変わる、いちばん簡単なきっかけです。

背景を共有する

何を作るかだけでなく、なぜそれが必要なのかを話していただけると、提案の質が変わります。目的が分かっていれば、指定されたものより良い方法に気づいたときに提示できます。目的が分からないまま作ると、指定どおりに作るしかありません。

進捗を一緒に見る

定期的に動くものを見ながら進めると、関係は自然と近くなります（納品後に「思っていたのと違う」と言われないために）。完成まで任せきりにするより、途中で会話がある方が、お互いに相手が何を考えているかが見えます。打ち合わせの頻度については開発の打ち合わせはどう進むのかも参考にしてください。

まとめ

FUNBREWがこれまでの案件を振り返って、うまくいったものに共通していたのは関係性でした。発注側が開発会社を業者として割り切っておらず、開発側も顧客を一緒にビジネスを成長させるパートナーだと思っている。この二つが揃った案件は、例外なくうまくいっています。

お互いをリスペクトできると、発注側は開発会社を専門家として頼れるようになり、開発側は顧客のビジネスをより良くしようと動けます。同じ金額でも、返ってくるものが変わります。発注側からできることは、判断を相談してみること、背景を共有すること、進捗を一緒に見ることです。

そういう関係でご一緒できる相手を探しています。お問い合わせよりお気軽にご連絡ください。