Indeed では非常に大規模で、興味深く、取り組み甲斐のある問題に取り組んでいます。できるだけ早くアイデアを実装の形まで持っていき、逐次増えていく変更や、コードを頻繁に本番環境に送ります。こうして小さなリリースを行うことでリスクを減らし、品質を向上しています。
しかし、どんなソリューションに取り組む前にも、私たちは自問します。「どうやって、成功したかどうかを計測するのか？」と。この問いが、私たちのソリューションにとって重要な「計測できる結果」になるように、焦点を絞ってくれます。
私たちのソフトウェア開発へのアプローチは、「計測-学び-進化」と呼べるかもしれません。私たちは、さまざまなソフトウェア開発の手法からテクニックを取り入れますが、何か特定の手法にこだわりません。協力し合い、実装を繰り返し、計測するのです。時には成功もしますし、また失敗もします。しかし、常に何かを学んでいます。
私たちは、どう実装や改善するかというプロセス自体を、成功とは見ていません。プロセスというのは、目的を達成する為の手段の一つでしかありません。終了に対する一つの方法です。プロセスは、成功するプロダクトを生み出すわけではありません。（人間が生み出すのです。）プロセスは、才能や情熱を与えてくれるわけでもありません。（人間が作るのです。）けれど、正しいプロセスやツールは、上記のような作業を助け、以下の状況において、予測できる仕組を提供してくれます。
- やるべきことを計画し、それに関連した事柄の優先順位を設定
- 実際に実行する事柄と、実行するかもしれない事柄の情報共有
- 達成した事柄の記録
- リスクの管理
私たちは、 Atlassian 社の JIRA を使って、上記のような仕組を実装しています。アイデアを提案し、要件を定義し、プロジェクトを企画するのです。依存性を記録し、工程管理をし、リリースを管理します。テストを説明し、結果を記録します。 JIRA を必要に応じてカスタマイズすることで、成功の指標との協力をとエンジニアリング･ベロシティ（開発の速度）を保つことができるのです。
昔からこういうやり方をしていたわけではありません。初めはシンプルでした。スタートアップ企業だったので、素早く完成させる、という点に注力しました。
会社として成長しても、こうした素早い開発と高い品質とを手放してしまうような事をしたくありませんでした。しかし、当時の私たちのその場その場のやり方では、同じ事を繰り返したり、結果を予想したりすることは不可能でした。一貫性のなさが多く見受けられ、将来のための記録なども残していませんでした。そうして、私たちは開発プロセスの形作りを JIRA を通じて始めたのです。
JIRA のカスタマイズ
Indeed では、オリジナルの JIRA のプロジェクトの種類、ワークフロー、フィールド、ロールなどを使用しています。このようにカスタマイズすることで、計画、情報共有、そしてソフトウェア開発を、望むやり方で行うことが出来ます。
カスタムしたプロジェクトの種類の紐付け
プロダクト開発において、 2 つの種類の JIRA プロジェクトを使用します。一つは「計画プロジェクト」と言う、プロダクト自体に対応するものです。もう一つは「エンジンリアリング・プロジェクト」という、デプロイ可能なアプリケーションやサービスなどに対応するものです。
計画プロジェクトには、イニシアティブ（構想）と実験と言う種類があります。イニシアティブという課題の種類を使用して、ゴール、計画、そしてプロダクト変更における成功指標を設定します。プロダクトのイニシアティブを四半期ごとに計画し、各期の間、その実装を繰り返すのです。その反復の中で、実験という種類の課題を使用して、プロダクトを最適化するために、テストしたい具体的なアイデアを説明します。
エンジニアリング・プロジェクトは、イニシアティブと実験に必要な実装を詳細に練り上げる課題（issue）を含みます。それぞれのデプロイ可能なアプリケーションやサービスに対応するエンジニアリング・プロジェクトが存在します。課題のリンクは、関連する課題同士を結んでいます。JIRA は複数のタイプの双方向のリンクを提供します。上に述べたこれらの使用例を、以下の表にまとめました。
| 組み入れ／組み入れ先 | プロダクトのイニシアティブが、エンジニアリング・プロジェクトの課題（issue）を組み入れている。 |
| 依存／依存元 | 課題が、その他の課題に依存している。これは、機能の開発の依存性を形作るほか、例として順序の依存性などをデプロイすることが可能。 |
| 参照／参照元 | 機能の回帰のための課題が、バグを発生させた課題を参照する。 |
課題の種類とワークフロー
Indeed では JIRA の標準的な課題の種類（バグ、改善、新機能）を使用しています。これらの標準的な課題の種類のワークフローは、典型的な JIRA ワークフローをほんの少し改変したものです。
- 課題を作成し、プロジェクトのリードに割り振ります。課題は、「トリアージ待ち」というステータスに移行します。
- 短期間でのリリースに作業のターゲットを絞り、課題の優先順位を選定します。そしてバージョンを設定し、開発者を割り振るのです。そのうえで、「受諾待ち」というステータスに課題を移行します。他の課題をバックログに移動します。
- 開発者は、課題を承認し、作業開始する計画を立てたら 「受諾」 に移動します。
- コードが完了したら、開発者は課題を解決し、 「レビュー待ち」 に移動します。
- コードのレビュー後、課題を 「マージ待ち」 に移動します。
- リリース候補の作成の準備ができたら、変更をリリース・ブランチの中にマージし、 QA 環境にデプロイします。この時、課題を 「検証待ち」 に移動します。
- QA アナリストはこの成果物を検証し、課題を差し戻すか、検証を完了させ、 「終了の確認待ち」に移動させます。
- ターゲットとなったリリースの中で、全ての課題を実証した後、本番環境に開発物をリリースし、全課題を 「終了」 にします。
また、私たちは自社のプロセスをモデル化するために、カスタマイズした課題の種類を使用しています。前回の投稿では、 ProTest という課題のタイプ （略称。正式にはProctor Test。）について説明しましたが、このカスタマイズされた課題の種類を使用することで、新しい Proctor の A/B テストをリクエストしたり、テストの割り当てを変更することができます。
Indeed には、もう一つカスタマイズされた課題タイプと、ローカライゼーション（ローカリゼーション）に関連したワークフローが存在します。グローバルに成長を続けるにあたり、私たちは、成長スピードを妨げることのないローカライゼーションを必要としています。多くの翻訳者との連携は、難しいこともあるので、翻訳プロセスを JIRA 内でモデル化しました。Indeed の Explosion (爆発) の課題タイプでは、各翻訳対象言語のための課題を取り入れます。以下がそのワークフローになります。
- 翻訳を必要とする英語のストリングに課題を作成する。
- 課題のトリアージを行い、レビューに回す。
- ストリングが翻訳できる状態になったら、自動化されたステップが、一件の翻訳の課題を翻訳対象言語ごとに作成し、「爆発」の課題に全てをリンクさせる。（補足：爆発という呼び名は １つの課題から 28 言語分の課題を一気に自動生成することから、シャレでそうネーミングされています。）
- それぞれの「爆発済み」の課題は、それぞれのワークフロー（１．受諾、２．解決、３．検証、４．終了）に沿って進む。
- 全ての翻訳の課題が閉じたところで、実証し、 Explosion の課題を閉じる。
爆発と翻訳のカスタマイズされた課題タイプやワークフローは、かかわる人数が多いプロセスの効率化を助けてくれます。言語と機能をトリアージするので、翻訳の課題が全機能のリリースを妨害することはありません。また、JIRA を使用することで、機械翻訳と外部の翻訳サービスの統合が可能になります。
チームのトリアージ
開発チームの多くは、 JIRA 内のダッシュボードとアジャイル・ボードを使用して、プロダクトに関連した課題に簡単にアクセスできます。定期的なトリアージ・ミーティングでは、プロダクト開発チームはこれらのツールを使用して、開発作業に優先順位をつけ、課題を分配しています。
メモリーのループを無くしていくこと
Git の中の各コードのコミットは、 JIRA 内で対応した課題として追跡可能です。さらに、参照した JIRA が、イニシアチブ（構想）に紐づく場合、その道すじは、イニシアチブにたどり着くのです。これは、エンジニアがいかなるコードのコミットもレビュー可能で、 JIRA 内の道筋を追うことで、全ての関係した実装の詳細、要件定義、そしてビジネスとしての同期を理解することが可能である、ということを意味しています。
本番のデプロイ
コードを本番環境にデプロイするのは、明確なコミュニケーションと連携を要しますが、Indeed のデプロイ用の課題は、このプロセスを追跡しやすくしました。デプロイを追跡するために JIRA を使用することは、結果として、スムーズな切り替えと透明性を全関係者にもたらしたのです。
デプロイのチケットは、各バージョンに関連付けられており、ビルドからリリースのプロセスまで成果物を移動するのに、連絡をしやすくさせる、ユニークなワークフローをもっています。課題のリンクも使用することで、成功したデプロイに必要な全てのシスアドのタスクも文書化することができます。デプロイチケットはリリースの中の、同じ修正バージョンもあります。
ほとんどのチームは週ごとに作業の計画をしますが、作業が完了次第、本番環境に移します。
よくあるサイクルとしては、週2回、毎日、あるいはそれ以上、などがありますが、リリースマネージャーはオープン中のマージリクエストからリリースの候補を作成します。Git (ブランチ管理)、JIRA （コード変更とデプロイ）、Crucible （コード・レビュー）、そして Jenkins （ビルド）、これらのツール間で連携する社内用のウェブアプリを開発しました。デプロイチケットにステータス変更をすることは、課題の割り振りを発生させ、スムーズな引き継ぎを促します。
このアプローチは、チームに精査すべき情報を提供し、本番環境へのリリースのリスク管理を可能にします。QA アナリストは、変更が引き起こしかねない潜在的な不具合について、さらに理解を深めることができます。リリースマネジャーは、何が変更されるかという全体論的な視点を持ち、問題が起きても素早く対処できるようになります。小規模なリリースはバグの調査をもっと単純にしてくれます。
開かれた環境で働くこと
Indeed において JIRA は、ソフトウェア開発とデプロイのプロセスを、効果的で、効率の良い連携を可能にしました。要件定義を明らかし、実装の選択肢を話し合い、変更を実証し、本番にデプロイするために、これを使用しています。
チーム間、そして組織の上下をこえて、Indeed の JIRA の使い方は、作業を終えるために、透明性をもたらしてくれるのです。開かれた環境で働くことで、計画に対し共有された理解を持ち、前進し、何百という進行中のプロジェクトやイニシアチブに取り組むことができるのです。
自分にとって腑に落ちることをしよう
方法論やプロセスは、計画や、コミュニケーション、デリバリーのために反復と予測を可能にする仕組みを提供できる場合のみ、役立つものです。JIRA はこれらの仕組みを形作るのを助けてくれました。
「既製品」の中から、方法論を組み立て、実装しないようにしてみましょう。そして、問題解決にあたり、ツールに依存するのはやめましょう。その代わりに、どうやって自分のチームが計画し、コミュニケーションを図り、デリバリーをしなければならないかを考えましょう。そのうえで、自分のニーズを満たす最善のプロセスとツールを定義し、必要なだけ、プロセスを反復してみてください。そうして、本当に一番大事なこと―成果を出すことに集中するのです。
原案： 弊社エンジニア Jack Humphrey によるプレゼンテーションより翻案。
発表場所：Keep Austin Agile 2014にて発表。