-
「Scrapboxがプロジェクトマネジメントに使えない」はFalse
- Scrapbox自体の開発プロジェクトはScrapboxで行われているから
-
「Scrapboxがプロジェクトマネジメントに適しているか」はプロジェクトマネジメントの定義不明瞭
- プロジェクトマネジメントの一般的な教科書であるPMBOKに従うなら、プロジェクトマネジメントは
- プロジェクトを所定の時間で完了するようにマネジメント
- プロジェクトを承認済みの予算内で完了するためのマネジメント
- プロジェクトに必要な資源を特定し、獲得するマネジメント
- などを含む概念
- Scrapboxの開発プロジェクトは、少人数で、明確なデッドラインなく実行されているように見える
- PMBOK的な意味でのプロジェクトマネジメントの実例とは言い難い
- プロジェクトマネジメントの一般的な教科書であるPMBOKに従うなら、プロジェクトマネジメントは
で、PMBOK的なプロジェクトマネジメントにScrapboxが向いているかどうかはさておき、 「Scrapboxの開発」的な、少人数で明確な締め切りなく長期的に行う自社開発のプロジェクトにおいて、 もしかしたらScrapboxでマネジメントするのはすごく向いているんじゃないか、という気がしている。
Scrapbox型マネジメントが第三勢力の可能性
- PMBOKは割とウォーターフォール的要素が強い
- 「ウォーターフォール⇔アジャイル」という対立構図で捉えると、Scrapboxの開発プロジェクトはウォーターフォールではないからアジャイルってことになりそうだけど、いわゆるアジャイル手法とも違いそう#誤った二分法
- イテレーション、ベロシティ、などのタイムプレッシャーに対して否定的な立場を取っているように見える
- /shokai/タスクを効率的に処理していくと高速にクソアプリを実装してしまう
- ドラッカー曰く「知識労働者の生産性は計測できない」のだが、アジャイル手法はそれを計測し管理しようとする
「何を作るべきか」
- 作るべきでないものを効率的に実装しても意味がない
- /shokai/タスクを効率的に処理していくと高速にクソアプリを実装してしまう
- Scrapboxを使ったソフトウェア開発のマネジメントは「何を作るべきか」の決定にとても有用である可能性がある
- こうやる