Scala/Scrum/DDD 困ったこと50連発ガトリングトーク！！
•
19 likes•11,433 views
2017/7/27に開催されたセプテーニ・オリジナル / オプト / CyberZ合同イベント「Scala/Scrum/DDD 困ったこと50連発ガトリングトーク！！」の発表資料です。 イベントページ: http://scala-scrum-ddd-gatlingtalk.connpass.com/event/34172/
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Scala/Scrum/DDD 困ったこと50連発ガトリングトーク！！
Similar to Scala/Scrum/DDD 困ったこと50連発ガトリングトーク！！ (20)
Recently uploaded
Recently uploaded (9)
Scala/Scrum/DDD 困ったこと50連発ガトリングトーク！！
- 1. Scala/Scrum/DDD 困ったこと50連発ガトリングトーク！！ 2016年 7月 27日 株式会社セプテーニ・オリジナル ／ 株式会社オプト / 株式会社CyberZ 1
- 4. セプテーニ・オリジナルの場合 当然のように金の弾丸 【セプオリ標準機】 15inch Macbook Pro Retina 2.5GHz SSD512GB 標準構成 + CPU増強 + SSD増量 = ¥272,800 4Scalaコンパイル遅い - セプテーニ・オリジナルの場合(発表者:杉谷)
- 5. optの場合 5Scalaコンパイル遅い - optの場合(発表者:岡田) とくにCIに時間かかって困っている。。 色々やってはみたが満足のいく結果は得られず ・複数コンテナで、sbtプロジェクトを並列にテスト => 共通プロジェクトのビルドに時間かかる ・masterと差分のあるプロジェクトのみビルドするsbtプラグイン 作った => 共通プロジェクトのビルドに時間かかり、効果微妙 ・コンテナ追加(Circle CI) => リードタイムは減らない
- 10. 解決法 Driver / Executorのどちらで実行されるかを意識する // 各ExecutorNodeで一度だけ実行される lazy val unserializableObj = createUnseriarizable() // DriverNodeで一度だけ実行される val serializableOneObj = createSeriarizable() sc.parallelize(1 to 1000).map(v => { // RDDの操作の処理はExecutorの中でレコードの数だけ実行される val temporaryObject = createTemporary() exec(unserializableObj, serializableOneObj, temporaryObject) }).saveAsTextFile("s3://my-bucket/object") 10Sparkでserializableじゃないオブジェクトを転送してしまう - opt(発表者:柴田)
- 13. どういう事？ - 例えばHaskellのEitherは右側優先 - Functorのインスタンスなのでfmap関数が使える - Monadのインスタンスでもあるのでbind演算子も 利用可能 - つまり、do記法の中でスイスイと利用可能 13Scala標準のEitherが使いにくい - opt(発表者:杉泊)
- 16. ほうほう、それで？ - 一方でScalaのEitherは左右を平等に扱う - Either自体にはmapやflatMapメソッドが定義され ていない - leftメソッド、rightメソッドで〜Projection型にして mapやflatMapを使う事はできるが…… - これらの結果はEither型を返してくる - つまり、for記法内での束縛やガードが使えない！ 16Scala標準のEitherが使いにくい - opt(発表者:杉泊)
- 22. どういう事なの？ - Scalaz./の導入でエラー情報を良い感じに返せ るようになったよ！ やったね！ - でも関数の中にはOption型の返り値を返すもの もあるよ！ - その2種類の関数を組み合わせて使う必要が出 てきたよ！ 22異種のモナドをまとめてシンプルに扱いたい - opt(発表者:杉泊)
- 27. 異種のモナドをまとめてシンプルに扱いたい - opt(発表者:岡田) 27 shapeless・・・型の力を活かしてboilerplateを排除できたりす る（悪名高い）便利ライブラリ 例えばLabelledGenericを使うと、case classに値を追加して 別の型のcase classにcopyみたいなことが(runtime reflection使わずに)書ける
- 28. 28異種のモナドをまとめてシンプルに扱いたい - opt(発表者:岡田) コンパイル時間のトレードオフがあることを理解する。 （そも そもちゃんとモデリングしよう） 使えるじゃん！ =>コンパイル時間が増大しすぎてやめた。。。
- 30. 30 読みにくいと思ったScalaコードは、背景にある概念やパター ンを自分が知らないだけなことも割とあった（個人の感想） Cake pattern, Type classes, Magnet pattern, Monad, etc... 知らないイディオム・パターンは学習しよう。（ただし、そのパ ターンを使わずに綺麗に書けないかどうかは意識する。） クリスマスプレゼントに金槌をもらった子どもは、何でも叩きたがる。 (金槌の法則 ―― ジェラルド・M・ワインバーグ) Scalaコード読みにくい問題 - opt(発表者:岡田)
- 33. Intellijに聞いてみる (Akkaのサンプル) ・1にsecondsなんてメソッドない ・「actor ? ○○」 って何？ ・（timeoutはどこで使われてる？） →Intellijに聞いてみましょう 33doc見てもこんなメソッド定義されてないよぅ（implicit conversion）- opt(発表者:柴田)
- 34. Implicit conversionは Ctrl + Shift + Q (Linux) ・1はDurationIntに変換されてるらしい。 34doc見てもこんなメソッド定義されてないよぅ（implicit conversion）- opt(発表者:柴田)
- 35. Implicit parameterは Ctrl + Shift + P (Linux) ・?がtimeoutをimplicitで使ってるらしい。 （言うまでもないが「?」はactorのメソッドでドットと括弧が省略されてる） （ちなみにこのactorもActorRef → AskableActorRef へ変換されている） （sender()もimplicit parameterだが、ここではデフォルト値なので無視） （vim/emacsはどうすればいいですか？ → 知らんがな） 35doc見てもこんなメソッド定義されてないよぅ（implicit conversion）- opt(発表者:柴田)
- 36. 発表 困った!! No. Option.get / Try.get 36 8
- 37. 何のためらいもなく、普通にOptionやTryのgetが使われているこ とがある。 37Option.get / Try.get -セプテーニ・オリジナル(発表者:杉谷) 対策 OptionはScalaで初めて遭遇したという場合が多く、扱い方と重要 性を認識できていない、ということが殆どだった 見つけた場合 ● 想定していないケースを考慮することの重要性 ● 異常パターンがあるからOptionやTryになっている ● getOrElseやmapやfor式で扱う等のやり方を示す などを丁寧に共有している
- 39. Scala初心者の頃に書いたコードは辛みが多い。ある程度はボーイスカウト ルールで解決するが ● Objectの乱用 ● DB操作などFutureを使うべき場所がベタ組み など辛みが続く失敗はできるだけ防ぎたい。 39初期のScalaのコードが辛い - セプテーニ・オリジナル(発表者:杉谷) 対策：オーバーウォッチチーム BitBucketプラグインの”Workzone”による自動レビュアー追加機能をつかっ て、社内で発生するPRにオーバーウォッチメンバー（杉谷やかとじゅん氏等）が 自動参加。アドバイスを行う。
- 41. playframework 2.2だったGANMA!を2.5にするとき死ぬほど大変 だった 41playframeworkのバージョンアップが辛い - セプテーニ・オリジナル（発表者:杉谷) 2.2 -> 2.3（あんまり大変じゃない） ○ コマンドが play -> activator。 ビルド・デプロイ周りを修正した。 ○ MigrationGuideに従うだけであんまり苦労しない 2.3 -> 2.4、2.5（超大変) ○ Java8化 。Java8環境でパッケージ作成 → Java7環境にデプロイ → 死 ○ DI導入。 Objectを使いまくっていると死ぬ。import play.api.Play.currentでお 茶を濁せるが、2.5でdeprecated指定 ○ anormの文法ががっつり変わる。ConnectionPoolがHikariCPに変わり、設定 も挙動もがっつり変わる ○ GlobalSettingsが滅ぼされる ○ confの記述が結構変わる
- 42. 実際にやったときの大変さ ● なんだかんだで1ヶ月くらい修正にかかった ● 全てのファイルが書き換わった ● 現行コードの修正は日々進むので git pullっては2.5化する 日々 ● リリース時に問題は大量に発生した ○ 意外とコード本編の移行は問題はあんまりなかった。 ○ 殆どはconfの構造変更時の移植ミス。confの記述が変わるからと、ついでにリ ファクタリング（環境別に1ファイル → ファイルを分割してincludeする方式）に したのがまずかった… 得られた教訓 フレームワークの更新は素早く小刻みにやりましょう！！！ 42playframeworkのバージョンアップが辛い - セプテーニ・オリジナル（発表者:杉谷)
- 44. DAO実装のボイラープレート化- セプテーニ・オリジナル（発表者: 木村) 44 (困った) scalaプロダクトが2,3個立ち上がったところで、同じような実装をし ていることが検出された (解決) DAOの実装コード/テストコードを自動生成できないかを模索し、 具体的なストレージ技術に依存しない(ただし、JDBC依存)自動生 成ツールを企画・開発 sbt-dao-generator - 2つのプロダクトで動作中(3プロダクト目検討中) - テーブル定義が固まれば、generateしてDAOができる - 筆者のプロダクトではSkinny-ORMで利用するORM生成して いる
- 47. セプテーニ・オリジナルの場合 言語の制定（パターン1) 1. ユビキタス言語は日本語と英語の2パターンで実装者が決める。 2. レビューでしっくりくるかどうかを念入りに揉む 言語の制定（パターン2） 設計時やストーリー起案時にユビキタス言語まで練る 言語普及の努力 根気よく訂正しまくる。 訂正しきれない場合、芯を捉え損ねているとしてユビキタス 言語のほうを変えてしまう。（※実装も変えます） 47ユビキタス言語が普及しない - セプテーニ・オリジナルの場合(発表者:杉谷)
- 48. セプテーニ・オリジナルの場合 つらみ：ユビキタス言語が増えていくと管理が難しい ● 新しく入った人が言葉の意味を知るのが大変 ● ドキュメント(Wiki等)や紙に意味をまとめても、言葉自体が成 長していくため保守しきれない ● EntityやVOなど、ドメイン層の住人のクラス定義には丁寧に 言葉の歴史を記述するように務めている ○ JavaDocからユビキタス言語辞書を作るなにかを作りたいな感 48ユビキタス言語が普及しない - セプテーニ・オリジナルの場合(発表者:杉谷)
- 55. セプテーニ・オリジナルの場合 組織問題の解決 (困った) ❏ プロダクト間のコラボレーションがしづらい ❏ プロダクト間の依存関係をなくした上でコラボレーションしたい ❏ デプロイが依存してしまう ❏ スクラムチームが肥大化して生産性が落ちる ❏ 意思決定の遅延 ❏ ベロシティの無意味化 55アーキテクチャ選定に困る - セプテーニ・オリジナルの場合(発表者:木村) (解決)[WIP] 戦略的設計で定義した境界づけられたコンテキストの1部をマイクロサービス化 マイクロサービス単位でスクラムチームを組成
- 56. セプテーニ・オリジナルの場合 アプリケーション課題の解決する (困った) ❏ アプリケーションの肥大化 ❏ 新技術を導入しづらい/入れ替えづらい 56アーキテクチャ選定に困る - セプテーニ・オリジナルの場合(発表者:木村) (解決) ❏ ヘキサゴナルアーキテクチャのPort/Adapterを定義 ❏ マイクロサービスアーキテクチャでアプリケーションをコンパクトに
- 58. optの場合 （少なくともWeb系の開発においては） アーキテクチャの難しさや複雑度の上昇は コアな機能要件の外側が原因である（と思う） - 性能や費用対効果 - 保守性や事業継続性 - メンバーの入れ替わりやスキルレベル - 市場や技術のトレンド だから、何がコアで、何がそうでないかを 切り分けて開発を進めていくことが大事 58アーキテクチャ選定に困る - optの場合(発表者:平岩)
- 61. CyberZの場合 61アーキテクチャ選定に困る - CyberZの場合(発表者:島田) レイヤードアーキテクチャ＋アクティブレコードの限界 - インフラ層の交換が事実上不可能 - 性能とDDDの両方を満たす設計が困難 - メンテナンスコストの肥大とそれに伴うエンジニアの疲弊 - トランザクションスクリプト的な実装が散見された クリーンアーキテクチャの導入した所感 - インフラレイヤの検証に時間を掛けられた - DIP（依存関係の逆転）で方針と詳細の分離出来る為、テストが書きやすい - React.js + Flux.js と設計が類似しており、メンバーが馴染みやすかった - 新人２名（＋レビューワ２名）が１ヶ月で１プロダクトリリース出来るほどの生産性 の高さを確かめることが出来た
- 63. AndroidやiOS開発は、View層の実装がほとんどになりDDDの旨 味を感じづらい。 63iOSとAndroidでDDDが効力発揮しづらい - セプテーニ・オリジナル(発表者:杉谷) それでもやる理由 ○ スマートUIパターン防止になる ■ サーバ側・クライアント側のドメイン層が無茶を防ぐ スマートUIになっても大丈夫な方法があると、安全なまま効率の 良い実装ができるかも？ ○ CQRS（コマンドクエリ責務分離）を取り入れるとOK ○ リード側とライト側を分離することによって、ライト系はシンプル・堅牢に、リード 系はバリエーション豊かにできる設計方針 ○ 詳細はこちらを参照 将軍祭り：かとじゅん氏発表 最新DDDアーキテクチャとAkkaでの実装ヒントに ついて
- 65. 発表 困った!! No. 4th party tracking ができなかった 65 15
- 66. ◆4th party trackingとは 広告媒体に対する第三者として広告を配信する第三者配信から 連携し、配信対象ユーザーをトラッキングすること。 広告媒体 （DSPやADNW） 3PAS 4th tracker ◆4th party tracking がダメだったわけ プラットフォーマーに認定されてないベンダーによるトラッキング だったから（当たり前） 664th party tracking ができなかった - opt(発表者:平岩)
- 67. ◆解決法 認定済みベンダーに 4th party tracking してもらう （当たり前） ◆背景（おまけ） ユーザーのプライバシーを守りながら、 企業のマーケティングを推進するために、 インターネット広告業界には色々な取り組みがあります。 - 広告入稿時の審査 - 各プラットフォーマーによる認定制度 - 国際業界団体（IAB）による標準規格策定 - 業界団体（JIAA）によるリテラシー向上施策（勉強会や分科会） - オプトアウトの標準化（NAI, DDAI） 674th party tracking ができなかった - opt(発表者:平岩)
- 70. ＜解決するには＞ 各種用語を自分ごと化する。例えば… ・自分のブログに広告を貼って運用してみる ・株の運用をやってみる（性質が近い部分があるので） ・インターネット広告代理店を立ち上げる [PR] 自分ごと化が難しい場合は Opt Technologies の Tech Magazine で 「５分くらいで読めるエンジニアのための インターネット広告講座」を読む http://tech-magazine.opt.ne.jp/entry/2016/06/22/120453 70略語が憶えられない(CVR,CTR,CPC,CPA,CPM,...) - opt(発表者:平岩)
- 76. DynamoDB Table (RCU 120, WCU 60) AWS DynamoDB はパーティション毎にシャーディングされて データが格納されており、キャパシティ（RCU/WCU）はパーティ ション数で分割される - パーティション数はデータ量などで決まる（ぐぐれば計算式出 てきます） - どのパーティションに格納されるかはHashKeyで決まる - HashKeyがランダムでないと、特定のノードに偏って格納され る パーティション RCU 20 WCU 10 パーティション RCU 20 WCU 10 パーティション RCU 20 WCU 10 パーティション RCU 20 WCU 10 パーティション RCU 20 WCU 10 パーティション RCU 20 WCU 10 データ HashKey 76DynamoDBのキャパ問題 - opt(発表者:平岩)
- 77. DynamoDB Table (RCU 120, WCU 60) パーティションがたくさんある状況で、アクセスが特定のパーティ ションに偏ると、設定しているキャパシティよりも遥かに低いI/O負 荷でキャパオーバーとなってしまう ＜解決法＞ HashKeyがランダムでない場合 →設計を見直して、ランダムにしましょう HashKeyがランダムなのに集中してしまう場合 →厳しい。かなり余裕をもってキャパシティを設定する、 祈る、設計を根本的に見なおす、自前でさらにシャーディングする etc… パーティション RCU 20 WCU 10 パーティション RCU 20 WCU 10 パーティション RCU 20 WCU 10 パーティション RCU 20 WCU 10 パーティション RCU 20 WCU 10 パーティション RCU 20 WCU 10 RCU 20, WCU 10 に 収まらなければキャパオーバー 77DynamoDBのキャパ問題 - opt(発表者:平岩)
- 79. マイグレーションのバージョン取り合い ● データベーススキーマ管理にflywayを利用しています ● V1__Create_user.sql, V2__…みたいに連番のSQLで変更を 入れていく ● 番号を飛ばして適用しておいて、あとで流すみたいにできない ○ ActiveRecordとかだと楽勝でできるのに… ● 番号がかち合うと当然エラーが出て、解消めんどくさい ○ rollbackが手動ですし。。 →早いもの勝ち！？ 79マイグレーションのバージョン取り合い - opt(発表者:渋谷)
- 80. 解決策 ● コミュニケーション取るしかないよね ○ 「いまからVxxを使います」とかチャットで宣言した り ● 可能ならスキーマ変更のみ先にPRして、あとで実装 するとか ● もっといいデータベーススキーマ管理ツールに乗り換 える ○ なんかいいのないですかね？ 80マイグレーションのバージョン取り合い - opt(発表者:渋谷)
- 90. サブスクリプション導入が大変 例)IntelliJ Ultimate 最終決済権を持つ人(非エンジニア)に ツールの利用用途を説明して、 理解してもらうまでが大変。 費用対効果の説明が利用者ではないと難しい。 サブスクリプション(特にIntelliJ)の稟議が大変 90サブスクリプション(特にIntelliJ)の稟議が大変 - CyberZ(発表者:門田)
- 94. Redshift依存のクエリのテストが難しい ● ローカル実行環境が作れない ● ある程度はPostgreSQLで代用 可能だが、COPYとか、 DISTKEY/SORTKEYつきの DDLとか、Redshiftにしかない 機能をどうテストしたらいいのか 94Redshift依存のクエリのテストが難しい - opt(発表者:渋谷)
- 95. 解決策 ● テスト用にRedshiftを立てた。。。 ● 1台しか立ててないので、masterのビルド専用 ● マージタイミングが近くてmasterビルドが並列に走るとテスト が落ちる ○ ローカルでもRedshiftを使うテストコードを実行したいこと がある ○ 複数人でローカルテストを実行＋masterのビルドが走って いる、みたいな状況もあってカオス ● 接続ごとに別のテーブルを使うように変更して、解決したい（願 望） 95Redshift依存のクエリのテストが難しい - opt(発表者:渋谷)
- 97. テストデータなど、意味のない数字には42を使うのが定番だと思いますが こういうのはやめましょう （地味にいろんな人がハマった） 教訓：account42のidを42にすること。（？） case class Account(id: Long, name: String) object Fixtures { val account1 = Account(42L, “Martin Odersky”) } 97テストデータのIDが42 - opt(発表者:岡田)
- 99. (困った) ホワイトボックスベースで単体テストコードを書いた結果... - 単体テストを書くだけの目的でアクセス修飾子をゆるめたdef private[package]、def protectedが多発した。 - テストコードを見ても仕様が埋もれてしまった - クラスの責務が大きいものが増えた(もちろん原因は他にもある...) - リファクタリングの妨げになった 内部実装を変更する時にpublicメソッドのアウトプットは変わらないのにテスト を書き直さくてはならなくなった 異論はあるかと思いますが、実際に運用してみて苦労した... 99テストの品質維持 - セプテーニ・オリジナル(発表者:木村)
- 100. (解決) ❏ ブラックボックステストを中心に単体テストを書く ホワイトボックステストに関しては必要な箇所だけ... いや、その場合は別のクラスに出来ないかを検討して大体クラス分割している ❏ テストメソッドを見て仕様を理解できるか確認 ❏ 単一責務になっているかを確認 ❏ アクセス修飾子がテストのために変更されていないかを確認 確認=プルリクエストで確認 100テストの品質維持 - セプテーニ・オリジナル(発表者:木村)
- 103. セプテーニ・オリジナルの場合 - 【暫定版】新人エンジニアのプルリクエスト入門 弊社社員がまとめている記事 どのようにプルリクエストをすれば通るようになるか言語化して、配布 - 指摘時に出来る限りサンプルコードは添えて 文章や言葉だけだと伝達度にばらつきがあるので - レビュー指摘は愛だとメンバーに伝える 指摘事項が多くなると険悪なムードになりがちなので 103レビューが大変 - セプテーニ・オリジナルの場合(発表者: 木村)
- 104. セプテーニ・オリジナルの場合 pull requestを利用した開発ワークフローを参考にレ ビューコメントにタグを付けた 104レビューが大変 - セプテーニ・オリジナルの場合(発表者: 木村)
- 106. optの場合 ● 重要性を認識して、しっかり工数を取る ○ レビューを受けた修正の工数も ● コミットを意味単位できっちり分けて把握しやすくする ○ 大きな意味を持つ変更もあるので、限界はある ● 特定のレビュアーへの負荷集中を防ぐため、あらかじめ 複数人をアサイン ○ 今後導入予定 106レビューが大変 - optの場合(発表者:渋谷 )
- 107. optの場合 ● レビューには「コードのオーナーシップ共有」の側面もあ る ○ 「レビューで問題が見つかった」まで至らずとも、コー ドが読まれただけで価値がある ● 大変でも逃げずに立ち向かう 107レビューが大変 - optの場合(発表者:渋谷 )
- 108. CyberZの場合 質疑応答を口頭や Slack/Issueでトラッキング ↓ [WIP] レビューでレビュー粒 度を細かくする ↓ レビューワーはPRが来たら 即日レビュー 108レビューが大変 - CyberZの場合(発表者: 島田)
- 111. 【解決策】 ・定期的なタイミングで棚卸しする場を設ける ex) スプリントMTG etc. ・優先度があがるトリガーを用意しておく ex) 機能の問い合わせが出始めたら 次にアラートが鳴ったら 111優先度の低い重要なタスクが減らない - CyberZ(発表者:鈴木)
- 113. トラブル発生！！ ↓ 原因当てクイズで帰れま10 「あのドメインモデル、じゃない？」 ↓ MGR「え、トラブル起きてるの？？」 トラブル時にテンパる 対応 取りまとめを買って出る「俺、まとめます！」 トラブル状況確認 ↓ 影響範囲調査&報告 ↓ 進め方を決める 113トラブル時にテンパる - CyberZ(発表者:遠藤)
- 115. 炎上プロジェクトにおかれたPM/PLがメンタルをやられて来なく なってしまった。 問題を一人で抱え込み外部から問題の本質が見えず、 火消しに入った代わりのPM/PLが 何が起きているか分からないと言う自体に。 対応 ある程度の失敗を許容し、大きな問題とならないように改善に繋 がるための心理的な安全を確保するようにした。 一人で抱え込むことが無いように、1 on 1 KPTでチームメンバー全員で課題の認識や 解決に対して取り組む場を設けた プロジェクトリーダー /プロダクトマネージャーが こなくなった 115プロジェクトリーダー/プロダクトマネージャーがこなくなった - cyberZ(発表者:島田)
- 125. 【課題】 ・プロダクトに責任を持つステークホルダが複数存在 ・誰の発言が正なのかわからない ・製造しても利用者不在の事態に.. 125プロダクトオーナー不在問題 - CyberZ(発表者:鈴木)
- 128. 解決： 貼るホワイトボードを活用する セプオリの多くのチームではデイリースクラムの報告をスムーズ に行うため、ホワイトボードに板書することにしているが、何人もホ ワイトボードに群がると大変 128デイリースクラムのレポート用意が大変 - セプテーニ・オリジナル(発表者:杉谷) 難点：貼るホワイトボードが高い（約1500円/枚）
- 130. バグ修正やリファクタリング等の保守タスクは何も考えないと通常 業務に負けてしまう。とはいえ放っておくと衛生環境が悪くなって しまう。やっていく気持ちをだす方策が必要 130スプリントに技術的負債の返済チケットが入れづらい - セプテーニ・オリジナル(発表者:杉谷) ● 保守系タスクをスプリントにいれるのはプロダクトオーナーの 義務 ○ 会社方針としてもこれは明示 ○ 毎スプリントに一定数、保守系チケットを盛り込む運用等で実現 ● そもそも保守系タスクが出にくいように頑張る ○ 開発者による手運用（DB直操作など）が出る仕様は厳禁 ○ 技術的負債が残る工法は出来るだけ選ばない。どうしても必要ならちゃんと関 係者全員が説明を受け納得した上で行う。
- 132. (困った) ❏ スクラムチームの状況を鑑みずに増員された ❏ 今までのベロシティが無意味になった ❏ 文化継承にコストがかかった 132無計画な人員の増員によるスクラム破綻 - セプテーニ・オリジナル（発表者:木村) (解決) - スクラムチームの枠を超え、経営戦略を理解し、適切 なチーム構成を話し合い、適切なアーキテクチャ設計 を立てる - だいたい半年単位インセプションデッキを再定義
- 138. スプリントプランニングの際に、一部の見積もりが難しいチケットに ついて時間がかかってしまったり、時間をかけて見積もったはい いが精度が低くなってしまう問題があった。 138スクラムの見積もりが難しい - セプテーニ・オリジナル(発表者:杉谷) 対応 「見積もりが難しい = チケットの粒度が大きすぎる」という傾向が あったため、極力ブレークダウンしてから見積もりをするようにし た。 事前に検証や調査が必要そうなチケットについては、設計及び実 装を行うスプリントよりも前のスプリントで検証/調査チケットを入れ るようにした。
- 139. 前回スプリントのベロシティを参考にしつつ、休みや祝日の存在を 確認した上でポイント総量を調整するようにした。 計画ミーティングは1部と2部に分け、 1. 第一部でプロダクトオーナーの意向を踏まえた大ざっぱな計 画をたてる 2. 翌日に行う第2部までに要件で怪しい箇所を確認する 3. 第二部では、実装内容やブロッカーの存在を確認、ある程度 具体的に作業が想像できるまでエンジニアのみで検討 という段取りを踏むようにした 139スクラムの見積もりが難しい - セプテーニ・オリジナル(発表者:杉谷)
- 142. セプテーニ・オリジナルの場合 1. PHPでイケイケで作った結果破綻し、”ちゃんとやる”の気運が高まる 2. GANMA!を当時の流行（Scala / DDD / TypeScript / etc …) で作成 3. GANMA!チームに別チームから留学 4. 留学終了。 かとじゅん氏（前職の同僚・DDD伝道師）にアドバイザー※として参加し てもらいつつ新規プロダクトをScala + DDDで作成 5. どんどん株分けが進み、全てがScala + DDDとなった 6. 新しい方ではヘキサゴナルアーキテクチャを採用するなど進化も進む。GANMAが 古くさく見える勢い… ※ぼったくりにあいお金に困ったかとじゅんが、杉谷に相談をしたことから始まった副業。 絶讃ご依頼承り中とのこと。 ご依頼は@j5ik2oまで。 （土日可動前提） 142言語・技術に対する宗教論争・普及の道のり - セプテーニ・オリジナルの場合（発表者:杉谷) 全アクティブプロダクト Scala ・ DDD採用率 【100%】
- 145. optの場合 よくわかるオプトの新技術導入フロー 〜ライブラリ編〜 1. 依存性に追加して、 コードにしれっと含める 145言語・技術に対する宗教論争・普及の道のり - optの場合（発表者:杉泊)
- 146. optの場合 よくわかるオプトの新技術導入フロー 〜ライブラリ編〜 2. PRを出し、 見逃してくれそうな人に アサインする 146言語・技術に対する宗教論争・普及の道のり - optの場合（発表者:杉泊)
- 147. optの場合 よくわかるオプトの新技術導入フロー 〜ライブラリ編〜 3. PRが通り、 無事masterにマージされる 147言語・技術に対する宗教論争・普及の道のり - optの場合（発表者:杉泊)
- 148. optの場合 よくわかるオプトの新技術導入フロー 〜ライブラリ編〜 4. やりたいようにやる 148言語・技術に対する宗教論争・普及の道のり - optの場合（発表者:杉泊)
- 150. 発表 困った!! No. 急いで作れ vs ちゃんと作ろう 素早く短く作れるほどビジネス成功率は高まるとはいえ 急ぎすぎても問題が。各社の方針は!? 43 150
- 151. セプテーニ・オリジナルの場合 会社としての品質の考え方、および具体的に利用する 技術やその理由・例外を記した文章「技術指針」を制定 経営から現場まで、全関係者がこれ従う。 とてもかいつまんだ内容 1. 我々は”高速高品質”を目指す 2. 我々は保守性のあるコードを高速に生産する 3. Scalaを使う理由は気軽に品質を維持するため / Scalaを利用しない場合 4. スクラムを採用する理由はプロダクトオーナーがハンドルを握るため / スクラム以外を利用する場合 5. DDDを採用するのはチーム全員で要件の芯を捉え続けるため / DDDを採用しない場合 6. ユニットテストを書く理由はリファクタリングをし続けるため / テストを書く＝遅いという思い込みを止めよう / テストを書かない場合 7. レビューを行うのは意識を保ち続けるため / レビューを行い続けるため属人性を高めない / レビューを行わない場合 8. 省略… 弊社サイトで全文読めます 一言で言うと 「”ちゃんと”を高速にやりつづけるための筋肉をつける」 151急いで作れ vs ちゃんと作ろう - セプテーニ・オリジナルの場合（発表者:杉谷)
- 152. optの場合 【大前提】 QCDにはトレードオフの関係がある 【中前提】 各個人の経験値やスキルにはばらつきがある 【小前提】 面白いと思って仕事をしているときが一番パフォーマンスが良い 152急いで作れ vs ちゃんと作ろう - optの場合（発表者:平岩)
- 153. optの場合 [プロダクトチーム制への移行] 2016年下期からセールスも開発も同じチームになるプロダクトチーム制への移行を試 みます - 「QCDにはトレードオフの関係がある」 - ビジネス側と開発側でできるだけ同じドキュメントを扱い、見える化を推進 - トレードオフが課題になりそうな場合、すぐに相談できるように - 「各個人の経験値やスキルにはばらつきがある」 - 何でも共有し、何でも助け合えるチームへ - DevOpsの仕組み作りに注力するほか、ビジネス側にも Opsに張り出してもらう - 「面白いと思って仕事をしているときが一番パフォーマンスが良い」 - ビジネスKPIをエンジニアも追い、ビジネス理解を高めてより本質的な仕事を - 作って意味のあるものを作り、作らなくて良い物は作らない 「急いで作れ vs ちゃんと作ろう」の判断を 高速に何度も行える体制へ 153急いで作れ vs ちゃんと作ろう - optの場合（発表者:平岩)
- 154. CyberZの場合 ビジネス要件は希望に満ち溢れている 要件通りに作っていたら「始まらない」 1ヶ月半程度でローンチ出来るプロトタイプ作成 構造は単純で安上がり。ボトルネックを明確に。 ↓ 市場に投下し、予算がついたタイミングで作り直し ↓ プロトタイプを部分的に置き換えていく形で アプローチ 154急いで作れ vs ちゃんと作ろう - CyberZの場合（発表者:門田)
- 155. CyberZの場合 プロトタイプの「撤退基準」を明確化しておく [いつまでに] 最長でも6ヶ月まで。 [何が出来ていないといけないか] 導入(利用)目標, 売上目標 → 達成？ システム費用対効果 → 想定どおり？ 振り返りはキチンと厳格化 155急いで作れ vs ちゃんと作ろう - CyberZの場合（発表者:門田)
- 157. ScalaだけでなくJavaScriptエンジニアも足りない ● 画面がSPAだったりして、開発にはそれなりにJS 力が必要 ● JS界隈のトレンド移り変わり速度が速すぎる ● JSできるエンジニアの求人票の難しさ ○ （jQueryしかできない人に来られても困る） ● デザインまではできなくて良いorデザインは外注 で良いケースも多くUI/UXエンジニアと言って良い のかという懸念も 157ScalaだけでなくJavaScriptエンジニアも足りない - opt(発表者:平岩)
- 158. 解決編 ● 画面側をTypeScriptに。 Scalaエンジニアも比較的 触りやすいように ○ （ん、Scala.js?） ● 一人か二人詳しい人が居 ると大変捗る ● 求人票については自分た ちに合ったものを頑張って 考える ● マガジン記事公開しまし た！→→→→→→→ 158ScalaだけでなくJavaScriptエンジニアも足りない - opt(発表者:平岩)
- 166. 入社された方はScalaやDDDを学ぶ段階から開始となるが、最初 は教え方が統一されておらず辛みが多かった。現時点では全社 で統一したカリキュラムを利用している 1. コップ本を読む 2. Scalaとplayを学ぶため、好きな方法で掲示板を実装してみる （要件はカリキュラムで定義） 3. レビューを通過する 4. EricのDDD本か、Quicklyを読む 5. 掲示板をDDDで作り直す 6. レビューを突破する 新卒入社の方々には、@OE_uia氏によるScala研修や、 @yattom氏が公開されているテストのありがたみが噛みしめられ る問題を使ったTDD演習、かとじゅん氏によるDDD研修も実施。 166新人さん教育の方法 - セプテーニ・オリジナル(発表者: 杉谷)
- 168. (困った) スクラムではチームの生産性を高めることに重きを置くが、他の チームの開発状況を鑑みた全体的なシステム戦略をたてづらかっ た 168チームを跨ぐと車輪の再開発が沢山発生してしまった - セプテーニ・オリジナル(発表者:木村) (解決) - プロダクト・フォーカス プロダクト間で課題やプラクティスを共有する - 社内Hack Days プロダクト間で抱えている課題を技術で解決する
- 170. セプテーニ・オリジナルの場合 170Scala人材が採用できない - セプテーニ・オリジナルの場合(発表者:杉谷) セプテーニオリジナルは常に人材を募集しています！！ 〈アピールポイント〉 全プロダクトScala・DDD採用 / 社外熟練者レビュアーからの実装アドバイス / テスト 整備やレビュー、CI可動などの昨今の常識は当然実施 / オレオレでない教科書通り のスクラム運用 / マシマシMacbookPro / スタンディング作業ができる上下に動かせ る流行の机 / 結構立派な社内カフェ(昼食ビュッフェ有り) Scala未経験でもOK！ ご応募お待ちしています！ ご応募は弊社サイトよりどうそ