![見出し画像](https://assets.st-note.com/production/uploads/images/93413815/rectangle_large_type_2_0d803096cc08838f9a7cdddc1a860d64.png?width=1200)
「開発サイド」も「ビジネスサイド」もない、ノーサイドなPharmaXの組織
※本記事は、PharmaX Advent Calendar 2022の 22日目の記事です。
はじめに
こんにちは。初めましての方は初めまして。PharmaXの倉内です。
PharmaXでは執行役員・事業部長を務めさせていただいているものです。
アドベントカレンダーは主にエンジニアの方を中心にした文化だと思うのですが、弊社ではエンジニア職以外の方も巻き込んでしまえということで、エンジニアではない自分も22日目の記事を書かせていただくことになりました。
いくつかテーマ候補を出した中で採択いただいた本テーマについて、正直中身のイメージは半分もついていないですが筆を執ってみようと思います。
「開発サイド」「ビジネスサイド」に分かれない弊社の組織
冒頭ではエンジニアかどうかのカテゴリーを意識したような書き方をしましたし、確か職能で分けたチームとしてのエンジニアチームは存在します。
一方で、「開発サイド」「ビジネスサイド」という表現は社内では使われないですし、使われた場合にはおそらく開発責任者の上野さん (@ueeeeniki) から強烈なフィードバックが返ってくることになります。
これは善悪や正解不正解の話ではなく、あくまで弊社のカルチャーの話ですが、エンジニアもビジネス観点・感覚 (例: 作っているプロダクトがどうマネタイズされるのか) を持たねばらならないし、非エンジニアもエンジニアリング観点・感覚 (例: ユーザーに届けたい新機能を実装するのに必要な工数はどの程度か) を持たねばならない、という考えが根底にあります。
おそらく「開発サイド」「ビジネスサイド」という表現を使われている会社さんでも、相互理解の重要性を否定することはないでしょう。違いを際立たせるために、雑で大げさな図を以下に示しています。
![](https://assets.st-note.com/img/1671152438043-4a31ST3r4K.png?width=1200)
「「開発サイド」と「ビジネスサイド」な組織」では、スキルや視点の共有度が低いため (図では大げさに全くないように書いていますが)、お互いのスキルや視点を必要とする論点が発生するたびに、議論のベースとなる知識や視点の共有が必要です。
一方弊社では、エンジニアリングについてもビジネスについてもベースを共有しているため、より互いに専門性の高い領域でのディスカッションに速やかに入ることができ、合意形成・意思決定のスピードも早くなります。
※実際にはこの理想にたどり着くための道のりの途中です
この組織が機能していると感じた出来事2選
①開発リードタイムについてのお互いにストレスを抱えるような議論がなくなった
テック企業あるあるとして、エンジニアが提示する開発リードタイムについて「そんなにバッファー必要?」「ここはこうこうこんな風にショートカットできないのか」「技術的負債とかどうでもいいから一旦早く作ってよ」といったコメントが非エンジニアからなされ、エンジニア側も「いや、ここを今妥協すると後々こういった問題が...」「バッファーはこうこうこういう理由で必要で...」と反応し、最終的には何とか分かり合えたとしても、お互いに時間を消費しストレスが溜まるようなコミュニケーションになってしまうということがあると思います。
弊社でも、自分が入社した2020年頃は、正直こういうコミュニケーションが頻発していたと記憶しています。自分自身も当時は今よりもエンジニアの感覚がよく分からず、悪気はないもののストレスを与えてしまっていたなと反省しています。
![](https://assets.st-note.com/img/1671152557795-8mAlkqwiVu.png?width=1200)
実は当時は「ビジネスサイド」「開発サイド」という言葉遣いを弊社でもしていたのですが (代表を悪者にしてしまいました。すいません笑)、組織について議論するとある会議で、冒頭でも名前を出した上野さんがこの言葉遣いを気に入らないと強く主張したのを覚えています。それが発端だったかは分かりませんが、言葉遣いもそうですし、ビジネスvs開発という意識が薄まっていったのは間違いありません。
特にここ1年くらいは、社内コミュニケーションが全て最高!とは言えないまでも、エンジニアvs非エンジニアの不毛な対立はほぼほぼないのかなと感じています。
開発リードタイムについて例を挙げましたが、逆にビジネス系のトピックについて分かり合えない・分かり合うのに労力がかかる、というケースも想像いただけると思います。
②エンジニアも非エンジニアも関係ないスクラム体制が自然発生し定着している
この件についてはすでに今回のアドベントカレンダーで弊社尾崎が記事にしているので、詳しくはそちらをご覧ください。
記事に事業部長である自分の存在が出てきていないのが、文化がチームに根付いている何よりの証拠だと思っています。
どうすればノーサイドな組織を作れるのか
ノーサイド組織は正直難しいです。私の汚い図で書いた通り、ノーサイド組織の前提として、ビジネス系職種の方もエンジニアリングについて一定理解を深める必要があり、逆も然りです。ただでさえ忙しい中、職能からして本来求められないと言っても良い領域についても理解するのは骨が折れます。
ただ、実際に一定レベルのノーサイド組織・ノーサイド人材に至った経験を踏まえると、まずは徹底的に相手の立場になって思考するということを繰り返すことで、自然と必要な知識が溜まっていき、視野も広がっていくと考えています。
弊社では4つの価値観と、各価値観に紐づく3つの行動指針を制定しているのですが、その中に「智を創発する」 (行動指針に「自分の専門領域だけでなく幅広いインプットをする」) および「仁を尽くす」(行動指針に「相手の立場になって考える」) というものも採用しており、人事評価の項目にもなっています。
![](https://assets.st-note.com/img/1671152768066-9dUivrBMis.png?width=1200)
因果関係を証明することはできませんが、この価値観と行動指針もノーサイドな組織を促進する一助になっていると考えています。
最後に
あるあるな課題について取り上げ、あるあるな解決策を提示してしまっただけのような気もしていますが、具体的なストーリーのところなどを楽しんでいただけたなら幸いです。
弊社組織や今回は話していませんが事業について興味を持っていただける方がいらっしゃいましたら、ぜひお気軽にご連絡ください。転職希望でなくても構いません笑 Twitter、YOUTRUST、LinkedIn等DM開放しております。
それでは!良いお年を!
PharmaXでは定期的にテックイベントをオンラインで開催しています!
2023年1月は、金融業界・花き業界・薬局業界という異なる業界でDX推進をリードするスタートアップ企業3社が集まり、それぞれのオペレーションを担っているドメインエキスパートとプロダクト開発チームがどのように連携しながらプロダクトや開発組織を作っているのかについてディスカッションします。
ぜひお気軽にご参加ください。
この記事が気に入ったらサポートをしてみませんか?