今から始める、Windows 10＆新.NETへの移行戦略
Upcoming SlideShare
Loading in...5
×
Like this presentation? Why not share!

Like this? Share it with your network

Share

今から始める、Windows 10＆新.NETへの移行戦略

  • 315 views
Uploaded on

2014/11/29 第7回 業開中心会議 にて ...

2014/11/29 第7回 業開中心会議 にて
https://itmedia.smartseminar.jp/public/seminar/view/663

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post
    Be the first to comment
No Downloads

Views

Total Views
315
On Slideshare
217
From Embeds
98
Number of Embeds
5

Actions

Shares
Downloads
0
Comments
0
Likes
3

Embeds 98

http://ufcpp.wordpress.com 96
https://feedly.com 16
https://twitter.com 10
http://feedly.com 2
http://digg.com 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 「元々打診を受けているテーマとしては」…なのだけども…
  • 業務系の人に対してこれだけは最初に言わないといけないけども、ほんと、変えたくないなら変えなくていい。不連続のない開発体験。
    「だいたい」ってのは、例えば、「.NET Native相手だと極端なReflectionコードは動かないことがまれにある」とか「Win32呼び出しとかしてると.NETの範疇外だしどこでもは動かないよ」とか、そういうレベル。
  • 「元々打診を受けているテーマとしては」…なのだけども…
    「指針」の話が中心になるかなぁと
  • そんな最先端な話題でもなくて。
    ツールとかプラクティス化が充実してきて、ちょっと前だったら小規模にしかできなかったことが、大規模にできるようになってきた。
    こなれてきた。何せ、もはや、GitHubすら設立から6年とか経ってる(2008年設立)。
  • この辺り、近々サンプルをgithubに上げると思う。

    厳密には、string interpolationのカルチャー指定可能なバージョンの文法が4.6以降専用になると思う(System.Runtime.CompilerServices.FormattedString依存)。
    あと、Await in catch/finallyは.NET 4 + Bcl.Async (拡張ライブラリ)でも動く。
  • どっちでもいい。性能が変わらない限り、書いてる本人の好みで書かせて上げて。
    で、C# 6.0の各種新文法はほんと性能も変わらないものばっかり。
    もちろん、「知らないだけの人に教えてあげる」スタンスはいいんだけど。知ってて使ってない人に強制しても仕方ない。
  • Client Profileがある程度。Full .NET Frameworkと比べると完全なサブセット。
  • いつまでたっても古いバージョンから抜けれない理由もこれ。
    新機能使いってだけで、バージョンは上げれない。業務だと、バージョン上げると全行程テストし直しとかで大変なんでしょ。
  • これまでも、この方向に向かう傾向はあった
    MS公式提供品もオープンソース開発、個別NuGet配布してたり(System.Collections.Immutable, System.Reflection.Metadata, System.Numerics.Vectors, System.Reactive, System.Net.Http)
    MS外のライブラリを推したり(Json.NET)
  • 具体的な手順は別途たぶんブログ化する。
    kpm build でライブラリ .kproj を .nupkg 化できる
    NuGet参照をプロジェクト参照に切り替えるのは、global.jsonのパス指定書き替える or コピペでsrcフォルダー以下にソースコード持ってくるだけ
  • 今年一番のニュースかもね
    http://blogs.msdn.com/b/somasegar/archive/2014/11/12/opening-up-visual-studio-and-net-to-every-developer-any-application-net-server-core-open-source-and-cross-platform-visual-studio-community-2013-and-preview-of-visual-studio-2015-and-net-2015.aspx
    http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx
    http://blogs.msdn.com/b/dotnet/archive/2014/11/20/one-week-of-open-source.aspx
  • 長期的に見てその方がもうかる算段なしでオープンソース化とかやらない。
    といっても、日本だとOEM売りが強すぎてサブスクリプション型の収益への移行遅れがちみたいだけども。
  • ここ数年言われ続けてることだけども。
  • 一時期、HTML5全振りな感じだったけども、今また結構.NETが面白い時期になってきた。
    まあいったん、非Windows環境にかなり注力するフェーズになるとは思うけど、Windowsを捨てるのかみたいなことにはならないと思う。
  • これも、ダメだったから戻ってきたんじゃなくて、大きく振らなきゃいけなかった過渡期を過ぎた。「両方」をやれる時期に来た。
    ちなみに、.NET 2015世代には、WPFのアップデートもある。
  • 仕事用のソリューション: 社外の人との協業。外注先がMacだった。Windows機買ってもらう前にtryしてみたとか。
    C# 6.0: コンパイラー担当してる人が結構仕事早いみたい
  • libuv: Node.jsが使ってるクロスプラットフォームなWeb Serverライブラリ
  • HTTPである必要すらない: ゲームとかのインタラクティブな通信で、「最初とりあえずHTTP long pollingでさらっと作っちゃって、パフォーマンス的に厳しそうなら自前でTCPで通信層書こう」とかもできる
    ミドルウェア挟むのも楽: ルーティングの分岐とかも楽。新旧フレームワーク混在で、あるフォルダー以下は新フレームワークで処理、みたいなことも書くの楽。段階移行とかもしやすいはず。
  • 依存を減らす技術: データアクセス層技術で poco (Javaでいう pojo) が受けるのもそういう事情。Plain = 何にも依存してない。
    幅広いプラットフォーム: 例えばの話、Webゲーからスマホゲーへの時代の変化についていけずに大変なことになってる会社もあるわけで。差し替えで別プラットフォームに移行できるってので、レイヤー化・モジュール化された構成大事
    業務系のWebだって、「あの技術もう古臭いから死んでほしい…」とかぼやきながら「枯れた技術」を使い続けるわけで。
  • まあまだまだ「理想は」だと思うけども。
    着実に進歩はしていってると思う。
  • 2枚前のスライドで見ての通り、OWINのFuncの戻り値がTask。OWINでも、戻り値がTaskってのがポイント高くて。
  • http://blogs.msdn.com/b/bharry/archive/2014/11/12/news-from-connect.aspx
    オープンソースに紛れ気味だけども、Connect()での発表、結構な分量がVSOがらみ。
  • TracとかJenkins、Gitとか使った開発管理サービスを提供してるところ結構あるし。「CIサービス」とかで検索すると出てくるサービス増えた。
  • あと、サービス間連携とか。VSO自体API公開してて、他のサービスが参照できる

Transcript

  • 1. 今から始める、Windows 10＆新 .NETへの移行戦略 岩永信之
  • 2. 本日のテーマ Windows 10 & .NET 2015を見据えて  今すぐに対応できること  .NET 2015までに準備すべきこと  おすすめの開発指針
  • 3. まずなによりも、業務系において  .NETは「変えないこと」の大切さをわかってる 既存のアプリ 既存の.NET (.NET 4.5) 既存の.NETで動いてたなら だいたい※動く .NET vNext (.NET Core 5) • 事前Native化 • SIMD演算対応 • モジュール化 • ソースコード配置 既存の.NETの 延長 (.NET 4.6) .NET 2015世代の新機能 はランタイムの内部で 頑張ってるものが多い • アプリの変更少なく • アプリの適用範囲が広がる ※ ReflectionとかInteropとかで変なことしていなければほぼ
  • 4. あらためて、本日のテーマ Windows 10 & .NET 2015を見据えて  今すぐに対応できること  .NET 2015までに準備すべきこと  おすすめの開発指針 割と、 「何かやることあったっけ？」 と言いたいレベル • Microsoftの組織変化 • .NETチームの開発体制変化 .NETを使う側も参考にすべき指針に
  • 5. キーワード  “One .NET” Open  Every developers  Cloud
  • 6. 互換性 本題の前に、どう「変わってないか」の話を 「変えないこと」の大切さをわかってる
  • 7. .NET Frameworkと.NET Core  .NET 2015 .NET Framework ASP.NET 5 ASP.NET 4.6 WPF Windows Forms .NET Core ASP.NET 5 .NET Native Innovation • モジュール化 • オープンソース • Agileリリース • エコシステム • クロスプラットフォーム ASP.NET 5 for Mac and Linux Common Runtime Next gen JIT SIMD Compilers .NET Compiler Platform Language innovation NuGet packages .NET Core 5 Libraries .NET Framework 4.6 Libraries Compatibility • 既存デスクトップ • 既存サーバー ポイント 既存のものには下 手に手を入れない ポイント 既存環境にも最新の アプリ開発モデルをポイント 可能な限り旧環境にも オープンソースの成果を pull-req 受付 back porting とはいえ、4.6どころか…
  • 8. .NETのサポートOS OS サポート期限.NETのバージョン Windows Server 2003 2010/7/13 2.0 R2 2015/7/14 4 Windows 7 / Windows Server 2008 R2 2015/1/13 2020/1/14 3.5.1 4.6 Windows 8 / Windows Server 2012 2018/1/9 2023/1/10 4.5 4.6 上段: メインストリーム 下段: 延長 現実的に多そう なのはこいつ？ 上段: 標準インストール 下段: サポートする最新バージョン 業務におかれましては、サポート期限ギリギリのOSで、標準 インストールのバージョンの.NETでないと使えないことも 多々あるかと思われます
  • 9. VS 2015でも、2.0, 3.5開発できます 古いバージョンのVisual Studioとの共存も可能 今はクライアントOSでもHyper-V動くし 実機開発でも、Visual Studio 2015はWindows 7に入る 「Windows 7だからVisual Studio 2008で開発」とかやめて
  • 10. .NET 2.0でもC# 6.0使えます  C# 6.0  Getter-only auto-property  Expression bodied function  Using static  Null-conditional operators  String interpolation  nameof  Index initializers  Exception filters  Await in catch/finally 割と単純な構文糖衣ばっかり ライブラリ依存の機能なし .NET 2.0で動く .NET 4.5で動く 「Windows 7だからC# 3.0」とかやめて
  • 11. 統制 統制取りたいから新機能使わせたくないって？  Privateな部分にうるさく言ってもしょうがない  C# 6.0が影響するのはprivateなところばかり int X(int x) { return x * x; } メソッドの外から見えてる情報 はここだけ(変わってない)  ここがレビューしにくいなら、何か別の問題あり  メソッド1個1個が大きすぎるとか  変数名がちゃんとついてないとか int X(int x) => x * x;
  • 12. まとめ 既存のものは下手に触らず、新しい試み 古い環境向けのアプリも、最新のC#, .NET, Visual Studioで
  • 13. “One .NET” 「縦割り」の改善 1つのエコシステム
  • 14. “One” 今年に入ってから、“One”(1つになろう)を標語にしてる  “One Microsoft”  縦割り組織の改善  PC向けOSとモバイル向けOSで社内で争ってる場合じゃない  1つのOSコアに  1つの開発モデルに  1つのストアに  .NETも“One .NET”
  • 15. “One .NET” 以前(.NET Framework) 現状: Profileベースのフレームワーク .NET for Windows Desktop .NET for Windows Store .NET for Server BCL※ Runtime BCL WinRT Interop BCL Runtime Runtime • ターゲットごとに違うフレーム ワーク(大きな赤枠)があって • 「どのフレームワークならどの クラスが使える」みたいなルー ル(Profile)を定めてる • 1つのインストーラーで全体の インストール • 多くのクラスがmscorlib.dllの中 WPF ASP.NET ※ Base Class Library
  • 16. 問題: Profileの種類 現状はまだそこまで多重保守になってない  Desktop = Server  Store = Desktopのものに小細工して使ってる でも、これから  .NET Native, Cloud-optimized .NET  Xamarinとももっと協業して、Mac, Linux, iOS, Android • (小細工でなく真に) 違うものになるかもしれない • バリエーションも増える • しかも、あとからどんどん追加で増える可能性も
  • 17. 問題: 全体をまとめて アップデートが大変 mscorlib 例えば: System.Xmlに脆弱性が 見つかりました！ 全部のアプリがSystem.Xml使ってるわけじゃないけど • 直接はもう使わないのに… • 間接的にも使ってない確証得られない… mscorlibを使っていることには違いないし • バージョンアップしなきゃ！ • テスト全部やり直し！ • 多大な工数が！
  • 18. “One .NET” (.NET Core)  .NET Core 5 Windows Desktop Windows Store Server WinRT Interop WPF ASP.NET パッケージ管理 (Ecosystem) BCL Runtime Xamarin .iOS Xamarin .Android … • 細かい単位に分けて、NuGetベース で必要な分だけ、必要なバージョ ンを参照 • 利用者がプラットフォーム選択で あれこれ悩む必要ない • NuGetパッケージの仕 組みを拡大 • BCLとNuGetパッケージ とプロジェクトを区別 しない • 実行環境自体もパッケージ管理の 仕組みを使ってside-by-side配布 one modularity agile in control 目標: 1つのエコシステムの上で、必要とされる部分を、素早く、制御可能な形で提供
  • 19. “One .NET” になることで  .NETを利用する側として覚えておくといいのは  ターゲット指定の改善  ライブラリ参照管理の改善  パッケージ単位のコード解析・補完
  • 20. ターゲット指定(旧): Profile選択ベース Portable Class Library: ターゲットを自分で選ぶ 共通部分 共通部分 これだけ使える ターゲットを増やすと 使える部分が減る
  • 21. ターゲット指定(新): 依存関係ベース パッケージ管理: 何に依存しているかでターゲットが決まる System.Runtime System.Collections.Generic System.Linq System.Net.Http System.Threading.Tasks Microsoft.Win32.Registry My App 1 My App 2 どこでもは使えなさそうな ものを参照すると… ターゲットに制限がかかる ターゲット指定は1st パーティ製ライブラリだけがやればよくなるはず
  • 22. ライブラリ参照(旧): .csprojプロジェクト形式 参照管理の仕組みがバラバラ BCL参照プロジェクト参照 .csproj内NuGetパッケージ参照 <Reference/>タグ .csproj内 <ProjectReference/> タグ packages.config + .csproj 内 <Reference/>タグ
  • 23. ライブラリ参照(新): .kprojプロジェクト形式  JSON (project.json)でプロジェクト設定を管理※ "dependencies": { "Newtonsoft.Json": "", "System.Console": "", "Classlibrary1": "" NuGetパッケージ参照 BCLアセンブリ参照 .sln内プロジェクト参照 } "4.0.0-beta-22231", (必要ならバージョン を明示的に指定) ※ 補完が効くし、ツールチップヒントも出る GUIでの参照設定もちゃんとできる
  • 24. 区別がなくなることで 例えばこんな開発フローが 1. 作ったアプリの中から共通利用できそうなところ抜き出す 2. 別プロジェクト化 3. それをNuGetパッケージ化して配布 4. 他のプロジェクトでMyGet越しでパッケージ参照 5. 他のプロジェクトからソースコードに手を入れる必要でてきたら git cloneしてプロジェクト参照 プロジェクト→ NuGetパッケージ化 NuGetパッケージ参照→ プロジェクト参照
  • 25. パッケージ単位のコード解析・補完 今までの問題: 文脈読まずにコード補完  例: コードスニペット 依存関係プロパティ • XAML系プロジェクト • プロパティが書ける文脈でしか使わないのに これから: パッケージ単位で配布可能  .NET Compiler Platformを使って作ったコード解析をNuGet配布  ライブラリにコード解析を同梱可能  例えば…  JSONライブラリに、文字列リテラル中のJSON解析を付ける 常に出る
  • 26. パッケージ単位のコード解析・補完 NuGet配布の例 自作のコード解析 自作のコード解析 が参照されてる コード解析が結果 (警告+ 書き替え)
  • 27. まとめ 全部入りインストーラー→ 個別パッケージ配布に  制御可能な形で、素早く提供 「パッケージ化」を意識した開発を
  • 28. Open Source .NET全体のオープンソース化
  • 29. .NETのオープンソース化  .NET全体をオープンソース化※  .NET Home : 各プロジェクトへのリンクとドキュメント  .NET Core  以前からオープンだったもの  .NET Compiler Platform  ASP.NET  Entity Framework  コミュニティプロジェクトへのリンクも  Mono Project  JSON.NET  … ※ といってもまだ途中。随時公開中
  • 30. オープンソース化の理由 クロスプラットフォームを維持可能な形で実現 コミュニティの活性化 新しい顧客の取り込み  既存顧客にとってもコミュニティが広がることはメリット  「Linuxで動かせるなら.NETをもっと活かせる」という要望は多い
  • 31. もちろんビジネス構造の変化もあって Windowsの会社→ Azureの会社  Azureのデータセンターを使っていただけるなら、その上のOSは WindowsでもLinuxでも パッケージ売り→ サービス売り  Offide 365, Share Point, Dynamicsなどや、Azure上の各種サービスを使って いただけるなら、クライアントはiOSでもAndroidでも  Visual Studio Online  VS Onlineを使っていただけるなら、クライアントはEclipseでもSublimeで も
  • 32. 日本の業務系でも: 大手にとっても 社内フレームワークが足かせになってはいないか  同じような機能ならオープンなものに勝てない  「オープンだから使ったことある」って人の調達と、1から社内フレー ムワークを覚えてもらうのと、どっちがコスト低いか  ググって出てこないものを使えない人  自社で作ったものもOpenな方が外注調達コスト下がってトータルで見 てお得になるかも
  • 33. 日本の業務系でも: 開発者個人にとっても 自分自身の身元保証  開発者求人とか、とりあえず「コード見せろ」 中小だと法人でも同様、身元保証  聞いたこともないような会社、中身見えなくて誰が応募するのか
  • 34. 業務系でも現実的なレベルになってきた Control  頻繁に更新されると動作保証ができない  → バージョン管理で「変えない」こともできる Governance  誰がコードの責任を持つの？  → 統制自体はマイクロソフト、.NETチームが責任持ってやってる  Discoverability  身元のはっきりしないコードは使えない  → どこの製品かまで含めて検索できる こういうソースコード管理、 パッケージ管理、開発工程管理 の仕組みがだいぶ充実してきた
  • 35. まとめ オープンソース化  信用の獲得  コミュニティの活性化  いろいろあったオープン化の課題は技術で解決されつつある  オープン化前提で成り立つビジネスモデルに移行
  • 36. Every developers Every applications .NETをすべての開発者に
  • 37. 多様なアプリケーション  .NETは元々適用範囲広いし Server Client On-premise Cloud Web Site Web Service HTTP Sockets GUI CUI Stand Alone Connected Desktop Mobile Mouse Keyboard Touch Windows Linux iOS Mac Android .NET Micro Framework 「AかBか？」→ 「AもBも！」 、これからさらに広がる
  • 38. 過渡期 一度大きく振らないと行けないことはある A B  新しいチャレンジの際の過渡期 最終的には間に落ち着いたり、両方半々になったり A AB B A & B  成熟の証  結局、全部ほしくなる この状態に対して 「既存顧客を捨てるのか」とか 「そんなの流行らない」とか 言っちゃダメ 「ほらダメだった」とか 「やっぱり戻ってきた」とか 言っちゃダメ
  • 39. Windows 8 → 10 Windows 10  デスクトップ回帰  エンタープライズ回帰 Mouse Keyboard Touch 制限なしWPF 審査付き セキュアWinRT エンタープライズ コンシューマー WinRT Windows 10 Windows 10 Windows 8 Windows 8
  • 40. 今はターゲットを広げる時期 協業  Xamarin, Docker サポートOS  Linux, Mac  Android, iOS(Xamarin) Web Server  IIS 開発環境  Visual Studio, Xamarin Studio, OmniSharp
  • 41. 選べる大事さ: 開発環境 Windows環境  これからもVisual Studioは非常に強力な開発ツール  Visual Studio Communityエディション  非商用、学術・研究向け、オープンソースへの貢献用途には無料提供 非Windows環境  Xamarin Studio そもそもIDEみたいな仰々しい仕組みがいやなら  OmniSharp - Cross platform .NET development  Sublime, Emacs, Vimなど向けのC#プラグインを提供
  • 42. 補足: Xamarin Studio VS側最近機能が結構使える※  NuGet Package manager  Shared Project  T4 template  PCL (個人の経験で言うと) Visual Studio以外を全く想定してなくて 割かし最近の機能をふんだんに使って 仕事用のそこそこの規模のソリューションが 普通にMac上でのXamarin Studioでビルド通せた  ちなみに、C# 6.0は、公式サイトで仕様が出てくるたびに即座に対応  Discussionに情報が出た数日内にはMonoに関連コミットがあったり ※ むしろLegacyな機能の方が怪しい… フルパス指定が必要だったり、 パス中の と/ で困ったり
  • 43. 選べる大事さ: Runtime, Webサーバー ASP.NET 5は階層化、モジュール化された構造  いろいろ差し替え、選択できる Runtime (何で.NETコードを実行するか) .NET Core 5 .NET Framework 4.6 Mono Web サーバー(何でHTTPを受け付けるか) IIS (Helios) libuv (Kestrel) 自作(Self-host) Loader (ソースコードの読み込み) C#/VB (Roslyn Loader) 自作※ 非Windows ※ 例えば、F#サポート用のLoaderのサンプルあり
  • 44. 選べる大事さ: OWIN※ Webサーバーとアプリケーション間のインターフェイス仕様 Func<IDictionary<string, object>, Task>  環境変数、リクエスト、レスポンスをDictionaryを使ってやり取り  どのキーにどの値を入れるかを規格化†  非同期(Task)  BCL提供の型しか使わない どこででも、何ででも動く • Webサーバーが何でもいいのはもちろん HTTPである必要すらない • アプリの下にミドルウェア挟むのも楽 ※ Open Web Interface for .NET † objectのままだと使いにくいので、適切なキーで適切な型でとりだせるラッパーライブラリあり(Microsoft.OWIN)
  • 45. 補足: 依存を減らす フレームワーク、サーバー、OSへの依存を減らす  (ASP.NET 5みたいな)差し替え可能なモジュール提供  (OWINみたいな)標準ライブラリのみへの依存  (MVC, MVVMなどの)分離しやすいアーキテクチャ  Modelの比率を増やすよう頑張るべき 依存を減らすことで  幅広いプラットフォーム対応  変化への対応 依存を減らせる技術は 積極的に取り入れるべき しなきゃいけない？
  • 46. 補足: 依存を減らす フレームワーク、サーバー、OSへの依存を減らす  (ASP.NET 5みたいな)差し替え可能なモジュール提供  (OWINみたいな)標準ライブラリのみへの依存  (MVC, MVVMなどの)分離しやすいアーキテクチャ • 開発者は本音では新しいものを使いたい • できないのは、入れ替えのコストが高いから • そのコストが下がるのならば…  Modelの比率を増やすよう頑張るべき 依存を減らすことで  幅広いプラットフォーム対応  変化への対応してもいい！
  • 47. 補足: Taskクラス  Taskクラス(await/async)は依存切りに使いやすい  Model中心の設計、Modelの比率向上しやすい Model ※ StatelessなWebだとこういう処理にはなりにくいものの、 WebSocket使った双方向通信とかだと同じような処理あるはず Taskクラスなし(イベント駆動) UI Click Model 処理開始 User void OnClick(sender, args) View側からのClickイベントで処理を始める UI await 処理開始 User Task AwaitClick() Model側から Clickイベント待ちをする※ Taskクラス利用
  • 48. まとめ 今はターゲットを広げる時期 レイヤー化、モジュール化、選べる大切さ  パーツごとに差し替え可能な構成  変えたいときに、変えたい場所だけ変える
  • 49. Cloud 自社の開発にもCloudを 自前で物理的なものを持たない世界
  • 50. Connect()にて Connect()での発表のうち、結構な量がVisual Studio Onlineがらみ  Release Management Service  Application Insights  Sneak Peak  Web based editing  Build service  Code search
  • 51. クラウド化 製品にCloudサービスを使うというのはもちろん  仮想マシンもAzure VMやAWSに置いたり  PaaSを使ったり: SQL Database, Service Bus, HDInsight, Media Services, etc. 自分達のインフラもCloudに  Visual Studio Online  MyGet  GitHub お客様への納品物はだいぶクラウド化したのに、 自分のことになると「医者の不摂生」してないか
  • 52. Microsoft自身も 開発サービスを提供する側だけども  Azure, Office 365 API, OneDrive API  Visual Studio Online すべてを自社でまかなわない  GitHubでソースコード公開  BCLパッケージ配布にMyGet※ を利用 エコシステム提供  3rd パーティ製サービスもAzure StoreのAdd-onsに並べられる ※ NuGetパッケージのホスティング、CIサービス
  • 53. まとめ 自分達のインフラもクラウド化  医者の不摂生になっていないか すべては一社で完結させない  自社の得意のところは自社で  そうでないところは外部と連携  Gitは避けて通れないかも  Git間の履歴移植は楽らしいので、一度以降してしまえば次は楽かも
  • 54. 全体まとめ  “One .NET”  パッケージ化、制御可能な形で個別に素早く提供 Open  信用の獲得、コミュニティの形成  Every developers  広いターゲット、変えたいときに変えたいモジュールだけ変える  Cloud  自社の得意なところは自社で、そうでないところは外部と連携