Transcript

• 1. Scalaに至るまでの物語 Septeni × Scala 第一回 2015/02/19
• 2. 前説
• 3. セプテーニ・グループとは • ネット広告の代理店が本業 – エンジニア知名度無いが、かなり大きい会社。 • ホールディングス制 – 1部署1会社のようなもので、いろいろやっています。 株式会社セプテーニ (ネット広告事業部) 株式会社セプテーニ・オリジナル (開発部) コミックスマート株式会社 (マンガ事業部) セプテーニ・ホールディングス …他19社
• 4. 自己紹介 • 杉谷(@sugitani)ともうします。 – 2013/7にセプテーニに入社 • 今はセプテーニ・オリジナル所属 • セプテーニ株式会社の執行役員・技術担当 • 株式会社コミックスマート・CTO • GANMA! というオリジナルマンガサービスをやっています。 – 前職はドワンゴ • ニコニコ動画モバイル配信系 – プロトコル設計・動画変換プログラム・docomo iアプリ • ニコニコ生放送初代リーダー • SmartySmile • ニコニコアラート
• 5. 本日の概要 • 入社して1年半。いろいろやった結果、セプ テーニはScalaをメインでやっていく流れになり ました。 – 弊社は弊社の知名度向上と、Scalaの普及加速を 狙い、情報公開を進める方向です。 – 僕のパートでは前職と現職を通して、どうしてこう なったのか、どうやってこうなったのか、共有しま す。 – それぞれの所属する組織でのScala普及に役立 つこと、を目指します。
• 6. それでは始めます。
• 7. Scalaを始める前のお話 昔話。
• 8. ドワンゴ在籍＠２０１２ • ニコ生を離れて、いろんなことをやっていた。 • ニコ生でPHPは”ちゃんとやるには難しすぎる”と 痛感 – 強いIDEと型がほしいと思った – 以降の自分実装はplayframework × javaを採用 • XML地獄に落ちずに、Javaでさくさくと実装できるのは新鮮 だった。 • （当時は）結構満足していた • ニコニコAndroidチームがScala正式採用 – へー。と思ってた。
• 9. ドワンゴ在籍中@2012〜2013 • ドワンゴのScala普及は加速 – 監督していたプロダクト(実装は自分ではない)では、開発者 の強い希望でScalaに。 • 自分の分をplay × javaでごりごりやりながら、横目で 見ていた。 • 読めなかったのでコードレビューも出来なかったが、楽 しそうだとはおもっていた。
• 10. Scalaに対する当時の印象 • すっごい重いんでしょ？ • 型ありは素敵だけど、Javaで良くない？ • Scalaのエンジニアなんて獲得できなくない？ • 一回経験したらJavaに戻れないんでしょ？こ わい！ こういうことを、いまだに言っている人いたら「ばーか」といってあげてください
• 11. なぜドワンゴを辞めたのか？ • 企画を考える仕事もしていた。 • ある企画を考え川上さん（ドワンゴ会長）に提案 • 好印象！ • 「でも君ってコード汚いっていうし（実装は）任 せないほうがいいよね？」 ( ﾟдﾟ)
• 12. こう言われても仕方が無い 4代目開発リーダーsifueさん Developer Summit 2014の発表
• 13. こう言われても仕方が無い 4代目開発リーダーsifueさん Developer Summit 2014の発表
• 14. こう言われても仕方が無い 4代目開発リーダーsifueさん Developer Summit 2014の発表
• 15. こう言われても仕方が無い 4代目開発リーダーsifueさん Developer Summit 2014の発表
• 16. こう言われても仕方が無い 4代目開発リーダーsifueさん Developer Summit 2014の発表
• 17. こう言われても仕方が無い 4代目開発リーダーsifueさん Developer Summit 2014の発表
• 18. こう言われても仕方が無い 4代目開発リーダーsifueさん Developer Summit 2014の発表
• 19. これの犯人は？
• 20. 自分でしょ？
• 21. 振り返り • 当時の自分には、複雑さに立ち向かうという ”概念”がなかった – テスト無し・ 設計やチーム運営もろもろ全部我流 • リクエストに応え続けるのが何よりもの是と思っ ていた – 悪いことに成果も激しくでてしまった。 – 結果、チームとしても会社としても、自分のやり方が 是となってしまった。 • システムも体制も、最初に作った人間に大きな 責任がある。 – 後から入ったメンバーに出来ることは少ない。
• 22. 価値観 • 自分にニコ生は「価値が無い」 – 会社としては大成功 • 収益の何割をも占める主力事業 – エンジニアとしては無価値 • いくら貢献しようが自分は「生ゴミのようなシステムを 作った人」である。 • 若かっただ・時間が無かった・技量が無かった、だの 一切の言い訳は無用 • 「安定した品質」 && 「誇れる組織」 && 「価値あるプロ ダクト」を自分で作ってみせるまで、打ちひしがれたま ま。
• 23. 転職 • やり直すために、転職を決意。 • GANMA! の立ち上げと、組織改革をミッション にセプテーニに入社 – 今後こそ、ちゃんした組織とプロダクトを作る決心 – Scala、ドメイン駆動開発（DDD)、スクラム、各種開 発支援ツールの導入、チャットツールの普及、黒 くない裁量労働制の導入、人事制度改革、etc…
• 24. 昔話以上。 次は、転職後の考えや、具体的行動等をご紹介。
• 25. なぜScalaなのか？ “開発がしやすいから、ではちょっと弱い”
• 26. 1. 簡単だから 2. 継続できるから
• 27. 私たちがやりたいこと • 美しく読みやすいコードを見たい書きたい • バグが少ない構造を組み上げたい触りたい • Scalaだと間違いなくやりやすいのは分かる – 型がある • 簡単なテストを自動で書いてくれるようなもの。 • IDEの補完とリファクタがよく効く – Nullがない – いくらでも華麗に書ける
• 28. 別にPHPでもできる • PHPだろうがJavaだろうがCだろうが、ちゃんとやれば綺麗 に書ける。 – テストを書く、CI回す。 – 息を吸うようにリファクタする。 – 設計を学ぶ考える。 – DRYなり各種法則を守る。 • 事実として、意識さえ高ければどの言語でも問題は無い • でも、そんなに出来る人、採用できる？ • そんなに意識の高い人が「PHPやりたい」って言う？ • ずっと意識持ち続けられる？ • システムは何年も生きるし、人も入れ替わるよ？
• 29. 何のためのScalaか。 • ちゃんとした実装を行い続けるためにScala。 – 目指す状態をめざし続けるなら、 Scalaの方が逆に体力を使わない。 • ちゃんとしたい人と出会うためにScala。 – Scalaやってる、やりたい、と言う人は、きっと意識 も高い。（広く普及すると、falseになるけど） – きっと自分たちに興味を持ってもらえる確率も高 い – 検索: Pythonのパラドックス
• 30. 昔の自分のへの回答 • 重いんじゃない？ – フルビルドは重いが、部分コンパイルが発達。 • 札束で叩けば全然平気 • 弊社はMacbook Pro15インチの最上位プランを支給 – ただしCtrl+F5駆動開発だと厳しい • Scalaエンジニアなんて調達できないぞ？ – 目的は良い人に会うこと。人の多い言語にして低マインド の人をとれるようになっても意味は無い。 – 始めたい人に始めてもらおう、言語の習得は問題に成ら ない。 • Scala経験したらJavaに戻れない – 真実だ。
• 31. 普及のための手続き 自分の組織をよくしたい作戦
• 32. 空気を動かそう • あなたの上長が、いきなり「話は分かった Scalaにしよう！！」と言うとは限りません。 • あなたの同僚が全員「Scalaやりたい！！」と 言うとは限りません。 • 大体、みな最初は半信半疑です。 • あなたが空気を動かす必要があります。
• 33. 成功するしかない • どうにかして、あなたが何かを新規作成するときの リーダーになってください。 • Scalaを使って”開発に成功”してください – 新規開発も追加開発も、常に予定通り。 – 不具合も障害も少ない。 – 終始、安定した開発チームとして見える状態が目標。 • 成功するために、正しい手段・手法を活用してください – 上長も同僚も、あぁ”Scala”も含めて素晴らしいな違うな、 と思わせることが出来れば勝ちです。 – Scalaを使う以外にも、様々な知識・技術を動員する必要 があります。
• 34. 成功するための技術：テスト • あなたの書いたコードは、未来永劫最適です か？ – 今後一切書き換えることはありませんか？ – 未来も含めて完璧なコードを書けるのですか？ – 神でなければNo • 開発の命綱としてテストは当然書きましょう。
• 35. 成功のための技術：プルリ • Githubとそのクローンにある「Pull-Request」 – コードをマージする時に”必ずレビューを行う”が 実現できる • 一人でだけで良いコードを書き続けというの は、大抵の人間には難しいです。 • 今現在、GithubかGithubもどきが無い場合、 どうにかして導入しましょう。
• 36. 成功するための技術：スクラム • おなじみのチーム管理手法 • 教科書通りに実行すると大変強力 – ベロシティを元に、精度の高いリリース予定日を算出 できる = 予定日ありき、をやめられる。 – 技術的負債を”負う覚悟”をプロダクトオーナーに委 ねることができる • エンジニアチームは選択肢を出すだけ「ベストは21pt。妥協 すると13pt。スゴくやっつけると3ptだけど副作用あるのであ とで21ptを別ストーリーとして残ります。どれにしますか？」 • デスマーチ防止・リリース前ぐだぐだ、謎の開発 遅延。などいろいろな問題に効果があります
• 37. 成功するための技術：DDD • 「ドメイン駆動開発」 • 設計の難しさに立ち向かうた めの技術 – ざっくり：作りたい物の本質（ドメ イン）を言葉で説明しよう、かつ 言葉と実装を一致させよう。 • システムの見通しがとてもよく なります。 • 非エンジニアとの対話も「翻 訳無し」で行えるようになりま す。
• 38. GANMA!での事例（初期） • Playframework + scala • テスト完備、DDD採用 • Chef とfabricでインフラ管理、Vagrantも活用 • サーバはREST API だけ、 クライアントは Sencha Touch × Cordova という構造 • 最初期はメンバーも居ないのでスクラムでは なく、見積もりもせず全力消化 – まだスクラムしらず。
• 39. GANMA!での事例（〜現在） • メンバーも増え、管理に限界を感じたのでスクラムを 導入 – 翔泳社のアジャイルアカデミーに研修を受けに行った – 講師さんを呼び、社内開発関係者全員にLEGO研修をうけ てもらった（役員含む） – とにかく教科書通り、を徹底した • 新規加入メンバー向けのチュートリアルも整備 – チュートリアルになる課題をやってもらう（スプリントの課 題としてね） – アジャイルアカデミーのTDD研修も受講し、その教え方を 参考に社内でテスト普及活動も実施
• 40. GANMA!での事例（結果） • 最初期リリース以外はかなり見積もりに忠実に なった – GANMA!ブラウザ版や、兄弟サイト（つぶやき GANMA!）のリリースも、見積もり通りにリリース。 • 負荷や不具合にはほぼ悩まされない • GANMA!が開発者育成場になった – GANMA!に留学してスクラムやDDD、テストやScalaを 学び、各プロジェクトに持ち帰る。 • 今後の新規プロダクトは、特に理由が無い限り GANMA!系統より原始的にはならない流れに。
• 41. 「普及させるにはどうすればよいか」 をまとめると
• 42. 道具をそろえてがんばれ。
• 43. 以上。
• 44. 如何でしたか？ 身もふたも無い？
• 45. 質疑応答。
• 46. がんばりましょう！
• 47. ご静聴ありがとうございました！