「できます」と答える前に。
TomokiImaizumi良いWebアプリを作るための提案・交渉の力
Webアプリの開発を相談するとき、こちらの要望に快く応えてくれる開発者は、頼もしく感じるものです。
機能を追加したい。公開を早めたい。予算内でもう少し対応してほしい。
そうした相談に柔軟に応える姿勢は、もちろん大切です。
ただ、内容を十分に確認せず、すべてに「できます」と答えることが、お客様のためになるとは限りません。
作るものが増えれば、費用や開発期間だけでなく、操作の複雑さや公開後の管理にも影響します。
だからこそ、開発者には実装する力に加えて、要望を整理し、必要な条件を確認し、別の方法を提案する力が求められます。
良い開発のパートナーは、お客様が実現したいことを理解したうえで、進め方を一緒に考えます。
今回は、私自身の音楽コミュニティ運営とWebアプリ開発の経験をもとに、安請け合いをせず、お客様の目的を守るための提案・交渉についてまとめます。
目次
- 要望に応える前に、実現したいことを確認する
- 「高い」「使いづらい」の背景に改善のヒントがある
- 費用・納期・範囲を整理して、選べる提案にする
- AIで開発が速くなっても、約束する前の確認は必要
- お互いが無理なく続けられる関係が、サービスを育てる
1．要望に応える前に、実現したいことを確認する
お客様から機能追加の相談をいただいたとき、最初に考えるのは、その機能をどう作るかです。
ただ、その前に確認したいことがあります。
その機能で、どのような困りごとを解決したいのでしょうか。
例えば、イベント管理アプリに「参加者への一斉メール機能が欲しい」という要望があったとします。
背景には、いくつかの可能性があります。
- 申し込み期限を忘れる人を減らしたい
- 会場変更を確実に伝えたい
- 毎回同じ案内を送る作業を減らしたい
- 参加していない人にも次回の企画を知らせたい
同じ「一斉メール」でも、目的が違えば必要な仕組みは変わります。
期限の案内なら、自動リマインドで解決できるかもしれません。会場変更なら、重要なお知らせを目立たせる表示も必要でしょう。案内作業の削減なら、定型文を保存するだけでも効果があるかもしれません。
実装方法を決める前に、目的を確認することで、より小さな仕組みで解決できる場合があります。
コミュニティ運営で気づいた「手段を見直す」大切さ
私は音楽コミュニティの運営も行っています。
合同イベントの準備では、料理と飲み放題が付いたプランを検討していました。食事を囲みながら交流できる、魅力的な内容です。
一方で、参加を検討している方からは、飲食より演奏を楽しみたい、仕事帰りに短い時間だけ参加したい、といった声もありました。
そこで、イベントの目的を改めて確認しました。
大切にしたかったのは、音楽を通じて新しい人とつながることです。
その目的に照らして、会場を借り、飲食は各自で選べる形式へと方針を見直しました。具体的な条件は、会場と確認しながら調整している段階です。
Webアプリ開発でも、同じように手段を見直すことがあります。
お客様の最初の案を尊重しながら、その背景にある目的まで理解する。そこから、より使いやすい方法を一緒に探します。
この章のまとめ：何を作るかを決める前に、何を実現したいかを共有しましょう。
2．「高い」「使いづらい」の背景に改善のヒントがある
サービスを提供していると、価格や使い勝手について率直な意見をいただくことがあります。
時間をかけて準備したものほど、説明を追加して納得してもらいたくなるかもしれません。
もちろん、内容や費用の説明は必要です。ただ、説明するだけでは解決しないこともあります。
提供する価値と、必要とされる価値を確かめる
機能が充実していても、使われなければ十分な価値を届けられません。
例えば、小規模な事業者向けの予約管理アプリを考えてみます。
詳細な分析画面、複雑な権限設定、多数の通知方法が用意されていても、利用者が最も困っているのは、予約の重複や変更連絡かもしれません。
その場合は、予約状況が一目で分かり、変更を簡単に伝えられることが優先されます。
作る側が力を入れた部分と、使う側が助かる部分は、必ずしも一致しません。
価格についても同じです。
「高い」という声には、予算が足りない場合だけでなく、必要な機能が少ない、効果が分からない、利用頻度に合わない、といった背景が考えられます。
そのため、すぐに値下げする前に、どこに負担を感じているのかを確かめることが大切です。
意見を具体的な改善につなげる手順
私は、次の順で整理すると考えやすいと感じています。
- 困っている場面を確認する
誰が、いつ、どの作業で困っているのかを把握します。 - 現在の対処方法を聞く
表計算ソフト、メール、紙のメモなど、今の業務を確認します。 - 負担の大きさを確かめる
作業時間、対応件数、ミスが起きた場合の影響を整理します。 - 解決方法を複数考える
新機能の追加だけでなく、画面や案内文の改善、運用の変更も検討します。
利用者が「使いづらい」と言った画面も、ボタンの位置が問題なのか、説明が足りないのか、そもそも手順が多すぎるのかで、対応は変わります。
意見を具体的な場面に落とし込むことで、改善の方向が見えてきます。
この章のまとめ：率直な意見は、必要とされる価値を見つけ直すための情報です。
3．費用・納期・範囲を整理して、選べる提案にする
開発中に新しいアイデアが出るのは、自然なことです。
画面を実際に使ってみて初めて、必要だと気づく機能もあります。
ただ、追加の要望を受けるたびに、その場で対応を約束してしまうと、開発全体に影響が出ることがあります。
そこで重要になるのが、費用・納期・対応範囲を整理したうえでの相談です。
一つの追加が、複数の変更につながることもある
例えば、顧客管理アプリに「担当者だけが見られるメモ欄」を追加する場合です。
入力欄を置くだけなら、小さな変更に見えます。
しかし、実際には確認すべきことがあります。
- 担当者が変わった場合、誰が見られるのか
- 管理者は閲覧・編集できるのか
- 一覧画面や検索結果に表示してよいのか
- データを出力するときに含めるのか
- 過去の情報をどう扱うのか
見た目の変更は小さくても、アクセス制御やデータの扱いまで検討が必要になる場合があります。
こうした影響を説明することも、開発者の役割です。
「対応するか」だけでなく「どう進めるか」を提案する
相談の際には、例えば次のような選択肢を用意できます。
| 進め方 | 向いている場面 |
|---|---|
| 当初の予定どおり公開し、後から追加する | 公開日を優先したい |
| 優先度の低い機能と入れ替える | 予算や期間を維持したい |
| 必要最低限の形で先に導入する | まず効果を確かめたい |
| 費用と期間を追加して対応する | 今回の公開に必要な機能である |
どの案にも利点と制約があります。
大切なのは、お客様が判断できる情報を揃えることです。
費用が変わるなら、その理由を説明する。納期に影響するなら、どの作業が増えるのかを伝える。簡易版を提案するなら、できることと制限を明確にする。
そして、決まった内容は文章で共有します。
認識を揃えてから作業に入ることで、後からの行き違いを減らせます。
この章のまとめ：条件を明確にすることは、お客様が納得して選ぶための支援です。
4．AIで開発が速くなっても、約束する前の確認は必要
AIを使うことで、コードの作成や調査、画面の試作を速く進められる場面が増えています。
私自身も、AIを活用しながら開発を行っています。
アイデアを早く形にし、実際の画面を見ながら相談できることは、大きな利点です。
一方で、コードが短時間で作れることと、安心して運用できる機能が完成することは、同じではありません。
画面が動いた後にも、確認することがある
例えば、参加申し込みを取り消す機能を作る場合。
ボタンを押してデータが消えれば、基本の動作は確認できます。
しかし、サービスとして使うには、さらに考えることがあります。
- 本人以外が取り消せないか
- 締め切り後にも操作できてしまわないか
- 画面を開いたまま締め切りを過ぎた場合はどうなるか
- 関連する通知や集計に影響しないか
画面上でボタンを隠すだけでは、操作を十分に制限できない場合もあります。サーバー側でも条件を確認するなど、仕組み全体を見る必要があります。
AIによる実装支援は有用ですが、必要な条件の整理や、変更の影響を判断する責任は残ります。
試作と正式対応を分けて伝える
開発の相談では、まず小さな試作を用意し、使い方を確認することがあります。
その際は、試作で確認できたことと、本番導入までに必要な作業を分けてお伝えします。
例えば、画面の操作感は確認できたものの、権限管理や既存データへの対応はこれから、という状態です。
ここを曖昧にすると、試作が動いた時点で完成したように受け取られてしまう可能性があります。
早く形にできるからこそ、どこまで確認できているかを丁寧に共有する。
その積み重ねが、AIを使った開発でも信頼につながると考えています。
この章のまとめ：開発の速さを価値にするには、確認と説明の丁寧さが欠かせません。
5．お互いが無理なく続けられる関係が、サービスを育てる
Webアプリは、公開後にも改善が続きます。
利用者が増えれば、新しい使い方が生まれます。業務が変われば、必要な機能も変わります。
そのため、一度の開発だけでなく、その後も相談しやすい関係を作ることが大切です。
安請け合いは、長期的な負担になることがある
追加の対応を無条件で引き受け続けると、開発者の負担が増えます。
確認や改善に使える時間が減り、結果としてお客様への対応にも影響するかもしれません。
反対に、契約範囲だけを理由に相談を切り上げてしまえば、お客様は必要な改善を伝えにくくなります。
だからこそ、要望は丁寧に受け止め、そのうえで進め方を相談することが必要です。
対応範囲、費用、優先順位、確認方法を明らかにする。今すぐ必要なものと、後からでもよいものを一緒に考える。
お互いが納得して進められる条件を作ることが、サービスを長く育てる土台になります。
開発を相談するときに、伝えていただきたいこと
最初から詳しい仕様書がなくても大丈夫です。
まずは、次のような情報があると、具体的な相談につながります。
- 現在、どのような作業に困っているか
- 誰が使う予定か
- いつまでに、何をできるようにしたいか
- 予算の目安や、優先したい条件
- 今使っているツールや業務の流れ
内容が固まっていない場合も、整理するところからご一緒できます。
私が大切にしているのは、お客様の要望の背景を理解し、実際に使える形へつなげることです。
音楽コミュニティの運営でも、自分で開発・運用するアプリでも、使う人の声を聞いて初めて気づくことがたくさんあります。
その声を受け止めながら、目的、費用、運用のしやすさを考えて判断する。
必要なときに別の案も提案できることが、開発のパートナーとしての誠実さだと思っています。
Webアプリや業務の仕組みづくりについて、まだアイデアの段階でも、お気軽にご相談ください。
実現したいことを整理しながら、無理なく始められる方法を一緒に考えていきます。
この章のまとめ：率直に相談し、納得して決められる関係が、良いサービスを育てます。
