成功も失敗もわからないプロジェクト

僕がITベンダーに勤めていたころは
「XXX開発プロジェクト」や「XXX社向けXXXXプロジェクト」など後ろにプロジェクトと名の付く仕事が中心でした。
製造業に勤める今、ワーキンググループと呼び名の異なるプロジェクトが仕事の中心です。

プロジェクトとは、一回限りの繰り返しのない仕事である。
プロジェクトの定義はNASAやPMI(米国プロジェクトマネジメント協会)などで行われていますが、
いずれにも共通する要素をピックアップするとこのようになります。

- 有期性がある業務(期間が限定され、明確な開始と終了がある業務)
- 独自性がある業務(繰り返しのない1回限りの業務)
- 明確なプロジェクト目標の存在

しかしながら、今の方が圧倒的に成功確率が低いのです。
何故なのか考察してみます。個人的な意見です。

DXの設計書⑯ – ユーザーを味方につけよ

ゴールや目的が「XXシステムを構築する」になっているケースをよく見かけます。

手段が目的になってますが大丈夫ですか?

程度の差はあれど、システムやソフトウェアは秩序やルールに従わせるものです。
人にはそれぞれ価値観があり、そぐわなければ秩序もルールも煩わしいだけです。

何の縛りもなく自由にやれてたユーザーはストレスを感じます。
ユーザーにとってシステムの導入はストレスです。

DXの設計書⑩ – 機能一覧を作成せよ

機能一覧が出来上がると途端にプロジェクトの見通しがよくなります。

これまでに集めた情報を機能一覧に凝縮させましょう。
カッコいい漢字が並んだXXX機能とかいう漢字だらけの曖昧なものではなく、
「~をする機能」ときちんと動作がイメージできる内容を記載して一覧をつくります。