ミッションの再設定へのフィードバック
解領域を検討しプロジェクトのソリューションを深く検討していくと、再設定したミッションとCＩ やBＩ の間で違和感が生まれて来る場合があります。このように上位の概念から順次概念を紡いで考えていくと、上位だった概念に疑念を持つことは様々な場面で発生します。
例えば解領域の検討において、当該プロジェクトを統括するマーケティング上の判断で、取り扱い製品のカテゴリー幅を広げるという製品ドメインの拡大が採用されることも考えられます。これなどはプロジェクトで当初に決めた解領域よりもプロジェクトの次元を上げることになります。このように新しい製品群を構成している概念がミッションの範疇に収まっていない場合は、解領域の再検討を行うか、ミッションの再々設定を行うかを検討します。
プロジェクトはその求めている解を得るために、いままで所与の条件の整序やフィジビリティスタディ、ミッションの再設定、解領域の決定、と順を追って検討しますが、各プロセスでの検討次第では前プロセスへ戻ることがあります。そしてこの手戻りを躊躇してはいけません。ミッションの再設定へフィードバックをかけて修正し、場合によってはフィジビリティスタディの追加検討を行う場合もあります。
プロセスとは手戻りを少なくするために仕事の順序を決めることですから、「プロセスの手順を説明しながら、手戻りを躊躇するな」というと矛盾しているように感じると思いますが、「より良いプロジェクトの解」を求めるのであれば、検討が進むにつれ外的要因の変化や所与の条件の変更、または検討の甘さなどにより手戻りをしなければならないことも認める必要があります。
「より良いプロジェクト解」とは、より高い次元で解を得るための発展的な考え方です。ですから発展的な手戻りは推奨します。しかし、一度設定した解領域が難しいからといって、もっと簡単な解領域にしたいので戻るといった、難しさから逃げるための手戻りは避けなければいけません。
またフィードバックをかけるということは一つ前の段階に戻ることだけでなく、場合によっては更に遡上してBＩ 、CＩ という企業戦略の根幹へフィードバックをかける必要が出てくることもあります。
それはデザインを検討しソリューションを提案するなかで、ソリューションが元々課題としていた問題の次元を超え、さらに高次の課題を解決していることを示す証左となり、本来は歓迎されるべき提案です。
このような提案はデザインのちからで、プロジェクトのソリューションを生み出すことができるデザインの最大の魅力でもあります。
しかしプロジェクトを実行する上でこの手戻りはとても嫌われます。開発スケジュールが遅延する、リソースを浪費した、などいろいろな影響が心配されるからで、この課題の解決するにはプロジェクトを中断または中止して、新たなプロジェクトを立ち上げ直す決断が必要であり、最も悩むポイントです。
新たなプロジェクトの再構築は大変です。前にも増してプロジェクトへの熱量を高めてスタッフやステークホルダーを説得するしかありません。私もプロジェクトの手戻りを自身で起こした経験を何度かしています。その度に関係者を説得しましたが、そのとき効果があったのはプロジェクトについて誰よりも深く広く考えたという事実と、成功させたいと思う熱い気持ちを誠実に説明する姿勢です。これらもスタンスの整序から始めた本ログに記した内容を準備しておくことで可能になりますので、個々のプロセスをしっかりと考え記述しておきましょう。
製品開発決定
以上の段階を経て、プロジェクトに於ける最適な解領域が確定します。
このログでは製品開発を行う際のデザインを決めるディレクションのノウハウを記述することが目標ですから、ここでプロジェクトの最適解は製品開発に決まったということにします。製品開発以外のソリューションについては別途記していきたいと思います。
製品開発決定までに至るプロジェクトの準備プロセスのステップは、どの項目もとても大切ですから、プロジェクトを開始する前にしっかりと検討して、関係者と共通認識ができる状態まで議論しておきましょう。
ではまた！
コメント