Scalaに至るまでの物語 - Septeni × Scala 第一回 杉谷

Scalaに至るまでの物語

Septeni × Scala 第一回2015/02/19

前説

セプテーニ・グループとは

• ネット広告の代理店が本業– エンジニア知名度無いが、かなり大きい会社。

• ホールディングス制– 1部署1会社のようなもので、いろいろやっています。

株式会社セプテーニ(ネット広告事業部)

株式会社セプテーニ・オリジナル(開発部)

コミックスマート株式会社(マンガ事業部)

セプテーニ・ホールディングス

…他19社

自己紹介

• 杉谷(@sugitani)ともうします。– 2013/7にセプテーニに入社

• 今はセプテーニ・オリジナル所属• セプテーニ株式会社の執行役員・技術担当• 株式会社コミックスマート・CTO• GANMA! というオリジナルマンガサービスをやっています。

– 前職はドワンゴ• ニコニコ動画モバイル配信系

– プロトコル設計・動画変換プログラム・docomo iアプリ

• ニコニコ生放送初代リーダー• SmartySmile• ニコニコアラート

本日の概要

• 入社して1年半。いろいろやった結果、セプテーニはScalaをメインでやっていく流れになりました。–弊社は弊社の知名度向上と、Scalaの普及加速を狙い、情報公開を進める方向です。

–僕のパートでは前職と現職を通して、どうしてこうなったのか、どうやってこうなったのか、共有します。

–それぞれの所属する組織でのScala普及に役立つこと、を目指します。

それでは始めます。

Scalaを始める前のお話昔話。

ドワンゴ在籍＠２０１２

• ニコ生を離れて、いろんなことをやっていた。

• ニコ生でPHPは”ちゃんとやるには難しすぎる”と痛感– 強いIDEと型がほしいと思った

– 以降の自分実装はplayframework × javaを採用• XML地獄に落ちずに、Javaでさくさくと実装できるのは新鮮だった。

• （当時は）結構満足していた

• ニコニコAndroidチームがScala正式採用– へー。と思ってた。

ドワンゴ在籍中@2012〜2013

• ドワンゴのScala普及は加速

–監督していたプロダクト(実装は自分ではない)では、開発者の強い希望でScalaに。

• 自分の分をplay × javaでごりごりやりながら、横目で見ていた。

• 読めなかったのでコードレビューも出来なかったが、楽しそうだとはおもっていた。

Scalaに対する当時の印象

• すっごい重いんでしょ？

• 型ありは素敵だけど、Javaで良くない？

• Scalaのエンジニアなんて獲得できなくない？

• 一回経験したらJavaに戻れないんでしょ？こわい！

こういうことを、いまだに言っている人いたら「ばーか」といってあげてください

なぜドワンゴを辞めたのか？

• 企画を考える仕事もしていた。

• ある企画を考え川上さん（ドワンゴ会長）に提案

• 好印象！

• 「でも君ってコード汚いっていうし（実装は）任せないほうがいいよね？」

( ﾟдﾟ)

こう言われても仕方が無い

4代目開発リーダーsifueさんDeveloper Summit 2014の発表

こう言われても仕方が無い

4代目開発リーダーsifueさんDeveloper Summit 2014の発表

こう言われても仕方が無い

4代目開発リーダーsifueさんDeveloper Summit 2014の発表

こう言われても仕方が無い

4代目開発リーダーsifueさんDeveloper Summit 2014の発表

こう言われても仕方が無い

4代目開発リーダーsifueさんDeveloper Summit 2014の発表

こう言われても仕方が無い

4代目開発リーダーsifueさんDeveloper Summit 2014の発表

こう言われても仕方が無い

4代目開発リーダーsifueさんDeveloper Summit 2014の発表

これの犯人は？

自分でしょ？

振り返り

• 当時の自分には、複雑さに立ち向かうという”概念”がなかった– テスト無し・設計やチーム運営もろもろ全部我流

• リクエストに応え続けるのが何よりもの是と思っていた– 悪いことに成果も激しくでてしまった。

– 結果、チームとしても会社としても、自分のやり方が是となってしまった。

• システムも体制も、最初に作った人間に大きな責任がある。– 後から入ったメンバーに出来ることは少ない。

価値観

• 自分にニコ生は「価値が無い」–会社としては大成功

• 収益の何割をも占める主力事業

–エンジニアとしては無価値• いくら貢献しようが自分は「生ゴミのようなシステムを作った人」である。

• 若かっただ・時間が無かった・技量が無かった、だの一切の言い訳は無用

• 「安定した品質」 && 「誇れる組織」 && 「価値あるプロダクト」を自分で作ってみせるまで、打ちひしがれたまま。

転職

• やり直すために、転職を決意。

• GANMA! の立ち上げと、組織改革をミッションにセプテーニに入社

–今後こそ、ちゃんした組織とプロダクトを作る決心

– Scala、ドメイン駆動開発（DDD)、スクラム、各種開

発支援ツールの導入、チャットツールの普及、黒くない裁量労働制の導入、人事制度改革、etc…

昔話以上。次は、転職後の考えや、具体的行動等をご紹介。

なぜScalaなのか？“開発がしやすいから、ではちょっと弱い”

1. 簡単だから2. 継続できるから

私たちがやりたいこと

• 美しく読みやすいコードを見たい書きたい

• バグが少ない構造を組み上げたい触りたい

• Scalaだと間違いなくやりやすいのは分かる

–型がある

• 簡単なテストを自動で書いてくれるようなもの。

• IDEの補完とリファクタがよく効く

– Nullがない

–いくらでも華麗に書ける

別にPHPでもできる

• PHPだろうがJavaだろうがCだろうが、ちゃんとやれば綺麗に書ける。– テストを書く、CI回す。– 息を吸うようにリファクタする。– 設計を学ぶ考える。– DRYなり各種法則を守る。

• 事実として、意識さえ高ければどの言語でも問題は無い• でも、そんなに出来る人、採用できる？• そんなに意識の高い人が「PHPやりたい」って言う？• ずっと意識持ち続けられる？• システムは何年も生きるし、人も入れ替わるよ？

何のためのScalaか。

• ちゃんとした実装を行い続けるためにScala。

–目指す状態をめざし続けるなら、Scalaの方が逆に体力を使わない。

• ちゃんとしたい人と出会うためにScala。

– Scalaやってる、やりたい、と言う人は、きっと意識

も高い。（広く普及すると、falseになるけど）

–きっと自分たちに興味を持ってもらえる確率も高い

–検索: Pythonのパラドックス

昔の自分のへの回答

• 重いんじゃない？– フルビルドは重いが、部分コンパイルが発達。

• 札束で叩けば全然平気• 弊社はMacbook Pro15インチの最上位プランを支給

– ただしCtrl+F5駆動開発だと厳しい

• Scalaエンジニアなんて調達できないぞ？– 目的は良い人に会うこと。人の多い言語にして低マインドの人をとれるようになっても意味は無い。

– 始めたい人に始めてもらおう、言語の習得は問題に成らない。

• Scala経験したらJavaに戻れない– 真実だ。

普及のための手続き

自分の組織をよくしたい作戦

空気を動かそう

• あなたの上長が、いきなり「話は分かったScalaにしよう！！」と言うとは限りません。

• あなたの同僚が全員「Scalaやりたい！！」と言うとは限りません。

• 大体、みな最初は半信半疑です。

• あなたが空気を動かす必要があります。

成功するしかない

• どうにかして、あなたが何かを新規作成するときのリーダーになってください。

• Scalaを使って”開発に成功”してください– 新規開発も追加開発も、常に予定通り。

– 不具合も障害も少ない。

– 終始、安定した開発チームとして見える状態が目標。

• 成功するために、正しい手段・手法を活用してください– 上長も同僚も、あぁ”Scala”も含めて素晴らしいな違うな、と思わせることが出来れば勝ちです。

– Scalaを使う以外にも、様々な知識・技術を動員する必要があります。

成功するための技術：テスト

• あなたの書いたコードは、未来永劫最適ですか？

–今後一切書き換えることはありませんか？

–未来も含めて完璧なコードを書けるのですか？

–神でなければNo

• 開発の命綱としてテストは当然書きましょう。

成功のための技術：プルリ

• Githubとそのクローンにある「Pull-Request」

– コードをマージする時に”必ずレビューを行う”が実現できる

• 一人でだけで良いコードを書き続けというのは、大抵の人間には難しいです。

• 今現在、GithubかGithubもどきが無い場合、どうにかして導入しましょう。

成功するための技術：スクラム

• おなじみのチーム管理手法

• 教科書通りに実行すると大変強力– ベロシティを元に、精度の高いリリース予定日を算出できる = 予定日ありき、をやめられる。

– 技術的負債を”負う覚悟”をプロダクトオーナーに委ねることができる• エンジニアチームは選択肢を出すだけ「ベストは21pt。妥協すると13pt。スゴくやっつけると3ptだけど副作用あるのであとで21ptを別ストーリーとして残ります。どれにしますか？」

• デスマーチ防止・リリース前ぐだぐだ、謎の開発遅延。などいろいろな問題に効果があります

成功するための技術：DDD

• 「ドメイン駆動開発」

• 設計の難しさに立ち向かうための技術– ざっくり：作りたい物の本質（ドメイン）を言葉で説明しよう、かつ言葉と実装を一致させよう。

• システムの見通しがとてもよくなります。

• 非エンジニアとの対話も「翻訳無し」で行えるようになります。

GANMA!での事例（初期）

• Playframework + scala

• テスト完備、DDD採用

• Chef とfabricでインフラ管理、Vagrantも活用

• サーバはREST API だけ、クライアントはSencha Touch × Cordova という構造

• 最初期はメンバーも居ないのでスクラムではなく、見積もりもせず全力消化

–まだスクラムしらず。

GANMA!での事例（〜現在）

• メンバーも増え、管理に限界を感じたのでスクラムを導入– 翔泳社のアジャイルアカデミーに研修を受けに行った

– 講師さんを呼び、社内開発関係者全員にLEGO研修をうけてもらった（役員含む）

– とにかく教科書通り、を徹底した

• 新規加入メンバー向けのチュートリアルも整備

– チュートリアルになる課題をやってもらう（スプリントの課題としてね）

– アジャイルアカデミーのTDD研修も受講し、その教え方を参考に社内でテスト普及活動も実施

GANMA!での事例（結果）

• 最初期リリース以外はかなり見積もりに忠実になった– GANMA!ブラウザ版や、兄弟サイト（つぶやき

GANMA!）のリリースも、見積もり通りにリリース。

• 負荷や不具合にはほぼ悩まされない

• GANMA!が開発者育成場になった– GANMA!に留学してスクラムやDDD、テストやScalaを学び、各プロジェクトに持ち帰る。

• 今後の新規プロダクトは、特に理由が無い限りGANMA!系統より原始的にはならない流れに。

「普及させるにはどうすればよいか」をまとめると

道具をそろえてがんばれ。

以上。

如何でしたか？身もふたも無い？

質疑応答。

がんばりましょう！

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