プロダクト開発を進めるにあたって良い組織の文化とはなにか

タイトルのとおりですが、「プロダクト開発を進めるにあたって良い組織の文化とはなにか」に関して雑に意見を伺ってみたいと思っての質問させていただきました。（※自社でプロダクトを内製化している、所謂Web系企業を想定しています。）

前提として、私は「組織」において一般的に通じる「良い施策」は存在せず、採択した施策が良いものになるか悪いものになるのかは様々な変数によって規定されると考えております。

例えば「弊社はエンジニアにも週3出社を要求します」みたいな話があったとして、事業フェーズが浅い場合、破壊的な仕様変更も頻発しうるため、情報共有を密に行いやすい出社はプロダクト開発においてポジティブに働く場合があると思います。
翻って、プロダクトの仕様がある程度固まっているフェーズになり破壊的な仕様変更がほぼ発生しなくなるのであれば、「エンジニアが集中して働ける時間」を最大化したほうが全体効率は上がると思っております。また、事業フェーズが浅くともメンバーのスキルセットの構成次第ではリモートで十二分にパフォーマンスがでるとも思います。

また、組織文化・カルチャーと呼ばれるものはなかなか言語化しづらいですが存在しており、わかりやすいのだと「営業主導な組織でプロダクト開発がやりづらい」とかはイメージしやすい話かと思います。（上述の通り、組織は様々な変数によって規定されるので「営業主導 = プロダクト開発がしづらい」という話ではないです）

前段が長くなりましたが、組織文化と銘打ってはいるものの上記の前提の上で「なんかよかった話」とか「なんか微妙だった話」とかを伺ってみたいです。
・PRレビューでめちゃくちゃgifを貼る人がいた
・評価形態がマネジメント職にならないと給与があがらない設計だった

など、どんな粒度でもよいので雑にご意見いただけると嬉しいです。
2年前
view数 936
  • 1
  • 1
  • 6
  • 2
  • 3
  • 2

回答を投稿して企業にアピールしましょう！

Q&Aで投稿された回答は、
企業側に表示されるプロフィールにも投稿履歴として表示されます。

Offersにログイン・新規登録して、気になるテーマやトピックを話してみよう！

簡単1分登録(無料) ログインする

＼回答があります！／

  • makoto tanaka

    プロジェクトマネジメント

    2年前

    良いプロダクト組織文化とは
    ・職種問わず、ソフトウェア経営・開発理解が全社に浸透
    ・コーポレートやプロダクトのミッション・ビジョンの実現に向け、皆がいきいきと働いている

    だと、考えています。
    その上で、一部ですが、下記のような取り組みを弊社では行なっています!
    ----
    # 全社での取り組み

    1.プロダクトの組織・文化作りのための勉強会
    https://note.com/offers_pm/n/n76d902f0101c

    2.開発、デザイン領域の技術戦略、組織戦略の社内公開と説明会の実施
    一部ですがzennで公開しています
    https://zenn.dev/offers/articles/20221102-development-organization-fy2022

    3.ロードマップの全社共有、運用方針、ルールの言語化
    - 開発組織（PM、デザイナー、エンジニア）が正社員15名を超えたタイミングで実施
    - 理由：プロダクトマネジメントのガバナンス強化のため
    - プロダクトが事業成長に貢献しているのか、事業計画/人員計画などとの整合性確認     （編集済み）
    view数 11
    • 1
    • 1
    • 1

  • 山本隼汰

    エンジニア

    2年前

    文化をざっくりと議論のテーマにしてしまうとどうも抽象度が高く、なかなか良い議論ができなかったなと個人的な経験では強く感じています。ゆえに、特に小さなチームにおいては「カルチャーは結果論」とある程度割り切ってしまうことも大事なのではないか？とさえ思ったりしています。いいプロダクトは、プロダクトに関わる人の貢献によって生み出されますし、関わる人たちと話し合いながらプロダクトをもっと効率的に、品質高く開発していく過程で勝手にカルチャーが形成されるのかなと。

    というのも、どのようなカルチャーが適切かから議論を始めるよりも、その組織の中にいる方々が自然に動いていて、「そうやってくれると嬉しい」「こういう動き良いよね」みたいなボトムアップに共通の動き方や価値観を定義していく方がずっと、カルチャーや良いプロダクトを作っていくのに寄与したな、と私は感じております。

    例えば、弊社でいうと開発時に「あ、もうこれテキストで書かない方が良いな」と感じる抽象度の高い議論がある場合は、各人自分で修正を入れてPRをお互いに投げ合い、レビュワーがレビュイーに変化するような開発スタイルを採用しています。これは、チームでとてもよく機能しておりかつお互いの学びが促進されている実感があります。レビューする側、される側を超えて、お互いに一緒にコトに向かえている感がそう思わせるのですが、別にこれは「こういうふうにしよう！」といちいち決めたわけではなく、そこにいるメンバーが自然にそう動いてくれていて、そのいい動きを周りに啓蒙したら、結果としてカルチャーのようなものになりました。     （編集済み）
    view数 13

    • kentaro haneda（jumbo）

      エンジニア

      2年前

      色々あるんですが、そのうちの一つに関係者間で「リスクがちゃんと話せている」ことが思いつきます。

      ・その施策は本当にユーザーさんに不利益がないか
      　ある場合、それはどういった課題か
      ・プロジェクトが遅延する可能性はあるか
      　ある場合、どのような対策・遅れても問題ないようなアクションが取れるか
      ・課金に影響はあるか
      　ある場合、どのように早期検知・品質を担保するか

      など。様々な関係者がいる中で、ちゃんとリスクヘッジできているのか
      リスクが不要に一箇所に固まってないかなど、ちゃんと皆の目線が揃って安定してデリバリができるような計画やロードマップを作り、変更しやすい状態になっていることが大事だと思いました（遠い目       （編集済み）
      view数 20
      • 1