突然ですが、ビジネスサイドと上手く付き合えていますか？
仕様や期限で揉めたり、意図がきちんと伝わらないといったことはありませんか？

この記事では、エンジニアサイドの人間が、ビジネスサイドの人間と上手く付き合っていくためのコツをお伝えいたします。

あ、自己紹介が遅れましたが、フリーランスの立場からCOUNTERWORKSをお手伝いしていますvvvvkoyoです。COUNTERWORKSでは、主にエンジニアサイドを中心にお手伝していますが、他のお仕事ではビジネスサイドの仕事もしているハイブリッド型です。

そのため、ビジネスサイドとエンジニアサイド双方を知っている人間ならではの目線でお伝えいたします。

なお、この記事は受託系の会社ではなく、自社サービスを提供する会社を前提として書いています。

ビジネスサイドとの考え方の違い

まず、ビジネスサイドとエンジニアサイドで、基本的な考え方が違うということを理解しておきましょう。

ビジネスサイドの存在意義は、その会社のビジネス自体を伸ばすことです。
「ビジネスを伸ばす」をもう少し分解して捉えると、会社のリソースをうまく使い、最大限のリターンを得るということになるかと思います。言い換えると、ROI（Return On Investment）の最大化がビジネスサイドの目的であるといえます。そのため、まともなビジネスサイドの人間の考え方の根底には、ROIの最大化があるはずです。

対してエンジニアサイドは、ROIをきちんと考えられているでしょうか？
いくつかの会社を見る限りでは、ROIをきちんと考えられるエンジニアサイドは現時点では少数派です。

例えば、コードのかっこいい書き方に3時間使ったというケースを例に考えてみます。
その3時間が何かしらの金銭的なリターンを生めば良いのですが、多くの場合は何も生みません。せいぜい、そのコードが読みやすくなったというぐらいです。

これを見てビジネスサイドの人間は、「お金を生まない無駄なことに3時間も揉めるなよ」と思います。それに対してエンジニアサイドの人間は、「コードが読みやすく保守性が上がることにより、将来的な改修が楽になる」といったことを考えます。

保守性が上がることはもちろん大事ですが、何もお金を生み出さないことに時間をかけることはビジネスサイドからすれば「意味がわからない」ことです。しかし、エンジニアサイドからすれば、保守性の低下は大問題です。ここに大きな溝が生まれています。

とはいえこれは、ROIをどの時間軸で考えるかという話でしかありません。すごく長期的に考えれば、その3時間以上のリターンがあるかもしれないからです。ですが、「今」3時間を無駄にしたということは事実であり、「将来のリターン」についてビジネスサイドにうまく説明ができなければ、揉めてしまうことは仕方ないと言えるでしょう。

上記は一つの例ですが、思い当たる節がある方も多いのではないでしょうか？
ROI以外にも、ビジネスサイドと根本的に考え方が部分はいくつかあります。それらを事前に理解しておくことで、ビジネスサイドの人間が発する言葉の文脈をうまく捉えることができます。そしてそのこと自体が、ビジネスサイドとうまく付き合う第一歩といえるでしょう。

余談ですが、ROIを考えるか考えないかという部分については、エンジニアサイドが歩み寄るべき課題だと感じています。資金や人的リソースが無限にある組織であればROIを考えなくても良いですが、現実的にそのような組織はありません。そのため、ROIを考えながらその時々の最適な設計、実装、アーキテクチャの選定等々を行なっていくべきでしょう。

ビジネスサイドとの常識の違い

上述の通り、根本的な考え方が違うこともあるのですが、育ってきた文化が違うことも多く、ビジネスサイドとは常識が違うということも理解しておきましょう。

例えば、「メールより電話」、「チャットより直接の声かけ」といったように、多くのビジネスサイドは直接のコミュニケーションを好みます。なぜなら、多くのビジネスサイドの人間は、直接のコミュニケーションが常識であると教え込まれているからです。

また、「ググるよりも質問する」というのも、ビジネスサイドの特徴です。
エンジニアの多くは、「わからないことはググって調べる」のが常識と教え込まれていると思いますが、多くのビジネスサイドは「わからなければ質問する」と教え込まれています。そのため、エンジニアからすれば「ググれ」と言いたくなるようなことであっても、ビジネスサイドの人間は悪気なく質問してきます。どちらが良いというわけではなく、常識をどう教わったかという話に帰着します。

これらは一例ですが、仕事の進め方、考え方、チームの育て方、マネジメントの仕方などにも、少なからず常識の違いがあります。これはもう育ってきた文化が違うということで、お互い理解し合うことが大事です。尊重し合い、お互いにとって良いルールを作っていきましょう。

ビジネスサイドと揉めやすい部分

上記の前提を踏まえた上で、ビジネスサイドと揉めやすい部分とその解決法について解説します。

期限で揉める

あるあるなのが、期限でもめるケースだと思います。

「ここに文言追加してよ。文言追加するだけなら簡単でしょ？じゃあ明日までにやっといて！」みたいな言葉がエンジニアをイラっとさせるのは間違い無いでしょう。

多くのビジネスサイドの人間は、その対応にどれくらい時間がかかるのかわかりません。餅は餅屋なので当然ですが、ビジネスサイドが理想と感じる期限と、エンジニアサイドが理想と感じる期限は別物だと思った方が良いです。

この部分に差が出る理由は、ビジネスサイドの人間がエンジニアリングを知らないため見積もりが出来ないということもありますが、依頼されたエンジニアのタスク量をビジネスサイドの人間が把握していないという部分が大きいです。ハッキリ言ってしまうと、多くのケースにおいて、ビジネスサイド人間はエンジニアサイドのタスク量などには興味がなく、誰が何をやっているかなんて把握していません。他のチームのことなので、当然ですよね。（営業メンバ個人の今日の訪問先をすべて把握しているエンジニアっていますか？）

とはいえ、エンジニアサイドからすれば、タスク表だったりチケット一覧だったりを見れば、誰がどれくらいタスクを抱えているかなんとなく知ることが出来るのに、なぜこんな無理な依頼をしてくるのかと思うことも多いでしょう。ですが、再度言いますが、エンジニア個々人のスケジュールになんて興味はありません。そのため、多少無理な期限であっても、ビジネス都合という言葉を盾にタスクをねじ込もうとしてきます。

この問題とうまく付き合うためには、タスクをビジネスサイドにも見える形にしておくことが一番効果的です。ビジュアル化できるカンバンなどは良い例でしょう。カードが10枚くらい溜まっている人に（これはこれでタスク管理ができていなくて問題ですが）、ギリギリの期限で何かを依頼する人は少ないでしょう。

また、タスクを見える形にしておくことで、エンジニアサイドから期限を調整する時の理由づけがしやすくなります。例えば、「期限がN日までのタスクAあるため、今回依頼いただいたタスクBをやろうとした場合、タスクAの優先度を落とすか、タスクBの期限を伸ばすかのどちらかを選ぶ必要があります」といった当たり前の会話が、タスクが見える形になっているだけで抜群にし易くなります。

それでも無理な期限を言ってくるビジネスサイドの人間には、そのタスクを実行することで具体的になんのリターンがあり、それがどの程度必要なものなのかを説明させましょう。納得すればタスクを調整して、それが納得できなければ突き返しましょう。

完成度で揉める

多くのビジネスサイドの人間は、システムなんて「動けばいい」と思っています。
そのため、見た目の動きが正しければ、そのモノは完成品だと感じます。

とはいえ、現実的には動くだけのモノは危ういです。性能面に課題があったり、異常系の処理が何も書かれていなかったりと、不足部分がある場合が多いからです。

このような危うさを危惧して、エンジニアサイドは「まだ完成していない」というでしょう。
とはいえ、動くものを見たビジネスサイドは「完成品」だと思うわけです。

この差を埋めるにはどうすれば良いでしょうか？
一つの答えとしてあるのは、「タスクを明確」にすることです。

なんとなく動く状態は、タスク全体の1/N程度であるといったことがわかるよう、対応全体のタスクを明確にしてみましょう。言葉で言って伝わらないケースは多くとも、明確化されたタスク表などを見せられることで、ビジネスサイドの人間にもタスクの正確な進捗度合いが伝わるはずです。

もう一つあるとすれば、「危険を見える化」すべきです。
「このバグが発生するとこのような危険があるため、ビジネス面でもこのような課題が発生する可能性がある」だとか、「性能が劣化するとPVがN%下落する可能性が高く、事業の収益が下落する可能性がある」だとか、ビジネスサイドの人間にも伝わる言葉でエンジニアリング観点の危険を見える化してあげましょう。そうすることで、ビジネスサイドの人間も正しい判断ができるようになるはずです。

ただ、上述の危険を踏まえても、完成度を犠牲にして早くリリースすべきという判断が出るケースもあります。その場合は本当にヤバいものの場合は引き下がってはいけませんが、多くの場合エンジニアサイドがリスクを高く見積もりすぎのケースが見受けられます。再度リスクを見直し、許容できるリスクだと判断できればリリースしてしまっても良いでしょう。

仕様で揉める

多くのビジネスサイドの人間は、エンジニアサイドについて、黒魔術を使う何かだと認識しています。そのため、自分の依頼を伝えれば、何かうまくやってくれる何かだと思っています。とはいえ、エンジニアもただの人間なので、出来ないものは出来ません。

例えば、「ユーザの情報をもっと表示してほしい」という依頼がビジネスサイドの人間から出たとします。普通のエンジニアであれば、下記のような疑問を抱くはずです。

• ユーザって誰
• 情報ってなに
• もっとって何
• 表示ってどこに、何件
• っていうかそもそもなんで？

そしてこう返すでしょう。
「仕様がハッキリしていないので、仕様を固めてから依頼してもらって良いですか？」
決まっていないモノを作ることは出来ないかです。当然ですよね？

でも、ビジネスサイドの人間からしてみると「それくらいお前らで考えろよ」と思うわけです。なぜなら、「それくらい」が決まっていないとシステムは作れないということを知らないからです。また、「それくらい」黒魔術でうまくできると思っているからです。

仕様で揉めるケースの根本的な課題は下記の二つです。

• エンジニアの守備範囲をビジネスサイドが理解していない
• システムを作るときに、どのようなタスクがあるのかを知らない

課題の一つ目の本質は、組織内の役割が明確化されていないということです。

多くの場合、いわゆる「ビジネス要件」を決めるのはビジネスサイドの仕事であると、「エンジニア」は認識しています。とはいえ、何が「ビジネス要件」に当たるのかを、エンジニアサイド・ビジネスサイドの双方が認識していないケースは多いです。そもそも、ビジネス要件という言葉自体がかなり曖昧な言葉なので、組織の中できちんと定義しないといけない言葉です。

そのため、まずは「ビジネス要件」という言葉の認識をチーム内で揃え、その上で、「ビジネス要件」はビジネスサイドが決めるというルールが有効です。

認識と決めがしっかりしていれば、仕様がハッキリしていない依頼はそうおう発生しませんし、発生したとしてもルールを盾に突っ返すことは容易です。もちろん、場合によってはビジネス要件を含めて考えてくれといったことも発生するかと思いますが、その場合はエンジニアサイドで考えろということなので、仕様で揉めること自体もないかと思います。

課題の二つ目は、組織内の役割分担がハッキリしているケースでよく見受けられます。営業は営業だけ、開発は開発だけ、サポートはサポートだけといった感じでやっていると、自社のサービスを作るときにどのようなタスクがあるのか、エンジニア以外はほとんど把握できません。また、他の職種について勉強する人は稀であり、それも相まって、システムを作るときのタスクを認識しているビジネスサイドのメンバは稀でしょう。

もちろん、一般論の部分はエンジニアリングの本を読んだりすることで、ビジネスサイドのメンバであっても十分補完することはできます。とはいえ、多くの場合においてビジネスサイドのメンバはエンジニアリングに拒否反応を示す場合が多く、最初から本などを薦めるのは難しいでしょう。

とはいえ、この部分を知ってもらわない限り、仕様を決めることの重要さ、仕様が曖昧だとシステムが作れないという事実を理解してもらうことはできません。

そのため、理想を言うならば、ビジネスサイドのメンバがエンジニアリングを理解するきっかけを与えられるとベストです。とはいえ現実解としては、ビジネスサイド向けのシステムの勉強会といったものが落とし所でしょう。

ビジネスサイドとの上手な付き合い方

長々と書きましたが、お互いを理解して、お互いを尊重することが一番大事です。
歩み寄るところは歩み寄って、良いチームを作り、良いサービスを生み出していきましょう。