アジャイル（カンバン）の好きなところ、ウォーターフォールの好きなところ

カンバンが好き。ガルパンじゃないよ。カンバンのどんなところが好きかというと、

work in progress　が可視化できるところ。

メンバにタスクをアサインした紐付けと負荷と納期が頭の中で整理できているプロジェクトマネージャなら起きないんだけど、ついついプロジェクト内での最適化をし過ぎてしまうとできるメンバにタスクが集中してしまうんだね。

それって結果的にアウトプットがプアになったり全然できていなかったりとなってしまうことが起きるんだけど、そうにならないようにプロジェクトマネージャが自分自身でタスクの割り当てをボードを見ながらコントロールできるから。

１つの情報を全員で理解できるところ。

ミーティングでもなんでもPCが一人１台ある環境だから各自が自分のPCの画面の中で興味あるところを見ている。つまり、誰が何に関心を持っているかが実は誰にも共有されないということ。

ホワイトボードにタスクを付箋紙で貼ることで全員がそれを見る。ホワイトボードでWIPが可視化されることで誰のタスクが遅滞しているかが明らかになるので誰かが問題を抱えていることに気づける。

チームとしての機能を発揮できるところ。

タスクをベースに気づきが得られるから、タスクを解決しようと問題解決の力学が働く。人を問題にせず、問題を問題として扱うことになり問題VSメンバの構造ができるように変わっていく。

このループが回り始めると、チームとして機能するようになるんですよ。頭数があっても問題を共有して解決しようする機能が働かない限りチームとは呼べないもの。

ウォーターフォールだって好き。それはすべての基礎であるから。

シナリオを考えるところ。

時間軸が未来になる分だけ不確実性は高くなるけれど、不確実性を受けれた上でプロジェクトのシナリオを考え思いつくケースからリスクを識別するところが醍醐味なわけで。

不確実性が極小でやることが決まりきっているならそれはプロジェクトではなくオペレーションだし高度なエンジニアリングは不要なわけです。言い方を変えれば、必要なスキルはエンジニアリングとして定義できるし育成も量産可能であるということ。

そういう工場的な生産も必要かもしれないけれど、プロジェクトであれば後者はプロジェクトの定義から外れるわけです。

現状ではすべての基礎であるところ。

成果物を作成する作業を分解して作業を遷移する手法を採用する時点で、ウォーターフォールがその根底にある。アジャイルだって、作業を分解して短時間でタスクを遷移する。ウォーターフォールの概念が理解でき、いいところ、悪いところを身を以て知っていればわかることかと。

これは今のシステム開発手法が今作業をしている自分が要件から成果物に直接変換できない時点で逃れることはできない。たとえ後工程を要件を整理した自分がやるとしても未来の自分がやるのであれば検討の経緯を残さなければ正しく伝えることができないのだから。ましてや頭脳が違う他人であれば言わずもがな。

ウォーターフォールをdisる人がいるけれど、ちゃんとウォーターフォールを自分でやった経験があるなら好きに言えばいいと思うけれど、できもしないで好き嫌いを言っているなら単なる食べず嫌いでしょ。当たり外れあるけど割といけますよ、ウォーターフォール。