2017年末から都内の会社で働き始めて、一年ほど経過しました。新しい年でもあるので、自分が一年間どんな仕事をやってきたのか、振り返ってみることにしました。ベトナムから帰国して一年半ほどが経過し、仕事をするのも久しぶりだったので、入社前後は不安要素が多かった気がします。

会社としては、

• 若いベンチャー
• 平均年齢も若め
• 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の使い方を思い出すとか、昔読んだ技術書を読み返すとか、新しい事を覚えるのにあまり時間を使えなかったので、今年は少しずつ時間を取っていきたいです。