昨日、Facebookに接続しているうちに、ある会社のiOSチームの求人広告を見つけた。普通の求人広告は、見てみると福祉、技術スタックなどのキーワードを中心に目立つが、この求人広告は技術ブログのように内容がすらすら読まれた。以前チームにいた時に導入したかった多くのものがすでに構築されていた。１人でチームメンバーを説得して少しずつ導入してみたので、これだけのモバイル開発環境を構築するためには、多くの努力と時間と試行錯誤が入ったことが分かった。うなずきながら読んでふと、私が初心者の時にこの投稿を読んだらどうなっただろうかと思った。経験が不足し知ることがあまりないので何が良いのか、これが私にどんな影響を与えるのかよく分からなかったと思う。これまでこんな開発環境がある時とない時の両方を経験してみたから今は分かる。このようなことが集まって、自分が会社で過ごす時間の質を決める。単純で反復的なことが少なく、開発中の集中力を奪うような出来事があってはならない。だから開発に集中できる時間が多く確保されるのが業務時間の質であり、この時間は開発者の成長とつながる。

デプロイの自動化

「コミットごとに全てのコードがテストされ、１日にも数十回、メンバーに開発中のビルドが共有されます」

デプロイの自動化とは、１回クリック（または０回）だけでアプリをビルドし、内部ユーザーや外部ストアまですぐにデプロイできる環境を意味する。デプロイは単純で繰り返し作業ながらも、意外と時間がかかる。以前チームの場合は、半分だけ自動化されていた。アプリをデプロイするには、まずアプリのバージョンやビルドナンバーを上げる必要がある。しかし、これを誰かが手動でコミットをし、PRを作り、ルールに基づくテストもクリアしなければならないし、最後に他の開発者がPRを承認してこそバージョンアップが可能だった。プロセスがこのようになっていると、メンバーにアプリを伝えようとするたびに、なんと２人の開発者の業務に支障が出た。このような方法に問題を感じて着実に改善をしていき、結局はSiriでデプロイができるほど自動化をしてデプロイにかかる労力と時間を大幅に減らした。

開発に没頭するには、邪魔されない連続した時間が本当に重要だ。特に開発者にとって２回の30分は１時間と決して同じではない。１日に数十回もビルドが共有されるということは、デプロイが完全に自動化されているため、開発者は業務中にデプロイに気にすることがないという意味で、メンバーも他のチームメンバーを邪魔する必要なく最も最新のアプリをインストールすることができるという意味だ。CI/CDが構築され、この種の細かい妨害業務が可能な限りない方が良い環境だ。

フィーチャーフラグ

「フィーチャーフラグを導入して、ユーザーに毎週デプロイできる環境を整えました。」

フィーチャーフラグとは、バックエンドが渡すBoolean値でアプリの機能をオフ・オフできる仕組みだ。 フィーチャフラグが無いと、ある機能が開発されている間は、マスターブランチにコードをプッシュできないため、フィーチャブランチを別に管理する必要がある。機能の規模が大きく、開発に時間がかかるほど、徐々にマスターとフィーチャーブランチに大きな差ができ、後でマージする時に大変なことになる。さらにマージの衝突を誤って修正してコードを失い、機能が壊れることも経験してみた。このようなことを経験すると、マスターブランチにコードをマージすることが重大なことになり心配や恐怖まで生じる。一生懸命開発してテストまでうまくいったが、コードをマージする最後の段階で問題が発生する可能性があるというのは、開発者を萎縮させる。

開発人数が少なくて一度に一つの機能しか開発できず、その間にアプリをデプロイすることがなければ、このような環境の必要性を感じることはできない。しかし、フィーチャーフラグが構築されていれば、複数の開発者が同時にそれぞれ異なる機能を開発しながらもマスターブランチ一つだけ維持すれば良いので、ブランチ管理がはるかに簡単で、その中で実際のデプロイも無理なくできる。開発が完了しないコードがあっても、バックエンド値を通じて未完成の機能をユーザーに隠すことができるからだ。これにより、開発者はブランチ管理やマージ衝突などを気にする必要がなく、完全に開発に集中することができる。フィーチャーフラグのもう一つの利点は、リリーズされた機能に問題が発見された場合一時の方便として機能を消すことで、ユーザーに与える影響を減らすことができるという点もある。

コードレビューとペアプログラミング

「コードレビューはiOSチームの中心的な文化です。（中略）ペアプログラミングをしばしば活用します」

イノベーションアカデミーのイ・ミンソク学長は「レビューなしに作られたコードはヤミ金と同じだ」と述べた。本当に共感できる言葉である。業界では「技術的負債」と表現するが、開発者一人が一人で作ったコードは、悪質なヤミ金のように技術的負債を多く発生させるという意味だ。自分が作成したコードを自分と同一視したり、過度な愛着を持って変化から守ろうとするのは本当に良くない。コードはチームメンバー全員との共同名義の資産という考えで扱わなければならない。コードレビューをすると技術が共有され、チームが全体的に成長する。開発してみると、たまには自慢気に「これは本当に完結性があるように作ったものだ。レビューでも別にコメントは出ないだろう」と思っても、他の同僚の観点からは改善点が発見され、新しいアイデアが生じて、知らなかった技術を学ぶことができる。互いのコードを見せず指摘しないと、個人でもチームでも成長できない。

ペアプログラミングは、コードレビューの上位バージョンだ。開発能力が似ている２人がするよりは、非対称的な実力を持つ２人がするのが効果的だ。Googleでは、ペアプログラミングで作成したコードはコードレビューでの承認を受けたとみなすという。ペアプログラミングではないが、私が新入の時、先輩が私を隣の席に座らせてコーディングをしてデバッグをする姿を見せた経験については、以前の投稿でも言及したことがあるが、本当に大きな助けとなって、今までも記憶に残っている。ついこの間は、私が知らせる立場で新入開発者とペアプログラミングをしたことがあるが、反応も良かったし、私も考えを整理して設計をよりしっかりする良いきっかけとなった。シニア開発者とのペアプログラミングは、ジュニア開発者にとって本当に貴重な時間だ。私よりも上手な人から技術とノウハウを１対１で伝授され、質問も思う存分できる機会は、いくらお金を支払っても買えない。

単純で反復的なことが少なく、完全に開発に長く集中できる時間が多い環境が良い。

そのためには、繰り返しの業務を自動化することが不可欠だ。また、コードレビュー文化が定着していれば、個人はもちろんチームが全体的に成長することができる。 上記の基準と事例を通じてどの会社に行くべきか、どのチームに行くべきか、あるいはどのように自分の周辺状況を改善したら更なる成長ができるのかを悩んでいるジュニア開発者の方々にお役に立てれば幸いだ。