この記事はうるる Advent Calendar 2019の1日目の記事です。

はじめに

この記事は、自社プロダクトを持つエンジニア組織の会社組織においての関わり方を、1社の中での組織編成の変遷中から経験則に基づいて振り返った記事となります。
当然、自組織における振り返りにしかおさまらないものであり、一般的普遍的考察とはなりえないものであることを前提としてご理解ください。

また、もう1つ記事を理解する上での前提として下記の情報を添えておきます。

• 株式会社うるるでは、複数のWebプロダクトを運営
• プロダクト毎にそれぞれの事業が存在
• プロダクトは基本的に内製の体制（外注や外部パートナーとの協業もあり）

変遷の歴史

入社以前の組織編成は把握していませんが、入社から7年間、株式会社うるるでは以下のように会社組織に対するエンジニアの関わり方を変えてきました。
※ここでは、機械的にフェーズ番号を振っていますが、番号にはなんら事業的な意味合いや組織成熟度の意味合いは含んでいません

• フェーズ1：~2015/09：事業部型組織の一つの機能として、エンジニアリング機能を持つ
• フェーズ2：2015/10~2018/6：マトリクス型組織の横串機能としてエンジニアリング機能を持つ職能型
• フェーズ3：2018/7~2019/12現在：マトリクス型組織の中で、事業部組織の一つの機能としてエンジニアリング機能を持つ形に再編成

各フェーズにおける状況と課題

フェーズ1：事業部型組織の一つの機能としてのエンジニアリング機能

私が入社した2012/10から2015/09における間、社内では各サービス毎に事業部化された組織体制となっていました。
その中で開発チームがエンジニアリングを担う組織として存在し、各事業におけるプロダクト開発を行っていました。
このときに以下のような組織的課題があり、フェーズ2の職能型の組織へと移り変わっています。

• 広く浅く対応できるメンバーが揃っており全体最適されたアーキテクチャを作り上げているが、部分最適を進めプロダクト毎に最適なアーキテクチャを作るためのノウハウを持つことに課題あり
• 分業制を敷き、フロントエンド/バックエンド/インフラなどの各役割が 流動的 にプロダクトに関わることができるようにする体制を作る
• エンジニアの仕事を エンジニアから評価 されるような形を作る

こういった背景があり、事業部型組織の一つの機能から、横串組織としての職能型組織へと組織編成を変えました。

フェーズ2：マトリクス型組織の横串機能としてエンジニアリング機能を持つ職能型

フェーズ1での課題をベースに、2015/10からは職能型の組織として、開発部という組織ができあがりました。
この開発部の中にフロントエンドエンジニア/バックエンドエンジニア/インフラエンジニア/モバイルアプリエンジニア/デザイナーなどの様々な職種が所属し、
また、各プロダクト毎にチームを組みメンバーがアサインされる形を取っていました。
このフェーズの途中段階から私自身が部長代理という形ながらも実質的な開発部門の責任者を担うことになったのですが、私自身の失敗も含めて、状況と課題を列挙すると以下のようになります。

• 部分最適なアーキテクチャを作りあげようとするも事業部要望とのバランスが上手にとれず、アーキテクチャ刷新の動きの鈍化
• 流動化を想定したが、まったくと言っていいほど流動性のない ほぼ固定的な メンバーアサイン
• 分業化を進めたが、完全なる分業体制になってしまい各役割における ボトルネック解消の困難さ が露呈
• エンジニアから評価される形を取ろうとするも、責任者についた私（評価初心者）の属人的かつ納得性の低い評価

上記のように、元々フェーズ1の課題に対して対処していくために組織編成を変えたものの、元々の課題に対してアプローチできていなかった状態かつ、新たな課題も生まれてきたのがこのフェーズ2の状況でした。
評価についての話は、各メンバーと評価者であるマネージャーとしての私のコミュニケーション不足が一番原因として大きく、普段業務に入ることが少ないものの評価を行わなければいけない状態に陥っていたことを解消できなかったことに原因があります。全体的に、この組織をまとめるべきマネージャーとしての私の力量不足でした。

組織を運営するために重要な3要素と言われているものは下記の3つですが、それぞれの要素で不足があるといった組織のアンチパターンを踏んでいた時期でした。

• 共通の目標
• 協働の意欲
• コミュニケーション

この状況を見直したとき、大きく課題となったマネージャーの力量不足をカバーするため一度事業部型の組織に所属を戻し、事業部のマネージャーにマネジメント業務を任せていく決定を取りフェーズ3へと移ることになりました。

フェーズ3：マトリクス型組織の中で、事業部組織の一つの機能としてエンジニアリング機能を持つ形に再編成

上述の通り、元々の課題に対応できなかった上に組織のマネジメント力を大きな課題とし、横串組織を解体することとなりました。
2017/7より現在に至るまで事業部型組織の中の1つの機能としてエンジニアリング組織が存在している形を取っています。
私の個人的な感覚では今の形がよく機能していると感じているため、その感覚を言語化することも含めて現在の状況と課題を記載すると以下のようになります。

• 組織の重要3要素を高めるための動きが柔軟にできる
• 部分最適なアーキテクチャを実現するための動きを、事業の動きと合わせ易い（調整のコストが低い）
• 分業の深さを判断するのが事業部内で完結するため、ボトルネック解消に向けた動きがし易い
• 採用や育成、社内規定整備、技術戦略については横串組織がないと整備が進まない

この中で一番大きいと思っているのが「組織の重要3要素を高めるための動きが柔軟にできる」ことなので、これをもう少し、現在のチームと過去にできていなかった原因に焦点を合わせ、説明を行います。

組織の3要素

現在、私は入札情報を扱うサービス、NJSS（入札情報速報サービス）のチームにおいて開発課の責任者をしています。
このチームにおいて、組織の3要素と言われる 共通の目標/コミュニケーション/協働の意欲 に対して行ってきたことを過去との対比で説明します。

共通の目標

共通の目的/目標をもっていることが組織には必要だと言われています。
所属するチームメンバーが同じ目的を持っていないと、人は集まっていてもただの集団にしかなり得ません。
この点について、私のチームでは
会社の中期経営計画 → 会社の今期方針 → 事業部の今期方針 → 開発課のミッション → ミッションを達成するための開発課の方針
と上位目標からブレイクダウンをさせたチーム方針を定めるようにしています。
私以外にもうひとり開発課所属のマネージャーがいるのですが、彼と共に

• キャッチーで口にしやすいこと
• メンバー全員が行う業務に落とし込みやすいこと

の2点を大事にしながら方針を定めました。
More Value, Keep Value という言葉を使い 「自分たちが発揮すべき価値をより素早く提供していくこと、将来の価値低下を防ぐこと」 を実現していく方針を定めました。

過去にこういった共通の目標が作れなかった原因に言及すると、下記が挙げられます。

• 携わるプロダクトが違うことで共通の方針を定めにくい
• 無理に定めてもそれぞれ状況が違うことで形骸化しやすい

この点について、ある意味自分たちだけに閉じた状態であれば、目標と実態に乖離が出ない目標が定め易いと考えています。

コミュニケーション

コミュニケーションは、情報の共有によってチームメンバーが円滑なコミュニケーションが取れることを意味しています。
この点については、以下のような場を設けてコミュニケーションにおける大事な点である 前提となる事実の認識合わせ/事実に基づいた認識のすり合わせ を抑えられるようにしています。

• 毎日実施のデイリーミーティング（作業の進捗と障壁について話す）
• 毎月実施のプロジェクト共有ミーティング（プロジェクトが複数にわかれており、進捗と課題について話す）
• 毎クオーター実施の振り返りミーティング（チームの状態と課題について話す）

過去には類似した場を設けることはあったものの、特に最後のクオーター毎の振り返りは実施できていませんでした。
ダブルループ学習という言葉がありますが、普段の仕事だけだと流ししまって気づけ無いようなことを、立ち止まって考えてみることがとても有意義です。
「そんなことをしても意味ない」と過去に言われたことがあって踏みとどまってしまっていたのですが、絶対にやっていたほうが良かったと、あらためて実感しています。

協働の意欲

お互いに協力し合う意欲が大事だと言われます。
目標達成ためには一人では困難なことが多いのでチームを組んでいるため、チームメンバーが協力し合うことはとても大事だと言われればきわめて当然に同意できる話です。
この点について現在のチームでは、組織の成功循環モデルに基づき、いくつかの施策を実施している途中です。

• ありがとうを伝え合う施策。日頃の感謝をGive & Takeします
• 所属メンバーのあれこれを可視化する施策。スキルマップから始まり、各自の価値観やストレングス、性格に至るまで可視化します
• ノウハウを可視化します。参画して間もないメンバーが多く、過去の経緯や個々人のノウハウがバラついているのを解消するためにドキュメンテーションを主に進めます

また、この記事内で分業化について触れてきましたが、共通の目標を達成するためには自らの職能に閉じているよりはすぐ隣にいる困ったメンバーがいたら助け合うチームでありたいという行動指針も定めています。
これによって、セクショナリズムを無くしてボトルネックを解消していくための会話が生まれるようになっています。
行動指針の話は、弊社の公式ブログの中で経緯から説明がされているのでそちらを御覧ください。

過去にこういった動きをできなかった原因は、考えを突き詰めてみても「こういうことをやったほうがいい」という経験や実感が一切なかったと言えます。
過去には会話に上がってこなかったくらいの感覚ですらあるので、現在所属するチームでこの辺りのチーム施策を展開しているもうひとりのマネージャーには、新しい気づきと経験を与えてくれて大変感謝しています。
※ここで出てくるもうひとりのマネージャーは、12/10の回に投稿予定なので乞うご期待

まとめ

これまで事業部型組織とマトリクス型組織を経験してきたが、現段階では組織の3要素を抑えていくためにはいま現在、個人的な感覚では事業部型のほうが進めやすい感覚を持っています。
一方、横串としての機能がないと整備が進まないと思っていることも事実です。
社内では各自どちらの形が良いのか、それぞれ意見を持っている状態なので、より良い組織の形を目指して議論を深めていくことを目指しています。

あとがき

Advent Calendar 1日目にして、ギリギリ滑り込みセーフ。。。
また、自身に対しては祝・Qiitaへの初投稿！
今回、これまで組織の形に関して思っていたことを明文化したことがなかったため、今後の社内での議論を深めるための材料としてアウトプットをした内容が有効に活用できると良いと期待しています。

それでは、明日2日目は Fumiaki Kurihara さんによる記事を乞うご期待！
https://adventar.org/calendars/4548