なぜCIサーバを制圧したのか？：Agile Japan 2015解説編

前回のブログで予告させていただきました通り、2015年4月16日（木）のAgile Japan 2015にて、同僚の直井和久さんと共に、昨年私たちが実施したCIサーバ絡みの改善施策とその成果について報告させていただきました。（今回は後述する理由から、同僚ですが「さん付け」で通させていただきます。）

今回、発表時間が25分と短く、時間内に伝えきれない内容・情報がどうしても多かったため、別途完全版資料を作成・公開させていただいています。

日本語版

CIサーバを制圧せよ！ - プロジェクトメトリクスと自動化技術の活用よる混乱の収拾と「最強」の組織の育成 from Rakuten, Inc

English Version

Conquer CI Server! - Re-establishment of Order and Nurture of the Solid Organization by Project Metrics and Automation Techniques from Rakuten, Inc

今回のエントリーでは、発表内容の解説や裏話を書かせていただきます。また、発表内容に関していただいた質問へも回答させていただきます。

1. なぜ発表したのか？

今回登壇した目的は、大きく３つあります。

組織としての昨年の成果を報告すること
機会を与えていただいた楽天トラベルへ恩返しをすること
共に戦った戦友（とも）との物語を後世に残すこと

以下、順番に簡潔に説明します。

(1) 組織としての昨年の成果を報告すること

私が当時所属していた「TDDグループ」は、支援先部署（今回の場合は楽天トラベル）に直接所属はせずに、『リーン開発の現場』の原著者のHenrik Knibergさんがおっしゃられている「外部アジャイルコーチ」として、間接的・外側からの支援を行う組織を志向していました。また、支援を通じて得た知見を整理・分析し社内外に報告することを、組織のミッションの１つとしていました。
今回の登壇の第一の目的は、この「知見を社内外へ報告する」という組織のミッションを達成することでした。

(2) 機会を与えていただいた楽天トラベルへ恩返しをすること

昨年１年間、「アジャイルコーチ」として、楽天トラベルで働かせていただきました。そこでは、前向きでエネルギッシュな多くの方々と一緒に働かせていただき、非常に有意義な時間を過ごすことができました。また、プロジェクトメトリクスに限らず、様々な知見を得る機会も与えていただきました。さらに今回の発表に当たっては、資料の事前確認や数値類の公開可否について積極的・前向きに検討して下さり、結果として楽天トラベルの後押しを得て発表できる形としていただきました。これまで楽天トラベルからいただいた多くのサポートへの感謝の気持ちを、「楽天トラベルの成果報告」として伝えたかった。これが、私の偽らざる気持ちです。

(3) 共に戦った戦友（とも）との物語を後世に残すこと

今回発表させていただいた一連の施策は、私一人では絶対になし得なかったものでした。圧倒的な技術力で、Jenkinsのマスタースレーブ化とInfrastructure as Codeの構築・一般化を短期間で成し遂げた池田涼太郎君。常に矢面に立って私たちTDDグループをガードし、一連の施策を全面的に後押ししてくださった直井和久さん。一連の施策を通じて劇的な成長を遂げ、今ではオリジナルの「Jenkins Consolidation Team」の代わりに施策を継続・強化してくれている「65%チーム」のメンバーたち。
彼らと共に戦ってきたという事実、彼らと何度も議論した課題への接し方や解決指針、そして彼ら自身が成し遂げた成果。これらを光の当たる形で残していくことが、施策をリードした立場の責務であると考えました。

2. 何を意識して発表したか？

今回は敢えて、「アジャイル」という、多くの人にとっては甘美に響くこの言葉の裏にある冷厳な現実を、「プロジェクトメトリクス」という私たちの活用した武器とそれをもとに達成した成果とで、徹底的に「純化」して「見せる」ことを主眼としました。

私も過去に同イベントに参加した経験があるため、イベントの主旨や雰囲気は理解しています。しかし一方で、アジャイルを数年続けてきた自身の経験から、「ウォーターフォールかアジャイルか」や「組織を生き生きとさせるためのマインドセットの作り方」といった議論を延々と毎年変わらず続けているままでは、「現実」を乗り越えられる人をなかなか生み出せないぞ、という危機意識も持っています。

そうした危機意識から、敢えて「徹底して現実を見せよう、現実と向き合って解決策を生み出していく様を見せよう、そして実際に成果を見せよう」と。私たちの発表は、現状認識・具体的課題と解決策・問題解決のためのマネージャとの接し方といった、「当たり前の仕事の仕方」を徹底して突き詰めてみるものとしました。

正直な話、アジャイルに限らず、仕事を改善していくことには多くの苦難がつきまといます。そして、こうしたイベントに参加して主旨を理解して行動まで移せる人は、せいぜい１割いるかどうかというのが現実です。今回の発表は、この１割の方にフォーカスすることで、一連の「アジャイル」への危機意識の解決を図ってみました。従いまして、どちらかと言うと初心者よりは玄人に響く内容になっているかも知れません。

3. Q&A

発表内容に関しましていくつか質問をいただきましたので、以下それらに回答させていただきます。

(1) 計測する数値は、予め用意しておくのか？それとも作為的に作り出したりするのか？

答えとしては、どちらもやっています。
Slideshare版資料をご覧いただきますと、

取得するメトリクス案を事前に詳細に検討・用意していること
一方で、途中で役に立つ数値を見つけたらそれを採用していること
結局どれを継続・改善してどれを捨てたのか

についての情報をご確認いただけると思います。（これらが、当日の発表では時間が足りずに詳細に言及できなかった点です。）
数値で見せるという前提は崩さず、どの数値で見せるかについては前提を持ちすぎず。そのような態度を意識しています。

(2) なぜ英語版の資料も作成・公開したのか？

自社の外国人社員にも、この知見を共有したいと考えたため。
- そもそも登壇の第一の目的が、「知見を社内外へ報告すること」ですので。
Janet Gregoryさんや数名の外国人の方がイベントに参加されると伺い、彼らにも知見を共有したいと考えたため。
海外に普通にこの知見を広めたいと考えたため。

ちなみに、英語資料をSlideshareで公開すると、海外企業からのリクルートメールが頻繁に届くようになりますw

(3) どうやってプロジェクト予算を勝ち取ったのか？

「よくありがちなのはリリース遅延がビジネスリスクと認識されてないから、なんでやる必要あるの？的なこと言われるんじゃないかと。」というご質問です。
色々説明が複雑なのですが、敢えて一言で言うならば、「意思決定者にビジネスリスクをキチンと説明して理解していただき、継続して関心を持ち続けていただいた」ということになるかと思います。

以下、若干複雑ですが詳細です。

CIサーバ起因のトラブルの存在・影響・解決策を、意思決定者にキチンと説明して合意を得た。
- 楽天トラベルに限らず弊社では、売上を日次管理・追跡しているため、そもそもリリース遅延で予定していた売上が出ない場合、即日問題として発覚する。
- 一方で当時、リリース遅延の根本原因まで分析している人がおらず、意思決定者まで正しい情報がエスカレーション・共有されておらず、対策が後手に回っていた。
- 私が、リリース遅延の頻度の高さと、誰もそれに向き合おうとしていない事実に気付き、独断で根本原因を分析し解決案を取りまとめてレポートを提示した。
  - しかし、私が楽天トラベル所属ではない外部の人間であったことから、レポートが然るべき人に読んでもらえないという壁に突き当たった。
- 私のレポートを読んで下さった直井さんが事態の重大さに気付き、自らの判断で意思決定者と直談判し、施策実施の合意を取り付けて下さった。
  - なので直井さんには頭が上がらないのです。
私たちTDDグループが、無償で業務支援を行うスキームを採用していたため、楽天トラベルにとってはコスト面でのハードルが低かった。
一方で私は、成果を常に見せ続けないといつ潰されるか分からない施策であるとも認識していた。そのため、技術的な課題解決だけではなく、プロジェクトメトリクスによる成果アピールを継続することで、意思決定者に継続的な関心を持ち続けてもらうよう配慮し続けた。