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

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/

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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

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

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

Más de Yusuke Suzuki

Más de Yusuke Suzuki (20)

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