Upgrade to Pro — share decks privately, control downloads, hide ads and more …

襲来する課題の山に立ち向かう開発体制づくり

 襲来する課題の山に立ち向かう開発体制づくり

急成長の中で開発組織の規模が50名に迫ろうとするiCAREの課題を赤裸々に語ります。
開発組織の全体像の把握はマネジメント以外の人にも大切なので、全ての開発者に聞いてほしい!

yasudatoshiyuki

November 17, 2021
Tweet

More Decks by yasudatoshiyuki

Other Decks in Technology

Transcript

  1. ©iCARE Co., Ltd All rights reserved 自己紹介 3 安田俊之 Twitter:

    @TakataNoToshi iCAREにて2020年7月よりVPoE 関わってきた技術 Ruby on Rails, Vue.js, AngularJS PHP, Java, Perl その他: Terraform, Ansible, Chef, AWS, etc.
  2. ©iCARE Co., Ltd All rights reserved 有益かつ応募があるかも 8 この手の格闘は業界や会社固有の問題というよりはス タートアップに共通の課題

    ・スタートアップ企業の開発者にとって有益 ・課題解決が面白そう、取り組みたい、 と考える方がiCAREに応募してくれるかも 課題の共有
  3. ©iCARE Co., Ltd All rights reserved 10 iCAREおよびCarelyの歴史 2011年(10年前) 創業

    2016年(5年前) Carelyローンチ 2021年 導入社数:470社(10月時点) 日本の人事部「HRアワード2021」人事労 務管理部門 最優秀賞受賞
  4. ©iCARE Co., Ltd All rights reserved 
 チャットによる
 相談・アドバイス
 従業員向け

    
 一元管理で
 圧倒的に効率化
 人事・産業医向け 企業の健康を
 トータルサポート
 従業員
 メディカルスタッフ
 人事・産業医
 チャット クラウド 健康診断
 ストレス
 チェック
 残業時間
 01 サービス概要
  5. ©iCARE Co., Ltd All rights reserved 主な要望の変化 14 1. 多様な機能

    2. 多様なユーザー権限体系 3. 多様な他システムとの連携(SSO IdP、API) 4. より高いセキュリティ基準 5. より安定したサービス提供 実現 システムが複雑化
  6. ©iCARE Co., Ltd All rights reserved システムの複雑化 15 1. 思わぬところで不具合が出る

    テストコードや動作確認で防止しても、事前予測が難し い依存関係により不具合が発生 2. システム全体を把握することが困難 不具合が発生した時に原因の特定に時間がかかった り、問題解決の難易度が上がる
  7. ©iCARE Co., Ltd All rights reserved 高くなる専門性 16 フロントエンド サーバーサイド

    インフラ それぞれ高い専門性が必要になるため、それぞれの領 域の壁を超えて作業する難易度が高くなる それぞれの領域の間にある問題が置き去りになる
  8. ©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 18 ここに本文が入ります ここに本文が入ります

    ここに本文が入ります 
 
 これらの問題を解決するための 開発体制
  9. ©iCARE Co., Ltd All rights reserved 開発体制として求められている点 19 1. 開発要員の増員

    2. 多様な要求に応えるチーム構成 3. 管理可能なチームサイズ 4. チームごとのマネージャー・リーダー 5. 領域の間問題を最速で解決するフィーチャーチーム制 6. 領域の間を埋める多様な開発ロール (具体的には、QAE、セールスエンジニア、 プロジェクトマネージャなど)や各種委員会の設置
  10. ©iCARE Co., Ltd All rights reserved フォーカスする話題 20 1. 開発要員の増員

    2. 多様な要求に応えるチーム構成 3. 管理可能なチームサイズ 4. チームごとのマネージャー・リーダー 5. 領域の間問題を最速で解決するフィーチャーチーム制 6. 領域の間を埋める多様な開発ロール (具体的には、QAE、セールスエンジニア、 プロジェクトマネージャなど)や各種委員会の設置
  11. ©iCARE Co., Ltd All rights reserved 開発チーム構成詳細 22 COO CTO

    シニアマネージャー        キャプテン チーム CTO VPoE 健診 QAE CTO室 基盤技術 CTO 応用技術 パートナー 技術顧問 デザイ ン SRE 現状はこんな感じです
  12. ©iCARE Co., Ltd All rights reserved チーム構成の説明 23 健診 基盤技術

    チーム チーム 応用技術 3つのフィーチャーチーム(フロントエンド・バックエンド) ファンクションチーム デザイン QAE 技術 顧問 パートナー SRE CTO室
  13. ©iCARE Co., Ltd All rights reserved チーム構成の意図 24 アプリケーションエンジニアが3つの フィーチャーチームに分かれている理由

    1. Carelyの中で健診関連開発は機能的な独立性を持っており、他 機能よりもドメイン知識が必要。そのため、チームとして独立したほ うが開発効率が良い 2. 健診関連開発以外の開発は、機能で分割するのは難しい。た だ、一つのチームを構成するにはメンバーが多く、メンバー管理が 難しい。→2つのチームに。
  14. ©iCARE Co., Ltd All rights reserved チーム構成の意図 26 アプリケーションエンジニアが3つの フィーチャーチームに分かれている理由

    1. Carelyの中で健診関連開発は機能的な独立性を持っており、他 機能よりもドメイン知識が必要。そのため、チームとして独立したほ うが開発効率が良い 2. 健診関連開発以外の開発は、機能で分割するのは難しい。た だ、一つのチームを構成するにはメンバーが多く、メンバー管理が 難しい。→2つのチームに。 責務の境界が曖昧
  15. ©iCARE Co., Ltd All rights reserved オペレーションチームの不在とチームの責務の曖昧さ 27 顧客増加により、調査やGUIから操作できないデータ操 作オペレーションが増加

    現状はそれぞれのフィーチャーチームの誰かが開発を 止めて対応 リリースが近かったり、スケジュールが厳しかったりする と自発的に拾いに行けない やりくり
  16. ©iCARE Co., Ltd All rights reserved サーバーサイド、フロントエンドの業務量のアンバランス 28 フロントエンド Vue.js

    サーバーサイド Ruby on Rails ひとりひとりのメンバーは、基本的にどちらかの役割を 担っており、状況に応じてスイッチしていない 業務量は、現状の人員構成 にあわせて発生するわけではない 言語が異なり、かつ高い専門性 が必要が必要なためスイッチが 難しい やりくり
  17. ©iCARE Co., Ltd All rights reserved 体制変更の連続によるメンバーへの精神的負担 29 人数の増加に伴う度重なる体制の変化 ・対人関係が苦手な人は、チーム構成が変わることによって関わる

    人が変わり、心理的に負担がかかる ・本人が希望しない役割を求められる フラストレーション ストレス ケア・ 個別対応
  18. ©iCARE Co., Ltd All rights reserved 開発チーム構成詳細 31 COO CTO

    シニアマネージャー        キャプテン チーム CTO VPoE 健診 QAE CTO室 基盤技術 CTO 応用技術 パートナー 技術顧問 デザイ ン SRE 様々な課題を解決するために 作られた体制。でもこの体制も またいろいろな課題を抱えてい る。しかも来月も5人ジョイン ・・・。
  19. ©iCARE Co., Ltd All rights reserved 課題はチーム構成以外にも山ほどある・・・ 32 ・難易度の高い問題を解決できるメンバーが一部のメンバー に限られる

    ・エンジニアが開発と採用活動を並行しなければいけない ・プロダクトの成熟の中で、軒並み課題の難易度が高くジュ ニアエンジニアのオンボーディングが難しい ・様々なエンジニアの志向性にあわせたキャリアパスの用意 などなど、この他にもたくさん・・・