プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ

プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきではないかと考えた。
考えがまとまっていないので、ラフなメモ。

【参考１】
日本型管理職はアジャイル実践の夢をみるか？. アジャイル時代のマネジャー育成計画 #1 | by Hiroyuki TAKAHASHI | WingArc1st Inc. | Medium

（引用開始）
PMBOKは、コストが開始時点で決まっていたり、成功条件がコスト・スケジュール・スコープの達成の場合にとても有効なManagement手段でした。
ソフトウェア開発を、内製よりも外注することが多い日本の企業では、コストははじめから決まっていることがほとんどです。
そんな背景もありPMBOKがスコープとする開始と終了がある「プロジェクト型開発」の考え方は、広く受け入れられました。
一方で、このことが日本におけるアジャイル導入の弊害になっていたかもしれません。
計画駆動でうまくいく「プロジェクト型開発」によって、昨今アジャイルがわかるマネジャーが少ない要因にもなっているのでは？と思うのです。
（引用終了）

PMBOKはPJ管理の基本を知るのに良い知識体系と思う。
日本のように、政府も企業も予算駆動で案件が動く場合ではとても有効と思う。
しかし、世界の流れは別次元で加速している。
おそらく、プロジェクト型開発の経験だけではやっていけない。

（引用開始）
PMI（PMBOKガイドを制定し世界的にプロジェクトマネージメントを広めている団体）もそこには気がついていて、PMBOKガイド第6版から「アジャイル実務ガイド」という冊子をリリースしています。
ただ、個人的には水と油感が否めず、別冊にしているのもPMBOKガイドに「混ぜ込めなかった」からかなと思っています。今後の進展に注目したいと思っています。
（引用終了）

昨今のSaaSのようなプロダクト型開発では、その考え方で全てをやり切るのは正直違和感があった。
PMBOKは確かにプロジェクトで駆動するPJ管理手法だから、始まりがあり終わりがある。
そこが一番のボトルネックなのかもしれない。

プロダクト型開発でPJ管理を行おうとすると、おそらく自然に、スクラムのような組織体制にならざるを得ないだろう、と直感している。
この理由付けは色々考えてみる。

【参考２】
なぜ大規模なシステム開発は失敗するのか｜最首 英裕｜note

（引用開始）
現行業務がわからない現状
さまざまな企業と話していると、自社の業務を正確に把握している企業は、実はほとんどないのだというのがわかってくる。
今や、業務のほとんどはコンピュータ化されている。なので、業務内容を理解することは、コンピュータの中でどのような処理をしているのかを理解することと同義となる。
でも、通常は毎日意識しないままコンピュータが動き、業務は進む。だから、わかっていたこともわからなくなり、自社の業務に関する知識はドンドン失われているのだ。
（引用終了）

今までのアナログの業務や作業をシステム化すると、ERPであれスクラッチであれ、現場業務の意図は失われる。
自動化されてしまって、全てが当たり前になってしまうからだろう。
ブラックボックスと化したシステムをリプレースする時に初めて、そのリスクに直面する。

（引用開始）
機能を足し算して複雑化するシステム
そして状況を悪くするのは、せっかく再構築するなら、欲しかった機能を色々と追加しようとする間違いだ。
使いやすいと感じるものは、大抵の場合、シンプルさと裏腹だったりする。
（引用終了）

どうしても日本人はカスタマイズにこだわる。
自分たちの業務プロセスに愛着があって、自分たちのプロセスにパッケージ製品やERPを合わせようとする。
しかもそのカスタマイズの要望は、ある一つの部門だけなのに、各部門の要望を集めて、それを実現してしまう方向に行ってしまいがち。
日本の要件定義の打ち合わせでは、総論賛成、各論反対になりやすい。

（引用開始）
インクリメンタル（プログラムはどんどん捨てる）
そして最も重要な４番目の要素が、インクリメンタルだ。
冒頭にも説明したように、開発しようとしている業務は、誰も全貌を理解していない可能性が高い。しかも将来を見据えた機能などという要素が出てくると、わからないことはさらに多くなる。
だからやるべきなのは、一度に大きな仕組みを作るのではなく、少しずつ完成に近づけていくこと。しかも、途中まで作ったプログラムを捨てながら完成させていくことだ。
（引用終了）

「途中まで作ったプログラムを捨てながら完成させていく」フレーズから、犠牲的アーキテクチャを思い出した。
一度作ったプログラムを全て捨てて、一から書き直す勇気も必要な時がある。

犠牲的アーキテクチャ～リプレースを正当化するアーキテクチャ: プログラマの思索

ITの地殻変動はどこに起きているのか～ソフトウェアの複雑さをどのようにして手なづけるか？: プログラマの思索

Martin Fowler氏の語る“犠牲的アーキテクチャ"

でも、SaaSでは犠牲的アーキテクチャは相当難しいと思う。
なぜなら、本番稼働中のサービスのシステム基盤を刷新してリリースするのは、並大抵の大変さではないからだ。
この辺りはどのように問題解決するのか？