プロジェクトがうまくいかないのは、あなたのせいじゃない

はじめに

チームがうまく動かないとき、プロジェクトが遅れるとき、メンバーが疲弊しているとき。その責任はプロジェクトを管轄する自分にある。そう感じながら日々仕事をしている人は少なくないはず。私もそう。

ディレクターとしてプロデューサー、デザイナー、エンジニア、ライター、マーケター、そしてクライアントと、さまざまな人たちと一緒にプロジェクトを進めてきた。
それぞれ得意なことも苦手なことも違う。大事にしていることも譲れないことも。多様な人が集まって何かを作り上げようとするとき、うまくいかない場面は当然のようにある。

そのたびに思っていた。自分のやり方が悪かったのか、自分の力が足りなかったのか、と。

しかし、あるとき気づいた。問題の多くは"人"ではなく"構造"にあった。

会議が機能しないのはメンバーのやる気の問題ではなかった。プロジェクトが遅れるのはディレクターの見立ての甘さが問題ではなかった。優秀な人が疲弊するのは性格の問題ではなかった。

どれも構造の問題だった。構造を変えれば同じ人でも違う結果が出る。そのことを現場での失敗と気づきを通じて少しずつ学んできた。

この記事では、私が6年間Webディレクターとして現場で経験してきた「プロジェクトがうまくいかない本当の理由とその対処法」を3つのエピソードを通じてお伝えしたい。マネージャーやリーダーとして、チームやプロジェクトをなんとか前に進めようとしている人たちに届けばうれしい。

そしてもし今、うまくいかないことで自分を責めているとしたら、この言葉を伝えたい。

うまくいかないのは、あなたのせいじゃない。問題は構造にある。

1. 会議が機能しない

Web制作のプロジェクトで、週次の社内ミーティングを開いていた時期がある。

Backlogを見ながら「今週はこれとこれを進めましょう」と確認する。担当者と期限も設定してある。なのに翌週のミーティングで「まだできていません」という報告が続く。ツールはちゃんと使っている。メンバーのスキルに問題があるわけでもない。それでもタスクが動かない。

そのとき私が考えたのは「コミュニケーションの量が足りないのかもしれない」ということだった。試しにミーティングの開催を週1回から2回にしてみた。それでも状況は変わらなかった。

では、本当の問題は何だったのか。

振り返ると、そのミーティングには大きな欠陥があった。アジェンダが用意されていない。この場で何を決めるかが設計されていない。進捗報告と意思決定が混在したまま、なんとなく話して終わる会議になっていた。

そしてもっと根本的な問題があった。メンバーが「自分で決めた」という感覚を持てていなかったことだ。ディレクターである私が「これをやってください」と伝え、メンバーが「わかりました」と答える。でもそれは合意ではなく、確認に近い。何を、いつまでに、どういう状態にするかをメンバー自身で言葉にされないまま会議が終わっていた。

人は自分で決めたこと、自分の口で言ったことはやらないと気持ち悪いと感じる生き物。逆に言えば、自分で決めていないことはどこか他人事になりやすい。
メンバーの問題ではなく、そうさせてしまっていた会議の設計の問題だった。

では、どうすればいいのか。意識するようになったのは三つのことだ。

一つ目は「話す場」と「決める場」を切り分けること。進捗を共有する場と次のアクションを決める場は本来性質が違う。この二つを区別するだけで会議の質は変わる。

二つ目はアジェンダを事前に用意すること。この会議で何を決めるかを明示しておくだけで、参加者の準備や心持ちが変わる。

三つ目はメンバーに宣言させる設計を作ること。ディレクターが「これをやってください」と言うのではなく、メンバー自身に「私はこれを今週中にやります」と言ってもらう。

この三つ目について、最近こんな経験をした。

明確な納期が決まっていないページ制作の仕事があった。クライアントから「急いでいないので、そちらの事情や状況で納品タイミングは任せる」と言われていた。一見すると余裕のある条件に見えるが、こういうプロジェクトは非常に危険である。締め切りがないからこそ、急ぎの仕事が入るたびに後回しにされやすい、ディレクターがスケジュールを提示しても明確な根拠がないために守られにくいからだ。

そこで担当者にこう伝えてみた。「あなたの仕事の状況を鑑みて、進められるスケジュールをご自身で作成してください」と。

結果として担当者が自らスケジュールを提示してくれた。しかもそれは私が想定していたよりもずっと早いものだった。私が気を遣いながら「これくらいでどうでしょうか」と提示するより、はるかに妥当性があり、その日を目指して担当者も自分ごととして動いてくれた。

決めてもらうと、人は動く。それだけのことだが、設計として意識するかどうかで結果が変わる。

会議が機能しないとき、まず疑うべきはメンバーでもツールでもなく、メンバーが自分で決める場になっているかどうかだ。

2. プロジェクトが遅れる

ヒアリング、ワイヤーフレーム、デザイン、コーディング。すべてのフェーズが順調に進んでいたプロジェクトがある。

クライアントのメイン担当者からはアウトプットのたびにOKをもらっていた。スケジュール通りに進んでいる。メンバーも問題なく動けている。公開まであと少し、というタイミングで事件が起きた。

「これは一度、関係者全員に見せて意見をもらっておこう」

そのとき初めて知った。関係者が何十人にもおよぶことを。デザインがほぼ出揃ったタイミングでそれまで一度も関わっていなかった、プロジェクトの背景や経緯を知らない人たちから意見を募ることになったのだ。

結果として、そのプロジェクトは当初の予定より2ヶ月遅延した。

このとき私が考えたのは「スケジュールの見積もりが甘かった」ということだった。次回からはバッファを多めに取ろうという話になった。でも本当の問題はそこではなかった。

誰が最終ジャッジを下すのかが、最初から定義されていなかったのだ。OKを出し続けてくれていた担当者は組織の中でどういう立場なのか。その人のOKで本当にプロジェクトが前に進むのか。他に決裁が必要な人はいないのか。そこを確認しないまま進めていた。

終盤になって何十人もの関係者を巻き込んだ担当者は、決して意地悪をしたいわけではなかったと思っている。組織として「あとから聞いていない」と言われるリスクを下げるために確認というプロセスを踏もうとしていただけだ。そこには組織の論理があった。問題は、その論理の存在をプロジェクトの開始時に把握していなかったことだ。

では、最初に何を確認すべきだったのか。一つは「このプロジェクトの最終ジャッジは誰が下すのか」だ。担当者なのかその上長なのか、別の部署も関わるのか。フェーズごとに決裁者が変わる場合もある。それを最初に明らかにして合意しておく必要があった。

もう一つは「プロジェクトメンバー以外に関わる可能性がある人はいるか」だ。組織が大きくなるほど、プロジェクトに直接関わっていない人が後から登場するリスクが高まる。そのリスクを最初に把握しておくだけで、スケジュールの見立てが変わる。

この二つを確認するようになってから、こんな経験をした。

100ページを超えるWebサイトのプロジェクトだった。プロジェクト序盤に意思決定者を確認すると、1人の名前が挙がった。でも少し気になった。100ページを超え、しかもページごとに確認すべき事業領域や部署が変わるようなプロジェクトを本当に1人で決裁するのか、と。

そのまま窓口の担当者に聞いてみた。

返ってきた答えはこうだった。「基本的には現場に任せようと思っている。ただ、意思決定者が最後に判を押したという事実はどうしても必要。全体の意思決定者は1人だが、この人は細かい部分までは見ない。現場の人がOKと言えば大丈夫だと思う」

この話をプロジェクトの序盤に聞けて良かったと思った。確認していなければ、その1人の意思決定者だけに目が向いていたはずだ。でも実際に大事なのは現場の人たちのOKであり、現場の人たちから意思決定者に許諾をもらいにいく流れだった。

それを前提にプロジェクトを設計できた。最初から多数の関与者に対して、最終的に確認してほしいページと意思決定者への許諾の流れを伝えることができた。結果としてプロジェクトはスムーズに進み、終盤の校正対応にも耐えうる状況を作ることができた。

表向きの意思決定者と実際の意思決定の流れは違うことがある。だから「誰が最終ジャッジを下すのか」を確認するだけでは足りない。「どういう流れで決まるのか」まで踏み込んで聞くことが、プロジェクト序盤にやるべき仕事だと今は思っている。

プロジェクトが遅れたとき、まず疑うべきはスケジュールの甘さでもメンバーのスキルでもなく「意思決定する人とその流れが定義されているか」という問いだ。

3. 優秀な人が疲弊する

昔、一緒に仕事をしていたディレクターがいる。実績もあり、周囲からの信頼も厚い。誰もが認める優秀な人だった。

でもその人はいつも忙しそうで、タスクを抱えすぎる印象があった。そのせいか、たまにタスクが滞ったり遅れたりしていた。傍から見ていて、どこか辛そうに見える場面もあった。

周囲の見立ては「任せられない性格の問題」だった。完璧主義で人に頼れない、自分でやらないと気が済まない。本人の気質の話として処理されていた。でも本当の問題はそこではなかった。

優秀である、自分でできる、クオリティを保てる。そのことが周囲から仕事を任される理由になっていた。同時にその人が誰かに任せる機会を奪ってもいた。「あの人に頼めば大丈夫」という信頼が積み重なるほど、その人へタスクが集中していく。優秀であることがタスクを抱え込む構造を生んでいた。本人の問題というより、周囲との関係の中で自然に出来上がった構造だった。

さらに言うと、周囲から期待されているがゆえに、頼れない側面もあったと思う。「できる人」として見られているからこそ、困っていると言い出しにくい。辛そうに見えたのはタスクの量だけでなく、素直に人を頼れない状況そのものへのしんどさだったのかもしれない。

あるとき、一緒に進めていたプロジェクトでその人のタスクを大きく巻き取ることにした。このとき意識したのは伝え方だった。「大変そうだから手伝う」という言い方はしなかった。代わりにこう伝えた。

「あなたにはあなたにしかできない仕事に集中してもらった方が、プロジェクト全体としても最適だと思います」

本人からは感謝された。助かった、という表情にも見えた。「大変そうだから」という理由では相手の自尊心を傷つける可能性がある。優秀な人ほど、助けてもらうことへの抵抗感がある。でも「あなたにしかできない仕事がある」という文脈で巻き取ると、それは助けではなく役割の再設計になる。相手が荷を下ろしやすくなる。

タスクを抱え込む問題の本質は、本人の性格でも意識でもなく「誰が何を担うか」の設計が最初からされていないことだと思っている。

別の機会でこんなことがあった。与件が多く、解決しなければならない課題も多数あるプロジェクトだった。当初はある優秀な社員1人で全体進行を進めようと考えていたが、早々にやめた。この規模を1人に集中させると、その人がボトルネックになることが目に見えていたからだ。

代わりに各与件に対して専門性を持った人をアサインし、相互に連携を取りながらも、意思決定は各人に委ねる形にした。

結果として誰かに偏りが生まれることはなかった。各人が自分のタスクに集中できた。スケジュールも大きな遅れなく進み、専門性を持った人が対応することで納品物のクオリティも高かった。

1人に任せていたら、おそらくどこかで抱え込みが起きていた。専門外の与件にも対応しなければならず、クオリティも落ちていたかもしれない。最初に役割を再設計したことでそれを防げた。

この人にしかできない仕事は何か。この人でなくてもできる仕事は何か。その問いを最初に立てて、誰が何をどう担うかを設計しておくこと。それもリーダーの仕事の一つだと思っている。

優秀な人がタスクを抱え込んでいるとき、まず疑うべきは本人の性格でもプライドでもなく「役割の設計ができているか」という問いだ。

おわりに

三つのエピソードに共通していることがある。

問題はいつも、人ではなく構造にあった。

会議が機能しないのはメンバーのせいではなかった。プロジェクトが遅れるのは担当者のせいではなかった。優秀な人が疲弊するのはその人のせいではなかった。すべては構造が問題だった。
そして、人を変えることは難しいが、構造は変えられる。

リーダーやマネージャーという立場にいると、うまくいかないことを自分のせいだと感じやすい。チームの問題は自分の問題で、プロジェクトの失敗は自分の失敗だと。その重圧は本物だし、責任感があるからこそそう感じるのだと思う。

でも、人はそれぞれ違う。得意なことも大事にしていることも働き方も異なる。多様な人たちが集まって何かを成し遂げようとするとき、うまくいかないことが起きるのは当然だ。問題は人が違うことではなく、違う人たちがそれぞれの力を発揮できる仕組みが設計されていないことだ。

人に期待するのをやめたとき、見える景色が変わった。期待するのではなく、設計する。人に依存するのではなく、仕組みに依存する。そう考えるようになってから、うまくいかないことが起きても「何が設計として足りなかったのか」と問えるようになった。

それはまだ完全にできているとは言えない。今も試行錯誤の途中だ。ただ、この問いを持てるようになったことで、自分を責める時間が少し減った気がしている。

もしあなたが今、チームやプロジェクトのことで自分を責めているとしたら、一度立ち止まって問いかけてみてほしい。

問題は本当に、人にあるのか。それとも構造にあるのか。

プロジェクトがうまくいかないのは、あなたのせいじゃない。