ニコ生は日本の生放送サービスで最も人気があったシステムだと思います（今はどうなんだろ？）ニコ生に関する仕事は大量にあり開発はもちろん番組制作に品質保証やユーザーサポートなど沢山の仕事が生み出されました。またニコ生由来の収益もあったことでしょうしそれにより会社活動（≒多数の人の給与≒生活）に貢献できていたでしょう。また生放送をしてくださる方々により多数のカルチャーが創造され、観たり配信したりして楽しむだけに留まらず人生も変わった人も多数いらっしゃることでしょう（例えばそれで出会って結婚するだとか仕事を得るだとか）ニコ生は世界を変えたと思っています。

ニコニコ超会議の音楽イベントでステージに立たせて戴いたことがあったんですが、膨大な数の人々が目の前にいらっしゃって、俺は文化を創ったんだろうかな？と感極まり打ち上げの時まで泣いていたことを思い出します。

その後色々あっていまはSUGARという会社でSUGARというアプリを開発しています。SUGARは著名なアーティストの方と、そのファンの方とのコミュニケーションにフォーカスしたシステムで電話がかかってきて1:1で話せるんだぜ、とか訳の分からん説明はできるのですが伝えるのが難しいです。電話と生放送の中間？かな？

そう、また生放送なんですよ。また。

また俺は生放送作るのか？とかいろいろ思うんですがこの企画を頂戴したとき面白くないわけが無いと思ってしまったのでしょうが無くもりもり作ってリリースしてみて使われているところみたらやっぱり尋常じゃ無く面白くてやべーな、と思ってしまっているのでしょうが無いと思っています（楽しい）。

SUGARは技術的にはたいしたことはありません。昔であれば生放送かーRTMPになるなーFMSかWowza調達してFlexかFlash持ち出してクライアントかいてーDCと機材も手配したりセットアップもしないといけないし大規模配信しないといけないから回線も調達しなきゃえらいこっちゃ、なんですが今回やったことはWebRTC等の必要な技術を調べてサーバを立ててブラウザで軽くプロトタイプを創り映像合成や回線切り換えが出来るか動くかCDNでHLSで再配信ができるかを検証してからサーバとクライアントを清書、サーバもAWSなりGCPあるしk8sめっちゃ便利やんけうっひょー、などとやっていたら完成していました。

2017/10から開発を開始、UI周りはフリーランスの方に手伝って戴きつつもおおむね一人で作業を進め2018/6にS-inできたくらいです。（画像エフェクト/顔認識系をいれなければもう少し早かったくらい）

技術的には優位性は薄いので機能的にはマネされやすいかもしれませんが（特許類は押さえてあるけど）ファンの方とのコミュニケーションに絞ってサービス提供をする、という立ち位置は既存のライブシステムには再現しきれないだろうなぁ、等と考えています。

幸い、仲間にも恵まれています

カタロニアのSuperScalaManであるGuillemさん
前職の同僚でありScalaもiOSも行けるナイスガイ嶽さん（一社挟まっているので前職からの引き抜きではない）
丁寧な仕事が光るiOSエキスパート星野さん
そして各所でいろいろな発表(最近だとScala関西)をされているSuperScalaGirlタラソワ・ダーシャさんが入社！

もしかして、もういちど、てっぺんめざせるんじゃ？

などと考えています。今年も頑張ります。みなさまSUGARを宜しくお願いいたします。

求人してます！

2017-10-01

初転職4年間のまとめ、あるいはCTOを辞めたお話

4年間務めた株式会社セプテーニ・オリジナル、およびコミックスマート株式会社を退職しました。役職はどちらもCTOでした。どなたかの役に立つことを願い、4年間の活動とその結果をまとめます。2014年。開発組織を作るためにやってみた事と 2015〜2016年で開発組織を作るためにやってみたことを最新結果と共にまとめた物になります。

前提：自分は何をやりたかったのか

"高速で高品質な開発ができる組織を作りたかった"が一つ。これは前のエントリ技術的負債について考えたで詳しく述べています。

もう一つは "有名プロダクトも知名度もない会社で腐った開発をしてたら、採用ができないよの解決"です。採用は会社の生存には欠かせない重要な要素ですが、エンジニアにはセプテーニの知名度はほぼありませんし、GANMA!等を除けば基本的に社内向けのツール開発になります。その上で開発文化も残念な状態になってしまってはエンジニア組織を維持できるとは思えませんでした。羨まれそうなくらい素敵な開発文化を整え、それを嘘偽りなく周知することで採用（生存）に繋げることを目指しました。

行ったこと: Scalaの普及

活発に開発されている全てのプロダクトがScala採用になるくらいの普及活動を行いました。

理由1: 意識を保つため。我々は美しく読みやすいバグの少ない実装を目指しています。どんな言語でも良い実装は行えます。とはいえ記述が大変だったり、小細工が必要だったり、型やIDEの支援を受けづらかったりすると意識を保つのが難しくなるかもしれません、楽をしたいところです。Scalaはやりたいことを小細工無しに綺麗に書ける場面が多く楽が出来ます。

理由2: 出会いのため。新規のよく話題に上がる言語のほうが意識の高い人と出会える確率が高いと考えられます。(Pythonのパラドックス)。 "なぜScalaに至ったのか"をトリガーに、どれぐらい気が合うかも測りやすいでしょう。広く普及した言語でなければ人が集められないのでは無いか？と心配される方がいらっしゃるかもしれませんが、心配いりません、気の合う人を育てれば良いのです。

普及方法: 以下の流れを基本に、後述の"社外アドバイザー"と"全レビュー"、"技術指針"を組み合わました。

GANMA!(サーバ側。後にAndroidクライアントも)をScalaで作成
GANMA!チームに他プロダクトから留学してもらう
留学を終え、Scala・DDDで新規プロダクト開発に着手
その後どんどん株分け

おあと全員Macbook Pro 15インチマシマシ版にしました（重要）

感想: 実装もレビューも容易になり、コードの質が上がったように思います。またScalaをトリガーに非常に優れた方々が来てくださるようになりました。Scalaを標準にして良かったと思っています。

行ったこと: ドメイン駆動設計(DDD)の普及

活発に開発されている殆どのプロダクトがDDD採用になるくらいの普及活動を行いました。

理由: ドメイン駆動設計とは乱暴に表現すると"普段使っている言葉が一番性能高いから、言葉と実装を一致させる設計にしましょう" という設計方法です。エンジニア・非エンジニア問わず生来備わっている言語能力を活用して設計を行うことにより、要件の芯を捉えつづける手助けになることが期待されます。

普及方法: Scalaの場合と同様にGANMA!からの株分け＋社外アドバイザー + 全レビュー + 技術指針により普及しました。

感想: 思ったよりも良さが多かった、という印象です。

設計がとても固くなった（設計に実装都合が入りづらくなった / "毎週連載"の"読み切り" みたいな矛盾する設定は設計レベルで存在できないようになった、等）
コードの見通しが良くなり、レビューが容易になった。最悪ドメイン層だけでもちゃんと見れば致命傷にならない。
リファクタリングが決断しやすい。実装することを言葉で言ってみておかしな事になってきたら要見直し。
言語能力は誰にでもあるので、後で入ってきた人が馴染みやすい（重要）

一定規模かつ開発し続けるものであれば、今後もDDDでやりつづけるでしょう。

非常にオススメできる手法なのですが、実践はなかなか難しく、大変読みづらいEric本を正確に読み抜く能力を持つか、DDDについて相談できる先駆者を確保しておかないと腐った何かができあがる可能性があります。 GANMA!でDDDをやってみてから1年くらい経ったは少しだけ参考になるかもしれません。

なおエンティティだVOだレイヤードだヘキサゴナルだ、等を指してDDDという方がいらっしゃいますが、それらは実践のためのテクニックに過ぎないのでご注意を("軽量DDD"で検索)。

行ったこと: ユニットテストの普及

書くべき所はまずテストが添えられている、という状態になるまで普及活動を行いました。(書くべき所＝不安を感じたら、とよく言っています）

理由: 殆どの場合でテストは書くべきでしょう。テストがない≒リファクタは出来ない、とほぼ同義なので、テストを書かずに突き進むのは自殺行為である、というくらいテストが重要であることは常識である世の中になりました(なってくれ)

普及方法: TDDの普及活動で有名な@yattomさんや@t_wadaさんが講師をされていたTDD研修に参加し、教え方を学んでからエンジニア全員にテストを書いてみよう会を開きました。それからはScalaやDDDと同様に、GANMA!からの株分け・全レビュー・技術指針などの施策で普及率を高めていきました。

感想: 基本的に、"テストがない不安さ"を一度味わえば自然とテストは書きたくなりますので、"テストがない"というのは組織の問題じゃなかろうか、と思います。テストが一般化する以前から生き残っているシステムだとか（しかたない）、テストを知らない人に土台を作らせたとか（ありそう）、テストを書く＝遅くなるから損、とか思い込んでる人が上にいるとか（ないよね…？）。

行ったこと: スクラムの普及

スクラムを理解した上で、開発手法としてスクラムを選択したり、スクラム以外を選択したりできるようになりました。

スクラムについて: スクラムの提唱者はKen Schwaber氏とJeff Sutherland氏で、彼らの共著であるスクラムガイドが原本となりますが、これだけでスクラムを実践するのは至難です。またスクラムを教える団体はとても沢山あり（両氏が関わった団体だけでも Scrum Inc/ Scrum.org /Scrum Allianceの3社)、実践方法もバラバラだと考えられます。書籍も沢山発行されていますが、スクラムのバージョンアップに追従できておらず、"スクラム is 何"が説明し辛い状態です。

このエントリで紹介するスクラムは次の二つになります。

オレオレスクラム: SCRUM BOOT CAMPなどを読み、我流でやってみたスクラム
ガチスクラム: Scrum Alliance(Odd-e Japan社)の研修・トレーニングにより、より正確にスクラムガイドに準拠したスクラム

違いについてはGANMA!チームのScrumについてをご参照ください。

理由1: プロダクトオーナーにハンドルを持たせるため。スクラムを実行すると、チームの持つ資源と投資対象の全てをかなり正確に把握できるようになります。平たくいうと新規開発しなくてはならないもの、直さなくてはならない不具合、返すべき技術的負債等がそれぞれ値段と共にリストアップされる状態になります（そして1ターン毎に使える金額も解る）。これが把握できて初めてプロダクトオーナーは費用対効果を追求できるようになりますし、選択の説明ができるようになります。

理由2: 裁量労働制への対応。裁量労働制は（適用して良いのかどうかはともかく）"何時までに何をやるべきか"をハッキリさせないとブラック企業まっしぐらです。何かしらの開発手法の導入は欠かせません。スクラムはスプリント単位（1週〜2週)で計画を立てるので、大変相性がよいです。

普及方法: 最初の頃はSCRUM BOOT CAMP等を元にしたオレオレスクラムをGANMA!で実施。これから株分けしつつ、講師の方をお招きして全社員で"LEGO®ではじめるスクラム入門"をやってみたりしました。全社に普及すると共にオレオレスクラムに課題を感じる場面が多くなり、会社としてよりもっとスクラムを学ぼうとOdd-e Japan社の開催する認定スクラムマスター研修を何人かが受講、また同社のトレーナーをお招きし数ヶ月トレーニングをしていただきました。

感想: オレオレスクラムとガチスクラムの効果の差が印象的でした。ハンドルを持たせるだの労務管理がちゃんとするだの、はオレオレスクラムでも実現できますが、ガチスクラムはスプリントの安定さが桁違いでした。

ガチスクラムの実践は難しく、例えばプロダクトバックログアイテム（作りたい機能 — タスク/チケット）を、30分や60分でできるくらいのスプリントバックログアイテム（サブタスク）に1〜2日、下手をすれば3日もかけてチームで実装内容を検討し分解するヘビーなセレモニーがあったりします。ストレスなく実践できるようになるには、相当な苦労が伴いますが、ここまでやるからこそ手戻りも想定外も少なく助け合いをスムーズに行うことができます。効率も上がるので速度も落ちませんでした（オレオレスクラムの最高速度＞ガチスクラム平均＞オレオレスクラム平均）。

行ったこと: 全レビュー制度と社外アドバイザー契約制度の作成

社外アドバイザーのかとじゅんさんや麻植さんを含めたレビューチームにより、社内の全てのプルリクエストをレビューをしています。

理由1: 間違ったやりかたの波及防止。 DDDやScalaの導入を旗振る上で最悪なのは間違ったやりかたが普及してしまうことでしょう。自分もDDDやScalaは初心者だったので、これをやってしまうリスクがあったので、防ぐ方法を用意する必要がありました。

理由2: レビューの質の担保。よい開発を行うためにコードレビューは欠かせませんが、経験の浅いチームや人数が少ないチームではレビューの質や視点の豊富さに課題があります。全レビューにより、これの解決を図りました。なお全レビュアーからの指摘はただのアドバイスであって強制ではないとしているのでチームの自治権は維持されています。

導入の流れ: 前職の同僚で、DDDの情報を多く発信しているかとじゅんさん(ChatWork)から「新宿でぼったくられてお金がない、できる副業はないか？」と相談されたのが切っ掛けで、新しく作るDDD採用プロダクトのレビュアー・アドバイザーとしてはいっていただきました。

その後、麻植さん(ScalaMatrusi座長/最近エフ・コード社商品開発部顧問にも就任されました)にも入って戴き全レビュー体制に発展しました。(PRのレビュアーに自動で混ざる仕組み。bitbucketのWorkzoneというプラグインで実現)

感想: 幸運にもスゴい人達にアドバイザーとしてはいっていただけたなーと思っています。

かとじゅんさんの働きにより、DDDの間違ったやり方の発生がとても抑えられている
麻植さんの働きにより、Scala的に良くない書き方(例: Option.get)がとても抑えられている

等の効果が実感としてあります。また後述の技術指針に反する状態を見つけやすくなりました(テストがない、プロトタイプが実践投入されている、等)。

みんなのレベルは徐々に上がっていくわけで、徐々に指摘事項も減っていく傾向にありますが、それでも美意識低下への抑止力になっているように思います。調整を間違えると息苦しさにつながったり、間違ったやり方を強制してしまったり等の問題を起こしやすそうなので、手放しでオススメできる施策ではありませんが、やってよかった施策だと思っています。

行ったこと: 技術指針の制定

会社としての品質に対する考え方、採用する技術やその理由と例外をまとめたこの文章を作成し、実体と文章が一致し続けるように努めました。

我々は”高速高品質”を目指す
Scalaを使うときの理由・使わないときの理由
スクラムをやるときの理由・やらないときの理由
DDDをやるときの理由・やらないときの理由
テストを書く理由
レビューをする理由

などが記載されており、実際にセプテーニ・オリジナルではこれ基づいた開発活動をしています。

理由: 全レビューを行う上で何を正とするのかを定めておかないと無用な混乱が発生するので、会社の考えを文章として形にする必要がありました。またプロトタイプと称して雑に書かれた物（しかもJava)が実践投入される、という事態が発生していたりもしたので、それを防ぐ意図もありました。（プロトタイプには技術指針は適用しないが、プロトタイプとは実戦投入出来ないものである、とわざわざ定義してあったりするのは、こういう経緯だから）

感想: 基準とその理由がハッキリしたことにより、気を抜かずにちゃんとやっていこうという意識が強くなっていった印象があります。

また、これのとても良かった点はこちらで公開したことです。

「技術指針にとても共感した」で採用に競り勝つことがとても増えた
我々のことを紹介するのに、とても手っ取り早くて便利
開発文化に関して、入社後のズレがない（ぐだぐだな開発現場だったらどうしよう、という恐怖も軽減）

などの効果がありました。是非どの会社にもやって戴きたい施策です。

行ったこと: 開発環境の整備

社内ツールを色々整備しました。

チャット: ChatWork ⇒ 後にSlackに乗り換え
コード管理：Atlassian Bitbucket Server(旧 Stash)
タスク管理：Atlassian JIRA
CI: Atlassian Bamboo
知識の蓄積 : Atlassian Confluence

理由: 高速高品質のために道具をそろえるのは当然のこととして、これらの中で最も大事なのはBitbucket(GitHubもどき)のプルリクエスト機能でしょうか。マージするにはレビューを行う必要があるようにできるので、無レビューなコードが発生しづらくなります。レビュー無しで美意識を保つことは難しいので、ちゃんとした開発を行うためには重要です。

なおGitHubでなくてBitbucketなのは、当時は値段が1/10くらい安かった割には、結構ちゃんとした使い勝手だった/むしろ企業向けとしては便利なことが多かった(Atlassian系で全部固めると権限管理がとても楽)、という経緯でした。

感想: 製品自体に強い拘りはあまりありません

エンジニアに限定するとSlackは便利。ChatWorkもエンジニア以外にはとても良い。
スクラムやるならJIRAは本当に便利(本当だって！)
BambooはBitbucketと連携させるならすごく便利
Confluenceは使い勝手良いとは思わないが、ページ毎に権限管理がちゃんとできるしなにかと便利

といった感想です。道具自体はカテゴリ毎にそれぞれ必須だとおもいますが、予算や好みに応じたものを選ぶと良いでしょう。

行ったこと: ScalaMatsuriで同人誌配布

ScalaMatsuri2016と2017の将軍スポンサーを務めさせて戴いたとき、プライズとして「セプテーニ・オリジナル技術読本」という同人誌を配布しました。（ 2016年度版、2017年度版）

理由: セプテーニの本業は広告代理店なので、エンジニア界隈にはとても知名度が低い状態でした。ある程度文化が整った2015年頃からなんとか知名度を上げようと、いろいろなイベントを企画・参加するようになりました。ScalaMatsuriに将軍スポンサーとして参加させて戴くとき、ボールペンやクリアファイルを配布しても誰の心にも刺さらなさそうだったので、我々がどういう技術水準なのかが解るようにみんなで技術ネタを詰め込んだ本を執筆し、頒布してみることにしました。

感想: 一冊あたりの価格はグッとくるのもがありましたが、作成は楽しく、あれは良かったというご感想をいただくこともあり、大変良かったです。採用に繋がることが何度かありました。

主な行ってきたことは以上です。

自分のミッションは何だったのか

次の二つが主なミッションでした。

GANMA!を成功させること
セプテーニ・オリジナル(当時は分社化前なのでセプテーニ本体)の開発文化をつくること

GANMA!はスマホ向けに、自社で作家様を募集しオリジナルの漫画作品を作成、配信する事業です。800万DLも超え、利用者も多く、アプリのレビューも多くの高評価を頂戴できている状態です。ストアのランキングに常にランクインできるようにもなりました。GANMA!は間違いなく大成功であると感じています。

開発文化の醸造に関しても、とてもよい文化になったとおもいます。自分は旗を振っただけに過ぎず、皆様がそれに乗ってくださったことがとても良かったです、感謝を申し上げます。このエントリはちょっと固めになってしまったので、もしかすると堅苦しいところなのかな？と思われるかもしれませんが、そんなことはありません。実装がずっと楽しめる職場だとおもいます。

このスライドには 〜「安定した品質」 && 「誇れる組織」 && 「価値あるプロダクト」を自分で作ってみせるまで打ちひしがれたままと書いたのですが、やれたと思います。

なぜ辞めるのか + このエントリは何が言いたいのか

僕が退職したのは、完全に0からつくるベンチャーに誘われ、その可能性に魅力を感じたからです。つまりはわがままです。

わがままに過ぎないのですが、トラック係数に普段から気をつけていて、ほぼ全ての場面で自分無しで何とかなるようにしてあったことと、非常によい人達にご入社いただいて、最近ではScala関西Summit 2017で5人も発表したり、元Lightbend社で現在スターバックス社のDirector of EngineeringであるJamie Allen氏を招いたイベントを開催したり、より高度なDDDを目指し様々な手法を取り入れたりなど、ますます発展していっていて、大丈夫だな、と思ったのもあります。

僕はセプテーニ・オリジナルは最高の環境であると信じています。次は完全に0からやりなおしなので、運良く生き残ることができれば、本エントリでご紹介させていただいた事を踏襲しつつ、同じくらい最高の組織を作ることを目指すと思いますが、それは何年も後のことです。

何年も経てば、そのときには、セプテーニ・オリジナルはセプテーニ・オリジナルで、より成長し、より良い会社になっているとおもいます。そうなることを祈っていますし、そうなるでしょう。次もまたScalaをやりますが、同じScala企業として切磋琢磨できるとよいなーと思っています。

このエントリをご覧戴いている方で、もしちゃんとした開発をしている場所に行きたい！と思っている方がいらっしゃれば、セプテーニ・オリジナルは良い選択の一つです。よろしければセプテーニ・オリジナルに興味を持って戴けると幸いです。イベントに行ってみるなどすると良いでしょう。

セプテーニ・オリジナルをよろしくお願いいたします。

次では何をやるのか

先述の通り、完全に新規のベンチャー企業(といっても起業の素人ではない) にコアメンバーとして参加し、新規のプロダクトの作成を行います。 BtoCのプロダクトで、iOS・Android向けのアプリを作成する予定です。どういったプロダクトなのかはまだ公表できないですが、きっと面白い物がお届けできるかとおもいます。

社名はSUGAR株式会社といいます。うまくいけば年末〜来年にでもメンバー募集ができるかとおもいます。方法はともあれ、高速高品質を目指した良い開発を行える組織を目指すつもりです。もしご興味がありましたら @sugitaniに対して「興味あります、動きがあったら教えて！」← これをそのままコピペしてDMを送っていただけますでしょうか。よろしくお願いいたします。

長文を読んで戴き、ありがとうございました。