こんにちは！コンビニや飲食店などで顔を覚えられてしまうと、途端に恥ずかしくてその店に行けなくなります！中薗と申します_(:3」∠)_
先日、近所にあるラーメン屋に行ったら「あ、いつもありがとうございます！から揚げ定食ですか！？」みたいに話しかけられて、リアルに「あ、あああああ、あああ」みたいな挙動不審なリアクションを取ってしまいました。
急にフレンドリーに話しかけられるのは、コミュ障であるわたしにはつらいのです←_(:3」∠)_

さて、今回はプロジェクトのプランニングにおいて非常に重要なフェーズである、「スケジューリング」について話を進めていきたいと思います

さて、読者のみなさんは「なぜスケジュールを作成するのか？」と問いかけられたとき、どのように答えるでしょうか？

プロジェクトの各作業の順序を明らかにし、プロジェクト全体の所要時間を算出するため？上司にプロジェクトの進捗状況を説明するため？さまざまな答えがあるかと思います。
しかし、今までの経験の中で当初の予定通りに進捗したプロジェクトがどれほどあったかを思い浮かべてみてください。
おそらく、片手で数えられるほどしかないのではないかと思います。

詳細にスケジュールを組んだところで、結果はその通りに進捗しないのであれば、なぜ時間をかけてまでスケジュールを組むのでしょうか？その理由はいったいどこにあるのでしょうか？

その答えを出すには、「スケジューリング」というものに対する発想の転換が必要です。
それは、「立てたスケジュールはたたき台である」という意識を持つということです。

スケジュールを非現実的な青写真にしないためには、スケジュールを構成する各要素の不確実性の度合いを認識し、シミュレーションによって不確実性を解消･軽減するための問題解決をすることが必要不可欠です。
発想を転換するとは、立てたスケジュールとはそのシミュレーションを立てるための「たたき台」として存在するのだという認識を持つことです。
つまり、スケジュールを立てていくプロセスの中で、各作業を実施するうえでの技術的制約、時間的制約や前提、作業実施に必要なリソースを活用する際にネックになる事柄などが洗い出せなければ、そのスケジュールは「作っただけでなんの役にも立たないもの」になってしまいます。

それでは、そうした制約や前提上の問題はどのようにして洗い出していくべきものなのでしょうか？
次回明らかにしていきましょう。

それでは、またっ！_(:3」∠)_

【関連記事】
サーバの冗長化について①
サーバの冗長化について②
ロードバランサについて
負荷試験について
プロトコルについて①
OSI参照モデル①
OSI参照モデル②
OSI参照モデル③
プロジェクトマネジメントの手法①
プロジェクトマネジメントの手法②
プロジェクトマネジメントの手法③
プロジェクトマネジメントの手法④
プロジェクトマネジメントの手法⑤
プロジェクトマネジメントの手法⑥
JavaScriptのテストフレームワーク