こんにちは。 @kimutyam (木村)です。
先日は『Scala/Scrum/DDD 困ったこと50連発ガトリングトーク』という勉強会にて登壇させていただきました。
scala-scrum-ddd-gatlingtalk.connpass.com
登壇後はガトリングすぎたのであっという間に終わったという意見がありましたので、
勉強会で質問していただいた内容の回答をまとめるエントリとします。
勉強会内容について
50連発でもスライド数173枚到達しました。
元々は100連発にしようと目論んでいたけど辞めてよかった...
以下のカテゴリで困ったことを50連発して各社でどのように解決してきたかというのが、このイベントの趣旨です。 詳細はスライドを参照ください。
Q&A (Scala)
Question 1
Scala関連のドキュメントが英語ばかりで辛いです！良い読み方はありませんか？ 英語覚えろks!以外でコツがあれば
Answer 1
セプテーニ・オリジナル 杉谷
英語を読むしか無いように思います。あるいは「100万円払うからplay2.5のドキュメント日本語化して！」と叫ぶとか。
オプト 平岩さん
自動翻訳して間違っててもいいから大意を掴み（掴んだ気になり）、その後目的の箇所を中心に読み進めるとかですかね？ あと、英語は「覚える」ものなのかについては諸説ありそう。
CyberZ 門田さん
技術英語は読むんじゃなくて感じるんです
Question 2
非エンジニアにScalaをどうやって認めさせましたか？ 「Scalaにしてる暇あったら機能増やして」に勝つ方法が知りたいです。
Answer 2
セプテーニ・オリジナル 杉谷
Scalaは型があり／表現力が豊か／IDE支援が強力、などの特徴から、慣れた後であれば他の言語に比べて圧倒的に楽にしっかりとした実装ができるし、慣れるのは大変ではない。PHPで同じ水準を保とうとすると大変だし、なによりPHPでそこまでちゃんとやりたがる人は多くない。つらい言語で衛生状態の悪いプロダクトをつくって人が寄りつかず衰退するよりは、より目的に合う言語で衛生状態の良い環境をつくり、組織を育てていくのであればScalaを積極的に利用しよう。という理屈でセプテーニ・オリジナルはScalaを利用しています。
オプト 平岩さん
一言で言うと、既成事実化しました（ニッコリ） ソフトウェアの減価償却の耐用年数を過ぎたら経営判断としてリプレースを検討した方が良いと思うので、それまで待つとか。
オプト 貴田さん
新機能の種類にもよりますが、マイクロサービス化できそうなのを立ち上げ時点からScalaで開発する方向はいかがでしょうか？
CyberZ 門田さん
誰か一人の意見ではなく、組織内のエンジニアの複数人の意見として上げました。メリットデメリットとか提示しつつ。 そもそも言語にこだわりは無いはずなので、越えるべきはラーニングコストかとおもいます。管理画面とか、ちっちゃいシステムとかでひっそり使って少しづつ慣れるのが一番かなと懐います。 それでも無理ならCyberZへお越しください
Q&A (DDD)
Question 1
DDDでドメインをコードに落とし込むところに工夫していることはありますか？
Answer 1
セプテーニ・オリジナル 杉谷
レイヤードなりヘキサゴナルなり、DDDに関係する全てのアーキテクチャはドメイン層に余計なことをかかないようにするために産まれた物なので、ドメイン層にドメイン外のことをできるだけ書かずに済むよう気をつけます。またドメインに書くべき事がドメイン外に漏れ出さないようにも気をつけます。
オプト 平岩さん
DDDやってませんが、名前重要という空気と無駄な依存は作らないという空気はあります。
CyberZ 門田さん
名前付けですかね。ドメインに密接に関係すると何気ない名前でもすごく意味を持つので、後世のメンバーに誤解されないかをレビューなどでいろんな観点から考えます。ドキュメントも書きますけど、読まなくていいほうがカッコイイので。
Question 2
DDDって何が嬉しいのでしょうか？
Answer 2
セプテーニ・オリジナル 杉谷
セプテーニ・オリジナルでは採用するのはチーム全員で要件の芯を捉え続けるためにDDDを採用しています。「エンジニア以外にも翻訳不要で伝えることができる」「設計と実装に対する価値観が共有できる」という特徴があり、チーム全員で要件の芯を捉える助けになることを期待しています。
オプト 杉泊さん
DDDやってませんが、とりあえず弊社内にて質問してみたところ、誰も答えをくれませんでした……。 DDDやってない人が傍から見て簡単にわかるような嬉しみは無いのかもしれませんね。
オプト 平岩さん
概念だけでも参考になる部分はあり、学ぶべき価値のあるものだと思いますが、実践するまでのコストをどう捉えるか、という要素はあるかなと思います。最終的にはやりたいかどうかなので、やりたい人がいれば是非チャレンジした方が良いと思います。
CyberZ 門田さん
ベタな話は置いといて、 ビジネスロジック部分に対してアプローチするフレームワーク的なものってあまりないので、一番フワッとする部分の「標準化」を図れるのはすごく大きいかなと思います
Q&A (開発ツール)
Question 1
使えるツールやライブラリを探すときは、 どうやって探してますか？(有益なサイトとか)
Answer 1
セプテーニ・オリジナル 杉谷
ググったりして見つけた物で、githubで人気のありそうなものを選びます。あとはTwitterでスゴそうな人がオススメしているものを選ぶとか
オプト 平岩さん
うちのメンバーの場合はtwitterが多そう。あとはgithubのtrendをウォッチしておくとか。 【宣伝】技術系キュレーションメディアです、私も公式Clipperというのを務めさせていただいてます。ツールを探すときにもオススメ！
CyberZ 門田さん
サイバーエージェントグループ内の知り合いにざっくり聞いたりとか。 いくつかグループ内のGithubを覗いて使ってるもの見たりもします
Question 2
仕様をドキュメントで可視化するために、 何か便利なツールやライブラリがあれば教えてください
Answer 2
セプテーニ・オリジナル 木村
我々はAtlassian(JIRA,Confluence,Bitbucket, Bamboo)を使っており、 ドキュメントは基本的にJIRAとの相性がいいConfluenceを使っています。 グラフィカルなドキュメントが必要な場合は別のツールを使うこともあります。 コンテキストマップはCacoo。シーケンス図、フローチャートはmermaidを利用しています。
また以前まではスプレッドシートで統合テスト仕様書を記載してましたが、 統合テストを自動(コード)化する動きをとり、Bitbucketで管理するようにしました。 自動化出来てない部分はMarkdownで記載後、Bitbucketリポジトリ上で管理してます。 これによりバージョニングも可能になります。
オプト 平岩さん
いろいろ試した結果、仕様については、マークダウンに向いてること or マークダウンでも頑張ればできることは極力マークダウンでgithub管理した方が良いよね、って流れになりつつあります。 あとはだいたいgoogle driveでやってますが、仕様書を補足するようなもの（管理資料や、仕様書になる前段階のもの）に限定しつつある感じです。議論しながら多人数でドキュメントを更新できるのは便利ですね。
CyberZ 門田さん
今全社あげて丁度探してるところです(笑)
Q&A (チーム運営・スクラム)
Question 1
振り返りで課題が出ないということはつまるところチームの運用が 上手いこといっているというポジティブな勘違いに至ることはないでしょうか？
Answer 1
セプテーニ・オリジナル 木村
勘違いしている可能性はあると思います。 ただ、本当に課題が出ない状況なのかは個人的には意識しております。 たとえ1~2週間の期間のスプリントでも課題が発生しないことの方が少ないからです。
例えば進捗が悪く見えるのに何も課題がないとなると、課題を言いづらい状況なのか 危機管理能力が欠落しているのかのどちらかだと思います。 課題を出さずにスプリント未達成になることは最悪なので、 そのような事案が発生しないように予防線をはっておくべきではあると思います。
オプト 平岩さん
課題が出ないのは、
- チームが取り組んでいるミッションの難度が低すぎる
- きちんと振り返れてない のどちらかなのではないかなと思います。
振り返りでしゃべってくれる人があまりいないこともあるかもしれませんが、チームの皆で互いにファシリテートしあえることが理想ですが、最初のうちはリーダークラスの人（スクラムマスターとは限らない）が責務としてファシリテートをやっていった方が動き出しやすいと思います。
ファシリテートについては、議論が進むように各人に発言を促したり、課題を示唆したり、といった司会っぽいファシリテートもありますが、発言しやすい空気、心理的安全をどうやって作るかということも重要になります。例えば、お茶やお菓子をいただきながらやっちゃう、という手段もあると思います。
CyberZ 門田さん
慣れたチームだとたまにあります(笑) 基本的にはマンネリになっている可能性が高いかなと思います。 無意識のうちに過去出したものを避けていたりなど。 ただ、今までやったKPTを見返してみたら、「そういえばあれTryで続いてたけど、最近やってないね」とかありますし、やり方や場所などをガッツリ変えてみたら大体うまく行きます。
Question 2
コードレビューをする側の時に気を付けていることはなんですか？ レビュアーは何に気をつけるべきでしょうか？
Answer 2
セプテーニ・オリジナル 木村
【コード内容について】
- 要件を満たしているか
大前提となります
- 何をレビューして欲しいのかが明確になっていること
明確になってないとレビューできません。
- コード内容を全て説明できること
例えばコピペが検知できたら理解せずに書いてる可能性が高い
- レビュアーへの配慮ができているか
レビュアーが理解できる粒度まで落とし込まれているかを確認します。 大抵はレビュイーよりレビュアーの人数が多いので、 レビューのコストを下げるためにレビュイーが コストを支払う方が全体コストが抑えられる可能性が高くなります。
【コミュニケーションについて】
- 指摘する際はサンプルコードを付与する
- 人格否定をしないこと
弊社社員がまとめている記事も合わせて参考にどうぞ
オプト 渋谷さん
重視すること
- 複雑でないこと
- 名前大事
- 異常値・エラーを正しく処理しているか
- 適切にテストコードでカバーされていること
- トレードオフについて検討がなされていること
重視しないこと
- ソースコードの書式や整形
CyberZ 鈴木さん
・人格を否定するコメントは一切書かないこと
・キツい指摘になる場合は、「かも」などをつけてやわらげること 以上、２点に気をつけています。
レビュー関係でモチベーションを下げることは気をつけたいですね。
Question 3
プルリクエストレビューについて、例えばRubyとJavaがあって、 担当者の得意不得意があって Rubyのレビュアー、Javaのレビュアーが 固定されたりするのについて対策ありますか？
Answer 3
セプテーニ・オリジナル 杉谷
そのようにレビュー不能になる段階で組織の負けなので、できるだけ属人性が高まらないようにチームを組んでいきます。 GANMAの場合、iOSしかみれないサーバ側しか見れない、というのは少数で、Scala/Swiftどちらもみれるとか、iOS/Android/Play全部いじれるというのは普通です。
オプト 平岩さん
フルスタック指向のある人はどんどん色んなことをやってもらうとか？ スキルの問題なのか（知識不足・経験不足）人の問題なのか（意識、仲の良し悪し）は切り分けても良さそう。両方のケースが多いと思いますが。
CyberZ 門田さん
ビジネスロジックのレビューについては、よほど苦手意識が無ければみんなレビューは可能かなと思います。 言語的なレビューになるとある程度得意(好き)な人がやるので良いとは思います。
Question 4
>プルリクエストの指摘
レビューの確認項目は大分類すると
1.業務要件が満たされているか
2.コードの美しさ
の2つあるかと思いますが、 この2つが混在するとコメントが増えていったり 本来レビューするべきことを見失ったり、 今の現場で起きています。
レビューの確認項目で何かルール決めなどされていたら教えてください
Answer 4
セプテーニ・オリジナル 木村
我々は『pull requestを利用した開発ワークフロー』を参考にして レビューコメントにタグをつけています。
業務要件が満たされていることは必須条件です。[must]のタグをつけてます。
コードの美しさは保守や拡張におけるコストを削減したいので求めたいです。 ただ、コードの美しさについては思想の違いによって 美しさの定義もばらばらですし、 ビジネスサイドとの兼ね合いも関係しますので、必要条件ではないです。 [IMO]のタグをつけます。
[IMO]をつけることで議論対象にし、 ROIがもっとも見込める選択をレビュイーとレビュアー間で合意した上で決定します。 コードの美しさにおける対応遅延が発生している状況はデイリースクラムで検知し、 プロダクトオーナーと相談して対応スコープを考え直すこともあります。
オプト 平岩さん
[MUST] とか [IMO] とか [nits] とかやってなくはないですけど、厳密にルールは決めてないです。 レビューの場だけでなくて、普段からオーラルコミュケーションも含めて取るようにしておくと、レビューも円滑に進むのではないかと思います。
オプト 貴田さん
まだ始めたばかりですが、レビュアーを複数アサインするのを試しています。「コードの美しさ」の方はどのレビュアーも気づいたら言ってくれると思いますので、業務要件の方をしっかり見てくださいという人を１人（以上）指名しておくのもいいかと思います。
CyberZ 門田さん
スライドにも書いたのですが、リアルファイトにならないよう、 主張か事実かをはっきりするとかですね。
Question 5
タイムゾーンが合わない状況でどうやってビデオ会議するんでしょうか？ 結構きつくないんでしょうか？
Answer 5
オプト 平岩さん
普段はそういう機会はあまりないですけど、一回、自社のイベントでlightbendの横田さん（マサチューセッツ州在住）にオンライン登壇していただいたときは、発表順を一番最後にすることで何とかしました。それでも向こう早朝だけど。 アメリカと打合せするときは、どちらかが早朝でどちらかが夜みたいな合わせ方が多い気がする。
CyberZ 門田さん
CyberZ USA(サンフランシスコ)にエンジニアが居て、日本のチームと一緒に開発していますが、日本の午前中が向こうの夕方ぐらいなので、リアルタイムに話す時間帯を絞ればそんなにめちゃくちゃキツくはないです。ただ、向こうの治安が悪いのであまり遅くまではやらないです。
Question 6
Scurmってどんな問題をどのように解決してくれる手法何でしょうか？
Answer 6
セプテーニ・オリジナル 杉谷
セプテーニオリジナルではプロダクトオーナーがハンドルを握るためにスクラムを採用しています。開発においてリソースが潤沢であることは希で、殆どの場合、限られたリソースの振り分け判断が重要となります。スクラムはバックログを通してプロダクトオーナーの意図を表せますし、スプリントとストーリーポイントにより、コストも根拠を持って可視化することができ判断が的確になります。
オプト 平岩さん
ベロシティ計測が意味を持ち始めるには１年以上とか続けないと意味ないのではないかなとも思います。 私は諦めました＞＜
CyberZ 鈴木さん
請負的な雰囲気なチームを主体的に持っていくマインドを変えるための手法です。
Scrumは、
・全てチームの承認を元に実行
・スプリントというマイルストーンごとでの計画
・少人数でのチーム編成 という各メンバーの責任感と一体感を醸成できる手法なので変化に強いと考えています。
Question 7
今までスクラムをやったことのないチームに 導入するのに苦労したことはありますか？
Answer 7
セプテーニ・オリジナル 杉谷
スクラムとはなにか、どういったルールになるのか、という基礎部分を全員理解するところがスタート地点である、というところが最も難しいところです。セプテーニ・オリジナルでは会社に講師をお招きし、社長も含め全社員が研修を受けました。
オプト 平岩さん
個人的には立ち上げたばかりの会社でやったので導入は苦労しなかったですが、以前流行ってたころに比べて、世の中的にスクラムというものに対して幻滅期に入ってる部分もあると思うので、「スクラムをやる意図」を関係者で合意する必要があると思います。
CyberZ 鈴木さん
いきなりガチガチのスクラムを行うのではなく、最小限から入っていくという感じです。 結局ガチガチのスクラムは、回すのも大変なので、最終的にゆるいスクラムになっていますが。
Question 8
スクラムにおけるポイント見積もりのコツってありますか？
Answer 8
セプテーニ・オリジナル 木村
- 複雑度で相対評価
- ポイントが大きくなるにつれて不確実性が増すことのでポイントの幅を増やす
フィボナッチ数列を採用するケースが多い印象
- ポイントが大きいチケットに関しては分割を検討
基本的に『エッセンシャルスクラム』を参考にしています
CyberZ 門田さん
スクラムでポイントは付けていないです。タスクを理解(イメージ)できているかどうかは、スプリント計画時に確認するのであまり問題はないです
Question 9
レビューの大きさってどんなもんでしょうか？ 小さな単位(メソッドの単位とか)でやるとやりやすいとは思うんですが、 全体を俯瞰してレビューできないかな、とも思います。
Answer 9
セプテーニ・オリジナル 木村
レビューのそれぞれ解決したい内容が異なるはずなので、 一概に粒度のレギュレーションは決めかねますが、 レビューしてもらうモジュールを限定的にする努力はしてもらう感じです。 チケットスコープ=プルリクエストスコープである必要はないと考えます。
また、単一責務の原則(SRP)、開放/閉鎖原則(OCP)が守られていないとレビュー粒度が肥大化すると思います。 責務=変更の理由であり、変更の理由が複数になっている場合は修正範囲が増える傾向があります。 拡張に対して開いていればコードの再利用ができ、修正に対して閉じていれば修正箇所を限定でき、 結果レビュー粒度が小さくなります。
土台コードが腐っているとレビューの度にボディブローを浴びるので、 そのような状況の時は技術的負債を返済する動きをとって事前に予防するのも大切かと思います。
オプト 平岩さん
コードレビューをするということと、ハイレベルアーキテクチャを把握するということは、別のタスクではないかなと思います。
ハイレベルアーキテクチャを理解できていないことが、コードレビューにとってマイナスになるなら、レビューに入る前にアーキテクチャを理解する工数を確保すべきかなと。方法はいろいろ（ひたすらドキュメント読む、詳しい人と打合せする）あると思いますが。
CyberZ 鈴木さん
全体のレビューは、GitHubではなく別で設計レビューという形でやっていますね。
なので、GitHubで見るコードレビューは基本的には、 小さい単位に分割してWIPでもらってレビューを実施しています。
Question 10
スクラムからDevOpsへ移行する検討はあるのでしょうか？
Answer 10
セプテーニ・オリジナル 杉谷
DevOpsとされるものの効果の「頻繁なリリースを可能にする」と相反するのでは？というご質問だとすると、スクラムだからといってスプリント区切りでしかリリースしないわけではないので、移行する物では無く共存する言葉だとおもいます。
オプト 平岩さん
CyberZ 鈴木さん
スクラムとDevOpsは対立する概念ではないですね。
Q&A (その他)
Question 1
PHPの開発で破綻したことはどんなことだったのでしょうか？
Answer 1
セプテーニ・オリジナル 杉谷
テストも無く設計のポリシーや知識もないまま機能追加を塗り重ねた結果、不具合が頻発し、業務として使い続けるには信頼できる品質ではなくなってしまった、という内容です。なお言語が悪いわけではなくPHPでも技量と衛生維持の意識さえ有ればちゃんとやることは可能です。
勉強会風景
勉強会は弊社の牧場スペース(!?)で行いました。
オープニングトーク(杉谷)
発表(木村)
LT&懇談会
感想
この勉強会はScala将軍達の後の祭りや#7 市ヶ谷Geek★Night「Scala大名の平成維新〜殿中でScala！〜」の懇談会で技術話をしていたCyberZさんとオプトさんと類似した開発手法および技術を扱っていることに気付き、3社で何か共同勉強会をやってみれば面白いんじゃないかとなったのが話の発端です。
Scala/Scrum/DDDで各社話そうと言ってましたが、会社の色がそれぞれ出ていて面白かったです。
CyberZさんとオプトさん改めてありがとうございました。
各社のTipsのまとめとしてイベントに参加いただいた方含め、このエントリをみていただいている方の何か役に立てると大変嬉しく思います。
