やっぱりシステムエンジニアはストーリーを描けないといけない

２つのレビューをしてそう思ったんですよ。うん（確信。

提案で何度目かのレビューでのこと。１つ前のレビューした資料を持って先方と協議した結果、リリース後のシステムを先方で運用したいから「運用に関わる作業は引き取りたい」と希望があり、役割分担が変更となったと。これによりこちら側は作業が減るので幾つかの資料を修正する必要が出てきます。

役割分担が変わったことで、提案の仕様、つまり、技術仕様と範囲に関わる資料が影響を受けます。作業範囲が変わることでコストも再計算が必要です。

ここまでは誰でも気づきますが忘れがちなものにスケジュールがあったりします。スケジュールは時間軸を展開した上に、局面やマイルストーンをプロットしてSOWで定義した双方の作業タイミングを共有するために使います。

で、SOWが変わるとこのスケジュールの描き方を変えないといけない。そのままでは変更前のSOWなので役割分担を誤謬してしまう可能性を生んでしまうのです。スケジュール上の局面を提案側の作業して描いているならその作業の担当者が誰であるか変わったことを理解できるようにしないといけないんですよ。

資料が複数あるので反映を忘れてしまうのも事情は理解できますが、修正漏れのまま提示したら誤解を与えてしまうわけで、そうすると提案側に非があることになってしまう。

それを回避するには、提案リーダはプロジェクトのストーリーを描いてそれをベースに資料に展開するやり方がいいと思うのですよ。

先の例では運用の局面は先方に移るわけで、そうするとシステムテストの完了のタイミングで主役が先方に変わる、と主役のバトンを渡す、とするんですね。

あとは、主役が変わる局面で場面転換することがイメージできるから、その役割の作業主管の変更をSOWで変わっていることを確認すればいいし、SOWで役割の主体者が変わっているのだからそれに見合ったコストになっていることを反映すればいいのです。で、そのタイミングがわかるようなスケジュールになっているかどうか、マイルストーンの主体者は正しく反映されているかを見ればいいのです。

作業分担の変更で影響を受ける資料を並べて潰していくのもいいですが、それでは気付けないこともある。資料が複数あると頭の中で展開しきって、あっちの資料、こっちの資料と影響範囲を相互に思い浮かべながら自分で紐付けしなくちゃいけないから。

それよりは、ストーリーの変更ポイントを押さえて、自分で提案の脚本を直しつつ矛盾がないように見ていくほうが全体を俯瞰して見ることになるので結果的に抜けにくくなるんです。

ストーリーを描くことは、妄想することです。妄想するということは、あれやこれやとケースを考えるということです。そうやって色々なケースを考えられないと一本線のつまらない、いきなりボスキャラが出てきたら回避できず死んでしまうストーリーしか書けなくなっちゃいます。

提案はプロジェクトのプロットなんですよ。だからストーリーが書けないといけない。ストーリーを誰がアサインされるかわからないプロジェクトチームに丸投げしちゃいけない。丁寧にリスクを回避するストーリーを描かなければならないのです。