Asana から JIRA Software へ : ある顧客におけるアジャイル開発への道のり

サンフランシスコに拠点を置く Switch Communications の目標は、クラウドベースのビジネスコミュニケーションシステムを世界で最も成長が早く、最も革新的な企業に提供することです。

switchcustomervalid-blog-600x-img4

Switch 社は最近、使用しているプロジェクト管理ソフトウェアが同社のソフトウェア開発プロセスを完全にサポートしていないことに気がつきました。一番明らかな欠点はバグレポーティングでした。そのため同社では、信頼性できる 1 つの情報源を情報管理用に必要としていました。「バグ報告の仕方を知っている人はいませんでした。また、当社には優れた追跡プロセスが必要でした」と Switch 社のプロダクトマネージャー Hugo Romano は話しました。

新ソリューションの導入を課せられた Hugo は開発チームの調査を行い、満場一致で JIRA Software が推奨されました。Hugo は JIRA Software がバグ追跡ツールとして使用できることを知っていましたが、結果的にもっと多くのことに使われることになりました。

Swithc が JIRA Software のどのような機能を使っているのか、また「軽量型アジャイル」を実施する上でその機能がどのように役立っているのかを紹介します。さらに、同社のアジャイル遍歴の新たなステップについて紹介します。

他のツールで上手くいかなかった理由

以前は、Switch 社では追跡や仕事計画に Asana を使用していましたが、Asana に他のツール類 (たとえば Gmail、Google ドキュメント、Smart Sheet など) を合わせて使う必要があると感じていました。結果的に、可視性や秩序に大きな問題がありました。

参考として、同社のソフトウェア開発プロセスがどのように行われていたのかを紹介します。製品開発では、四半期の始めのデータ、ユーザー調査、業界トレンド、フィードバックループから得られた知見を大きなプロジェクトに分類しました。これらのプロジェクトは Asana に入力されるのですが、開発チームは Smart Sheet や Google Sheet (チーム毎に異なる) で開発タスクのリストに分割して、集中的に管理していました。「Asana に全タスクを簡単に表面化する方法がなかったから」と言います。

たとえば、Asana のあるプロジェクトは「Switch – Next」と名付けられ、仕様作成設計中作業可能 などの開発段階でセクションが分けられてプロジェクトに収められています。典型的なウォーターフォール開発ワークフローです。

そして重大な問題 (バグ) があった場合は Asana 内で追跡され、進行中のリリースプロジェクト (たとえば「Switch – Release」) にまとめられることが普通になっています。重大な問題、プロジェクト、タスクのリストをまとめると、ときには 250 項目以上のリストになってしまいます。「構造化されていない巨大な 1 つのリストになってしまった」と Hugo も話しています。

バグ追跡をアジャイル開発に変えた方法

Switch 社が JIRA Software に変えたとき、Hugo は「プロセスとバズワードに関して言うと、チームはアジャイルという言葉が好きではなかった」と話しました。ただ重要なことに集中したかっただけと言います。チームが望むワークフローのソフトウェア開発プロセスを作りたかったのです。しかし JIRA Software を使うようになると、Hugo は現在のチームの仕事を表現するために「軽量型アジャイル」という言葉を作りました。

同社の計画はシンプルです。各チームは四半期毎に計画セッションを行い、製品ロードマップマイルストーンを計画します。Hugo がいつも OKR (目的および主要な結果) と呼ぶこれらのマイルストーンは、その後いくつかのストーリーに分割され、JIRA Software プロジェクトバックログに登録されます。各 OKR にはタイムフレームがあります。これはガントチャートビューを介して Smart Sheet に記録され、スプリント計画ミーティングとして週に 1 度チェックインされます。そのミーティングでは、プロダクトマネージャー (PM) が OKR のタイムフレームを調整して、次のスプリントを計画します。

switchcustomervalid-blog-600x-img1

四半期毎に行う計画セッションとスプリント計画ミーティングは、どちらも優れたアジャイルプラクティスです。これらは開発方法にフィードバックを与え、チームが開発について感じていることにもフィードバックを与えるものです。アジャイル開発の重要な信条は、製品のための継続的改善です。これは、チームが協力して仕事をした結果として現れるものです。

アジャイル開発を促進する JIRA Software の機能

同社の仕事と追跡プロセスも同様にシンプルです。PM として Hugo は毎日一つ一つのタスク詳細の記述に多くの時間を費やし、タスクのコメントセクションで議論を行い、チームのボードが最新になるようにタスクのステータスを変更しています。この作業は、ソフトウェアチームメンバーとしてはごく普通に見えるかもしれませんが、JIRA Software の機能を使わなければ何一つ実現できないことでしょう。

ワークフローステータスを使うことで、Switch 社の開発チーム全体は初めてボード上で自分たちの仕事を見ることができます。このボードを使って、分かりやすくて柔軟なビューを作ることができます。Asana では簡単にこのようなものを見ることができませんでした。

通知も重要な機能の一つです。これは主に、チームメンバーにタスクの変更がいつ行われたのかを知らせるために使用します。メンバーは現在、タスクがキューに追加されたときに通知を受けています。そのため Hugo は、デザインチームや品質保証 (QA) チームと新タスクについて議論する週次ミーティングを削減できるとして、通知を支持しています。また、ある課題に対して提供されたあらゆる情報のおかげで、チームメンバーはさらに情報を求めて Google ドキュメントのような他のツール類を切り替える必要性がほとんどありません。

同チームは JIRA Software のリリースハブも使用して、リリースノートを作成したり機能追加やバグ修正がいつ行われたのかを確認したりしています。リリースハブから生成されたリリースノートのコピーを PM が手に入れると、リリースノートはいくつかの分析とともにチームに送信されます。それがレトロスペクティブです。

switchcustomervalid-blog-600x-switchreleasehub

これらの各機能が解決する欠点が限られているとしても、全体としては、Switch 社の仕事の可視化や優先順位、コミュニケーションを支援し、ソースが不必要なまで複雑にならないよう見直すことができます。このこと自体がアジャイル開発なのです。

軽量型アジャイルの次のステップ

Hugo は「軽量型」を付けずにアジャイルという言葉を使うことを嫌がりますが、Switch 社は主要なアジャイル原理を実践していて、見積もりやチーム形成を中心に明確な次のステップを検討しています。

Hugo が次に取り組みたいことは、「チームと管理者にうまくタイムフレームを提供する」ための評価です。これによりチームがベロシティを成功の尺度として使い仕事をするようになります。

同様に、四半期の始めに大きな仕事を決め、その四半期で特定の OKR を遂行する約束をするのではなく、タイムラインを決定するための評価を行うべきでありその反対のことはするべきではありません。この評価は、チームのベロシティについて良いアイデアを出した後、四半期の計画セッションで実施することができます。

評価と計画は 100% 合理化されているわけではないので、Hugo の責任は開発マネージャーとプロジェクトマネージャーの領域にまで及んでいます。彼のチームは、開発マネージャーとチームリーダーから恩恵を受けることになりますし、チームが予測可能なベロシティを出せるように、できる限り手戻りを少なくすることを目標としています。これは、チームがスプリントの継続的改善を繰り返すほど、評価の適用に役立ちます。

最後に、アジャイルの境地に達するために、デザインチームと QA チームは Switch 社のソフトウェア開発プロセスの一部になるべきです。現在では、デザイナーの仕事が完了すると開発に渡され、その後 QA に渡されます。デザインチームと QA チームを開発工程に参加させることで、機能、バグ、プロジェクトは一般に、より短期間で対処することが可能になります。これは間違いなくアジャイル開発という長期的なゲームの一部ですが、毎日考慮すべきことです。QA はどのようにして開発者ともっと密接に仕事ができるのか? 開発者はどのようにしてデザイナーともっと密接に仕事ができるのか? これは試行錯誤を通してのみ発見できることです。

switchcustomervalid-blog-600x-releasetrain

Switch Communications だけの話ではありません

一晩でアジャイルになれるわけではありません。重要な教訓は、部門を超えて生産的かつインタラクティブに仕事をすることでチームがアジャイルになるということです。Switch 社は、何を改善したいか、なぜ改善したいかを理解し、役に立ちそうなツールを探し、アジャイル開発を自社のプロセスに少しずつ導入する方法を探していた企業の素晴らしい一例です。

JIRA Software 対 Asana の詳細はこちら


*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2016 年 2 月 12 日 “From Asana to JIRA Software: one customer’s journey towards agile development