新規事業など継続的開発が見込まれるプロジェクトでのJIRA運用

世間はゴールデンウィーク突入で楽しそうなポストで賑わっている最中、39度近い高熱でうなされるという、泣けてくるスタートを切ったMMM代表の国本です。

今月から新年度が開始され、業務効率化・品質の更なる向上に向けて様々な取り組みを進めていますが、その一環として、課題管理・プロジェクト管理のツールとして新たにAtlassian(アトラシアン)社のJIRAを採用したプロジェクトのマネジメントを進めています。

今回は受託開発(クライアントワーク)を前提に、お客様ビジネスの継続的な改善、機能開発が発生するような新規事業プロジェクトを対象としたMMMのJIRA運用例を簡単にご紹介したいと思います。

JIRA導入の目的

昨今、複数のプロジェクト運営を同時並行で進めており、工数見積や機能の要件定義、開発タスクや雑多な運用業務に関して、厳密な管理・可視化をGithub Issueのみで実現することが困難となってきました。

そこで、管理できるプロジェクト形式の懐の広さ、アドオンを含めた機能の豊富さと、柔軟なカスタマイズが可能な点から、JIRAをプロジェクト管理に活用を決定し、全タスクをストーリー化し、JIRA上で一元管理することで

• 工数見積の上振れを抑制し、納期遅延を防ぐ
• 納期含めたタスク進捗を可視化し、属人化・タスク漏れを防ぐ
• プロジェクト全体として今完遂すべきタスクを可視化し、主体的な取り組みが可能な土壌を作る
• タスク・納期の明確化により、品質に掛けられる工数低下をヘッジする

これらを実現し、より健全なプロジェクトの運営を目指しています。

利用するJIRAプロジェクトの形式

受託開発(クライアントワーク)における新規事業の立ち上げや、KPIをベースとした改善・機能改修などが継続的に必要なプロダクト開発などターゲットとした場合は、JIRA上に定義されているプロジェクトの スクラムソフトウェア開発 を利用しています。

こちらは文字通りアジャイルにおけるスクラム開発前提の管理方式となっており、継続的な改善を、迅速にリリースし、顧客へ価値を届けていく必要があるプロジェクト、いわゆるSoE(System of Engagement)に類されるような、攻めのプロダクトにフィットする方式だと考えています。

プロジェクトのフロー

1. ストーリー出し

ビジネス上の解決したい課題、付加価値を加えるアイディアや機能改善、そしてリファクタリングや運用上必須となるタスクなどを、JIRAプロジェクトの 課題タイプ から ストーリー を選択して、起票します。

受託開発においては、プロジェクト状況や、ストーリ化したい内容により粒度も異なるため、2017年4月時点であえてストーリーフォーマットは統一していませんが、 ストーリーにおける完了条件 は確実にプロジェクト・メンバー全員で共通認識を持って理解できる形でストーリー起票時に記入必須とするルールを設けています。

この時点のストーリー出しは、あまり細かい粒度を気にせず、現時点で思いつく限り漏れがないようにプロジェクト・メンバー全員で実施します。

2. 工数見積りとストーリー分割

JIRAプロジェクト上に起票された ストーリー に対して、プロジェクト・メンバー全員参加で工数の見積りを行います。

この際に用いる見積り方式としてMMMではアジャイルな見積りと計画づくりで紹介されている、50%(標準的)と90%(悲観的)それぞれの確率で終わると見込まれる工数をベースに標準偏差を用いて算出された営業日数を、 ストーリー の 見積り にポイントとしてセットしています。

アジャイルではフィボナッチ数などを用いることが多いかと思いますが、上記の標準偏差を用いたバッファ見積りと、受託開発時のクライアントへの説明などを考慮し、MMMでは見積りポイント = 営業日数というルールで運用しています。

また、このタイミングで実装や改修に5営業日を超えてしまうと見込まれるストーリーについては、ストーリーを適切なサイズに分割し、スプリント計画フェーズに備えておきます。

3. リリース計画

工数見積が完了し、ストーリーが適切に分割された状況で、プロダクトのリリース計画を立案します。

JIRAプロジェクト リリース から version name を定義し Start date と Release date をセットしリリースを追加した後に、そのリリースを行うにあたり、完了が必要な ストーリー を編集し 修正バージョン から先程作成した リリース を紐付けます。

この リリース の紐付けにより、JIRAプロジェクトからリリース毎の ストーリー を可視化でき、プロジェクトメンバー全員でリリースに向けた共通認識を持てるようになります。

4. バックログからのスプリント計画

ここまでの工程で、実施すべきタスクが適切と考えられる粒度でストーリー化され、見積りが完了し、リリース計画が立案できているため、JIRAプロジェクト上で スプリントの作成 に入ります。

JIRAプロジェクト上で、 スプリントの作成 をクリックし、新規生成されたスプリントに対して、先の工程で作成済みの ストーリー をドラッグ・アンド・ドロップで登録し、 Start sprint をクリックすることで、スプリントが開始されます。

スプリントの実施期間は様々な定義があるとは思いますが、MMMではフレキシブルでリズミカルな開発を実現するために『1スプリント = 1週間』と比較的短い間隔で定義しています。

5. 振り返り、次スプリント計画へ

MMMでは、毎週金曜日の午前中にプロジェクトメンバー全員で当週のスプリントに対する振り返りを行います。

JIRAプロジェクト上の アクティブなスプリント にて当週のスプリントが可視化されており、MMMではこのボードの表示を 作業前 進行中 レビュー中 完了 という4つのステータスを持たせて利用しています。

デフォルト状態のボードに対して レビュー中 という列を追加で設けており、こちらはコードレビューや顧客側の受け入れテスト(UATなど)のストーリーが所属する形です。

振り返りでは、当週の アクティブなスプリント をベースに良かった点・悪かった点を全メンバーで振り返り、その場で次週のスプリント計画を立案し、ストーリーの登録を行い、次週のスプリント実施に入るという改善のループが繰り返されるという形です。

また、 ストーリー を進めていく中で、新たに対応が必要なタスクや、漏れていたストーリーについては、バックログに追加を行っているため、この追加されたストーリーについても、振り返り時にチェックしています。

JIRAに改善して欲しい箇所

MMMでは今回ご紹介した スクラムソフトウェア開発 以外にも運用保守の管理では プロジェクト管理 なども利用しており、JIRAを引き続き活用していく予定ですが、いくつか改善を行って欲しいと考えている点もあります...。

課題作成時にMarkdownが使えない

MMMではGithubやesa.ioなどを多用しているため、ドキュメントはMarkdownという文化があり、課題の起票やコメントにMarkdownが標準で利用できないというのは非常に辛みです。

設定オプションなどでMarkdown形式が選択できると最高なのですが。

クラウド版だと動作が重たい

現在クラウド版を利用していますが、動作がもっさりしているのが非常にストレスが溜まります。

自社ホスト方式に切り替えれば良いのかもしれませんが、運用コストを掛けたくないので、クラウドプロダクトを選定しているという前提もあり、クラウド版の高速化に期待しています。

まとめ

MMMではJIRAを本格導入してまだ日が浅い状況ではありますが、プロジェクト管理のツールとしては非常に高機能で、かつ幅広いユースケースに対応できる点から、現時点で非常に満足しています。

今後、並行でもうすこし軽めのTrelloなども検証・活用も行う予定ですので、また別途ブログでご紹介できればと思います。

ではでは。

kuni