PJの立ち上げ／計画重視（WF）⇔調整重視（アジャイル）／アーキテクチャ

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

WF型であっても変化に備えて「選択肢を増やすようにしておく」というのはけっこう大事だと思う。主に人材リソースと技術的な面でね。要員スキルの幅だったり、プロダクトの交換性だったり。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

会社の勉強会でプロジェクトマネジメントの話をしたけど「プロジェクトマネジメントとは何か」というので時間がかかってアジャイルまでたどり着かなんだ。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

計画重視型のプロジェクトマネジメントは計画力と調整力が重要ですが、両者とともPMの役割であり、つまりPMの能力に依存します。一方、アジャイルのような調整重視型では計測と調整を重視し、それはプロセスの中でチームが実施します。つまり、チームの能力に依存します。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

調整型のプロジェクトマネジメントは多要素が複雑に絡み合う探索的な状況において有効ですが、逆に計画精度が高められる状況で、要素が多いだけの煩雑な状況では有効に機能しません。例えばパッケージの導入のように手順が明確である場合。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

また、プロジェクトが混乱した状況にある場合は「PMの強引な調整」が求められるためチームが主体となるアジャイルでは、うまく乗り越えられないでしょう。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

計画重視型（ウォーターフォール〕と調整重視型（アジャイル）の違いについて幾つかの類型化が可能ですが、先ほどのツイートのように「PM重視かプロセス重視か」「煩雑なだけか複雑なのか」「問題解決を強引にすべき状況か漸進的な改善で行うか」という観点で考えても良いと思います。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

ドメインが安定してて、きちんとコミュニケーション（宿題を期限通りにやる、とか）できれば週1時間しか会わなくても要件定義はガンガン進むわな。逆にドメインが探索的なら常駐する勢いでやらないといけないし。プロジェクトって個性があって面白いもんだ。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

システム開発の立ち上げって、機能や業務を詰めるよりも先に、大きな目的や関係者との合意形成の進め方や導入計画を確認したほうが良いと思うんだけどね。飛び込む前に、飛び込み方や終わり方を考える。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

プロジェクトマネジメントの観点では、そういうシステム開発の「外側を埋める」っていう感覚が大事なんではないか。そう考えるとスクラムマスター的な要素に近いのかなぁ。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

アーキテクチャが決まってないのに見積もりが出てるって意味不明です。そもそもアーキテクチャの定義が曖昧なのにプロジェクト計画ができることが不思議でならない。何を根拠にスケジュールを作ったんだと。PMの前にアーキテクトが入らないって、いまだに常識なの？

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

最初にアーキテクトがスコープ設定、機能分割、作業分割（=WBS)ぐらいまでやってからじゃないと、PMがリソースの割り付け、見積もり、スケジュール化なんてできやしないですよ。対象を正しくとらえないのに計画なんか立てられないっつーの。

鈴木雄介/Yusuke SUZUKI @yusuke_arclamp

アーキテクチャ設計って「対象を構造的に明らかにし、そこに向かう方針を立てる」というだけですよ。対象が分かりきっているなら簡素でいいけど、そうでないならちゃんとやれ、と。それをやらないで、なんでプロジェクト計画が作れるのか不思議でならん。