More Related Content
Similar to エンタープライズ、アーキテクチャ、アジャイルのこれから (20)
More from Yusuke Suzuki (20)
エンタープライズ、アーキテクチャ、アジャイルのこれから
- 2. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
自己紹介
• 鈴木雄介
–Graat(グラーツ)
» グロース・アーキテクチャ&チームス株式会社
» 代表取締役 社長
» http://www.graat.co.jp/
–日本Javaユーザーグループ
» CCC運営委員長(初代)
–SNS
» @yusuke_arclamp
» http://arclamp.hatenablog.com/
1
NEW
- 5. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
10年前…
• 日経SYSTEMS 2009年2月号
–特集1「10年後も通用するスキル」
» 今後重要なのは「ユーザーにサービスとしてどのような価
値を提供するのか」という視点だ。この視点で優れた提案
ができるITエンジニアこそ,ユーザーから支持されるよう
になるだろう。
» 10年後<中略>クラウド・プラットフォームを利用したり,
他人が開発したサービスを組み合わたりして,ユーザーの
求めるサービスを作っていくようになる
» よいサービスを提供するためには、常に改善をしていかな
くてはいけない。
4
- 6. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
10年前…
• JJUG CCC 2009 Fall
–クラウドを超えた先の企業システム像
» システム統合パターンの整理
▸ Enterprise Integration Patterns大事
» コンテナ型アーキテクチャの導入
▸ ガジェット型の企業アプリケーション
» インターフェースによる分業
▸ APIを通じて分業し、個別に最適な道具を選ぶ
5https://www.slideshare.net/yusuke/20091008-jjug-ccc
- 7. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
10年前…
• ソフトウェアアーキテク
トが知るべき97のこと
» アーキテクトはシステムをデ
ザインする前に、コミュニケ
ーションについて考えなくて
はいけません。<中略>どん
な人たちが、どんな目的で、
どんなコミュニケーションを
しているのかを知るのです。
» ユーザーと呼ばれる存在のい
ない、コミュニケーションの
総体をデザインする
6
2009/10/5
https://ソフトウェアアーキテクトが知るべき97のこと.com/エッセイ/システム
ではなく-コミュニケーションをデザインせよ
- 8. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
10年前…
• ITアーキテクト 最終号
–これからのITアーキテクト
/開発者のあり方
» システムの価値は本来、「社
会におけるユーザーの価値を
どれだけ高めたか」によって
測られるべき
» ITアーキテクトは、システム
の外側へ、システムが置かれ
た環境へと目を向ける必要が
ある
7
- 9. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
10年前…
• (続き)
» ITアーキテクトは開発者だけではなく、ユーザー、経営者
、さらには取引先や消費者など、システムの外側にいる専
門家たちを相手にする。
» そして、彼らの価値観を調整することで、初めて真に良い
システムを設計することができる。
» 「システムがどのような環境で使われるのか。そして、シ
ステムが何をもたらし、何を変えていくのか」ーーこの視
点を持つことが、これからの時代に必要なことなのだ。
8
- 10. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
10年前…
• DevLOVE2009
–「開発を愛する僕らが目を向けるべき、ソフトウェ
ア以外に大事な5つ4つの事」
9https://www.slideshare.net/yusuke/devlove2009-4
- 11. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
余談:JJUGの6年 →会長退任
• 方針:金は調達するから、あとは好きにして
• JJUG CCC
–1000名以上、20代~30代:70%、初参加:30%
–海外スピーカーセッション:10枠/57枠
10
- 14. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
2040年問題
• わりと確定した未来
–2025年以降は「現役世代の
急減」にシフト
» 団塊ジュニアが65歳以上に
–課題
» 社会保障の維持
» 社会インフラの老朽化
» 労働力不足
» 地方の低密度化
13
今後の社会保障改革について
https://www.mhlw.go.jp/content/12601000/000474989.pdf
自治体戦略2040構想研究会
http://www.soumu.go.jp/main_content/000562105.pdf
- 16. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
2040年問題
• ITに対する期待感は強い
–医療・福祉サービス改革
» オンライン資格確認(マイナンバーカードが健康保険証)
» PHRの構築
–保健医療分野におけるAI活用推進
–介護ロボット/センサー導入、介護情報の連携・活用
–保育園等におけるICT化推進事業
–地域医療構想
–オンライン診療…
15
社会保障ワーキング・グループ 会議資料
https://www5.cao.go.jp/keizai-shimon/kaigi/special/reform/wg1/301112/shiryou1-2.pdf
- 17. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
16
僕のやりたいこと:
いま社会を支えている企業を変革する
https://www.flickr.com/photos/osamukaneko/6305736274/
- 18. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
エンタープライズ
• 「いま社会を支えている企業を変革する」
–存続している企業は社会から求められている企業
–いわゆるエンタープライズ領域
–残念ながらITを活用しきれていない
–彼らが変わるのが、一番影響力がある
• 10年以内に変革が必要
–20年後に間に合うためには10年以内
17
- 19. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
エンタープライズの可能性と課題
• 社会を支えている企業には変革する力がある
–経営者は気付いている
–現場に優秀な人材は多い
–まだ、お金も時間もある
• 具体的に何をしたらいいかは分からない?
–だから、やりながら学んだらいい
–多少の失敗を許容することはできる
» ていうか、どうせ失敗しているわけだし
18
- 21. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
「既存」を超える
• 「既存」を変えるのは困難
–組織全体の慣性にあらがうのはつらい
–というか、そもそも慣性だと気付かない
• 新しい手法が既存の概念で理解してしまう
–言葉を付け替えただけで何も変わらない
–やれても「部門内の最適化」に終始
• 既存の敬意を持ちながら組織全体を変える
20
- 24. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
一括再構築禁止
• 今のシステムは複雑で
大きすぎる
–一括再構築の現実味はな
くなっていく
• マイクロサービス化
–段階的な再構築
–ストラングラーパターン
–レベル0から始める
» 時間をかけてチームとして
のレベルを上げる
23
https://www.flickr.com/photos/17674930@N07/39039463314/i
- 25. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
Pub/Sub
• 拡張性の確保
–イベントに注目する
» データの状態ではなく変化
» イベントへの対応を拡張可
能にしておく
–もちろん課題もある
» イベントと結果が疎結合
» データの不整合
–今後はReactive
» どこが人間の限界か…
24https://www.flickr.com/photos/legin101/6405770209/
- 26. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
適切な標準化
• 企業には標準化が必要
–長期的な保守性の確保
–MSAの揺り戻し…
• 制約ではなく基盤
–基盤通りにやればロジッ
クに集中できる
–基盤自体もアップデート
25https://www.flickr.com/photos/psd/60375301/
- 27. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
運用基盤
運用のセルフサービス化
• 開発者はアプリではなくサービスを開発する
–運用作業の自動化を通じて、開発者が自力で運用を
行えるようにする取組み ≒ DevOps
–NoOps:運用部門の作業は無くしてもらう
–CI/CD:リリース判定の自動化=テストの自動化
–汎用化のためのContainer → K8s
26
開発
部門
運用
部門
アプリ サービス
開発
部門
サービスアプリ
DevOpsチーム
- 28. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
余談:Javaでいいんですよ
• Javaはオープンで無償利用が可能です
• 起動が早くなります
–GraalVM
» Java言語でゼロから書き直したJVM
» AOTビルドでネイティブイメージ生成可能
–Micronaut
» 注目のアプリケーションフレームワーク
» コンパイル時のDI/AOP解決
• ますますDevOpsが重要になる
27
- 31. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
リードタイムを計る
• 企画~リリースまでの時間を重視する
–調整/待ちをゼロにすればいい
–アジャイルは「電車」
» 定期的な開発実施にビジネス側が合わせるほうが効率的
» 運行計画だけ承認し、誰が乗るかは乗車前に決める
» 次がある安心感:曖昧な要件は次の電車に回ってもらう
» ビジネス部門が直接関わればいい=企画部門いらない
30
企画
立案
概算
見積
稟議
決裁
詳細
見積
要員
計画
実装
&テスト
システム
テスト
品質
検査
リリース
作業
受入
テスト
- 33. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
全部門のリズム
• 部門横断な要件は困難
–複雑で広範囲な要件をPO
だけで判断するのは困難
–SoR+SoEで価値が出る
• 全部門のリズムを合わ
せる
–推奨:四半期リリース
–全体でアジャイル
» 個別はなんでもいい
32https://www.flickr.com/photos/geoftheref/279567717/
- 34. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
ストーリーを重視
• 価値はストーリーで
–機能で語らない
» もっともシンプルなストー
リーから拡げていく
–ユニバーサル設計禁止
» 誰でも使いやすいものは、
誰にとっても使いにくい
» 最初のファンを見つける
33https://www.flickr.com/photos/markmarkmark/1388768114/
- 36. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
35
白馬の王子も銀の弾丸もない
https://www.flickr.com/photos/hellie55/3296714569/
https://www.flickr.com/photos/pamwood707/5833028607/
自分の頭で考えろ
- 37. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
36
いま、小さなことを多く積み重ねることが、
とんでもないところへ行くただひとつの道
なんだなというふうに感じています
https://www.flickr.com/photos/russwalker/4713100247/