エンタープライズ、アーキテクチャ、アジャイルのこれから

Copyright© Growth Architectures & Teams, Inc. All rights reserved.
エンタープライズ、
アーキテクチャ、
アジャイルのこれから
2019/6/23
グロース・アーキテクチャ＆チームス株式会社
代表取締役鈴木雄介
#devlovexC

自己紹介
• 鈴木雄介
–Graat（グラーツ）
» グロース・アーキテクチャ＆チームス株式会社
» 代表取締役社長
» http://www.graat.co.jp/
–日本Javaユーザーグループ
» CCC運営委員長（初代）
–SNS
» @yusuke_arclamp
» http://arclamp.hatenablog.com/
1
NEW

アジェンダ
• この10年
• これからの未来
• これからのアーキテクチャ
• これからのアジャイル
• さいごに
2

この10年
3

10年前…
• 日経SYSTEMS 2009年2月号
–特集１「10年後も通用するスキル」
» 今後重要なのは「ユーザーにサービスとしてどのような価
値を提供するのか」という視点だ。この視点で優れた提案
ができるITエンジニアこそ，ユーザーから支持されるよう
になるだろう。
» 10年後<中略>クラウド・プラットフォームを利用したり，
他人が開発したサービスを組み合わたりして，ユーザーの
求めるサービスを作っていくようになる
» よいサービスを提供するためには、常に改善をしていかな
くてはいけない。
4

10年前…
• JJUG CCC 2009 Fall
–クラウドを超えた先の企業システム像
» システム統合パターンの整理
▸ Enterprise Integration Patterns大事
» コンテナ型アーキテクチャの導入
▸ ガジェット型の企業アプリケーション
» インターフェースによる分業
▸ APIを通じて分業し、個別に最適な道具を選ぶ
5https://www.slideshare.net/yusuke/20091008-jjug-ccc

10年前…
• ソフトウェアアーキテク
トが知るべき97のこと
» アーキテクトはシステムをデ
ザインする前に、コミュニケ
ーションについて考えなくて
はいけません。<中略>どん
な人たちが、どんな目的で、
どんなコミュニケーションを
しているのかを知るのです。
» ユーザーと呼ばれる存在のい
ない、コミュニケーションの
総体をデザインする
6
2009/10/5
https://ソフトウェアアーキテクトが知るべき97のこと.com/エッセイ/システム
ではなく-コミュニケーションをデザインせよ

10年前…
• ITアーキテクト最終号
–これからのITアーキテクト
/開発者のあり方
» システムの価値は本来、「社
会におけるユーザーの価値を
どれだけ高めたか」によって
測られるべき
» ITアーキテクトは、システム
の外側へ、システムが置かれ
た環境へと目を向ける必要が
ある
7

10年前…
• （続き）
» ITアーキテクトは開発者だけではなく、ユーザー、経営者
、さらには取引先や消費者など、システムの外側にいる専
門家たちを相手にする。
» そして、彼らの価値観を調整することで、初めて真に良い
システムを設計することができる。
» 「システムがどのような環境で使われるのか。そして、シ
ステムが何をもたらし、何を変えていくのか」ーーこの視
点を持つことが、これからの時代に必要なことなのだ。
8

10年前…
• DevLOVE2009
–「開発を愛する僕らが目を向けるべき、ソフトウェ
ア以外に大事な5つ4つの事」
9https://www.slideshare.net/yusuke/devlove2009-4

余談：JJUGの6年 →会長退任
• 方針：金は調達するから、あとは好きにして
• JJUG CCC
–1000名以上、20代~30代：70%、初参加：30%
–海外スピーカーセッション：10枠/57枠
10

この10年
• 取り組んできたこと
11
ユーザー
企画
実装
運用
アーキテクチャ
アジャイル

これからの未来
12

2040年問題
• わりと確定した未来
–2025年以降は「現役世代の
急減」にシフト
» 団塊ジュニアが65歳以上に
–課題
» 社会保障の維持
» 社会インフラの老朽化
» 労働力不足
» 地方の低密度化
13
今後の社会保障改革について
https://www.mhlw.go.jp/content/12601000/000474989.pdf
自治体戦略２０４０構想研究会
http://www.soumu.go.jp/main_content/000562105.pdf

14
あなたの20年後は？
https://www.flickr.com/photos/stephenliveshere/1528409572/

2040年問題
• ITに対する期待感は強い
–医療・福祉サービス改革
» オンライン資格確認（マイナンバーカードが健康保険証）
» PHRの構築
–保健医療分野におけるAI活用推進
–介護ロボット/センサー導入、介護情報の連携・活用
–保育園等におけるICT化推進事業
–地域医療構想
–オンライン診療…
15
社会保障ワーキング・グループ会議資料
https://www5.cao.go.jp/keizai-shimon/kaigi/special/reform/wg1/301112/shiryou1-2.pdf

16
僕のやりたいこと：
いま社会を支えている企業を変革する
https://www.flickr.com/photos/osamukaneko/6305736274/

エンタープライズ
• 「いま社会を支えている企業を変革する」
–存続している企業は社会から求められている企業
–いわゆるエンタープライズ領域
–残念ながらITを活用しきれていない
–彼らが変わるのが、一番影響力がある
• 10年以内に変革が必要
–20年後に間に合うためには10年以内
17

エンタープライズの可能性と課題
• 社会を支えている企業には変革する力がある
–経営者は気付いている
–現場に優秀な人材は多い
–まだ、お金も時間もある
• 具体的に何をしたらいいかは分からない？
–だから、やりながら学んだらいい
–多少の失敗を許容することはできる
» ていうか、どうせ失敗しているわけだし
18

19
課題：「既存」を超える
既存の規則、組織、文化が変革の壁となる

「既存」を超える
• 「既存」を変えるのは困難
–組織全体の慣性にあらがうのはつらい
–というか、そもそも慣性だと気付かない
• 新しい手法が既存の概念で理解してしまう
–言葉を付け替えただけで何も変わらない
–やれても「部門内の最適化」に終始
• 既存の敬意を持ちながら組織全体を変える
20

これからのアーキテクチャ
21

これからのアーキテクチャ
• 一括再構築禁止
• Pub/Sub
• 適切な標準化
• 運用のセルフサービス化
22

一括再構築禁止
• 今のシステムは複雑で
大きすぎる
–一括再構築の現実味はな
くなっていく
• マイクロサービス化
–段階的な再構築
–ストラングラーパターン
–レベル0から始める
» 時間をかけてチームとして
のレベルを上げる
23
https://www.flickr.com/photos/17674930@N07/39039463314/i

Pub/Sub
• 拡張性の確保
–イベントに注目する
» データの状態ではなく変化
» イベントへの対応を拡張可
能にしておく
–もちろん課題もある
» イベントと結果が疎結合
» データの不整合
–今後はReactive
» どこが人間の限界か…
24https://www.flickr.com/photos/legin101/6405770209/

適切な標準化
• 企業には標準化が必要
–長期的な保守性の確保
–MSAの揺り戻し…
• 制約ではなく基盤
–基盤通りにやればロジッ
クに集中できる
–基盤自体もアップデート
25https://www.flickr.com/photos/psd/60375301/

運用基盤
運用のセルフサービス化
• 開発者はアプリではなくサービスを開発する
–運用作業の自動化を通じて、開発者が自力で運用を
行えるようにする取組み ≒ DevOps
–NoOps：運用部門の作業は無くしてもらう
–CI/CD：リリース判定の自動化＝テストの自動化
–汎用化のためのContainer → K8s
26
開発
部門
運用
部門
ｱﾌﾟﾘｻｰﾋﾞｽ
開発
部門
ｻｰﾋﾞｽｱﾌﾟﾘ
DevOpsﾁｰﾑ

余談：Javaでいいんですよ
• Javaはオープンで無償利用が可能です
• 起動が早くなります
–GraalVM
» Java言語でゼロから書き直したJVM
» AOTビルドでネイティブイメージ生成可能
–Micronaut
» 注目のアプリケーションフレームワーク
» コンパイル時のDI/AOP解決
• ますますDevOpsが重要になる
27

これからのアジャイル
28

これからのアジャイル
• リードタイムを計る
• 部門を超えて話し合う
• 全部門のリズムを合わせる
• ストーリーを重視
29

リードタイムを計る
• 企画～リリースまでの時間を重視する
–調整/待ちをゼロにすればいい
–アジャイルは「電車」
» 定期的な開発実施にビジネス側が合わせるほうが効率的
» 運行計画だけ承認し、誰が乗るかは乗車前に決める
» 次がある安心感：曖昧な要件は次の電車に回ってもらう
» ビジネス部門が直接関わればいい＝企画部門いらない
30
企画
立案
概算
見積
稟議
決裁
詳細
見積
要員
計画
実装
&ﾃｽﾄ
ｼｽﾃﾑ
ﾃｽﾄ
品質
検査
ﾘﾘｰｽ
作業
受入
ﾃｽﾄ

部門を超えて話し合う
31
バリューストリームマッピング

全部門のリズム
• 部門横断な要件は困難
–複雑で広範囲な要件をPO
だけで判断するのは困難
–SoR+SoEで価値が出る
• 全部門のリズムを合わ
せる
–推奨：四半期リリース
–全体でアジャイル
» 個別はなんでもいい
32https://www.flickr.com/photos/geoftheref/279567717/

ストーリーを重視
• 価値はストーリーで
–機能で語らない
» もっともシンプルなストー
リーから拡げていく
–ユニバーサル設計禁止
» 誰でも使いやすいものは、
誰にとっても使いにくい
» 最初のファンを見つける
33https://www.flickr.com/photos/markmarkmark/1388768114/

さいごに
34

35
白馬の王子も銀の弾丸もない
https://www.flickr.com/photos/hellie55/3296714569/
https://www.flickr.com/photos/pamwood707/5833028607/
自分の頭で考えろ

36
いま、小さなことを多く積み重ねることが、
とんでもないところへ行くただひとつの道
なんだなというふうに感じています
https://www.flickr.com/photos/russwalker/4713100247/

37
未来のために、我々には
いま、やれることがある
https://www.flickr.com/photos/olivireland/16448886959/

エンタープライズ、アーキテクチャ、アジャイルのこれから

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to エンタープライズ、アーキテクチャ、アジャイルのこれから

Similar to エンタープライズ、アーキテクチャ、アジャイルのこれから (20)

More from Yusuke Suzuki

More from Yusuke Suzuki (20)

Recently uploaded

Recently uploaded (9)

エンタープライズ、アーキテクチャ、アジャイルのこれから