12月に入社した @okapon_pon です。
ラクスルには8人目の開発メンバーとしてジョインしました。（インターン生１人を含む）
現在ラクスルではサービスの機能拡充と合わせて、開発環境改善プロジェクトというものに着手しつつあります。
私が入社した当時の開発環境は、弊社大嶋が以前書いた「ラクスルの開発フローについて」 にある通りGithub、skype、redmineを利用しており、加えてmediawiki、Gyazo-client、cacooといったツールを利用しています。
これらのツールは今でも利用しているのですが、私が入社してからの3ヶ月ほどで開発環境・開発体制も変わってきましたので紹介したいと思います。
コードレビュー体制
コードレビューにはGitHubを使っています。今どきの開発では珍しくないと思います。
ですが、これまでは少人数のスピード重視で開発していたということもあり、
- レビューを通さずにmasterへ直接コミットしてそのままリリース
なんてことも珍しくありませんでした。
また、昨年後半はラクスルのエンジニアが急激に増加したタイミングというのもあって、以下のような問題が発生していました。
- Pull Request(以下PR)のレビューでOKを出せるのは数人だけ
- PRは作っているが説明が一切書かれておらず「どんな変更が行われているのか分からない」
- 結果レビュー出来る人が限られてしまい時間がかかる
つまり、コードレビューの属人化です。
現在はこれらの問題は解消されつつあります。
やったこと1つ目：原則他の人のレビューを通さないとリリースできないようにワークフローを定めた
よく「レビューした方がいい」と聞くと思いますが、レビューを行うと以下のようなメリットが得られます。
- 「バグ」や「潜在的に問題となるコード」「ちょっとしたミス」を減らすことができる
- いい加減なものを書けなくなるので、良いコードを意識して書くようになる
- 指摘(指導)されることでより品質の高いコードを書けるようになる
やったこと２つ目：PRを送る時は「概要」や「変更の理由」など書くようにした
行うようにした理由は3つ
- 人のコードをレビューするのは大変なので、レビューする側のコストを下げる
- Pull Requestが作成された変更の背景を知らない人でも理解してレビューできるようにするため
- レビューをしなくてもどんな変更が行われ、リリースされようとしているのか分かるようにするため
コードレビューの本来の目的である品質確保を行うことは当然のこととして、Pull Requestを工夫することでレビューの効率を上げることができますし、情報共有にまで使うことができます。
実際、最近のラクスルではレビューされる側からレビューできる人が増えてきて、変更の背景を知らなくてもPull Requestに対してOKすことができるようになってきていて、少しずつですが属人的な部分が減ってきました。
その他、普段の開発のPRとは話が逸れますが、レビュー会を定期的に行うことで、コードや機能シェアするようにしています。
これについては、田島の「ラクスルのエンジニア組織について」にて触れられています。
皆自分の業務で忙しいので業務とは別のところで時間を作って、皆でコードを共有するというのも大事だと思います。
普段のコードレビューだけでは得られない様々な意見が得られると思います。
コミュニケーションツール（チャット）
ここではSlack自体の話は割愛し、チームにどんな変化が起こったのか、slackをどう活用しているのかという事に絞って書いていきたいと思います。
Skype上で行っていた、エンジニア、企画部門のコミュニケーションは完全にslackに置き換わりました。slackへ移行した結果として、コミュニケーションが増加し情報伝達速度が向上しました。
そもそものskype利用時（運用時）には以下の様な問題がありました。
- botによるシステム通知が多く会話が流れてしまうのでコミュニケーションが生まれづらい
- GitHubなど外部連携がうまく行われておらず、流れてきて欲しい情報が流れていない
- 結果コードレビューが中々進まない・・・
このような問題が起こらないようにして注意してSlack移行していきました。
- Slack移行の際には必要な通知だけを流す、通知する部屋を分けることを徹底
- 周辺サービス（GitHub、リリース情報、wiki）の更新通知をslackを流すようにする
そうすることにより、エンジニア同士のコミュニケーションは増加し、チャット上で議論や質問が行われるようになりました。
リリース通知
特にGitHubに関しては、Githubの変更通知が流れてくることにより、レビューも早くなり、実装相談なども頻繁に行われるようになりました。
デプロイ環境
以前は特定のエンジニアだけがリリースできるようなフローになっていました。
弊社ではmasterブランチをリリースするフローをとっているのですが、手作業でリリースしていたため、その間に誰かのコミットが混じって意図せずリリースされてしまうという事故が発生したりしていました。
リリースの複雑性などを排除するためcapistranoを導入し、誰でも簡単にリリースできるようになりました。
また、リリース通知をslackに流すことで、誰が何をリリースを行っているのか分かるようになりました。
開発環境
これまで１つの開発サーバーを皆で共有して開発してきましたが、それを個人開発環境で開発するように移行しました。サーバーはIDCFクラウドを利用しています。
自分の開発環境を持つことで周りへの影響を気にすることなく開発を行えるようになりました。
コマンドでサーバーを立ち上げたり環境を作れるようになったので、開発者の追加も容易にできるようになりました。
情報共有ツール（wiki）
Qiita::team を試験的に導入してみました。
が、これについてはまだワークするというところまで至ってません。徐々に書き始めているといったところです。
既に社内wikiがあったり、confluenceが良いかもという意見があったりで、今後どうしていか話し合っている段階です。
いずれにせよ、ツールは決めて、どんどん書いていくようにしたいと考えています。
タスク管理
カスタマーサポートからの改善要望はRedmineへ上がってきています。
ただ、メインの開発タスクやロードマップについてはスプレッドシートで管理するようになってきています。
タスク管理をどのように行っていくのかも今後の課題です。
まとめ
以上、後半は駆け足となりましたが開発環境や開発体制の紹介でした。
開発環境・体制についてはラクスルでもまだ試行錯誤してしている段階です。今後も変わっていくと思いますので、またの機会に紹介したいと思います。
Featured posts
in #Culture
