開発組織の負債と戦い続ける

Akerun Advent Calendar 2023

この記事は Akerunのカレンダー | Advent Calendar 2023 - Qiita の 11 日目です。

このイベントに参加して 4 年目となりました AkiAbe - Qiita です。
昨年は FW 開発領域のマネージャーとしての活動をしていましたが 、今年はソフトウェア領域全体のマネージャーとして活動をさせていただきました。
photosynth.co.jp

現職に拝命して、まず開発組織の立て直しに注力しました。
その過程で SaaS 事業を運営する会社の宿命として「組織/技術負債と戦い続ける覚悟」が必要だなと感じました。

組織的負債ってなんなん？

ChatGPT さんに聞いてみよう。

問１

ふむふむ。
じゃあ技術的負債との違いはなんだろうか？

問２

ですよね。リンクしてますよね。どちらも一緒に改善が必要ですね。
技術側はテックリードのエンジニアにお任せして、私の方は並行して組織的負債と向き合うことにします。

我々の組織コンディションはどうなの？

こちらから引用。 www.infoq.com

  • 異なる部門で別のツールや方法論を使って同じ問題を解決している。それによって、上層部は企業全体の問題に対処するための同質性を見つけにくくなる。
  • マネージャはその時に良いアイディアだと思ったプロセスを作り、ソフトウエアを実装するが、問題の根本には対処せず、その結果、長期的にはより問題が生まれる。
  • 時間の短縮によって、チームは"今回は"あるタスクを理想的な時間よりも短い時間で仕上げようと決定する。しかし、このやり方が繰り返されてしまう。というのは、最初の1回が特別だったことを誰も覚えていないからだ。

いやーあるあるですね。
我々ももれなく抱えていました。

過去の開発部組織体制は、技術領域ごとにグループをきっちり分けている状態でした。
そのため同じソフトウェア開発をしているのに文化、モチベーション、マインドセットがグループごとに違っている状態でした。
プロダクトとしてもコンウェイの法則が色濃く反映された状態でした。

特に顕著だなと思った一例を挙げます。 一時期、リポジトリの参照権限を各開発グループ/所属ごとに厳しく設定管理していました。
そのため、開発時に依存するライブラリを開発担当者が参照できず、リリースまでの時間的余裕もないという状態であったため、期日に間に合わせるために、無理やり内部リポジトリにそのライブラリを固定して持っているというプロダクトが存在しました。
まさしく、組織構造がそのままプロダクトに反映された例だと感じました。
組織的負債が技術的負債につながっている実例を見た気がしました。

イメージ

また、技術領域を超えたコラボレーションも少ない状態でした。
我々は IoT x SaaS という事業を展開しており、ハードウェア開発および組込ソフトウェア開発からクラウドサービス開発までカバーしています。
横を見れば自分が経験したことのない技術を扱っている人がいる状況にも関わらず組織を超えた技術領域に対する興味が薄い。興味があるが声をかけ辛い。みたいな状況が続いていました。

我々の規模 (開発部以外も含めた全従業員数 160 名程度) の会社でこれだけ広い技術領域をカバーしたエンジニアが在籍する企業は世間を見てもそんなに多くないと思うので、すごくもったいないなぁと感じていました。

どう変えたのか？

上述した課題を解決すべく、組織構造を思い切って変えました。

開発組織体制

賛否はあるのは承知ですが現時点で以下の狙いをもって活動しています。

  • エンジニアが事業貢献に対する意識をより向上させる
    • これから作るものが事業にどう影響するかの理解する
    • 作ったるプロダクトに対する責任をもつ
  • 技術領域を超えた交流のを促進させる
    • 組込/web の相互プロダクト理解を進める
    • システムとしてどういう設計であるべきかの議論をスムーズにする
    • それぞれ独自に進化した文化を共有し合い、いいとこどりを目指す

併せて横串で技術領域を統括する基盤開発チームを作りました。
我々がキーレス社会を担うプラットフォーマーとして成長/運営し続けられるための共通基盤開発をメインにしてもらいます。
また、各事業で独自にプロダクト開発が進んだ際に、知らない間に共通基盤に魔改造が入り誰もメンテナンスできない状態になるのを防ぐ役割も担ってもらいます。

よくあるマトリクス組織の形に近づいた感じですね。

この組織変更と並行して、開発運用プロセスの再定義や運用サイクルの立て付け、仕組み化なども行いました。
その話はまた別途。

組織変更でどういう影響があったのか

概ねポジティブな影響が多いなと感じています。
特に情報の受け渡し、部門内の透明性は少し上がった印象です。

実際にエンジニアからもらったよかったフィードバック

  • 開発プロジェクト関連者が見えやすくなった。相談しやすくなった
  • 作業の依頼がしやすくなり業務がスムーズになった (旧組織だとチームを超えた依頼となり心理的ハードルが高かった)
  • 次にどういう開発案件が待っているのかみえるようになった
  • 上述で例にあげたような技術的負債の一部解消も進んだ

逆に悪かった (狙い通りいっていない) フィードバック

  • (1人 or 2人で完結するような) 小規模な開発プロジェクトが何本も並列している場合、お互いのやっていることの把握が難しい
  • 案件がたくさんはしっていて QA エンジニアとのコラボレーションが進まない
  • 横串活動の技術リーダーの負荷が高い

という感じでした。
案件がたくさん走っている状態だと横串部門への相談が増える傾向にありました。 会社方針として「小粒な案件を大量に捌いていきたい」という状況ではこのような組織構成は向いていないのかもしれません。

どんな組織が最適なのか？は会社のフェーズ、事業内容によっても変わってくることだと思います。
その時々の開発チームコンディションも加味する必要があります。
現時点ではこの体制で特に大きな問題はないと感じていますが、来年になったら違うことをいうかもしれません。
会社も組織も生き物ですので、柔軟にやっていけるとよいかなと感じています。

これからも安定したサービスの提供と、新しく価値のあるプロダクトを生み続けられる開発組織を目指して試行錯誤していきたいと思っています。

株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 photosynth.co.jp

Akerunにご興味のある方はこちらから akerun.com