Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Graat（グラーツ）, profile picture
Uploaded byGraat（グラーツ）
PDF, PPTX1,875 views

事業貢献できるチームを機能させるための組織とプラットフォーム - デブサミ夏2024

事業に貢献するチームは、その領域で「ビジネスの目標」と「ITの活動」の整合性が取れている状態にあります。これを実現するマネジメント手法としてアジャイルが広く知られていますが、チームが置かれている組織的・技術的な環境が適切でなければ、効果を発揮しません。 本講演では、事業に貢献できるチームが具体的にどのような活動を行うべきかを定義し、それを実現するために必要な組織プロセスや技術プラットフォームについて詳しく説明します。また、特に大企業や大規模な組織において、従来のウォーターフォール文化からの転換についても補足します。 この講演を通じて、企業内のIT組織がどのようにして事業貢献して行くのかについて、実践的な知識と方針を提供します。 https://event.shoeisha.jp/devsumi/20240723/session/5089

Technology◦
Download as PDF, PPTX
事業貢献できるチームを機能させるための 組織とプラットフォーム 2024/7/23 グロース・アーキテクチャ＆チームス株式会社 鈴⽊雄介 Developers Summit 2024 Summer
⾃⼰紹介 鈴⽊雄介 • Graat（グラーツ） » 正式名称：グロース・アーキテクチャ＆チームス(株) » 代表取締役社⻑ • (株)アイムデジタルラボ » 三越伊勢丹グループ DX推進機能⼦会社 » 取締役 • ⽇本Javaユーザーグループ • SNS » @yusuke_arclamp » http://arclamp.hatenablog.com/ 1
アジェンダ 事業に貢献する 組織の取り組み 技術の取り組み まとめ 2
3 事業に貢献する
事業に貢献する ビジネスとITがリンクする • 顧客やビジネスの変化に、ITが 素早く対応し続けている状態 »変化への対応を企画し、 »サービスを開発し、 »運⽤し続ける。 »適切なリードタイムとサイクルで ▸リードタイム：1周にかかる時間 ▸サイクル：提供の周期 4
事業に貢献する 今⽇の話 • 事業貢献できるチームを機能させるための 組織とプラットフォーム »事業貢献できるチームがいても、 組織的・技術的問題によって 事業貢献できないことがある »どのような問題が発⽣し、 どうやって解決していくのか？ 5
6 組織の取り組み
7 組織の取り組み 組織的な問題とは
組織的な問題とは チームが機能しない？ • アジャイルチームを作った »プロダクトオーナー（PO）を 中⼼に、顧客を理解し、開発者 がサービスを作る • どうも成果が出せない »決まった機能を、決まった期間 で作ることを要求される »社内の都合で顧客価値に繋がら ない機能が増えていく 8 UX設計 開発者 顧客 PO 開発調整 チームの活動
UX設計 開発者 顧客 PO 開発調整 組織的な問題とは 組織の合意形成が壁になる • 企業には組織の合意形成が必要 »稟議や経営会議への報告 »様々な部署や部⾨との業務調整 • 「縦の合意形成」が壁になる »チーム外の誰かが「合意の覆し」 と「決定の遅延」をする »どうしても既存の業務と考え⽅に 流されていく 9 意思 決定者 業務 説明責任 業務調整
10 組織の取り組み 組織的な問題を解決する
組織的な問題を解決する ①アジャイルを理解する 1/2 • アジャイルは電⾞ »定期的に周回する⼦供電⾞ 1. ホームに乗客が並んでいる 2. 電⾞が来たら定員まで乗⾞ 3. １周回って帰ってくる 4. ⾛⾏中にホームの乗客を並び替えOK • 変化への対応＝どの電⾞に誰を乗せるかを決めるだけ »⾛っている電⾞に影響を与えずに、優先順位を変えられる 11 電⾞ スクラム 電⾞ 開発者たち 乗客 バックログ（案件） 駅⻑ プロダクトオーナー 電⾞に乗る スプリントプランニング 運⾏管理 スクラムマスター
組織的な問題を解決する ①アジャイルを理解する 2/2 • ウォーターフォールはタクシー »乗客が決まるたびに調達する »運転⼿の腕や道路状況、天気などに左右されやすい »乗⾞中の⾏き先変更は⼤きな影響を与える • 電⾞の⽅が状況がわかりやすい »電⾞に間に合うように準備して並ぶのは乗客(親)の責任 ▸乗る準備が完了＝開発者が精度の⾼い⾒積もりが可能になっている 12
組織的な問題を解決する ②リズムを考える • 電⾞の周回リズムと、改札から戻ってくるまでの期間 »リリースサイクル(周回)：リリースの頻度 »リードタイム(改札〜戻る)：企画発案からリリースまでの期間 13 種類 概要 リリースサイクル リードタイム 新機能 業務調整を含む新しい機能 3ヶ⽉/年4回 6-9ヶ⽉ 改善 既存機能の改善や追加 1ヶ⽉/年12回 2-3ヶ⽉ 保守 ちょっとした修正 1週間/年50回 2-3週間 緊急 障害対応 随時 ASAP
組織的な問題を解決する 14 要件調整 概算⾒積もり ビジネス 開発 要件調整/ 概算⾒積もり ※リファインメント 優先順位調整 PO 案件検討 開発 案件回答 調整 ③プロセスを整備する • 組織としての決定プロセスを明確にする »改札前集合〜乗⾞／案件候補募集締切〜スプリントプランニング »⾒積もりできないレベルの要件は、次の機会に向けて再検討 スプリントプランニング→ 相談対応 案件候補募集締切→
組織的な問題を解決する ④組織を巻き込んで運営する • 組織として締切りを守る »遅延や覆しがあるとリズムが狂う • PO(駅⻑)がファシリテーター »⼀般的にPOには決定権がない »適切な意思決定の場を作り、組織とし ての決定をしてもらうための推進者 15 意思 決定者 業務 開発者 顧客 PO
16 技術の取り組み
17 技術の取り組み 技術的な問題とは
技術的な問題とは モノリス • 巨⼤な⼀枚岩のシステム »機能同⼠が密結合になっているため、 ⼀部の変更が全体に波及 »結果、影響調査、リグレッションテスト 、リリース調整に時間がかかる 18 機能 A 機能 B 機能 C Haystack Rock at 8:30am by Brenda Dobbs https://www.flickr.com/photos/bugldy99/45583127204/
技術的な問題とは マイクロサービス • 2014年から広まった概念 • 機能の間の依存/影響を最⼩化する ことで独⽴した変化を可能にする »クラウド、IaC、DevOps、疎結合を実現 するためのデザインパターン... 19 機能 A 機能 B 機能 C Grand Canyon Nat. Park; Desert View Point Refurbishing 1663 by Grand Canyon National Park https://www.flickr.com/photos/grand_canyon_nps/7498769012/
技術的な問題とは マイクロサービスの限界 »この10年で最⼤のアーキテクチャ 的な間違いは、すべてをマイクロ サービスにしようとしたこと • 疎結合や分散は「複雑」 »データの不整合 »構成管理や設計の複雑さ »独⽴性による保守コストの増⼤ 20 https://twitter.com/jasoncwarner/status/1592227285024636928 GitHubの元CTO Jason Warner⽒
21 技術の取り組み 技術的な問題を解決する
技術的な問題を解決する ①適切な粒度で分割/連携 • 変化の境⽬で分割する »業務、ユーザー種別、セキュリティ境 界、性能など • それらを連携させる »API(同期/⾮同期),DB共有,ファイル連 携,イベントストリーム... 22 Stone wall by faungg's photos https://www.flickr.com/photos/44534236@N00/4965756445/ アプリ アプリ サ ー ビ ス サ ー ビ ス サ ー ビ ス サ ー ビ ス マ イ ク ロ マ イ ク ロ マ イ ク ロ マ イ ク ロ マ イ ク ロ マ イ ク ロ マ イ ク ロ マ イ ク ロ モノリス ⾼凝集・疎結合 低凝集・密結合
技術的な問題を解決する ②IDPを整備する 1/2 • 新たな標準化の姿 »IDP(Internal Developer Platform) • DevOps/運⽤管理基盤として »コンテナランタイム、Gitレポジトリ 、CI/CDツール、オブザーバビリティ ツール、チケット管理など »基本設定がされたクラウド環境 »テンプレートやガイドラインなど 23 チームA A専⽤ B専⽤ C専⽤ チームB チームC サービス A1 サービス B サービス C1 サービス A2 サービス A3 サービス C2 IDP クラウド基盤/各種ツール 企業⽤設定やガイドライン
技術的な問題を解決する ②IDPを整備する 2/2 • データ共有基盤として »基幹システムのデータやロジックを利 ⽤しやすくする中間層 ▸ユーザー体験は基幹システムをまたがる ▸これを個別に調整するのが⾯倒 »APIゲートウェイ、データストリーム 、データカタログなどを整備 24 IDP サービス A1 サービス B サービス C1 サービス A2 サービス A3 サービス C2 APIゲートウェイ データストリーム 基幹システムとのブリッジ 顧客管理 販売管理 商品管理 ...
技術的な問題を解決する ④IDPを運営する • チームトポロジーに従う »ストリームアラインドチーム ▸仕事の流れ（ストリーム）に沿ったチーム ▸直接的に事業貢献をするためのチーム »プラットフォームチーム ▸サービスとしてツールやAPIを提供することで、 間接的に事業貢献するチーム 25 プラットフォーム チーム ストリーム アラインドチーム ストリーム アラインドチーム ストリーム アラインドチーム ストリーム アラインドチーム X-as-a-Service 参考『チームトポロジー』 （⽇本能率協会マネジメントセンター,2021） 事業貢献
技術的な問題を解決する ④段階的に進めていく • システム単位の⼀括再構築から、段階的再構成へ • 重要なシステムはIDP上に「クラウドシフト」して構築 »新規サービスだけではなく、基幹システムも段階的に移設可能 ▸ストラングラーパターンを利⽤（次ページ） »もちろん、SaaS適⽤や塩漬けもあり 26 アプリ アプリ サ ー ビ ス ア プ リ マ イ ク ロ マ イ ク ロ マ イ ク ロ モノリス IDP アプリ モノリス モノリス モノリス サ ー ビ ス マ イ ク ロ ...
参考：ストラングラー • ストラングラーパターン »既存システムに⼿を⼊れずに、別構築 した機能ですり替えていく ▸最終的に既存システムを使わなくしていく 27 https://www.flickr.com/photos/paulafunnell/3871868188/ ｻｰﾋﾞｽ A ｼｽﾃﾑA 機能A 機能B 機能C クライアント 機能A ｼｽﾃﾑA ｼｽﾃﾑA 機能A 機能B 機能C クライアント ｻｰﾋﾞｽ A 機能A ｻｰﾋﾞｽ D 機能D ｻｰﾋﾞｽ C 機能C クライアント
28 まとめ
まとめ どうやったらチームが事業貢献できるのか？ • 組織と技術 »アジャイルが電⾞型であることを理解し、組織内調整のリズムを アジャイルに対応していく »IDPを整備し、新サービスの構築や基幹システムのモダナイズを 通じて、クラウドシフトしていく »上記を企業や組織に働きかけていくことが⼤事 • 巨⼈の肩に乗ればいい »ゼロから努⼒する必要はない。先⼈の知恵を学ぼう 29
30 ITとチームの⼒を引き出し、 エンタープライズDXを推進する https://www.graat.co.jp 提供： カジュアル⾯談受付中 https://recruit.gxp-group.co.jp/entry/casual/