「進捗率を出すだけの関数なのに、タスクの階層が深くなるとバグるんです。しかも今度、マイルストーン機能を追加しろって……」
私は高橋。中堅SIerでエンジニアを8年やっている。去年までは受託開発の現場をいくつも渡り歩いてきたが、半年前に自社プロダクトの開発チームに異動になった。社内PMツール「TaskFlow」の保守が、私の新しい仕事だ。
TaskFlowは元々フラットなタスクリストだった。タスクを作って、完了にチェックを入れて、進捗率が出る。それだけのシンプルなツールだった。ところが前任者が退職する直前に「サブタスク機能」を追加した。タスクの下に子タスクを作れるようになり、さらにユーザーから「サブタスクにもサブタスクを付けたい」という要望が来て、孫タスクにも対応した。
問題はそこからだ。進捗率を計算する関数。工数を合計する関数。完了数をカウントする関数。どの関数にも「これはタスクか？ タスクグループか？」を判定するif文が入っていて、階層が増えるたびにバグが出る。
そして今朝、プロダクトマネージャーが笑顔で言った。
「高橋さん、マイルストーン機能も追加してもらえますか？ 次のスプリントで」
マイルストーン。工数はゼロだが、完了/未完了の状態を持つ新しいノード。つまり、あのif文がすべての関数でもう1分岐増える。
私は嫌な予感を覚えながら、雑居ビルの階段を上がった。
「レガシー・コード・インベスティゲーション（LCI）」
ガラス扉を開けると、キーボードの打鍵音とエナジードリンクの甘い残り香。革張りの椅子に沈み込んだ男が、私の顔を見る前にモニターに映った何かを睨んでいた。
「……ふむ。ワトソン君、少し待ちたまえ。今この正規表現の犯人を追い詰めているところだ」
「高橋です。初めてなんですが……」
「初めてだろうと百回目だろうと、ここに来た者は皆ワトソン君だ。それで、今日の事件は？」
自称「コード探偵」のロックに、私はTaskFlowのコードを見せた。
現場検証：分断された指令系統
「まず全貌を見せたまえ」
私はタスクのデータ構造を開いた。
| |
「ここまではいいんです。問題はここからで……」
私は工数集計や進捗率計算の関数を開いた。
| |
「見てください。total_hours、count_completed、count_all……全部同じ構造のif文です。ref $node eq 'Task' か 'TaskGroup' かで分岐して、グループなら再帰する。ここにマイルストーンを追加したら、3つの関数すべてに elsif を足さないと……」
ロックは私の言葉を遮るように手を上げた。
「初歩的なにおいだよ、ワトソン君」
ロックは立ち上がり、ホワイトボードにツリー構造を描き始めた。
「この構造は地下組織の系譜図と同じだ。ボスの下に幹部がいて、幹部の下に構成員がいる。だが君のコードは、ボスに報告を求めるときと構成員に報告を求めるときで、まったく別の手順書を使っている」
「手順書……ですか？」
「そうだ。ref で相手の肩書きを確認し、肩書きごとに違う命令を出している。新しい役職——たとえば『連絡員（マイルストーン）』——が組織に加わったら、すべての手順書を書き直す必要がある。こんな組織は統率がとれていない」
ロックはツリーの各ノードに×印を付けていった。
「関数が3つで済んでいるうちはまだいい。だが表示処理やエクスポート機能が加われば、同じif文はさらに増殖する。そしてどこか1つの関数で Milestone を書き忘れれば——」
「実行時にクラッシュする……」
「型チェックの散在。これが今回の犯人だよ、ワトソン君」
推理披露：統一された命令系統（Composite）
「ワトソン君。よく統率された組織とは、どういうものだと思う？」
「えっと……命令系統が一本化されている、とか？」
「悪くない。もう一歩踏み込もう。ボスも幹部も末端の構成員も、同じ命令に同じ形式で応答する。ボスに『工数を報告せよ』と言えば、ボスは部下たちに同じ命令を伝え、集まった報告を集約して返す。末端の構成員は自分の工数をそのまま返す。命令する側は、相手がボスか構成員かを知る必要がない」
「相手が誰かを気にせず、同じ命令を出せる……」
「それがCompositeパターンだ。まず、全員が守る掟を定める」
【After】共通の掟（TaskComponentロール）
| |
「TaskComponent は組織の掟だ。この掟に従う者は、必ず total_hours、count_completed、count_all に応答できなければならない。progress はこの3つから自動的に計算される——掟に組み込まれた共通ロジックだ」
「Moo::Role で共通のインターフェースを定義して、progress だけはデフォルト実装を持たせるんですね」
「次に、末端の構成員だ」
【After】末端の構成員（TaskLeaf）
| |
「末端はシンプルだ。自分の工数、自分の完了状態、自分は1人。それだけを報告する」
「Before の if (ref $node eq 'Task') の中身が、そのままメソッドになっただけ……？」
「その通り。では次に、幹部——子を持つノードだ」
【After】幹部（TaskComposite）
| |
「幹部は自分では作業しない。部下に同じ命令を伝え、返ってきた報告を集約する。そして重要なのは——部下が末端の構成員でも、別の幹部でも、同じ方法で命令を出しているということだ」
私は画面を見つめて、少しずつ理解が追いついてきた。
「$_->total_hours を呼んでいるだけで、相手が TaskLeaf なのか TaskComposite なのか、一切チェックしていない……！」
「よろしい。ref による身元確認は不要になった。全員が同じ掟に従っているからだ」
ロックはホワイトボードに新しい図を描いた。
classDiagram
class TaskComponent {
<<Role>>
+title
+total_hours()*
+count_completed()*
+count_all()*
+progress()
}
TaskComponent <|.. TaskLeaf
TaskComponent <|.. TaskComposite
TaskComponent <|.. Milestone
TaskComposite o-- TaskComponent : children
class TaskLeaf {
+hours
+completed
+total_hours()
+count_completed()
+count_all()
}
class TaskComposite {
+children
+add(child)
+total_hours()
+count_completed()
+count_all()
}
class Milestone {
+reached
+total_hours()
+count_completed()
+count_all()
}
「そして——ワトソン君が恐れていたマイルストーンの追加だ」
【After】新たな構成員（Milestone）
| |
「……え、これだけですか？」
「これだけだ。TaskComponent の掟に従うクラスを1つ作る。既存のコードは一切変更しない。TaskComposite は子が何者であろうと total_hours を呼ぶだけだからね。マイルストーンだろうと、将来追加される『レビュー待ち』ノードだろうと同じだ」
「Before だったら、3つの関数すべてに elsif (ref $node eq 'Milestone') を追加して……」
「そして4つ目の関数でそれを忘れてバグを出す。開放閉鎖原則——拡張に対して開き、修正に対して閉じている。Compositeはそれを自然に実現する」
「使う側のコードも見せてもらえますか？」
【After】組織を編成する
| |
「$project->total_hours も $phase1->total_hours も、同じメソッド呼び出し……。プロジェクト全体でもフェーズ単位でも、タスク単体でも、同じインターフェースで操作できるんですね」
「組織のどの階層を切り取っても、同じ命令系統が通る。ボスに聞いても幹部に聞いても末端に聞いても、報告の形式は変わらない。それがCompositeの本質だ」
解決：組織に秩序が戻る日
ロックがテストを実行すると、ターミナルに整然とした結果が並んだ。
| |
「Before ではテスト10を見てください。Milestone を渡した瞬間に Unknown node type で死んでいます。After では、TaskComponent の掟に従うだけで既存のツリーにそのまま組み込める」
「テスト16から19がすごいですね。Milestone をツリーに追加した後も、プロジェクト全体の集計が自然に更新されている……」
「当然だ。幹部が部下に命令を委譲し、部下がさらにその部下に委譲する。組織の深さに上限はない。これがCompositeの再帰的な強さだ」
「感動しました……。これなら次に『レビュー待ち』ノードを追加しろって言われても、クラスを1つ書くだけですね」
ロックは椅子に深く沈み込み、エナジードリンクの缶を手に取った。
「報酬は——そうだな。この組織の階層の深さと同じ杯数のエスプレッソをいただこうか」
「3階層なので3杯ですね。Before の if のネスト数じゃなくて良かった……」
「ふん。ワトソン君、最後に一つ」
ロックは人差し指を立てた。
「Compositeはツリー構造を統一的に扱いたい場面で威力を発揮する。だが、世の中のすべてのデータがツリーである必要はない。フラットなリストで十分なところに無理にCompositeを持ち込むのは、2人しかいない部署に組織図を作るようなものだよ」
私はPCを閉じて立ち上がった。マイルストーン機能、次のスプリントで余裕で間に合う。
探偵の調査報告書
| 容疑（アンチパターン） | 真実（パターン） | 証拠（効果） |
|---|---|---|
型チェック分岐の散在（Type Check Dispatch）。ツリー構造の各ノードに対し ref で型を判定する if/elsif が操作の数だけコピペされる。新しいノード種の追加で全関数の修正が必要になり、1箇所でも書き忘れればランタイムエラー。 | Composite パターン。共通インターフェース（Role）を通じて「個」と「集合」を同一視し、ツリー構造を再帰的に操作する設計方式。リーフもコンポジットも同じメソッドに応答する。 | 型チェック if 文が全関数から完全に消滅。新しいノード種の追加はクラス1つで完了し、既存コードの修正はゼロ。ツリーの深さに制限なく動作。 |
推理のステップ
- 共通インターフェースを定義する: すべてのノードが守るべき契約（
total_hours、count_completed、count_all）をRoleとして定義する。共通ロジック（progress）はRole内に実装する。 - リーフノードを実装する: 個別のタスクは自分自身の値だけを返す、最もシンプルな実装にする。
- コンポジットノードを実装する: 子を持つグループノードは、子に同じメソッドを委譲し、結果を集約する。子の具体的な型には一切依存しない。
- 新しいノード種を追加する: Roleを実装するクラスを1つ作るだけで、既存のツリーにそのまま組み込める。既存コードの修正は不要。
ロックより
ワトソン君。ref による型チェックは、一見すると素朴で分かりやすい手法に見える。だがそれは、組織の全員に顔写真付きの名札を確認してから別々の手順書で対応するようなものだ。構成員が増えるたびに手順書が膨れ上がり、一人でも確認を忘れれば組織は崩壊する。
Compositeは「掟」の統一だ。ボスも幹部も末端も、同じ命令に同じ形式で応答する。命令する側は、相手が一人の構成員か百人を束ねる幹部かを知る必要がない。この無関心こそが、組織の柔軟さを生む。
ただし、ツリーの全ノードに無理やり同じインターフェースを課すと、リーフに不自然なメソッド（add や children など）が生まれることがある。掟は必要最小限にとどめたまえ。過剰な統制もまた、組織を硬直させるのだからね。