Gaiax Engineers' Blog

Gaiaxのエンジニアブログです。 社内のエンジニア様子、イベントレポート等を発信していきます。

事業部制の組織形態と今思う大事にしたいこと

ガイアックスの技術責任者のhidehigoです。
Gaiax アドベントカレンダー Gaiax Advent Calendar 2016 - Qiita の8日目です。
昨年も1人1エントリで完走することができましたが、今年は、もう少しラインナップを広げて完走を目指します。お楽しみに!

今日は、少し組織寄りの話、思想寄りの話をします。
Gaiaxでは、全社の組織を、2015年から事業部制組織という形に切り替え運営しています。
昨年のエントリから少し引用します。

Gaiaxというのは、なかなかにボトムアップな風土の会社でして、事業の裁量を広げさらに加速すべく、この形態に移行しました。 私の考えですが、機能組織がいいか事業組織がいいか、は時によって最適が変わるものだと思っています。エンジニア/エンジニアリングは「機能」を担う面が強いため「機能か、事業か」という問題はエンジニアにとって実は大きな影響があります。 事業組織への移行の判断時、それから約1年経った現在、今のGaiaxには事業組織がベターと考えています。

Gaiaxのエンジニア組織について - Gaiax Engineers' Blog

今年1年では、事業が、子会社化してさらに自立度高く運営する、という選択をできる制度を作り、事業部制をさらに推し進めています。

上に引用した昨年のエントリでは触れませんでしたが、’エンジニアにとって実は大きな影響’というのは、一部のエンジニアにとって所属の部署が変わる、ということに留まりません。
事業部制において、事業所属のエンジニアは、事業の実現したいミッションにコミットし実現に全力を注ぐことになります。必然、エンジニアリングとしては、事業のサービスやアプリケーションの機能、ユーザーインターフェース、あるいはその実現スピードに重点を置くことになります。(もちろん何かをやらない、という話ではありません)。
一方で、技術開発部所属のエンジニアは、一段後方から事業を、また事業の開発チームを支える、たとえば共通のサービスを提供したり、開発プロセスや手法の強化のための支援、全社のセキュリティのルール整備などのように、支援の要素が増えます。
一つの会社に所属するエンジニアに、貢献方法に大きく2つのパターンができるということになりますし、マインドも必要なスキルセットも少し違うという状態になります。

ここのところ、そんな事業部制組織を運営する上で大事だと思うことを少し表現できるようになってきました。

キャリアパスと評価の仕組みをどうデザインするか
分散しがちなノウハウを集中するために、技術選択を集約するか
薄れていく全社の横のつながりをどう作るか
などいくつも大事な論点はありますし、制度や運用として整えられていくべきです。

一方で、メンバーひとりひとりがそうあってほしい、と願うところもあって、
それは、技術でもなく、心もちでありメンタリティについてなのですが、

自分と違うOOをリスペクトする

この点が重要だと考えています。

たとえば自分と違う職種
たとえば自分と違うキャリアの志向
たとえば自分と違うスキル
たとえば自分と違う価値観

さらにいうと、AかBかという二元論になる要素である場合に、自分でない他方をリスペクトするというのが絶対的に重要。

上記した、貢献の2つのパターンは二元論になりがちな要素です。
しかし、エンジニア人生通じてどちらかの貢献方法を決めなければいけないわけではないですし、 その時その時の興味や、伸ばしたい領域、取り組みたいことなどで変わるものですし。
たとえば、チームの誰かが、別のキャリア、ステップを希望するようになった。それは全力でリスペクトし、応援したい。

こうして書いたら、ほとんどの人は反論も感じないと思います。
でも、これと同じ構造の話がそこここにあるんじゃないかな。
それが、事業部制のデメリットとして表出し、感じられている一因じゃないかな、と考えています。

極端なケースでは「みんなと違う、わたし(たち)」という形でアイデンティティを保とうとしてしまうことさえ。
得てしてこれは、ネガティブなスパイラルを助長します。

最後に、

自分とは異なる考え方を受け入れられないのも、暴力のひとつの形です。それでは真の民主的精神は、一向に育たない。

これは、マハトマ・ガンジーの言葉ですが、ダイバーシティについての考え方として多く引用されています。
他者との違いを尊重し、応援しあえる。それが一体感やシナジーと呼ばれる行為・思いやりにつながる、そんな組織を目指したいと思います。