日記475
・パリ政治学院のMPAプログラムの集大成として、Policy Projectに参加予定です。プロジェクトの概要は以下HPの最終段落をどうぞ
Master in Public Affairs | Sciences Po School of Public Affairs
・これに参加するに先立って、自分の考えをいろいろと整理した結果、このプロジェクトに参加しながら個人的に「失敗ジャーナル」というものをつけようと思いました。
・以下では、このアイディアについて説明しています。日英、両方で書きました。
なぜ失敗ジャーナルを書くのか / Why Write a Failure Journal?
今学期はポリシープロジェクトに取り組むわけですが、そもそもこのプロジェクトは失敗すると思ってます。もちろん私はこのプロジェクトを成功させたいですし、成功させるためにあらゆる努力をしたいと思います。ちなみに成功例は以下のようになります。
Content Regulation in France, the UK and China: Our Work with Sciences Po Students
一方で、やっぱり物事ってそんなにうまくいかないですし、自分にとって母国語以外でチームプロジェクトを回していくっていうことは初めての経験なので、これが初めからうまくいくというイメージは沸きません。
As I embark on a policy project this semester, I'm bracing myself for the likelihood of failure. Despite my desire for success and willingness to put in every effort necessary, I find it hard to imagine everything going smoothly right from the start, especially as this is my first time managing a team project in a language that is not my mother tongue.
大事なことは、これはどこかで失敗するという可能性を頭に入れた上で、どこで自分が、あるいは自分たちが失敗したかというのを振り返ることができるように、その記録をつけておくということです。このプロジェクトのどの段階で失敗するかをあらかじめ考えておき、その対処法をまずは考えましょう。
Acknowledging the possibility of failure and maintaining a record of where I/we might go wrong is crucial. By anticipating potential pitfalls, I can devise preliminary strategies to address them.
そして、それでも失敗すると思います。その差分、つまり事前に防げると思ってたけど、結局防げなかった問題、あるいは、そもそも起きることが予想できなかった問題、というのを見つけていくというのが、この失敗ジャーナルの重要な点です。
Yet, I believe we will still encounter failure. The essence of the Failure Journal lies in identifying issues that I thought could be prevented or completely unforeseen.
もっとも、ジャーナルの本質はもう少し向こう側にあります。それは、次に自分が、何かグループプロジェクトをする時に、このジャーナルを活用して、どこでチームのプロジェクトというものがつまずくのかに関して、レッスンを蓄積するということがこの記録の本質です。失敗を経験として後から振り返れるように記録しておくということが一番大事です。
The true nature of the journal, however, goes beyond mere documentation. It serves as a reservoir of lessons for future group projects, allowing me to reflect on and learn from our missteps. The most critical aspect is recording these experiences for retrospective analysis.
ということで、前編と後編に分かれてやります。まずは問題発見編、後半に解決策編ということで解決策を探っていきます。解決策編の最後のゴールとしてて、どうやって問題を防ぐかという観点で、使える／ストックしておきたいタンジブルなフレーズをいざという時のために考えておこうかなと思います。
This series will be divided into two parts: first, identifying the problems, and second, exploring solutions. The ultimate goal is to develop actionable phrases to prevent issues, ready to be used when needed.
問題発見編 / Identifying the Problems
問題発見編です。このプロジェクトがどこで失敗するかを考える切り口はいろいろあると思うんですけど、僕は大きく 3 点だと思います。1 つ目はプロジェクトの入り口、あるいはプロジェクトの前半のところで、「クライアントのニーズを見極める」という段階で失敗すると思います。 2 点目は、プロジェクトの次の段階として最終的にソリューションをアウトプットとして提供しますが、この「ソリューションの提案」に失敗すると思います。3 点目はこの「ニーズの見極め」と「ソリューションの提案」の両方に共通して起きること、つまりどっちのステージでも起きることだと思うんですけど、「チームのマネジメント」、ないしはチームのコミュニケーションと言ってもいいかもしれないけど、そういうところでつまずくと思ってますので、この 3 つの複合的な要因によってこのプロジェクトは失敗すると思います。
I foresee three main areas where the project may falter. The first is at the initial stage, where we could fail to assess the client's needs accurately. The second is at the stage of proposing solutions, which we might also struggle with. The third is a common thread across both stages: team management or communication, which could lead to stumbling blocks.
クライアントのニーズの見極めに失敗する / Failing to Assess the Client's Needs
まずはそのニーズの見極めというところですけど、ニーズを見極めるとか、あるいは後半考えるソリューションの提案のところもそうなんですが、実際にその失敗例としてどこのタッチポイントで失敗するかっていうことを以下に書きます。ここでは６点ほど考えました。
Discerning client needs can be a complex task. There are several touchpoints where we might fail in assessing needs, and here, I outline six potential pitfalls:
まず 1 点目は、「深い思考」ができないリスク、つまり一般論や目についたソリューションに場当たり的に飛びついてしまうこと、言い換えるとソリューションの提案に急いでしまうというリスクです。
The Risk of Shallow Thinking: The tendency to latch onto superficial solutions or rush the proposal process without deep consideration.
2 点目はこれに似た話で、自分としては１点目の状況を理解して深い思考をできていて、クライアントが本質的に求めるいわゆる「ニーズ」と呼ばれるようなことを見極めなきゃなぁと思っているものの、ほかのチームメンバーがそうした状況に陥るリスクです。つまり、場当たり的にソリューションに飛びついてしまうとか、「なんかとりあえずインタビュー調査してみようぜ」とか、そういう状況にチームが陥ることを自分が止められない、止めるべきところでブレーキをかけられないというリスク、これが 2 点目です。
The Risk of Shallow Thinking from a Team Perspective: The second point of potential failure is akin to the first: while I may grasp the concept of deep thinking and the essence of what the client truly needs, there's a risk that other team members might fall into the trap of superficial solutions. Imagine the scenario where the team opts for an ad-hoc approach instead of delving deeper—perhaps saying, "Let's just do some interviews for now." This is where I may find myself unable to halt the momentum, failing to apply the brakes where necessary. That is the second pitfall we face: the inability to prevent the team from hastily jumping at solutions without a thorough understanding.
3 点目も似ていて、この「深い思考」ができないリスク、つまりクライアントのニーズを深く見極めることができないリスクが、プロジェクトのあらゆるフェーズで顕在化し得るということを認識していないという問題です。それはどういうことかというと、クライアントのニーズやソリューションの方向性というのは、1 回見極めてしまえばそれでおしまいというものではなく、プロジェクトが進行していくにつれて、あるいは時間が経つにつれて、プロジェクトの本当のゴールというものが変化していく可能性があるわけです。しかしその変化にキャッチアップできず、なんとなく場当たり的に、ニーズを見極め切った気になってしまう、そういうリスクです。例えばソリューションの方向性が見えたと思って、ちょっと調べてみたらすでに誰かが提案済みです、なんていう状況になった時に、それに対応できず時間がなくなって、なんとなくまた別のソリューションに飛びついてしまう、というリスクがありえると思います。
The Risk of Shallow Thinking at Any Stage of the Project: This issue arises from a lack of awareness that understanding the client's needs and the trajectory of solutions isn't a one-and-done task. Instead, the real objectives may shift as the project moves forward or as time evolves. Failing to keep up with these changes could lead us to mistakenly believe we've fully grasped the needs—a false sense of completion. Imagine realizing the direction for a solution seems great, but a quick check reveals it's already been proposed. The risk here is that we may not have the capacity to adapt, and as time dwindles, we might hastily latch onto an alternative solution—a reactive rather than proactive approach to problem-solving.
4点目も結構大事なんですけど、そもそもクライアントが問題解決を望んでいない／ソリューションを望んでいないっていうパターンがあり得ます。そもそもクライアントが「どうせ、こんなのは学生さんのプロジェクトだから」というスタンスで、核心に突っ込んだような分析は不要だとなると、プロジェクトは失敗します。その場合、学生、つまり我々に対して裁量やデータ、クライアントの知見を共有しないからです。クライアントが、本質的なソリューションの提案ではなく、あくまでも授業の一環として授業が丸く収まればいいよと、それっぽいものを出してくれればいいよというようなことを望んでいるリスクがあると思います。
The Client's True Intentions: A crucial point often overlooked is the possibility that the client may not actually desire a resolution or a solution. There is a scenario where the client may perceive the endeavor merely as a "student project" and deem a deep-dive analysis unnecessary. In such cases, the project is set up for failure—not due to a lack of effort from the students but because the client may withhold vital discretion, data, or insights. This leads to a situation where the client is satisfied with a superficial outcome that neatly ties up a class exercise rather than seeking a substantive proposal. The risk here is that the client's actual expectations are for something that merely appears to be a solution without the need for it to be genuinely effective or innovative.
5 点目はクライアントと学生のポジション立ち位置が不明瞭なままプロジェクトが進行していくリスクです。この場合、ニーズの見極めは難しくなります。なぜなら、先ほどの話ともちょっと繋がるんですが、クライアントのスタンスが曖昧で、そもそもこちらのことを単純に学生としか思っておらず、何か斬新なソリューションを提案するとも思ってない場合、我々の立ち位置がものすごく曖昧になります。クライアント側がきちんとこちらを、ソリューションの提供者である、かつ自分たちはクライアントであるというふうなスタンスを明確に示してくれれば、あるいはクライアントにそう示させることができれば、このリスクは回避することができます。
Unclarified Stance: The fifth point of concern is the risk associated with ambiguous roles between the client and the students as the project progresses. This ambiguity complicates the process of identifying needs. The connection here is that if the client's stance is unclear and they regard the participants merely as students, without expecting any innovative solutions, then our position becomes incredibly vague. If the client were to clearly define us as solution providers and themselves as the client, or if we could ensure they adopt this perspective, then we could avoid this risk. Establishing clear roles is essential for the project.
最後 、6 点目は、プロジェクトのスコープがものすごく曖昧であったり、あるいはアウトプットのイメージが曖昧なまま、プロジェクトが走っていくリスクです。すでに来ているプロジェクトのお題に関する資料に、プロジェクトのスコープって一応書いてあるんですけど、それでもかなり曖昧です。つまり、アウトプットイメージのすり合わせができていないということです。クライアント側にも、ぼやっとしたイメージしかないと思います。お題に対して、解決策の提示を望んでいるのか、あるいはもう少し行って、その解決策の実効性の検証まで求められているのか、あるいはもっと前の段階で踏みとどまって、調査・分析結果を示してくれればそれでいいよと思っているのか、このあたりが早い段階でしっかりと把握できていないと難しいんじゃないかなと思います。
The Haziness of Project Scope and Outputs: The final point addresses the risk of proceeding with a project when the scope is vague, or the envisioned output remains indistinct. Even when the project documentation lists a scope, it can still be quite unclear, indicating that the expected outputs must be appropriately aligned. It seems likely that the client also has only a nebulous idea of what they want. Are they looking for just a proposed solution, or do they expect us to go further and verify the effectiveness of that solution? Or are they satisfied with stopping at an earlier phase, simply showcasing the research and analysis results? Not having a firm grasp of these expectations from the early stages can spell trouble.
この 6 点全てを、やはりチームでコミュニケーション取ってマネジメントしていくことが重要です。対内コミュニケーションと対外コミュニケーション、両方あると思いますが、それがうまくいってないと、ここのフェーズは失敗するだろうと思います。
Overall, as I mentioned earlier, effective communication and management within the team, as well as with external stakeholders, are crucial for handling these six types of risk. Without smooth internal and external communication, we risk faltering at this phase.
ソリューションの提案に失敗する / The Pitfalls of Proposing Solutions
問題解決編の後半ですけど、ソリューションの提供をする時にボトルネックになるようなリスクが何なのかを書いていきます。三つあります。
In the latter half of our problem-solving journey, we confront the risks inherent in providing solutions. There are three primary bottlenecks.
一番簡単にわかるのはやはりデータの分析力の不足です。つまり、現状分析が不十分で深い洞察のあるソリューションが導出できないことは考えられます。これにはいくつか要因があると思っています。
The most apparent is the inadequate ability to analyze data. Flawed analysis might lead to solutions lacking depth and insight. Several factors contribute to this potential shortfall.
まず一つはスキル面の不足。すなわち、適切なデータを見つけてくるとか、あるいはその見つけてきたデータをきちんとクリーニングするとか、そこに対して適切な分析を加えるっていうスキルが、我々チームメンバーに不足している可能性があります。
Firstly, there's the possibility of skill deficiency. This could manifest as an inability to find appropriate data, properly handle the gathered data, or conduct relevant analyses. These skills might be lacking among our team members (hopefully not, of course).
それからリソースが不足するパターン。時間がなくなったりとか、あるいはチームメンバーがあまりレスポンシブじゃなくて、他の授業にかまけていてリソースが不足してしまうというパターンですね。
Then, there's the possibility of resource shortage. This could be due to dwindling time or team members being non-responsive, possibly preoccupied with other commitments, leading to an overall scarcity of necessary resources.
結局、アウトプットの質は、このスキルとリソースの掛け算で決まるわけですね。高いスキルを伴った分析に多くのリソースで捌いていけば、いいアウトプットというのは基本的にはできるということです。けれども、このどちらかあるいは両方が不足してしまうというパターンが考えられます。
At the end of the day, the quality of the output is determined by the multiplication of skills and resources. Adequate skills, coupled with sufficient resources, typically result in quality outputs. However, a deficiency in either or both could spell trouble.
ここでもう一つ付け加えておきたいのはチームマネジメント。チーム内でのコミュニケーションが不足するということですね。どんなに良い分析をしようと思っても、あるいは分析ができると思っても、それをチームメンバーに対して積極的に「この分析が有用である」と、あるいは「あなたがやろうとしている分析は有用ではない」とアサーティブに指摘をしたりして、チームの中でコミュニケーションをうまくとって、どんな分析が最も最適であるかということを考えられなければ、十分な分析をし深い洞察を導くというところは失敗します。
Another aspect worth emphasizing is team management. Inadequate communication within the team can be detrimental. No matter how effective the analysis might seem or the potential for it to be conducted, it's crucial to assertively communicate within the team, indicating the usefulness/uselessness of specific analyses. Without such internal coordination and decision-making, even the most thorough analysis could fail to yield the deep insights necessary for success.
2 点目はクライアントとの調整不足ですね。対外コミュニケーションの方ですが、例えばソリューションの大まかな方向性に、クライアントの納得感とか満足感みたいなものがないとこれは厳しいです。ですので、おそらくここで重要なことは、そもそも大まかなソリューションの方向性っていうものを早くに取りまとめ、詳細な分析に入る前にそれをクライアントに一度示し、その方向性に納得感や満足感があるかどうかっていうのを確認することですよね。
The second significant challenge revolves around insufficient coordination with the client. This is a matter of external communication, where gaining the client's satisfaction and approval on the general direction of the solution becomes critical. It's vital to consolidate a rough direction for the solution early on and present it to the client before delving into a detailed analysis. This step helps confirm whether the client feels satisfied and agrees with the proposed direction.
のちほど解決編のところでも書きたいんですけど、ここでのリスクヘッジとして、仮にソリューションの方向性に満足感、納得感が得られなかった場合にも、プロジェクトを少し巻き戻せるような状況にチームをマネジメントしておくということが重要かなと思います。
A key strategy in managing this risk, which I'll explore more in the following solution section, is ensuring that our team is prepared to roll back the project slightly if necessary. If the initial direction of the solution fails to resonate with the client, having the flexibility to reassess and adjust our approach is crucial. Effective client engagement and the ability to pivot based on their feedback are essential for the successful culmination of any project.
３点目、最後にこれも重要だと思うんですが、最終的なソリューション、あるいはアウトプット、あるいは提案に至るストーリーの全てに対して、全てのチームメンバーが納得している事が重要です。自分としては、どんなにそのソリューションの価値が高くても、メンバーが全員が納得していないという状態で、最終プレゼンに漕ぎつけたとしても、あまり意味がないと思うんです。
Team Consensus on the Final Solution: The last, yet equally crucial aspect, is ensuring that every team member is on board with the final solution, output, or proposal. From my perspective, the value of a solution is significantly diminished if it doesn't have the unanimous support of the entire team. Even if we reached the final presentation, it would lack meaning if not all team members agreed.
それよりかは、ある程度アウトプットの精度を犠牲にしてでも、チームメンバー全員が納得しているアウトプットを出すという方を私は優先したいと思っています。ここに失敗すると、つまり、全員が納得して進めるっていう方向性で全員が一致していないと、かなり独りよがりなアウトプットになり、仮にソリューションの質が高くてもチームプロジェクトとして満足感がいくものにはならないんじゃないかなという風に思ってます。
I believe it's preferable to compromise a bit on the precision of the output if it leads to achieving the entire team's consensus. Failing to secure this agreement could lead to a situation where the output, while high in quality, is perceived as unilateral, not truly reflective of a collaborative team effort. This misalignment could potentially detract from the overall satisfaction and effectiveness of the team project. Prioritizing a collective understanding and agreement within the team is fundamental for the success of any collaborative endeavor.
