こんにちはプロセスコンサルタントのYoshiyaです。
現在いくつかのクライアント先にJIRAの導入を支援しています。
導入時に行った方が良い活動・作業がいくつかあります。
一気に新しい運用にすることを焦ることはチームがJIRAを理解することを遅らせます。
新しいツールになることでチームの管理も一時期見えにくくなります。
移行期間は運用を割り切って新しいツールになれることをお勧めします。
JIRAは素晴らしいツールで、特にタスク管理という側面にフォーカスしたとき、エンジニアよりのコンピュータに詳しい人たちの間で評判が良いというものがあります。実際に使ってみても、UIに優れており、サクサクとタスクを管理していけるので快適かつスムーズで模範となるSaaS（クラウド型サービス）です。
一方で、マネジャーの立場になってみると、JIRAは何でもできるからこそ、そしてゼロかパーフェクトかという二項対立的な構造になってしまうというデメリットを持ちます。JIRAは進捗管理、タスク管理、評価の管理、バグ管理と、さまざまな用途に使えますが、進捗管理はゼロか１か、終わらせたかまだかで判断されます。
開発マネジャーの視点から見たときに、プログラミングの構造と一対一でJIRAが組まれているわけではないのです。つまり、プログラミングは再帰的かつ反復的で、オブジェクト指向プログラミングはとくに、部品の再利用という側面が強いですから、その構造と対応した進捗管理ツールではなく、もっと直線的なツールです。
たとえば、A-B-Cというモジュールを順番に開発し、統合テストをするわけではなく、最初にDという全体を動かす仕組みを作って、A-B-C-ABと開発して、さらにもう一度Dをいじる、といった開発方法が多いのです。A-B-Cと順番に、シンプルにプロジェクトが進むのであれば、単純なタスク管理でいいのですが、プロダクトの構造が複雑になると、シンプルな機能では追いつけなくなるのです。
これを克服して行くには、ソフトウェア開発への深い理解が必要です。
JIRAでは、終わったチケットと未消化のチケットの比率で進捗がはかれらますので、ある程度トレーニングして、JIRA上で評価される進捗と、実際の進捗の間にある少しの溝を埋めていく認識が必要です。ちょっと慣れるまで時間がかかります。
複雑な構造を持つソフトウェアと、シンプルな構造を持つタスク管理ツール。
その両者を上手にバランス取って進めていく必要があります。なぜ複雑な現実に呼応する複雑なタスク管理ツールが登場しないかというと、その複雑なタスク管理をさらに進捗管理するツールが必要となり、永遠に管理し続けることになるからです。それは冗談としても、ソフトウェアに呼応したタスク管理をいちいち開発していては、本体と管理でプロダクトのサイズが倍になってしまいます。
JIRAは最も使われているタスク管理ツールで、直線的な進捗管理には大きな力を発揮してくれます。とくにコミュニケーションを取りながら進めていく開発に適しており、マネジャーが全体を見渡すときにもパワフルな力でバックアップしてくれます。仮に自分一人の開発なら、どのようなタスク管理ツールを使っても良いでしょうが、仲間がいるとき、マネジャーとエンジニアと派遣スタッフといった、大きく職種の違う人たちが関わって、より高度なサービスを提供したいと考えるとき、さまざまな職種の人にも使いやすいJIRAは最適です。
上記のような進め方はアジャイル運用でのMVPからアプローチです。
アジャイル開発のMVP（Minimally Viable Product）は、最小実行可能製品、と呼ばれます。いちばん小さく、そして動き、さらに使える製品でなくてはならない、その最小単位からはじめようというものです。
MVPは、さらに３つの要素に分解できます。
Usable（使える）
Testable（試せる）
Lovable（気に入る）
このアジャイルのMVPをよく表現したものに、「スケボーから作れ」というものがあります。
顧客は自分が欲しいものを理解しているとはいいがたく、ただぼんやりと「遠くに行きたい」というインサイト（本音）があるとします。そのぼんやりとしたインサイトを形にするのが仕事ですが、自動車を作るにしても、タイヤを初期リリースしてはいけないのです。
タイヤだけ見て、「おっ、遠くに行けそうだ！」と思ってくれる顧客はおらず、ぽかーんとされてしまうだけだからです。自動車を売りたいときに作るべきは「スケボー」です。タイヤをつけ、タイヤをシャーシでつなぎ、ボディフレームを作り、ようやくタイヤをつくるのではなく、スケボーを作って、スケボーにハンドルをつけ、自転車を作り、さらにバイクを作ってから、スーパーカーを作るべきなのです。
つまり、MVPの３つの単位（Tastable、Movable、Lovable）をどのフェーズでも守りながら、徐々に全体のプロダクトを完成させ、最終ゴールにたどりつく、そうした進め方が求められます。これがアジャイル開発であり、MVPの考え方です。
ザッポスは、このMVPの単位を上手に使いながら、サービスをグロースしていきました。ザッポスといえば、伝説的なコールセンターの仕組みが知られていますが、プロダクトサービスそのものも、アジャイルMVPで作られているのです。
重要な部分、靴を選ぶ楽しみの機能や、返品機能、その部分を、MVPで開発したのです。また、コールセンターも無限に話につきあうということでも知られ、企業カルチャーをよく表しています。
多くの人が、ウォーターフォール型開発に慣れています。上述の例でいうと、タイヤから作り始めてしまうのです。ウォーターフォール型開発は、大規模な、それこそ何千人月といった大型開発には向いています。また、仕様が逆戻りせず、最初から顧客が「仙台から奈良に行きたい」といったインサイトをきちんと自覚して、言葉にできている必要があります。
しかし、インターネット上のプロダクトはもっともっとスピードが求められ、さらに求めているインサイトそのものも、若干ゆれうごきます。よって、小サイクルではじめていくアジャイルが型もっとも適しているのです。
リーダーに仕様書をもらってプログラミングするだけではなく、メンバー側からこうじゃないですか？ これではどうでしょう？と提案していく。お互いにコミュニケーションも必要ですし、一緒に仕組みを回していくという意識が何より必要です。
スケボーの例にありますとおり、アジャイルは小さく、そしてとても大切な部分からはじめます。カイゼンを繰り返しながら、自分たちの形を追い求めていくのです。初期プロダクトは大切です。タイヤができあがらないように、スケボーができあがるように、小さくて使えるそして愛されるプロダクトを作り上げる必要があるのです。
ファーストステップのスケボーができれば、あとはどんどん小さく改良を進めていくだけです。
アジャイル開発は20年前に登場した仕組みで、昔から熱狂的に支持されてはいますが、それでも多くの人がアジャイル開発を難しいと感じるようです。それはこの協力体制を得るハードルが高いからといえます。しかし、成功する組織もあります。何が違うのでしょうか。
それは、組織が良い意味で小さく、身軽で風通しがいいとき、アジャイルが適切だといえます。ただ小さく開発するだけではなく、きちんと製品として成立していること。それを念頭におけば、アジャイルはきっと大きなパワーを生み出してくれます。
逆にいえば、組織が身軽で風通しがよいことが前提ともいえます。組織のスタンスがプロダクトの開発スピードに大きく影響を与えるのです。
そのアジャイルの開発ツールのひとつとして、JIRAがあります。JIRAは世界中で導入されており、非常にパワフルかつ使いやすいツールです。アジャイル開発をするからといって、チームが小さくプロダクトも小さいからといって、記録せずに管理も行わず進めていくのはよくありません。
JIRAを使ってアジャイル開発のマネジメントをしましょう。
アトラシアン製品及びトレーニングに関するお問い合わせはこちら