Diary?

(22:33)

変更管理は難しい。理屈の上では「こうすりゃいいじゃん」とわかっていても、実践する段階になるといろいろと問題が出てくる。俺はフレームワーク・共通ライブラリ・パイロット実装の仕事をすることが多いのだが、これらは特に変更管理が難しい。

例えば「パイロット版の実装をしつつその成果をフレームワーク・ライブラリにフィードバック」という作業を考えてみる。理想を言えばパイロットの実装者はフレームワークに手を入れるべきではなく、そこはフレームワークチームに修正を要求するべきなのだが、実際のところはそうもいかない（人手はいつでも足りない）。というわけで「パイロット版の実装」というタスクから「フレームワークの修正」というタスクが派生していくわけだが、これをどうやって管理するのか。まあ単純にタスクの親子関係の定義とスケジュールの更新ができれば問題ないんだが。ってかクリティカルパスに引っかからない範囲で辻褄あってりゃいいじゃんスケジュールなんて。

それでここから先はちと Rational Clear Quest と今の俺に限定した話になってしまうのだが、現状で俺には CQ にタスクを登録する権限が与えられていない。だが考えてみれば俺は（一次請けの人と協議するとはいえ）担当部分の仕様から作業スケジュールまで諸々の決定権があるに等しいのだから変更管理についても権限を持っていないとおかしい。言われるままに手を動かすだけの要員ならそんな権限があっても仕方がないが、参加当初はともかく先月頭辺りからの俺にはそういった権限があった方が良く、ここはちゃんと交渉しておくべきだった。

流石に個別のタスクを取りまとめる上位タスクなどに踏み込むような部分の権限は不要だが、相応の決定権のある要員には変更管理とスケジュール管理についても相応の決定権がないと困ったことになりかねない。ということはこれは（変更管理のお膳立てがしてあれば）権限の委譲をどうするかという問題になる……のか?

まあ、変更管理について何かしらの知見が得られただけでも今回のプロジェクトに参加する意義は多いにあったな。