そのプロダクト作りの「進め方の仮説」は立っているか？
「スケジュール」というものを再考してみよう。スケジュールは必要だろうか、それとも不要だろうか。
スケジュール = 役に立たないもの
あまりスケジュールに良い印象を持っている人は少ないかもしれない。過去の体験から「厳しい締め切り」「終わりの見えないタスク」などを思い起こすからだろうか。あるいは、スケジュールによって仕事の進め方が固定化されてしまい、かえってやりにくさを感じるからだろうか。
ひとたびスケジュールを細かく記述したところで、やっていることが変わることがあるからムダになる。むしろ、詳細さが仇となり、メンテナンスに苦労することになる。そんな意見もありそうだ。
スケジュールがなかったら何が困る？
では、スケジュールが一切なかったら何が困るだろう。いつまでに仕事を終えれば良いかが見えなくなる。明確な「締め切り日」があるわけではない仕事であっても、たいていの場合「いつ頃には終えたい」という期待は存在するだろう。そうした期待を不用意に踏み抜きそうになると、いきなり燃え始めることも多い。「終わるのものだと思っていた」「次の段階で考えていることに影響が出てしまう」「絶対に終えてほしい」云々。
スケジュールがなければ「力の入れ加減」も見立てられなくなる。半年の仕事があったときに、常時最高潮というわけにはいかないだろう。最初から最大出力では早晩息切れしてしまう。山場をどこに作るか。人間が仕事をする以上はメリハリが必要になる。
もう一つ。スケジュールが見えないと、「進め方」も見えなくなる。何を目指して、どういう段階を刻みながら進めていくのか。
単純な仕事であればよいが、タスクに並行して取り組まなければならなかったり、複数人で認識をあわせながら進める必要があるとしたら、ある程度の先も含めて、どう進めていくかの「目論見」が無ければ分かりにくい。
もちろん、この目論見を半年一年分と、みっちり詳細に書き出し始めると、目論見が変わるたびに「無価値なメンテナンス業」に苦しむことになる。半年一年先までの道筋をあらかじめ予言できるほど単純な仕事をやっていない。
だから、アジャイルなんでしょ？
だから、アジャイルなんでしょ？ スプリント単位の仕事の進め方を取れば、ムダなスケジュールなんて引かなくて済むんでしょう？ と思われる方はいるだろうか。
そう、スプリントの運営によって、一年先まで見越した予言書を書かなくはなる。しかし、先に述べた「進め方」はやはり見えないままだ。
「1-2スプリント先まで見越せば十分。一寸先は闇なのだから、その時その時に考えるで結構」というほど不確実な仕事でもない。泥棒を見てから縄を編み始めるようなスタンスでは、後手に回りすぎて現実的ではない。
ゆえに、アジャイルに関するメンタリングを行いながら、一方で、「線表を書きましょう」と言うことになる。アジャイルと線表？ 何となく不審に思うのも無理はない。「スケジュール」を「線表」のような別の言葉に置き換えたところで、お茶濁しの範疇に過ぎない。
本当のところスケジュールで何を表したいのか？
あらためて「スケジュール」で何を表しているのか、考え直してみよう。
3つある。目指す状態、やるべきこと、期限。やるべきことと期限、この2つは自明だろう。残りの1つ「目指す状態（ステート）」とは何だろうか。例えば、プロダクト作りを行うならば、みんなおなじみPSF / PMFという状態達成を目指していくことになる。
目指したい状態とは、ある目的を果たすために必要な前提であり、たどり着きたい中間地点であり、本質的な進み具合を担保する目安といえる。これが無ければ、何をどう進めていけばよいのか、タスクも立たない。闇雲に進めることになる。
「とりあえずやってみる」精神で延々と広がる不確実性の海を泳ぎきろうというのはあまりにも無謀だ。目指す状態、ステートを海に浮かんだ「ブイ」のように、手がかりとしよう。
実際には、このステートがあいまいになっていることが珍しくない。こういうスケジュールはあまり役に立たない。
さらに、想定による「やるべきこと」の緻密な洗い出しによって、スケジュールはどうしようもない存在になっていく。
まともなスケジュールを立てるためには？
さて、状態とやるべきことを捉えるためには、ナレッジが必要になる。当たり前のように用いているPSF / PMF も、「伝統的なソフトウェア開発」におけるフェーズ定義に関しても、またそのために必要なる具体的なタスクの洗い出しに関しても、ナレッジがあるから認識し、書き出すことが出来る。
リファレンスするナレッジ、知識体系の有効性を判断するのはもちろん進め方を組み立てる自分たち自身になる。上手くいかないからといって、PMBOKや、V字モデル、スクラムにただ八つ当たりしていても学びは少ない。該当するリファレンスがフィットする仕事、状況だったのか。まさしく、PSFよろしく使う側が整合を判断しなければならない。過去より積み上がってきた知見というのは実際のところ、妥当性があり、相当強力である。どんなナレッジであっても、そうそう伊達ではない。
手元はスクラム、展望は進め方仮説で
では、実際どのように運営すれば良いのだろうか。次のようなイメージになる。
日々の営みはスクラムで行う。日々とは最も変化に富み、不確実性の最前線にあたる。ここにスクラムを適用することには多くを語る必要はもはやないだろう。関心は、状態と期限に関してだ。
ステートにどのようにして辿り着くのか、その流れを可視化する。この流れはあくまで目論見であり、「仮説」だ。課題仮説やソリューション仮説を仮説キャンバスで立てるように、「進め方の仮説」にあたる。仮説ということは、検証によって（進んでいく展開によって）、その検査と適応が必要ということだ。固定化し、守り抜こうとする対象ではない。
進め方仮説を変える、適切なタイミングを見出すために「むきなおり」する機会を設けるようにしよう。