読者です 読者をやめる 読者になる 読者になる

arveltのソフトウェア技術メモ

Arvelt's software technology memo

Developer Summit 2014にいったときのメモ

memo report
2日とも行ってて、聞いたことひたすらメモってたのでその供養。 ・公開分のまとめはここからみる http://codezine.jp/article/detail/7640 ・気になったキーワードとか プロビジョニングツール。pupet、chef、ansible コンテナ作るやつ。Docker モバイルクロスプラットフォーム開発できるXamarin ゲームのUnity3D a developer role focused on testabilityのSET、a role that puts testing firstのTE。開発するためのテストなのか、品質のためのテストなのか。 「小さなチーム、大きな仕事完全版」「リーダブルコード」は読んでなかったので読む。あと「経営戦略全史」面白そうだった。 SSLってなんだっけ・・・ OpenStackとCloudStackは結局どっちがいいんだ Kinect進化してる。Oculus RiftはUnity用のSDKがあったりする。 ドメイン駆動設計をちゃんとやることの難しさ。ちゃんとやったことで得られるメリット。 ・以下は自分のメモ。見なおすかはぶっちゃけ微妙。 ・2/13日分 ◯サーバプロビジョニングのこれまでとこれから(宮下剛輔) pupet chef ansible Infrastracture as Code  サーバーの状態を定義して実行すると用意してくれる  冪等性を有する Test-driven infastructure テスト駆動インフラ  インフラを記述したコードを書く、それをテストする  serverspecはインフラの状態をテストするためのツールではない、  インフラの状態を記述したコードをテストするためのツール  >違いがわからん インフラCI Immutable Infrastructure  動かないサーバーに手は入れない、  新しく用意したサーバーに切り替える。  変更に伴うトラブルが起きにくい  よって継続的改善がしやすくなる  The Twelve-Factor App  IX. Disposability  Immutableにできないところはどうするのか   ケース・バイ・ケース Contanir Base Deploment  単機能・軽量なVM  コンテナをまるごとアップロードして差し替える  →Docker  Iaas上じゃなくてもイミュータブルインフラにできる。  Mesos/YARN等との組み合わせで自動的にリソース配置を最適化できるようになるかも Orchestration  コンフィグレーション+単一のサーバで完結する   ApacheやNginex  オーケストレーション複数のサーバ   ロードバランサにノード追加   MuninやMagiosへのノード追加   アプリケーションデプロイ  旧来のオーケストレーション   イミュータブルではない   サーバの増減が頻繁でない   Command&Contraoll  新しいオーケストレーション    イミュータブルな世界   サーバの増減が多く発生   Autonomy、自立強調する  Serf   ロードバランサが自動でサーバを組み込む   機能 ノードのクラスタリング    ゴシッププロトコルベース    イベントプロパゲーション   オーケストレーションをSerfにまかえることでコンフィグレーションがシンプル これから  テスト駆動インフラ   BootstrappingにDocker   Pupput、Chef   Serverspec   Mesos/Yarn   SERFでオーケストレーション  ◯エンタープライズHtml5 Html5が作り出す新たな世界  Html5認定試験  可視化技術は限りなく進歩する   頭に思い描くものを可視化したいというものも含む  KendoUI  Nvidiaのアクセルレーター  Creative+ITの能力が圧倒的な優位性を作る  Webプログラミング、Webデザイン、サーバーのスキルの融合 フロントエンジニアに対する企業のスキルニーズの分析 Html5によって  デバイスや言語の技術的なインパクト  誕生した市場と、淘汰された市場、  ついていくひと、置いて行かれる人  DENAの例   フロントエンジニア(ECサービス    Html5が望ましいスキル、にある   フロントエンジニア(ソシャゲ    Html5を使用している、と明記    フォトショなどの操作が、望ましいスキルにある。  どういうスキルが理想になるのか   システム+デザイン=フロントエンジニア  「機能的なものが美しいのではない、美しいもののみ機能的である」(丹下健三 Html5がSIに与えた衝撃、エンジニアは何を学ぶべきか テクノロジとしてのHtml5  Html5パラダイムシフトである ムーブメントとしてのHtml5  実現方法の変化   WebブラウザとJavascriptの進化   ソフトウェアアーキテクチャの変化  ユーザビリティの変化   マルチデバイス   アクセシビリティ  プレイヤーの変化   電子書籍のフォーマットに採用 マイクロソフトが起こした破壊とは  ソフトウェアライフサイクルの考え方の変化 Appleショックは何を与えたのか  プラグインベースRIAがなくなっていく 開発プロセスツールの不在  HTML5はプラットフォーム側から始まった プラットフォームへ依存しない開発手法 ツールの選定  Grunt,YEOMAN  VS、SENCHA、Wijimo、ColdFusion ミドルウェアとしてのWeb標準への理解 エンタープライズ特化のHTML5カンファレンス Html カンファレンス 2014でぐぐるのおすすめ ◯ビジネスアプリケーションとつながる「Heroku1」のご紹介(相澤歩)  Force.com CLI  Force.com Client Library   gem dotenv  Heroku Connect ◯社内システムの構造と設計、実装のはなし(田籠聡) Dev Of Ops, by Ops, for Ops 社内システムほど他システムとの連携を考える 社内システムではJSONAPIを使う WebAPI制限 →トラフィック、レスポンスタイムへの負荷のせい OpenWebAPI  コストは誰が払うのか  互換性は 社内システム  機能>性能  Long Life Cycle  TargetUser:自分 何が問題か  情報と権限の分断  情報と機能の冗長化  UXの欠如  自動化の障壁  全部入り:アップデート不可能  社内システム連携   DB直接接続   SOAP   CORBA   SOA   RPC 社内システム連携をシンプルに  権限、分断を最小限に  機能、情報には複数の参照方法  モジュール化   単機能システムを連携させる   アップデートが容易な状態を保つ 社内システムほどほかシステムとの連携を考える  機能をAPIとして公開する  API互換性   プロコトル   データ構造   意味の一貫性   クライアント要件の普遍性 プロコトル  IDL  SSH  HTTP,JSON 優先度ハック 逆優先度ハック  今いらないなら後でやる 必要なところから必要な時にやる アーキテクチャの割り切りが開発・運用を加速する 開発・運用の前提がアーキテクチャをシンプルにする ビジネスへのインパクト  社内システムほど試しやすい場はない  顧客は自分 ◯iOSAndroid、百花繚乱モバイル開発環境を比較する(細川淳) 普通の開発環境  Android   Java   AndroidStudio/eclipse  IOS   Objective-c   Xcode  純正のメリット   最新機能に対応している   情報が豊富  純正のデメリット   環境・言語の強制   それ以上のものは提供されない  Html5+javascript   例    PhoneGap    Sencha Touch    Titanium   利点    人を集めやすい   問題    技術者のレベル差が大きい    チューニングに長けている人と、そうでない人の差が激しい   Webサービスのモバイル展開におすすめ   Sencha Touchがおすすめ  Script+Frameworl   例    Python+Kivy    Ruby Motion    Ruboto     Android用    Adobe   利点    LL言語を使える    Flasherが活躍できる   問題    AdobeAirは遅い気味    Python/Ruby     Ios/Android両対応しているFrameworkが存在しない   WebAPI経由のアプリなどにおすすめ   AdobeAir    Flasherが喜ぶ  Mono   例    Xamarin.iOS、Xmarin.Android    Unity3D   利点    .Net Frameworkが使える    C#が使える    Unity3D、3Dゲームに向いてる   問題    .NET Framework    Xamarin、GUIがネイティブ    UnityのGUI、NGUIとか使う(癖ある   一般的なアプリにはXamarinにおすすめ   ゲームにはUnity3Dがおすすめ  Naitive   Delphi/C++Builder/Firemonkey   例    Nativeである   利点    IOS/Android双方ともNativeになる。速い    OS APIにシームレスにアクセス    Firemonkey     GUIも1ソースで作れる     2D/3D対応     DIPフリー     Style機構   問題    AndroidではNaitveであることは推奨されない    Delfi    Styleの調整(PixelPerfect    IDEWindows専用(Windows On OsX   一般的なアプリにおすすめ  一般的なアプリには   Xamarin  エンターテイメント   Unity3D ◯成功と失敗の狭間に横たわる2つのマネジメント(中村洋) 期待マネジメント  関係者が互いに持っている期待を明らかにし、適切に調整する モチベーションマネジメント  関係者のやる気を安定して目標に向かうようにする なぜ今この話か  意思決定が遅れると置き去りになる世界  単なるタスクではなく、課題の発見から始める  偉い人が全てを知っているわけではない 期待マネジメントとは  「ここまでやってくれるはず」というディスコミュニケーション  ドラッカー風エクササイズ   1.自分は何が得意なのか    プログラミングやテスト、積極性とか自分の武器   2.自分はどうやって貢献するつもりか    得意なことで貢献するには、ゴールを理解している必要がある   3.自分が大切に思う価値はなにか    家族お金キャリアコードなどのこだわり   4.チームメンバーは自分のにどんな結果を期待していると思うか    お互いの期待を表明してすり合わせる  誰と期待をすり合わせるのか   関係者全員  一度やればOKか?   ずっと一緒とは限らない   定期的な確認がいる  事例   顧客との期待マネジメント  「言わなくてもわかってくれる」はない   計測できるもので見せる必要がある モチベーショマネジメントとは  モチベーションの特性   何気ない一言で乱高下する  人によってトリガーが違う  周りは手助けできるだけ、自分自身でマネージメントするしかない  成長しやすい土壌を作る   自分の調整と相談、無理なときにはすっぱり諦める  日によってパフォーマンスが違う、しかし、良いプレイヤーは不調な時期が短い  褒めるのではなく一緒に喜ぶ  その先にある光景を語る  若手のチームで頻繁なふりかえり   Good!を出しまくった  成功体験が少ないという問題  事例     指示待ち   自分たちでやることを考える   WHYから始めようより、ゴールデンサークル。    Why, How、What   まずは少しだけやってみる    自分たちで改善できるようになる   客の顔が見えない    組織の外にロールモデルを求めてもいいのでは まとめ  期待を表明しあうということ  関係者のやるきを目標に向かわせること  Actionしよう!   1,周囲への期待を明らかにしてみてください。周囲からの期待をきいてみてください。   2,自分を含めたメンバーそれぞれのモチベーションの源泉を考えてみてください ◯Mobageを支えるテストエンジニアリング(中川勝樹) Mobage Open Platform  モバゲでゲームを公開できる仕組み QAチーム立ち上げ背景  プラットフォームのグローバル展開  大規模システムの拡張とリファクタリング  デリバリーのスピードを落とさない  検証属人性の解消 方針  Endo-to-Endテストを確立する  テストを徹底的に自動化する  テストしやすい環境を提供する テストしやすい環境  単体テストのREDが消えない問題  リリース頻度・速度・影響範囲のバランス  テスト時間のコスト問題  CIの必要性 なぜ独立したチームにしたか。  横串チームによる、戦略的横展開 SWETってなにか  Software Engineer in Test. Google Testing Blog How Google Tests Software(書籍  SET   a developer role focused on testability  TE   a role that puts testing first SETs primary focus is on the developer DeNA SWET = SET + TE  Developer Productivity  Quality Assuarance SWET Group Mission Statement  Keep the quality of Platform  Improve the quality and productivity of Platform エンジニアとして  テスト対象の開発が行えること  テスターではなく、テストエンジニアであること SWETの仕事とは  サーバーサイトテスティング  クライアントテスティング テスト戦略  誰がテストをするのか   デベロッパーテスト   受け入れテスト  どんなテストか   単体テスト   結合テスト  どうやってテストするか   ブラックボックス   ホワイトボックス   グレーボックス  何をテストするのか   機能テスト   非機能テスト WebAPIのテスト  HTTPとJson  グレイボックスフィクスチャ   DBやキャッシュの状態を操作したりする  特定のターゲット   ローカルDNSを使用する  特定ドメインのクライアント Web/mobileアプリのテスト  HTTPとUI  SeleniumWebDriver  エージェント切り替え  特定ドメインのクライアント  ページオブジェクトパターンを使用せず、ドメインエージェントパターン的なことをしている  モバイルエミューレーション クライアントSDK  SDKを使ってテスト用のアプリを作る  それをテストする  UI自動化  複数デバイスサポート  テストケースの一貫性   Calabash   Appium 結合テスト  通知機能のテスト マルチセッション  ゲームとユーザーで違うテストクライアントが使用できるようにしておくことで、結合テストがしやすくする ◯「ITエンジニアに読んでほしい!技術書・ビジネス書大賞」LT大会(白石俊平/高橋征義/吉田健吾/和田裕介(選考委員))(角征典) 経営戦略全史 小さなチーム、大きな仕事完全版 リーンスタートアップ無駄のない企業プロセスでイノベーションを生み出す アジャイルサムライ なぜ、システム開発は必ずモメるのか リーダブルコード ・2/14日分 ◯Webの現在過去未来(竹迫良範/和田裕介/宮川達彦OpenID 認証と認可 ネイティブアプリ  プラットフォームにお金払えば、純粋にコンテンツだけで勝負できるという世界 電子書籍  個人デベロッパーが直接書籍を販売できる Iosのニューススタンド デバイスやリテラシーを選ばないメール プラットフォームロックインのサービス github等を使った書籍の執筆とか オライリーが実験している書籍作成のインタラクティブ化 ◯暗号破りに新たな攻撃!進化する脅威に対抗するためのWebサイトセキュリティとSSLの進化(林正人) 電子証明書  SSLサーバ証明書  コードサイニング証明書  セキュアメールID SSLサーバ証明書  SSLを支える技術   Webサーバ運営団体の実存性の証明。公開鍵暗号。Ex(RSA,ECC,DSA   暗号鍵   暗号の世代交代の必要性   暗号の世代交代で考慮すべきこと    暗号強度とユーザビリティのバランス  具体的なアクション   SHA-2の導入   !RSA(SHA-2)を利用するウェブ管理者はSHA-2にあと3年以内にSHA-2への移行を済ませなければいけない  ECCについて コードサイニング証明書  !RSA(SHA-2)を利用するウェブ管理者はSHA-2にあと2年以内にSHA-2への移行を済ませなければいけない Webサイトへの攻撃  被害拡大中  分業化専業化により、攻撃者も高度化  さまざまな攻撃手法  Struts2脆弱性の事例、SQLインジェクションの事例  脆弱性のギャップ   安全性についてチェックしたことがある企業は多くない  脆弱性の対策   各工程でセキュリティを考慮する ウェブアプリケーションファイアーウォール  プロクシ的に間にいて防御する ◯アプリケーションエンジニアのためのクラウドインフラ再入門(司会:吉田雄哉/輿水万友美/曽我部崇) クラウドを使う開発が多くなり、アプリ開発者は低レイヤーを学ぶ機会が減っている OSSクラウドを駆逐するソフトウェアを通じて  クラウドの基礎的な理解  クラウドを活かすソフトウェアの設計 OpenStack  ブラックボックスは怖い  PrivateCloudをうまく使うと便利でお得  できること   AWSみたいなインフラを構築できる  特徴   OSS   コンポーネント  使うメリット   クラウドサービスの設計理念がわかる   スケールアウト性能の高いソフトウェアの作り方がわかる   プライベートクラウドを構築できる  事例   プライベートクラウド    CiscoPaypalGREE   パブリッククラウド    IO.Cloud、RackSpace、HP、GMOインターネット  始め方   VM上のUbunt,CentOSとかにインストール   devstackを使う  最新動向   Heatコンポーネント    複数インスタンスで構成されるシステムをtemplateで一括deploy   Celiometer    課金に必要な利用状況を集計する    プライベートクラウドでも状況を知るのに使える   OpenComputeProject  日本OpenStackユーザ会   勉強会   ハッカソン   コードリーディング CloudStack  特徴   OSS  できること   AWSのような仮想インフラの作成  CloudStackの機能   AWS EC2/EBS/S3とほぼ同様  アーキテクチャ   管理サーバを中心とした集中管理  日本CloudStackユーザー会 DeNAにおけるゲーム以外の新規事業の立ち上げ方(沖津貴智) もの作りの進め方  スクラム守破離 スクラムの基本を忠実にこなすだけだとコストが高い  コストの大きい部分   バックログ、バーンダウンチャート、スプリントプランニング  工夫してみたこと   専任のスクラムマスターをやめる   タスクの粒度は荒く   バーンダウンチャートは排除   タスク管理は各チームやりやすい方法  少人数体制   プロディーサ1名   エンジニア1名   UI/UXデザイナー1名  座席   チーム単位で座席おく  結果   各人が考えて行動している感じが強くなった   少人数かつ裁量を増やすことで帰属意識   デイリースタンドアップ、プラニングと振り返り兼ね、PDCA早い  人が増えたら   進捗遅延、意思疎通など、従来通りの問題が起きてくる ものづくりアンチパターン  一生懸命考えたけどユーザは使ってくれない  ヒアリングしてみて必要そうだったから作ったけど使ってくれない  ユーザは本当は何がほしいのか 事例  チラシル   練馬の主婦を集めて、プロトアプリをインストールしてもらい、リモートでヒアリング  アプリゼミ  Peko  ※Facebookログインする?って聞いても半分はNoというが、実際使わせてみると8割ほどは使用する UserTesting.comおすすめ 技術面の話  サーバーアプリケーション構成   リードエンジニアが好きに使いたいフレームワークミドルウェア  通信プロコトル   JSON-RPC over Http   JSON over Http  インフラ   自社のデータセンター   コスト優位な部分ではAWSも使用  スケーラビリティ   新規サービスはあたるかどうかわからないので、スモールスタートしたい   どんな小さく始めるとしても確保は必須  インフラの基本構成   疎結合+多重化  サービスの規模によって要検討   データベースの垂直分割   データベースの水平分割(シャーディング  インフラ特化型の共通モジュール   Baranモジュール  さらなる高速化   Mbaas   Parse,Google Mobile Backend Starter  Github Enterprise   全員が各リポジトリをWatchしてる   エンジニア・デザイナー間コミュニケーション    画像リソースやりとりをGithubEで  IOs?Android?   まずどちらかのみ注力し、当たりそうならもう片方もやる  対応IOS   最近はIos7専用多い  対応Android   Android2.3以降サポート  Iosよく使われるライブラリ  Androidよく使われるライブラリ  通知   ユーザ間のコミュニケーションスピードが年々早まっている  分析用ロギング   かなり重要   アナリティクス、Flurry  分析プラットフォーム  ログ出力のポイント   APIアクセスログ   アプリ起動ログ   画面ごとの表示ログ(画面遷移、離脱ポイント   サービスごとに必要なポイント(入会とか  プロモーション   リリースしたけど何も起こらない  ある程度ユーザを流入させて数字をみる  FacebookAd/TwitterAdが比較的使用しやすい  FacebookAd広告クリエイティブ   キャラ系、人物系、アプリのUI系   事例だとUI系がうけよかった  オフラインプロモーション In US   飲み屋でおねーちゃんにアプリを進められる 一年たってみて  余計なこと考えずに問題に向かう  ひたすらフィードバックと改善をする  銀の弾丸はない ◯モーションセンサーの現状と2014年の予測(中村薫) なぜセンサー  センサー価格の低下  Web,モバイルに続く価値 デジタルサイネージ 空中ディスプレイ 現実世界へのインタラクション  階段+マッピングKinect さまざまなセンサー  全身   Kinect   Xtion/Carmine   KinectV2  指先   Creative Senze3D   Leap Motion NUIの先駆け Creative Senze3D  開発会社がAppleに買われた 2014年度の予測  新しいデバイス   ストラクチャーセンサー   MIO  センサーの内蔵化が進む   Leap Motion   Intel Perceptual Computing SDK  3Dプリンタのモデル化に内蔵センサーとかが生かされる未来? もっと未来  モバイル   IOsやAndroid対応のセンサーが発売される  Web   Webやクラウドと背サーの連携が進んでいく  ウェラブル   センサー、モバイル、ウェアラブルの融合   Meta Pro   Oculus Rift 出力装置の進化  入力が3Dなら出力も3Dにする Oculus Rift Demo  Unity3Dで動かせる ◯Play2/Scalaドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所(吉村総一郎) ニコニコ生放送Scalaで書き話している話 なぜ書き直すのか?  技術的夫妻   PHPが300万行   コピペ1万   潜在的不具合4500   循環複雑度600   リフレクション多用しgrep不能  循環ド複雑度600度   終盤のジェンガ   通常は50でテスト不可能 なぜこうなったのか?  要件と締め切り優先で、内部品質やプロセス品質をおろそかにしている体制  人員が増えていったが、パッチワーク的修正が大量 このような状況に対して打ち出した緊急対応  各人のタスクを見える状況にした  いらない機能を削って保守コストを下げる  個人開発から開発体制へ移行してチームで開発をする  長期案件、突発対応、改善活動の3つのチームに分割し、安定して改善活動を行う 3ヶ月間の対応の結果  休出ストレス減った、ストレス減った、離職減った ニコ生2の開発  スケーラブル  安定性・フォールトトレラント性  保守性・拡張性  パフォーマンス プロトタイプ作成をしながら2週間に一度ショーケースで紹介  10月で初期リリース、12月で大規模配信 Play2/Scalaでの大規模開発 なぜScala  Java,Scala,PHP,Ruby  保守性の観点から性的型付け言語  プロトタイプを作ったメンバーはJava/Ruby/関数型色々使えたのでScalaでも問題なし PHPしか知らない人がScalaをやるにあたってネックになる知識   アルゴリズムとデータ構造    PHPにはarrayしかないとか    対策:勉強会、プログラミングコンテストチャレンジブック   純粋関数型プログラミング    無理に適用しない    ベターJavaとして使う   ValとVar    Valを徹底    可変コレクションは扱わない    徹底しても困らない    サーバーでメモリリークが発生しなくなる   Implict    ライブラリ層を除き利用しない    Implicit converterを使うと負債になりがち    ImplicitがあるとPullRequestのレビューでわかりにくい   並行プログラミング    Actorのトラブル解決で必要   JVMJavaライブラリの仕組み    やりながら学ぶ    1理詳しい人がいればなんとかなる ニコ生2のアーキテクチャ  インフラメンバーにデイリースタンドアップに参加してもらった   コミュニケーション重要   インフラの制約などを確認  クラウドではなくオンプレミスという選択   IOパフォーマンス   費用   社内方針として    人材確保と教育が問題  DBの水平分割と垂直分割   MySQL   水平分割    IDの中にシャードIDやデータタイプを組み込んで、シャーディングしやすくしている    Instaram,Pinterest,TwitterSnowflakeなどを参考にしている  2つのキャッシュ   中央RedisとローカルRedis  冗長化方法   MySQLはMHA   RedisはSential  アプリケーション構成  Websocketアプリ1インスタンスで5万ユーザーの視聴管理を実現   NginxとNetty   REST APIからWebsocketを利用することで接続コストがさがった   パフォーマンス測定    Gatling    Node.jsのプラグインを自作した  ドメイン駆動設計を実施するために徹底したこと   ユビキタス言語   モデルを使って議論する   レイヤードアーキテクチャ   正しいモジュール化を行い、変更時に読まなきゃいけないコードを減らす   エンティティと値オブジェクトの使い分け  Play2はDDDを実践するのに良いフレームワーク   CoCがきつくない   マルチプロジェクトで依存関係を作れる   CaseClassが便利  エリック・エヴァンスドメイン駆動設計に入る前に読んでもらいたい本が多い   Youtubeに上がっているDebLovで津元さんがDDDを解説した動画が素晴らしい  ユビキタス言語   近い座席、会議  DDDを実践する価値   DDDではないコードの例を考える  ユビキタス言語が導入されると、同じ言葉で会話できる  コードと要件について話している言語の乖離が少なくなり、リファクタ性能が上がる   ドメイン層  アプリケーションの運用とチーム開発  Capistranoによるデプロイ   Playの設定のテンプレート  コード規約   Scala Guide / Effective Scala  開発環境   Intelij Idea Ultimateに統一  JenkinsでCI/CD運用   検証期間の工数を削減できた  Play2の問題点   Sbtが遅い   Play2のテンプレートが、コンパイル遅く、文法がデザイナーにやさしくない   objectとtraitがテストで困る スクラムの導入  ウォーターフォール開発、アジャイル開発  アジャイル導入までつらみ   ガントチャートが好き   啓蒙活動   マネジメント問題の根本はアジャイルウォーターフォールが関係ないことが多い  スクラムはリーダーを育てるのに素晴らしい開発手法   会議体が固定   JIRA/GreenHopperなどのツール   書籍が充実    アジャイルサムライ、アジャイルな見積もり、ドラッカーのマネジメント  スクラム開発の課題   コミニュケーションコストが高い   メンバーの要件定義の能力が身につきにくい   要求や要件が深いコンテキストがドキュメントにまとまることがすくない  ニコ生のスクラムで重要していること   ユーザーの要求理解に対して時間をかける   ストーリーポイントを小さくする   密なコニュニケーションのストレスを減らす   スクラムマスターが常にプレイングマネージャーであれるようにする   ゆとりを持った開発計画   規格と相談するときには、不確定な時期と優先順位と一緒に持ち込む   インフラチームやほかチームおの合同作業は共同バッファを用意する まとめ  Play2は大規模でも使える  Play2はDDDしやすい