Redmineのブロッキング機能はどこで使うのか？～FF関係で使うべきだ！

Redmineの真価の1つは「先行・後続」と「ブロッキング」機能にあるのではないか。
PMBOKの依存関係をチケットに適用し、クリティカルパスを可視化すれば、プロジェクト管理の精度は劇的に向上する。
実践的な運用ノウハウと、煩雑な設定を圧倒的に効率化するLycheeプラグインの活用法を解説してみたい。

【1】Redmineのチケット機能がやはり凄いなと思う点はどこにあるのか？
僕が思うに、先行・後続関係と、ブロッキング機能だと思う。

Redmine標準機能には、先行・後続関係と、ブロッキング機能がある。
一般ユーザは使っているだろうか？

【2】PMBOKの進捗管理の授業資料では、クリティカルパスを説明する時に、アクティビティ間の論理的依存関係として4つの種類が使われる。
具体的には、FS、FF、SS、SFだ。

一般に、FS関係がよく使われるだろう。
「Aが終了しないと、Bを開始できない」関係だ。
Redmineでは驚くことに、標準機能に、チケットの先行・後続を関係づけすることができる。
たぶん、関連チケットの機能を発展させた機能の1つとして実装されたのだろう。

チケット間でFS関係が使って、ガントチャート画面上に表示させれば、クリティカルパスが一目で分かる。
実際は、FS関係を元に、最長となるタスクの経路がクリティカルパスになる。
つまり、FS関係は、クリティカルパスの計算や進捗の遅れ（遅延波及）の把握で使われるだろう。
よって、FS関係が一番利用用途が多い。

【3】では、FS以外のFF、SS、SF関係は使っているだろうか？
一般には、ユーザ自身がそれら関係を理解できていないので使えていないと思う。

【4】SS関係は、「Aが開始しないと、Bを開始できない」だ。
具体的には、2つの作業を並行して進める（ファストトラッキング）際によく用いられるだろう。

たとえば、「新業務プロセスの構築（先行）」の開始と同時に、「マニュアル作成（後続）」を開始する。
たとえば、「データベースのデータ移行（先行）」の開始に伴い、並行して「移行データの整合性チェックツール作成（後続）」を開始する。
つまり、タスクを並行稼働させることで、クリティカルパスを短くする手法として使われるだろう。

RedmineにはSS関係は実装されていない。
理由は、チケットの親子関係で解決できるからだ。
具体的には、SS関係にしたい2つのタスクがある場合、「親チケット（Epicや機能）」を作成し、その配下に複数の子チケットを並行（同じ開始日）でぶら下げることで、WBS（Work Breakdown Structure）的に表現可能だ。
つまり、SS関係にある複数のタスクを親チケットの配下にぶらさげれば実装可能だからだ。

【5】FF関係は、「Aが終了しないと、Bを終了できない」だ。

Redmineでは、完全なFF関係は実装されていない。
しかし、SS関係と同様に、親子チケットを使うことで代用できるだろう。
つまり、親チケットの配下にFF関係にある子チケットをぶらさげて、「先行アクティビティが終了して初めて、後続アクティビティも終了できる（着地を合わせる）」関係を作れる。

しかし、実際のチケット管理のシーンでは、「Aが終わらないと、Bを開始できない（FS）」ではなく、「Aが終わらないと、Bを完了できない（FF）」という制約を強制する機能にすべきだろう。
なぜならば、FF関係の制約は単純に終了日を合わせるのが目的ではなく、「Aが終わらないとBもクローズできない」というステータスに依存した機能だからだ。

具体的な実装は下記になる。
ブロック元＝先行タスク＝A
ブロック先＝後続タスク＝B

実際のRedmineのブロック機能が使われるケースはどこだろうか？
具体的には、「並行して作業は進められるが、最終的な着地（クローズ）は先行タスクの完了を待たなければならない」ケースになるだろう。

たとえば、
ブロック元＝旧システムから出力したデータのクレンジング作業
ブロック先＝新システムへのデータインポート作業
としよう。
ブロック先チケット「新システムへのデータインポート作業」は並行で実施できるが、ブロック元チケット「データクレンジング作業」が作業中ステータスであれば、ブロック先チケット「新システムへのデータインポート作業」はクローズできない。
データクレンジング作業が完了できていないのだから、データインポート作業は全て実行できていないからだ。

したがって、FF関係にあるブロック元チケットのステータスを見ることで、ブロック先チケットを勝手に完了ステータスに更新できない制約を課すことができる。

他の例としては、
ブロック元＝新機能の実装
ブロック元＝システムテスト
ブロック先＝リリース判定レビュー
にしてみよう。

炎上案件では既に進捗遅延していて納期が間に合わないリスクがあるので、リリース判定レビュー（ブロック先）の準備をしながら、新機能の実装（ブロック元）、システムテスト（ブロック元）を平行作業しているだろう。
しかし、リリース判定レビュー（ブロック先）を勝手に完了ステータスにできない。
なぜならば、先行タスクである実装、システムテストが終わっていないからだ。
つまり、リリース判定レビューをゲートウェイのように扱う時に、ブロッキング機能を使うととても有効だ。

さらに、
先行＝リリース判定レビュー
後続＝本番環境へのデプロイ作業
の関係をチケットに付けてみよう。

すると、リリース判定レビューの期日が遅れてしまった時、自動的に、デプロイ作業の開始日もずれるような仕組みを作れる。
たとえば、新機能の実装は終わっても、システムテストのバグ修正が収束せず長引いてしまった時、リリース判定レビューも並行作業で実施しても、リリース判定レビューの期日に間に合わず期日を伸ばすしかない。
その分、デプロイ作業の開始日も先行後続関係の制約により、開始日が後ろに倒れる。
このように、チケットの先行後続・ブロッキング機能をうまく使えば、ガントチャートに現実に即した制約を課すことができるだろう。

ただし、ブロッキング機能は、チケットのステータスに注目した機能なので注意点がある。

1つ目は、ブロック先のチケットは並行で作業開始しても、進捗中のままステータスが保留になる。
担当者が作業を99%終わらせて「あとはブロック元が終わるのを待つだけ」という状態になりがちだ。
つまり、90％シンドロームに陥りやすい。

一見するとプロジェクトが順調に進んでいるように見えて、実は完了待ちのチケットが大量に滞留し、最終盤で大きなボトルネックとして顕在化するリスクがある。

2つ目は、チケット間に、先行後続・ブロッキングを複雑に入れ込むと、循環ブロック（デッドロック）が発生してしまうリスクがある。
この辺りは、RDBのデッドロック機能に似ている。

【6】なお、SF関係は、「Aが開始しないと、Bを終了できない」だ。
これは一番利用用途が少ない。
殆ど見かけないので無視していい。

【7】Redmine標準機能である「先行後続」「ブロッキング」機能はとても良く考えられていると思う。
たぶん、これらの機能があれば一般には十分だろう。

しかし、大量のチケットに「先行後続」「ブロッキング」を1個ずつ付けるのは面倒だ。
実際、ブロック元、先行チケットのIDを逐一覚えておく必要が出てくるからだ。

そこで、アジャイルウェア社が出しているLycheeRedmineプラグインを使って、ガントチャート機能を使うと、ガントチャート画面上でマウスでグリグリすれば簡単に先行後続を関係づけれる。
ブロッキング機能も、ガントチャート画面上で右クリックすることで関連付けが簡単にできる。

Lychee Redmine【公式】ガントチャートで進捗管理をラクに｜プロジェクト管理ツール

丁度、MSProject上で、4種類の依存関係をマウスでグリグリできた機能と全く同じだ。

Lycheeガントチャートには便利な機能が盛りだくさんなので、今後も色々使ってみたいと思う。

Lychee-ガントチャートTips集vol.2≫ Lychee Redmine | テクマトリックス