デブサミ2010 これからのアーキテクチャを見通す

Developers Summit 2010 1

【19-C-1】これからのアーキテクチャを見通す

グロースエクスパートナーズ株式会社ビジネスプラットフォーム事業ゼネラルマネージャーチーフアーキテクト

日本Javaユーザーグループ幹事 / 日本Springユーザー会幹事

鈴木雄介

自己紹介

鈴木雄介75年生まれ

グロースエクスパートナーズ（株）ビジネスプラットフォーム事業ゼネラルマネージャー/チーフアーキテクト

アークランプブログhttp://www.arclamp.jp

JJUG/JSUG幹事日本Javaユーザー会/日本Sptingユーザー会

97本監修『ソフトウェアアーキテクトが知るべき97のこと』

これからのアーキテクチャを見通す

いま、何が起きているのか？

▲ 20.0

▲ 10.0

95 96 97 98 99 00 01 02 03 04 05 06 07 08 09

受注ソフトウェア売上伸び率

経済産業省「特定サービス産業動態統計調査」

成熟期

▲ 20.0

▲ 10.0

95 96 97 98 99 00 01 02 03 04 05 06 07 08 09

派遣受入れ従業者（人日）

8.5% 8.2%

経済産業省「特定サービス産業動態統計調査」

▲ 20.0

▲ 10.0

08/1 08/5 08/9 09/1 09/5 09/9

リーマンショック後

-3.0%-9.7%

衰退期？

http://www.flickr.com/photos/29007475@N08/3218110963/

労働集約的産業生産要素のうちの労働と資本の組み合わせにおいて、労働者一人当たりの設備など固定資産額の小さい産業

http://kotobank.jp/word/労働集約的産業

Developers Summit 2010 9http://www.flickr.com/photos/eqqman/76493361/

「クライアントために」は手工芸。産業としては原始的なありかた

http://www.flickr.com/photos/24443965@N08/3286611736/

世界は変わった。受託開発が産業として衰退期を迎えつつある。市場縮小＝人員削減。

いま、何が起きているのか？

これから何が起きるのか

自家発電のための機械を売ろう

発電所を運営して電力を売ろう

トーマス・エジソン（1847年-1931年）

サミュエル・インサル（1859年-1938年）

電力のユーティリティ化は技術がなければできなかった。しかし、経済合理性がなければ進まなかった。

http://www.flickr.com/photos/plastique/4021279909/

ニコラス・G・カー『クラウド化する世界』翔泳社、2008年

いかに早く作るか

いかに長く使うか

いかに早く作るか開発生産性の向上動くコード質の良いコード

http://www.flickr.com/photos/emciek/2683598052/

いかに長く使うか運用保守性の向上変化に素早く対応する質の良いサービス

「Force.comの開発効率はJavaや.NETの5倍」

開発生産性が5倍（＝早く作れる）ではない。

長く使える、と理解すべき・必要な分だけ作る・開発/本番環境の準備が必要ない・サービスの管理が容易・ユーザー数の変化にはすぐに対応可能

http://www.itmedia.co.jp/enterprise/articles/0905/18/news087.html

Force.comの開発効率はJavaや.NETの5倍――Nucleus調査

ただし制約があるデータ転送量/速度

専用言語/専用ツール/専用APIセキュリティ

http://www.flickr.com/photos/greendragonflygirl/3387375487/

クラウドに移行しない理由

セキュリティの懸念:46%

制御できないこと :39%

コスト :36%

既存インフラ投資 :32%

性能懸念 :31%

レガシーシステムおよび統合懸念:26%

http://www.thehostingnews.com/cloud-computing-adoption-survey-results-released-12517.html

Cloud Computing Adoption Survey Results Released

何かを得れば、何かを失う。そして何ものをも失わずに次のものを手に入れることはできない。

- 開高健

開発の現場に産業革命がおきる。新たな価値感は新たなアーキテクチャによってもたらされる。当然、失うものもある。

これから何が起きるのか

これからのアーキテクチャを見通す

いかに長く使うか運用保守性の向上変化に素早く対応する質の良いサービス

本当に我々は変化に適応できるのか？

オブジェクト指向

構造要素

サービス/機能

ソフトウェアの基本構造

変化する”コト”

変化しない”モノ”

クラスA クラスB クラスC ユースケースA

ユースケースB

散乱（scattered）

もつれ合い（tangled）

責務

散乱ともつれ合い散乱：複数のクラスを横断するような変更もつれ合い：ユースケースに共通のクラスへの変更

DI（依存性の注入）

利点・構造要素間の関係を外出しできる

ただし、・インターフェースの変更に対応できない

・依存性が複雑になると管理が煩雑になる

アスペクト指向

利点・クラスを変更せずに後から処理を追加できる

・クラスに横断する関心事を扱える

ただし、・アスペクト間の依存に影響を受ける・クラスの変更に影響を受ける

・予見できる変化にしか最適に変化できない

・柔軟性を上げるには複雑にするしかない（DI、アスペクト…）

・人の経験や認識力に強く依存する

オブジェクト指向の限界

萩原正義『アーキテクトの審美眼』翔泳社、2009年

アジャイルプロセス

構造：変化しにくく、長く残るプロセス：変化しやすく、後に残らない

江渡浩一郎『パターン、Wiki、XP ―― 時を超えた創造の原則』 2009

デザインパターンからXPへパターンの適用対象を設計からプロセスへ

動的平衡にはエネルギーが必要

http://www.flickr.com/photos/ralphunden/3380101930/

・変化しやすいが維持しにくい・スケールしない（教育が必要）・人の経験や能力に非常に強く依存する

アジャイルの限界

結論：変化に適応するのは難しい

オブジェクト指向とアジャイルプロセスは優れた手法だが、それだけでは足りない

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

構造の不変性を利用し、変化の影響を管理する。→モジュール

変化の方向を管理する。→プラットフォーム

モジュール変化の影響を管理する

http://www.flickr.com/photos/rltherichman/4241350513/

モジュールとは

実装の追加情報をメタデータとして持ち、内部の実装方法を隠蔽する。（コンポーネント）

追加情報の例：バージョン、呼び出しの事前/事後条件、呼び出しのポリシー定義、依存性など

Java用のモジュール管理基盤。モジュール＝バンドル

採用プロダクト・Eclipse・アプリケーションサーバ・Spring DM/iPOJO…

ただのアーカイブファイル

Aバンドル

バージョンベンダー公開依存

OSGia.Foo[1.3.0,2.0.0]

a.Foo1.0

a.Foo1.1

a.Foo2.0

バージョンを利用したクラスロード解決

モジュールの可能性

・これまでの開発手法は流用可能・より”疎”を実現。部分単位の入れ替えを可能に・SOAはモジュールの一形態として捉えられる

・時間軸上での再利用が可能・変化の影響を管理できる

プラットフォーム変化の方向を管理する

http://www.flickr.com/photos/saturnism/195649679/

プラットフォームとは

狭義：アプリケーションソフトを動作させる際の基盤（OS、ミドルウェア）

広義：ソーシャルグラフ上でコミュニケーションをするための基盤

エンタープライズソーシャルアプリケーションソーシャルグラフを前提に、ユーザー同士がコミュニケーションを行うためのアプリケーション。のエンタープライズ適用

ベース的プラットフォーム

横断的プラットフォーム

ベース的プラットフォームの例。特定のプラットフォームを前提とした埋め込み式のものが増えている

ガジェット/ウィジット

Facebook アプリmixiアプリOpenSocial（Google）

覇権抗争中

GoogleガジェットW3C WidgetsOpenAjax Metadata/iWidget

Chatter by SFDC

横断的プラットフォームの例。

すべてのデータが喋り出す。データ（ネタ）を中心としたコミュニケーションなので時間軸の中で流れていくが、論点がブレない。

http://japan.cnet.com/news/media/story/0,2000056023,20367358,00.htm『ニコニコ動画から見える第3世代のナレッジマネジメント論--「コト」「人」の次は「ネタ」』

ナレッジマネジメント（KM）の変遷 … 文書共有を中心としたグループウェアなどの第1世代ナレッジマネジメントを「Document Centric KM」、第2世代であるQ&Aコミュニティーやソーシャルネットワーキングサービス（SNS）など情報を持っている人を中心としたものを「Human Centric KM」 … 動画共有サイトのニコニコ動画や初音ミクをはじめとしたVOCALOIDシリーズの製品などがネット上で流行している現象をKMの第3世代「Neta Centric KM」ではないかと仮説をたてる。

吉川日出行氏

デブサミ2008講演より

プラットフォームの可能性

・既存システムは流用可能。価値向上・横断的機能を緩やかに分離可能・時間軸上での再利用が可能・変化の方向を管理できる

プロセスとアーキテクチャは補完的である

Architecture

http://www.flickr.com/photos/seandreilinger/1247300270/

アジャイルとアーキテクチャの補完関係

その他のトピックス

並列化（GPGPU）スレート端末（Android）ソリューション型OSS（BI,オンライン会議…）空間情報システム（a.k.a GIS）

何かを得れば、何かを失う。そして何ものをも失わずに次のものを手に入れることはできない。

- 開高健

Developers Summit 2010 58http://www.flickr.com/photos/dingo_x/3721358864/

あなたはどこにいますか？

デブサミ2010 これからのアーキテクチャを見通す

Technology

Oracle WebLogic Server アーキテクチャ

デブサミ関西2011 JAZ紹介

デブサミ2009: iPhone開発者座談会

ICHIGAN 参照アーキテクチャ

オペレーティングシステム i386 アーキテクチャ (2)

デブサミ2008 .NETの仕組み

IA-32 インテルアーキテクチャデベロッパーズマ … インテル ® アーキテクチャソフトウェア・デベロッパーズ・マニュアル中巻A：

TDD研究会デブサミ2012 コミュニティLT

デブサミ2012にいってきたよ。 - takigawa401

デブサミ関西2013 「ソーシャルゲームのデータサイエンス」

オペレーティングシステム i386 アーキテクチャ (1)

オペレーティングシステム i386 アーキテクチャ (3)

デブサミ2015 オフィシャルコミュニティ募集要項

インテル IA-64 アーキテクチャ・ソフトウェア・デベロッ …ii インテル® IA-64 アーキテクチャ・ソフトウェア・デベロッパーズ・マニュアル

デブサミ2014 個人スポンサー募集要項

DevOpsから見たテスト自動化と価値の見える化（ …KPIの見える化：アーキテクチャ 15 LOGSTASH extract monitor transformJenkins pull Syslog push load ・Functional

ソフトウェア工学からコンピューターサイエンスへ（デブサミ2014）

組織能力とアーキテクチャの適合仮説‐全体の見取 …...組織能力とアーキテクチャの適合仮説‐全体の見取り図ものづくりの組織能力

デブサミ関西2012 B-3

【17 e-7】デブサミ2011要求開発アライアンス