イノベーション エンジニアブログ


株式会社イノベーションのエンジニアたちの技術系ブログです。ITトレンド・List Finderの開発をベースに、業務外での技術研究などもブログとして発信していってます!


このエントリーをはてなブックマークに追加

社内共有も兼ねてJIRAの使い方をまとめてみます

KTNです
今回は今まで開発の課題管理で使っていたJIRAの使い方をまとめて見ようと思います
色々あって今後JIRAの管理を引き継いで行く感じになるので、
その時の資料に使えればという思いで書きます

基本的に使い始めるときに気にしなくても良いような、細かい設定については説明を省いていこうと思います
また2018年10月に新しいタイプのプロジェクト(次世代プロジェクト)が作成できるようになったようですが、
既存のプロジェクトの説明をするという趣旨のため
今までのもの(クラシックプロジェクト)を扱います

JIRAの概要について

一番大きな単位として「プロジェクト」というものがあり、用途ごとに作成します
例えば弊社だと
開発タスク管理用として「ITトレンド開発」「リストファインダー開発」
承認ワークフロー用として「ITトレンド申請」「リストファインダー申請」などです
設定を確認するときはサマリ画面が見やすいです、
「プロジェクト設定」 - 「概要」と移動すると見ることが出来ます

1.jpg

「プロジェクト」の設定としては、ここに出てくる項目を設定すればほぼ完了です
順番に見ていきます

課題タイプ

「課題タイプ」とはJIRAで作成する課題のグループ分けみたいなものです
「タスク」という「課題タイプ」を作って全部の課題をそれに紐づけても良いですし、
「新規開発」「バグ修正」「質問」など業務の種類によって分けても良いです

この後に出てきますが、課題が終わるまでにどのようなステータスがあるか設定する「ワークフロー」や、
入力項目の種類や、必須項目設定などする「画面」などがあり、それらは「課題タイプ」毎に設定することが出来ます

1つの「プロジェクト」で複数の「課題タイプ」を扱うことが出来るので、
複数の「課題タイプ」をまとめて1つの「課題タイプスキーム」と呼ばれるものを定義して、
その「課題タイプスキーム」を「プロジェクト」に紐づけます

「ITS: 申請課題タイプスキーム」のリンク部分をクリックすると一覧で見れます
課題タイプ「ジョブスケジュール申請」は、
ワークフロー「ITS: JobScheduleApplication Workflow」を使い
フィールド設定「ITS: フィールド設定」を使い
画面「ITS: ジョブスケジュール申請画面スキーム」を使うということがわかります

2.jpg

ワークフロー

「ワークフロー」とは課題が終わるまでにどのような工程を踏む必要があるか設定するものです
例えば課題タイプ「新規開発」の場合に、要件定義→設計→開発→テスト→リリース→クローズのような工程を踏む必要があるとします
この工程を「ワークフロー」で定義しておくことで、課題タイプ「新規開発」の課題に各工程の遷移を強制することが出来ます

各課題が現状どの工程にあるのか見れるようになることや、
「要件定義」から「設計」に変更できるのは特定の権限を持った人だけ(部長だけ)という設定も出来るので、
課題を確認して「設計」となっている場合は部長が承認したという意味をもたせることも出来ます

「ワークフロー」は「課題タイプ」毎に設定可能で、複数の「ワークフロー」をまとめて1つの「ワークフロースキーム」と呼ばれるものを定義して、
その「ワークフロースキーム」を「プロジェクト」に紐づけます

先程の、「ITS: 申請課題タイプスキーム」のリンク部分をクリックすると一覧で見れます

2.jpg

画面

「画面」はその名のとおりです
必要な画面項目(フィールド)複数を1つの「画面」に紐づけて利用します

課題の作成、編集、表示用の「画面」をまとめて1つの「画面スキーム」と呼ばれるものを定義します
「画面スキーム」は「課題タイプ」毎に設定可能で、複数の「画面スキーム」をまとめて1つの「課題タイプ画面スキーム」と呼ばれるものを定義して、
その「課題タイプ画面スキーム」を「プロジェクト」に紐づけます

フィールド

「フィールド」もその名の通りです、「画面」で使う入力項目などの設定です
標準である程度入力項目が用意されているのですが、足りないときに「カスタムフィールド」を作ります
開発費用の予実管理をしたい場合は、「見積総費用」「総費用実績」という感じで自由に作ってください
項目の入力方法の説明コメントの設定や、数値のみ・選択リスト・チェックボックスなどの種類を選択可能です

「カスタムフィールド」のどれを利用するか、表示/非表示、必須/任意などを「フィールドの構成」で定義します
「フィールドの構成」は「課題タイプ」毎に設定可能で、複数の「フィールドの構成」をまとめて1つの「フィールドの構成スキーム」と呼ばれるものを定義して、
その「フィールドの構成スキーム」を「プロジェクト」に紐づけます

ロール

一応説明しますが使わなくても大丈夫なやつです
複数の「プロジェクト」で1つの「ワークフロー」を共有して使う場合などに有効です、
逆に「ワークフロー」を共有する時以外は使う意味がありません
「ワークフロー」のところでちらっとお話していた、
「要件定義」から「設計」に変更できるのは部長だけとした「ワークフロー」を、
「ITトレンド開発」「リストファインダー開発」の「プロジェクト」に設定したとします

プロジェクト「ITトレンド」ではITトレンドを担当する部署の部長Aさんを部長とする
プロジェクト「リストファインダー」ではリストファインダーを担当する部署の部長Bさんを部長とする
と設定することで、「ワークフロー」を共有していながら、
「プロジェクト」ごとに「要件定義」から「設計」に変更できる人を制限出来ます
まあ、使わなくても大丈夫なやつです

権限

「プロジェクト」の管理者は誰か、課題を作れるのは誰かなど
権限設定が出来ます。これは簡単ですね
〜〜の管理、〜〜の削除 の権限は設定を気をつけてください

通知

課題を作ったとき、課題にコメントを追記した時などに
メール通知する設定が出来ます。これも簡単ですね

ただ、課題の状態が変更されたときの動作しかここで通知設定出来ません
1週間更新されていない課題をまとめてメール通知、
設定した期限を過ぎている課題をまとめてメール通知、
などについては「課題とフィルター」を使うと通知することが出来ます

さいごに

ここまででざっくり構成は理解できた。かもしれません!
色々自由に設定できるのですがかゆいところに手が届かないし、
なれるまですごく使いづらいし、色々設定していくと設定がごちゃごちゃ汚くなる
というのが全体的な印象です
設定項目を理解して、設定時のルールをしっかり決めてからやるのがおすすめです

眠いのでここで終わりにしますが、
社内で説明する必要があるのでまた続き書きます

こちらからは以上です