inSmartBank

ワンバンクを運営する株式会社スマートバンクのメンバーによるブログです

100人の壁を乗り越える “委員会制度” へのチャレンジ

こんにちは!スマートバンクでEMをしているmitaniです!今年度から自分自身も一つのチームのエンジニアリングマネージャー(EM)として働きつつ、サーバーサイド部の部長としてEM陣をマネジメントしながら組織の改善に取り組んでいます!

スマートバンクでは全社員数が50人を超え、組織化が進んできたことで縦割り構造や意思決定スピードの低下などの100人の壁が顕在化しつつあります。この記事では、100人の壁解消に向けて今年度からサーバーサイド部で始めた “委員会制度” という取り組みについて紹介します!

50 → 100人規模への会社の成長期のマネジメントや、新機能開発と保守運用を両立するための組織マネジメントに悩まれている方、ぜひ最後まで読んでください!

サーバーサイド部における5つの重要組織課題

スマートバンクの組織構造

はじめに、昨年度までのサーバーサイド部における状況を紹介します。スマートバンクはマトリクス組織になっており、新機能開発や新事業立ち上げなどのミッションを元に構成されたチーム(以下、ミッションチーム)に、エンジニアリング本部に属するサーバーサイド部、モバイルアプリ部、SRE部、コーポレートIT部、データ基盤部といった職能で分けた部署がクロスする形で開発してます(参考)。

マトリクス組織図

サーバーサイド部に所属するエンジニアは全員ミッションチームに配属されています。サーバーサイド部としての保守運用系のタスクと、ミッションチームの機能開発のタスクの両方があるものの、会社としてはミッションチームの機能開発が最優先ということを経営レベルで決めております。そのため、日々の業務のほとんどはミッションチームでの開発に割いており、縦割り型な開発体制となっています。これは会社として、10X な事業成長のために事業の種を作り育てていくことと、安心・安全にユーザーのみなさんにアプリを利用してもらうことにフォーカスし人員を配置していたためです。大きな方針として、ミッションチーム体制は維持していく予定で、今年度取り組んでいきたい内容は CTO の @yutadayo が書いたブログ記事で詳しく紹介した通りです。

blog.smartbank.co.jp

縦割り構造によって生じた横断的課題

一方で我々が開発しているワンバンクはリリースから4年が経ち、既存機能の保守運用業務もそれなりに発生してきました。また、人が増えたことで他部門からの依頼や技術広報への取り組みにも対応する必要があります。これまでは特定の誰かにお願いしたり、一時的なプロジェクトチームを立ち上げることで対応をしてきており、ミッションチームで縦割り型の構造にある中で横の連携を保ってきました。しかし、組織構造としての受け皿が十分ではないため、何かの問題が発生してもスピーディに対応できなかったり、既存チームから人員を割くことでミッションチームの計画に影響が出るといった問題も表出し始めていました。

そこで昨年度末にサーバーサイド部のEMが集まり、会社の目標を達成するために現状の組織構造にはどのような問題があるのか?どのような対策を考える必要があるのか?について話し合う場を作りました。話し合いの中でたくさんの課題が出たものの、以下の5つの課題に対して組織的な受け皿を作って対応していくことが重要があると判断しました。

1. 高い開発者体験を保つための課題

スマートバンクでは初期からテストコードをしっかりと書き、リリース前にはQAを入念に行うなどコードの品質を高める取り組みを継続してきました。一方で大量のテストコードによりCIの時間が長くなってきたり、ユーザー数の増加とともにデータ量が増大して特定のクエリに時間がかかってレスポンスが遅くなったり、バッチの実行時間が当初見込みを大幅に超えるような課題が発生し始めました。

ミッションチームの開発に集中しすぎていると、どのミッションチームにも属さない課題や複数のミッションチームに跨る課題への対応が後手に回ってしまっていました。既存のテストコードやバッチなどの既存の技術資産を見つめ直し、これからの事業拡大に耐えるため改善していく必要性が増してきました。

2. エンジニアリング視点でThink N1が足りていない課題

スマートバンクにはThink N1というバリューがあり、「対話と分析を重ねて、 本当に重要な課題を発見しよう。大きな成功から逆算して、チャレンジを続けよう。」ということを大切にしています。これはとことんユーザーと向き合い、対話を重ねて実在する人のイシューを捉え、それを解決するプロダクトを作る、という私たちのプロダクト開発のスタイルを表したものです(詳細)。

これまでユーザーや事業環境に対してThink N1を突き詰めてきたものの、エンジニアリング領域でのThink N1についてはまだまだ改善の余地があります。例えば、決済情報をもっと深掘りして分析し次の事業の種を探したり、ここ最近のAIの波を最前線で乗りこなすなど、会社においてエンジニアリングの重要性が増しています。

3. ミッションチーム間のエンジニア連携、部門間連携が弱い課題

スマートバンクではこの2年で人員が倍増してきました。それに伴い、去年から組織構造を大きく変えてミッションチーム制を取るようにしました。会社が推進したい事業に集中できる状況になった一方、「1. 高い開発者体験を保つための課題」でも紹介したように既存機能の保守運用の課題対応が属人化してきていたり、マーケターやリサーチャー、BizDevなど様々な部署からの依頼といったタスクが増えてきました。

個々のタスクは小さいものの、ミッションチームのタスクへの影響を抑えるため、それらのタスクの担当を遠慮してしまうケースが増えたり、全体を統括する立場の人がいないため進捗管理や優先度決めに苦慮するシーンもありました。増えた人員がスタックすることなく、互いにシナジーを起こして生産性を高めていくために、意図を持って構造を作っていく必要が出てきました。

4. 会社の発信力を維持・向上していくための課題

スマートバンクでは昔から意識的にイベントへの登壇やブログ発信など、技術広報に積極的に取り組んできました。これは会社の強みだと思っており、人が増えたこれからも続けていきたいと思っています。むしろ人が増えた今だからこそ、意識的にエンジニアリング上の強みを見つけて発信したり、会社に新しく生まれた技術領域の発信力を高めるなど、増えた武器を上手く活用することでの効用が得やすくなっていると考えています。

これまでは少人数で全員野球で技術広報に取り組んできましたが、組織が大きくなったこれからも続けられるよう構造を再整理するタイミングが来ました。

5. 個人の成長の場をもっと提供したいという課題

色々な能力を持ったメンバーが増え、チーム体制も整ってきたことにより、ミッションチームの開発生産性は高まりました。同時に会社の組織化も進み評価制度も整ってきたことで、EMが人材育成について考える機会も増えました。

ミッションチームでの開発は、組織的には生産性を高めるものの、限られた特定の役割を個別に割り当てなければならない意味において、個々人の成長面においては必ずしも最適ではないと思っています。例えばチームをリードしたいというエンジニアが複数名いたとしても、チームの役割上誰か一人にお願いせざるを得ず、その開発が続く中ではリーダーシップ面の向上は特定の誰かに集中してしまうという問題があると思います。

「人の成長は環境に依存する」ことは真だと思っているため、成長しやすい環境を提供し続けることが中長期的な会社の成長に重要だと考えています

委員会制度

上記5つの課題を解決するための施策として、 ”委員会制度” というものを今年度から始めました。これは、エンジニアは既存の新規事業開発などのミッションチームに所属しながら、重要課題に対して設けた委員会に兼務という形で参加し、課題解決を図るものです。

今年度は、重要組織課題に対して4つの委員会を設立しました。

事業戦略と各委員会の位置付け

品質委員会

「1. 高い開発者体験を保つための課題」を解決するための委員会です。以下のミッションを持っています。

  • 急成長するサービスの信頼性を維持・向上し、10Xなユーザー数になっても安定して稼働するサービスを作る
  • 急拡大するサーバーサイド部においても、品質・スピード・オーナーシップを維持できるような開発環境を作る
  • 中長期的に技術投資が必要な箇所を見極めて計画・実施する

直近では、以下のような課題に対処してもらっています。

  • 外部キー制約を貼るDDLを追加したリリースがコケる問題への対処
  • バッチ時間を計測し想定時間を超えるバッチの性能改善
  • エラートラッキングツールに通知されたエラーのトリアージ
  • テストCIの実行時間の短縮

テストCIの実行時間はすでに10分以上かかっていたものが7分程度まで短縮されるなど、効果が出始めています。

CIの時間短縮の様子

投資委員会

「2. エンジニアリング視点でThink N1が足りていない課題」を解決するための委員会です。以下のミッションを持っています。

  • AIなどの最新技術に積極的に触れ、効果検証や組織への浸透を図る
  • 今後のワンバンクの事業領域においてエンジニアリングで深掘りできる部分を発見し検証する

直近では、以下のような課題に対処してもらっています。

  • 全社で推進するAI活用のためのガイドライン整備
  • 他部署を巻き込んだAIツールの導入推進

ガイドライン整備では、AIを安全に利用するための利用可能なサービスの整備や、入力可能な情報の整理などを行なっています。

委員会で整備したガイドライン

チーム連携最大化委員会

「3. ミッションチーム間のエンジニア連携、部門間連携が弱い課題」を解決するための委員会です。以下のミッションを持っています。

  • 急拡大する組織において、サーバーサイド部内の交流・連携・共創・切磋琢磨を促し、部全体の生産性を向上させる
  • サーバーサイド部とそれ以外の部署・本部との連携を支援し、協業しやすい組織にする

直近では、以下のような課題に対処してもらっています。

  • Runbookという保守運用のためのルールやドキュメント整備
  • PCI DSSなどでのSREチームとの協力

Runbookでは定常タスクのやり方を記載したり、困ったときに相談できるよう過去の経験者を記載したり、過去の実行ログを紐づける事でナレッジの集積化を図っています。

実際に運用しているRunbook

広報委員会

「4. 会社の発信力を維持・向上していくための課題」を解決するための委員会です。以下のミッションを持っています。

  • 社外に対してスマートバンクの開発組織の魅力を発信しファンを作る
  • 社内のエンジニアの外部発信・プレゼンス向上を支援する

直近では、以下のような課題に対処してもらっています。

  • スマートバンクの強みを意識したブログ発信
  • 技術カンファレンスのスポンサー活動

ブログ発信では、エンジニアのブログの公開スケジュールを管理したり、発信したいテーマに応じて執筆者を募ったりしています。

ブログ管理の様子

人材育成の取り組み

上記それぞれの委員会には委員長を置いており、委員会ごとのOKRの設定・実行・評価までを担っていただいています。委員会以前の組織では、部として対処すべき課題はCTOが設定していたのですが、どの課題に対して何名程度アサインし、どのくらいの期間で完了させるのかを決める権限を委員長に移譲しています。

委員長は入社年月や評価制度上のグレードを問わず、自薦制でやりたい人にお任せしています。既存のミッションチームなどの組織構造の中では発揮できないコンピテンシーを育み、エンジニアリング面でもマネジメント面でもスキルアップを図れる制度になるよう工夫しています。委員会はボトムアップ型でOKRを設定し、実行計画から人の割り振り、進捗管理から成果の評価まで全て委員会内で行ってもらっているため、課題発見やチームマネジメント、やり切る力など幅広くコンピテンシーを高められる場となっています。

委員会制度を導入してみて

まだこの取り組みを開始して3ヶ月ですが、参加メンバーで課題を細分化し、ひとつひとつ解いていっています。CTOや部長といった特定の個人では把握しきれない課題の特定や、ミッションチームの開発との細やかなタスク調整など、委員長と委員がオーナーシップを持って進めてくれることで、これまでにない速さで並行して課題が解決でき始めています。

トップダウン的に課題を見つけ、タスクを割り振ることではできない、細やかな課題への目配せだったり、権限を大胆に委譲して意思決定できることによるモチベーション向上がワークしているのではないかと思っています。

まとめ

スマートバンクでは50人の壁を超え、次は100人の壁が待ち構えています。去年から始めたミッションチーム制は、会社の重要事業を伸ばすことに貢献してきたものの、縦割り型の構造だったためミッションチームの狭間にあったり横断的な課題への対処は別途考える必要がありました。

委員会制度はこのような課題への対処として今年度から “委員会制度” を始めました。滑り出しは上々であるものの、これから新たな課題も出てくると思います。それぞれの委員会が取り組んでいる内容やその成果、反省点などブログで発信していきたいと思うので続報をお待ちください!

We create the new normal of easy budgeting, easy banking, and easy living.
In this blog, engineers, product managers, designers, business development, legal, CS, and other members will share their insights.