49
Challenge for Startup's CTO from Big company 2017 October 28 https:/yourmystar.jp/

Challenge for statup's cto from big company nagaaki hoshi

Embed Size (px)

Citation preview

Challenge for Startup's CTO from Big company

2017 October 28

https:/yourmystar.jp/

自己紹介

星 永亮 (ほし ながあき)

• 2010年4月 楽天株式会社入社• 2013年 Webアプリケーションエンジニア• 2014年 DBA• 2015年 テクニカルディレクター• 2017年3月〜 ユアマイスター株式会社入社

楽天カード時代

• プログラミングほぼ未経験で入社→半年の開発研修

• フロントがPHP、バックエンドがJavaのC向けWebアプリ

• メジャーバージョンアップに際して、DBAにコンバート

• MySQLからOracleへのDB移行がハイライト

• 複数事業入り混じった案件で、PL&エンジニアで社内MVP

• サービス運用担当者の時期には、先輩に教わりながら、いろんなツールを使って遊んでた

新サービス開発室時代

• プログラミングすることはなくなった

• プロダクトマネージメントがメイン

• 予算策定、人材調達、開発リソース調整、要件の策定・・・

• 事業担当者が自分を含めて2名(Project 6)

• 社長室直下

• ”幕の内弁当恐怖症”

• 要件詰め込みすぎ

• 手段が目的化

ユアマイスター株式会社とは

創業1年のスタートアップです。日本一「応援される」会社を目指してます。

会社名 ユアマイスター株式会社(Your mystar, Inc)

本社事務所 東京都渋谷区桜丘町3-2 第3野口ビル201号室

設立 2016年8月8日

資本金 1億500万円

株主 星野貴之 他

代表者 代表取締役社長 星野貴之

従業員数 社員13名 インターン25名

MaintenanceHouse

CleaningRepair Cleaning Remake Exchange

大切なものを、もっと大切に

ハッピートライアングル

Partner User

Yourmystar

お客さんがそもそも喜ばないことはやらない。お客さんが喜んでもパートナーさんが苦しいならやらない。

お客さんもパートナーさんも喜んでも僕たちが幸せにならないことはやらない。

3つの点、すべてがハッピーであることが最低条件

運営サービス

サービスEC総合プラットフォーム「あなたのマイスター」と大切なものをもっと大切にしたくなるメディア「RELIVERS(リライバーズ)」の運営を行っています。

大切なものをもっと大切にしたくなるメディアサービスEC総合プラットフォーム

https://yourmystar.jp/ https://yourmystar.jp/relivers/

サービスEC総合プラットフォーム

サービス登録サービス検索

サービス予約

メッセージやりとりメッセージやりとり

サービス提供

支払い

レビュー投稿

or

サービス完了報告

①さがす

②予約する

③サービス実施

④サービス後サポート

サービス予約確定

プロお客様

今あなたのチームには何人いますか?

ユアマイスター入社時、僕らは

社員エンジニア数

どんな状況だったか

2016年8月の創業当時から、関わってます。

2ヶ月でリリースという短納期だったため、CakePHPを採用しました。リリース後も

、ユアマイスターさんのエンジニアが入るまで、しっかり機能開発と運用します!(半常駐)業務委託エンジニア

マーケティング担当社員

もともとマーケティングが本業ですが、社内にエンジニアがいないので開発案件

の管理をやってます。

フロントのHTMLやCSSなら書けるので、画面系は自分でも実装しちゃいます。

学生エンジニアインターン

プログラミングが大好きで、遅くまで没頭することもしばしばあります。

自分もいつか起業したいと思ってるので、それまではユアマイスターのサービス

開発、頑張ります。

まずい。

もちろん、CTOなんてやったことなかったので何をすればいいか考えた。

採用?

開発?組織マネージメント?

技術選定?

プロダクトマネージメント?

チームビルディング?

技術力育成?

ブランディング? 技術的負債の返済?

まだ十分にメンバーはいないから、開発をする上での無駄は増える前に解決しておこう。

当時の結論

僕がバリバリコーディングするよりエンジニアたちが働きやすい環境を

まずは

技術スタック(2017年3月)

Amazon

EC2Amazon

S3

インフラ

アプリケーション

デザイン ローカル開発

検索

CI

ミドルウェア

コミュニケーション

解析

Web接客外部連携

SEOコード管理 監視

CMS

技術スタック(現在)

Amazon

EC2Amazon

S3

インフラ

アプリケーション

ElastiCache

デザイン ローカル開発

検索

CI

Amazon

RDS

ミドルウェア

コミュニケーション

解析

Web接客外部連携

SEOコード管理 監視

CMS

AWSやElasticsearchでの性能改善ストーリーは巷に溢れてる。

ちっちゃなチームで、最速の開発をするためにした工夫のお話をしよう。

当時はどんな流れでやっていたかというと、

当時の開発フロー

Amazon EC2

develop branch

master branch

local branch

本番

STG

PullRequest

local branch

PullRequest

Push

手動リリース

developからブランチ作成

手動リリース

各工程に改善点を発見

Amazon EC2

develop branch

master branch

local branch

本番

STG

PullRequest

local branch

PullRequest

Push

手動リリース

developからブランチ作成

手動リリース課題その1

課題その2

課題その4

課題その3

開発スピードアップのための課題 その1

検証環境にdeployするたびに、いちいちサーバーにログインし、GitHubからソースコードを最新化していて属人化、対応時間がチリツモ。

1日何回デプロイすればいいの!!

解決策

CIツール入れて人間は楽しよう。PHP Unitでテストも書いてるんだから、それも回しておこう。

(本当は順番逆ですが)

Circle CI

CIツールです。Jenkinsのように、自前でサーバにインストールする必要がないので、登録するだけで気軽に使えます。GitHubのアカウント連携するだけで即効です。

circle.yml

YAML形式でビルド前、ビルド中、ビルド後の動きを事細かに定義できる。ブランチによって挙動を変えられるのも嬉しい。

machine:timezone: Asia/Tokyohosts:

server11111: 111.111.111.111

dependencies:override:

- composer install --no-interactionpost:

- #DB作成、ユーザー作成、権限付与を行う- bin/cake migrations migrate

test:override:

- mkdir -p $CIRCLE_TEST_REPORTS/phpunit- vendor/bin/phpunit --configuration phpunit.xml.dist --log-junit $CIRCLE_TEST_REPORTS/phpunit/junit.xml

deployment:staging:branch: developcommands:- ssh hoge@server11111 /home/hoge/bin/deploy.sh

<circle.ymlのイメージ>

開発フロー途中経過

Amazon EC2

develop branch

master branch

local branch

unit test

deploy

本番

STG

PullRequest

local branch

PullRequest

Push

Deploy

手動リリース

developからブランチ作成

Trigger

開発スピードアップのための課題 その2

検証環境用ブランチへのPull Requestのつもりで、誤ってmasterにPull Requestを作成。そして、気づかずにそのままmergeからの、本番障害。

解決策

プルリクエストを作る手順を自動化する。エンジニアがするのはSlackにブランチ名を呟くだけ。

にしたい。

zapier

コードを書かなくても、選んで組み合わせるだけで、複数のコミュニケーションツールを組み合わせることができるサービス。

参考:https://zapier.com/app/explore

zapier

設定は5分くらいで終わり、あっという間にミスがない運用ルールを構築できる。Slack × GitHub 以外にもたくさん選択肢がある。

開発フロー途中経過

Amazon EC2

develop branch

master branch

local branch

unit test

deploy

本番

STG

PullRequest

local branch

PullRequest

Push

Deploy

手動リリース

developからブランチ作成

Trigger

開発スピードアップのための課題 その3

4名のインターンを受け入れていたが、知識やスキルはバラバラ。インターン1人ひとりのソースコードレビューの負荷がめちゃくちゃ重い。

• 少人数のチームでは、インターンに形式的な研修を提供するのは難しい

• コードレビューの中にも、視力検査レベルのものも含まれている悲しみ

• 必要最低限のPHPのコード規約を守るレベルにしてからレビューに出して欲しい

解決策

静的コード解析を入れよう。しかも、ローカルが重くなるのは嫌だから、サーバーサイドでやってくれる何かをPull Request単位とかで。

Side CI

参考:https://sideci.com/ja

Side CIによる静的コード解析

PHPはCodesniferとPHPMDを適用している。Pull Requestに指摘行にコメントしてくれるので、レビュー前にコード品質を上げられる。

開発フロー途中経過

Amazon EC2

develop branch

master branch

local branch

unit test

deploy

本番

STG

PullRequest

local branch

PullRequest

Push

TriggerDeploy

手動リリース

developからブランチ作成lint

Trigger

開発スピードアップのための課題 その4

インターンがハマっててもなかなかコミュニケーションが取れずに、必要以上に調査や試行錯誤に時間をかけてしまう。

石川(社員)

高梨(インターン)

自分の開発に集中してるうちに、インターン

がハマってることに気づけない!

社員のみんなが忙しそうにしていて、いちい

ち質問するのは気が引ける!(ググればわかりそうなレベルだし・・・)

解決策

#timesチャンネルを作り、ググったキーワードを都度Slackに書き残してみよう。

試しにやってみたら、劇的に声をかけやすくなった。

jQueryの数字の処理でハマってる

画面をスクロールさせようとしてる

横に並べて表示しようとしてる

現在の開発フロー

Amazon EC2

develop branch

master branch

local branch

unit test

deploy

本番

STG

PullRequest

local branch

PullRequest

Push

TriggerDeploy

まだ・・・

手動リリース

developからブランチ作成lint

Trigger

deploy

少しずつの改善を積み重ね、得られたもの。

人間がすべき仕事に少しずつ注力できるようになることで、

一人当たりのスピード。チームとしてのスピード。

会社の成長速度に追い越されぬよう開発が引っ張れる体制を目指して。

質疑応答