営業の「これできる？」になぜ開発は「できます！」と即答できないのか？
本記事はアプレッソAdvent Calendar第1日目の記事です。
というわけで今年もこの時期がやって参りました！ 弊社株式会社アプレッソの開発部およびその関係者がプログラミングやソフトウェア開発、それにまつわる話題について毎日書き尽くす1ヶ月です。 第一回目となる今回は私、土岐が担当させていただきます。
私はアプレッソではDataSpiderを始めPIMSYNC、Thunderbusなどの製品開発を担当しております。
会社によって呼び名は違うとは思うのですが、ソフトウェア開発においてお客様と直に接して販売する立場の人間を「営業」、ソースコードを実際にコーディングしてソフトウェアを作る立場の人間を「開発」とざっくり呼ぶことにします。
今回は、この「開発」と「営業」の関係をテーマに記事を書きたいと思います。
なお最初に注意書きしておくと、弊社での話ではなく一般的なソフトウェア開発の現場での話として書いています。その前提でお読みいただけると幸いです。
「これできる？」、そして「開発 vs 営業」？
ソフトウェア開発をやっている方なら経験あると思うのですが、営業の方から「これできる？」と聞かれることがあります。 例えば、
- この機能があれば製品を買う！ とお客様から伺った
- 既に購入されているユーザーから「こういうことがやりたいんだけどできないかな？」と相談された
- この機能があれば売り上げが見込める市場がある などの場合ですね。
で、こういうとき開発としてはいろいろ悩みます。
悩みながら「スケジュールが・・・」「リソースが・・・」「要件が・・・」とか話していると、営業の方から見ると、「やらない理由を探してる」ように見えることがあるようです。
営業の方から見れば「やれるかやれないのか聞いてるだけなのに！」という苛立ちが発生してしまう。
その結果、「開発が動いてくれない」「営業は分かってない」みたいに最終的に「開発 vs 営業」という対立関係の構図になることがあります。
そのような事態になる原因としては誰の責任というよりも、伝え方の問題だったり情報共有不足だったりと様々な原因が考えられます。
ただ、同じ「良い製品をユーザーに使っていただきたい」という目的のために仕事をしてるのに、そのようなことで対立するのは不毛だと思うわけです。
で、開発を担当する私としてはいろいろと伝え方を検討しながら改善しています。
ただ、あらためて「これできる？」と聞かれたときに開発の立場としてどのようなことを考えているか？ ということは整理されていないし、情報としてまとまっていないのが事実であります。
そこでこの機会に検討して整理してみよう！ というのが今回の記事の趣旨であります。
大前提＝開発は「できる」「やりたい」！
まず開発者として私の経験から前提を書かせていただきます。もちろん、すべての開発者がこのように思っているかどうかは保証はできかねますが、ある程度一般的な意見ではないかと思います。
そのように営業の方から「できる？」という問いが出てきたとき、ほとんどの場合、技術的には「できます」。そして「やりたい」です。
もちろんこれにはいろいろな留保があって、現代の技術では実現不可能であったり、社会的に問題のある技術であったりする場合があります。
例えば以下のようなものです。
- 200TBのデータを0.001秒で日本からアメリカに送りたい(現代の技術では実現不可能）
- 日本全国の人間のマイナンバーを収集したい（社会的に無理）
- 織田信長にメールを送りたい（無理）
このような場合には「できません」と即答せざるをえません。
もちろん営業の方は開発と立場は違うとは言え、同じ会社で働いて現代に生きている人間なわけです。
そんな「あからさまに無理」なものを「できる？」と聞くことはありえません。
ということでほとんどのの場合は「できる」わけです。
ただもちろん、リリースまでにかかる時間であるとか必要なリソースに関しては度外視した上で、です。（この辺は後述します）
そして基本的には「やりたい！」のです。
なぜならば開発者としては日々、そういうユーザーからの要望に応えて使っていただきたい、という思いから技術を研鑽していただいているわけであります。蓄積してきた技術を発揮してそのような絶好の機会に、やりたくないわけがありません。
というわけで、そういう中で持ち込まれた「これできる？」という質問には、
「できます！」
と答えたい、あわよくば、
「もうできてます！」または「すぐできます！」
とくらい答えたいわけです。
開発者は決して「やりたくない」とか「やらない理由を探してる」ということは全く無く、「やりたい！」というの欲望を持っているわけです。
ではなぜそう答えられないのか？
「これできる？」と聞かれたときに考えること
ここからは具体的な例で検討してみます。
とはいえ、現実に存在するものだといろいろと問題があるので、例えば以下のような例で考えてみましょう。
データ連携ソフトウェア「DataSniper」
という架空のソフトがあります。あらゆる離れたところにあるデータを狙撃して連携する、というのがテーマのパッケージソフトウェアです（架空）。
▲あらゆるデータを狙撃する！ データ連携ソフトウェア「DataSniper」アイコン（架空）
で、そのソフトウェアの営業の方から、開発がこう聞かれました。
「亞風列荘というレストランにオムライスの出前を頼める機能がほしいんだけど、これできる？」
亞風列荘(アプレッソウ）とはオムライスが名物の老舗レストランです（架空）。 ユーザーの企業ではがその店に出前を頼む社員が多く居るため、その注文業務を自動化したい、ということでそのような要望があったというストーリーです。 （極端な例ですが！）
▲みんな大好き！ 美味しいオムライス（実在）
これを聞いたとき、「できます！」と言いたい気持ちをぐっと抑えて、開発はだいたい以下の4つのことを考えます。
- その機能がユーザーの本当に望む機能なのか？ = 要件定義の問題
- その機能が技術的に可能なのか？ どのような技術で可能なのか？ ＝ 技術的な問題
- その機能が製品にとって必要があるのか？ = 製品設計の問題
- ユーザーが望む期限までにリリースが可能なのか？ そのリソースがあるのか？= スケジュール・リソースの問題
（実際にはこれ以外にもさまざまな要素があるのですが、ここでは割愛します）
これらの4つは密接に関係し合っており、1つ1つの影響を検討しつつ最終的な結論になるわけです。 これらについて1つずつ検討していきます。
要件定義の問題 ～オムライスだけでいいのか？
例えば何も考えずに「DataSniperに、亞風列荘にオムライスを注文する機能を付けました！」と作ったとします。
ところが運用してみると・・ 「ハンバーグ定食を注文したい」 「亞風列荘以外のお店にも注文したい」
などの要望が出てくることが予想されます。
その度ごとに「じゃあハンバーグ定食の機能も・・・」「亞風列荘以外の店にも注文できる機能を・・」とDataSniperに機能を追加していくと、そのたびごとにユーザーは機能のリリースを待つことになり、開発としてもその度ごとに機能の開発・テストを行うことになり負荷が大変大きくなります。
そこでここで抽象度を上げて、 「亞風列荘にオムライスを注文する機能」→ 「ユーザーが指定した連絡先に、ユーザーが指定したメニューを注文する」 という機能とすることで、そのような要望にも対応できる汎用的な機能としてリリースすることを提案したりします。
また、実は本当の要望をヒアリングしていくと「社員の注文を集計する機能が欲しい」のであって「注文する機能が欲しい」わけではなかったりすることが考えられます。 その結果、実は既存の機能で対応できることが分かり、リリースを待つ必要がなかったりすることがあります。
この要件定義を失敗してしまうと、どんなに技術的にエレガントに解決したとしても、どんなに急いで機能を実装したとしても、全く使われない機能となっていまい、ユーザーもベンダーとしても全く幸せではない状況が発生してしまいます。
ということで、開発しては
- その機能で本当にユーザーの要件は満たせるのか？
- 機能要望が出てきた背景としてはどのようなことがあるのか？
- 他の既存機能で既に実現できる機能ではないのか？
などを確認・相談しながら進めていくことをまず考えます。
技術的な問題 ～どうやって注文するか？
それでは要件定義はクリアして、実際にどのように実装するか？ という技術的な検討に入ったとします。 ここでは例えば「注文する」という機能をDataSniperに実装しようとしたときの検討事項について考えたとします。
その場合、以下のようなことを考える必要があります。
- 使用しているOSやプログラミング言語で実現できる機能か？
- ソフトウェアにどのように機能を追加するか？
- 機能を追加した場合、非互換が発生しないか？
この辺は細かく検討していくとキリがないのですが、「どのように注文するか？」ということに焦点を絞って検討してみます。
まず確認するとすると、「亞風列荘はどのような注文のインターフェースを用意しているか？」ということが問題となります。 それによって実装の難易度や工数が大きく変わってくるからです。
例えば
REST APIをを持っている先進的なレストランだった！
- 多くのプログラミング言語ではHTTPリクエストの機能を持っているので実装が容易
- 既にREST APIを叩く機能がDataSniperに実装されているのであれば、エンハンスの実装なしに対応が可能かも
注文書をFAXで受け付けるレストランだった
- 注文を集めてFAXを送信する機能を検討
- FAX送信サービスなどの外部の機能を利用することを検討→そのサービスのインターフェースは?
電話注文のみの受付しかできない
- 自動で電話をする外部サービスの利用を検討
- 自動で注文の音声を作成する機能の実装を検討
電話も無い。伝書鳩でのみ受け付けることしかできない
▲みんな大好き！ 可愛い鳩（実在）
など、インターフェースによって使用する技術やそれにかかる難易度や実装にかかる工数が大きく変わってきます。 またそれぞれの方法においても利用する言語やOS、外部サービス、さらに実装方法によって変わってきます。
この辺を要件やスケジュールと照らし合わせた上で、最終的な「できます！」という判断をする必要があります。
製品設計の問題 ～注文機能を標準の機能とすべきかどうか？
ここは特にパッケージソフトウェアにおいては重要となるところであり、議論の対象となるところです。 SIのようにそのユーザーに向けたソフトウェアを作成する場合に比べて、パッケージソフトウェアに標準の機能として必要かどうか、ということを検討する必要があります。
例えば「亞風列荘にオムライスを注文する機能」をDataSniperの標準機能としてリリースした場合、他のユーザーにとっても同じ機能がリリースされるわけであります。 当然のように、他の会社にとっては何の役に立たない機能になってしまいます。 そして、「使えない機能がゴテゴテとある使いにくいソフトウェア」という印象を持たれてしまい、DataSniperの製品としての価値を下げてしまうことにも繋がりかねません。
さらに、ソフトウェアにはリリースした後にも、その機能が常に十全に使用できるようにメンテナンスをし続ける必要があります。 多くの機能があればあるほどメンテナンスにリソースがかかってしまい、それによって本来実現したい機能のリリースが出来なくなってしまう・・・という悪循環に繋がる可能性があります。
これまで検討してきたように、
- 指定された連絡先に指定された注文をする機能
として実装すれば汎用的な機能として使えるかもしれません。 さらに切り分けて、
- 指定した電話番号に電話をかける機能
- 指定した文字の音声を作成する機能
とすれば、また製品としての機能強化にも繋がってユーザーもベンダーも良いかもしれません。
または機能として追加するのはあえてやらずに、
- 既存機能を利用して外部サービスのAPIを叩くことで実現する
ということが最もベストな選択肢である可能性もあります。
そしてまた別のオプションとして、パッケージソフトウェアのベンダーとしてはあまり取りたくない選択肢ではありますが、
- ユーザーに特化したカスタマイズされた機能を非標準の機能として実装する
という選択を取ることもありえます。
「製品としてその機能はどういう位置づけになるのか？」
「汎用的な標準機能としてリリースできるか？」
「標準機能にできないのであれば、どのような実現方法があるのか？ それはユーザーも納得できる方法か？」
などの検討がここで行われるわけです。
スケジュール・リソースの問題 ～で、結局いつリリースできるのか？
ということでようやくここに行き着きました！
最も議論になるポイントであります。
ここまで検討してきたものをクリアして、では「その機能を作りましょう」となったとき、当然のように開発スタートからリリースまでにはさまざま過程があり、時間がかかります。
例としては以下のような過程があります。
- 技術検証
- 機能実装
- テストケースの作成
- 製品利用マニュアルの作成
- QA(品質保証チーム)によるテスト
- リリースドキュメントの作成
これらには並行して進めことのできるタスクもありますが直列でしかできないタスクがあるので、いくら人員（リソース）を増やしたとしても限界があります。
また、社内には常に限られたリソースしか無いわけであり、そのとき別の大きなプロジェクトが動いていれば投入できる人員にも制限が発生します。
そういうことを鑑みながら、できるだけユーザーの要望に添った形でリリース可能な日付を調整しながら検討していきます。
そこを考えずに、
「これできる？」「できます！ でもいつできるかは分りません！」
と胸を張って答えたとしても、冷ややかな笑顔を浮かべられるだけです。
だいたいこういうときは、ユーザーが「●●年○○月××日に新しいシステムがカットオーバーするので、その2ヶ月前くらいに欲しい」みたいな感じで希望時期があります。
それを聞いた上で、
- 通常のリソースとフローで開発を行った場合、それまでにリリースできるか？
- リリースできない場合、人員の投入によって間に合わせることは可能か？
- 間に合わせられない場合、ユーザーと交渉してリリースを遅らせることは可能か？
- 社内の別のプロジェクトよりも優先してやる必要があるか？
- リリースを遅らせることができない場合、今回は実装の対象外とできる機能はあるか？
- 通常フローとは別に、β版を先にリリースすることで対応することはできるか？
など、さまざまな施策で実現へ向けての検討を行い、社内やユーザーと相談・調整をしながらスケジュールを決定していくことになります。
（もちろん、スケジュールが決っても開発に入ると予想外の問題が発生してスケジュール調整が必要になってきて・・・みたいなこともあり得るのですが、そこはまた別の機会に・・・）
結果「これできる？」にどう答えるか？
「これできる？」から始まる長々とした検討にお付き合いいただきありがとうございました。
では改めて、元の営業からの「これできる？」とはこういう質問でした。
「亞風列荘というレストランにオムライスの出前を頼める機能がDataSniperにほしいんだけど、これできる？」
これまでのことを全部踏まえて、全部の情報入りで答えると、以下のような感じです。
（※ 書いてみると強烈にウザくなったので小さい文字にしています。）
「注文するのはオムライスだけでいいんですか？ ハンバーグ定食も必要なのではないですか？ あと亞風列荘以外のレストランにも注文したいという要望は無いですか？ そういうこと考えると、それぞれ指定できた方が運用しやすいですよね。でも本当は注文できる機能じゃなくて、注文を集める機能であれば要件を満たすっていうことは無いですかね？ その場合、既存機能でも対応可能かもしれないので、その検討を依頼することは可能ですか？ あと亞風列荘の注文インターフェースって何ですか？ REST？ FAX? まさか伝書鳩じゃないですよね？ それによってリリーススケジュールが変わりますね。あと使用しているOSやスペックによっても実現可能なものって変わってきますよね。この機能って汎用的に使いにくいので、もうちょっと電話できる機能とか音声作る機能とかに切り分けて機能を設計しないと標準機能としてリリースするのは厳しいですよね。その辺はユーザーの要望もあると思うので相談しつつ進めたいんですが大丈夫ですか？ あと希望時期はありますか？ それは確定的なものですか？ 今他のプロジェクトが動いているので来年4月までは動きづらいんですよね。もし普通にやるとだいたい再来年になってしまうんですが、優先度が高いようだったら社内で調整する必要があるんだったらそうしますがどうですか？」
はい、ものすごくやりたくなさそうな雰囲気が漂ってきました・・・。
この辺が伝え方の難しいところで、開発としては「検討しなければならないことがある」ということを具体的に伝える必要があるのですが、それをどういう順序でどのように伝えるか、ということで営業とのすれ違いが発生してしまい、冒頭に書いたような対立構造にまでなってしまうことがあります。
これはどのように伝えればベストか、ということは製品や対象とする機能、または要件やそのときの状況でケースバイケースで正解は無い、とは思います。
ただ個人的に必ず気を付けるているのが、
実現するためにはどうすればいいか？
というポジティブな目的のために話を進めていくことです。
どうしてもいろいろなリスクを考慮していくと、「やらない」というのが一番楽で、「やらない理由」を探すのが一番簡単、という罠があります。
もちろん、苦渋の選択として「やりません」「できません」と答えざるをえない場合もあります。
ただ、それは最後の選択肢であって、それに向けて議論を進めることは避けるべきだと思います。
常に、共通の目的に向けて、営業と開発が協力して良い方法を模索していく、ということが、ユーザーにもベンダーにとっても、そして営業にも開発にも、製品にとっても良い方向に作用するのではないか、と思うところであります。
終わりに
気軽に書こうとしたら大変な分量になってしまいました・・・しかも結構絞ったはずなのに。
まだまだ書きたいことはあるんですが、ぜひこれをお読みいただいた開発の方、そして営業の立場の方からも、ご意見をいただき、またアップデートできると嬉しいとこです。
良いソフトウェアを楽しく作っていきましょう！
ということでアプレッソAdvent Calendar1日目は終了です。
明日は合気道の使い手でもある開発の田中から、彼の合気道経験を踏まえた何かしらの技術ブログがアップされるはずです（何書くのが知らないのでテキトーに言ってます）。
お楽しみに！
