プロジェクトを始める際に、まず何を考えればよいのか
プロジェクトを始める際に行うべきことの1つとして、「プロジェクトをどのように行っていくか」という計画（プロジェクト計画書）の策定があります。そこでは、プロジェクトの目的は何か、実施内容は何か、それをどのようなスケジュールで行っていくか、体制・コストをどうするか、コミュニケーションはどのようなツールを用いてどのように行うかなどが言語化されますが、プロジェクトを始めるタイミングで重要なのは、プロジェクトが始まってしまうと問い直されにくい前提を確認することだと考えています。
誰しも、プロジェクトが動き出してしまうと、どうしても目の前のタスクに追われてしまい、本質的な視点を失ってしまいがちになるため、「そのプロジェクトとして確認しておくべき前提や本質的な論点・問い」を共有しておけるとよいのではないでしょうか。
本記事では、プロジェクトを始める際に考えるべき点として、私が大切にしている以下の3点について検討します。当然、下記以外にも重要な視点はあるかと思いますので、みなさまの組織・プロジェクトに合うものをご検討いただくためのたたき台としてお使いください。
Why：「なぜ、なんのためにそれをやるのですか？」と問うこと
Agility：プロジェクトの不確実性に向き合うーー主体的に変化し続けるための準備
Learning：成長し続けるためにチームとして学習しようというマインドを揃える
なお、「プロジェクトの開始時にやるべきこと」は、プロジェクトが始まった後にはやる必要がない、というものではありません。仮に開始時に行うことができなかったのであれば、プロジェクトが始まったあとのタイミングでも行うべきことであると考えています。すでに動いているプロジェクトにおいても、プロジェクトを見直す観点として参考にしていただければ幸いです。
Why：「なぜ、なんのためにそれをやるのですか？」と問うこと
・ゴールのWhy：なぜ、なんのためにそれをやるのだろうか？
・役割のWhy：私たち（もしくは私）が関わるべき理由は何だろうか？
まず何より大事なのが、なぜ、なんのためにそれをやるのか、なぜ私はそのプロジェクトに関わるべきなのかという理由（Why）を問うことです。
なぜなら、「Why」が明確になっているか、腹落ちしているかということによって、同じ目的（Goal）であっても、プロジェクトに対する向き合い方やモチベーションが全く変わってくるためです。
やるべき理由・関わるべき理由の納得感があるからこそ、プロジェクトは良いものになっていきます。逆に言えば、自分が関わる理由が見いだせないのであればそのプロジェクトに積極的に前向きに関わろうとは誰も思えません。何より必要なのが「Why」です。
「プロジェクト計画書」などのドキュメントを作成する際も、何よりもまず、「なぜ、なんのためにそれをやるのだろうか？」というWhyを言語化するようにしていただければと思います。もしすでに「プロジェクトの目的」が明文化されているのであれば、「なぜ、その目的なのか？」と、もう一歩Whyを問うことをおすすめします。
状況によっては、「やると言われたからからやるしかない。理由なんか考えても意味がない」というケースもあるかもしれませんが、そのような場合でも、そのことをプロジェクトチームとして共有すること自体に価値があります。「Why」は、必ずしも長期ビジョンのような高尚なものである必要はありません。「Whyのレベル感」は脇に置いて、まずはプロジェクトメンバー間で「Why」を確認するようにしましょう。
組織の文化によっては、このようなことを問うことが、上司から「生意気な態度」だと捉えられてしまい、言いにくいこともあるかと思いますが、仕事の質を高めるためには不可欠な振る舞いです。上司のあるべきスタンスは、Whyを問われることを「生意気な態度」だとするのではなく、部下がWhyを理解しているかどうか・腹落ちしているかどうかをフォローすることであり、部下に依頼する際にも、Whyが伝わる言葉を丁寧に選択する必要があります。
Agility：プロジェクトの不確実性に向き合うーー主体的に変化し続けるための準備
・状況に合わせて変化していくためには何が必要だろうか？
・変化が必要となる場合の「兆し」をなるべく迅速に把握するためには、プロジェクト内のコミュニケーションをどのように設計したら良いだろうか？MTGでは、何をしたら良いだろうか？
2点目は、プロジェクトの不確実性に向き合うために、主体的に変化し続けるための準備をしようというものです。
ゴールが明確なプロジェクトであっても、その途中では様々な問題が起こり、軌道修正が必要となる場面は必ず起こるものです。ゴールそのものを自ら定義するようなプロジェクトでは、なおさらプロジェクトの不確実性が大きくなります。
このような状況においては、不確実性をネガティブなものとして捉えずに、むしろ、より良いプロジェクトに変化していくためのきっかけのようなものとしてポジティブに捉えることが重要です。つまり、不確実性は必然のものであり、そうであるならば、不確実な状況になった場合には、プロジェクトの状況をより良いものにしていく契機として生かしていこうということです。
そのために必要なのは、主体的に変化し続けるための「仕組み・環境」を設計したり、そのためのマインドや共通認識を持つことです。「状況に合わせて変化していくためには何が必要だろうか？」「変化が必要となる場合の「兆し」をなるべく迅速に把握するためには、プロジェクト内のコミュニケーションをどのように設計したら良いだろうか？MTGでは、何をしたら良いだろうか？」ということをプロジェクト開始時に問いかけて、それぞれのプロジェクトに合った仕組みを検討しましょう。
個人的には、プロジェクト開始時に「スピードを早める」ことの共通認識を持てると良いと考えています。不確実であるということは、我々が取り組んだことがどのような結果になるか予見しづらいということです。そうであるならば、たとえば何かをアウトプットする場合にも、作り込んだアウトプットを期限ギリギリに共有するより、手書きのラフなイメージを今すぐに共有した方が、すぐにアウトプットを検証できるという点で不可欠のアプローチだと考えています。そのような動きをプロジェクト全体として実施していくために、プロジェクト開始時に「ラフでも良いのでスピーディにアウトプットをして、仮にズレていた場合にも早く気づけるようにしよう」という認識を共有できると良いのではないでしょうか。
Learning：成長し続けるためにチームとして学習しようというマインドを揃える
・プロジェクトをより良いものにしていくために、我々・私はプロジェクトから何を学ぶべきだろうか？
・今回のプロジェクトからの学びを次のプロジェクトに生かしていくために、どんなナレッジをどのように残しておけるとよいだろうか？
・ナレッジを気軽に残しやすくするためには、どうすればよいだろうか？
3点目は学習・ナレッジ蓄積に関することですが、これらのテーマについて、どのような印象をお持ちでしょうか。多くの方が感じられているのは「重要なのはわかるが、今やっている場合ではない」というものではないかと思いますが、個人的には、そうであるからこそ、「短時間で良いので、可能な範囲で取り組む」ということをおすすめしたいです。
学習もナレッジ蓄積も、一度の取組で完成するものではなく、継続的に行いつづける必要があるものです。十分な時間を確保しても一度で終わってしまっては意味がなく、少しずつでも良いので継続することの方が望ましいと考えています。
たとえば、1分間だけで良いので、以下のようなことに取り組んでいただければと思います。
・今から1分間で、このプロジェクトで学びたいことを書く
・今から1分間で、先週このプロジェクトから学んだこと・気づいたことを書く
・今から1分間で、「もう一度このプロジェクトを行うのであればどうしたいか」ということを書く
まずはこれだけで十分です。
しかし、これらを行うだけで、本記事の2点目で言及した「プロジェクトの不確実性に向き合うーー主体的に変化し続ける」ということが実現しやすくなります。
プロジェクトで失敗することが問題なのではありません。失敗したことから学ばずに、同じ失敗を繰り返してしまうことこそが問題です。目の前のプロジェクトをうまく進められていないのは、もしかしたら、以前のプロジェクトで、適切に学習したり、ナレッジを残してこなかったからかもしれません。だとするならば、目の前のプロジェクトから、チームとして学び、学んだことはナレッジとして残しておきましょう。
最初から、完成度の高い完璧なナレッジにする必要はありません。まずは「一言メモ」でも良いので、「次に同じようなプロジェクトをやるのであればこうしよう、このあたりに注意しよう」というような「未来の自分へのメモ」を残しておきましょう。個人個人が小さなナレッジを残していくことが、結果的に、チーム全体にとっても大事なナレッジに育っていきます。最初から完璧なものを完成させようとせず、「少しずつ育てていく」ということを大切にしてください。
プロジェクト開始時には、まずそのような思いを共有した上で、「学習やナレッジ蓄積を行っていくために、どのようなことをすればよいだろうか？」「1分間でも実施できることはないだろうか？」ということを検討いただければと思います。
この記事を書いたひと
プロジェクトファシリテーター、プロジェクトコンサルタント。
プロジェクト・組織の推進をPMとして関わりながら、プロジェクト・組織の未来に必要なナレッジ・知を言語化するサポートをしています。 対象分野は民間企業のDX領域が中心となりますが、シンクタンク・パブリックセクターでの勤務経験から、公共政策の立案・自治体DXに関する業務も担当しています。
※本記事は、COPILOT BLOG に書いたものの転載です。