「こう作ってほしい」より「こう困っている」——外部ベンダーへの依頼で失敗しない、たった一つの心がけ

「仕様通りに作ってもらったのに、使いにくい」

kintoneの開発を外部ベンダーに依頼した経験のある方なら、こんな場面に心当たりはないでしょうか。

• 打ち合わせで伝えた通りのアプリが完成した。でも、なぜかチームに定着しない。
• 追加改修のたびに、思っていたものと違うものが出来上がってくる。
• 「言った・言わない」の確認に、何度も時間を取られている。
• 完成して使い始めてから、「あ、これも必要だった」という抜け漏れに気づく。

これらの悩みの多くは、開発の技術力や担当者との相性の問題ではありません。「何を伝えるか」の問題です。

外部ベンダーへkintoneの開発を依頼する際に最もよく見られる失敗のパターンがあります。それは、「仕様を伝える」ことに一生懸命になりすぎてしまうことです。

「仕様を伝える」とはどういうことか

外部ベンダーへの依頼経験が少ないと、つい「自分の頭の中にある完成形」を伝えようとしてしまいます。これは自然な発想です。「ちゃんと準備してから相談しなければ」という真面目さから来ることも多いでしょう。

たとえば——

これは「仕様を伝える」依頼です。ベンダーはこの通りに作ることはできます。しかし、これだけではなぜそれが必要なのかがわかりません。

なぜフィルタリングが必要なのか。なぜ自動転記が必要なのか。受注後のデータはどんな用途で使われるのか。その背景が見えない状態でアプリを設計すると、「仕様通りではあるが、使いにくい」ものが完成してしまうリスクが高まります。

「課題を伝える」と何が変わるのか

同じ依頼を「課題」ベースで伝えると、こうなります。

この伝え方をすると、ベンダー側は自然とこんな問いを持ちます。

• 情報の錯綜を防ぐには、更新時に関係者へ通知する仕組みが必要かもしれない
• 受注直前の対応漏れを防ぐには、期日アラートやステータス管理の設計が重要だ
• 経理への情報共有は、転記ではなく経理への通知や閲覧権限の整理で解決できるかもしれない
• そもそもステータスの定義は、チーム内で共通認識を持てているか確認が必要だ

つまり、課題を伝えることで、ベンダーが「より良い解決策」を考えるスタートラインに立てるのです。依頼者が思いつかなかった視点や機能が提案されることも珍しくありません。

なぜ「仕様を伝える」は危ないのか

仕様を伝えて依頼することには、見落とされがちなリスクが3つあります。

① 解決策の選択肢が狭まる

依頼者が思い描いた仕様は、あくまで「自分が知っている手段」の中からの発想です。kintoneには多様な機能があり、ベンダーには豊富な実績があります。課題を共有することで、自分では思いつかなかった、より適切なアプローチが見つかることは珍しくありません。「この課題なら、プラグインを使うよりも基本機能のこの組み合わせの方がシンプルで運用しやすいですよ」といった提案は、課題を共有して初めて出てくるものです。

② 責任の所在が曖昧になる

仕様通りに作ったものが使いにくかった場合、「その仕様を指示した側」にも責任があります。ベンダーとしては「言われた通りに作った」という立場になりやすく、改修の費用や対応範囲をめぐってトラブルになることもあります。一方、課題ベースで議論しながら設計したアプリは、ベンダーも「この課題を解決する」という目的を共有した上での成果物です。何か問題が起きたときも「仕様通りに作った」ではなく「一緒に考えた結果」として向き合ってもらいやすくなります。

③ 改修コストが増える

仕様だけを伝えると、実際に使い始めてから「あ、これも必要だった」「やっぱりここは違った」という抜け漏れや認識のズレに気づくことが多くなります。課題を起点に設計すると、必要な機能を最初から網羅しやすくなり、結果として手戻りが減ります。最初の設計に時間をかけた方が、トータルのコストが低くなる場合があります。

課題をうまく伝えるための3つのポイント

「課題を伝えるといっても、どう言語化すればいいかわからない」という方のために、実践的なポイントを3つ紹介します。

① 「今、何に困っているか」を具体的に話す

「なんとなく非効率」ではなく、「誰が・いつ・どんな作業で・どれくらい困っているか」を言語化してみましょう。「毎月末の集計に担当者が3時間かかっている」「月に2〜3回、入力ミスによるクレームが発生している」のように、頻度や影響範囲を伝えると、優先度の判断もしやすくなります。数字で表現できると、なお伝わりやすいです。

② 「なぜその業務が必要か」を添える

その業務が会社の中でどういう位置づけなのかを伝えることで、設計の優先度や方向性が変わります。たとえば「上司への月次報告用のデータ」と「現場スタッフが毎日参照する作業管理用のデータ」では、同じ情報でも見せ方・入力しやすさの設計が変わります。背景を伝えることで、ベンダーが本当に使われるアプリを設計できるようになります。

③ 「理想の状態」を伝える

完成形の仕様ではなく、「このアプリが使えるようになったら、どんな状態になっていてほしいか」を言葉にしてみましょう。「担当者が毎朝確認しなくても、対応漏れがなくなっている状態」「経理が自分でデータを確認できるので、私への問い合わせが減っている状態」——こうした「ゴールのイメージ」がベンダーに伝わると、機能の選択から画面設計まで、一貫した方向性でアプリを作ることができます。

仕様を考えるのは、ベンダーの仕事

よくある誤解として、「ベンダーに依頼するなら、ある程度仕様を固めてから相談しなければいけない」というものがあります。準備不足のまま相談することへの遠慮からくる発想ですが、これは逆効果になりやすいです。

良いベンダーであれば、課題を聞いてから仕様を一緒に考えることができます。むしろ、仕様を固める前に相談することで、最初から的外れな方向に進むことを防げます。「まだ何も決まっていないのですが……」という状態で相談を始めることは、決して失礼ではありません。それがプロへの相談の正しい使い方です。

kintoneの開発依頼は、「発注」ではなく「相談」に近いイメージで臨むと、うまくいくケースが増えます。依頼者が答えを持っていなくてもいい。「困っていること」を正直に話すところから、良いアプリ開発は始まります。

実際にあった話——「この業務フロー、何のためにやっているんですか？」

「課題を伝えることで、より良い開発につながる」——これは実際にアールスリーが支援したお客様の事例でも、はっきりと表れています。

ベンチャー企業の経営支援・IPO支援を行う響きパートナーズ株式会社様は、長年Excelで管理していた営業活動・売上管理・請求業務をkintoneで一元化するため、アールスリーに開発を依頼されました。

開発の過程でアールスリーの担当者は「この業務フローは何のためにやっているのでしょうか？」と繰り返し問いかけました。その結果、「何となく続けていただけで、実は不要だった仕様」がいくつも明らかになり、シンプルで使いやすいアプリが完成。また、当初の開発計画にはなかった「TC工数管理アプリ」をアールスリー側から提案したことで、請求書作成の工数が「2人で丸2日」から「半日×2人」へと大幅に削減されました。

担当者の森様はこう振り返っています。「踏み込んだ質問にはドキッとしますが、このおかげで最終的に良くなることが多かった」と。

これはまさに、課題を起点にした開発だからこそ生まれた成果です。

まとめ

外部ベンダーへの依頼で大切なのは、「何を作るか」ではなく「何に困っているか」を起点にすることです。課題を共有することで、ベンダーは当事者として考え、依頼者一人では思いつかなかった解決策を提案できるようになります。また、認識のズレや手戻りも減り、結果としてコストや時間の節約にもつながります。

「うまく伝えられるか不安」という方ほど、仕様を作り込む前に一度、「今、何に困っているか」をそのまま話してみてください。そこから、良いアプリ開発はスタートします。

📺 動画でチェック！

本コラムと連動した動画を公開しています。こちらも是非ご覧ください！

まずは「困っていること」を話すだけでOK——kintoneの無料相談会を毎日開催中！

「課題をうまく言語化できるか自信がない」「そもそも何から始めればいいかわからない」——そんな方のために、アールスリーではkintoneの無料相談会を毎日開催しています。

整理された資料も、固まった仕様も必要ありません。「今こんなことで困っている」というお話をそのまま聞かせていただくところから始められます。kintoneに関することであれば、開発の依頼を検討中の方も、すでに使っているけど困っている方も、どなたでもお気軽にご参加ください。