見出し画像

エンジニアもビジネスから逃れられない!

ことのあらすじ

noteを書き始めて最近過去に起きた事件物しか書けてないのに悲しんでいるのは置いておきつつ....(笑)

自分が以前法人を立ち上げる前に携わっていた接待サービスにまつわるお話で、「ビジネス(経営)サイドとエンジニアサイドで起きた意識の乖離」、そこから得た「ビジネスを意識したエンジニアの動き」についてお伝えします。

2019年初頭、自分がまだフリーランスエンジニアとして活動していた時期に、今でも懇意にしている得意先の企業担当者様から、既存の接待サービスを引き継ぐことになりました。

接待サービスについてざっくり説明しますと(守秘義務もありますのでざっくり)、

本サービスへ接待をしたい幹事様に会員登録していただき、提携飲食店舗で飲み会を伴う接待を行うと、ポイントを高還元する

という仕組みです。

高還元されたポイントは幹事様の収入源(電子マネーやマイルなど)にもなりつつ、飲食店様に固定のお客様をつけることができるようなサービスでした。

そのシステムはwordpressで構築されていたシステムでしたが、

・独自のカスタマイズが施されてシステム仕様がわからない

・前任者が情報を残さない(挙句の果てにはどっかに飛んでった

・バージョン管理されていないことにより修正履歴がわからない

などの問題が重なり拡張が困難を極めたため、今のビジネスモデルを維持しつつ接待サービスを拡張できるように作り直そうという話になりました。

当時は今も一緒に活動しているエンジニア仲間と一緒に要件整理をしつつ、得意先の代表取締役とビジネス要件を詰めながら、2020年4月にローンチできるように動いていました。

当時の自分はエンジニア的な考え方で経営側へ意識を向けるような意識は高くはありませんでしたが、この体験を元にビジネスに関する感度が高まることとなりました。

どんな問題が起きたか?

得意先の代表取締役様と一緒に要件を詰めていく際にビジネスサイドとしては、

・接待サービスを仲介する代理店様にコミッションを払う仕組みを自動化したい

・接待した飲食店から紹介料を自動で振り込む仕組み

・接待サービスを利用したユーザへポイント高還元

などなど、要望が沢山出てきました。(割とあるある

ただ我々は自分含めてエンジニア2名で、しかもその当時は、契約形態自体がレベニューシェア という完全成果報酬型であったため、全要件を満たした開発を受けてしまうと、明らかにリソース(人件費や時間)が破綻してしまうことなり、確実に2020年4月には間に合わない流れでした。

そのため、得意先の代表取締役様には、

・現実的に開発できる機能を絞っていきましょう

新規機能を作っていきますが、実現が難しい場合は相談させてください

と前もって伝えて着手しておりました。

開発時の選定技術としては、当時、比較的得意であったJava(spring framework)でAPIサーバを構築(インフラはAWS)し、フロントはReactを採用しており、店舗や代理店への通知にLINE Messaging API を使用。

要件も簡易的になったので、実装も楽だろうと予測していましたが、SPA構成でよく問題に上がるCORS周りの設定が中々解消できなかったり、Reactを使うのが今回初めてだったので、構成のキャッチアップに手間取ったりしていました。

その結果、中々、成果物が仕上がらない状態が続きました。

技術的な問題が発生している中でも、ビジネスサイドでは開発が進んでいると認識されてしまっており、当時どう報告すれば良いか悩みまくっていた記憶があります。

エンジニア的な目線で今技術的に起きている課題を伝えたとしても、ビジネスサイドからすると、

・ローンチまでに起きるリスク

・接待サイトをオープンする際の準備(店舗との連携、ポイント導入の仕組みを説明

・代理店への報酬形態説明

・公開用のLPを用意するために業者発注する

などをしたいという気持ちがあるはずですが、そういったビジネスサイドの意識まで考えを巡らして、作業調整ができずに苦戦しておりました。

2020年3月に差し掛かった頃、世間はコロナ騒ぎが起き始めてる最中、ついに痺れを切らした得意先の代表様にこういったことを言われました。

技術的な課題があって遅れているのは分かったけど、他にできる手段は模索したのかな?

ビジネスサイドでも運用で回避したり、お客様への説明で複雑な手続きを簡易化することもできるよ!

と言われ、ハッとしました。

私の中では開発物をローンチさせることにしか目がいってませんでしたが、ビジネスサイドでの立ち回りを想定することで、無駄な作業やコミュニケーションロスを回避できることを確信しました。

そして、2020年4月を迎え、機能縮小しつつも整理したものをなんとかリリースすることができました。元々Java + Reactで開発していましたが、スピード感と現実性を優先し、途中からLaravelへ切り替えました。

しかし、2020年4月といえば、緊急事態宣言の1回目(2020/4/7~5/25)がちょうど始まる時期で、接待サービスに協力してくれる店舗も軒並み営業時間短縮や閉店する店舗もあり、このシステムのコアとなる協力体制が軒並み破綻しました。。。orz

レベニューシェアということもあり、お互い損して終わってしまいましたが、ビジネスサイドの知見をキャッチすることの重要性を認識できる良い機会でもありました。(あと弊社的には新しい技術の知見が溜まったりした

エンジニアとしてのビジネスマインド ~ビジネス全体の価値提供を考える必要性~

大企業やチーム数が膨大にある組織では、そこまでビジネスサイドのことを意識することはありませんが(もちろん意識が0ということもありませんが)、特にスタートアップや中小企業の1部署レベルで新規事業をやるとなった場合に、ビジネスサイドのことを考慮したエンジニアリングができる人材はより市場における必要性が高まると思いました。

特に予算がなく、人材確保に困難な状況だと、より無駄な開発工数を減らして、本来提供したいサービス価値を追求することにリソースを割きたいというのがビジネス全体の責任者の本音だと考えています。

フリーランスでいろいろな開発案件を回ってきている中でも、

・予算を膨大に突っ込んで最終的には使われないものが作られてしまった

・PoCで確度の高いビジネスを実現しよう意気込みシステム開発したが、組織構造上無理だったことが後からわかって、せっかく作ったシステムがお蔵入り

・組織文化やビジネスサイドの考え方酷すぎて、エンジニアが逃亡

など諸問題で価値追求ができない状況が起きるので、我々としてもそいういった課題を未然に防げるような立ち回り方をしていきたいと思いました。

最後に思ったこと

またもや過去のお恥ずかしい体験をお伝えしてきたのですが、ひと昔に比べて、

エンジニアがプロダクトの価値追求やビジネスサイドの意向をどれだけ把握できるか?

ということが問われているような気がしてます。

単純に開発ができるだけでは、生き残ることは難しく、ビジネスレイヤーや各レイヤーにいる人の行動把握やその先にある社会課題にもっと目を向けていく必要性があると再認識できました。

特に今の時代は技術も非常に扱いやすくなっており、企業の事業構造やビジネスモデルなどに目を向けやすい時代になったと思います。

我々も開発会社というスタンスを取ってはいますが、開発だけを引き受けるのではなく、「共に」そのビジネスが提供できる価値の本質的な部分を追求できるような企業を目指していきます。

最後まで読んで頂きありがとうございます。

この記事が気に入ったらサポートをしてみませんか?