スケジュールを決める時にどうするか

スケジュールを決める際に、ウォーターフォール開発とアジャイル開発の側面からの決め方があると思う。
どちらがいいかはその時々によるが、納期、工数、メンバーのレベル、実現可能性、目標等を元に考えるのがいいのだと思う。

不確実性を扱いたくないウォーターフォール

ウォーターフォールについて軽く触れておく、

ウォーターフォール開発の骨子は、プロジェクトの立ち上げからソフトウェアの開発までの「ソフトウェア開発ライフサイクル（SDLC: Software Development Life Cycle）」を複数の工程に区分し、上流工程から下流工程へと順番に進めていく点にあります。

ウォーターフォールの考え方は下記のような感じ。よくV字モデルで語られることが多い。

実装工程：要件定義　ー＞　　外部設計　ー＞　内部設計　ー＞　実装
テスト工程：単体テスト　ー＞　結合テスト　ー＞　システム/受け入れテスト

左側の開発フェーズは、それぞれのテストに対応している。

要件定義　ー＞　システム/受け入れテスト
外部設計　ー＞　結合テスト
内部設計　ー＞　単体テスト

実際には大規模なWEB開発において複雑性が増しているので、各レイヤで求められるスキルももちろん増大しているし、不確実性ももちろん高くなる。だいたいそうなるとスケジュール通りには行かずに炎上して同じことを繰り返すようになる。昨今の開発において運用するにはかなり求められるレベルは高くなる

なぜうまくいかないのか

実行したタスクに対してのスケジュールやタスク自体に関して検証をしないから
お互いの合意形成が圧倒的に足りていないから

だと思う。

本当のウォータフォールが成立する組織ってなんだろう

この考え方は各レイヤにおいて、本当のプロフェッショナルな組織でないと実現が不可能に思える。（もちろん簡単なアプリケーションなどでは可能かもしれない。）
そうでなければ実装の漏れや不確実性に対しての対処が後手に回り、技術的負債、納期に苦しめられる。

ウォーターフォール開発においては以下が重要だと思う。

各レイヤにおける明確な定義、合意
できる限りの不確実性が排除された工数管理
各レイヤにおける数字の見える化（上流であれば流入バグ数、下流であれば流出バグ数など）
起きた問題に対してのトレーサビリティの管理

様々な方法で工数を算出する方法はあると思うが、その組織においての工数を測るには仮説検証しかない。
これがそもそもできない組織の大規模開発は破綻、収束するまで地獄のような時間をかけるしかない。

つまり大規模開発というのは安易にできるものではない。

アジャイルをどのように活用するか

アジャイル開発宣言で語られている事項として下記がある。

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

なるべく「価値」のあるものに関して、きちんと開発者、顧客に合意できる形の成果物にして合意することこそ大事だと書いてあるように解釈している。アジャイルにも仮説と検証が必要であり、スクラム開発の考え方と一致している。

たとえば以下のような開発のスケジュールだとどうだろうか。（かなり簡略にしている。あくまで考え方の話）

タスク	10/1	10/2	10/3	10/4
要件定義	○
外部設計		○
内部設計			○
実装				○

この場合に確認したいことがいくつかある。

なぜ各タスク1日で終わると思ったのか？（根拠）
1日で終わるとして、各レイヤでどこまでやることをゴールとするのか？（目標）
もっとタスクを分解してフィジビリを高められないか？（実現可能性）

これで根拠がそもそもない、ミスリードな根拠を提示すると、そもそもスケジュールを引く意味はない。
（それやるぐらいなら手を動かせ、となってしまう。）

「自分が思う観点と、他人が思う観点の議論と認識合わせ」
「実現可能性に対しての仮説と検証」

これらが工数やスケジュールを引く時に大事なポイントだと思いました。

・自分や相手にとって、どこまでできたら価値があるのか？
・相手や他の人にとって、できたものに関して合意ができるのか？
・その価値を届けることができると思った根拠は？

これらを確認するタスクをフローとして乗せていきたいですね。