プロマネ（目的達成まで進める）で考える順序

背景

制約条件は考える範囲を狭めます

期限近すぎるのであれば「自分で肌感持って進める」を排除できるし

期限が明確で技術力が必要ならば、「自分が進める」よりも「社内交渉してResource確保」が大事になる

自ずとやることが決まるので「制約条件」は有用

自らに問う時の大事なところ

制約条件の強弱を見極めること。「Must」と「Should」と「Better」は違う

Mustから順に狭めていく

最悪Shouldは無視していい

背景

「やらない可能性がある」のであれば、その可能性を潰しておくこと

モチベーションのために。

今からカオスな状況に飛び込むときは、「退路を断つ」ことで自分を震え立たせる方が良い

カオスな状況。退路（やめてもいい）があると、そこに逃げちゃいそうになる

何より…進捗が悪いと報連相しなくなっちゃう

さらに高等テクとしては

どんな時も「やる前提」で考える方が良いアウトプットが出る

NPで足りないのは技術/方法論。

Why＋What＋How。いずれも高品質じゃないと良いアウトプットでない

世間一般ではHowが重視されがちなので「Why（目的から考える）」「What（どのプロジェクトから手をつけるか考える）」が大事

NPはWhy, What考えすぎているのでHowが大事。

「やる前提」で考えるとは、「やるとなった時の方法を一度検証してみる」ということ

検証しないと「その手段を使えるか」がわからない

（本来は、PMBOKにおける「立ち上げ」Phaseで検証まで行うのがBest）

NPでは「やれるか分からないからその方法をとらない」というProjectがよく起こる

背景

制約条件の一具体として「Resource」を考える

特に大事なのはNaturaの「経営視点」と「業務遂行」

経営視点を補ってくれるメンター or 併走者はいるか？

業務遂行を補ってくれるメンター or 併走者はいるか？

背景

最低品質が見えると「そのレベルを達成するための方法」が見えてくる

例：

データ移行ミスが少しも許されないならば、厳格なETL処理が必要になる

ETL処理の成功可否をCheckするsoftwareを準備することになりそう

移行ミスが許されるならば、雑な連携ツールでOK.（例：AppFlow）

さらに高等テクとしては

「最低品質」「制約条件」「使えるResource」が見えたところで、その3つのバランスを見る

最低品質を下げられたら、他2つがうまくいく？

経営陣に交渉して制約条件を解除できたら、今のResouceでもなんとかなる？

品質と制約条件が変えられない？ならば、その情報をもとにResourceを調達に行くのだ

この3つは全部が理想の値になることはないので、その時の会社/team状況を見てバランスをとりに行かないといけない