久しぶりに、プロジェクトマネジメントのことを書こうと思った

あるスライドを見ていて、久しぶりにプロジェクトマネジメントのことを書こうと思った。

エンジニアのイメージとして、従来型のシステム開発（要はウォーターフォール）は、

『顧客が忘れた頃に、

顧客がやりたかったことかどうかは別にして、

システムを提供する』

と刷り込まれているのではないだろうか。

その対極にある今のデリバリの考え方（要はアジャイル開発）は、

『最優先にするのは顧客満足で

価値あるソフトウェアを

継続的に、早く届ける』

とやるわけだ。どっちがいいかと聞かれれば、誰が判断しても後者の方が良いと思って選ぶだろう。

ところで、

『顧客が忘れた頃に、

顧客がやりたかったことかどうかは別にして、

システムを提供する』

の『顧客がやりたかったことかどうか』をプロジェクトの上流で、やりたいことを顧客自身に考えてもらうことで、顧客が忘れた頃にシステムを提供するということにしない、ということをやっていた。

従来のように、実際に触れるシステムが先になると顧客は

『先になってからやりたいことを考えればいいことを経験的に知っている』

ので、プロジェクトの頭から自分のリソースは割かないし、意思決定をしない。こうなてしまったのも、それまでそれでよしと刷り込んできたSIerなのだが。

顧客がシステムに満足するかどうかは、顧客自身が業務の中でどこの部分を電子計算機を用いた自動機械化を行うか、業務を理解し、自動と自働を使い分ける思想を持っていなければならない。

言い換えれば、プロジェクトの最初から、本気でリソースを割いてもらい、何をするのかをエンジニアと共同で言語化しなければならないということである。

上流にも関わらず、顧客が業務を考えながら検証できるPoC環境を準備しなければならないから、こちらのエンジニアは大変だし、顧客自身も業務フローを準備したり、業務関係者に駆け回って調整したりと大変である。

それでも、ハリボテでも実際に動くソフトウェアを目の前にすると、顧客は真面目にやってくれる。

従来のシステム開発のイケてないところは、顧客もSIerもプロジェクト立ち上げからマジでリソースを投下せずに面倒臭いことを将来の自分達に先送りしていたからじゃないのか。

もちろん、全部のスコープに対してこれをやる必要はなくて、やばいところだけやればいい。そうしないとハリボテで実質全部を作ってしまうことになるので。それだったらプロトタイプのシステム開発を採用すればいい。

どんなシステム開発手法（ウォーターフォールもアジャイル開発も開発手法だ）を採用しても、最初からマジでやればいいだけ、と思うのだが。