最初に
プロジェクト管理ツール うまく使いこなせてますか？
システムの保守・維持管理業務でプレーイングマネージャをやっている皆さんこんにちは。
システムの保守・維持管理のプロジェクト管理用にRedmineやJira等のプロジェクト管理ツールを導入し、
ITILとかPMBOKを参考しながら運用ルールを作って、チケットを使ってタスクや課題、工数の管理をやり始めてみたけど、
なんかうまくいかないみたいな経験ありませんか。
例えば
・Excelやメモ帳での管理を脱却してredmine、Jiraに移行してみたけど、結局Excelの方が楽で管理もうまくいってた
・チケットは作成しているけど、忙しくて中身を確認しきれず、結果 長期間放置されている謎の塩漬けチケットが大量
・チケットの種類の決め方、項目の書き方が人それぞれ入力内容や形式がバラバラで、結果どこに何が書いてあるのかわからない。
などなど・・・身に覚えがある人いると思います。
うまくいかない原因はいろいろ考えられますが、
あなたのチーム管理 プレーイングマネージャが率いるチームに適した管理方法になってますか？
※プレーイングマネージャとは
本来チームに必要であるマネジメント専門の立場の人が、体制縮小やコスト足りない等の理由でおらず、やむ負えずプレーヤー(開発等の実働業務)とマネージャ(管理職)を兼務している立場の人です。
マネジメントは大変な業務です。
本来、プロジェクトなどでは場合のQCDの管理や業務のアサイン、育成といったマネジメント業務は、マネジメント専門の役割の人が行います。PM、PMO、品質管理チーム等 それだけ大変な仕事だということです。
プレーイングマネージャは、プレーヤーしつつ大変なマネジメント業務をこなさないといけないので忙殺されてしまい、マネジメント業務まで手が回らないということがしばしばあります。
規模が小さかったり、いろいろと気が利く優秀なメンバーが集まっているチームだと、マネジメントしなくてもうまく回ることもありますが、新しいメンバーが入ったり優秀なメンバーが抜けたりするとうまく回らなくなってしまうので、チームとして良くない状態です。
では、プレーイングマネージャは、どのようにしてプレーヤーとマネージャを両立すればいいかというと
マネジメントを超効率的にやるしかないです！
本記事では、私が過去、システム保守チームのプレーイングマネージャをやらされた時に、忙しくてマネジメントまで手が回らず、労務が悪化し、品質も低下して、追加人員も確保できないような絶望的な状況に陥った時に、なんとかQCDを担保するために編み出した効率的なチームの運営の仕組みの一部を紹介します！
全て書くとすごい量になるので、今回はチーム運営の仕組みの中でも最も重要な課題管理にフォーカスします。
自己紹介
大阪府堺市出身のSEです。
とてもめんどくさがりで、なんでも効率化、自動化したがります。
最近テントサウナを買いました。
好きなHUNTER×HUNTERのキャラはツェズゲラです。
（知ってる人は分かると思いますがツェズゲラもプレーイングマネージャです）
マネージャの役割
マネージャがやるべきことはこれだ！
課題管理の話に入る前に、課題管理を含めたマネジメント業務とは何ためのものなのか、マネージャの役割はなんなのかを書きます。
（内容について異論は認める）
チームで仕事をする上でマネージャに求められるミッションは主に下記の4つです。(優先度順)
1. QCDを担保する
2. PDCAを回す
3. 業務量(労務状況)の管理
4. メンバーの育成
それぞれの中身を語りだすと非常に長くなるので割愛します。
まず、1は必須で、まずはQCDを担保するためにどうするかをベースにチーム運営を考える必要があります。
2～4は組織として継続的に業務を続けていく上で必要で、
特にシステム保守・維持管理においては、対象のシステムが存在する限りは終わりがないので、2～4も重要な要素になります。
本記事の「課題管理」は上記の1～4をチームで達成するための方法論で、主な内容は
・プロジェクト管理ツール(Redmine)のデザイン
・運用方法(チーム運営方法)
になります。
本題 ～Redmineで効率的な課題管理を実現する～
課題を見える化し、効率的に管理せよ！
前置きが長くなりましたが、Redmineを使って前述の1～4を効率的に達成するための課題管理方法を紹介します。
Redmine以外のプロジェクト管理ツール(Jira等)や、プロジェクト管理ツールを使わない場合でも使える考え方なので、環境に合わせて参考にしてください。
課題管理を実現するためにやることは主に下記です。
まず、Redmineのチケットを使って、
・どんな業務(課題)があって、優先的に管理すべき業務はどれなのか。
・誰がどの業務やっていて、どんな状況なのか。
を分かりやすく見える化します。
そして見える化された課題に対して
・対応する業務の見極め(優先度付け)と担当者のアサイン
・業務のQCD状況（成果物や業務推進の品質、工数状況、進捗状況）の確認
・課題が漏れなく起票されているかの確認
・完了した業務の振り返り
を継続的に行えるようにチームの運営方法を決めます。
これをプレーイングマネージャでも管理できる効率的な方法でやる！ それだけです！
以降で実現するための具体的な流れを下記の順で説明します！
①課題とは何かを定義(分類)する
②チケット管理方法をデザインする
③Redmineをデザインする
①課題とはなにかを定義(分類)する
課題区分をいい感じに決めろ！
課題管理を行う上で、最も重要なのが、「課題」とは何なのかを明確にすること です。
言い換えると、管理対象の課題を分類すること です。
課題管理経験者は分かると思うのですが、
「課題」といっても、いろんな種類(課題区分)があり、課題の分類で躓く人がたくさんいます。
例えば システム障害、設計書不備、バグ、問合せ、組織改善 etc...みたいな、広義の「課題」がいっぱいあります。
この「課題区分」は馬鹿正直に細かく分類しすぎるとチケット作成時の区分の判別や管理が大変で、分類が甘いと課題の中身がなんなのかわからなくなります。
ベストな粒度で課題区分を決める必要があります。
そこで、私が考える課題区分の決め方のポイントは下記です！
直近の私のチームで採用した課題区分を例に詳細を説明します。（課題管理以外も含まれてますが、この方がデザインの感覚はつかめると思います！）
上記の課題管理では3つの管理区分を採用しています。
| 管理区分 | 説明 |
|---|---|
| インシデント管理 | システム障害における、障害発生～暫定対応～本格対応方針決定を管理する。 |
| 変更管理 | システム更新、修正、リリースが必要になる課題を管理する。 |
| 問題管理 | 上記以外の課題を管理する。 |
インシデント管理、変更管理、問題管理 というワード自体は、ITILでも使われている表現なのですが、これらの言葉の意味は重要ではありません。
大事なのは、ポイントの
１．管理(運用)方法を意識している かどうかと
２．誰が判断しても同じ区分になる かどうかです。
まず、１．管理(運用)方法を意識している かどうかについては、
組織やシステムの管理方法によって違いはあるのですが、
上記の例では
システム障害（＝インシデント管理）と、
システム更新(リリース)（＝変更管理）
を重要視し、個別に管理する必要があるため、切り出しており、それ以外は問題管理で一括りにしています。
問題管理をさらに細かく分けることもできますが、課題区分は管理に必要な最小限の数なのでこうしています。
私の経験上、プレーイングマネージャがマネジメントを行うチームでは、これ以上区分を増やすと管理が大変になってまわらなくなります。
２．誰が判断しても同じ区分になるかどうかについては、
チケット判別フローを見ればわかりますが、事実に基づいて、だれがやっても同じ区分になるようになっています。
（案件か？は微妙に曖昧さを含んでいますが、この場合は何が案件なのかを明確に決めておくとよいです。）
要するに、上記の2つのポイントを意識しつつ、チームとして管理必須な重要な課題区分（障害など）をリストアップし、課題区分が明確に判別できるように判別フローを考えながら課題区分を決めるとよいです。
cf.システム障害の管理はとても重要
特にシステムの保守・維持管理においては、システム障害は最優先で対応すべきものであり、管理も個別に行ったほうがよいです。システム障害の管理とは、事象や原因、対応内容、システム影響を記録しておくことです。
障害の記録はとても重要で、同じような障害が発生したときに参照したり、対応内容が妥当なのかを振り返ったり、システム運用における品質の担保やPDCAを回すのに必要不可欠です。
また、上位の組織や、他チーム、顧客側等の運用で、障害報告や障害一覧の提示を求められる場合もあったりします。
インシデント管理で何を管理するのかは後述します。
②チケット管理方法をデザインする
課題区分が決まれば、どのように管理するかを具体的に決める必要があります。
Redmineのチケットでの管理が前提ですので、決めるものは下記の2つです
１．管理すべきチケット項目を決める
２．チケットのワークフローと運用方法を決める
１．管理すべきチケット項目を決める
これも重要です。課題管理表の項目名にあたるものです。
課題管理表を見たことがない人はいないはずなのでイメージつくかと思います。
一般的な課題管理表の項目は下記みたいなかんじです。
参考URL：https://www.sei-info.co.jp/webdatabase/scene/basic_issue_mngmt_tbl.html
上記をそのまま利用しても良いですが、効率的に運用するにはベストではないです。
それぞれ説明します。
１．項目数は必要最低限にせよ（曖昧な項目は消去せよ）
項目数が多いと、チケットの作成が面倒くさくなり、チケットが漏れなく作成されなくなったり、必須じゃない項目が入力されなくなったりします。←重要
あと、よくある課題管理表やタスク管理表の中で、何を書けばいいのか曖昧になってしまいがちな項目があります。
↓こいつらです↓（異論は認める）
★重要度、優先度、影響度
★進捗率(%)
この項目はできれば無くしましょう。（高、中、低とか何%とか個人の感覚で決められたり、基準を決めても 全部優先度：高になって結果項目の意味がなくなることが多々ある。）
後述しますが、チケットを管理する上で重要なのは、対応中(進行中)のものなのかそうではないのかだけで、これらの指標は運用をややこしくして生産性を落とす一因になります。
）
２．別の管理媒体への転記が必要な場合は、転記先の項目に合わせろ
組織の都合だったり、上長への報告だったり、いろんな事情で、課題内容を転記する運用が避けられない場合があります。
転記するという業務は、無駄of無駄なので無くせるものなら無くしましょう。
ただ、どうしても転記しないといけない場合は、転記の手間は最小限にしたいです。
Redmineでは、チケットをCSVでexportできたりするので、別の課題管理表に転記しないといけない場合などは、exportしてそのままコピペできるようにRedmineの項目を転記先の課題管理の項目と合わせるとよいです。
インシデント管理の項目を例として載せておきます。
必要な項目は記載しつつ、効率化や、品質の均質化のために、ある程度入力内容が決まっている項目はテンプレートを設定しておくと良いです。
２．チケットのワークフローと運用方法を決める
ワークフローとは、チケットにおけるステータス遷移のことで、その業務がどのような状態にあるのかを表します。
ワークフローは運用方法によって変わってくるので、同時にデザインする必要があります。
運用方法は様々で、マネージャによって好みが分かれるのですが、
効率、品質両方を兼ね備えた（と私が思っている）カンバンボードを使ったアジャイル風のチケット運用を例に紹介します。
上記のポイントを踏まえたワークフローでカンバンボードを設定した時の例は下記みたいな感じです。
※なお、Redmineでカンバンボードを使う場合は「Redmine agile」「チケットパネル」といった無料のプラグインをインストールする必要があります！
各ステータスごとの意味と運用方法は下記の通り。
①起票
⇒課題が発生したら、まずはチケット起票する。
②未対応
⇒タスクスケジュール、担当者が決まっていないチケット。
担当者のアサインはマネージャが行い、タスクスケジュールや要件は、担当者の力量に応じて任せる。
（自分でタスクが切れない担当者の場合は、マネージャが設定した上でチケットにアサインする）
③対応中
⇒タスクスケジュール、担当者が決定し、対応中で特に問題が発生していないチケット。
設定したスケジュール通りに順調に進んでいると見做し、チェックしない。
④対応中（問題あり）
⇒担当者だけで判断できず、週次のチーム定例や進捗定例等の場でホウレンソウ(エスカレーション)が必要な問題が発生しているものは。担当者が定例までにこのステータスに変えておく。
⑤クローズ待ち
⇒課題の対応が完了したもの。完了条件を満たしていることを確認し、チームメンバーで振り返りしてクローズする
このワークフローや運用方法はあくまで、一例ですが、ポイントを意識して決めていればよいです。
上記のワークフローと運用の考え方をポイントに沿って説明します。
１．ステータス数は運用を考慮した必要最小限の数にする
まず、管理の手間を減らしてわかりやすくするために、ステータスの数は最小限にします。
課題管理においては、
・対応中かどうか
・対応中の課題にQCDの問題が発生しているかどうか
がわかれば良いので、上記のようにしています。
組織の運用上、管理必須のステータスがあれば増やしてもよいです。（例えば「レビュー待ち」とか「承認待ち」とか）
★ステータス増やした方が、漏れがなくなるから品質向上するのでは？と思うかもしれませんが、ステータス変更の手間が負担となり、逆効果になる場合があります。（レビュー待ちチケット溜まってるから適当にレビューしよ！ みたいな・・）
極力、マネージャのステータス変更の手間を減らすためにこのようにしており、スケジュール通りに成果物レビュー等を終わらせる責任はチケット担当者に任せるようにします。
２．マネージャがチェックすべきチケットが一目でわかるようにする
前述していますが、プレーイングマネージャは多忙で、メンバ全員の全ての業務内容をチェックする時間はないです。
選択と集中の考え方で、QCDの状況に問題があるものだけを重点的にチェックすべきです。
上記の運用方法では、普段は自分の業務で忙しいプレーイングマネージャが週次のチーム定例の場でメンバの業務状況をチェックする運用を前提としています。
ホウレンソウが必要なチケットについては、担当者が自ら「対応中（問題あり）」に変更し、マネージャはそれのみを確認します。
３．担当者の責任範囲を明確にする
業務をチケット化することで、責任範囲は明確になっていますが、チームの運用として、どこまで責任を持つのかは明言しておいた方がよいです。
「チケット担当にアサインされた担当者は、そのチケットを責任をもってクローズさせる。」のようにルールに明記して、メンバにも伝えて自分の責任範囲を意識させ、 業務を 任せる ことが大事です。
どこまで責任を持たなければならないか を明確に意識させることで、メンバーの意識向上、育成にもつながります。
（意外にみんな出来ていない ホウレンソウ の練習にもつながります）
また、メンバーの力量によってアサインするチケットの難易度や規模をコントロールし、メンバーの能力よりも少し難易度が高いチケットをアサインすることでより難しい業務ができるようになっていきます。
責任範囲の考え方も厳密に話すと長くなるので割愛しますが、メンバーの育成 につながる重要な要素であることは理解できたかと思います。
４．チケットの棚卸はメンバー全員がいる場で定期開催する
課題管理をやる上で必須なのが「棚卸」です。
週次、月次等 定期的に実施する必要があります。
アジャイル風課題管理における、定期開催する棚卸会 は、アジャイル開発のスプリントにおける「デイリースクラム(朝会)」をイメージしてください。
アジャイル開発では、チームにおけるタスク一覧の中で、その日(スプリント)でやるべきタスクを決めて、だれがやるかをアサインしますが、
棚卸会でも同様に未対応のチケットを誰がやるかをアサインします。
具体的には
・未対応の課題チケットの中で、対応すべきものを判別して、手が空いている進行可能なメンバをアサインする。
・対応中のチケットの担当者に偏りがある（特定のメンバが担当しているチケットがたくさんある）場合は、担当者の見直し等を行う。
みたいなことをします。
チームで仕事を割り振る会なので、全員いる場で行う必要があります。
この運用をしていると、例えば1か月に利用可能な工数制限（固定で道幅20人月みたいな）がある場合、
対応する課題の予定工数の合計が、1か月の工数を超えていないか みたいなコスト、工数の管理も可能になり、
下記みたいに、担当者毎の負担の可視化も可能になります。
↑↑担当者毎のチケット数を可視化し、特定のメンバーに負担が偏ってないか？（労務管理）ができるようになります。
あと棚卸会は、進捗定例とは別開催してください。
③Redmineをデザインする
課題管理におけるRedmineのデザイン方法については ②チケット管理方法をデザインするでほぼ説明したので、
デザインした内容をRedmineに設定してみます。（ググればわかるので超簡単に流れだけ解説します）
また、課題管理を効率的に行い、運用をチームに定着させる上で特に意識すべきポイントを紹介します。
Redmine設定の流れ
１．カスタムフィールドに必要な項目を追加する。
２．チケットのステータス(カンバンボードの列）を登録する。
３．Redmineプロジェクトを作成する。
４．課題区分に対応したトラッカーを作成する。
５．トラッカーに対してワークフローを作成する。
上記の中でも、癖が強くて扱いずらい ５．トラッカーに対してワークフローを作成する。 だけ実例を紹介します。
ワークフローを厳密に考えると大変ですので、チーム内に統制ルールとかがないなら↓↓みたいに全部チェックしてください！(力技)
１．１クリック、１画面遷移の効率化を惜しむな！
チケットが漏れなく切られないことの原因の一つに「チケット切るのがめんどくさい！！」というものがあります。
②チケット管理方法をデザインする でも、項目数を減らせとかステータスを減らせとか書きましたが、
チケット駆動の管理方法において、チケット操作が面倒くさいというのは本当に致命的です。
特に、チケット起票 は一番漏れてはいけないところなので、Redmineの便利な機能を使って効率化しましょう！
STEP1：チケットテンプレートを作成する
Redmineプラグインのチケットテンプレートを設定します。
下記に1例をあげます。
ある程度決まったフォーマットを入力しておいて、チケット入力の手間を削減できます。
STEP2：チケット起票ボタンをブックマークしておく。
もはやただのブラウザのブックマークですが、
チケット種別ごとに、1クリックでチケット起票できるように設定しておき、テンプレートが表示されるようにすれば、チケット起票が楽になります。
ブックマークはRedmineのトップページだけにして、トップページからチケット起票まで遷移すればええやん って人は、
1クリックの手間を甘く見すぎなので、UIの勉強してください。（半ギレ）
↑ブックマークの一番いいところにチケット起票のブックマークを張っとけば一発でチケット切れます！
任意のテンプレートの呼び出しはURLのリクエストパラメータに値を設定することで実現できるので下記を参考にやってみてください。
出来れば全ての課題区分のチケットテンプレートを呼び出すブクマを登録してください。
https://blog.redmine.jp/articles/opc/new-issue-template/
２．メンバーに運用が定着するまでは、Redmine警察をし続けろ！
Redmineチケットで課題を管理する場合、下記をしっかりできていないと、そもそも管理が成り立たない場合があります。
・課題チケットが漏れなく起票されている
・課題チケットの中身が最新化されている
これらをやるには、誰かがしつこくチェックしてRedmine警察をやり続けるしかないです。
チケットに書くべき内容をチャットで言ってくる人に対して「チケットに記載お願いします！！」
障害や問題が発生したら「チケット起票お願いします」
としつこく言い続けてください。
３ヵ月ぐらいやり続ければ定着します！
３．自動化できるところは自動化しろ！
私が言うまでもないですが、自動化は大事です。
宣伝になりますが、
以前担当していたシステムでは、システム障害が非常に多く、障害対応や、障害対応のナレッジの蓄積等の管理にかかる手間を全部自動化するツールを導入し、障害対応、障害管理の工数負担を激減させてました。
障害発生⇒障害メッセージをツールに自動連係⇒対応メンバに自動電話⇒障害メッセージを分析し、自動的に障害対応手順をチャットでレコメンド⇒障害状況のエスカレーション⇒障害の対応内容ナレッジや原因などの登録
を全て半自動化してくれるZeroOpsというツールで非常に便利なので、気になる方は是非 ke-yoi@kddi.com までご連絡ください。
最後に
読んでくれた人ありがとうございます。
Qiitaの記事 初めて書いたのですが、題材選びを間違えてとんでもないボリュームになってしまいました。
（手法よりマインドの話が強くなってしまいましたが・・・
本当はもっとオシャレな図表とか使って文字少なくして、原宿っぽい感じにしたかったんですが、体力が持ちませんでした。
RedmineやJiraを使ったプロジェクト管理が主流になってから10数年経過しており、いろんな管理方法がやりつくされていてQiitaにもこの類の記事は多く、ITILやPMBOKで体系的なマネジメント方法も学ぶことができるのですが、
本記事で書いてあるような、忙しくてマネジメントできないプレーイングマネージャのための管理方法ってありそうでなかったりします。
現場の事情に合わせた管理方法にする必要があるので、忙しくて管理方法の改善すらできない！みたいなチームやリーダーが結構いると思ってます。
この記事で紹介した、システムの維持管理の高品質化、効率化の手法は、忙しい中で何とか品質を担保したいという思いでとても苦労して死ぬ気で生み出したもので、ちゃんとマネジメントして品質担保したいけど、忙しくてできない！みたいなチームリーダーやマネージャの方々の助けになれば良いなと思ってます。
個人的には自分が生み出した方法をどこかに体系的にまとめたいなと思っていたので、2022年のクリスマスのタイミングでまとめられてよかったです。（正直自分用のまとめみたいな感じです）
自分の周りでは割とこの辺の管理で困っている人多かったので、どなたかの役に立ったらうれしいです。