自分のいるチームは特定電話機シリーズ向けのアプリを開発しているので、年に一回ある新しい電話機のリリースが主要なリリースターゲットである。それ以外のタイミングもいれると年に何回かリリースはするが、基本的には電話機のお披露目を中心に一年周期で物事が進む。近隣にある platform の人たちも、同じく年に一回の新バージョンのリリースに向けて一年のサイクルで仕事をしている。

これは daily, weekly あるいはせいぜい monthly か bi-monthly くらいで継続的にリリース/デプロイしていく近代的なソフトウェア開発とはだいぶ違う。昔のソフトウェア開発に近い。外から見ていたときはあいつらダメだなと思っていた。中の人となった今もダメだと思う。しかし自分がどうこうできる問題でもないので適応しないといけない。

サイクルが長いと具体的にどう困るか。今となっては珍しい体験な気もするので、慣れ切らないうちに様子を記録しておく。

締め切りの対価

サイクルが一年だと、ある締め切りを逃すと次は一年後である。自分はある新機能を unblock するために直してほしい platform のバグがあった。けれど二ヶ月くらい風邪で休んだりなんだりしているうちに締め切りをのがしてしまった。なんとか master branch では直してもらったのだけれど、それをリリースブランチに cherry pick してもらえなかった。なんとかしてくれとゴネるも交渉は成り立たず、結果としてその修正に依存していた機能達は軒並み drop された。厳しい。

自分が締め切りのインパクトを内面化していたら、もうちょっと優先度をあげて頑張っただろう。これが毎月リリースだったら翌月出せばよいだけなのだが・・・。もう締め切りというものを体が忘れてしまったよ。

締め切りは一つでなく「とりあえずデモできる程度に動く」「API 確定」「Dogfood できる」「バグなし」など複数のマイルストンにわかれている。レイヤによっても締め切りが違い、たとえばアプリのような事後的に空から撒きやすいやつは platform に比べると少しあとにずれている。なのでアプリのバグだとおもったら platformの バグだった、とわかったときには手遅れになることがありうる。

締め切りの前には駆け込みで変更が殺到し、ツリーが不安定になりバグトラッカーの流動が増し、機能を入れたい人々とツリーを安定させたい人のあいだに緊張が走り、チームの空気が殺伐としてくる。これといった新機能を持っていない、というか早い段階で drop されてしまった自分は、読み物で見聞きした世界だなー・・・などと眺めている。

長いブランチ

リリースブランチの寿命がながい。リリース間隔がながいからといって必ずしもツリーの安定化にかかる時間が長い必要はないが、長い。たぶんリリース間隔がながいと QA のプロセスを短縮する動機が弱まってしまうのだろう。結果として前のリリースブランチが死ぬ前に次のリリースブランチが切られたりして、カオス。

ようやく canary を撒いてみつかった crash report にでてきたクラス、リファクタリングされちゃって master にはないんですけど・・・みたいな事態が起こる。しかも社内のツール群は short living branch を前提としているため long living な branch で作業するのがすごい面倒。辛い。

それでも昔よりはよくなったらしい。昔はどうだったのか知りた・・くはないな別に。

手持ちぶたさ

リリースが近づくと ToT でもあまりでかい変更ができなくなる。ブランチを切ってあるから理論的にはできるわけだけれど、まわりの人たちがリリースにむけたバグ修正モードで仕事をしているところで実験的なコードを書いたりしてると肩身が狭いし、下手にでかいリファクタリングをして cherry pick の邪魔になっても気の毒だから気が乗らない。

まあ手持ちぶたさというのは語弊があり自分もバグ修正大会に参加しているので仕事はある。ただ自分の新機能は drop されている手前コードは動いておらず、バグもでてこない。なので他人の球拾い的なバグ修正が中心になる。バグ修正はきらいじゃないけど、それなりに大きな成果を求められる立場なのに細かい作業ばかりしてる不安はある。

まわりのシニアなエンジニアをみると、難しいバグを直したり遅れている機能を手伝ったりしている。なるほど。実力不足で手伝えなくてごめんね・・・

計画性

一方、来年にむけての計画のもようなものもどこかでは始まっているらしい。そこでちゃんとクビを突っ込んでおかないと、また必要な変更が締め切りに間に合わず先送りということになりかねない。

ただ自分は一年前ここにいなかったため、この序盤の計画フェーズがどう進むのかいまいちよくわからない。一方で目の前には pile of bugs がある。なのでついバグ修正を優先してしまうが、計画に時間と頭を使わなくていいのか不安。しかし何をすればいいのかわからない。落ち着かない。

長い坂道

一歩下がると、一年サイクルの問題点は学習の iteration が長いことである。

まず自分のような新入りがプロセスを見届けるのに一年かかる。自分の仕事が一年かかるだけでなく皆が同じサイクルで動いているため他人を見て学ぶのも難しい。しかし会社の勤務評定は年に二回容赦なくやってくる。ひどい。一周するまで待ってちょ・・・。

新入りだけでなく組織の学習サイクルも長くなってしまう。何かを変更して結果を見届けるのに一年かかる。外から見ていたときはこのひとたち全然よくならないな・・・とおもっていたが、納得。

構造的問題ゆえ自分がどうにかできるものではないけれど、適応の過程で近代的とは程遠いこのサイクルを当たり前と思わないようにしないとなあ。

といったところで適応のために必要なことを書き出してみると:

• 様々な締め切りへの awareness を高める。Platform や電話機のリリースがずっと先でも、プロセスのマイルストンはそのもっと手前にやってくる。締め切り関係のメールを見落とさず、印刷して壁に貼るなりノートの冒頭に書いておくなりして目に入るようにする。
• 各フェーズでやるべきことをやる。
  • リファクタリングが継続的な所作である、という理想は妥協し、でかいリファクタリングは序盤に済ませておく。後半で気づいた smell はどこかに記録して次のリファクタリング期に片付ける。
  • バグ取り期にはバグをとる。人のバグ取りを手伝う。
  • 新機能は早めに end-to-end で動かして下のレイヤのバグを特定する。（これはインクリメンタルな開発でも一緒だけどね。）
  • 計画・・・についてはどうすべきなのかまだわからん。

若干 sigh ではあるけれど、現実として受け入れます。はい。