スケジュールを引く上でのマインドセット
「スケジュールを引けって簡単に言うけど、スケジュールを引くには、スケジュールを引けと言った側も覚悟を決める必要があるんだぞ、ごらぁ」という個人の見解を書く
システム開発の管理に、曲がりなりにも携わるようになり、非常に憂鬱な作業の一つにスケジュール作成がある。憂鬱な理由は単純明快で、「意味がない」、無駄な作業だからである。より正確に書けば、「意味がなくなってしまう場合が多い」、という事で、意味を持たせるには、顧客・ベンダー含めプロジェクトに関わる全ての人間がある前提を満たさなければいけないと考えている。それは：
スケジュールを引くからには、そのスケジュールを死守する前提で、関わる全員が「（スケジュールを守るための）課題解決思考」で物事を考え、行動する
という事である。
言葉にすると非常に単純に、それこそ当たり前のように、聞こえるかもしれないが、この本当の意味を理解し、行動にも落し込めている人間は（自分の経験から推測するに）残念ながら実に少ない。
戦略コンサル時代もプロジェクトのスコープを決め、スケジュールを引く事はあったが、戦略コンサルが引くスケジュールは「なんちゃって」であり、ほとんど意味がない（こう断言しても、現役戦略コンサルも反論はないだろう、笑）。そもそも、細かいスケジュールを戦略コンサルが引く事はなく、引いてもざっくりしたものであり、かつ引いた本人も「翌日には変わるだろうな」と思っている場合が殆どだろう。
しかし、システム開発はやはりざっくりではまずく、特にウォーターフォール型の大規模な開発を進める際には、かなり精緻なスケジュール（≒WBS）に落とし込む必要が出てくる。
システム開発に限ったことではないが、スケジュールの引き方には大きく2つある
- エンドが初めから決まっており、そこから逆算して引く：
分かりやすい例で言えば、オリンピックのためのシステム開発が挙げられる。オリンピックの開催時期は決定しており、そこに向けて開発を進める必要があり、遅れる事は、この場合許されないのである - 積み上げ式で引く：
必要なタスクと、各タスクにかかる工数をすべて洗い出し、積み上げで引いていくという、よく用いられる引き方だ
重要な事は、2つあるといっても結局どちらも最終的には一旦エンドが決まる、という事であり（もちろん１はそのエンドを動かすことができないわけだが、、、）、決まった後は、本来「それをどう守るのか」に移行する。
そう、現実には、移行するはずなのだが、あたかも移行してないように振る舞うプロジェクトメンバーが実に多い事がストレスの種となる。「3回の議論で要件定義をしなければいけないと合意したはずなのに、いつまでも決めないプロジェクトリーダー」、「決めたはずなのに後から付け足してくる、よくわからない脇役」、「突然、前提が違うのでは、とちゃぶ台をひっくり返すことでしかプレゼンスを出せない偉いと思われたい人」などなど、実例を考えると枚挙にいとまがない。
スケジュールを引く、という事は、覚悟を決める、という事であり、その覚悟は一人一人共有する必要がある。という事で、スケジュールを引いて管理していく際に、自分が気を付けている事は以下である：
- スケジュールを引くリスクをそもそもちゃんと話す：バッファが詰まれるから結局長くなりがち、など
- それでもスケジュールを引くのであれば、全員が関わる場できちんとスケジュールを合意する：それこそ全員に手形を押させる、くらいの勢いで覚悟を突き付ける
- その後、スケジュールを管理していく際には、誰の責任でどうスケジュールに影響が出るのか、を明確化する：特に誰のどういった発言・行動で、という部分を曖昧にしない、相手が例え社長だろうが絶対に曖昧にしない、という事を徹底して、毎回各人の覚悟を確認し続ける
一方で、アジャイル開発というのは、ある意味「スケジュールを引かない」という逆転の発想のイノベーションだと思っており、できるだけアジャイル思想で自分は自分の人生も含めて管理していきたいと思っているのだが、それはまた別のエントリーで気が向いたら書こう。
