はじめに
bravesoftで自社事業の開発部にて部長をしております木戸と申します。
昨年の9月に、開発部の部長に就任させていただきましたが、そのタイミングで上長が退職し、マトリックス組織が始まることとなり（元々はピラミッド組織）、今年の1月からはそこのユニットの管理にも携わらせていただくようになりました。正直に自分の能力含め、多くの至らないポイントもあり、新しい組織体制の中で正解も見えず、仕事の大変さというレイヤーが一個大きく変わって、メンタル面で成長を問われる年ではありましたが、無事？に乗り越えて今があるということで、主に苦労したユニットでの少し振り返りをさせていただきます。
マトリックス組織とは
そもそも自分もあまり知らなかったので触れさせていただきます。マトリクス組織は機能別組織と事業部別組織など、2つの組織に属する組織構造のようです。弊社でいうと、縦と横にそれぞれ組織があり、縦が事業部別組織、横が機能別組織（ユニット）という形でスタートしました（図を添付しておきます）。添付しました図の開発部と開発ユニットが私の責任範囲となります。
開発人員は業務委託を除くと27名で元々は
A本部12名、B本部5名、C本部10名
でしたが、マトリックス組織後はユニットへの所属要員も増やし、
A本部7名、B本部5名、C本部9名、ユニット6名
となりました。
タレントユニット側に所属するメンバーについては、専属の仕事があるというよりは、忙しくなった事業を助けにいくことをミッションとしていました。
マトリックス組織で大きく取り組んだところは２点あります。
１つは目標管理、もう１つはコミュニケーションです。
それぞれについて背景から振り返りまでをさせていただきます。
1. 目標管理
マトリックス組織自体が初めての試みとなるので目標も改めて定める必要がありました。事業部の組織については、基本的にビジネスにコミットするので、目的となる指標は売り上げや利益となります。ただ私の部は開発部であり、かつスクラム開発を行なっておりましたので、スプリントレビューにおけるステークホルダー評価や、ストーリポイントにおけるベロシティでした。しかし、他の事業部は受託開発などを行なっており、事業の中に開発人員がいるということもあり、そこの評価も含めてどのように行なっていくかというのは大きな課題としてありました。
1-1. 目標値として取り入れたクリエイティブポイント
今期の目標管理の仕組みとしては、クリエイティブポイント（以下、CP）というポイント評価制度を全社として導入することとなりました。定義は下記となります。
受託案件CP
・案件の売上-外注費=大粗利をPJ参加メンバーで分配する
・分配はPMが決定する
VCP（Vision CP）
・bravesoftの未来を創るためのアクションを価値評価する
・自社プロダクトのCPもプロダクトオーナーが決定し分配する
・経営会議などで定めた特別なプロジェクトは、プロジェクトオーナーが分配する
貢献CP
・上記2点の対象外だが、bravesoftにとって必要なアクションであれば申請して承認する形で付与する
評価指標としてCPを選んだ背景は大きく２つあります。
・元々受託側の方で運用していた指標で回っていた評価制度であり、一定テストされていた制度である
・タレント所属のメンバーは受託・自社の両プロジェクトに入る可能性があり、横断の共通指標が必要
このCPによる評価は約1年程度運用してみました。
1-2. 運用してみての感じたメリット・デメリット
CP運用自体は全ての職種に対して適用されていたものだったので、他のユニットの方の感想も当然あるかとは思いますが、私が開発者評価に関して運用を回してみて感じたメリット、デメリットを記載します。
メリット
・全職種が共通指標で数値化されているので活躍がわかりいやすい
・事業として成果を出している部署が評価される
・事業に関わらない社内の横断タスク評価の可視化（社内イベントの運営、LPの修正などの細かい改善業務）
デメリット
・プロジェクトの成果（主に利益）に影響を受けやすい
・過去実績がないものについて、妥当性は計りづらい
・小さいプロジェクト単位でCPを割り振ると運用コストが高い
・ルーチンワークでコスパのいいものはCPパフォーマンスが高くなる
・稼働ベースになりやすく、技術レベルが反映しづらい（階級での考慮になりやすい）
・スクラム開発だとストーリーポイントをCPに変換していたが本来の使い方ではない
と私としてはデメリットの方を大きく感じました。
1-3. CP制度に関する所感
実際に支払われる金額を分配する形で評価をしているので、受託開発のようなところで誰のパフォーマンスがいくらの価値があったのかを可視化する分にはいい指標であるとは感じました。実際にいいエンジニアがそこに入らなければならないか、というスキルの割に勿体無いアサインには少なからずこれをきっかけにメスがはいったように思い、お金の流れを可視化することの効果は感じました。
一方で評価設計として階級の高いエンジニアほど、CPの目標値も高く設定することとなったのですが、必ずしも技量が高いことは実装が早いというわけでもなく、役割として重要な頼られ役が評価されなくなってしまうことにも大きく危機感を感じました。また、自社プロダクトのような稼働と売上が連動しないタスクとの相性は悪く、分配の基準は別途建てる必要があり、ベロシティ測定に使っていたストーリーポイントを変換する形で運用を開始しました。しかし、評価と直結するとなるとベロシティ以外の箇所（問い合わせなどのサポート対応や営業相談など）でも何かしらの評価基準を作る必要はあり、そのタスクの会社への貢献度や優先順位が自分の中でも整理しきれていないことを実感しました。
結論としては、CP制度の導入により評価されていなかったタスクなどが可視化され、評価基準が見直されていくことはいいと感じた一方、エンジニアなどの技能を持っている人のスキルレベルや貢献度を図るスケールは別途必要なんだと思います。
1-4. ユニットの評価基準はスキルで作る
社員の評価において、事業の成功の有無がその事業部に所属している人の評価に影響があることは全くもって問題だとは思っていません。しかしながら、事業部内の評価が事業の結果できまるのであれば、ユニットの役割は別としてもつべきであり、ユニットの評価は事業の影響を受けないことが適切であると考え始めました。そこで独自のスキルチェックシートを作成し、技術力の可視化を行う動きを始めております。今期はエンジニアのスキルチェックまでの実施となりましたが、エンジニアにはスペシャリストになりたい人とマネージャーやPDM、CTOになりたい人がおり、それぞれの描くキャリアによって求められるスキルや評価も異なってくるものだと感じています。そちらに向けたキャリアプランや必要スキルなどについて、来期から整理して社内評価制度に組み込んでいくべく、取り組みを行なっていきます。
2.コミュニケーション
弊社には自社プロダクトは6個、受託プロジェクトだと新規・保守含めて50個程度あります。私は元々自社プロダクトを担当していたため、受託側のエンジニアやプロジェクトとの関わりは相当に薄かったです。実際に受託側のエンジニアと交流を持ち始めると、プロジェクトを跨いだ交流というのもそもそも薄く、自社と受託で壁があったわけではなく、プロジェクト単位で壁がありそうでした（言われて気づきましたが、自分もエンジニアのみをやっていた際には他のプロダクトのエンジニアとはあまり交流なかったかも、、、）。横断での定例MTGなどコミュニケーションを図る機会を作って行ったのですが、そもそもコミュニケーションが取れていないことによって生じていた課題を認識するところから始めました。
2-1.横断的なコミュニケーションがないことから生まれる課題
以下の３つが組織として抱えている課題だと認識しました。
・プロダクトの品質がバラバラである
・ノウハウが貯まらない
・技術力の向上が俗人的である
弊社もベンチャーではあるので、一定の水準まではそれぞれのプロジェクトで書かれたコードを正として改善しながら運用していくことで問題はないと思っていました。しかしながら、規模もこれから大きくなっていく、かつ開発ユニットとして横断的に活躍し始める人が増えることを想定すると、プロジェクトに入ってみないとどういうコーディングや技術選定がされているかわからない状態はリスクでしかないと感じました。
プロジェクト毎に開発が行われているということは、技術選定も特にフローがないという状態でした。そのせいで、自分が得意な使い慣れた言語を選定したり、使ってみたい技術を未成熟ながらトライアルするケースもありました。前者は技術の成長を阻害することがあり、後者は脆弱性やトラブルを生みやすいという問題がありました。また最も問題だと感じたポイントは、そこで成熟された技術やトライアルで生まれた失敗例などが、まったく組織に共有されないということです。組織の成長を促すためには、これらが共有されるための仕組みを作る必要もありました。
2-2.品質を産むコミュニケーションとは
課題の中で特に脆弱性を生むようなコードや保守性や可用性が悪いものを特に解消したいという思いはあったのですが、例えば自分がチェックされる側の立場だとした場合に、いきなりコードをチェックされて文句を言われるのは、正直しんどいだろうな、という風に感じるところもありました。なのでいきなり何かをチェックするのではなく、まず良いコードの目線を組織として合わせる必要があると感じました。またオフショアの開発拠点と連携して開発するケースもあるのですが、出てきたものに対して都度修正依頼をかけるのはお互いに大変（特に設計や構成の部分の指摘は先に言ってよって思ってそうだし、それはそう）だったので、そこに対してもアクションをしたいところもありました。
そこで施策として実行したのはガイドラインの作成と技術選定です。そしてこれを作成することを軸にした技術に関するコミュニケーションを取ることを最重要のミッションとしました。
・ガイドラインの作成
WEB、アプリ、サーバー、インフラでチームを分け、それぞれでガイドラインを作成していくプロジェクトを発足し、推進を始めました。またコーディング規約やライブラリの選定基準、gitフローなど、共通で扱うものもリードエンジニアで集まって基準を作っていくこととしました。50本以上のガイドラインを作成し、まだ作成途中のものもありますが、みんなが迷うようなポイントに対して社内での回答は一定用意できてきたように感じます。関係者の皆様、ありがとうございました。
このガイドラインを作る工程にはそれぞれのチームに誰かしら属して議論に入ってもらうこととしました。そうすることで、良いコードとは何かというコミュニケーションが発生し、判断基準で迷った時はそのチームで会話が生まれるようになります。その会話をきっかけに少しづつですが、品質を良くしたいという会話が増えていったように感じています（感じているだけで何か指標があった訳ではないですが、第一歩としては嬉しい）。
・技術選定
技術選定については、タイミング良く新規のプロダクトを作る話が出てきたので、自分たちだったらどういう技術を使ってプロダクトを作りたいか、という議論をしてからスタートすることにしました。私は元々フロントエンドエンジニアだったので、フロントエンドについての技術選定を社内の技術者を集めて意思決定することにしました。結果として、弊社はVueをメインのフレームワークとして利用していたのですが、Reactに切り替えて、Next.jsでの実装を基盤とする方針になりました。コンポーネント設計についてはFSD、フォーマッターはBiomeを採用するなど、少し挑戦的な決定をしたのですが、これらはある程度実装したタイミングでまた振り返り会を実施し、選定してよかったのかどうかを一定のマイルストーンでFBしつつプロジェクトを進行するようにしております。
ここで重要なのは、VueからReactに切り替えた内容ではなく、その過程でどれだけの項目について関係者で合意できたのかだと思っています。技術選定にあたって選定した項目は下記の13項目です。全てにおいて、何かしら選定した訳ではなく、利用しない・使わないといった決定も中には含んでおります。
・JSフレームワーク
・デプロイ
・ページルーター
・パッケージ管理
・コード整形
・HTTP通信
・UIフレームワーク
・CSSフレームワーク
・ヘッドレスUI
・コンポーネント設計
・UIコンポーネントの管理
・状態管理
・テスト
これらを決定する中で、社内で技術や知識について自分よりも詳しく、頼もしい方がいることがわかり、コミュニケーションが取れたことが何よりの収穫だったと感じました。こう言った機会を作り、チームメンバーを頼りにいくというのもマネジメントの中では必要な要素なんだと改めて実感しました。
さいごに
１年半前に自分がマネージメントをすることになったこともそうですが、このような試みを推進する立場になろうとは全くもって想像しておりませんでした。ただ開発部や開発ユニットの責任者をさせていただくにあたり、思ったようにやって欲しいと背中を押してくださった方々のお陰で、このような学びと挑戦の日々を送らせていただいており、大変感謝しております。
自分ができることを愚直にやるとともに、常に変化し、発信し、会社ともども成長できるよう邁進していければと思っておりますのでよろしくお願いします。
最後まで読んでいただきありがとうございました。ご意見などありましたらコメントいただければ幸いです。