Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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プロジェクトを並列にテスト
=> 共通プロジェクトのビルドに...
optの場合
6Scalaコンパイル遅い - optの場合(発表者:岡田)
CI速くする銀(金)の弾丸求む!
CyberZの場合
マシンスペックで
殴る!!
7Scalaコンパイル遅い - CyberZの場合(発表者:鈴木)
ただ、実際フルビルドが走らなければ、
そこまで気にならない。
エンジニアには、
MacBookProのフルスペックを支給
発表
困った!! No.  
Sparkでserializableじゃない
オブジェクトを転送してしまう
8
2
Sparkアプリの難しさ
・明示的にBroadcastしてなくても転送されたりする。
・オブジェクトのライフサイクルが掴みにくい。
・ローカルでは動いたのに分散環境ではエラーになるとかもある。。
オプトで詰まった例(解消済み)
・ロガーとかの設...
解決法
Driver / Executorのどちらで実行されるかを意識する
// 各ExecutorNodeで一度だけ実行される
lazy val unserializableObj = createUnseriarizable()
// Dr...
余談
・明示的にBroadcastするのとしないのとは何が違う?
Scalaの関数で定数を使用している場合、
関数を転送する度に値の転送も発生することになる。
ブロードキャストを使うと、定数の内容は1度だけ各executorに転送される。
fr...
発表
困った!! No.  
Scala標準のEitherが使いにくい
12
3
どういう事?
- 例えばHaskellのEitherは右側優先
- Functorのインスタンスなのでfmap関数が使える
- Monadのインスタンスでもあるのでbind演算子も
利用可能
- つまり、do記法の中でスイスイと利用可能
13S...
HaskellのEither
14Scala標準のEitherが使いにくい - opt(発表者:杉泊)
HaskellのEither
カッコいい!
素敵!
抱いて!
15Scala標準のEitherが使いにくい - opt(発表者:杉泊)
ほうほう、それで?
- 一方でScalaのEitherは左右を平等に扱う
- Either自体にはmapやflatMapメソッドが定義され
ていない
- leftメソッド、rightメソッドで〜Projection型にして
mapやflatMa...
ScalaのEither
17Scala標準のEitherが使いにくい - opt(発表者:杉泊)
ScalaのEither
なんかダサーい
無駄な記述が
多すぎる
LISPで書けば
いいのに……
18Scala標準のEitherが使いにくい - opt(発表者:杉泊)
そこで……
Scalaz./
cats.Xor
19
Scalaz./
Scala標準のEitherが使いにくい - opt(発表者:杉泊)
発表
困った!! No.  
異種のモナドをまとめてシンプルに扱いた
い
21
4
どういう事なの?
- Scalaz./の導入でエラー情報を良い感じに返せ
るようになったよ! やったね!
- でも関数の中にはOption型の返り値を返すもの
もあるよ!
- その2種類の関数を組み合わせて使う必要が出
てきたよ!
22異種のモ...
そこで
モナドトランスフォーマーを使います。
23異種のモナドをまとめてシンプルに扱いたい - opt(発表者:杉泊)
こんな補助関数を用意して、
24異種のモナドをまとめてシンプルに扱いたい - opt(発表者:杉泊)
こんな感じで使います
25異種のモナドをまとめてシンプルに扱いたい - opt(発表者:杉泊)
発表
困った!! No.  
ほとんど構造の同じcase class同士で
値をcopyしたい
26
5
異種のモナドをまとめてシンプルに扱いたい - opt(発表者:岡田) 27
shapeless・・・型の力を活かしてboilerplateを排除できたりす
る(悪名高い)便利ライブラリ
例えばLabelledGenericを使うと、case c...
28異種のモナドをまとめてシンプルに扱いたい - opt(発表者:岡田)
コンパイル時間のトレードオフがあることを理解する。 (そも
そもちゃんとモデリングしよう)
使えるじゃん!
=>コンパイル時間が増大しすぎてやめた。。。
発表
困った!! No.  
Scalaコード読みにくい問題
29
6
30
読みにくいと思ったScalaコードは、背景にある概念やパター
ンを自分が知らないだけなことも割とあった(個人の感想)
Cake pattern, Type classes, Magnet pattern, Monad, etc...
知ら...
発表
困った!! No.  
doc見てもこんなメソッド定義
されてないよぅ(implicit conversion)
31
7
問題点
 タイトルそのまま(辛い)
対応
・Intellijに聞いてみる → 次ページで説明
・むやみにワイルドカードインポートしない
・ライブラリに関しては頑張って覚える。
 (Akka/Play2/ScalikeJDBC etc...)
・...
 Intellijに聞いてみる (Akkaのサンプル)
・1にsecondsなんてメソッドない
・「actor ? ○○」 って何?
・(timeoutはどこで使われてる?)
→Intellijに聞いてみましょう
33doc見てもこんなメソッド...
 Implicit conversionは Ctrl + Shift + Q (Linux)
・1はDurationIntに変換されてるらしい。
34doc見てもこんなメソッド定義されてないよぅ(implicit conversion)- op...
 Implicit parameterは Ctrl + Shift + P (Linux)
・?がtimeoutをimplicitで使ってるらしい。
(言うまでもないが「?」はactorのメソッドでドットと括弧が省略されてる)
(ちなみにこのa...
発表
困った!! No.  
Option.get / Try.get
36
8
何のためらいもなく、普通にOptionやTryのgetが使われているこ
とがある。
37Option.get / Try.get -セプテーニ・オリジナル(発表者:杉谷)
対策
OptionはScalaで初めて遭遇したという場合が多く、扱い方と...
発表
困った!! No.  
初期のScalaのコードが辛い
38
9
Scala初心者の頃に書いたコードは辛みが多い。ある程度はボーイスカウト
ルールで解決するが
● Objectの乱用
● DB操作などFutureを使うべき場所がベタ組み
など辛みが続く失敗はできるだけ防ぎたい。
39初期のScalaのコードが...
発表
困った!! No.  
playframeworkの
バージョンアップが辛い
40
10
playframework 2.2だったGANMA!を2.5にするとき死ぬほど大変
だった
41playframeworkのバージョンアップが辛い - セプテーニ・オリジナル(発表者:杉谷)
2.2 -> 2.3(あんまり大変じゃない)
○ コ...
実際にやったときの大変さ
● なんだかんだで1ヶ月くらい修正にかかった
● 全てのファイルが書き換わった
● 現行コードの修正は日々進むので git pullっては2.5化する
日々
● リリース時に問題は大量に発生した
○ 意外とコード本編の...
発表
困った!! No.  
DAOの実装ボイラープレート化
43
11
DAO実装のボイラープレート化- セプテーニ・オリジナル(発表者: 木村) 44
(困った)
scalaプロダクトが2,3個立ち上がったところで、同じような実装をし
ていることが検出された
(解決)
DAOの実装コード/テストコードを自動生成で...
DDDの困った
45
ドメイン駆動設計に関する困り事
発表
困った!! No.  
ユビキタス言語が普及しない
DDDのユビキタス言語はみな共通で使う言葉!
…のはずなのに言い回しがどんどん変わっていく現象
12
46
セプテーニ・オリジナルの場合
言語の制定(パターン1)
1. ユビキタス言語は日本語と英語の2パターンで実装者が決める。
2. レビューでしっくりくるかどうかを念入りに揉む
言語の制定(パターン2)
設計時やストーリー起案時にユビキタス言語まで...
セプテーニ・オリジナルの場合
つらみ:ユビキタス言語が増えていくと管理が難しい
● 新しく入った人が言葉の意味を知るのが大変
● ドキュメント(Wiki等)や紙に意味をまとめても、言葉自体が成
長していくため保守しきれない
● EntityやV...
optの場合
良い名前は難しい
・名前をつける事柄や事象それ自身を良く言いあわらしていること
・それ自身だけでなくコンテキストによっても最適な名前は変わる
・その名前を扱う人々の前提知識やスキルは様々である
【過去にあったことの例】
よーしパパ...
optの場合
良い名前は難しい、
でも決まると色々捗る
名前(ユビキタス言語)がバシッと決まることで、
ビジネス・開発の双方の認識が統一され、それ自体の価値がより明確になる
【とはいえ、よくあること】
・開発が後半になって、ある機能の本質がより...
CyberZの場合
問題領域の言葉をリーダー的立場の開発者が、
同じ言葉を使って話し続ける。
↓
チーム内に言葉が浸透すると共通言語に昇格する。
↓
言葉が共通言語に昇格すると、
ドキュメントやコードに落ちていく。
51ユビキタス言語が普及しな...
発表
困った!! No.  
アーキテクチャ選定に困る
レイヤードアーキテクチャだとかヘキサゴナルアーキテクチャだとか
CQRS+ESだとか沢山あって選定に悩む
13
52
セプテーニ・オリジナルの場合
前提として、課題解決のためのアーキテクチャを目指す
明確な課題抽出ができてないアーキテクチャは採用しない
(個人がやりたいだけが理由のオレオレアーキテクチャなんて話に
なった場合は危険信号...)
53アーキテクチ...
セプテーニ・オリジナルの場合
DDDの解決
(困った)
エリック本から入門し、レイヤードアーキテクチャを採用したが、ドメインモデル
が具体的なインフラ層に依存することからドメインモデルを隔離することが難し
かった
54アーキテクチャ選定に困る ...
セプテーニ・オリジナルの場合
組織問題の解決
(困った)
❏ プロダクト間のコラボレーションがしづらい
❏ プロダクト間の依存関係をなくした上でコラボレーションしたい
❏ デプロイが依存してしまう
❏ スクラムチームが肥大化して生産性が落ちる
...
セプテーニ・オリジナルの場合
アプリケーション課題の解決する
(困った)
❏ アプリケーションの肥大化
❏ 新技術を導入しづらい/入れ替えづらい
56アーキテクチャ選定に困る - セプテーニ・オリジナルの場合(発表者:木村)
(解決)
❏ ヘキ...
optの場合
とりあえずある程度まともに動くものが作れそうなアーキテクチャ
→ちょっと難しい
動作はもちろん、適度に最適化することができ、費用対効果が高いものが作れそうな
アーキテクチャ
→かなり難しい
ある程度まともに動き、保守性が高いものが...
optの場合
(少なくともWeb系の開発においては)
アーキテクチャの難しさや複雑度の上昇は
コアな機能要件の外側が原因である(と思う)
- 性能や費用対効果
- 保守性や事業継続性
- メンバーの入れ替わりやスキルレベル
- 市場や技術のトレ...
optの場合
ヘキサゴナルアーキテクチャが言いたいことも
もしかすると何がコアで、何がそうでないかを
切り分けて開発を進めていくことが大事
ということなのかも(筆者の感想です)
59アーキテクチャ選定に困る - optの場合(発表者:平岩)
CyberZの場合
60アーキテクチャ選定に困る - CyberZの場合(発表者:島田)
課題や問題を定期的に振り返り
↓
トレンド技術をキャッチ
↓
技術検証(時間を掛ける)
↓
デザインレビュー
↓
クリーンアーキテクチャ導入
アーキテクチ...
CyberZの場合
61アーキテクチャ選定に困る - CyberZの場合(発表者:島田)
レイヤードアーキテクチャ+アクティブレコードの限界
- インフラ層の交換が事実上不可能
- 性能とDDDの両方を満たす設計が困難
- メンテナンスコストの...
発表
困った!! No.  
iOSとAndroidでDDDが効力発揮しづらい
62
14
AndroidやiOS開発は、View層の実装がほとんどになりDDDの旨
味を感じづらい。
63iOSとAndroidでDDDが効力発揮しづらい - セプテーニ・オリジナル(発表者:杉谷)
それでもやる理由
○ スマートUIパターン防止になる
...
アドテクの困った
64
ネット広告に関係する困り事
発表
困った!! No.  
4th party tracking ができなかった
65
15
◆4th party trackingとは
広告媒体に対する第三者として広告を配信する第三者配信から
連携し、配信対象ユーザーをトラッキングすること。
広告媒体
(DSPやADNW)
3PAS
4th
tracker
◆4th party tr...
◆解決法
認定済みベンダーに 4th party tracking してもらう
(当たり前)
◆背景(おまけ)
ユーザーのプライバシーを守りながら、
企業のマーケティングを推進するために、
インターネット広告業界には色々な取り組みがあります。
...
発表
困った!! No.  
略語が憶えられない(CVR,CTR,CPC,
CPA,CPM,...)
68
16
インターネット広告業界にはやたらと3文字の略語が多い
自身の生活や技術に
直接関係することもあまりないため
大変覚えづらい
69略語が憶えられない(CVR,CTR,CPC,CPA,CPM,...) - opt(発表者:平岩)
<解決するには>
各種用語を自分ごと化する。例えば…
 ・自分のブログに広告を貼って運用してみる
 ・株の運用をやってみる(性質が近い部分があるので)
 ・インターネット広告代理店を立ち上げる
[PR] 自分ごと化が難しい場合は
Opt Tec...
インフラの困った
71
AWSやデーターベース等に関する困り事
発表
困った!! No.  
EMR辛い
72
17
EMRは環境がブラックボックス
・s3の接続周りなどが特殊
 ・普通のSparkはS3スキーマに対応しておらず、hadoop-awsが必要。
 ・ローカルで同じように試せない。
・s3スキーマで出力するときにエラーが出る。。。
 ・databr...
とはいえ、他のHadoopツールより遥かに楽
(個人の感想です)
・とりあえずstdout/errに吐いとけばYARNでも見れるし、
 S3に永続化してくれる。(反映タイミングに注意)
・IAMやaws-sdkをそのまま使えるので色々捗る。
・...
発表
困った!! No.  
DynamoDBのキャパ問題
75
18
DynamoDB Table (RCU 120, WCU 60)
AWS DynamoDB はパーティション毎にシャーディングされて
データが格納されており、キャパシティ(RCU/WCU)はパーティ
ション数で分割される
- パーティション数は...
DynamoDB Table (RCU 120, WCU 60)
パーティションがたくさんある状況で、アクセスが特定のパーティ
ションに偏ると、設定しているキャパシティよりも遥かに低いI/O負
荷でキャパオーバーとなってしまう
<解決法>
Ha...
発表
困った!! No.  
マイグレーションのバージョン取り合い
78
19
マイグレーションのバージョン取り合い
● データベーススキーマ管理にflywayを利用しています
● V1__Create_user.sql, V2__…みたいに連番のSQLで変更を
入れていく
● 番号を飛ばして適用しておいて、あとで流すみた...
解決策
● コミュニケーション取るしかないよね
○ 「いまからVxxを使います」とかチャットで宣言した
り
● 可能ならスキーマ変更のみ先にPRして、あとで実装
するとか
● もっといいデータベーススキーマ管理ツールに乗り換
える
○ なんかい...
発表
困った!! No.  
AWSのコスト管理が大変
81
20
AWSのコスト管理が大変
開発者とコスト見る人が分かれていると
「なんか高くない?」に発展しにくい。
エンジニア
「Spark鯖はメモリ20Gぐらい積んどくだろJK」
結果使わなくて放置してマネージャ激おこ
AWSのコスト管理が大変
82AWS...
AWSのコスト管理が大変
エンジニア全員マネコン見れるようにした
毎月かかったコストの読み会
小さいチーム毎
大きいプロダクト単位
やってみたら思ったより面白い
適切なスペックへの変更、台数調整、
アーキテクチャレベルの変更をするように。
83...
開発ツールの困った
84
タスク管理ツールやCIなど、開発支援に関する困り事
発表
困った!! No.  
Jenkinsおじさん大量発生
85
21
・各チーム毎にJenkinsおじさんが繁殖(15人?)
・CI以外のバッチ処理にもJenkinsおじさんが活躍
・Scalaのコンパイルが重くて別のおじさん召喚
誰がどのJenkinsを使って何をやってるか把握できな
い。。
(/ω・\)チラッ...
発表
困った!! No.  
ツール繁殖問題
87
22
・かんばんツール(Backlog、Trello、redmine、
QiitaTeam、Docbase、waffle)
・チャットツール(chatworkとSlack)
・スケジューラー(Patriot、Rundeck、DigDag)
・監視(n...
発表
困った!! No.  
サブスクリプション(特にIntelliJ)の稟議が大
変
89
23
サブスクリプション導入が大変
例)IntelliJ Ultimate
最終決済権を持つ人(非エンジニア)に
ツールの利用用途を説明して、
理解してもらうまでが大変。
費用対効果の説明が利用者ではないと難しい。
サブスクリプション(特にIntel...
サブスクリプション(特にIntelliJ)の稟議が大変
対応
エンジニアMGRに決済権を委譲
(今のところ門田)
利用妥当性の確認はエンジニアMGRで。
額が大きい場合はタッグを組んで最終決済へ。
ただ、ツール選定でごまかしが効かなくなった。
...
テストの困った
92
テストを書く・維持するに関しての困り事
発表
困った!! No.  
Redshift依存のクエリのテストが難しい
93
24
Redshift依存のクエリのテストが難しい
● ローカル実行環境が作れない
● ある程度はPostgreSQLで代用
可能だが、COPYとか、
DISTKEY/SORTKEYつきの
DDLとか、Redshiftにしかない
機能をどうテストした...
解決策
● テスト用にRedshiftを立てた。。。
● 1台しか立ててないので、masterのビルド専用
● マージタイミングが近くてmasterビルドが並列に走るとテスト
が落ちる
○ ローカルでもRedshiftを使うテストコードを実行し...
発表
困った!! No.  
テストデータのIDが42
96
25
テストデータなど、意味のない数字には42を使うのが定番だと思いますが
こういうのはやめましょう
(地味にいろんな人がハマった)
教訓:account42のidを42にすること。(?)
case class Account(id: Long, n...
発表
困った!! No.  
テストの品質維持
98
26
(困った)
ホワイトボックスベースで単体テストコードを書いた結果...
- 単体テストを書くだけの目的でアクセス修飾子をゆるめたdef
private[package]、def protectedが多発した。
- テストコードを見ても仕様が埋も...
(解決)
❏ ブラックボックステストを中心に単体テストを書く
ホワイトボックステストに関しては必要な箇所だけ...
いや、その場合は別のクラスに出来ないかを検討して大体クラス分割している
❏ テストメソッドを見て仕様を理解できるか確認
❏ 単一...
チーム運営・スクラムの困った
101
チームに対して発生する様々な困り事
発表
困った!! No.  
レビューが大変
コメントと修正の応酬で、マージにたどり着かないとか
修正内容がわからないとか、いつの間にか20件ほどPRが貯まってたりとか
27
102
セプテーニ・オリジナルの場合
- 【暫定版】新人エンジニアのプルリクエスト入門
弊社社員がまとめている記事
どのようにプルリクエストをすれば通るようになるか言語化して、配布
- 指摘時に出来る限りサンプルコードは添えて
文章や言葉だけだと伝達度...
セプテーニ・オリジナルの場合
pull requestを利用した開発ワークフローを参考にレ
ビューコメントにタグを付けた
104レビューが大変 - セプテーニ・オリジナルの場合(発表者: 木村)
セプテーニ・オリジナルの場合
技術的に口が立つ人の指摘内容を全て修正するような
形になっていたが、タグを付けることで対応スコープを明
確化した
IMOで意見が食い違う時はとことん議論する
チーム形成期に意見の食い違いをそのままにすると、混
乱状...
optの場合
● 重要性を認識して、しっかり工数を取る
○ レビューを受けた修正の工数も
● コミットを意味単位できっちり分けて把握しやすくする
○ 大きな意味を持つ変更もあるので、限界はある
● 特定のレビュアーへの負荷集中を防ぐため、あらか...
optの場合
● レビューには「コードのオーナーシップ共有」の側面もあ
る
○ 「レビューで問題が見つかった」まで至らずとも、コー
ドが読まれただけで価値がある
● 大変でも逃げずに立ち向かう
107レビューが大変 - optの場合(発表者:渋...
CyberZの場合
質疑応答を口頭や
Slack/Issueでトラッキング
↓
[WIP] レビューでレビュー粒
度を細かくする
↓
レビューワーはPRが来たら
即日レビュー
108レビューが大変 - CyberZの場合(発表者: 島田)
発表
困った!! No.  
優先度の低い重要なタスクが減らない
109
28
【課題】
問題をチーム内で把握できている
しかし、いつやるかなどの方針が立っていない!!
「やんなきゃネー」「やりたいネー」
   だけが積み上がる
110優先度の低い重要なタスクが減らない - CyberZ(発表者:鈴木)
ネー(*´・ω・)...
【解決策】
・定期的なタイミングで棚卸しする場を設ける
ex) スプリントMTG etc.
・優先度があがるトリガーを用意しておく
ex) 機能の問い合わせが出始めたら
次にアラートが鳴ったら
111優先度の低い重要なタスクが減らない - Cy...
発表
困った!! No.  
トラブル時にテンパる
112
29
トラブル発生!!
↓
原因当てクイズで帰れま10
「あのドメインモデル、じゃない?」
↓
MGR「え、トラブル起きてるの??」
トラブル時にテンパる
対応
取りまとめを買って出る「俺、まとめます!」
トラブル状況確認
↓
影響範囲調査&報告
↓...
発表
困った!! No.  
プロジェクトリーダー/プロダクトマネー
ジャーがこなくなった
114
30
炎上プロジェクトにおかれたPM/PLがメンタルをやられて来なく
なってしまった。
問題を一人で抱え込み外部から問題の本質が見えず、
火消しに入った代わりのPM/PLが
何が起きているか分からないと言う自体に。
対応
ある程度の失敗を許容し、大き...
発表
困った!! No.  
遠隔地のメンバーとのコミュニケーションが
上手くいかない
116
31
海外子会社のエンジニアとプロジェクト進行するに当たり、
時差(UTC-7@16時間)の問題でスプリントMTGができず
リモートワーカーとのコミュニケーションが上手くいかず、作業連携
に失敗することがあった。
対応
情報透明性を測るために、sla...
発表
困った!! No.  
プロジェクトの掛け持ちをすると炎上する問
題
118
32
タスクや責任の所在が不明なものが増えたり、
PJの優先度が選べなくなってしまい、
結果的に炎上PJになってしまった
作成イメージ:本文ページ
対応
・スクラムの掛け持ち、ダメ絶対
・コンテキストスイッチを起こさない
・定期的にゴールとマイルスト...
発表
困った!! No.  
GitHubでのコードレビューからリアルファイ
トに発展
120
33
コードレビューのレビュアー・レビュイー間で
フラストレーションが溜まり、
最終的にリアルファイトに発展してしまった
対応
主張の場合issueにトラックするように
レビュワーが主張か事実かを判別
コメントには責任を持つよう意識改革を。
スクラム...
発表
困った!! No.  
振り返りで話題がでない
122
34
スプリントの振り返りにて課題があまり出てこない現象があった。
原因:”自分の技術的に不十分だった汚点の事で、課題があると
いう事は、悪い事で自分の評価が下がるのではないか?”という
思い込みがあった。
対策:課題を自分のことでなくても・些細なこ...
発表
困った!! No.  
プロダクトオーナー不在問題
124
35
【課題】
・プロダクトに責任を持つステークホルダが複数存在
・誰の発言が正なのかわからない
・製造しても利用者不在の事態に..
125プロダクトオーナー不在問題 - CyberZ(発表者:鈴木)
【解決策】
・専任POを役員が指名。
プロダクトの責任の所在を明確化
・POに権限委譲
POの発言をプロダクト方針とするように組織改編
運用方針が決定
素早い仕様策定
126プロダクトオーナー不在問題 - CyberZ(発表者:鈴木)
発表
困った!! No.  
デイリースクラムのレポート用意が大変
127
36
解決: 貼るホワイトボードを活用する
セプオリの多くのチームではデイリースクラムの報告をスムーズ
に行うため、ホワイトボードに板書することにしているが、何人もホ
ワイトボードに群がると大変
128デイリースクラムのレポート用意が大変 - セプテ...
発表
困った!! No.  
スプリントに技術的負債の返済チケットが入
れづらい
129
37
バグ修正やリファクタリング等の保守タスクは何も考えないと通常
業務に負けてしまう。とはいえ放っておくと衛生環境が悪くなって
しまう。やっていく気持ちをだす方策が必要
130スプリントに技術的負債の返済チケットが入れづらい - セプテーニ・オリジ...
発表
困った!! No.  
無計画な人員の増員によるスクラム破綻
131
38
(困った)
❏ スクラムチームの状況を鑑みずに増員された
❏ 今までのベロシティが無意味になった
❏ 文化継承にコストがかかった
132無計画な人員の増員によるスクラム破綻 - セプテーニ・オリジナル(発表者:木村)
(解決)
- スクラムチー...
発表
困った!! No.  
スクラムの各種会議に時間がかかる
133
39
デイリースクラムやスプリントプランニングで、事前に想定していた
時間よりも大幅に時間を超過してしまう傾向があった。
134スクラムの各種会議に時間がかかる - セプテーニ・オリジナル(発表者:杉谷)
対応
デイリースクラムについてはあくまでも報...
発表
困った!! No.  
プロダクトオーナーが上手く働かない
135
40
(困った)
コードを書かない作業はプロダクトオーナー(以下、PO)が対応す
るという暗黙的なルールができていた。
POが多忙になり、本来の業務に注力できなくなった。
136プロダクトオーナーが上手く働かない - セプテーニ・オリジナル(発表者:...
発表
困った!! No.  
スクラムの見積もりが難しい
137
41
スプリントプランニングの際に、一部の見積もりが難しいチケットに
ついて時間がかかってしまったり、時間をかけて見積もったはい
いが精度が低くなってしまう問題があった。
138スクラムの見積もりが難しい - セプテーニ・オリジナル(発表者:杉谷)
...
前回スプリントのベロシティを参考にしつつ、休みや祝日の存在を
確認した上でポイント総量を調整するようにした。
計画ミーティングは1部と2部に分け、
1. 第一部でプロダクトオーナーの意向を踏まえた大ざっぱな計
画をたてる
2. 翌日に行う第2部...
組織・文化の困った
140
会社やチーム間連携など、チームを超えた様々な困り事
発表
困った!! No.  
言語・技術に対する宗教論争・普及の道のり
新しいものの導入には様々な軋轢があったりなかったり。
各社の状況を共有
42
141
セプテーニ・オリジナルの場合
1. PHPでイケイケで作った結果破綻し、”ちゃんとやる”の気運が高まる
2. GANMA!を当時の流行(Scala / DDD / TypeScript / etc …) で作成
3. GANMA!チームに別チー...
optの場合
Scalaは何か私が入る前から使ってたので
よく知らない
(葛藤とかあったのかしらん?)
だからScalaに関しては
論争も葛藤も無ければ布教も啓蒙も無かった(ん
じゃない? 知らないけど)
143言語・技術に対する宗教論争・普及...
optの場合
そのかわりライブラリ導入に関する論争とか、議論
とか、宗教活動とか、肉体言語とかは多少あった
……ような気がする。
(Scalazとか、shapelessとか)
でも基本的に、
メンテ可能なら認められるっぽい?
手法とかはプロマネ...
optの場合
よくわかるオプトの新技術導入フロー
〜ライブラリ編〜
1. 依存性に追加して、
コードにしれっと含める
145言語・技術に対する宗教論争・普及の道のり - optの場合(発表者:杉泊)
optの場合
よくわかるオプトの新技術導入フロー
〜ライブラリ編〜
2. PRを出し、
見逃してくれそうな人に
アサインする
146言語・技術に対する宗教論争・普及の道のり - optの場合(発表者:杉泊)
optの場合
よくわかるオプトの新技術導入フロー
〜ライブラリ編〜
3. PRが通り、
無事masterにマージされる
147言語・技術に対する宗教論争・普及の道のり - optの場合(発表者:杉泊)
optの場合
よくわかるオプトの新技術導入フロー
〜ライブラリ編〜
4. やりたいようにやる
148言語・技術に対する宗教論争・普及の道のり - optの場合(発表者:杉泊)
CyberZの場合
Scalaの導入に抵抗を持つ人材はいた。
どうやって普及活動をしたか?
結局、度重なる啓蒙活動!
他の言語はゼッタイ否定しない(...?)
そこから、「Scalaいいよ」
「それScalaならできるよ」
などと甘い言葉を囁き...
発表
困った!! No.  
急いで作れ vs ちゃんと作ろう
素早く短く作れるほどビジネス成功率は高まるとはいえ
急ぎすぎても問題が。各社の方針は!?
43
150
セプテーニ・オリジナルの場合
会社としての品質の考え方、および具体的に利用する
技術やその理由・例外を記した文章「技術指針」を制定
経営から現場まで、全関係者がこれ従う。
とてもかいつまんだ内容
1. 我々は”高速高品質”を目指す
2. 我々は...
optの場合
【大前提】
QCDにはトレードオフの関係がある
【中前提】
各個人の経験値やスキルにはばらつきがある
【小前提】
面白いと思って仕事をしているときが一番パフォーマンスが良い
152急いで作れ vs ちゃんと作ろう - optの場合...
optの場合
[プロダクトチーム制への移行]
2016年下期からセールスも開発も同じチームになるプロダクトチーム制への移行を試
みます
- 「QCDにはトレードオフの関係がある」
- ビジネス側と開発側でできるだけ同じドキュメントを扱い、見える...
CyberZの場合
ビジネス要件は希望に満ち溢れている
要件通りに作っていたら「始まらない」
1ヶ月半程度でローンチ出来るプロトタイプ作成
構造は単純で安上がり。ボトルネックを明確に。
↓
市場に投下し、予算がついたタイミングで作り直し
↓
プ...
CyberZの場合
プロトタイプの「撤退基準」を明確化しておく
[いつまでに]
最長でも6ヶ月まで。
[何が出来ていないといけないか]
導入(利用)目標, 売上目標 → 達成?
システム費用対効果 → 想定どおり?
振り返りはキチンと厳格化
1...
発表
困った!! No.  
Scalaだけでなく
JavaScriptエンジニアも足りない
156
44
ScalaだけでなくJavaScriptエンジニアも足りない
● 画面がSPAだったりして、開発にはそれなりにJS
力が必要
● JS界隈のトレンド移り変わり速度が速すぎる
● JSできるエンジニアの求人票の難しさ
○ (jQueryしかできな...
解決編
● 画面側をTypeScriptに。
Scalaエンジニアも比較的
触りやすいように
○ (ん、Scala.js?)
● 一人か二人詳しい人が居
ると大変捗る
● 求人票については自分た
ちに合ったものを頑張って
考える
● マガジン記...
発表
困った!! No.  
社外勉強会を企画したのに準備が進まず
余裕がなくなる
159
45
・他人駆動型準備(ODP)
・業務時間内に発表内容や企画内容のレビュー
・人事や総務も巻き込んで会社全体で準備!
・セプさん、オプトさんみたいにタスクをどんどんレコメンドしてくれ
るような会社と一緒に勉強会を開催する
(皆様、よろしくお願いしま...
発表
困った!! No.  
プロジェクト間や部署間でのコミュニケー
ション問題
161
46
スクラムの外の他部署とコミュニケーションがうまくとれ
なくなり、お互いにいわゆるお役所仕事になってしまった
(ex:インフラや広報など)
プロジェクト間や部署間でのコミュニケーション問題
対応
ロードマップ作成時に他部門や他PJに関わるマイルス...
発表
困った!! No.  
横展開で工数削減するつもりがカオスに
なった
163
47
横展開で工数削減するつもりが、
カオスになって逆に混乱の原因となった
対応
複数システムでの共通ライブラリなど幻想
夢を見過ぎない
途中から導入しようとしない
ある程度経ったら独立して作りなおす
横展開で工数削減するつもりがカオスになった
16...
発表
困った!! No.  
新人さん教育の方法
165
48
入社された方はScalaやDDDを学ぶ段階から開始となるが、最初
は教え方が統一されておらず辛みが多かった。現時点では全社
で統一したカリキュラムを利用している
1. コップ本を読む
2. Scalaとplayを学ぶため、好きな方法で掲示板を実...
発表
困った!! No.  
チームを跨ぐと車輪の再開発が沢山発生し
てしまった
167
49
(困った)
スクラムではチームの生産性を高めることに重きを置くが、他の
チームの開発状況を鑑みた全体的なシステム戦略をたてづらかっ
た
168チームを跨ぐと車輪の再開発が沢山発生してしまった - セプテーニ・オリジナル(発表者:木村)
(解決)...
発表
困った!! No.  
Scala人材が採用できない
《求人タイム》
求人!求人です!募集中です!
各社求人しています!
50
169
セプテーニ・オリジナルの場合
170Scala人材が採用できない - セプテーニ・オリジナルの場合(発表者:杉谷)
セプテーニオリジナルは常に人材を募集しています!!
〈アピールポイント〉
全プロダクトScala・DDD採用 / 社外熟練者レビ...
CyberZの場合
Scalaやりたい方(※未経験者OK)、
Scala以外やりたい方、大募集中です!
興味のある方、話を聞いてみたい方、
saiyo@cyber-z.co.jpまでご連絡もしくは、
弊社HPをご覧ください!!
懇親会でも気軽に...
optの場合
採用積極的にやってます!!!!111
- Scala未経験でも今後業務で書いてみたい方
- 1ミクロンでもオプトに興味をお持ちいただけた方
この後お話しましょう!
172Scala人材が採用できない - optの場合(発表者:勝股)
ご静聴ありがとうございました
アンケートへのご協力、よろしくお願い申し上げます。
この後はLTと懇談会です。
173
Upcoming SlideShare
Loading in …5
×

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

9,919 views

Published on

2017/7/27に開催されたセプテーニ・オリジナル / オプト / CyberZ合同イベント「Scala/Scrum/DDD 困ったこと50連発ガトリングトーク!!」の発表資料です。

イベントページ: http://scala-scrum-ddd-gatlingtalk.connpass.com/event/34172/

Published in: Technology
  • Be the first to comment

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

  1. 1. Scala/Scrum/DDD 困ったこと50連発ガトリングトーク!! 2016年 7月 27日 株式会社セプテーニ・オリジナル / 株式会社オプト / 株式会社CyberZ 1
  2. 2. Scalaの困った 2 Scalaやフレームワークに関する困り事
  3. 3. 発表 困った!! No.   Scalaコンパイル遅い Scalaのコンパイルの遅さには皆様苦労しているはず…? 各社の対策は!? 1 3
  4. 4. セプテーニ・オリジナルの場合 当然のように金の弾丸 【セプオリ標準機】 15inch Macbook Pro Retina 2.5GHz SSD512GB 標準構成 + CPU増強 + SSD増量 = ¥272,800 4Scalaコンパイル遅い - セプテーニ・オリジナルの場合(発表者:杉谷)
  5. 5. optの場合 5Scalaコンパイル遅い - optの場合(発表者:岡田) とくにCIに時間かかって困っている。。 色々やってはみたが満足のいく結果は得られず ・複数コンテナで、sbtプロジェクトを並列にテスト => 共通プロジェクトのビルドに時間かかる ・masterと差分のあるプロジェクトのみビルドするsbtプラグイン 作った => 共通プロジェクトのビルドに時間かかり、効果微妙 ・コンテナ追加(Circle CI) => リードタイムは減らない
  6. 6. optの場合 6Scalaコンパイル遅い - optの場合(発表者:岡田) CI速くする銀(金)の弾丸求む!
  7. 7. CyberZの場合 マシンスペックで 殴る!! 7Scalaコンパイル遅い - CyberZの場合(発表者:鈴木) ただ、実際フルビルドが走らなければ、 そこまで気にならない。 エンジニアには、 MacBookProのフルスペックを支給
  8. 8. 発表 困った!! No.   Sparkでserializableじゃない オブジェクトを転送してしまう 8 2
  9. 9. Sparkアプリの難しさ ・明示的にBroadcastしてなくても転送されたりする。 ・オブジェクトのライフサイクルが掴みにくい。 ・ローカルでは動いたのに分散環境ではエラーになるとかもある。。 オプトで詰まった例(解消済み) ・ロガーとかの設定を動的にしたい。  →Driver/Executor両方で走るように書く。 ・Serializableでない、生成が重たいオブジェクトを扱いたい。  →Executorで一度だけ走るように書く。 9Sparkでserializableじゃないオブジェクトを転送してしまう - opt(発表者:柴田)
  10. 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(発表者:柴田)
  11. 11. 余談 ・明示的にBroadcastするのとしないのとは何が違う? Scalaの関数で定数を使用している場合、 関数を転送する度に値の転送も発生することになる。 ブロードキャストを使うと、定数の内容は1度だけ各executorに転送される。 from (http://www.ne.jp/asahi/hishidama/home/tech/scala/spark/SparkContext.html) 一度しか使わないなら明示的に Broadcastしないのもアリかも。 11Sparkでserializableじゃないオブジェクトを転送してしまう - opt(発表者:柴田)
  12. 12. 発表 困った!! No.   Scala標準のEitherが使いにくい 12 3
  13. 13. どういう事? - 例えばHaskellのEitherは右側優先 - Functorのインスタンスなのでfmap関数が使える - Monadのインスタンスでもあるのでbind演算子も 利用可能 - つまり、do記法の中でスイスイと利用可能 13Scala標準のEitherが使いにくい - opt(発表者:杉泊)
  14. 14. HaskellのEither 14Scala標準のEitherが使いにくい - opt(発表者:杉泊)
  15. 15. HaskellのEither カッコいい! 素敵! 抱いて! 15Scala標準のEitherが使いにくい - opt(発表者:杉泊)
  16. 16. ほうほう、それで? - 一方でScalaのEitherは左右を平等に扱う - Either自体にはmapやflatMapメソッドが定義され ていない - leftメソッド、rightメソッドで〜Projection型にして mapやflatMapを使う事はできるが…… - これらの結果はEither型を返してくる - つまり、for記法内での束縛やガードが使えない! 16Scala標準のEitherが使いにくい - opt(発表者:杉泊)
  17. 17. ScalaのEither 17Scala標準のEitherが使いにくい - opt(発表者:杉泊)
  18. 18. ScalaのEither なんかダサーい 無駄な記述が 多すぎる LISPで書けば いいのに…… 18Scala標準のEitherが使いにくい - opt(発表者:杉泊)
  19. 19. そこで…… Scalaz./ cats.Xor 19
  20. 20. Scalaz./ Scala標準のEitherが使いにくい - opt(発表者:杉泊)
  21. 21. 発表 困った!! No.   異種のモナドをまとめてシンプルに扱いた い 21 4
  22. 22. どういう事なの? - Scalaz./の導入でエラー情報を良い感じに返せ るようになったよ! やったね! - でも関数の中にはOption型の返り値を返すもの もあるよ! - その2種類の関数を組み合わせて使う必要が出 てきたよ! 22異種のモナドをまとめてシンプルに扱いたい - opt(発表者:杉泊)
  23. 23. そこで モナドトランスフォーマーを使います。 23異種のモナドをまとめてシンプルに扱いたい - opt(発表者:杉泊)
  24. 24. こんな補助関数を用意して、 24異種のモナドをまとめてシンプルに扱いたい - opt(発表者:杉泊)
  25. 25. こんな感じで使います 25異種のモナドをまとめてシンプルに扱いたい - opt(発表者:杉泊)
  26. 26. 発表 困った!! No.   ほとんど構造の同じcase class同士で 値をcopyしたい 26 5
  27. 27. 異種のモナドをまとめてシンプルに扱いたい - opt(発表者:岡田) 27 shapeless・・・型の力を活かしてboilerplateを排除できたりす る(悪名高い)便利ライブラリ 例えばLabelledGenericを使うと、case classに値を追加して 別の型のcase classにcopyみたいなことが(runtime reflection使わずに)書ける
  28. 28. 28異種のモナドをまとめてシンプルに扱いたい - opt(発表者:岡田) コンパイル時間のトレードオフがあることを理解する。 (そも そもちゃんとモデリングしよう) 使えるじゃん! =>コンパイル時間が増大しすぎてやめた。。。
  29. 29. 発表 困った!! No.   Scalaコード読みにくい問題 29 6
  30. 30. 30 読みにくいと思ったScalaコードは、背景にある概念やパター ンを自分が知らないだけなことも割とあった(個人の感想) Cake pattern, Type classes, Magnet pattern, Monad, etc... 知らないイディオム・パターンは学習しよう。(ただし、そのパ ターンを使わずに綺麗に書けないかどうかは意識する。) クリスマスプレゼントに金槌をもらった子どもは、何でも叩きたがる。 (金槌の法則 ―― ジェラルド・M・ワインバーグ) Scalaコード読みにくい問題 - opt(発表者:岡田)
  31. 31. 発表 困った!! No.   doc見てもこんなメソッド定義 されてないよぅ(implicit conversion) 31 7
  32. 32. 問題点  タイトルそのまま(辛い) 対応 ・Intellijに聞いてみる → 次ページで説明 ・むやみにワイルドカードインポートしない ・ライブラリに関しては頑張って覚える。  (Akka/Play2/ScalikeJDBC etc...) ・自分で書くときはなるべく暗黙変換しない。 32doc見てもこんなメソッド定義されてないよぅ(implicit conversion)- opt(発表者:柴田)
  33. 33.  Intellijに聞いてみる (Akkaのサンプル) ・1にsecondsなんてメソッドない ・「actor ? ○○」 って何? ・(timeoutはどこで使われてる?) →Intellijに聞いてみましょう 33doc見てもこんなメソッド定義されてないよぅ(implicit conversion)- opt(発表者:柴田)
  34. 34.  Implicit conversionは Ctrl + Shift + Q (Linux) ・1はDurationIntに変換されてるらしい。 34doc見てもこんなメソッド定義されてないよぅ(implicit conversion)- opt(発表者:柴田)
  35. 35.  Implicit parameterは Ctrl + Shift + P (Linux) ・?がtimeoutをimplicitで使ってるらしい。 (言うまでもないが「?」はactorのメソッドでドットと括弧が省略されてる) (ちなみにこのactorもActorRef → AskableActorRef へ変換されている) (sender()もimplicit parameterだが、ここではデフォルト値なので無視) (vim/emacsはどうすればいいですか? → 知らんがな) 35doc見てもこんなメソッド定義されてないよぅ(implicit conversion)- opt(発表者:柴田)
  36. 36. 発表 困った!! No.   Option.get / Try.get 36 8
  37. 37. 何のためらいもなく、普通にOptionやTryのgetが使われているこ とがある。 37Option.get / Try.get -セプテーニ・オリジナル(発表者:杉谷) 対策 OptionはScalaで初めて遭遇したという場合が多く、扱い方と重要 性を認識できていない、ということが殆どだった 見つけた場合 ● 想定していないケースを考慮することの重要性 ● 異常パターンがあるからOptionやTryになっている ● getOrElseやmapやfor式で扱う等のやり方を示す などを丁寧に共有している
  38. 38. 発表 困った!! No.   初期のScalaのコードが辛い 38 9
  39. 39. Scala初心者の頃に書いたコードは辛みが多い。ある程度はボーイスカウト ルールで解決するが ● Objectの乱用 ● DB操作などFutureを使うべき場所がベタ組み など辛みが続く失敗はできるだけ防ぎたい。 39初期のScalaのコードが辛い - セプテーニ・オリジナル(発表者:杉谷) 対策:オーバーウォッチチーム BitBucketプラグインの”Workzone”による自動レビュアー追加機能をつかっ て、社内で発生するPRにオーバーウォッチメンバー(杉谷やかとじゅん氏等)が 自動参加。アドバイスを行う。
  40. 40. 発表 困った!! No.   playframeworkの バージョンアップが辛い 40 10
  41. 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. 42. 実際にやったときの大変さ ● なんだかんだで1ヶ月くらい修正にかかった ● 全てのファイルが書き換わった ● 現行コードの修正は日々進むので git pullっては2.5化する 日々 ● リリース時に問題は大量に発生した ○ 意外とコード本編の移行は問題はあんまりなかった。 ○ 殆どはconfの構造変更時の移植ミス。confの記述が変わるからと、ついでにリ ファクタリング(環境別に1ファイル → ファイルを分割してincludeする方式)に したのがまずかった… 得られた教訓 フレームワークの更新は素早く小刻みにやりましょう!!! 42playframeworkのバージョンアップが辛い - セプテーニ・オリジナル(発表者:杉谷)
  43. 43. 発表 困った!! No.   DAOの実装ボイラープレート化 43 11
  44. 44. DAO実装のボイラープレート化- セプテーニ・オリジナル(発表者: 木村) 44 (困った) scalaプロダクトが2,3個立ち上がったところで、同じような実装をし ていることが検出された (解決) DAOの実装コード/テストコードを自動生成できないかを模索し、 具体的なストレージ技術に依存しない(ただし、JDBC依存)自動生 成ツールを企画・開発 sbt-dao-generator - 2つのプロダクトで動作中(3プロダクト目検討中) - テーブル定義が固まれば、generateしてDAOができる - 筆者のプロダクトではSkinny-ORMで利用するORM生成して いる
  45. 45. DDDの困った 45 ドメイン駆動設計に関する困り事
  46. 46. 発表 困った!! No.   ユビキタス言語が普及しない DDDのユビキタス言語はみな共通で使う言葉! …のはずなのに言い回しがどんどん変わっていく現象 12 46
  47. 47. セプテーニ・オリジナルの場合 言語の制定(パターン1) 1. ユビキタス言語は日本語と英語の2パターンで実装者が決める。 2. レビューでしっくりくるかどうかを念入りに揉む 言語の制定(パターン2) 設計時やストーリー起案時にユビキタス言語まで練る 言語普及の努力 根気よく訂正しまくる。 訂正しきれない場合、芯を捉え損ねているとしてユビキタス 言語のほうを変えてしまう。(※実装も変えます) 47ユビキタス言語が普及しない - セプテーニ・オリジナルの場合(発表者:杉谷)
  48. 48. セプテーニ・オリジナルの場合 つらみ:ユビキタス言語が増えていくと管理が難しい ● 新しく入った人が言葉の意味を知るのが大変 ● ドキュメント(Wiki等)や紙に意味をまとめても、言葉自体が成 長していくため保守しきれない ● EntityやVOなど、ドメイン層の住人のクラス定義には丁寧に 言葉の歴史を記述するように務めている ○ JavaDocからユビキタス言語辞書を作るなにかを作りたいな感 48ユビキタス言語が普及しない - セプテーニ・オリジナルの場合(発表者:杉谷)
  49. 49. optの場合 良い名前は難しい ・名前をつける事柄や事象それ自身を良く言いあわらしていること ・それ自身だけでなくコンテキストによっても最適な名前は変わる ・その名前を扱う人々の前提知識やスキルは様々である 【過去にあったことの例】 よーしパパ ユビキタス言語を決めるべく用語集作っちゃうぞー  ↓  ・ユビキタス言語を決めること自体が難しいし、   イケてないと簡単に別の名前で呼ばれる(特にマーケティング用語)  ・用語集のメンテしてんの俺だけじゃん  ↓ 別にメンテしなくてよくね? 49ユビキタス言語が普及しない - optの場合(発表者:平岩)
  50. 50. optの場合 良い名前は難しい、 でも決まると色々捗る 名前(ユビキタス言語)がバシッと決まることで、 ビジネス・開発の双方の認識が統一され、それ自体の価値がより明確になる 【とはいえ、よくあること】 ・開発が後半になって、ある機能の本質がよりはっきりしてくると、良い名前がつけられることがある ・それ自身は変わっていないのに、外部環境の変化により、名前を変えたほうが良いことがある 名前(ユビキタス言語)自体を決めることよりも、 ・ビジネス側と開発側が対話を続けること ・名前の変更が簡単な設計になっていること が重要なのかも! 50ユビキタス言語が普及しない - optの場合(発表者:平岩)
  51. 51. CyberZの場合 問題領域の言葉をリーダー的立場の開発者が、 同じ言葉を使って話し続ける。 ↓ チーム内に言葉が浸透すると共通言語に昇格する。 ↓ 言葉が共通言語に昇格すると、 ドキュメントやコードに落ちていく。 51ユビキタス言語が普及しない - CyberZの場合(発表者:島田)
  52. 52. 発表 困った!! No.   アーキテクチャ選定に困る レイヤードアーキテクチャだとかヘキサゴナルアーキテクチャだとか CQRS+ESだとか沢山あって選定に悩む 13 52
  53. 53. セプテーニ・オリジナルの場合 前提として、課題解決のためのアーキテクチャを目指す 明確な課題抽出ができてないアーキテクチャは採用しない (個人がやりたいだけが理由のオレオレアーキテクチャなんて話に なった場合は危険信号...) 53アーキテクチャ選定に困る - セプテーニ・オリジナルの場合(発表者:木村)
  54. 54. セプテーニ・オリジナルの場合 DDDの解決 (困った) エリック本から入門し、レイヤードアーキテクチャを採用したが、ドメインモデル が具体的なインフラ層に依存することからドメインモデルを隔離することが難し かった 54アーキテクチャ選定に困る - セプテーニ・オリジナルの場合(発表者:木村) (解決) IDDDを参考に依存関係逆転の原則(DIP)を取り入れ、その延長線でヘキサゴ ナルアーキテクチャに発展させる。 Scalaで学ぶヘキサゴナルアーキテクチャ実践入門 開発が進むにつれて参照用だけのクエリモデルが増え、ドメインモデルの管理コストが かかることがあり、 コマンドモデルとクエリモデルを分けるCQRSなどのアーキテクチャを考察中
  55. 55. セプテーニ・オリジナルの場合 組織問題の解決 (困った) ❏ プロダクト間のコラボレーションがしづらい ❏ プロダクト間の依存関係をなくした上でコラボレーションしたい ❏ デプロイが依存してしまう ❏ スクラムチームが肥大化して生産性が落ちる ❏ 意思決定の遅延 ❏ ベロシティの無意味化 55アーキテクチャ選定に困る - セプテーニ・オリジナルの場合(発表者:木村) (解決)[WIP] 戦略的設計で定義した境界づけられたコンテキストの1部をマイクロサービス化 マイクロサービス単位でスクラムチームを組成
  56. 56. セプテーニ・オリジナルの場合 アプリケーション課題の解決する (困った) ❏ アプリケーションの肥大化 ❏ 新技術を導入しづらい/入れ替えづらい 56アーキテクチャ選定に困る - セプテーニ・オリジナルの場合(発表者:木村) (解決) ❏ ヘキサゴナルアーキテクチャのPort/Adapterを定義 ❏ マイクロサービスアーキテクチャでアプリケーションをコンパクトに
  57. 57. optの場合 とりあえずある程度まともに動くものが作れそうなアーキテクチャ →ちょっと難しい 動作はもちろん、適度に最適化することができ、費用対効果が高いものが作れそうな アーキテクチャ →かなり難しい ある程度まともに動き、保守性が高いものが作れそうで、新メンバーも理解しやすい アーキテクチャ →とても難しい ある程度最適化することができ、保守性や理解のしやすさも担保しやすいアーキテク チャ →難しいってレベルじゃない 57アーキテクチャ選定に困る - optの場合(発表者:平岩)
  58. 58. optの場合 (少なくともWeb系の開発においては) アーキテクチャの難しさや複雑度の上昇は コアな機能要件の外側が原因である(と思う) - 性能や費用対効果 - 保守性や事業継続性 - メンバーの入れ替わりやスキルレベル - 市場や技術のトレンド だから、何がコアで、何がそうでないかを 切り分けて開発を進めていくことが大事 58アーキテクチャ選定に困る - optの場合(発表者:平岩)
  59. 59. optの場合 ヘキサゴナルアーキテクチャが言いたいことも もしかすると何がコアで、何がそうでないかを 切り分けて開発を進めていくことが大事 ということなのかも(筆者の感想です) 59アーキテクチャ選定に困る - optの場合(発表者:平岩)
  60. 60. CyberZの場合 60アーキテクチャ選定に困る - CyberZの場合(発表者:島田) 課題や問題を定期的に振り返り ↓ トレンド技術をキャッチ ↓ 技術検証(時間を掛ける) ↓ デザインレビュー ↓ クリーンアーキテクチャ導入 アーキテクチャ検証の過程 [クリーンアーキテクチャの場合]
  61. 61. CyberZの場合 61アーキテクチャ選定に困る - CyberZの場合(発表者:島田) レイヤードアーキテクチャ+アクティブレコードの限界 - インフラ層の交換が事実上不可能 - 性能とDDDの両方を満たす設計が困難 - メンテナンスコストの肥大とそれに伴うエンジニアの疲弊 - トランザクションスクリプト的な実装が散見された クリーンアーキテクチャの導入した所感 - インフラレイヤの検証に時間を掛けられた - DIP(依存関係の逆転)で方針と詳細の分離出来る為、テストが書きやすい - React.js + Flux.js と設計が類似しており、メンバーが馴染みやすかった - 新人2名(+レビューワ2名)が1ヶ月で1プロダクトリリース出来るほどの生産性 の高さを確かめることが出来た
  62. 62. 発表 困った!! No.   iOSとAndroidでDDDが効力発揮しづらい 62 14
  63. 63. AndroidやiOS開発は、View層の実装がほとんどになりDDDの旨 味を感じづらい。 63iOSとAndroidでDDDが効力発揮しづらい - セプテーニ・オリジナル(発表者:杉谷) それでもやる理由 ○ スマートUIパターン防止になる ■ サーバ側・クライアント側のドメイン層が無茶を防ぐ スマートUIになっても大丈夫な方法があると、安全なまま効率の 良い実装ができるかも? ○ CQRS(コマンドクエリ責務分離)を取り入れるとOK ○ リード側とライト側を分離することによって、ライト系はシンプル・堅牢に、リード 系はバリエーション豊かにできる設計方針 ○ 詳細はこちらを参照 将軍祭り:かとじゅん氏発表 最新DDDアーキテクチャとAkkaでの実装ヒントに ついて
  64. 64. アドテクの困った 64 ネット広告に関係する困り事
  65. 65. 発表 困った!! No.   4th party tracking ができなかった 65 15
  66. 66. ◆4th party trackingとは 広告媒体に対する第三者として広告を配信する第三者配信から 連携し、配信対象ユーザーをトラッキングすること。 広告媒体 (DSPやADNW) 3PAS 4th tracker ◆4th party tracking がダメだったわけ プラットフォーマーに認定されてないベンダーによるトラッキング だったから(当たり前) 664th party tracking ができなかった - opt(発表者:平岩)
  67. 67. ◆解決法 認定済みベンダーに 4th party tracking してもらう (当たり前) ◆背景(おまけ) ユーザーのプライバシーを守りながら、 企業のマーケティングを推進するために、 インターネット広告業界には色々な取り組みがあります。 - 広告入稿時の審査 - 各プラットフォーマーによる認定制度 - 国際業界団体(IAB)による標準規格策定 - 業界団体(JIAA)によるリテラシー向上施策(勉強会や分科会) - オプトアウトの標準化(NAI, DDAI) 674th party tracking ができなかった - opt(発表者:平岩)
  68. 68. 発表 困った!! No.   略語が憶えられない(CVR,CTR,CPC, CPA,CPM,...) 68 16
  69. 69. インターネット広告業界にはやたらと3文字の略語が多い 自身の生活や技術に 直接関係することもあまりないため 大変覚えづらい 69略語が憶えられない(CVR,CTR,CPC,CPA,CPM,...) - opt(発表者:平岩)
  70. 70. <解決するには> 各種用語を自分ごと化する。例えば…  ・自分のブログに広告を貼って運用してみる  ・株の運用をやってみる(性質が近い部分があるので)  ・インターネット広告代理店を立ち上げる [PR] 自分ごと化が難しい場合は Opt Technologies の Tech Magazine で 「5分くらいで読めるエンジニアのための  インターネット広告講座」を読む http://tech-magazine.opt.ne.jp/entry/2016/06/22/120453 70略語が憶えられない(CVR,CTR,CPC,CPA,CPM,...) - opt(発表者:平岩)
  71. 71. インフラの困った 71 AWSやデーターベース等に関する困り事
  72. 72. 発表 困った!! No.   EMR辛い 72 17
  73. 73. EMRは環境がブラックボックス ・s3の接続周りなどが特殊  ・普通のSparkはS3スキーマに対応しておらず、hadoop-awsが必要。  ・ローカルで同じように試せない。 ・s3スキーマで出力するときにエラーが出る。。。  ・databricksのDirectOutputCommitterを参考にして凌いだ。 ・クラスタの縮退がなんか上手くいかない。  ・社内の識者曰く、「AWSコンソールの仕様」らしい。辛み。。。 73EMR辛い - opt(発表者:柴田)
  74. 74. とはいえ、他のHadoopツールより遥かに楽 (個人の感想です) ・とりあえずstdout/errに吐いとけばYARNでも見れるし、  S3に永続化してくれる。(反映タイミングに注意) ・IAMやaws-sdkをそのまま使えるので色々捗る。 ・パラメータチューニングがある程度されている。 ・GangliaやZeppelinがすぐ使えてすごく楽。  \アッカリ~ン/ <わぁいEMR あかりEMR大好き 74EMR辛い - opt(発表者:柴田)
  75. 75. 発表 困った!! No.   DynamoDBのキャパ問題 75 18
  76. 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. 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(発表者:平岩)
  78. 78. 発表 困った!! No.   マイグレーションのバージョン取り合い 78 19
  79. 79. マイグレーションのバージョン取り合い ● データベーススキーマ管理にflywayを利用しています ● V1__Create_user.sql, V2__…みたいに連番のSQLで変更を 入れていく ● 番号を飛ばして適用しておいて、あとで流すみたいにできない ○ ActiveRecordとかだと楽勝でできるのに… ● 番号がかち合うと当然エラーが出て、解消めんどくさい ○ rollbackが手動ですし。。 →早いもの勝ち!? 79マイグレーションのバージョン取り合い - opt(発表者:渋谷)
  80. 80. 解決策 ● コミュニケーション取るしかないよね ○ 「いまからVxxを使います」とかチャットで宣言した り ● 可能ならスキーマ変更のみ先にPRして、あとで実装 するとか ● もっといいデータベーススキーマ管理ツールに乗り換 える ○ なんかいいのないですかね? 80マイグレーションのバージョン取り合い - opt(発表者:渋谷)
  81. 81. 発表 困った!! No.   AWSのコスト管理が大変 81 20
  82. 82. AWSのコスト管理が大変 開発者とコスト見る人が分かれていると 「なんか高くない?」に発展しにくい。 エンジニア 「Spark鯖はメモリ20Gぐらい積んどくだろJK」 結果使わなくて放置してマネージャ激おこ AWSのコスト管理が大変 82AWSのコスト管理が大変 - CyberZ(発表者:門田)
  83. 83. AWSのコスト管理が大変 エンジニア全員マネコン見れるようにした 毎月かかったコストの読み会 小さいチーム毎 大きいプロダクト単位 やってみたら思ったより面白い 適切なスペックへの変更、台数調整、 アーキテクチャレベルの変更をするように。 83AWSのコスト管理が大変 - CyberZ(発表者:門田) 解決策
  84. 84. 開発ツールの困った 84 タスク管理ツールやCIなど、開発支援に関する困り事
  85. 85. 発表 困った!! No.   Jenkinsおじさん大量発生 85 21
  86. 86. ・各チーム毎にJenkinsおじさんが繁殖(15人?) ・CI以外のバッチ処理にもJenkinsおじさんが活躍 ・Scalaのコンパイルが重くて別のおじさん召喚 誰がどのJenkinsを使って何をやってるか把握できな い。。 (/ω・\)チラッ 作成イメージ:本文ページ 対応 第一次Jenkinsリストラ計画 ・バッチスケジューラ導入 ・CirclCIに移行 86Jenkinsおじさん大量発生 - CyberZ(発表者:遠藤)
  87. 87. 発表 困った!! No.   ツール繁殖問題 87 22
  88. 88. ・かんばんツール(Backlog、Trello、redmine、 QiitaTeam、Docbase、waffle) ・チャットツール(chatworkとSlack) ・スケジューラー(Patriot、Rundeck、DigDag) ・監視(nagiosとzabbix、cacti、datadog) ・CI(JenkinsとCircleCI) etc,etc ツール繁殖問題 対応 断捨離 1ついれたら1つ捨てる 88ツール繁殖問題 - CyberZ(発表者:遠藤)
  89. 89. 発表 困った!! No.   サブスクリプション(特にIntelliJ)の稟議が大 変 89 23
  90. 90. サブスクリプション導入が大変 例)IntelliJ Ultimate 最終決済権を持つ人(非エンジニア)に ツールの利用用途を説明して、 理解してもらうまでが大変。 費用対効果の説明が利用者ではないと難しい。 サブスクリプション(特にIntelliJ)の稟議が大変 90サブスクリプション(特にIntelliJ)の稟議が大変 - CyberZ(発表者:門田)
  91. 91. サブスクリプション(特にIntelliJ)の稟議が大変 対応 エンジニアMGRに決済権を委譲 (今のところ門田) 利用妥当性の確認はエンジニアMGRで。 額が大きい場合はタッグを組んで最終決済へ。 ただ、ツール選定でごまかしが効かなくなった。 「え。それってスタンダードじゃないけど、 なんで導入するの?比較検討はしたの?」 91サブスクリプション(特にIntelliJ)の稟議が大変 - CyberZ(発表者:門田)
  92. 92. テストの困った 92 テストを書く・維持するに関しての困り事
  93. 93. 発表 困った!! No.   Redshift依存のクエリのテストが難しい 93 24
  94. 94. Redshift依存のクエリのテストが難しい ● ローカル実行環境が作れない ● ある程度はPostgreSQLで代用 可能だが、COPYとか、 DISTKEY/SORTKEYつきの DDLとか、Redshiftにしかない 機能をどうテストしたらいいのか 94Redshift依存のクエリのテストが難しい - opt(発表者:渋谷)
  95. 95. 解決策 ● テスト用にRedshiftを立てた。。。 ● 1台しか立ててないので、masterのビルド専用 ● マージタイミングが近くてmasterビルドが並列に走るとテスト が落ちる ○ ローカルでもRedshiftを使うテストコードを実行したいこと がある ○ 複数人でローカルテストを実行+masterのビルドが走って いる、みたいな状況もあってカオス ● 接続ごとに別のテーブルを使うように変更して、解決したい(願 望) 95Redshift依存のクエリのテストが難しい - opt(発表者:渋谷)
  96. 96. 発表 困った!! No.   テストデータのIDが42 96 25
  97. 97. テストデータなど、意味のない数字には42を使うのが定番だと思いますが こういうのはやめましょう (地味にいろんな人がハマった) 教訓:account42のidを42にすること。(?) case class Account(id: Long, name: String) object Fixtures { val account1 = Account(42L, “Martin Odersky”) } 97テストデータのIDが42 - opt(発表者:岡田)
  98. 98. 発表 困った!! No.   テストの品質維持 98 26
  99. 99. (困った) ホワイトボックスベースで単体テストコードを書いた結果... - 単体テストを書くだけの目的でアクセス修飾子をゆるめたdef private[package]、def protectedが多発した。 - テストコードを見ても仕様が埋もれてしまった - クラスの責務が大きいものが増えた(もちろん原因は他にもある...) - リファクタリングの妨げになった 内部実装を変更する時にpublicメソッドのアウトプットは変わらないのにテスト を書き直さくてはならなくなった 異論はあるかと思いますが、実際に運用してみて苦労した... 99テストの品質維持 - セプテーニ・オリジナル(発表者:木村)
  100. 100. (解決) ❏ ブラックボックステストを中心に単体テストを書く ホワイトボックステストに関しては必要な箇所だけ... いや、その場合は別のクラスに出来ないかを検討して大体クラス分割している ❏ テストメソッドを見て仕様を理解できるか確認 ❏ 単一責務になっているかを確認 ❏ アクセス修飾子がテストのために変更されていないかを確認 確認=プルリクエストで確認 100テストの品質維持 - セプテーニ・オリジナル(発表者:木村)
  101. 101. チーム運営・スクラムの困った 101 チームに対して発生する様々な困り事
  102. 102. 発表 困った!! No.   レビューが大変 コメントと修正の応酬で、マージにたどり着かないとか 修正内容がわからないとか、いつの間にか20件ほどPRが貯まってたりとか 27 102
  103. 103. セプテーニ・オリジナルの場合 - 【暫定版】新人エンジニアのプルリクエスト入門 弊社社員がまとめている記事 どのようにプルリクエストをすれば通るようになるか言語化して、配布 - 指摘時に出来る限りサンプルコードは添えて 文章や言葉だけだと伝達度にばらつきがあるので - レビュー指摘は愛だとメンバーに伝える 指摘事項が多くなると険悪なムードになりがちなので 103レビューが大変 - セプテーニ・オリジナルの場合(発表者: 木村)
  104. 104. セプテーニ・オリジナルの場合 pull requestを利用した開発ワークフローを参考にレ ビューコメントにタグを付けた 104レビューが大変 - セプテーニ・オリジナルの場合(発表者: 木村)
  105. 105. セプテーニ・オリジナルの場合 技術的に口が立つ人の指摘内容を全て修正するような 形になっていたが、タグを付けることで対応スコープを明 確化した IMOで意見が食い違う時はとことん議論する チーム形成期に意見の食い違いをそのままにすると、混 乱状態が続き、成熟期を迎えられないと考え議論のコス トを支払う方向に倒す 105レビューが大変 - セプテーニ・オリジナルの場合(発表者: 木村)
  106. 106. optの場合 ● 重要性を認識して、しっかり工数を取る ○ レビューを受けた修正の工数も ● コミットを意味単位できっちり分けて把握しやすくする ○ 大きな意味を持つ変更もあるので、限界はある ● 特定のレビュアーへの負荷集中を防ぐため、あらかじめ 複数人をアサイン ○ 今後導入予定 106レビューが大変 - optの場合(発表者:渋谷 )
  107. 107. optの場合 ● レビューには「コードのオーナーシップ共有」の側面もあ る ○ 「レビューで問題が見つかった」まで至らずとも、コー ドが読まれただけで価値がある ● 大変でも逃げずに立ち向かう 107レビューが大変 - optの場合(発表者:渋谷 )
  108. 108. CyberZの場合 質疑応答を口頭や Slack/Issueでトラッキング ↓ [WIP] レビューでレビュー粒 度を細かくする ↓ レビューワーはPRが来たら 即日レビュー 108レビューが大変 - CyberZの場合(発表者: 島田)
  109. 109. 発表 困った!! No.   優先度の低い重要なタスクが減らない 109 28
  110. 110. 【課題】 問題をチーム内で把握できている しかし、いつやるかなどの方針が立っていない!! 「やんなきゃネー」「やりたいネー」    だけが積み上がる 110優先度の低い重要なタスクが減らない - CyberZ(発表者:鈴木) ネー(*´・ω・)(*´・д・`*)(・ω・`*)ネー
  111. 111. 【解決策】 ・定期的なタイミングで棚卸しする場を設ける ex) スプリントMTG etc. ・優先度があがるトリガーを用意しておく ex) 機能の問い合わせが出始めたら 次にアラートが鳴ったら 111優先度の低い重要なタスクが減らない - CyberZ(発表者:鈴木)
  112. 112. 発表 困った!! No.   トラブル時にテンパる 112 29
  113. 113. トラブル発生!! ↓ 原因当てクイズで帰れま10 「あのドメインモデル、じゃない?」 ↓ MGR「え、トラブル起きてるの??」 トラブル時にテンパる 対応 取りまとめを買って出る「俺、まとめます!」 トラブル状況確認 ↓ 影響範囲調査&報告 ↓ 進め方を決める 113トラブル時にテンパる - CyberZ(発表者:遠藤)
  114. 114. 発表 困った!! No.   プロジェクトリーダー/プロダクトマネー ジャーがこなくなった 114 30
  115. 115. 炎上プロジェクトにおかれたPM/PLがメンタルをやられて来なく なってしまった。 問題を一人で抱え込み外部から問題の本質が見えず、 火消しに入った代わりのPM/PLが 何が起きているか分からないと言う自体に。 対応 ある程度の失敗を許容し、大きな問題とならないように改善に繋 がるための心理的な安全を確保するようにした。 一人で抱え込むことが無いように、1 on 1 KPTでチームメンバー全員で課題の認識や 解決に対して取り組む場を設けた プロジェクトリーダー /プロダクトマネージャーが こなくなった 115プロジェクトリーダー/プロダクトマネージャーがこなくなった - cyberZ(発表者:島田)
  116. 116. 発表 困った!! No.   遠隔地のメンバーとのコミュニケーションが 上手くいかない 116 31
  117. 117. 海外子会社のエンジニアとプロジェクト進行するに当たり、 時差(UTC-7@16時間)の問題でスプリントMTGができず リモートワーカーとのコミュニケーションが上手くいかず、作業連携 に失敗することがあった。 対応 情報透明性を測るために、slackで分報の導入、日報の義務化、 GitHubでの仕様議論などツール類の整備化をすすめた ビデオ会議の生産性向上が極めて重要 ノイズキャンセルスピーカーマイクが非常に効果的 たまに帰国してもらい顔を合わせて話す 遠隔地のメンバーとのコミュニケーションが上手くいかない 117遠隔地のメンバーとのコミュニケーションが上手くいかない - CyberZ(発表者:島田)
  118. 118. 発表 困った!! No.   プロジェクトの掛け持ちをすると炎上する問 題 118 32
  119. 119. タスクや責任の所在が不明なものが増えたり、 PJの優先度が選べなくなってしまい、 結果的に炎上PJになってしまった 作成イメージ:本文ページ 対応 ・スクラムの掛け持ち、ダメ絶対 ・コンテキストスイッチを起こさない ・定期的にゴールとマイルストーンを確認 119プロジェクトの掛け持ちをすると炎上する問題 - CyberZ(発表者:遠藤)
  120. 120. 発表 困った!! No.   GitHubでのコードレビューからリアルファイ トに発展 120 33
  121. 121. コードレビューのレビュアー・レビュイー間で フラストレーションが溜まり、 最終的にリアルファイトに発展してしまった 対応 主張の場合issueにトラックするように レビュワーが主張か事実かを判別 コメントには責任を持つよう意識改革を。 スクラムマスタが心理的安全性を 高めるチームメイク 謙虚(Humility) 尊敬(Respect) 信頼(Trust) GitHubでのコードレビューからリアルファイトに発展 121GitHubでのコードレビューからリアルファイトに発展 - CyberZ(発表者:島田)
  122. 122. 発表 困った!! No.   振り返りで話題がでない 122 34
  123. 123. スプリントの振り返りにて課題があまり出てこない現象があった。 原因:”自分の技術的に不十分だった汚点の事で、課題があると いう事は、悪い事で自分の評価が下がるのではないか?”という 思い込みがあった。 対策:課題を自分のことでなくても・些細なことでもよいので出来る だけ書いてもらったりするようにした。またプロダクトオーナーやス クラムマスターが出来るだけ反省事を拾うようにした(もちろん、責 めにならないように注意する) これを起点に意見を出し → 改善を積み重ねでチームが良くなっ ていくことを全員で実感し、改善していった。 123振り返りで話題がでない - セプテーニ・オリジナル(発表者:杉谷)
  124. 124. 発表 困った!! No.   プロダクトオーナー不在問題 124 35
  125. 125. 【課題】 ・プロダクトに責任を持つステークホルダが複数存在 ・誰の発言が正なのかわからない ・製造しても利用者不在の事態に.. 125プロダクトオーナー不在問題 - CyberZ(発表者:鈴木)
  126. 126. 【解決策】 ・専任POを役員が指名。 プロダクトの責任の所在を明確化 ・POに権限委譲 POの発言をプロダクト方針とするように組織改編 運用方針が決定 素早い仕様策定 126プロダクトオーナー不在問題 - CyberZ(発表者:鈴木)
  127. 127. 発表 困った!! No.   デイリースクラムのレポート用意が大変 127 36
  128. 128. 解決: 貼るホワイトボードを活用する セプオリの多くのチームではデイリースクラムの報告をスムーズ に行うため、ホワイトボードに板書することにしているが、何人もホ ワイトボードに群がると大変 128デイリースクラムのレポート用意が大変 - セプテーニ・オリジナル(発表者:杉谷) 難点:貼るホワイトボードが高い(約1500円/枚)
  129. 129. 発表 困った!! No.   スプリントに技術的負債の返済チケットが入 れづらい 129 37
  130. 130. バグ修正やリファクタリング等の保守タスクは何も考えないと通常 業務に負けてしまう。とはいえ放っておくと衛生環境が悪くなって しまう。やっていく気持ちをだす方策が必要 130スプリントに技術的負債の返済チケットが入れづらい - セプテーニ・オリジナル(発表者:杉谷) ● 保守系タスクをスプリントにいれるのはプロダクトオーナーの 義務 ○ 会社方針としてもこれは明示 ○ 毎スプリントに一定数、保守系チケットを盛り込む運用等で実現 ● そもそも保守系タスクが出にくいように頑張る ○ 開発者による手運用(DB直操作など)が出る仕様は厳禁 ○ 技術的負債が残る工法は出来るだけ選ばない。どうしても必要ならちゃんと関 係者全員が説明を受け納得した上で行う。
  131. 131. 発表 困った!! No.   無計画な人員の増員によるスクラム破綻 131 38
  132. 132. (困った) ❏ スクラムチームの状況を鑑みずに増員された ❏ 今までのベロシティが無意味になった ❏ 文化継承にコストがかかった 132無計画な人員の増員によるスクラム破綻 - セプテーニ・オリジナル(発表者:木村) (解決) - スクラムチームの枠を超え、経営戦略を理解し、適切 なチーム構成を話し合い、適切なアーキテクチャ設計 を立てる - だいたい半年単位インセプションデッキを再定義
  133. 133. 発表 困った!! No.   スクラムの各種会議に時間がかかる 133 39
  134. 134. デイリースクラムやスプリントプランニングで、事前に想定していた 時間よりも大幅に時間を超過してしまう傾向があった。 134スクラムの各種会議に時間がかかる - セプテーニ・オリジナル(発表者:杉谷) 対応 デイリースクラムについてはあくまでも報告の場とし、問題の解決 の場ではないということを徹底するようにした。何らかのアクション が必要そうな事案については、どのメンバーで対応するかのみ決 め、デイリースクラム後に別途時間を取るようにした。 スプリントプランニングについては、詳細部分まで話し合っていた ことが時間がかかっていた原因だったため、設計チケットを細かく 作成し、詳細部分については担当メンバーに一任するようにし、レ ビューを厚くするような体制にした。
  135. 135. 発表 困った!! No.   プロダクトオーナーが上手く働かない 135 40
  136. 136. (困った) コードを書かない作業はプロダクトオーナー(以下、PO)が対応す るという暗黙的なルールができていた。 POが多忙になり、本来の業務に注力できなくなった。 136プロダクトオーナーが上手く働かない - セプテーニ・オリジナル(発表者:木村) (解決) POの必須作業を明文化し、それ以外の作業についてはチーム内 で分担するようにした。 また、POに求めることを技術指針として明文化(POはステークホ ルダーとチームのバランスを取る必要があり、衛生を保つために 時として技術的負債の返却にも協力する必要がある) し、チーム 内で認識を共有できるようにした。
  137. 137. 発表 困った!! No.   スクラムの見積もりが難しい 137 41
  138. 138. スプリントプランニングの際に、一部の見積もりが難しいチケットに ついて時間がかかってしまったり、時間をかけて見積もったはい いが精度が低くなってしまう問題があった。 138スクラムの見積もりが難しい - セプテーニ・オリジナル(発表者:杉谷) 対応 「見積もりが難しい = チケットの粒度が大きすぎる」という傾向が あったため、極力ブレークダウンしてから見積もりをするようにし た。 事前に検証や調査が必要そうなチケットについては、設計及び実 装を行うスプリントよりも前のスプリントで検証/調査チケットを入れ るようにした。
  139. 139. 前回スプリントのベロシティを参考にしつつ、休みや祝日の存在を 確認した上でポイント総量を調整するようにした。 計画ミーティングは1部と2部に分け、 1. 第一部でプロダクトオーナーの意向を踏まえた大ざっぱな計 画をたてる 2. 翌日に行う第2部までに要件で怪しい箇所を確認する 3. 第二部では、実装内容やブロッカーの存在を確認、ある程度 具体的に作業が想像できるまでエンジニアのみで検討 という段取りを踏むようにした 139スクラムの見積もりが難しい - セプテーニ・オリジナル(発表者:杉谷)
  140. 140. 組織・文化の困った 140 会社やチーム間連携など、チームを超えた様々な困り事
  141. 141. 発表 困った!! No.   言語・技術に対する宗教論争・普及の道のり 新しいものの導入には様々な軋轢があったりなかったり。 各社の状況を共有 42 141
  142. 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%】
  143. 143. optの場合 Scalaは何か私が入る前から使ってたので よく知らない (葛藤とかあったのかしらん?) だからScalaに関しては 論争も葛藤も無ければ布教も啓蒙も無かった(ん じゃない? 知らないけど) 143言語・技術に対する宗教論争・普及の道のり - optの場合(発表者:杉泊)
  144. 144. optの場合 そのかわりライブラリ導入に関する論争とか、議論 とか、宗教活動とか、肉体言語とかは多少あった ……ような気がする。 (Scalazとか、shapelessとか) でも基本的に、 メンテ可能なら認められるっぽい? 手法とかはプロマネの人が推せば良いんじゃない のだろうか(DDDとかscrumとか) 144言語・技術に対する宗教論争・普及の道のり - optの場合(発表者:杉泊)
  145. 145. optの場合 よくわかるオプトの新技術導入フロー 〜ライブラリ編〜 1. 依存性に追加して、 コードにしれっと含める 145言語・技術に対する宗教論争・普及の道のり - optの場合(発表者:杉泊)
  146. 146. optの場合 よくわかるオプトの新技術導入フロー 〜ライブラリ編〜 2. PRを出し、 見逃してくれそうな人に アサインする 146言語・技術に対する宗教論争・普及の道のり - optの場合(発表者:杉泊)
  147. 147. optの場合 よくわかるオプトの新技術導入フロー 〜ライブラリ編〜 3. PRが通り、 無事masterにマージされる 147言語・技術に対する宗教論争・普及の道のり - optの場合(発表者:杉泊)
  148. 148. optの場合 よくわかるオプトの新技術導入フロー 〜ライブラリ編〜 4. やりたいようにやる 148言語・技術に対する宗教論争・普及の道のり - optの場合(発表者:杉泊)
  149. 149. CyberZの場合 Scalaの導入に抵抗を持つ人材はいた。 どうやって普及活動をしたか? 結局、度重なる啓蒙活動! 他の言語はゼッタイ否定しない(...?) そこから、「Scalaいいよ」 「それScalaならできるよ」 などと甘い言葉を囁き続ける 149言語・技術に対する宗教論争・普及の道のり - CyberZの場合(発表者:鈴木)
  150. 150. 発表 困った!! No.   急いで作れ vs ちゃんと作ろう 素早く短く作れるほどビジネス成功率は高まるとはいえ 急ぎすぎても問題が。各社の方針は!? 43 150
  151. 151. セプテーニ・オリジナルの場合 会社としての品質の考え方、および具体的に利用する 技術やその理由・例外を記した文章「技術指針」を制定 経営から現場まで、全関係者がこれ従う。 とてもかいつまんだ内容 1. 我々は”高速高品質”を目指す 2. 我々は保守性のあるコードを高速に生産する 3. Scalaを使う理由は気軽に品質を維持するため / Scalaを利用しない場合 4. スクラムを採用する理由はプロダクトオーナーがハンドルを握るため / スクラム以外を利用する場合 5. DDDを採用するのはチーム全員で要件の芯を捉え続けるため / DDDを採用しない場合 6. ユニットテストを書く理由はリファクタリングをし続けるため / テストを書く=遅いという思い込みを止めよう / テストを書かない場合 7. レビューを行うのは意識を保ち続けるため / レビューを行い続けるため属人性を高めない / レビューを行わない場合 8. 省略… 弊社サイトで全文読めます 一言で言うと 「”ちゃんと”を高速にやりつづけるための筋肉をつける」 151急いで作れ vs ちゃんと作ろう - セプテーニ・オリジナルの場合(発表者:杉谷)
  152. 152. optの場合 【大前提】 QCDにはトレードオフの関係がある 【中前提】 各個人の経験値やスキルにはばらつきがある 【小前提】 面白いと思って仕事をしているときが一番パフォーマンスが良い 152急いで作れ vs ちゃんと作ろう - optの場合(発表者:平岩)
  153. 153. optの場合 [プロダクトチーム制への移行] 2016年下期からセールスも開発も同じチームになるプロダクトチーム制への移行を試 みます - 「QCDにはトレードオフの関係がある」 - ビジネス側と開発側でできるだけ同じドキュメントを扱い、見える化を推進 - トレードオフが課題になりそうな場合、すぐに相談できるように - 「各個人の経験値やスキルにはばらつきがある」 - 何でも共有し、何でも助け合えるチームへ - DevOpsの仕組み作りに注力するほか、ビジネス側にも Opsに張り出してもらう - 「面白いと思って仕事をしているときが一番パフォーマンスが良い」 - ビジネスKPIをエンジニアも追い、ビジネス理解を高めてより本質的な仕事を - 作って意味のあるものを作り、作らなくて良い物は作らない 「急いで作れ vs ちゃんと作ろう」の判断を 高速に何度も行える体制へ 153急いで作れ vs ちゃんと作ろう - optの場合(発表者:平岩)
  154. 154. CyberZの場合 ビジネス要件は希望に満ち溢れている 要件通りに作っていたら「始まらない」 1ヶ月半程度でローンチ出来るプロトタイプ作成 構造は単純で安上がり。ボトルネックを明確に。 ↓ 市場に投下し、予算がついたタイミングで作り直し ↓ プロトタイプを部分的に置き換えていく形で アプローチ 154急いで作れ vs ちゃんと作ろう - CyberZの場合(発表者:門田)
  155. 155. CyberZの場合 プロトタイプの「撤退基準」を明確化しておく [いつまでに] 最長でも6ヶ月まで。 [何が出来ていないといけないか] 導入(利用)目標, 売上目標 → 達成? システム費用対効果 → 想定どおり? 振り返りはキチンと厳格化 155急いで作れ vs ちゃんと作ろう - CyberZの場合(発表者:門田)
  156. 156. 発表 困った!! No.   Scalaだけでなく JavaScriptエンジニアも足りない 156 44
  157. 157. ScalaだけでなくJavaScriptエンジニアも足りない ● 画面がSPAだったりして、開発にはそれなりにJS 力が必要 ● JS界隈のトレンド移り変わり速度が速すぎる ● JSできるエンジニアの求人票の難しさ ○ (jQueryしかできない人に来られても困る) ● デザインまではできなくて良いorデザインは外注 で良いケースも多くUI/UXエンジニアと言って良い のかという懸念も 157ScalaだけでなくJavaScriptエンジニアも足りない - opt(発表者:平岩)
  158. 158. 解決編 ● 画面側をTypeScriptに。 Scalaエンジニアも比較的 触りやすいように ○ (ん、Scala.js?) ● 一人か二人詳しい人が居 ると大変捗る ● 求人票については自分た ちに合ったものを頑張って 考える ● マガジン記事公開しまし た!→→→→→→→ 158ScalaだけでなくJavaScriptエンジニアも足りない - opt(発表者:平岩)
  159. 159. 発表 困った!! No.   社外勉強会を企画したのに準備が進まず 余裕がなくなる 159 45
  160. 160. ・他人駆動型準備(ODP) ・業務時間内に発表内容や企画内容のレビュー ・人事や総務も巻き込んで会社全体で準備! ・セプさん、オプトさんみたいにタスクをどんどんレコメンドしてくれ るような会社と一緒に勉強会を開催する (皆様、よろしくお願いします) 「Scala勉強会を開催しよう」ってノリノリで決定 いざフタを開けると勉強会間際になっても準備が進んでない 160社外勉強会を企画したのに準備が進まず余裕がなくなる - CyberZ(発表者:遠藤)
  161. 161. 発表 困った!! No.   プロジェクト間や部署間でのコミュニケー ション問題 161 46
  162. 162. スクラムの外の他部署とコミュニケーションがうまくとれ なくなり、お互いにいわゆるお役所仕事になってしまった (ex:インフラや広報など) プロジェクト間や部署間でのコミュニケーション問題 対応 ロードマップ作成時に他部門や他PJに関わるマイルス トーンをあらかじめ設定 進捗の共有を定期的におこなったり、依頼する際は事前 当てをしっかりして、連帯感を作る ちゃんと「ありがとう」を伝える 162プロジェクト間や部署間でのコミュニケーション問題 - CyberZ(発表者:遠藤)
  163. 163. 発表 困った!! No.   横展開で工数削減するつもりがカオスに なった 163 47
  164. 164. 横展開で工数削減するつもりが、 カオスになって逆に混乱の原因となった 対応 複数システムでの共通ライブラリなど幻想 夢を見過ぎない 途中から導入しようとしない ある程度経ったら独立して作りなおす 横展開で工数削減するつもりがカオスになった 164横展開で工数削減するつもりがカオスになった - CyberZ(発表者:鈴木)
  165. 165. 発表 困った!! No.   新人さん教育の方法 165 48
  166. 166. 入社された方はScalaやDDDを学ぶ段階から開始となるが、最初 は教え方が統一されておらず辛みが多かった。現時点では全社 で統一したカリキュラムを利用している 1. コップ本を読む 2. Scalaとplayを学ぶため、好きな方法で掲示板を実装してみる (要件はカリキュラムで定義) 3. レビューを通過する 4. EricのDDD本か、Quicklyを読む 5. 掲示板をDDDで作り直す 6. レビューを突破する 新卒入社の方々には、@OE_uia氏によるScala研修や、 @yattom氏が公開されているテストのありがたみが噛みしめられ る問題を使ったTDD演習、かとじゅん氏によるDDD研修も実施。 166新人さん教育の方法 - セプテーニ・オリジナル(発表者: 杉谷)
  167. 167. 発表 困った!! No.   チームを跨ぐと車輪の再開発が沢山発生し てしまった 167 49
  168. 168. (困った) スクラムではチームの生産性を高めることに重きを置くが、他の チームの開発状況を鑑みた全体的なシステム戦略をたてづらかっ た 168チームを跨ぐと車輪の再開発が沢山発生してしまった - セプテーニ・オリジナル(発表者:木村) (解決) - プロダクト・フォーカス プロダクト間で課題やプラクティスを共有する - 社内Hack Days プロダクト間で抱えている課題を技術で解決する
  169. 169. 発表 困った!! No.   Scala人材が採用できない 《求人タイム》 求人!求人です!募集中です! 各社求人しています! 50 169
  170. 170. セプテーニ・オリジナルの場合 170Scala人材が採用できない - セプテーニ・オリジナルの場合(発表者:杉谷) セプテーニオリジナルは常に人材を募集しています!! 〈アピールポイント〉 全プロダクトScala・DDD採用 / 社外熟練者レビュアーからの実装アドバイス / テスト 整備やレビュー、CI可動などの昨今の常識は当然実施 / オレオレでない教科書通り のスクラム運用 / マシマシMacbookPro / スタンディング作業ができる上下に動かせ る流行の机 / 結構立派な社内カフェ(昼食ビュッフェ有り) Scala未経験でもOK! ご応募お待ちしています! ご応募は弊社サイトよりどうそ
  171. 171. CyberZの場合 Scalaやりたい方(※未経験者OK)、 Scala以外やりたい方、大募集中です! 興味のある方、話を聞いてみたい方、 saiyo@cyber-z.co.jpまでご連絡もしくは、 弊社HPをご覧ください!! 懇親会でも気軽にお話しましょう♪ 171Scala人材が採用できない - CyberZの場合(発表者:阪本)
  172. 172. optの場合 採用積極的にやってます!!!!111 - Scala未経験でも今後業務で書いてみたい方 - 1ミクロンでもオプトに興味をお持ちいただけた方 この後お話しましょう! 172Scala人材が採用できない - optの場合(発表者:勝股)
  173. 173. ご静聴ありがとうございました アンケートへのご協力、よろしくお願い申し上げます。 この後はLTと懇談会です。 173

×