scala/scrum/ddd 困ったこと50連発ガトリングトーク！！

Scala/Scrum/DDD 困ったこと50連発ガトリングトーク！！

2016年 7月 27日株式会社セプテーニ・オリジナル／株式会社オプト / 株式会社CyberZ

1

Scalaの困った

2

Scalaやフレームワークに関する困り事

発表

困った!! No.　　

Scalaコンパイル遅いScalaのコンパイルの遅さには皆様苦労しているはず…？

各社の対策は!?

1

3

セプテーニ・オリジナルの場合

当然のように金の弾丸

【セプオリ標準機】

15inch Macbook Pro Retina 2.5GHz SSD512GB標準構成 + CPU増強 + SSD増量 = ¥272,800

4Scalaコンパイル遅い - セプテーニ・オリジナルの場合(発表者:杉谷)

optの場合

5Scalaコンパイル遅い - optの場合(発表者:岡田)

とくにCIに時間かかって困っている。。色々やってはみたが満足のいく結果は得られず

・複数コンテナで、sbtプロジェクトを並列にテスト => 共通プロジェクトのビルドに時間かかる・masterと差分のあるプロジェクトのみビルドするsbtプラグイン作った => 共通プロジェクトのビルドに時間かかり、効果微妙・コンテナ追加(Circle CI) => リードタイムは減らない

optの場合

6Scalaコンパイル遅い - optの場合(発表者:岡田)

CI速くする銀（金）の弾丸求む！

CyberZの場合

マシンスペックで殴る！！

7Scalaコンパイル遅い - CyberZの場合(発表者:鈴木)

ただ、実際フルビルドが走らなければ、そこまで気にならない。

エンジニアには、MacBookProのフルスペックを支給

発表


Sparkでserializableじゃないオブジェクトを転送してしまう

8

2

Sparkアプリの難しさ

・明示的にBroadcastしてなくても転送されたりする。

・オブジェクトのライフサイクルが掴みにくい。

・ローカルでは動いたのに分散環境ではエラーになるとかもある。。

オプトで詰まった例（解消済み）

・ロガーとかの設定を動的にしたい。

　→Driver/Executor両方で走るように書く。

・Serializableでない、生成が重たいオブジェクトを扱いたい。

　→Executorで一度だけ走るように書く。

9Sparkでserializableじゃないオブジェクトを転送してしまう - opt(発表者:柴田)

解決法

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(発表者:柴田)

余談

・明示的にBroadcastするのとしないのとは何が違う？

Scalaの関数で定数を使用している場合、

関数を転送する度に値の転送も発生することになる。

ブロードキャストを使うと、定数の内容は1度だけ各executorに転送される。

from (http://www.ne.jp/asahi/hishidama/home/tech/scala/spark/SparkContext.html)

一度しか使わないなら明示的に Broadcastしないのもアリかも。

11Sparkでserializableじゃないオブジェクトを転送してしまう - opt(発表者:柴田)

http://www.ne.jp/asahi/hishidama/home/tech/scala/spark/SparkContext.html

発表


Scala標準のEitherが使いにくい

12

3

どういう事？

- 例えばHaskellのEitherは右側優先

- Functorのインスタンスなのでfmap関数が使える

- Monadのインスタンスでもあるのでbind演算子も

利用可能

- つまり、do記法の中でスイスイと利用可能

13Scala標準のEitherが使いにくい - opt(発表者:杉泊)

HaskellのEither


HaskellのEither

カッコいい！

素敵！

抱いて！15Scala標準のEitherが使いにくい - opt(発表者:杉泊)

ほうほう、それで？

- 一方でScalaのEitherは左右を平等に扱う

- Either自体にはmapやflatMapメソッドが定義され

ていない

- leftメソッド、rightメソッドで〜Projection型にして

mapやflatMapを使う事はできるが……- これらの結果はEither型を返してくる

- つまり、for記法内での束縛やガードが使えない！


ScalaのEither


ScalaのEitherなんかダサーい

無駄な記述が多すぎる

LISPで書けばいいのに……


そこで……

Scalaz.\/

cats.Xor

19

Scalaz.\/

Scala標準のEitherが使いにくい - opt(発表者:杉泊)

発表


異種のモナドをまとめてシンプルに扱いたい

21

4

どういう事なの？

- Scalaz.\/の導入でエラー情報を良い感じに返せ

るようになったよ！　やったね！

- でも関数の中にはOption型の返り値を返すもの

もあるよ！

- その2種類の関数を組み合わせて使う必要が出

てきたよ！

22異種のモナドをまとめてシンプルに扱いたい - opt(発表者:杉泊)

そこで

モナドトランスフォーマーを使います。


こんな補助関数を用意して、


こんな感じで使います


発表


ほとんど構造の同じcase class同士で値をcopyしたい

26

5

異種のモナドをまとめてシンプルに扱いたい - opt(発表者:岡田) 27

shapeless・・・型の力を活かしてboilerplateを排除できたりする（悪名高い）便利ライブラリ

例えばLabelledGenericを使うと、case classに値を追加して別の型のcase classにcopyみたいなことが(runtime reflection使わずに)書ける

28異種のモナドをまとめてシンプルに扱いたい - opt(発表者:岡田)

コンパイル時間のトレードオフがあることを理解する。（そもそもちゃんとモデリングしよう）

使えるじゃん！ =>コンパイル時間が増大しすぎてやめた。。。

発表


Scalaコード読みにくい問題

29

6

30

読みにくいと思ったScalaコードは、背景にある概念やパターンを自分が知らないだけなことも割とあった（個人の感想）

Cake pattern, Type classes, Magnet pattern, Monad, etc...

知らないイディオム・パターンは学習しよう。（ただし、そのパターンを使わずに綺麗に書けないかどうかは意識する。）

クリスマスプレゼントに金槌をもらった子どもは、何でも叩きたがる。 (金槌の法則 ―― ジェラルド・M・ワインバーグ)

Scalaコード読みにくい問題 - opt(発表者:岡田)

発表


doc見てもこんなメソッド定義されてないよぅ（implicit conversion）

31

7

問題点

　タイトルそのまま（辛い）

対応

・Intellijに聞いてみる　→　次ページで説明

・むやみにワイルドカードインポートしない

・ライブラリに関しては頑張って覚える。

　（Akka/Play2/ScalikeJDBC etc...）

・自分で書くときはなるべく暗黙変換しない。

32doc見てもこんなメソッド定義されてないよぅ（implicit conversion）- opt(発表者:柴田)

　Intellijに聞いてみる　(Akkaのサンプル)

・1にsecondsなんてメソッドない

・「actor ? ○○」って何？

・（timeoutはどこで使われてる？）

→Intellijに聞いてみましょう


　Implicit conversionは Ctrl + Shift + Q (Linux)

・1はDurationIntに変換されてるらしい。


　Implicit parameterは Ctrl + Shift + P (Linux)

・?がtimeoutをimplicitで使ってるらしい。

（言うまでもないが「?」はactorのメソッドでドットと括弧が省略されてる）

（ちなみにこのactorもActorRef → AskableActorRef へ変換されている）

（sender()もimplicit parameterだが、ここではデフォルト値なので無視）

（vim/emacsはどうすればいいですか？　→　知らんがな）


発表


Option.get / Try.get

36

8

何のためらいもなく、普通にOptionやTryのgetが使われているこ

とがある。

37Option.get / Try.get -セプテーニ・オリジナル(発表者:杉谷)

対策

OptionはScalaで初めて遭遇したという場合が多く、扱い方と重要

性を認識できていない、ということが殆どだった

見つけた場合

● 想定していないケースを考慮することの重要性

● 異常パターンがあるからOptionやTryになっている

● getOrElseやmapやfor式で扱う等のやり方を示す

などを丁寧に共有している

発表


初期のScalaのコードが辛い

38

9

Scala初心者の頃に書いたコードは辛みが多い。ある程度はボーイスカウト

ルールで解決するが

● Objectの乱用 ● DB操作などFutureを使うべき場所がベタ組み

など辛みが続く失敗はできるだけ防ぎたい。

39初期のScalaのコードが辛い - セプテーニ・オリジナル(発表者:杉谷)

対策：オーバーウォッチチーム

BitBucketプラグインの”Workzone”による自動レビュアー追加機能をつかっ

て、社内で発生するPRにオーバーウォッチメンバー（杉谷やかとじゅん氏等）が

自動参加。アドバイスを行う。

発表


playframeworkのバージョンアップが辛い

40

10

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の記述が結構変わる

実際にやったときの大変さ

● なんだかんだで1ヶ月くらい修正にかかった

● 全てのファイルが書き換わった

● 現行コードの修正は日々進むので git pullっては2.5化する

日々

● リリース時に問題は大量に発生した○ 意外とコード本編の移行は問題はあんまりなかった。

○ 殆どはconfの構造変更時の移植ミス。confの記述が変わるからと、ついでにリ

ファクタリング（環境別に1ファイル → ファイルを分割してincludeする方式）に

したのがまずかった…

得られた教訓

フレームワークの更新は素早く小刻みにやりましょう！！！

42playframeworkのバージョンアップが辛い - セプテーニ・オリジナル（発表者:杉谷)

発表


DAOの実装ボイラープレート化

43

11

DAO実装のボイラープレート化- セプテーニ・オリジナル（発表者: 木村) 44

(困った)scalaプロダクトが2,3個立ち上がったところで、同じような実装をし

ていることが検出された

(解決)DAOの実装コード/テストコードを自動生成できないかを模索し、

具体的なストレージ技術に依存しない(ただし、JDBC依存)自動生

成ツールを企画・開発

sbt-dao-generator

- 2つのプロダクトで動作中(3プロダクト目検討中)- テーブル定義が固まれば、generateしてDAOができる

- 筆者のプロダクトではSkinny-ORMで利用するORM生成して

いる

https://github.com/septeni-original/sbt-dao-generator

https://github.com/septeni-original/sbt-dao-generator

http://skinny-framework.org/documentation/orm.html

DDDの困った

45

ドメイン駆動設計に関する困り事

発表


ユビキタス言語が普及しないDDDのユビキタス言語はみな共通で使う言葉！

…のはずなのに言い回しがどんどん変わっていく現象

12

46


言語の制定（パターン1)

1. ユビキタス言語は日本語と英語の2パターンで実装者が決める。

2. レビューでしっくりくるかどうかを念入りに揉む

言語の制定（パターン2）

設計時やストーリー起案時にユビキタス言語まで練る

言語普及の努力

根気よく訂正しまくる。訂正しきれない場合、芯を捉え損ねているとしてユビキタス

言語のほうを変えてしまう。（※実装も変えます）

47ユビキタス言語が普及しない - セプテーニ・オリジナルの場合(発表者:杉谷)


つらみ：ユビキタス言語が増えていくと管理が難しい

● 新しく入った人が言葉の意味を知るのが大変

● ドキュメント(Wiki等)や紙に意味をまとめても、言葉自体が成

長していくため保守しきれない

● EntityやVOなど、ドメイン層の住人のクラス定義には丁寧に

言葉の歴史を記述するように務めている○ JavaDocからユビキタス言語辞書を作るなにかを作りたいな感

48ユビキタス言語が普及しない - セプテーニ・オリジナルの場合(発表者:杉谷)

optの場合

良い名前は難しい・名前をつける事柄や事象それ自身を良く言いあわらしていること・それ自身だけでなくコンテキストによっても最適な名前は変わる

・その名前を扱う人々の前提知識やスキルは様々である

【過去にあったことの例】よーしパパユビキタス言語を決めるべく用語集作っちゃうぞー　↓　・ユビキタス言語を決めること自体が難しいし、　　イケてないと簡単に別の名前で呼ばれる（特にマーケティング用語）　・用語集のメンテしてんの俺だけじゃん　↓別にメンテしなくてよくね？

49ユビキタス言語が普及しない - optの場合(発表者:平岩)

optの場合

良い名前は難しい、

でも決まると色々捗る名前（ユビキタス言語）がバシッと決まることで、

ビジネス・開発の双方の認識が統一され、それ自体の価値がより明確になる

【とはいえ、よくあること】・開発が後半になって、ある機能の本質がよりはっきりしてくると、良い名前がつけられることがある・それ自身は変わっていないのに、外部環境の変化により、名前を変えたほうが良いことがある

名前（ユビキタス言語）自体を決めることよりも、

・ビジネス側と開発側が対話を続けること・名前の変更が簡単な設計になっていること

が重要なのかも！

50ユビキタス言語が普及しない - optの場合(発表者:平岩)

CyberZの場合

問題領域の言葉をリーダー的立場の開発者が、

同じ言葉を使って話し続ける。

↓

チーム内に言葉が浸透すると共通言語に昇格する。

↓

言葉が共通言語に昇格すると、

ドキュメントやコードに落ちていく。

51ユビキタス言語が普及しない - CyberZの場合(発表者:島田)

発表


アーキテクチャ選定に困るレイヤードアーキテクチャだとかヘキサゴナルアーキテクチャだとか

CQRS+ESだとか沢山あって選定に悩む

13

52


前提として、課題解決のためのアーキテクチャを目指す

明確な課題抽出ができてないアーキテクチャは採用しない

(個人がやりたいだけが理由のオレオレアーキテクチャなんて話に

なった場合は危険信号...)

53アーキテクチャ選定に困る - セプテーニ・オリジナルの場合(発表者:木村)


DDDの解決

(困った)エリック本から入門し、レイヤードアーキテクチャを採用したが、ドメインモデル

が具体的なインフラ層に依存することからドメインモデルを隔離することが難し

かった


(解決)IDDDを参考に依存関係逆転の原則(DIP)を取り入れ、その延長線でヘキサゴ

ナルアーキテクチャに発展させる。

Scalaで学ぶヘキサゴナルアーキテクチャ実践入門

開発が進むにつれて参照用だけのクエリモデルが増え、ドメインモデルの管理コストが

かかることがあり、

コマンドモデルとクエリモデルを分けるCQRSなどのアーキテクチャを考察中

https://speakerdeck.com/kimutyam/scaladexue-buhekisagonaruakitekutiyashi-jian-ru-men

https://speakerdeck.com/kimutyam/scaladexue-buhekisagonaruakitekutiyashi-jian-ru-men


組織問題の解決

(困った)❏ プロダクト間のコラボレーションがしづらい

❏ プロダクト間の依存関係をなくした上でコラボレーションしたい

❏ デプロイが依存してしまう

❏ スクラムチームが肥大化して生産性が落ちる

❏ 意思決定の遅延

❏ ベロシティの無意味化


(解決)[WIP]戦略的設計で定義した境界づけられたコンテキストの1部をマイクロサービス化

マイクロサービス単位でスクラムチームを組成


アプリケーション課題の解決する

(困った)❏ アプリケーションの肥大化

❏ 新技術を導入しづらい/入れ替えづらい


(解決)❏ ヘキサゴナルアーキテクチャのPort/Adapterを定義

❏ マイクロサービスアーキテクチャでアプリケーションをコンパクトに

optの場合

とりあえずある程度まともに動くものが作れそうなアーキテクチャ

→ちょっと難しい

動作はもちろん、適度に最適化することができ、費用対効果が高いものが作れそうな

アーキテクチャ

→かなり難しい

ある程度まともに動き、保守性が高いものが作れそうで、新メンバーも理解しやすい

アーキテクチャ

→とても難しい

ある程度最適化することができ、保守性や理解のしやすさも担保しやすいアーキテク

チャ

→難しいってレベルじゃない

57アーキテクチャ選定に困る - optの場合(発表者:平岩)

optの場合

（少なくともWeb系の開発においては）

アーキテクチャの難しさや複雑度の上昇は

コアな機能要件の外側が原因である（と思う）

- 性能や費用対効果

- 保守性や事業継続性

- メンバーの入れ替わりやスキルレベル

- 市場や技術のトレンド

だから、何がコアで、何がそうでないかを

切り分けて開発を進めていくことが大事


optの場合

ヘキサゴナルアーキテクチャが言いたいことも

もしかすると何がコアで、何がそうでないかを

切り分けて開発を進めていくことが大事

ということなのかも（筆者の感想です）


CyberZの場合

60アーキテクチャ選定に困る - CyberZの場合(発表者:島田)

課題や問題を定期的に振り返り

↓

トレンド技術をキャッチ

↓

技術検証（時間を掛ける）

↓

デザインレビュー

↓

クリーンアーキテクチャ導入

アーキテクチャ検証の過程

[クリーンアーキテクチャの場合]

CyberZの場合

61アーキテクチャ選定に困る - CyberZの場合(発表者:島田)

レイヤードアーキテクチャ＋アクティブレコードの限界

- インフラ層の交換が事実上不可能- 性能とDDDの両方を満たす設計が困難- メンテナンスコストの肥大とそれに伴うエンジニアの疲弊- トランザクションスクリプト的な実装が散見された

クリーンアーキテクチャの導入した所感

- インフラレイヤの検証に時間を掛けられた- DIP（依存関係の逆転）で方針と詳細の分離出来る為、テストが書きやすい- React.js + Flux.js と設計が類似しており、メンバーが馴染みやすかった- 新人２名（＋レビューワ２名）が１ヶ月で１プロダクトリリース出来るほどの生産性

の高さを確かめることが出来た

発表


iOSとAndroidでDDDが効力発揮しづらい

62

14

AndroidやiOS開発は、View層の実装がほとんどになりDDDの旨

味を感じづらい。

63iOSとAndroidでDDDが効力発揮しづらい - セプテーニ・オリジナル(発表者:杉谷)

それでもやる理由

○ スマートUIパターン防止になる

■ サーバ側・クライアント側のドメイン層が無茶を防ぐ

スマートUIになっても大丈夫な方法があると、安全なまま効率の

良い実装ができるかも？

○ CQRS（コマンドクエリ責務分離）を取り入れるとOK○ リード側とライト側を分離することによって、ライト系はシンプル・堅牢に、リード

系はバリエーション豊かにできる設計方針

○ 詳細はこちらを参照

将軍祭り：かとじゅん氏発表最新DDDアーキテクチャとAkkaでの実装ヒントに

ついて

https://speakerdeck.com/j5ik2o/zui-xin-dddakitekutiyatoakkadefalseshi-zhuang-hintonituite



アドテクの困った

64

ネット広告に関係する困り事

発表


4th party tracking ができなかった

65

15

◆4th party trackingとは広告媒体に対する第三者として広告を配信する第三者配信から

連携し、配信対象ユーザーをトラッキングすること。

広告媒体（DSPやADNW）

3PAS 4thtracker

◆4th party tracking がダメだったわけプラットフォーマーに認定されてないベンダーによるトラッキング

だったから（当たり前）

66 4th party tracking ができなかった - opt(発表者:平岩)

◆解決法認定済みベンダーに 4th party tracking してもらう

（当たり前）

◆背景（おまけ）ユーザーのプライバシーを守りながら、

企業のマーケティングを推進するために、

インターネット広告業界には色々な取り組みがあります。

- 広告入稿時の審査

- 各プラットフォーマーによる認定制度

- 国際業界団体（IAB）による標準規格策定

- 業界団体（JIAA）によるリテラシー向上施策（勉強会や分科会）

- オプトアウトの標準化（NAI, DDAI）

67 4th party tracking ができなかった - opt(発表者:平岩)

発表


略語が憶えられない(CVR,CTR,CPC,CPA,CPM,...)

68

16

インターネット広告業界にはやたらと３文字の略語が多い

自身の生活や技術に

直接関係することもあまりないため

大変覚えづらい

69略語が憶えられない(CVR,CTR,CPC,CPA,CPM,...) - opt(発表者:平岩)

＜解決するには＞

各種用語を自分ごと化する。例えば…

　・自分のブログに広告を貼って運用してみる

　・株の運用をやってみる（性質が近い部分があるので）

　・インターネット広告代理店を立ち上げる

[PR] 自分ごと化が難しい場合は

Opt Technologies の Tech Magazine で

「５分くらいで読めるエンジニアのための

　インターネット広告講座」を読む

http://tech-magazine.opt.ne.jp/entry/2016/06/22/120453

70略語が憶えられない(CVR,CTR,CPC,CPA,CPM,...) - opt(発表者:平岩)

インフラの困った

71

AWSやデーターベース等に関する困り事

発表


EMR辛い

72

17

EMRは環境がブラックボックス

・s3の接続周りなどが特殊

　・普通のSparkはS3スキーマに対応しておらず、hadoop-awsが必要。

　・ローカルで同じように試せない。

・s3スキーマで出力するときにエラーが出る。。。

　・databricksのDirectOutputCommitterを参考にして凌いだ。

・クラスタの縮退がなんか上手くいかない。

　・社内の識者曰く、「AWSコンソールの仕様」らしい。辛み。。。

73EMR辛い - opt(発表者:柴田)

とはいえ、他のHadoopツールより遥かに楽

（個人の感想です）

・とりあえずstdout/errに吐いとけばYARNでも見れるし、

　S3に永続化してくれる。（反映タイミングに注意）

・IAMやaws-sdkをそのまま使えるので色々捗る。

・パラメータチューニングがある程度されている。

・GangliaやZeppelinがすぐ使えてすごく楽。

　＼アッカリ～ン／　＜わぁいEMR　あかりEMR大好き

74EMR辛い - opt(発表者:柴田)

発表


DynamoDBのキャパ問題

75

18

DynamoDB Table (RCU 120, WCU 60)

AWS DynamoDB はパーティション毎にシャーディングされて

データが格納されており、キャパシティ（RCU/WCU）はパーティ

ション数で分割される

- パーティション数はデータ量などで決まる（ぐぐれば計算式出

てきます）

- どのパーティションに格納されるかはHashKeyで決まる

- HashKeyがランダムでないと、特定のノードに偏って格納され

る

パーティション

RCU 20WCU 10


RCU 20WCU 10


RCU 20WCU 10


RCU 20WCU 10


RCU 20WCU 10


RCU 20WCU 10

データ

HashKey

76DynamoDBのキャパ問題 - opt(発表者:平岩)

DynamoDB Table (RCU 120, WCU 60)

パーティションがたくさんある状況で、アクセスが特定のパーティ

ションに偏ると、設定しているキャパシティよりも遥かに低いI/O負

荷でキャパオーバーとなってしまう

＜解決法＞

HashKeyがランダムでない場合　→設計を見直して、ランダムにしましょう

HashKeyがランダムなのに集中してしまう場合　→厳しい。かなり余裕をもってキャパシティを設定する、

　　祈る、設計を根本的に見なおす、自前でさらにシャーディングする etc…


RCU 20WCU 10


RCU 20WCU 10


RCU 20WCU 10


RCU 20WCU 10


RCU 20WCU 10


RCU 20WCU 10

RCU 20, WCU 10 に収まらなければキャパオーバー

77DynamoDBのキャパ問題 - opt(発表者:平岩)

発表


マイグレーションのバージョン取り合い

78

19

マイグレーションのバージョン取り合い

● データベーススキーマ管理にflywayを利用しています

● V1__Create_user.sql, V2__…みたいに連番のSQLで変更を

入れていく

● 番号を飛ばして適用しておいて、あとで流すみたいにできない

○ ActiveRecordとかだと楽勝でできるのに…● 番号がかち合うと当然エラーが出て、解消めんどくさい

○ rollbackが手動ですし。。

→早いもの勝ち！？

79マイグレーションのバージョン取り合い - opt(発表者:渋谷)

解決策

● コミュニケーション取るしかないよね

○ 「いまからVxxを使います」とかチャットで宣言した

り

● 可能ならスキーマ変更のみ先にPRして、あとで実装

するとか

● もっといいデータベーススキーマ管理ツールに乗り換

える

○ なんかいいのないですかね？

80マイグレーションのバージョン取り合い - opt(発表者:渋谷)

発表


AWSのコスト管理が大変

81

20


開発者とコスト見る人が分かれていると

「なんか高くない？」に発展しにくい。

エンジニア

「Spark鯖はメモリ20Gぐらい積んどくだろJK」

結果使わなくて放置してマネージャ激おこ


82AWSのコスト管理が大変 - CyberZ(発表者:門田)


エンジニア全員マネコン見れるようにした

毎月かかったコストの読み会小さいチーム毎

大きいプロダクト単位

やってみたら思ったより面白い

適切なスペックへの変更、台数調整、アーキテクチャレベルの変更をするように。

83AWSのコスト管理が大変 - CyberZ(発表者:門田)

解決策

開発ツールの困った

84

タスク管理ツールやCIなど、開発支援に関する困り事

発表


Jenkinsおじさん大量発生

85

21

・各チーム毎にJenkinsおじさんが繁殖（15人？）・CI以外のバッチ処理にもJenkinsおじさんが活躍・Scalaのコンパイルが重くて別のおじさん召喚

誰がどのJenkinsを使って何をやってるか把握できない。。(/ω・＼)ﾁﾗｯ

作成イメージ：本文ページ

対応第一次Jenkinsリストラ計画

・バッチスケジューラ導入・CirclCIに移行

86Jenkinsおじさん大量発生 - CyberZ(発表者:遠藤)

発表


ツール繁殖問題

87

22

・かんばんツール（Backlog、Trello、redmine、QiitaTeam、Docbase、waffle）・チャットツール（chatworkとSlack）・スケジューラー（Patriot、Rundeck、DigDag）・監視（nagiosとzabbix、cacti、datadog）・CI（JenkinsとCircleCI）etc,etc

ツール繁殖問題

対応

断捨離１ついれたら１つ捨てる

88ツール繁殖問題 - CyberZ(発表者:遠藤)

発表


サブスクリプション(特にIntelliJ)の稟議が大変

89

23

サブスクリプション導入が大変

例)IntelliJ Ultimate

最終決済権を持つ人(非エンジニア)にツールの利用用途を説明して、

理解してもらうまでが大変。

費用対効果の説明が利用者ではないと難しい。

サブスクリプション (特にIntelliJ)の稟議が大変

90サブスクリプション(特にIntelliJ)の稟議が大変 - CyberZ(発表者:門田)

サブスクリプション (特にIntelliJ)の稟議が大変

対応エンジニアMGRに決済権を委譲

(今のところ門田)

利用妥当性の確認はエンジニアMGRで。額が大きい場合はタッグを組んで最終決済へ。

ただ、ツール選定でごまかしが効かなくなった。「え。それってスタンダードじゃないけど、

なんで導入するの？比較検討はしたの？」

91サブスクリプション(特にIntelliJ)の稟議が大変 - CyberZ(発表者:門田)

テストの困った

92

テストを書く・維持するに関しての困り事

発表


Redshift依存のクエリのテストが難しい

93

24

Redshift依存のクエリのテストが難しい

● ローカル実行環境が作れない

● ある程度はPostgreSQLで代用

可能だが、COPYとか、

DISTKEY/SORTKEYつきの

DDLとか、Redshiftにしかない

機能をどうテストしたらいいのか

94Redshift依存のクエリのテストが難しい - opt(発表者:渋谷)

解決策

● テスト用にRedshiftを立てた。。。

● 1台しか立ててないので、masterのビルド専用

● マージタイミングが近くてmasterビルドが並列に走るとテスト

が落ちる

○ ローカルでもRedshiftを使うテストコードを実行したいこと

がある

○ 複数人でローカルテストを実行＋masterのビルドが走って

いる、みたいな状況もあってカオス

● 接続ごとに別のテーブルを使うように変更して、解決したい（願

望）

95Redshift依存のクエリのテストが難しい - opt(発表者:渋谷)

発表


テストデータのIDが42

96

25

テストデータなど、意味のない数字には42を使うのが定番だと思いますが

こういうのはやめましょう

（地味にいろんな人がハマった）

教訓：account42のidを42にすること。（？）

case class Account(id: Long, name: String)

object Fixtures { val account1 = Account(42L, “Martin Odersky”)}

97テストデータのIDが42 - opt(発表者:岡田)

発表


テストの品質維持

98

26

(困った)ホワイトボックスベースで単体テストコードを書いた結果...

- 単体テストを書くだけの目的でアクセス修飾子をゆるめたdef private[package]、def protectedが多発した。

- テストコードを見ても仕様が埋もれてしまった

- クラスの責務が大きいものが増えた(もちろん原因は他にもある...) - リファクタリングの妨げになった内部実装を変更する時にpublicメソッドのアウトプットは変わらないのにテストを書き直さくてはならなくなった

異論はあるかと思いますが、実際に運用してみて苦労した...

99テストの品質維持 - セプテーニ・オリジナル(発表者:木村)

(解決)

❏ ブラックボックステストを中心に単体テストを書くホワイトボックステストに関しては必要な箇所だけ... いや、その場合は別のクラスに出来ないかを検討して大体クラス分割している

❏ テストメソッドを見て仕様を理解できるか確認

❏ 単一責務になっているかを確認

❏ アクセス修飾子がテストのために変更されていないかを確認

確認=プルリクエストで確認

100テストの品質維持 - セプテーニ・オリジナル(発表者:木村)

チーム運営・スクラムの困った

101

チームに対して発生する様々な困り事

発表


レビューが大変コメントと修正の応酬で、マージにたどり着かないとか

修正内容がわからないとか、いつの間にか20件ほどPRが貯まってたりとか

27

102


- 【暫定版】新人エンジニアのプルリクエスト入門

弊社社員がまとめている記事

どのようにプルリクエストをすれば通るようになるか言語化して、配布

- 指摘時に出来る限りサンプルコードは添えて

文章や言葉だけだと伝達度にばらつきがあるので

- レビュー指摘は愛だとメンバーに伝える

指摘事項が多くなると険悪なムードになりがちなので

103レビューが大変 - セプテーニ・オリジナルの場合(発表者: 木村)

http://qiita.com/yharada/items/4f5c288fa4c57f71ea1b

http://qiita.com/yharada/items/4f5c288fa4c57f71ea1b


pull requestを利用した開発ワークフローを参考にレ

ビューコメントにタグを付けた


https://speakerdeck.com/hotchpotch/pull-request-woli-yong-sitakai-fa-wakuhuro?slide=43


技術的に口が立つ人の指摘内容を全て修正するような

形になっていたが、タグを付けることで対応スコープを明

確化した

IMOで意見が食い違う時はとことん議論する

チーム形成期に意見の食い違いをそのままにすると、混

乱状態が続き、成熟期を迎えられないと考え議論のコス

トを支払う方向に倒す


optの場合

● 重要性を認識して、しっかり工数を取る

○ レビューを受けた修正の工数も

● コミットを意味単位できっちり分けて把握しやすくする

○ 大きな意味を持つ変更もあるので、限界はある

● 特定のレビュアーへの負荷集中を防ぐため、あらかじめ

複数人をアサイン

○ 今後導入予定

106レビューが大変 - optの場合(発表者:渋谷 )

optの場合

● レビューには「コードのオーナーシップ共有」の側面もあ

る

○ 「レビューで問題が見つかった」まで至らずとも、コー

ドが読まれただけで価値がある

● 大変でも逃げずに立ち向かう

107レビューが大変 - optの場合(発表者:渋谷 )

CyberZの場合

質疑応答を口頭や

Slack/Issueでトラッキング

↓

[WIP] レビューでレビュー粒

度を細かくする

↓

レビューワーはPRが来たら

即日レビュー

108レビューが大変 - CyberZの場合(発表者: 島田)

発表


優先度の低い重要なタスクが減らない

109

28

【課題】問題をチーム内で把握できている

しかし、いつやるかなどの方針が立っていない！！

「やんなきゃﾈｰ」「やりたいﾈｰ」　　　だけが積み上がる

110優先度の低い重要なタスクが減らない - CyberZ(発表者:鈴木)

ﾈｰ(*´・ω・)(*´・д・｀*)(・ω・｀*)ﾈｰ

【解決策】

・定期的なタイミングで棚卸しする場を設けるex) スプリントMTG etc.

・優先度があがるトリガーを用意しておく

ex) 機能の問い合わせが出始めたら

次にアラートが鳴ったら

111優先度の低い重要なタスクが減らない - CyberZ(発表者:鈴木)

発表


トラブル時にテンパる

112

29

トラブル発生！！↓

原因当てクイズで帰れま10「あのドメインモデル、じゃない？」

↓MGR「え、トラブル起きてるの？？」

トラブル時にテンパる

対応取りまとめを買って出る「俺、まとめます！」

トラブル状況確認↓

影響範囲調査&報告↓

進め方を決める113トラブル時にテンパる - CyberZ(発表者:遠藤)

発表


プロジェクトリーダー/プロダクトマネージャーがこなくなった

114

30

炎上プロジェクトにおかれたPM/PLがメンタルをやられて来なく

なってしまった。

問題を一人で抱え込み外部から問題の本質が見えず、

火消しに入った代わりのPM/PLが何が起きているか分からないと言う自体に。

対応

ある程度の失敗を許容し、大きな問題とならないように改善に繋

がるための心理的な安全を確保するようにした。

一人で抱え込むことが無いように、1 on 1KPTでチームメンバー全員で課題の認識や

解決に対して取り組む場を設けた

プロジェクトリーダー /プロダクトマネージャーがこなくなった

115プロジェクトリーダー/プロダクトマネージャーがこなくなった - cyberZ(発表者:島田)

発表


遠隔地のメンバーとのコミュニケーションが上手くいかない

116

31

海外子会社のエンジニアとプロジェクト進行するに当たり、

時差（UTC-7＠16時間）の問題でスプリントMTGができず

リモートワーカーとのコミュニケーションが上手くいかず、作業連携

に失敗することがあった。

対応情報透明性を測るために、slackで分報の導入、日報の義務化、

GitHubでの仕様議論などツール類の整備化をすすめた

ビデオ会議の生産性向上が極めて重要

ノイズキャンセルスピーカーマイクが非常に効果的

たまに帰国してもらい顔を合わせて話す

遠隔地のメンバーとのコミュニケーションが上手くいかない

117遠隔地のメンバーとのコミュニケーションが上手くいかない - CyberZ(発表者:島田)

発表


プロジェクトの掛け持ちをすると炎上する問題

118

32

タスクや責任の所在が不明なものが増えたり、PJの優先度が選べなくなってしまい、結果的に炎上PJになってしまった

作成イメージ：本文ページ

対応

・スクラムの掛け持ち、ダメ絶対

・コンテキストスイッチを起こさない

・定期的にゴールとマイルストーンを確認

119プロジェクトの掛け持ちをすると炎上する問題 - CyberZ(発表者:遠藤)

発表


GitHubでのコードレビューからリアルファイトに発展

120

33

コードレビューのレビュアー・レビュイー間で

フラストレーションが溜まり、

最終的にリアルファイトに発展してしまった

対応主張の場合issueにトラックするように

レビュワーが主張か事実かを判別

コメントには責任を持つよう意識改革を。

スクラムマスタが心理的安全性を

高めるチームメイク

謙虚(Humility) 尊敬(Respect) 信頼(Trust)

GitHubでのコードレビューからリアルファイトに発展

121GitHubでのコードレビューからリアルファイトに発展 - CyberZ(発表者:島田)

発表


振り返りで話題がでない

122

34

スプリントの振り返りにて課題があまり出てこない現象があった。

原因：”自分の技術的に不十分だった汚点の事で、課題があると

いう事は、悪い事で自分の評価が下がるのではないか？”という

思い込みがあった。

対策：課題を自分のことでなくても・些細なことでもよいので出来る

だけ書いてもらったりするようにした。またプロダクトオーナーやス

クラムマスターが出来るだけ反省事を拾うようにした（もちろん、責

めにならないように注意する）

これを起点に意見を出し → 改善を積み重ねでチームが良くなっ

ていくことを全員で実感し、改善していった。

123振り返りで話題がでない - セプテーニ・オリジナル(発表者:杉谷)

発表


プロダクトオーナー不在問題

124

35

【課題】

・プロダクトに責任を持つステークホルダが複数存在

・誰の発言が正なのかわからない

・製造しても利用者不在の事態に..

125プロダクトオーナー不在問題 - CyberZ(発表者:鈴木)

【解決策】・専任POを役員が指名。

プロダクトの責任の所在を明確化

・POに権限委譲

POの発言をプロダクト方針とするように組織改編

運用方針が決定

素早い仕様策定

126プロダクトオーナー不在問題 - CyberZ(発表者:鈴木)

発表


デイリースクラムのレポート用意が大変

127

36

解決：貼るホワイトボードを活用する

セプオリの多くのチームではデイリースクラムの報告をスムーズ

に行うため、ホワイトボードに板書することにしているが、何人もホ

ワイトボードに群がると大変

128デイリースクラムのレポート用意が大変 - セプテーニ・オリジナル(発表者:杉谷)

難点：貼るホワイトボードが高い（約1500円/枚）

発表


スプリントに技術的負債の返済チケットが入れづらい

129

37

バグ修正やリファクタリング等の保守タスクは何も考えないと通常

業務に負けてしまう。とはいえ放っておくと衛生環境が悪くなって

しまう。やっていく気持ちをだす方策が必要

130スプリントに技術的負債の返済チケットが入れづらい - セプテーニ・オリジナル(発表者:杉谷)

● 保守系タスクをスプリントにいれるのはプロダクトオーナーの

義務

○ 会社方針としてもこれは明示

○ 毎スプリントに一定数、保守系チケットを盛り込む運用等で実現

● そもそも保守系タスクが出にくいように頑張る

○ 開発者による手運用（DB直操作など）が出る仕様は厳禁

○ 技術的負債が残る工法は出来るだけ選ばない。どうしても必要ならちゃんと関

係者全員が説明を受け納得した上で行う。

発表


無計画な人員の増員によるスクラム破綻

131

38

(困った)❏ スクラムチームの状況を鑑みずに増員された

❏ 今までのベロシティが無意味になった❏ 文化継承にコストがかかった

132無計画な人員の増員によるスクラム破綻 - セプテーニ・オリジナル（発表者:木村)

(解決)- スクラムチームの枠を超え、経営戦略を理解し、適切なチーム構成を話し合い、適切なアーキテクチャ設計を立てる

- だいたい半年単位インセプションデッキを再定義

発表


スクラムの各種会議に時間がかかる

133

39

デイリースクラムやスプリントプランニングで、事前に想定していた

時間よりも大幅に時間を超過してしまう傾向があった。

134スクラムの各種会議に時間がかかる - セプテーニ・オリジナル（発表者:杉谷)

対応

デイリースクラムについてはあくまでも報告の場とし、問題の解決

の場ではないということを徹底するようにした。何らかのアクション

が必要そうな事案については、どのメンバーで対応するかのみ決

め、デイリースクラム後に別途時間を取るようにした。

スプリントプランニングについては、詳細部分まで話し合っていた

ことが時間がかかっていた原因だったため、設計チケットを細かく

作成し、詳細部分については担当メンバーに一任するようにし、レ

ビューを厚くするような体制にした。

発表


プロダクトオーナーが上手く働かない

135

40

(困った)

コードを書かない作業はプロダクトオーナー(以下、PO)が対応す

るという暗黙的なルールができていた。

POが多忙になり、本来の業務に注力できなくなった。

136プロダクトオーナーが上手く働かない - セプテーニ・オリジナル(発表者:木村)

(解決)

POの必須作業を明文化し、それ以外の作業についてはチーム内

で分担するようにした。

また、POに求めることを技術指針として明文化(POはステークホ

ルダーとチームのバランスを取る必要があり、衛生を保つために

時として技術的負債の返却にも協力する必要がある) し、チーム

内で認識を共有できるようにした。

発表


スクラムの見積もりが難しい

137

41

スプリントプランニングの際に、一部の見積もりが難しいチケットに

ついて時間がかかってしまったり、時間をかけて見積もったはい

いが精度が低くなってしまう問題があった。

138スクラムの見積もりが難しい - セプテーニ・オリジナル(発表者:杉谷)

対応

「見積もりが難しい = チケットの粒度が大きすぎる」という傾向が

あったため、極力ブレークダウンしてから見積もりをするようにし

た。

事前に検証や調査が必要そうなチケットについては、設計及び実

装を行うスプリントよりも前のスプリントで検証/調査チケットを入れ

るようにした。

前回スプリントのベロシティを参考にしつつ、休みや祝日の存在を

確認した上でポイント総量を調整するようにした。

計画ミーティングは1部と2部に分け、

1. 第一部でプロダクトオーナーの意向を踏まえた大ざっぱな計

画をたてる

2. 翌日に行う第2部までに要件で怪しい箇所を確認する

3. 第二部では、実装内容やブロッカーの存在を確認、ある程度

具体的に作業が想像できるまでエンジニアのみで検討

という段取りを踏むようにした

139スクラムの見積もりが難しい - セプテーニ・オリジナル(発表者:杉谷)

組織・文化の困った

140

会社やチーム間連携など、チームを超えた様々な困り事

発表


言語・技術に対する宗教論争・普及の道のり新しいものの導入には様々な軋轢があったりなかったり。

各社の状況を共有

42

141


1. PHPでイケイケで作った結果破綻し、”ちゃんとやる”の気運が高まる

2. GANMA!を当時の流行（Scala / DDD / TypeScript / etc …) で作成

3. GANMA!チームに別チームから留学

4. 留学終了。かとじゅん氏（前職の同僚・DDD伝道師）にアドバイザー※として参加し

てもらいつつ新規プロダクトをScala + DDDで作成 5. どんどん株分けが進み、全てがScala + DDDとなった

6. 新しい方ではヘキサゴナルアーキテクチャを採用するなど進化も進む。GANMAが古くさく見える勢い…

※ぼったくりにあいお金に困ったかとじゅんが、杉谷に相談をしたことから始まった副業。

　絶讃ご依頼承り中とのこと。ご依頼は@j5ik2oまで。（土日可動前提）

142言語・技術に対する宗教論争・普及の道のり - セプテーニ・オリジナルの場合（発表者:杉谷)

全アクティブプロダクト Scala ・ DDD採用率

【100%】

https://twitter.com/j5ik2o

optの場合

Scalaは何か私が入る前から使ってたのでよく知らない（葛藤とかあったのかしらん？）

だからScalaに関しては論争も葛藤も無ければ布教も啓蒙も無かった（んじゃない？　知らないけど）

143言語・技術に対する宗教論争・普及の道のり - optの場合（発表者:杉泊)

optの場合

そのかわりライブラリ導入に関する論争とか、議論とか、宗教活動とか、肉体言語とかは多少あった……ような気がする。（Scalazとか、shapelessとか）

でも基本的に、メンテ可能なら認められるっぽい？

手法とかはプロマネの人が推せば良いんじゃないのだろうか（DDDとかscrumとか）


optの場合

よくわかるオプトの新技術導入フロー〜ライブラリ編〜

1. 依存性に追加して、コードにしれっと含める


optの場合


2. PRを出し、見逃してくれそうな人にアサインする


optの場合


3. PRが通り、無事masterにマージされる


optの場合


4. やりたいようにやる


CyberZの場合

Scalaの導入に抵抗を持つ人材はいた。

どうやって普及活動をしたか？

結局、度重なる啓蒙活動！他の言語はゼッタイ否定しない(...?)

そこから、「Scalaいいよ」「それScalaならできるよ」

などと甘い言葉を囁き続ける

149言語・技術に対する宗教論争・普及の道のり - CyberZの場合（発表者:鈴木)

発表


急いで作れ vs ちゃんと作ろう素早く短く作れるほどビジネス成功率は高まるとはいえ

急ぎすぎても問題が。各社の方針は!?

43

150


会社としての品質の考え方、および具体的に利用する

技術やその理由・例外を記した文章「技術指針」を制定

経営から現場まで、全関係者がこれ従う。

とてもかいつまんだ内容

1. 我々は”高速高品質”を目指す

2. 我々は保守性のあるコードを高速に生産する

3. Scalaを使う理由は気軽に品質を維持するため / Scalaを利用しない場合

4. スクラムを採用する理由はプロダクトオーナーがハンドルを握るため / スクラム以外を利用する場合

5. DDDを採用するのはチーム全員で要件の芯を捉え続けるため / DDDを採用しない場合

6. ユニットテストを書く理由はリファクタリングをし続けるため / テストを書く＝遅いという思い込みを止めよう / テストを書かない場合

7. レビューを行うのは意識を保ち続けるため / レビューを行い続けるため属人性を高めない / レビューを行わない場合

8. 省略… 弊社サイトで全文読めます

一言で言うと「”ちゃんと”を高速にやりつづけるための筋肉をつける」

151急いで作れ vs ちゃんと作ろう - セプテーニ・オリジナルの場合（発表者:杉谷)

http://www.septeni-original.co.jp/culture/policy.html

optの場合

【大前提】

QCDにはトレードオフの関係がある

【中前提】

各個人の経験値やスキルにはばらつきがある

【小前提】

面白いと思って仕事をしているときが一番パフォーマンスが良い

152急いで作れ vs ちゃんと作ろう - optの場合（発表者:平岩)

optの場合

[プロダクトチーム制への移行]

2016年下期からセールスも開発も同じチームになるプロダクトチーム制への移行を試

みます

- 「QCDにはトレードオフの関係がある」- ビジネス側と開発側でできるだけ同じドキュメントを扱い、見える化を推進

- トレードオフが課題になりそうな場合、すぐに相談できるように

- 「各個人の経験値やスキルにはばらつきがある」- 何でも共有し、何でも助け合えるチームへ

- DevOpsの仕組み作りに注力するほか、ビジネス側にも Opsに張り出してもらう

- 「面白いと思って仕事をしているときが一番パフォーマンスが良い」- ビジネスKPIをエンジニアも追い、ビジネス理解を高めてより本質的な仕事を

- 作って意味のあるものを作り、作らなくて良い物は作らない

「急いで作れ vs ちゃんと作ろう」の判断を

高速に何度も行える体制へ

153急いで作れ vs ちゃんと作ろう - optの場合（発表者:平岩)

CyberZの場合

ビジネス要件は希望に満ち溢れている要件通りに作っていたら「始まらない」

1ヶ月半程度でローンチ出来るプロトタイプ作成構造は単純で安上がり。ボトルネックを明確に。

↓市場に投下し、予算がついたタイミングで作り直し

↓プロトタイプを部分的に置き換えていく形で

アプローチ

154急いで作れ vs ちゃんと作ろう - CyberZの場合（発表者:門田)

CyberZの場合

プロトタイプの「撤退基準」を明確化しておく

[いつまでに]最長でも6ヶ月まで。

[何が出来ていないといけないか]導入(利用)目標, 売上目標　→　達成？システム費用対効果　→　想定どおり？

振り返りはキチンと厳格化

155急いで作れ vs ちゃんと作ろう - CyberZの場合（発表者:門田)

発表


ScalaだけでなくJavaScriptエンジニアも足りない

156

44

ScalaだけでなくJavaScriptエンジニアも足りない

● 画面がSPAだったりして、開発にはそれなりにJS力が必要

● JS界隈のトレンド移り変わり速度が速すぎる

● JSできるエンジニアの求人票の難しさ○ （jQueryしかできない人に来られても困る）

● デザインまではできなくて良いorデザインは外注

で良いケースも多くUI/UXエンジニアと言って良い

のかという懸念も

157ScalaだけでなくJavaScriptエンジニアも足りない - opt(発表者:平岩)

解決編

● 画面側をTypeScriptに。

Scalaエンジニアも比較的

触りやすいように○ （ん、Scala.js?）

● 一人か二人詳しい人が居

ると大変捗る

● 求人票については自分た

ちに合ったものを頑張って

考える

● マガジン記事公開しまし

た！→→→→→→→

158ScalaだけでなくJavaScriptエンジニアも足りない - opt(発表者:平岩)

発表


社外勉強会を企画したのに準備が進まず余裕がなくなる

159

45

・他人駆動型準備(ODP)

・業務時間内に発表内容や企画内容のレビュー

・人事や総務も巻き込んで会社全体で準備！

・セプさん、オプトさんみたいにタスクをどんどんレコメンドしてくれるような会社と一緒に勉強会を開催する(皆様、よろしくお願いします)

「Scala勉強会を開催しよう」ってノリノリで決定いざフタを開けると勉強会間際になっても準備が進んでない

160社外勉強会を企画したのに準備が進まず余裕がなくなる - CyberZ(発表者:遠藤)

発表


プロジェクト間や部署間でのコミュニケーション問題

161

46

スクラムの外の他部署とコミュニケーションがうまくとれ

なくなり、お互いにいわゆるお役所仕事になってしまった

（ex:インフラや広報など）

プロジェクト間や部署間でのコミュニケーション問題

対応ロードマップ作成時に他部門や他PJに関わるマイルス

トーンをあらかじめ設定

進捗の共有を定期的におこなったり、依頼する際は事前

当てをしっかりして、連帯感を作る

ちゃんと「ありがとう」を伝える

162プロジェクト間や部署間でのコミュニケーション問題 - CyberZ(発表者:遠藤)

発表


横展開で工数削減するつもりがカオスになった

163

47

横展開で工数削減するつもりが、

カオスになって逆に混乱の原因となった

対応

複数システムでの共通ライブラリなど幻想

夢を見過ぎない

途中から導入しようとしない

ある程度経ったら独立して作りなおす

横展開で工数削減するつもりがカオスになった

164横展開で工数削減するつもりがカオスになった - CyberZ(発表者:鈴木)

発表


新人さん教育の方法

165

48

入社された方はScalaやDDDを学ぶ段階から開始となるが、最初

は教え方が統一されておらず辛みが多かった。現時点では全社

で統一したカリキュラムを利用している

1. コップ本を読む

2. Scalaとplayを学ぶため、好きな方法で掲示板を実装してみる

（要件はカリキュラムで定義）

3. レビューを通過する

4. EricのDDD本か、Quicklyを読む

5. 掲示板をDDDで作り直す

6. レビューを突破する

新卒入社の方々には、@OE_uia氏によるScala研修や、

@yattom氏が公開されているテストのありがたみが噛みしめられ

る問題を使ったTDD演習、かとじゅん氏によるDDD研修も実施。

166新人さん教育の方法 - セプテーニ・オリジナル(発表者: 杉谷)

https://gist.github.com/yattom/567dfa484016012e21a0



発表


チームを跨ぐと車輪の再開発が沢山発生してしまった

167

49

(困った)スクラムではチームの生産性を高めることに重きを置くが、他のチームの開発状況を鑑みた全体的なシステム戦略をたてづらかった

168チームを跨ぐと車輪の再開発が沢山発生してしまった - セプテーニ・オリジナル(発表者:木村)

(解決)- プロダクト・フォーカス

プロダクト間で課題やプラクティスを共有する

- 社内Hack Days プロダクト間で抱えている課題を技術で解決する

発表


Scala人材が採用できない《求人タイム》

求人！求人です！募集中です！各社求人しています！

50

169


170Scala人材が採用できない - セプテーニ・オリジナルの場合(発表者:杉谷)

セプテーニオリジナルは常に人材を募集しています！！

〈アピールポイント〉全プロダクトScala・DDD採用 / 社外熟練者レビュアーからの実装アドバイス / テスト整備やレビュー、CI可動などの昨今の常識は当然実施 / オレオレでない教科書通りのスクラム運用 / マシマシMacbookPro / スタンディング作業ができる上下に動かせ

る流行の机 / 結構立派な社内カフェ(昼食ビュッフェ有り)

Scala未経験でもOK！ご応募お待ちしています！ご応募は弊社サイトよりどうそ

http://www.septeni-original.co.jp/

CyberZの場合

Scalaやりたい方(※未経験者OK)、Scala以外やりたい方、大募集中です！

興味のある方、話を聞いてみたい方、[email protected]までご連絡もしくは、弊社HPをご覧ください！！懇親会でも気軽にお話しましょう♪

171Scala人材が採用できない - CyberZの場合(発表者:阪本)

mailto:[email protected]

mailto:[email protected]

https://cyber-z.co.jp/recruit#_recruit-carrier

https://cyber-z.co.jp/recruit#_recruit-carrier

optの場合

採用積極的にやってます！！！！１１１

- Scala未経験でも今後業務で書いてみたい方- 1ミクロンでもオプトに興味をお持ちいただけた方

この後お話しましょう！

172Scala人材が採用できない - optの場合(発表者:勝股)

ご静聴ありがとうございました

アンケートへのご協力、よろしくお願い申し上げます。この後はLTと懇談会です。

173

scala/scrum/ddd 困ったこと50連発ガトリングトーク！！

Technology