ステークホルダーの特定と直接コミュニケーション
弊社は多くの組織同様に、少数の上位層に判断権があるピラミッド型の組織です。
この場合、ピラミッドの頂点に近ければ近いほど多くの情報が集まりますが、一方でその詳細はピラミッドの下層に近いところにあります。その情報の中心にいる人物（詳しく状況を把握している人物）を探し当てることが大事です。
探し当てたあとは、1on1などの直接のコミュニケーションを始めた方が良いです。その会話の中で課題が見えてきたら、さらに適切な組織改編や会議体などを整理します。
ベルフェイスの場合、私の入社前までは、エンジニアリング部門は以下の通り分断されていました。
- 開発と運用部門はそれぞれ別組織として独立しており、その組織間のレポートラインは社長の中島だった
- 品質管理部門はプロダクトに所属
- セキュリティ部門はコーポレートに所属
私は入社前から技術顧問としてこの分断の課題を認識していました。そこで、入社直後の組織デザインとして開発・運用部門を一つの組織に所属させることにして、「システムグループ」という部門を誕生させました。その上でグループ内の出来事を定期的に吸い上げるための会議体を週次で実施することにしました。
さらに、当時の社内会議においてはアジェンダと議事録文化が根付いていなかったため、ドキュメントツールの整備にも着手しました。円滑で適切な情報共有のためには、共有範囲をコントロールできるように情報設計し、伝えるべき内容を構造化するためにテンプレートを駆使するなど、似たフォーマットでレポーティングされるように整理します。
レポーティングが定着し、会議でやりとりすることで、各マネージャーが自分のチームをどこまで把握できているかが可視化されました。ここで次のステップに進みます。
次はグループ内の出来事を適切に把握できるように、マネージャー一人あたりのメンバー数を表すスパン・オブ・コントロールの適正化を行いました。スパン・オブ・コントロールは5～7人とされている中、弊社では多い所で10人以上のケースがあったので、採用や内部昇格などによってマネージャーを充当していくことにしました。このような形で自分が見える組織の範囲を広げていきます。
執筆している現在（2021年4月）で、前述の分断されていた組織は全てシステムグループに統合しきっており、広義のエンジニアリング部門のほとんどの情報が集約されるようになっています。
スタートアップの成長痛を乗り越える、情報の整備
スタートアップの成長痛の代表的な事例は、成長スピードに伴う業務量の増加を人員拡大によって補うことによる弊害がほとんどだと思います。
その弊害の一つが、円滑な情報展開が行いにくくなり、知見が属人化してしまうことだと思います。そうならないために、ドキュメントを適切な公開範囲で充実させていくことが大事です。
弊社はあまり社内ドキュメントが豊富とは言えない状態だったので、ドキュメントを記述する文化を根付かせるために、テンプレートを用意したり、Product Requirements Document（PRD）やDesign Docなどの記述を推進することで、Why/What/Howを明文化し、誤解の余地を排除しようとしています。
またSlackを相当駆使しているのですが、ここでもチャンネル名などが不統一なため、情報を検索、共有する場所を探すのにも一苦労という、非効率な状態が放置されていました。これが全社員に発生しているとなると、恐ろしいほどの時間のロスにつながっていることになります。
まだ完全に浸透しきってはいませんが、現在組織デザインの整備とともにSlackのチャンネル命名ルールやグループメンション、G Suiteのグループエイリアスなど、組織名が決まると自動的に命名できるような基盤を整理しているところです。
特にSlackのチャンネル名に関しては名称でソートされることを念頭に置いたルール設計が良いです。具体的には、
- 接頭辞でチャンネルの用途が一目瞭然となるようにする
- 組織ツリーをチャンネル名に反映させる
などが良いアプローチです。
弊社の組織デザインではDivision/Teamといった単位をよく使っていますが、例えば「AAA DivisionのBBB Team」の場合はチャンネル名をdv-aaa-tm-bbb（小文字は略称）のようにしています。こうすることによって同じDivision内のチャンネル群がソートされ、チームもアルファベット順にソートされるようになります。
現在は私の管掌部門にのみ適用していますが、今後全社に適用していこうと思っています。
