こんにちは。初めてブログを執筆させていただきます。
株式会社ROBOT PAYMENTで請求管理ロボの開発を担当している芳賀（はが）です。
株式会社ROBOT PAYMENTは6年目となりますが、エンジニアは1年目の超新人です。
エンジニア転向前は、カスタマーサクセス部に所属して、請求管理ロボのオンボーディングやお問い合わせの対応など、顧客対応に従事しておりました。
現在は、プロダクトの一部である「請求まるなげロボ」を中心に開発に従事しています。
社内でも珍しい異動経緯ではありますが、エンジニアチームの方々にも快く受け入れてもらったと思っております。（そうであって欲しいと切に願います）
まだまだ開発経験が浅く、技術的な発信ができない私ですが、Biz←→Dev間を行き来した経験や思いはシェアできるものがあると思い共有させてもらえればと思います。
BizとDevを隔てる『壁』の正体
感じた壁
「壁」と表現すると、ネガティブな印象を持つ方もいらっしゃるかも知れませんが、フラットに聞いていただければと思います。
１）言語の壁
これが最も分厚い壁と言って過言ではないと思います。「知識の壁」と言い換えても良いかも知れません。
異動後初めての会議での絶望は忘られません。
EM「ガズルを使って〜」
芳賀「なるほど（わかってない）」 → ガズルを裏で検索しながら聞く
他の先輩社員「というかガズルをモックして〜」
芳賀「あかんもう無理や」
またその後も、いろいろと導入支援を受ける中で、開発者としては「知っていて当たり前」という単語が多く存在しその都度、聞いたりコンテキストから理解したりなど苦労は絶えませんでした。
他部署間のコミュニケーションでも発生することも経験上知っていました。
お互いに「当たり前に知っていると思っている」ことがコミュニケーションに余白を生み、認識齟齬などにつながることを体感しました。
（開発業務で考えるとこれが要件定義時の認識ズレなどを呼ぶことがよくあることかなと思います）
この経験から、発信側が相手の知識レベルを意識して話すことは非常に重要ですが、もちろん限界もあるため
お互いに相手の言っていることを正しく理解しようとする姿勢こそがこの壁を乗り越える正攻法だと考えています。
「聞くはいっときの恥」と言いますが、業務上は「聞けばバグやインシデントが減る」と言えると思います。
２）視点の壁
これは、たとえば「より良いサービスをお客様に提供する」「お客様の困りごとを解消する」という目標を追いかけていたとしても BizサイドではWhat（ゴールやその先にある効果）に目を向け、DevサイドではHow（ゴールに至るまでの道のりやその後の道の保守） に目を向けていることによる視点の壁です。
不思議と同じ目標に向かっていても、この視点の差が方向性を徐々にズラしていき意見の衝突につながることもあります。
しかし、この視点は両方ないと求められない機能の実装や技術的負債の温床になるため必要な差でもあると思います。
それぞれの職責に熱心に向き合うほどこの差が生まれるのだと考えています。 「なんでこの機能作ってくれないの？」「リスクや技術的負債になるじゃん」とお互いの主張をマイナスに捉えすぎずに、
「その気持ちもわかるけど、こういう背景があるから現実的にこういうのはどうか」とあくまでゴールである「お客様のために」が達成できることをルールに建設的に議論のテーブルに乗せることで少しずつお互いの意見の着地点を見つけられると思っています。
３）情報の壁
これは最も温度差を感じる壁でした。「温度差」とはプロダクトに向けられる思いの強さです。
この壁について印象的なやり取りがあります。ある同僚の方と会話をしていた際、開発中の機能について私がBiz時代に
「ずっと欲しかった。すごいお客様も求めている」ということを伝えたところ、とても驚かれました。
その方としては、この機能は「そんなに使われるのかな？」と感じるものだったとのことでした。
しかし、求められていることがわかったことでかなりモチベーションが上がった明るい声で言っていました。
（もちろんモチベーションでパフォーマンスが左右される方ではないです）
エンジニアとして、「なぜ」、「どんな人が」、「どんな熱量で」この機能を求めているかを知っているかは
モチベーションや使命感に直結すると感じていますが、「どんな熱量で」が非常に伝わりにくいと感じています。
今後の展望としてエンジニアがより上流工程に関わっていくことなどで、より熱量に近づいていくようなフローを
作っていけると少しずつ温度差が埋まっていくのではないかと考えています。
BizとDev、それでも変わらなかった大切なこと
ここまでBiz・Dev間で感じた壁について書いてきましたが、最後に変わらないものについて書こうと思います。
変わらないものそれは「結局のところ人のやること」である。ということです。
システムは「人」が作っており、Bizサイドで考えても報連相でのミスや書類不備などが起こるように、
開発サイドでもバグ混入や考慮漏れなどは（ある意味）当たり前に起こることであると考えるようになりました。
だからこそ、開発フローを整備し、レビューや静的解析ツールなどの「自分以外の人」「人以外のツール」を活用し
精度を上げていく努力・仕組みが必要であるということも同時に理解しました。
また、その理解は「エンジニア組織論への招待」 広木大地 著 技術評論社 という本を読みより強く思うようになりました。
かなり大雑把にですが、エンジニアリングとは、コーディングや技術を指すのではなく、不確実性と向き合い、目標を実現していくための考え方であると
この本では具体的な考え方を紹介してくれています。（かなり有名だと思いますがBiz・Dev両方で面白い内容なのでまだ未読の方がいればぜひ！）
ここまでに私が感じてきた壁も、情報の不確実性やコミュニケーションのリファクタリングという形で 具体化されることで現実的に対処が考えやすいものになったと思っています。
まとめ
今回は異動して初めてということもあり、今だからこそ感じる違いについて書かせていただきました。
かなり私見によるものですので、伝わりにくい内容もあったかと思いますが、ここまでお読みいただきありがとうございます！
超ざっくりまとめとしては、「結局は人とコミュニケーションが大事」という一般論的な結論ですが、
それがBiz・Devでも変わらないというのが私にとっては新鮮な発見でした。
今後はより技術的な知見も広め、発信していけるようにしていければと思いますが、
今回感じた壁がどのように変化していったかも機会があれば共有できればと考えています。
We are hiring！！
ROBOT PAYMENTでは一緒に働く仲間を募集しています!!!
