今日（7月1日）は富士山の山開き。夏になると、富士山をはじめ、山開きや海開きの様子がニュースになることが少なくない。
昔は、単なるイベント位に思ってた。海だと遊泳許可になる程度かと。ところが、少し登山に興味が出た事もあって、富士山に単独で登ろうとして判明した。7月1日で、バスの運行ががらっと変わる。7月1日からを夏季平常期と呼ぶようだが、言い方が微妙かも知れないけど、かき入れ時の運行スケジュールへ。思えば、海開きでも、海の家が営業を開始したりする。監視員の配置も、海開き以降だろう。
海や山でのバスなどの交通機関や宿泊や休憩の施設、それらに伴う色んな活動が、大きく変化するわけだ。設計とか開発だと、フェーズが変わるみたいなもの。
なお、今年の富士山山開きは、残雪の関係で延期になるかもとの情報もあった。しかし、雪かきなどで連年どおりだった。雪解けを待っての山開き日決定ではなく、一応7月1日を山開きと決めておいて、状況によっては延期するとの考えだ。（富士山の全ルートが、そうなのか/そうだったかは自信ないけど。）
プロジェクト管理でのスケジューリングには、タスク間の関係として、依存のあるものとそうでないものと考える。依存には前のタスクが終わってから次を開始するなどがある。非依存だと、開始日がばらばらで良い、あるいは該当タスクは予め決まった日に開始とのことになる。
富士山の山開きは、プロジェクト管理でのタスクと考えると、基本的に非依存となる。バスにしろ山小屋にしろ、7月1日開始。ただし、もし残雪が多ければ、雪かきがうまく行ってから、山小屋を開くのだろう。残雪が多いときには、雪かきなどのタスクが発生して、山小屋関連の大抵のタスクがスライドする。（バスの方の残雪との関係は、良く分からない。残雪が多くても夏季平常期のダイヤに移行するかも知れないし、雪かきを待って夏季平常期のダイヤになるのか？ 個人的には、前者のような気がするが。）
プロジェクトのスケジュールでは、イベントを特定の日にすることは少なくない。展示会のような外部の日程によるものもあるし、判定会議や記者発表のようにある程度融通できるものもある。スケジュール表では、どちらも特定の日にしてあるが、変更する/変更できる可能性があるものがあるというわけだ。それらを別文書にしておくとかスケジュールのタスクの情報に付記しておくことは有効と言える。
思うに、プロジェクトのスケジュールを期日一覧にして、タスク間の依存がほとんど分からない運用の所が多いようにも聞く。個人的には論外で、タスク間に依存関係があれば、それをはっきりさせておくべきだ。そうしないと遅延した場合の対応が効率悪い。また、他のタスクも遅延する旨の連絡や周知徹底の手間も、馬鹿にならない。
逆に、日にちの設定に幅がある場合は、それが分かるような情報を共有しておく方がよい。リスク対応としても非常に有効だ。暗黙知でも良いだろうが、重要な事は明文化していた方が良いだろう。今回の山開きなら、残雪が多いケース。
富士山の山開きで、ふとそんなことを考えた。
