タグ: Atlassian JIRA

Atlassianのバグトラッカー/機能プランナーJIRAは、今や至るところで使われているし、ぼくも長年、ソフトウェアビジネスの重要な目的に奉仕する製品、と考えていた。重要な目的とは、プロジェクトチームが共通の敵を見つけて共同で立ち向かうことだ。でも、そうではなかった。JIRAの設計は基本的に、良質なソフトウェア開発とは正反対のもので、単純なバグトラッキングぐらいにしか使えない。では、もっと良いやり方とは、なんだろう。

ライターでないときのぼくはソフトウェアエンジニアで、ソフトウェアコンサルタント企業のHappyFunCorpに籍を置いていろんなクライアントの仕事をしている。だからJIRAのいろんな違った使い方を、見る機会がある。一部の企業はそれをBugzilla++として使っているが、それで十分だ。でも最近ますます多いと思われる使い方が、要求の定義だ; プロジェクトを多数のJIRAチケットに分解すれば、それらを使って、評価もコミュニケーションも進捗管理も変更管理も、何でもできる、という考え方だ。

でも、この考え方には深刻な欠点がある。JIRAのチケットは、絶対的で不可避な想定とそれらの結果を表現している。それが記述している機能やビヘイビアは、離散的でない。それは絶対的な二択、すなわち完全か、無か、だ。しかもそれは、個別に評価できる、とされる。つまり個々に、それだけを孤立的に扱える、と想定される。そしてその、他のチケットとの結びつきは、JIRAの子どもっぽい概念、“リンクされた”チケットという言葉で表現される。

これは、ソフトウェアの最良の作り方ではない。ソフトウェアは、反復的(iterative)である。サブシステムAを作る、次にサブシステムBを作る、そしてABをインタフェイスする…という単純な過程ではなく、デベロッパー間には最初にA-AB-Bの全体を見通した情報の流れ〔プログラム中の情報の流れ、フロー〕が共有されていて、それから（あるいはその前に）最初の方のデータでその流れをテストし、その過程を通じて何かを発見し、何かを学ぶ。そして次は、そこで現れた想定外や、システムのどこかにあった地雷原に対策することが多い。ときにはその作業に数週間を費やし、その後本流に戻って、情報の流れを拡大する、…以上の過程を、A、AB、Bの三者が完成するまで反復する。

しかしJIRAでは、進捗はまだ残っているチケットと、クリアしたチケットの数で計られる。そう明示されているわけではないけど、必然的にそうなる。“To Do”（未着手）や“In Progress”（作業中）のチケットが並ぶでっかいカラムは、誰も見たくない。みんな、できるだけ早くそれらをそこから外して“QA”（品質管理中）や“Shelved”（保留中）へ移したい。だからJIRAのチケット方式では、デベロッパーが一度に一つのチケットだけを扱いがちになり、それは多くの場合に非効率であるだけでなく、開発の後段における重大な、その時点ではもはや手遅れの、エラーを招きがちだ。

さらにまずいのは、デベロッパーが考えるソフトウェアのアーキテクチャが、知らず知らずのうちに、JIRAのチケットにマップしやすい構造になることだ…それが技術的最適ではない場合でもだ（そういう場合の方がむしろ多い）。もちろん、完全に最初に戻って、プロジェクトのメンタルモデルの全面的な再構築を求めることはできる。だが、そんな重い社会的および資本的負担を、すでに進行中のプロジェクトに関して誰が引き受けるのか？　ときには非技術系の管理職が片手間で拙速に作ることもある、暗黙にチケットを前提しているアーキテクチャを、黙って受け入れる方が楽である。

しかし最悪なのは、プロジェクトを複数のチケットに分解するこのやり方では、システム全体を展望する場がどこにもないことだ。最良のソフトウェアは、細部の緻密な実装に集中できると同時に、システム全体の大きな目的や狙いをつねに心にとめているデベロッパーから生まれる。JIRAでは後者が、異様なほど、そして不必要に、困難になる。

ここで強調したいのは、悪いのは必ずしもJIRA自身ではない、ということだ。ここまで書いてきたことはすべて、ソフトウェアのアーキテクチャと開発を“チケット”の集合に還元する、という考え方に由来している。JIRAの最大の罪は、それが、もっとも成功し広く普及しているチケットシステムであること、それだけだ。ソフトウェアプロジェクトをチケットの集合で表す、という考え方そのものが、真の敵だ。

そしてぼくが提案するもっと良い方法は、びっくりするほど単純だ。複雑なシステムを定義/表現できて、そこに曖昧性や不確定性、互いに絡みあった関係性、成功のための反復レベル、そして大きさと細部が不特定に幅広いスペクトル、などなどを記述できる強力なシステムが、すでにある。それは、“散文(prose)”と呼ばれる。

何らかの理由で今日の企業の多くが、明快でシンプルな長い散文（2パラグラフ以上）を書くことを、疫病のように恐れて避ける。でも、上手に書けた8ページのドキュメントなら、複雑なシステムのニュアンスを、互いにリンクし合ったJIRAのチケットの扱いにくい小艦隊よりもずっと見事に、定義できる。

しかも今なら、シンプルなテキストドキュメントを、文や箇条書き、パラグラフ、節、章などに分解して、それらの要素の評価や進捗を記録する自動化システムを、容易に作れる。チケットと違って、各要素の大きさは制限されない。散文をJIRAのチケット集合に自動的に変換することも、必要ならできるだろうが、その場合もプロジェクトを主導する仕様は、単一の、一貫性のある散文ドキュメントだ。

機能のプランニングには、コミュニケーションが必要だ。JIRAは、複雑なシステムの要求をコミュニケーションする方法としては基本的に劣悪である。言葉の並びは、それが良く書けていれば、つねにベターである。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））