SlideShare a Scribd company logo
⾒えない壁を越えよう!
アジャイルやマイクロサービスを阻む
「今までのやり⽅」
2023/7/27
グロース・アーキテクチャ&チームス株式会社
鈴⽊雄介
⾃⼰紹介
鈴⽊雄介
• Graat(グラーツ)
» 正式名称:グロース・アーキテクチャ&チームス(株)
» 代表取締役社⻑
• (株)アイムデジタルラボ
» 三越伊勢丹グループ DX推進機能⼦会社
» 取締役
• ⽇本Javaユーザーグループ
» イベント実⾏委員⻑
• SNS
» @yusuke_arclamp
» http://arclamp.hatenablog.com/
1
アジェンダ
はじめに
アジャイルを阻むもの
マイクロサービスを阻むもの
まとめ
2
はじめに
3
DXに必要な能⼒
変化に素早く対応し続ける能⼒
4
企業が競争上の優位性を確⽴するには、
常に変化する顧客・社会の課題をとら
え、「素早く」変⾰「し続ける」能⼒
を⾝に付けることが重要である
経済産業省 DXレポート2
https://www.meti.go.jp/press/2020/12/20201228004/20201228004.html
“
• 組織とITのあり⽅は、
»⽬的ごとに横断チームを構成、
サービスを連携
»横断的に管理、全体最適
»顧客視点での優先順位
»ルールとプロセスを作り出す
»状況に合わせて意思決定
これから求められるやり⽅
変化に素早く対応し続ける能⼒
5
IT
組織
チーム サービス群
アジャイル マイクロ
サービス
今までのやり⽅
• 組織とITのあり⽅は、
»⽬的ごとに部署もシステムも分割
»分割した単位で管理、個別最適
»期初に定めた優先順位
»ルールとプロセスを遵守
»⻑期計画で稟議
6
IT
組織
部署 システム
ウォーター
フォール
モノリス
安定して効率的に対応し続ける
「今まで」と「これから」
このギャップを、どうすればいいの?
7
IT
組織
部署 システム
ウォーター
フォール
モノリス
安定して効率的に
対応し続ける能⼒
IT
組織
チーム サービス群
変化に素早く
対応し続ける能⼒
アジャイル マイクロ
サービス
?
今⽇の話
意識的に分離し、つなげる
• 出島を意識する
»孤島:流通が遅すぎて成果が⼩さい
»半島:名前を変えただけになる
• どのように繋げるか?
»両者の間にある「⾒えない壁」を意
識し、意識して越える
8
Ground-plan of the Dutch trade-post on the island Dejima at Nagasaki
Isaac Titsingh
↑⾒えない壁
9
アジャイルを阻む壁
10
Yamanote Line ⼭⼿線 by Melvinnnnnnnnnnn (FN2187) CC BY-SA 2.0
https://www.flickr.com/photos/montoya711/49110746247/
JPN TAXI. by MIKI Yoshihito CC BY 2.0
https://www.flickr.com/photos/mujitra/50629363916/
どっちがアジャイル?
アジャイルは電⾞
アジャイルは⾃由?
• タクシーは、どこにでも、
何⼈でも⾃由に運べる
»ただし、調達やスキルが不安
• 電⾞は、ルールが明確
»継続して安定的に運ぶなら、運
⾏計画が厳密な⽅が安⼼
»スクラムを例に説明
11
11
11
11
Yamanote Line ⼭⼿線 by Melvinnnnnnnnnnn (FN2187) CC BY-SA 2.0
https://www.flickr.com/photos/montoya711/49110746247/
JPN TAXI. by MIKI Yoshihito CC BY 2.0
https://www.flickr.com/photos/mujitra/50629363916/
スクラムの仕組み
»電⾞は定期に出発
»ホームでは乗客が⼀列に並ん
で待っている
»電⾞が来たら定員まで乗⾞
»電⾞が出発したら、乗客の並
び順は変えていい
12
出発ホーム 到着ホーム
電⾞は定期的に
出発する
出発ホーム 到着ホーム
出発ホームには乗客が
並んで待っている
出発ホーム
電⾞に乗る
到着ホーム
出発ホーム 到着ホーム
出発ホームの乗客の
並び順を変える
スクラムの仕組み
スクラム⽤語との対⽐
13
電⾞の説明 スクラム⽤語 説明
電⾞の運⾏ スプリント 繰り返し続ける作業期間。1ヶ⽉以内の決まった
⻑さ
出発ホーム プロダクトバックログ これからやりたいことを優先順に並べたリスト
の乗客 プロダクトバックログアイテム そのリストの1⾏
電⾞に乗る スプリントプランニング スプリントの開始時に、このスプリントでやる
ことを決めるイベント
電⾞ スプリントバックログ このスプリントで実施するタスクのリスト。
スプリントプランニングでプロダクトバックロ
グからアイテムを移動させてくる
の乗客 スプリントバックログアイテム そのリストの1⾏
スクラムの仕組み
やりたいことを安全に変えられる
• 電⾞は出発したホームを気にしない
»「今やること」と「やりたいこと」の分離
»予定の変更による影響が開発チームに発⽣しない
• 「誰を乗せるか」を決めるだけでいい
»開発リソースの調達が不要で、無駄がない
• ただし、電⾞に間に合うのは乗客の責任
»荷物をまとめ、切符を買い、⼀列に並んで待つ
14
アジャイルを阻む壁
スクラムと要件の詳細化
15
スクラムと要件の詳細化
⾒えない壁
• 要件の詳細化はビジネス側の責任
»プランニングまでに⾒積もり可能なレベルに詳細化し、並べる
▸スプリント内で開発者が詳細化していると⾒積もり精度が悪くなる
16
要件 要件定義 基本設計 詳細設計 実装 テスト
詳細設計
実装/テスト
詳細設計
実装/テスト
詳細設計
実装/テスト
詳細設計
実装/テスト
詳細設計
実装/テスト
要件定義&
基本設計
要件定義&
基本設計
要件定義&
基本設計
要件定義&
基本設計
要件定義&
基本設計
要件定義&
基本設計
要件 要件 要件 要件 要件 要件
ウォーターフォール
スクラム
…
⽂書 ⽂書 ⽂書
ビジネス主導
開発主導
凡例:
スクラムと要件の詳細化
⾒えない壁を越える
• PO主導で要件の詳細化をできるようにする
»要件の詳細化作業はスプリントとは独⽴して⾏う
▸プランニングまでに各所調整なども完了させる
▸開発者にはリファインメントで相談、スプリントでの技術検証を依頼
»POに詳細化スキルがない場合、開発経験者をつけて⽀援
▸POが専任して担当するのが望ましいが、現実は簡単ではないので
▸スクラムマスターが担当するのはアンチパターン
▸⽀援者をプロキシPOと称することもある
ü 決定権はないが、要件の詳細化や開発者との細かい調整を実施する⼈
17
アジャイルを阻む壁
プロダクトオーナーと決定
18
プロダクトオーナーと決定
プロダクトオーナー
• 最⼤の仕事は「決定」
»価値を最⼤化させるために、ど
んな乗客を乗せるか?いまの並
び順は?いつ電⾞に乗せる?を
決定する
• 決定の遅延も覆しもしない
»遅延:決めるのが遅い
»覆し:決まったことを変える
19
価値の
最⼤化
開発者
ユーザー/
顧客 PO
開発者と
調整
スクラムガイド 2020年11⽉版
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
“
プロダクトオーナーと決定
POが「決定」できるのか問題
»プロダクトオーナーをうまく機能させるには、組織全体でプロダ
クトオーナーの決定を尊重しなければならない
»プロダクトオーナーは 1 ⼈の⼈間であり、委員会ではない
• POへ権限委譲をすれば解決されるのか?
20
プロダクトオーナーと決定
⾒えない壁
• 組織としての決定をするには
「縦の合意形成」が必須
»POの決定を、組織の決定として
尊重するには、各所との合意が
必要になる
»かつ、この決定をスプリントに
合わせて遅延も覆しもしないよ
うにする
»形式的な権限以上は無意味
21
意思
決定者
業務
開発者
ユーザー/
顧客 PO
説明責任
業務調整
価値の
最⼤化
開発者と
調整
プロダクトオーナーと決定
⾒えない壁を越える
• 組織としての意思決定プロセスを明確にする
»縦の合意形成に必要な⼈を集めるミーティングを定期開催
▸スプリントと同じサイクルで⾏うが、スプリントレビューとは別にする
ü 主にビジネス上の意思決定になるので、PO+SMぐらいが参加
»メリット
▸コンテキストが共有されていく
ü 意思決定者の考え⽅と現場の考え⽅の共有
▸⼩さな失敗の報告が⾏いやすくなる
ü 取り組みが⼩さいと成功も失敗も学びと⾔える
22
23
マイクロサービスを阻む壁
MSAとは
モノリスの課題
• モノリスでは機能間調整と実
⾏時影響が問題になる
»機能間調整:影響調査、リグレ
ッションテスト、リリース調整
»実⾏時影響:スローダウン
24
Haystack Rock at 8:30am by Brenda Dobbs
https://www.flickr.com/photos/bugldy99/45583127204/
機能
A
機能
B
機能
C
MSAとは
マイクロサービスで解決
• 機能間依存をなくせばいい
»機能をサービスに分割し、依存
を疎にすれば、機能間調整も実
⾏時影響も抑えられる
25
機能
A
機能
B
機能
C
cobblestone by Bri Weldon
https://www.flickr.com/photos/briweldon/5354470757
MSAとは
実現に向けた技術論
• 機能を疎結合にする
»機能をサービスに分割し、
APIで繋ぐ
»サーバもデータベースも独⽴
»無停⽌デプロイと⾃動障害対応
• インフラの⾃動化が必須
»⼤量のサーバを効率的に管理
26
サービスA
v1.0
サービスB
v1.0
サービスC
v1.0
DB A DB B DB C
サーバ サーバ サーバ
サービスB
v1.1
サーバ
障
害
MSAとは
実現に向けた設計とプロセス
• ⾼凝集・疎結合は、将来の変更容易性を⾼める
»⾼凝集:各モジュールは単⼀の明確な責任を持つ
▸それぞれのモジュールが理解がしやすく、再利⽤性が⾼い
»疎結合:各モジュールが独⽴し、依存しない
▸⼀部の変更が他者に影響しにくくなる
• 各モジュールはアジャイルで開発される。各チームは独⽴
したリズムで変更とデプロイを実施する
27
MSAとは
MSAの課題
• ⾼凝集・疎結合は、実現難易度が⾮常に⾼い
• 低凝集・密結合にもメリットがある
»開発容易性が⾼い:密結合の⽅が設計がシンプル
»全体管理コストが低い:サーバ台数が少ない
»データ整合性が取りやすい:RDBのトランザクション機能が保証
28
モノリス アプリ アプリ
サ
"
ビ
ス
サ
"
ビ
ス
サ
"
ビ
ス
サ
"
ビ
ス
マ
イ
ク
ロ
マ
イ
ク
ロ
マ
イ
ク
ロ
マ
イ
ク
ロ
マ
イ
ク
ロ
マ
イ
ク
ロ
マ
イ
ク
ロ
⾼凝集・疎結合
低凝集・密結合
マ
イ
ク
ロ
MSAとは
参考
»近年のアーキテクチャにおけ
る⼤きな間違いは、すべてを
マイクロサービス化しようと
したこと
»モノリスからマイクロサービ
スまでは連続的であり、以下
ように考える
»モノリス > アプリ > サービス
> マイクロサービス
29
https://twitter.com/jasoncwarner/status/1592227285024636928
GitHubの元CTO Jason Warner⽒のツイート
マイクロサービスを阻む壁
マイクロサービスへの取り組み⽅
30
MSAへの取り組み⽅
⾒えない壁
• ⼀括再構築では成功しない
»低凝集・密結合のシステムを単純に
MSAにしようとすると「分割した密
結合」になりやすい
• 単純な分割も成功しにくい
»密結合のまま分割するのは危険
▸「DB共有した複数アプリ」ぐらいまで
が現実的
31
Grand Canyon Nat. Park; Desert View Point Refurbishing 1663
by Grand Canyon National Park
https://www.flickr.com/photos/grand_canyon_nps/7498769012/
MSAへの取り組み⽅
⾒えない壁を越える 1/3
• マイクロサービス“化”
»対象システムや組織の規模や成熟度に
合わせて段階的に進める
»疎結合になるように切り出していく
»その途中段階は、粒度が混ざり合う
32
Stone wall by faungg's photos
https://www.flickr.com/photos/44534236@N00/4965756445/
アプリ アプリ
サ
"
ビ
ス
サ
"
ビ
ス
サ
"
ビ
ス
サ
"
ビ
ス
マ
イ
ク
ロ
マ
イ
ク
ロ
マ
イ
ク
ロ
マ
イ
ク
ロ
マ
イ
ク
ロ
マ
イ
ク
ロ
マ
イ
ク
ロ
マ
イ
ク
ロ
モノリス
同時に存在する
MSAへの取り組み⽅
⾒えない壁を越える 2/3
• ストラングラーパターン
»×既存システムを分割する
»○新サービスで機能をすり替える
33
https://www.flickr.com/photos/paulafunnell/3871868188/
サービス
A
システムA
機能A
機能B
機能C
クライアント
機能A
システムA
システムA
機能A
機能B
機能C
クライアント
サービス
A
機能A
サービス
D
機能D
サービス
C
機能C
クライアント
MSAへの取り組み⽅
⾒えない壁を越える 3/3
• プラットフォームを整備し、段階的にシフトする
»DevOpsを実現できる基盤を整備し、共通化する
▸パブリッククラウド上にPaaSを中⼼に組み上げるのが⼀般的
»既存機能を段階的にシフトしながら、新しいものも作る
▸Netflixは2008年にAWS移⾏を開始し、2016年1⽉にクラウドシフト完了※
34
アプリ
アプリ
サ
"
ビ
ス
サ
"
ビ
ス
マ
イ
ク
ロ
マ
イ
ク
ロ
マ
イ
ク
ロ
マ
イ
ク
ロ
モノリス
プラットフォーム
アプリ
モノリス
モノリス モノリス
サ
"
ビ
ス
マ
イ
ク
ロ
...
※Netflixのクラウド移⾏が完了 - About Netflix
https://about.netflix.com/ja/news/completing-the-netflix-cloud-migration
35
まとめ
まとめ
意識的に分離し、つなげる
• 出島を意識する
»孤島:流通が遅すぎて成果が⼩さい
»半島:名前を変えただけになる
• どのように繋げるか?
»両者の間にある「⾒えない壁」を意
識し、意識して越える
36
Ground-plan of the Dutch trade-post on the island Dejima at Nagasaki
Isaac Titsingh
まとめ
⾒えない壁を越えよう
• アジャイルを阻む壁
»スクラムと要件の詳細化
»プロダクトオーナーと決定
• マイクロサービスを阻む壁
»マイクロサービスへの取り組み⽅
37
まとめ
⾒えない壁とは、何なのか?
• ビジネスとIT、組織とIT、経営とITの壁
»ITに対して要件を決める、意思決定する、投資する、といったス
ピード感が変わっていく必要がある
»企業のさまざまな要素とITの距離を短くする必要がある
»そのためには「今までの常識」を変えないといけない
38
安定して効率的に
対応し続ける能⼒
変化に素早く
対応し続ける能⼒
まとめ
今⽇は時間が⾜りない…
• 価値と機能は直⾏する
• カスタマージャーニーだけで業務/ITは検討できない
• MVPは実現可能性を前提とする
• リードタイムとリリースサイクルを管理する
• DevOpsにおける開発部⾨と運⽤部⾨
• 外部品質を維持するために内部品質を⾼める
• ...
39
40
さいごに
さいごに
壁を越える⼈の⼼持ち
• 他者にリスペクトを持つ
»⾃分と異なる「やり⽅」には背景があり、それには意味がある
▸⽬指す場所は同じであることを共有する
• オープンに話し合う
»なぜ、そのやり⽅をするのかを説明し、意⾒をもらう
▸応援してくれる⼈は、必ずいる
• ⾃らが考え、動く
»うまくいかないことを他者のせいにせず、⾃ら変えていく
▸ただし、妥協してはならない
41
42
ITとチームの⼒を引き出し、
エンタープライズDXを推進する
https://www.graat.co.jp
提供:
カジュアル⾯談受付中
https://recruit.gxp-group.co.jp/entry/casual/

More Related Content

PDF
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
PDF
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
PPTX
Amazon SageMakerでカスタムコンテナを使った学習
PDF
アーキテクチャのレビューについて - JaSST Review '18
PPTX
WayOfNoTrouble.pptx
PDF
ユーザーストーリーの分割
PDF
アジャイル開発とメトリクス
PDF
ユーザーストーリー駆動開発で行こう。
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
Amazon SageMakerでカスタムコンテナを使った学習
アーキテクチャのレビューについて - JaSST Review '18
WayOfNoTrouble.pptx
ユーザーストーリーの分割
アジャイル開発とメトリクス
ユーザーストーリー駆動開発で行こう。

What's hot (20)

PDF
アジャイル開発を支えるアーキテクチャ設計とは
PDF
インフラCICDの勘所
PDF
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
PDF
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
PDF
ビジネスパーソンのためのDX入門講座エッセンス版
PDF
マルチテナントのアプリケーション実装〜実践編〜
PPTX
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
PDF
機械学習モデルのサービングとは?
PDF
テストとリファクタリングに関する深い方法論 #wewlc_jp
PDF
正しいものを正しくつくる
PDF
AWSではじめるMLOps
PDF
MLOps に基づく AI/ML 実運用最前線 ~画像、動画データにおける MLOps 事例のご紹介~(映像情報メディア学会2021年冬季大会企画セッショ...
PDF
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
PPTX
アジャイルメトリクス実践ガイド
PDF
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
PDF
フロー効率性とリソース効率性、再入門 #devlove #devkan
PDF
Infrastructure as Code (IaC) 談義 2022
PDF
テスト計画の立て方 WACATE2019 夏
PPTX
MLOps入門
PDF
開発速度が速い #とは(LayerX社内資料)
アジャイル開発を支えるアーキテクチャ設計とは
インフラCICDの勘所
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
ビジネスパーソンのためのDX入門講座エッセンス版
マルチテナントのアプリケーション実装〜実践編〜
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
機械学習モデルのサービングとは?
テストとリファクタリングに関する深い方法論 #wewlc_jp
正しいものを正しくつくる
AWSではじめるMLOps
MLOps に基づく AI/ML 実運用最前線 ~画像、動画データにおける MLOps 事例のご紹介~(映像情報メディア学会2021年冬季大会企画セッショ...
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
アジャイルメトリクス実践ガイド
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
フロー効率性とリソース効率性、再入門 #devlove #devkan
Infrastructure as Code (IaC) 談義 2022
テスト計画の立て方 WACATE2019 夏
MLOps入門
開発速度が速い #とは(LayerX社内資料)
Ad

Similar to 見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023 (20)

PDF
ビジネスとITをリンクさせるアジャイルな組織のつくり方 - アジャイル経営カンファレンス2023
PDF
マイクロサービスに至る歴史とこれから - XP祭り2021
PDF
エンタープライズ、アーキテクチャ、アジャイルのこれから
PDF
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
PDF
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
PPTX
エンタープライズアジャイルを阻む組織やプロセスと、その処方
PDF
XP祭り2014「アジャイルを手放して得られたこと」
PDF
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
PDF
ITトレンドに見る日本のエンタープライズITについて
PDF
アジャイル成功の鍵 意思決定を進化させる組織プロセス設計の8ステップ - GraatエンタープライズDXセミナー
PDF
なぜ「マイクロサービス“化”」が必要なのか
PDF
エンタープライズアジャイルの課題と解決へのアプローチ - Developers X Summit 2024
PDF
enterprise agile lean modeling
PDF
Microsoft Dynamics CRMで営業力と組織対応力を強化
PDF
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
PDF
大企業のアジャイル導入で本質的に変えるべきこと - Agile Japan2021
PDF
SIerとクラウドの付き合い方
PDF
What is Enterprise Agile
PPTX
20201023 Builders Box 2nd Enterprise Architect
PDF
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
ビジネスとITをリンクさせるアジャイルな組織のつくり方 - アジャイル経営カンファレンス2023
マイクロサービスに至る歴史とこれから - XP祭り2021
エンタープライズ、アーキテクチャ、アジャイルのこれから
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
エンタープライズアジャイルを阻む組織やプロセスと、その処方
XP祭り2014「アジャイルを手放して得られたこと」
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
ITトレンドに見る日本のエンタープライズITについて
アジャイル成功の鍵 意思決定を進化させる組織プロセス設計の8ステップ - GraatエンタープライズDXセミナー
なぜ「マイクロサービス“化”」が必要なのか
エンタープライズアジャイルの課題と解決へのアプローチ - Developers X Summit 2024
enterprise agile lean modeling
Microsoft Dynamics CRMで営業力と組織対応力を強化
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
大企業のアジャイル導入で本質的に変えるべきこと - Agile Japan2021
SIerとクラウドの付き合い方
What is Enterprise Agile
20201023 Builders Box 2nd Enterprise Architect
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
Ad

More from Yusuke Suzuki (20)

PDF
Javaとコミュニティの歩み 2020
PDF
エンタプライズ領域のアジャイル開発の課題 - FIT2020
PDF
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
PDF
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
PDF
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
PDF
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
PDF
Javaはコミュニティの力で再び偉大になれるのか
PDF
Javaのカルチャーとグロース - MANABIYA 2018
PDF
JJUG初心者のためのJava/JJUG講座
PDF
エナジャイル設立によせて
PDF
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
PDF
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
PDF
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
PDF
JavaOne 2016総括 #jjug
PDF
クラウド時代のエンジニアについて #sesfukui
PDF
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
PDF
ウォーターフォールとアジャイルを考える #ita_ws
PDF
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
PDF
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
PDF
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演
Javaとコミュニティの歩み 2020
エンタプライズ領域のアジャイル開発の課題 - FIT2020
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
Javaはコミュニティの力で再び偉大になれるのか
Javaのカルチャーとグロース - MANABIYA 2018
JJUG初心者のためのJava/JJUG講座
エナジャイル設立によせて
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
JavaOne 2016総括 #jjug
クラウド時代のエンジニアについて #sesfukui
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
ウォーターフォールとアジャイルを考える #ita_ws
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演

見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023