AtlassianのパートナであるDevInitでアプリケーションマーケティングマネージャを務めるDzmitry Hryb氏は先頃、"7 reasons Why use of Jira can be frustrating"と題して、Jiraの使用でフラストレーションを覚える7つの理由と，それらに対処する効果的戦略を取り上げた一連の記事を公開した。その中で氏は、組織独自のワークフローを表現するために、Jiraのカスタマイズや他のツールと併用することの重要性について述べている。Hyrb氏の記事は、エンジニアリングジャーナリストのJon Evans氏が先日TechCrunchに寄稿した、"JIRA Is An Antipattern"という記事に答えたものだ。Evans氏の記事では、プロジェクトやイシューを主眼としたモデルを使ってデリバリ上の懸念に対処する場合にありがちな、"マクロな視野(macro-vision)"やアーキテクチャといった極めて重要なニーズの無視について指摘している。AdaptivistのDevOps責任者であるMatt Saunders氏もEvans氏の記事に返答する記事を書いて、Jiraは"組織が特定の人々や必要なプロセスを形成するためにデザインされたツールセット"を提供するものであって、より広範なツールボックスのひとつのピースであるべきだ、という結論を導いている。
Evans氏の記事では、Jiraが"ソフトウェアプロジェクトの中心的なマップ"であり、"悪名高き真実の源泉"となっている多くの組織に存在すると氏が主張する、アンチパターンについて論じている。プロジェクトと機能提供のトラッキングにおけるJiraの卓越性は、プロジェクトやエピックを"チケット"に分解するのに適したモデルを提供する一方で、マクロな視野や戦略共有の喪失という対価を伴っている、と氏は言う。さらに氏は、"チケットを完了とマークしなければならないという、終わりのない暗黙的プレッシャ"が、インフラストラクチャやデザインといった広範な懸念の無視という問題をさらに悪化させている、と付け加える。氏によれば、
... 機能主導のJIRAを使って、個々の機能には対応しない、プロジェクト規模のインフラストラクチャというコンセプトをサポートするのは，簡単なことではないのです。プロジェクト全体で使用されるデータモデル。複数のページにまたがって使用される複雑なコンポーネント。キャッシュ層 ...
Saunderｓ氏は、Jiraのコンサルティング提供を専門とする氏の会社で、２つのタイプの組織がある，ということを経験している。"Jiraを導入して大きな成功を収めた"組織と、"Jiraをそのまま導入することが、すべての開発チームの作業を改善するソリューションである"と思い込んでいる組織である。その上で氏は、プラットフォーム以外でのコラボレーションと，"チケットシステム以外に適切な文書を追加する"ことが重要であるとして、WikiやSlack、ZoomといったJira以外のツールを使ったエコシステムによる強化の重要性について強調する。氏によれば、
Jiraは単独では機能しません — そのようには設計されていないのです。Jiraの構造をそのまま使うだけで、チームが一貫して前進できると期待するのは非現実的です。他のツールやコミュニケーション手段で補完したときに、最もその能力を発揮するように意図されているからです。
Hryb氏はさらに、マクロな視野でコミュニケーションする能力を奪うというEvans氏の批判に対しても、これは"ツールそのものよりも、その使用方法の誤り、あるいは組織文化の問題である、"という指摘で反論する。デリバリの詳細に対して近視眼的に焦点を絞り過ぎている原因は、一部の企業が"チームの効率性測定"に選択している方法にある、と氏は考えて、"KPIや役に立たないレポートはお払い箱"だという選択が、"有害な行為"の原因になっていないか、まずチェックするべきだ、と指摘する。さらに氏は、Jiraを他のツールと併用することの必要性や、AtlassianがJiraの関連プロダクトやマーケットプレースでこれを実現している方法にも触れている。氏は言う。
確かにJiraは、それ自体では十分なプロジェクト管理機能を持っていません。ですが，AtlassianがConfluenceを開発した理由はそこにあるのです。Confluenceを使えば、プロダクトシートの作成や要件の追跡、Jiraイシューとのリンク、さらにはプロジェクトの全体的なビジネス戦略の文書化が可能になります。
Evans氏は、基本となるアメニティのサポートのないままに都市計画のメタファを使用して、インフラストラクチャや包括的戦略を先に勧めることの危険性について、次のように記している。
タワーや住宅地、講演、モールや道などを含む市街図を簡単に設計できるような、都市計画ツールを想像してください .. ただし上水道や下水道、地下鉄のトンネル、配電網といったものはサポートされていないか，可能であったとしても、小細工を駆使しなくてはならないようなものです。
"JIRAはマイクロピースの管理には長けていますが、マクロには別のツールが必要なのです"、とEvans氏は述べて、アーキテクチャ資料やマクロな視野を捉えるための文書の必要性を提案する。さらに、"クリック可能なプロトタイプでは不十分"である、なぜならば、同じように"説明的なコンテキストが必要である"からだ、と説明した上で、次のような提案をする。
プロジェクト全体のビジョンを詳細に説明した10ページ程度の概要、ソフトウェアインフラストラクチャを説明した６ページ程度のアーキテクチャ資料が必要でしょう — 都市計画の上下水道、電力、地下鉄、空港の配置や機能にあたるものです ...
ソリューションアーキテクチャの研究者で、CGIのプラクティスリーダを務めるEltjo R. Poort氏は先日、特定の価値を重視したアーキテクチャ資料の必要性に関する記事を書いた。その中で氏は、"ドキュメントの肥大化"が"アーキテクチャ上のフィードバックループ"を遅らせ、"重大な遅延を引き起こす"可能性について言及している。これが"組織にとって、アーキテクチャ資料の付加価値に対して疑問を持ち始める原因になる"ことが多い、と氏は見る。アーキテクチャ資料のビジネス価値は、"意思決定支援、業務推進、設計品質、リスクおよびコスト管理の観点で"測ることができる、と氏は記している。より効果を上げるために，氏は、適切なツールを使って、以下のようなシナリオそれぞれに対応する、さまざまなアーティファクトを提案する。
- 計画、プロジェクト、エピック、ストーリに関する具体的な懸念に対して、文章や図表を使って"アーキテクチャビュー"を作成し、それを通じてステークホルダの懸念がどのように対処されているかを説明する。
- "アーキテクチャの情報"が利用可能になった時、将来的な方向性や分析、明確化のために、Wikiやドキュメンテーションシステムを活用してそれを保存する。
- 新たな意思決定が行われた時には、それを登録簿(decision register)に記録することで、コラボレーションとフローを支援する。それらはJiraや、Wiki、ドキュメンテーションシステムでトレース可能にしておく。
ターゲットを特定し、価値を重視したアーキテクチャ資料を作成することで、"小規模プロジェクトの立ち上がり期間が(一般的な)２ヶ月から2週間に短縮されたという、アジリティの大幅な向上と組織としてのメリット"が改善として確認できた、とPoort氏は記している。
Hyrb氏は自身の記事で、Jiraのユーザビリティやパフォーマンス、プロセスのアジリティに関する一般的な不満な回答として、ツールとしての目的の違いを根拠として示した上で、自身のワークフローに合わせてJiraをカスタマイズすることの重要性、場合によっては機能的ギャップを埋めるために、マーケットプレイスを利用することの必要性について指摘している。全体としてHyrb氏が訴えるのは、自身のワークフローとコミュニケーション構造をまず正しく把握することの必要性である。
チーム内の作業プロセスとコミュニケーションの確立に代わるツールはありません。すでにJiraを使用しているのであれば、それを学び、よりよい結果を得ることに努めてください。