会社としては、

• 若いベンチャー
• 平均年齢も若め
• B向けwebサービスの開発
  • webはRails + React
  • iOSアプリとAndroidアプリもある

という属性です。

問題多発

入社してすぐの頃はバグが頻発していて、全体的に慌ただしい状況でした。この問題はずっと引きずっていて、当時に比べればかなりマシになってきているものの、まだ収束していません。入って一ヶ月ぐらいの頃に、社内会議で「全然テストしてないですよね？」という発言をした記憶があります。

原因としては、

• 仕様・設計に対してテストするべきはずが、まずい設計のせいで自動テストが書けない
  • アプリケーションアーキテクチャがまずい
  • 数百行の長いメソッドを久しぶりに見た
  • god object的なやつも見た
  • 適切にレイヤー分けできていない
• 仕様が不定なせいでテストケースも不定・実装漏れが発生
  • 画面コンポーネントをテストしてない
  • 画面遷移・シナリオテストをしていない

といった要因でした。

性能バグ

サービス停止につながる致命的なバグもありました。春先にかけて、ユーザー数の多い企業が利用開始となり、利用者が増える月末にサービス停止が多発しました。主な原因としては、DB負荷です。参照系のAPIに関してはおよそ一ヶ月ほどで収束しました。平均レスポンスタイムは600-670ms程度から、5月以降から現在までは120-150ms程度で推移しています。更新系はまだ遅い場合があるものの、対処できてません。

Railsのeager_loadが多用されている

10個以上のテーブルがjoinされている箇所がありました。preloadにして大体解決しました。

N+1問題

これもpreloadにして大体解決しました。

どちらにせよ、データ数が少ない状態でしかテストしておらず、100件程度のデータを入れればすぐにわかるような問題がずっと放置されていました。

ページネーションしていない

あればあるだけデータを表示してしまう一覧画面がいくつかあり、1000件のデータが表示されるまで1分近く待つような状況もありました。致命的なところはページネーションするようにして解決しました。

pluckした長いidリストがログに出ていた

あるテーブルのidをpluckして、それを後続のSQLに渡していた箇所があり、それがスロークエリーを引き起こしていました。さらにスロークエリーのログに、そのSQLのwhere句にある長いidリストが大量に書き込まれてしまい、ログファイルを保管していたサーバーのディスク容量が圧迫され、停止するというのもありました。

• スロークエリーの基準を緩くした
• pluckからselectに変えて、SQLを1つにまとめた

スロークエリー

あとはほとんどが普通のスロークエリーだったので、NewRelicでレスポンスの遅いAPIを見つけてチューニングしていきました。必要なindexが無かったもの・非効率なSQLなど、この辺はセオリー通りの対応です。

今振り返ってみて

月末の利用者が多いというサービス特性があるにも関わらず、実質的に月末ちゃんと動かないサービスを提供してお金をもらうのは詐欺に近いものがあるなと思いました。対応が後手回ってしまっていたのも、手が回っていなかった事以上に、チームの作業限界を大幅に超過していた事に気が付かなかったのが根本的なヤバさかなと思いました。後述するPM不在のデメリットがもろに出ていたように思います。

プロジェクト管理の話

どのレベルでもマネージメント能力のある人が一人もいません。それを象徴するような愚痴を聞くこともあります。そういった現状に課題を感じた開発メンバーが主体となり、秋ごろからはPMBOK勉強会が始まりました。

自分も一応参加してみて、基本的な知識が全くない状態で仕事をしている人が多いという事実が分かりました。自分の場合はSIer出身なので、上流から下流まで、多少なりとも開発に関わることは勉強したり、仕事で一通り使う機会があったためその基礎はあったと思っていますが、このあたりの知識の欠如が発覚してこれが仕事の仕方にも大きく影響しているように思いました。

一番ヤバいのは、炎上しているのにそれに気づける環境にないという事です。

以前にも、1on1ミーティングでこの辺りの必要性は話をしてみたものの、あまり理解されているようには思えません。スキル・知識がないことを非難するつもりは全くなくて、毎月5-10時間程度の勉強時間を確保すれば、より円滑な仕事ができるのに、そうしない・できない理由はなんなんだろうかというのが自分の問題意識です。

• 何かが足りていないけどそれが何であるか、理解できていない
• 何かが足りていないという自覚が無い

という可能性なのかなと思っていますが。日本人の場合、社会人になると本を読まない・勉強しないというのはすでによく知られた話のようで、2018年はそういった記事をちょくちょく見かけました。

朝会

入社以前から、朝会をやっていて、

• 昨日やったこと
• 今日やること

をチームで共有しています。しかし、各自のタスクはその人自身しか把握していないため、先週言っていたタスクが終わっていないなど、進行中のタスクが多くなる状況が発生しています。

主にPRの指摘・修正が繰り返し発生している状態で、別の割り込みタスクが発生し、・・・というのが原因でした。カンバンの本を読むと、どこかのタイミングで作業調整をして、進行中のタスクを終わらせるというのが一般的な話のようです。

• 終わらせることを最優先にする
• 終わるまで始めない

という話をしてみたものの、ユーザーからの問い合わせに対して、当日中に一次回答するという目標もあり、なかなか完遂するのは難しい状況です。

PRがたまる問題

よく聞くプルリクエストがたまる問題も発生しました。各自が優先事項をもってタスクに取り組んでいますが、チームとしての優先事項が見えてないと、完了するPRが増えないという話です。開発者同士でレビューしているので、レビュワーも同様に開発タスクを持っていて、自身のタスクとレビューとどちらを優先するべきなのか、判断をつけられなくなっていました。

現状としては、自分が専任レビュワーになっているような状況です。一日中レビューしているので、全くPRがマージされないという状況はかなり減りましたが、それでも複数人からPRが来るので、変更点の多いPRだとなかなかレビューが進まないという課題が残っています。

自動テスト

秋ごろからは、Rails5へのバージョンアップも見据えて、自動テストを増やすべく、毎週木曜日がテストの日になりました。テストで有名な業界人である「らいおんさん」の写真を私がslackに貼りつつ、各自が「今日はxxのテストを書きます」と宣言してテストを書いていくスタイルです。

レビューをしていて、RSpecの使い方が分からないという人が多数だったため、esaにガイドラインを書きつつ啓蒙していきました。現在は主に2種類の自動テストを書いています。e2eテストは未着手なので、system spec/feature specはまだ対応できていません。

• ドメイン層のユニットテスト
• アプリケーション層のインテグレーションテスト

途中経過

取り組みを始めて1ヶ月ほどで、メンバーの書くテストコードが劇的に良くなったと実感しています。木曜日という練習時間を確保したことで、テストコードを書くハードルが下がり、各自の案件のPRでもテストコードをちゃんと書けるようになりました。また、バグのあるコードを書いていても、しっかりテストが失敗したという状態になってきました。

カバレッジ

サービス上、重要なクラスに対しての自動テストを増やすのが目的なので、個人的にはカバレッジxx%という目標はあまり意味があるとは思っていませんが、開発チームの目標としてはまだ30%台という状況です。

手動テスト

画面遷移を伴うシナリオテストなど、実際に手を動かして実施するテストも依然として必要ではあります。テストケースをどう記述するかで迷っている部分はありますが、あまりガッチリした操作・期待値を書くとメンテ辛そうという気がしています。テストケースをmdファイルに書いて、githubで見ながらテストできるといいかなと思ってます。

• メニュー > xx登録画面を開く
  • xxに金額を入力する
  • 保存する
• メニュー > xx一覧画面を開く
  • 保存したデータが表示されていること

みたいな感じで。実際には不正データの場合にちゃんとエラーメッセージが出てくるかどうかとか、もうちょっと細かいことを書いていくと思います。

勉強

上で書いているように、直近の課題はスキルの底上げです。過去の失敗から反省すべきこと・これから達成したいことに対して、レベルと装備が足りていないという状況だからです。レビューの時間を増やしたのもその一環で、設計がまずいコードをどう改善するか理解してもらうという意図もありますし、テストの書き方を社内ドキュメントに書いたのもそういう目的です。

時間を確保して実際に行動するというのが大事なところで、テストに関しては実際に業務時間を割り当ててメンバーにやってもらったら意外なほど上手になったわけですし、スキルの習得に関して不得意なわけでもなく、やったらやった分効果が出てくるのかなと思っているところです。

自分が先頭に立ってやっている部分が大きいので、業務時間にコードを書く時間が全然なくなったという現実もあります。あと何ヶ月続けるんだろうかと考えると、この点に関しては不満ですね。正直な事を言えば、各自で「練習時間」を増やして欲しいですし。早く帰ってその時間を確保して欲しいですが、残業している人がかなり多く、組織としては残業しても全く構わないという方針なので、そう簡単に変わらないだろうなという諦めもあります。間違った方向に時間を使って失敗してきたように見えるので、どうなのかなと思っていますが。とはいえ、実業務で使っている技術にキャッチアップできていない状況を放置しても、大して良い事がないのは前職で経験しています。つまりこの辺りが現在のチームの最大速度になります。

現職まで1年半近く仕事をしてなかったため、入社してからはRailsの使い方を思い出すとか、昔読んだ技術書を読み返すとか、新しい事を覚えるのにあまり時間を使えなかったので、今年は少しずつ時間を取っていきたいです。

説明書

• https://github.com/scalableminds/gulp-image-resize
  • ImageMagick、GraphicsMagickを使ってリサイズするやつ
• https://github.com/sindresorhus/gulp-imagemin
  • gif, jpeg, png, svg画像のロスレスオプティマイザーがバンドルされている

元画像が別ファイルとして残っているので、ロスレスである必要もないし、ファイルサイズを抑えられる別のオプティマイザーを使う。

• https://github.com/imagemin/imagemin-jpegoptim
• https://github.com/pornel/pngquant

環境

$ node -v
v6.9.1
 
$ npm -v
3.10.8

インストール

npm install --save-dev gulp-image-resize gulp-imagemin imagemin-jpegoptim imagemin-pngquant

imagesタスク

import gulp from 'gulp';
import gulpLoadPlugins from 'gulp-load-plugins';
import pngquant from 'imagemin-pngquant';
import jpegoptim from 'imagemin-jpegoptim';
 
const $ = gulpLoadPlugins();
 
const imageSrc = 'frontend/app/images/**/*.+(jpg|jpeg|png|gif|svg)';
const imageBase = 'frontend/app/images';
const imageDest = 'public/images';
 
var imageminOptions = {
  optimizationLevel: 2,
  progressive: true,
  interlaced: true,
  svgoPlugins: [{cleanupIDs: false}]
};
 
var getPlugins = (pngQuality, jpegQuality) => {
  return [
    $.imagemin.gifsicle(),
    jpegoptim({progressive: true, max: jpegQuality}),
    pngquant({quality: pngQuality, speed: 1, posterize: 4}),
    $.imagemin.svgo(),
  ];
};
 
var getResizeOptions = (width) => {
  return {
    width: width,
    upscale: false,
    imageMagick: true
  };
};
 
gulp.task('images:mobile', () => {
  const resizeOptions = getResizeOptions(400);
  const plugins = getPlugins('70-90', 60);
 
  return gulp.src(imageSrc, {base: imageBase})
    .pipe($.changed(imageDest))
    .pipe($.imageResize(resizeOptions))
    .pipe($.imagemin(plugins, imageminOptions))
    .pipe($.rename((path) => {
      path.basename += '-small';
    }))
    .pipe(gulp.dest(imageDest));
});
 
gulp.task('images', ['clean:public:images', 'images:mobile']);

このタスクを実行すると、モバイル向けに小さめサイズの画像を生成できる。

npm run gulp images

運用方法

一度最適化した画像は何度も最適化する必要はないし、最適化が完了した画像はS3などに保存しておいて、必要な時に取りに行く方がgulpの実行時間が減らせると思う。と考えると、defaultタスクからはimagesタスクを外しておいて、画像を追加した時だけimagesタスクを実行し、S3に保存するというのが良さそう。

S3に画像をアップロードすると、AWS Lambdaで画像を最適化して、S3に保存してくれる、というのが一番いい方法かもしれない。その場合、どのくらいのファイルサイズになるか、最適化オプションを調整したい時にはこのタスクが役に立つと思う。

アマゾンのコメント欄を見ると、日本の筋トレ業界ではiHerbが人気らしい。

筋トレしてます

ベトナムで生活するようになってから、体調が非常に悪くなったこともあり、2年前から適度な有酸素運動を、1年半前から自重トレーニングを始め、今年7月に日本に帰国してからジムに通ってウェイトトレーニングを始めた。9月の記録を見返すと太ももが5cm以上太くなっている。2016年4月からは食事を全て見直して、体調は劇的に改善した。現在のBIG3の1rep maxはこの通り。

• ベンチプレス 72.5kg
• スクワット 100kg
• デッドリフト 115kg

さて。日本で必要なサプリメントを買おうとすると、そもそも売ってないか、非常に値段が高い。筋トレといえばアメリカ。サプリメント大国なので、手頃な値段で筋トレ用サプリメントが販売されている。

bodybuilding.comでは海外シッピングにも対応しているのだが、送料が高い。重量や配送日数にもよるが、ちょっと重いものになると¥2,000以上はかかる。しかし、軽い商品であれば¥400程度に送料を抑えることができる（円安になってきたので、現時点では¥448になっている）。

どの商品が¥400で配送できるのか

具体的には、400gまでの商品を注文すると一番安い価格帯の送料が適用されるようだ。

シェーカー

プロテインやアミノ酸などのサプリメントを混ぜるのに欠かせないのがシェーカー。有名ブランドBlenderBottleの中で最大サイズのBlenderBottle Pro45をカートに入れてみた。

送料は¥448となっている。

クレアチン

Optimum Nutritionのクレアチン 300gをカートに入れてみた。

これも送料は¥448だった。

EAA

CellucorのAlpha Amino 30 servingsをカートに入れてみた。一杯で12.7gなので、重量は381gである。

送料は¥448。

グルタミン

PrimaForceのGlutaForm 400gをカートに入れてみた。

送料¥448。

BCAA

Gaspari NutritionのAMINOLAST 420gをカートに入れてみた。

送料は¥1,804となった。

400g以下であれば送料は安い

結果としては、400g以下の商品であればSuperSaverの送料を¥448に抑えることができることが分かった。アミノラストがギリギリアウトなのが悔しい。

Super Saverで注文すると、安い代わりに配送日数がかかる。何度か注文した結果、7-21日程度で配送された。届かなかったことは今のところ一度もない。クリスマスシーズンのせいか、PriorityとEconomyが異常に高い。

説明書

• Browsersync + Gulp.js

環境

$ node -v
v6.9.1
 
$ npm -v
3.10.8

インストール

$ npm install browser-sync --save-dev
browsersync@1.0.0 /home/vagrant/work/browsersync
└─┬ browser-sync@2.18.5

stylesタスク

gulpからlibsassを使うの記事に書いたのと同じタスクを使う。cssを書き出した後にbrowserSync.stream()を入れておく。

import gulp from 'gulp';
import gulpLoadPlugins from 'gulp-load-plugins';
import browserSync from 'browser-sync';
 
const $ = gulpLoadPlugins();
const src = 'frontend/app/styles';
const dist = 'public/assets/styles';
 
gulp.task('styles', () => {
  return gulp.src(src + '/*.scss')
    .pipe($.plumber())
    .pipe($.sourcemaps.init())
    .pipe($.sass.sync({
      outputStyle: 'expanded',
      precision: 10,
      includePaths: ['.']
    }).on('error', $.sass.logError))
    //.pipe($.autoprefixer({browsers: ['last 1 version']})) // vendor prefixを使いたい場合
    .pipe($.sourcemaps.write('.'))
    .pipe(gulp.dest(dist))
    .pipe(browserSync.stream());
});
 
gulp.task('styles:minify', ['styles'], () => {
  return gulp.src(dist + '/**/*.css', {base: dist})
    .pipe($.if('*.css', $.minifyCss({compatibility: '*'})))
    .pipe($.rename((path) => {
      path.basename += '.min';
    }))
    .pipe(gulp.dest(dist));
});

serveタスク

• notify: trueにすると、画面右上に"Connected to BrowserSync"みたいなメッセージが表示される
• proxy: Railsアプリを動かしている場合は、webrickなどのIPやポート番号を設定する
• port: ブラウザーからアクセスする場合のポート番号。開発時にhttp://192.168.35.21:3000を開いていた場合はhttp://192.168.35.21:9000になる
• ui: 設定用画面を有効にするかどうか。{port: 9001}にすると9001番ポートで設定用画面にアクセスできる。

import gulp from 'gulp';
import browserSync from 'browser-sync';
 
gulp.task('serve', ['serve:styles'], () => {
});
 
gulp.task('serve:styles', () => {
  browserSync({
    // show "Connected to BrowserSync" at right-top when reloaded
    notify: true,
    // proxy original http://192.168.35.21:3000
    proxy: '192.168.35.21:3000',
    // Let's access to http://192.168.35.21:9000
    port: 9000,
    ui: false
    //ui: {port: 9001}
  });
 
  gulp.watch('frontend/app/styles/**/*.scss', ['styles']);
});

npm-scripts

説明書によると、package.jsonに"scripts"フィールドを設定しておくと、npm run gulpでnode_modules/.bin/gulpを実行できるようになる。

{
  "scripts": {
    "gulp": "gulp"
  }
}

これで、npm run gulp serveとしておくと、勝手にコンパイル＋自動リロードができるようになった。

他のツールを使う場合

• https://github.com/Browsersync/recipes
  • 他のツールとの組み合わせの設定例が載ってる。

説明書

• npm update
  • npm updateすると、全パッケージが最新版に更新される(package.jsonで指定されているsemverでの最新版の事)
  • npm update pkgすると、指定したパッケージが最新版に更新される

固定したバージョンをアップデートする

npm update、npm update pkgで更新するか、npm install pkg@versionで更新する。特殊な事情でsemverを変えたくない場合にnpm installすることになるんだと思う。

npmのバージョン。

$ node -v
v6.9.1
 
$ npm -v
3.10.8

$ cat npm-shrinkwrap.json 
{
  "name": "shrinkwrap-test",
  "version": "1.0.0",
  "dependencies": {
    "jquery": {
      "version": "3.0.0",
      "from": "jquery@3.0.0",
      "resolved": "https://registry.npmjs.org/jquery/-/jquery-3.0.0.tgz"
    },
    "jquery-ui": {
      "version": "1.12.0",
      "from": "jquery-ui@1.12.0",
      "resolved": "https://registry.npmjs.org/jquery-ui/-/jquery-ui-1.12.0.tgz"
    }
  }
}
 
$ npm update jquery-ui
shrinkwrap-test@1.0.0 /home/vagrant/work/shrinkwrap-test
└── jquery-ui@1.12.1 
 
$ npm ls --depth 0
shrinkwrap-test@1.0.0 /home/vagrant/work/shrinkwrap-test
├── jquery@3.0.0
└── jquery-ui@1.12.1

配付後に更新する場合はnpm install

サーバーにnpm-shrinkwrap.jsonを配付した後に実行するのは、npm installである。npm updateすると、npm-shrinkwrap.jsonを無視して全パッケージを更新することになる。ここでは、別ディレクトリにnpm-shrinkwrap.jsonをコピーして試してみる。

$ npm install
shrinkwrap-test@1.0.0 /home/vagrant/work/shrinkwrap-test2
└── jquery-ui@1.12.1 
 
$ npm ls --depth 0
shrinkwrap-test@1.0.0 /home/vagrant/work/shrinkwrap-test2
├── jquery@3.0.0
└── jquery-ui@1.12.1
 
$ npm update
shrinkwrap-test@1.0.0 /home/vagrant/work/shrinkwrap-test2
└── jquery@3.1.1

npm updateするとバージョンを上げていないjqueryの最新版3.1.1がインストールされてしまった。元に戻す場合には、もう一度npm installする。

$ npm install
shrinkwrap-test@1.0.0 /home/vagrant/work/shrinkwrap-test2
└── jquery@3.0.0