_5_開発体制整備編

Startup CTOとして2019年に取り組んだこと【Web開発体制整備編】

効果測定体制構築

メンバーが増えたことで、「チームがどの方向へ向かっていくべきか」と「目指す方向へ進めているか」をよりしっかりと自覚する必要があると感じました。

これらを測る指標なしでは目を瞑って歩き回るようなものでどんなに素晴らしいメンバー・開発環境を整えたところで目的は達成されないでしょう。

Webサイトの開発においてそれらは、以下の指標で表現できると考えました。

・要求される機能の提供
・コンバージョン数
 → 小目標1:Googleの検索順位
 → 小目標2:サイトPV / サイト内での回遊

特にコンバージョン数のその小目標の方は日々具体的な数値を取っていくことが可能なので、できるだけ早く取り始めるべきだと思いました。

しかし、狙っている検索キーワードでの検索順位や、サイトのPV数等の指標を毎日、わかりやすい形式にまとめていく作業はとても単調で工数がかかります。

この辺りはGoogle Apps Scriptを使って完全に自動化することにしました。

毎日8:00〜9:00の間に自動的にスクリプトが起動して、サイトのコンバージョン数の小目標を自動収集してスプレッドシートにまとめてくれます。

画像1

画像2

GASの開発には@google/claspを使いました。GASではソースコードのファイルを分けても関数のスコープが別れなかったり、import / export / require等が使えなかったりして若干苦戦したので、最終的にはWebpackで1ファイルにバンドルしてしまう体制を構築しました。

こうすることでmoment.jsのようなライブラリもバンドルできて、GASがよりJavaScriptの実行環境として扱えるようになりました。

また、UIレベルでのユーザーの行動を把握して改善につなげるためにヒートマップツールも導入しました。

WordPress開発環境のモダン化

指標が明確になったら、次は開発体制の効率化です。

WordPressで独自テーマを3つほど作っています。テーマはそれぞれ独立したGitリポジトリとして管理されています。

WordPressあるあるかもしれませんが、改善前は以下のようなフロントエンドの開発環境でした。

・CSSはSass等を使わずそのまま書く
・header.phpで共通CSSと各ページ用のCSSファイルを読み込む
・必要なライブラリもheader.phpで読み込む
・CSSセレクタの命名規則なし
・CDNなし

当時のheader.phpはこんな感じです。

<!-- 全ページで共通のCSS -->
<link rel="stylesheet" href="<?php echo get_template_directory_uri(); ?>/style.css">

<?php if (is_home()): ?>
  <!-- トップページ用のCSS -->
  <link rel="stylesheet" href="<?php echo get_template_directory_uri(); ?>/css/home.css">
<?php elseif (is_single()): ?>
  <!-- 記事個別ページ用のCSS -->
  <link rel="stylesheet" href="<?php echo get_template_directory_uri(); ?>/css/single.css">
<?php elseif (is_page('contact')): ?>
  <!-- 問い合わせ用のCSS -->
  <link rel="stylesheet" href="<?php echo get_template_directory_uri(); ?>/css/contact.css">
<?php endif; ?>

この状況をで生じた課題は次の通りです。

・1ページあたりのCSS/JSファイルの読み込みが多い
・CSSファイルをブラウザで長めにキャッシュさせられない
・どのCSSセレクタがどのページに影響しているのかわからない
・ベンダープレフィックスを手動でつける必要がある

このあたりの課題を一気に解決すべく、Node.jsとWebpackを使ったフロントエンドビルド環境を構築しました。

詳細は本稿では省きますが、現在のWordPressのテーマ開発環境は以下のような状態になっています。

・モジュールはnpmでインストール / 管理
・CSSはSassで記述
・CSSはPostCSSでベンダープレフィックスを自動追加
・JSはBabelでレガシーブラウザでも動作するコードにトランスパイル
・CSS / JSは最終的に1ファイルずつにバンドル
・CSS / JSはスペースや改行を削除・変数名を最適化して容量削減
・CSS / JSファイルはファイルの中身から計算されたハッシュをファイル名に付加することでキャッシュ対策
・ソースコードの保存時に上記処理を自動実行
・CSS / JSや素材画像はCDN(Amazon CloudFront)から配信

控え目に言って非常に快適です。学生Webエンジニア2名の採用段階では、これらのスキルは求めていませんでしたが、スムーズにキャッチアップしてくれてとても助かっています。

本番環境 / ステージング環境へのデプロイパイプライン構築

前述の改善を行う前のデプロイ方法はシンプルで、サーバーにSSH接続して $ git pull を実行するという手順のみでした。

GitHubリポジトリのmasterブランチにマージされたら本番サーバーにWebhookを送って自動的に$ git pullを実行するようにしてデプロイ完了後にSlackに通知するくらいの自動化もしました。

しかし、今回ガッツリフロントエンドのビルド環境を整えたので、このステップを本番環境 / ステージング環境で行う必要が出てきました。

本番環境 / ステージング環境でビルドを行ってもいいっちゃいいのですが、ビルド環境を整えたり、ビルド中のリソース消費に気を配ったりする必要があり抵抗がありました。

そこで、AWSのサービスであるAWS CodeBuildを使うことにしました。具体的には、以下のプロセスでフロントエンドのソースをビルドしてデプロイします。

・GitHubのmaster / stagingブランチへのデプロイを拾ってCodeBuildが起動する
・Slackにビルド開始を通知する
・フロントエンドに必要なNodeパッケージ等々をnpmでインストールする
・フロントエンドのソースをビルドする
・RSyncで本番サーバーに同期する
・Slackにビルド終了を通知する

AWS CodeBuildには以下のような特徴があります。

・完全従量課金制=契約や月額が必要ない
・並列実行し放題=同時実行2ビルドまで、等の縛りがない

手探りで開発体制を考えているフェーズで、月額課金のCIサービスを契約したり、Jenkinsのようなビルドサーバーを自前で立てたりするのはリスクが大きいです。

従量課金制のAWS CodeBuildを使うことで、必要なときに必要な分だけビルド用のリソースを用意することができます。

今ではこのビルド・デプロイパイプラインを使って、多い日では1日10回くらいのビルド / デプロイを実行しています。

待っているだけで安全にデプロイされるのでとても快適です。

改善スプリントを設計

ここまでで、

・開発の成果を測る指標
・素早く着実な開発を可能にするフロントエンド開発環境
・成果を本番環境に0人時でデプロイするパイプライン

が整いました。

次に着手したのは、改善を回すためのチームとしての体制づくりです。

当時必要だったのは、

・サイトの指標を見て仮説を立てる
・仮説を元に変更内容を検討する
・変更内容を具体化するための設計を行う
・変更内容を実装する

この4つです。もちろんこれらは1人が複数やってもよいし、複数名で1つを担当しても良いものです。要は最初に決めた指標の上で結果が出せればなんでもよいです。

結果、以下のような布陣になりました。

・プロダクトオーナー
・サイトの指標を見て仮説を立てて変更内容を検討するマーケッター
・変更内容をUIに落とすWebデザイナー
・UIの変更を具体化するための設計を行うシステム設計者(僕)

このメンバーで隔週の会議を開き、そこで1週間にやることを決めるスタイルです。

また、改善を適用してからデータが集まるまでは多少待つ必要があるので、以下のようなタイムラインで進めることにしました。

#5_採用活動編

開発メンバー2名のマネジメントの工夫

会議で決めた変更点を元にシステムの変更内容まで落とすのは僕が担当しましたが、そこから実際にコードを変更していくのは完全に学生Webエンジニア2人にお願いしていました。

作業を依頼するに当たって注意していたことは2点です。

・できることを依頼する
・依頼した内容ができたら、120%の内容を依頼する

採用の時点で「このような働き方をして欲しいから、このようなスキルセットを持っている人を採用したい」という形を取っているので、それを全うしてもらうだけのシンプルな形です。

「スタートアップに入ってくれたからこそ、責任感を持って主体的に動くような働き方をさせたい」みたいな考えはここでは求めてはいません。

もしそうするなら募集・採用の段階でそうすべきです。

できると思ったことを依頼し、できたらより上のレベルを要求する(=自分の予測が外れただけで、本当はもっとできたのでは?と考えて探る形)。

もしできないことがあれば、無理に指導せずできる範囲でお願いする。

まず何よりも安定した開発ワークフローを維持して、立てた指標の上で結果を出してもらえる仕組みを作ることに注力しました。

2人の学生Webエンジニアがジョインして4ヶ月 / 2ヶ月が経過しますが、2人ともどんどん技術を吸収してくれてアウトプットの質を高めてくれています。

ここまでやってようやく結果がついてきた

本稿で挙げた体制づくりを始めたのが今年の8月なので、完成までだいたい3ヶ月かかりました。

ソースコード上の技術的負債を徹底的に片付けて快適にする作業もみんなで力を合わせて乗り越えてきました。

ここまで進めてようやく望む結果がで始めたところです。

ここからさらに重箱の隅をつつくような改善を重ねて伸ばして行けたらと考えています。

チームがフォーカスできるような仕組みづくりにフォーカスした2019年後半でした。

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

5
Engineering&Design/組織づくり/自分の中のモヤモヤを強みに変えていくためにアウトプットします。

この記事が入っているマガジン

CTO

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。