最高のワークフローを作成する方法

組織が成長するにつれ、社員が小規模チーム内でどのように共同作業するかに基づき、独自の文化が展開され始めます。大規模環境で人々が共同作業することを可能にする反復可能なプロセスであるワークフローに、チームの機能性は大きく依存しています。

私は常に、ワークフロー管理のために JIRA を使用している組織の多種多様さに驚嘆しています。JIRA のカスタマイズ可能なワークフローは、大小様々なあらゆる種類の組織文化に対応できます。私はアトラシアンに入社して以来、アトラシアンに関する数本の記事を書いてきましたが、JIRA を最大限に活用するために最も重要なコンセプトはワークフローであると断言できます。組織内で JIRA がどのように機能するかの要はワークフローにあります。店内で完璧な商品を見つけ出すのと同様、時間をかけてワークフローのカスタマイズを行えば、その後、大きな見返りを得ることになるでしょう。

まず、ワークフローの構造に目を向けてみましょう。ワークフローには、 ステータス、トランジション、担当者、解決状況のユニークな 4 要素があります。例として、図書館には人々に貸し出す資料を抱合する周知のワークフローがあります。各アイテムを一課題として JIRA に格納し、次の単純なワークフローで管理することができます:

ステータス (Status) – どこに

ステータスは、ワークフロー内での課題の位置を示すものです。図書館の例で考えると、一冊の本は次の3カ所のいずれかにあると言えます: 図書館内 (AT LIBRARY)、利用者の手元 (WITH CUSTOMER)、図書目録から削除 (RETIRED)。あらゆるステータスは、ワークフロー内で固有なものです。

トランジション (Transition) – どのように

トランジションは、ステータス間の橋渡しです。ある特定の課題がステータス間を移動する手段です。図書館の例では、図書は司書により貸し出され、利用者により返却され、図書館職員により貸し出し記録と一致しているか否か審査されます。ここで留意すべきは、利用者は、ある本が図書目録に一致するか否かを査定できない点です。これは、図書館職員によって決定されなければなりません。JIRA は、適切な人物に対してのみ、課題のトランジションを許可するワークフロー権限を設定できます。

担当者 (Assignee) – 誰が

ワークフローは、人々に共同作業方法を導くものです。JIRA では、任意の課題に対して担当者が責任のある関係者を決定します。図書館の例では、本が貸し出される度に借り手を担当者に設定し、どの利用者がその本を所持しているかが図書館が把握できるようにします。図書目録に本が復帰後、その本を図書目録にトランジションする際、その担当者が削除されます。

解決状況 (Resolution) – なぜ

解決状況は、ある課題のステータスがオープンからクローズへ移行する理由を説明するものです。ある本を図書目録から削除する行為では、その本に解決状況を設定できます。破損、期限切れ、紛失等の解決状況を使えるでしょう。JIRA の新しい管理者が犯しやすい 2 つのミスを以下に挙げます:

• 解決状況をステータスと混同 – ステータスは、アイテムがワークフローのどの位置にあるかを説明するものであり、解決状況はあるアイテムがワークフロー内を移動していない理由を説明するものです。これらの機能を効果的に使用して、ある本の貸し出しを停止するには、図書館司書は、貸し出し停止というステータスと、紛失、破損、期限切れ等の解決状況のオプションを作成するでしょう。解決状況オプションを使用して、なぜ破棄されたのかを検索する性能と共に、すべての破棄済み (または、解決済み) 項目の検索は、はるかに優れた報告基準を提供します。これが、組織により課題が非アクティブにされたか否かを判断するために、JIRA が解決状況を利用する理由です。これを正しく理解できているか否かを確認する最善の方法は、created versus resolved gadget (作成済みvs.解決済みガジェット)を使用することです。ある課題への解決状況のタグ付け時と、正式なクローズ時の間にワークフローを設定できます。多くの組織は解決済みの課題を検証し、正当な理由で課題が解決された事を確認しています。

• 解決状況を適切に設定 – ある課題のステータスがオープンからクローズへ移行した時、解決状況を設定する必要があります。同様に、ある課題が再オープンされた時、解決状況を削除する必要があります。図書館の例では、図書館司書がワークフローで本を貸し出し対象に戻すことにした場合、その本から解決状況を削除する必要があります。例えば、貸し出し可能な本の解決状況が紛失であるべきではありません。

ワークフローを構築する準備ができた…さて、どうする?

私には、多種多様な組織のためにワークフローを構築してきた 10 年間の経歴があります。私が経験から学んだアドバイスをいくつか紹介したいと思います。

利害関係者全員を集める

ワークフローとは、文化を拡大することであり、文化とは人々のことです。ある一群の人々の周りにプロセスを構築する時期が来たら、必ず、そのワークフローに関係するすべての人を特定しましょう。例えば、製品管理、ソフトウェア開発、サポート部門の間でワークフローの構築を検討する場合、必ず各部門の代表者一人が会議に参加するようにします。ワークフローを設計している立場で、何が最も重要なのかについて各関係者と話し合いを持つことに時間を割いてください。会議を始める前に、ホワイトボードにワークフローの下絵を描き、会議で各項目を検証し、関係者からフィードバックを集めてください。ワークフローは、人々の働き方を左右するものなので、非常に厄介です。忍耐強く対応すれば、後日、その努力は報われることになります。

フィードバックを得やすいようにホワイトボードにはおおまかにワークフローを描き、この段階で変更を加えます。

 

ワークフローをシンプルに保つ

多くの場合、利害関係者はワークフローの各部分にステータスを配置することを望みます。一般的に、これは良い事なのですが、各ステータスはワークフローにより多くのトランジションと複雑さを追加することを忘れないでください。ワークフローは、物事をシンプルかつスケーラブルにするために設計されるものです。ワークフローに新しいステータスを追加する時は必ず、ワークフローを大きくする以外に他の手段がないことを利害関係者に確認してください。では、例を 2 つ見てみましょう。

• 多くの組織では、コードレビューはソフトウエア開発プロセスにおける重要な部分です。開発マネージャーのジェーンは、コードレビューという特定のステータスを追加し、アクティブな開発下にある課題とレビュー待ちの課題を開発チームが明確に把握することを望んでいます。コードのレビューは、コードを書く事とは明らかに異なる作業です。レビュープロセスが、開発が終了し、他の誰かに責任の所在が移ったことを示す、新しいステータスを追加することは理にかなっています。
• テストマネージャーのビルは、彼のチームによるレビューを通過していないすべての課題に「拒否」という新しいステータスを追加することを望んでいます。私ならこれに反対するでしょう。テストエンジニアはレビューを通過できなかった課題を単に再オープンすることができるからです。

JIRA 管理者として、自身とユーザーに対してワークフローをシンプルに保つ義務があります。

全てのトランジションに気を使う

ステータス間での課題のトランジション時に管理者が利用できる多くのオプションが JIRA にはあります。

• 条件 (Condition) – 条件は、トランジションを実行できる人物を管理します。例えば、図書館では、本を図書目録から除外できるのは特定の人物だけです。
• 検証 (Validation) – 検証は、トランジションが発生する任意の課題状態を確認します。例えば、利用者によって破損されたとされる本が除外された場合、その信ぴょう性を確認するために、少なくとも一回はその本が貸し出されたことを確認したいと考えるでしょう。
• 事後操作 (Post function) – 事後操作は、条件と検証の両方をパスした後、課題に対してアクションを実行します。最も一般的な事後操作は、課題の再オープン時に、解決状況を削除することです。図書館の例では、事後報告を使用して、本が貸し出しサービスに戻った時に、その本が除外された理由を削除できます。JIRA は課題の詳細履歴を保存し、課題が破棄された時と理由を確認することができます。
• 担当者 (Assignee) – トランジションが発生するたびに、課題の新しい所有者を必ず確認してください。すべてのトランジションにおいて、課題を正しい位置に導くデフォルトアクションを必ず設定してください。ユーザーはそのデフォルトアクションを無効にすることもできます。
• プロパティ (Property) – JIRA は、トランジションにおいてプロパティをいくつか認識します。最も一般的なプロパティは、任意トランジションにおいてユーザーに表示する解決状況を制限するものです。例えば、破棄時にかすり傷という解決状況をディスクメディアに対しては表示を望むものの、本には表示を望まないかもしれません。

JIRA でワークフローを構築する

JIRA でワークフローを構築する準備が整ったら、私は時間を取ってワークフローダイアグラムをプレゼンテーションに使えるレベルのものにします。最終フィードバックのために利害関係者すべてにそのダイアグラムを見せたいと考えるはずです。また、JIRA で、ワークフローにおける現在の課題の位置を簡単に表示するオプションを有効にすべきです。全ユーザーは、view workflow (ワークフローを表示する) をクリックするだけです。

ワークフローで JIRA の使用範囲を拡大

JIRA は課題管理プラットフォームとしてソフトウェア開発者の間で良く知られているので、ソフトウェア開発チームで使用が始まることが多くあります。また、JIRA は、在庫管理、変更管理、ヘルプデスク運営、その他多くのことにも使用されます。このように多種多様な方法での使用が可能なのはなぜでしょうか? その目的が、効率の良いワークフローを構築し、人々で構成されるチームの生産性を上げることだからです。組織内でより多くの人々が JIRA を使用すれば、異なるチーム間で作業を共有することがさらに簡単になります。例えば、ソフトウェア開発者がドメイン名を購入する必要がある場合、その課題を簡単に IT へ渡すことができ、随意、同システム内ですべてを購入することができます。「複数システムでのチケット地獄」の中で我慢する必要はありません。

追加資料

ワークフロー作成に役に立つ追加資料をいくつか挙げます:

• JIRA ワークフローのドキュメント
• JIRA ワークフローの共有 – お使いの JIRA にインストール可能な多くのワークフローがアトラシアンのマーケットプレイスで入手できます。
• JIRA Misc Workflow Extensions – 追加の条件、検証、事後操作を追加する JIRA オンデマンドおよび JIRA ダウンロード用のマーケットプレイスのアドオンです。
• JIRA Workflow Toolbox – 追加の条件、検証、事後操作を追加する JIRA ダウンロード用のマーケットプレイスのアドオンです。

最後に

JIRA でのワークフロー開発で私が最も満足感を得るのは、より効率的な人々の共同作業を支援している点です。常にカスタマーの意見に耳を傾け、共感し、非効率的であるかもしれないカスタマーの行動と、その理由、および、新しい作業方法が拡大に役立ちうることをカスタマーに理解してもらえるように努力しましょう。共同作業がうまく進めば、人々はより楽しめ、より多くを成し遂げることができます。そのような環境を好まない人がいるでしょうか?

ワークフローは、JIRA を活用するための根本であることを最初に述べました。次回の記事では、ワークフローに基づいて JIRA 内のデータを可視化する方法を検証していきます。

ワークフローを設定するステップを学びましょう。また、ワークフローに関する下記のプレゼンテーションをご覧になり、ぜひチームで共有してください！

アトラシアンにおけるアジャイル開発のたくさんのヒントもご覧ください。

*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2013 年 10 月 16 日 "Building Workflow Awesome"