開発部横断チームを立ち上げた話
株式会社オプティマインドの高田です。
私は2023年6月から「開発基盤チーム」という開発部を横断したチームの立ち上げを行い半年間活動してきました。
その中で見えてきた難しさや学びを共有するとともに、オプティマインドで定義された評価基準である "Five Powers" の素晴らしさにも触れたいと思います。
この記事は株式会社オプティマインドの社員による Optimind Advent Calendar 2023 の17日目の記事です。
開発基盤チームの誕生
開発基盤チームは2023年6月に誕生しました。
オプティマインドはざっくりとビジネスと開発に組織が分かれており、さらに開発の中で実際に開発を行う２〜７名程度のチームが６つ存在します。
少し前まではチーム数も少なかったのですが、会社が成長し新規プロダクトが立ち上がるなどして人やチームが増えてくる中で以下のような課題や懸念が発生しました。
プロダクトの品質担保が完全にチーム（リーダー）任せの状態
各チームで共通して使うツールの運用ルールが洗練されていない
チーム横断で使いたいツール・システムの開発を担うチームがない
つまり、部を横断して責任を持つチームが今までしっかりと存在しなかったことで、様々な不便やリスクが存在してしまっている状態でした。
これらに対処するために開発基盤チームが誕生しました。ミッションは以下の通りです。
プロダクトのセキュリティや品質の向上
共通業務の集約による全体効率の向上
唯一の横断チームということであえて非常に幅広いミッションを負うことにしています。
取り組んだこと
実際に取り組んだことを一部抜粋します。
新規チームやプロダクトにおける品質担保のための方針の作成
データ保持に関する方針の作成
チームごとに分散したタスク管理ツールの統一
業務委託メンバーの管理DBやフォームの作成
GitHub、AWS、GCPなどの権限管理の方針作成
細かいものも挙げるときりがないのですが、当然のことながらどれも各チームのプロダクトの特性や開発フローなどに影響を受ける／与えるようなものが多いです。
例えば分散したタスク管理ツールの統一を取り上げます。
今まで社内ではRedmine, Jira, GitLabなど様々なツールでタスク管理されていました。開発チームごとに見れば好きなツールを使えて良いのですが、以下のようなデメリットもあります。
複数チームと関わるプロダクトオーナーや他チームと共同して開発するメンバーが、それぞれのチームのタスクの状況をスムーズに見られない
チーム異動があったときのオンボーディングが面倒
ユーザー管理の手間が大きい
そこで開発部内ミーティングでツール統一を提案し、どういったツールにすべきか議論し、試用期間を設け、全チームに移行計画を立ててもらうということをしました。
他にも権限管理まわりでは各サービスの仕組みの理解、ベストプラクティスや事例の調査、チームごとのワークフローにフィットするかどうかの検討、全チームへの周知と運用の徹底、など幅広い要素を学び検討しながら各種ステークホルダーを巻き込みつつ全体像を固めていくという作業が必要でした。
困難と学び
こういった業務を進める中で以下のような困難がありました。
部横断なので技術範囲が広く、さらにセキュリティや認証など初めて触れることが多い
やるべきことがとても多く、プロジェクトを進めるほどスコープが広がりがち
開発からビジネスまで他チームとの連携が多く、スピードの低下が起きる
以下それぞれについて説明します。
１．部横断なので技術範囲が広く、さらにセキュリティや認証など初めて触れることが多かった
オプティマインドは前述した通り６つの開発チームが存在します。それぞれWebやアルゴリズム、データ基盤など多岐にわたる技術スタックを持ち、プロダクト特性も異なるものばかりです。それらをすべて考慮した上で、どのチームにも無理の無い方針や運用を考える必要があります。
また私自身は今までアルゴリズムやバックエンド、インフラ開発をメインとしていました。一方で品質・セキュリティや認証・認可などには今までそこまで深く触れて来ませんでした。そういった新しい専門性が必要な領域において、社内の方針をリードし意思決定する必要がありました。
難しいなとは思いつつ、しかしできないと言っていては何も進みません。日々学び続け、時には各チームにヒアリングし、何とか自分なりにベストなソリューションを模索してきました。
２．やるべきことがとても多く、プロジェクトを進めるほどスコープが広がってしまった
品質やセキュリティ向上と言ってもできることは無限にあります。
例えばテストを書こうという方針を開発チームに示すこともあれば、プロダクトに二要素認証を導入しようとか、社内不正のリスクに対処するために社員のアカウントや権限管理を徹底しようなど、様々な角度から様々なリスクへの対処が求められます。
そうすると一言にセキュリティ向上と言っても考えれば考えるほどやるべきことが出てきます。実際に検討を進める中でタスクから別のタスクが派生して膨らんでいき「あれ、そもそもこれって何が目的だっけ？」となることもありました。
人間の認知能力を越えた問題を一度に扱うことは、途方もない砂漠を無闇に歩き続けるような不安感があります。
やたらと目の前の課題解決に飛びつくのではなく、まず目指す姿を明確にイメージし、そこから逆算して今やるべきことを見定めた上でスコープを区切り、そこに集中して取り組むことが大切だと実感しました。
３．開発からビジネスまで他チームとの連携が多く、スピードの低下が起きた
先に挙げたツール統一は各開発チームに深く関わることでした。個人の好みもありますので、あまりにトップダウン的に「このツールにするぞ！」と押し通しても、メンバーには不満が溜まりますし、モチベーションが上がらないことでプロジェクトが頓挫するかもしれません。
統一することのメリットを示し、統一先がどのツールであるべきかを客観的に議論し、なるべく関わる全員の納得感を醸成する必要がありました。
またプロダクトのセキュリティ向上のための機能追加や仕様変更などは、開発スケジュールとの調整もあれば、お客様への説明のためにビジネス側のメンバーとの調整も必要です。
それぞれの都合をよく知った上で、どういった落とし所がベストなのかを模索し、それをそれぞれに説明し理解してもらう必要があります。
現場からの反発が強く出ることはありませんでしたが、逆に慎重になりすぎてプロジェクトのスピードが出ないということが多くありました。
現場への理解や気遣いと同時にスピード感を持って物事を推し進める力のバランスが求められる、良い経験でした。
必要とされた力とオプティマインドの価値観
上述したとおり、開発基盤チームの活動を通して以下が大切であるという学びがありました。
日々学び続け、時には各チームにヒアリングし、何とか自分なりにベストなソリューションを模索
まず目指す姿を明確にイメージし、そこから逆算して今やるべきことを見定めた上でスコープを区切り、そこに集中して取り組む
現場への理解や気遣いと同時にスピード感を持って物事を推し進める力のバランス
後から気づきましたが、実はこれらはすべてオプティマインドの人事評価基準である "Five Powers" に定義されていることでした。
Five Powers とは、以前はオプティマインドのバリューとして定義されていたもので、現在は人事評価の基準として運用されています。
今回必要だと感じたことはすべて、以下のようにFive Powersとの関係がありました。
日々学び続け、時には各チームにヒアリングし、何とか自分なりにベストなソリューションを模索 → 技術力
まず目指す姿を明確にイメージし、そこから逆算して今やるべきことを見定めた上でスコープを区切り、そこに集中して取り組む → 先見力
現場への理解や気遣いと同時にスピード感を持って物事を推し進める力のバランス → 現場力、実行力、謙虚力
もちろん Five Powers のことはよくわかってはいるものの、改めて難しい課題に挑戦しようとしたとき、これらの力がいかに大切なのかということを改めて実感しました。
またこれらが人事評価の基準として用いられていることから、オプティマインドの評価制度が非常によく考えて作られており、さらにそれが実際に会社の成長に直結しているものだということがよくわかりました。
まとめ
新しいチームを立ち上げ奮闘した半年間でしたが、そのおかげあって多くの学びもありました。さらに手前味噌ながら、オプティマインドの価値観が改めて良いものだということも再認識できました。
今後も自身の成長を意識しつつ、開発基盤チームとしてオプティマインドをどんどんと改善していきたいと思います！
さいごに
ちなみに、開発基盤チームには2023年11月から新たに１名メンバーが加入しました（やっとチームらしくなってきました🙌）。以下はその方の記事で、開発基盤チームのことがもう少しよくわかるかなと思います（本題はイベント参加レポですが）。
このようにオプティマインドではどんとんと新しいチームができ、それに伴って新しいメンバーもどんどん募集しています！
我々と一緒に物流業界の社会課題を解決することにご興味がある方は、カジュアル面談も大歓迎ですのでお気軽にお声がけください！
この記事が気に入ったらサポートをしてみませんか？