PJTとは？ 定例会議を軸にPJTを推進する「プロジェクトスプリント」も解説

PJTとは

プロジェクト（英：project）とは、売上や利益といった数字や成果物の完成といった、設定した目標を達成するために策定した計画および行動のことを意味します。projectの頭文字をとって「PJ」や「PJT」と訳されたりもします。「PJT」「pjt」は英単語projectの略称で、プロジェクトのことを指します。「prj」や「PJ」と表記されることもあります。

関連する単語に「PM」があり、英単語project managerの略称で、プロジェクトを管理・推進する役割を負うプロジェクトマネージャーを指します。

定例会議を軸にPJTを推進する「プロジェクトスプリント」とは？

プロジェクトマネジメントにおいて、スケジュールと作業状況を調整する進行管理は、大事な業務の一つ。コパイロツトでは、定例会議を軸としたプロジェクトマネジメントのメソッドを体系化し、プロジェクトを取り巻く状況の変化にも素早く対応しつつスムーズな進行を実現しているそうです。そのノウハウをうかがいました。

 

 

1· 定例会議で、プロジェクトをグレードアップ！

変化に対応しゴールを目指すプロジェクトマネジメントとは？

コパイロツトでは、「プロジェクト」をWebサイト・プロダクト・サービスなどをつくり出すために限られた期間や予算で実施する業務、「プロジェクトマネジメント」をその制約の中でバランスを取る業務と考えています。近年、プロジェクトをベースにした働き方やテクノロジーの進歩により、プロジェクトの規模や参加するメンバーの人数が大きく変わりました。そのためプロジェクトも、最初に提案した企画やスケジュールを最後まで変更なく進めるということは少なくなったと感じます。状況の変化が速くなり、軌道修正や多様なメンバーと意見をすりあわせる場を持つ必要が出てきたことで、定例会議を活用しながらプロジェクトマネジメントをスムーズに進められないかと試行錯誤してきました。そうして体系化したのが、定例会議を中心に据えたプロジェクトマネジメントのメソッド「プロジェクトスプリント」です。

これは、プロジェクトに変化が起きることを前提として、定例会議で見直していく方法です。「クライアントの課題を解決する」ためには、最初に決めたことを信じ込んで実行するのがプロジェクトの本質的な成功とはいえません。進めていく中で新たに課題が出てきたり、最初に導き出したものよりもっといいゴールが見えてきたりする場合もあります。プロジェクトスプリントの一番の目的は、変化に柔軟に対応し、プロジェクトの成果をよりよいものにすることです。

具体的には、短いサイクルで定例会議を行い、その中で課題やタスクの洗い出し、その実行や検証を繰り返して進めていきます。定例会議は再構築の場として捉え、毎回ゴールのためにはこれでよいのかという見直しを行うことで、本質的な成功に近づけていきます。

プロジェクトの全体設計

プロジェクトがシンプルな施策で規模も小さく、状況が変わりにくくてゴールが明快なものであれば、一人のプロジェクトマネージャーで管理していくことが可能です。しかし、施策が複雑・多様で規模が大きく、状況が変わりやすくてゴールが不明瞭な場合は、プロジェクトの進行もチーム全体で対応していく方がよいでしょう。ここからご紹介していく方法はそうした場合に向いていますが、規模にあわせて必要なところを取り入れていけばよいでしょう。

まずは、現状の把握をします。探索から始めるべきなのか、いきなり要件定義から取りかかれるのかといったスタート地点を明らかにします。そして、ゴールにいたるまでのマイルストーンを設定します。マイルストーンごとの間の期間をフェーズと呼び、その期間内でどのくらいの頻度・開催時間で定例会議を行っていくか、最初のマイルストーンまでの定例会議ではどんなアジェンダを取り扱っていくのかといった、プロジェクトを設計していきます（01）。

ゴールは変化していく前提ですが、何も決めないままだと動き出せないので、その段階で判断できる仮説を組み立てていきます。以降は、毎回の定例会議で見直します。クライアントに不安を感じさせないためにも、プロジェクトの進め方やフェーズごとのゴール・成果物を明確にし、その上で変化していくことに理解・納得をしてもらうとよいでしょう。

会議の頻度や開催時間は、プロジェクトの納期やかかりそうな工数、クライアントの担当者が短いスパンで確認したい人かどうかなどの観点から判断していきます。経験上、週1回、1～2時間程度で始める場合が多いです。

プロジェクトを取り巻く状況に変化の兆しが見えてから関係各所に会議の打診をしていては、すぐに動けず手遅れになる場合もあり得ますが、定例会議を設定すると、想定外の変化や新たに見えてきた課題に対応しやすくなります。また、開催曜日や時間を固定することでプロジェクトメンバーのスケジュールを確保しやすくなり、作業のリズムも掴みやすくなります。

 

 

2· 成果の上がる定例会議の開催・運用方法

定例会議の流れ

定例会議は、アジェンダ（みんなで話し合いたいこと）とタスク（実際に行う作業）を軸に進行します（02）。その定例会議に設定したテーマに沿って、会議の前に参加者全員がアジェンダを検討し追加します。会議冒頭に、集まったアジェンダの中からその日に議論すべきもの、次回以降でも問題ないものなどをより分け、優先順位をつける作業を参加者全員で確認しながら行います。また、それぞれのアジェンダに何分かけて議論するかも開始前に決めておき、時間内に収まるよう、優先順位の高いアジェンダから皆で議論していきます。そして議論の結果に基づき、課題の抽出や次の定例会議までに行うタスクを決定します。コパイロツトでは、会議においてファシリテーターを行うことが多いですが、決裁者ではありません。プロジェクトマネージャーとしてプロジェクトを前に進めるため、最善の選択をするための議論を行い、総意として決定します。最後に、次の定例会議のアジェンダとタスクを決めます。これは1週間後には変化しても構わないものです。そして次の定例会議では、前回の定例会議以降の活動報告やプロジェクトで方向修正すべき点はあるかを最初に確認し、同様の手順を繰り替えしていきます。

プロジェクトスプリントにおける会議では、「持ち帰って検討します」ということは厳禁で、その場で結論を出すことが重要です。そのためにも、アジェンダの議論に必要な人、タスクをその場で決定できる権限を持っている人は全員会議に参加してもらう必要があります。目まぐるしく変わっていく状況や業界・テクノロジーの進歩が激しい現在では、あらゆる分野を一人のプロジェクトマネージャーが架け橋となって管理するのは難しいという理由もあります。

 

 

アジェンダのつくり方

定例会議の前に準備するアジェンダには、次の三つの要素を必ず記載するようにします。まず一つ目は、なぜそのアジェンダについて議論したいのかをチームメンバーに理解してもらうための「目的・理由」です。次に、議論の「進め方」、そして三つ目に議論の結果どうなるといいのかという「終了時の状態（終了条件）」を明記します。

議論の終了条件は、「発散」「収束」「共有」の三つに大別できます。発散は、結論が見えないテーマについて行う議論で、皆で意見を出しあうことが目的なので答えが出ないまま終了しても構いません。収束は、メンバー間での意思決定や合意形成をする目的のもので、何かしらの結論を出します。共有は、チームメンバーとの認識あわせなどのため、報告すればよいものです。

定例会議で必要な環境とツールの活用

会議をスムーズに行うために、環境づくりやツールの活用も大切です（03）。会議の場には、モニタが2台あることが望ましいです。1台はアジェンダやマイルストーン、タイマーを表示します。アジェンダのリストは、Googleスプレッドシートなどで管理します。現在、この作業をよりスムーズに行える会議用ツール「SuperGoodMeetings」をコパイロツトで開発中です。議論を決めた時間内で行えるよう、全員に見える状態であることが重要です。

もう1台は、議論するための資料や議事録を表示するためのものです。議事録はGoogle Docsなど全員で同時編集できるツールで記録していきます。なぜかというと、誰か一人が代表して記録すると、受け取り方によって内容にズレが出てしまう可能性があるからです。また、会議終了時には議事録を完成させておき、その場で次のアジェンダやタスクを決められるようにしたいため、会議のスピードに追いついて記録できるよう、複数人で書き込んでいくという理由もあります。

ホワイトボードや壁に貼った模造紙などにも、アジェンダや議論の概要を書き出します。これも、皆で閲覧するためです。会議終了後は、写真に撮って記録に残しておけばよいでしょう。

 

 

3· 会議を中心に据えるメリット

定期的な振り返りでプロジェクトを俯瞰する

定例会議とは別に、「振り返り」の場を持つことも重要です。定例会議でも、プロジェクトを俯瞰して見られるように努めますが、それでも目線は狭くなっていくものです。そうならないために、定例会議と同じメンバーで、一歩引いてプロジェクトを眺め感想を共有する場を設けます。このとき過去のアジェンダを見ながら、何がよかったか、改善できる点はあるかといった意見を集め、付箋で書き出していくとよいでしょう（04）。

開催タイミングは、マイルストーンごとなど区切りのよいときの他、例えば定例会議が週1～2回だとしたら、振り返りは月1回くらいのタイミングで行う場合が多いです。というのも、プロジェクトは立上げや計画、実行などの工程が並行して行われることもあり、プロセスごとに区切りをつけるのが難しいからです。また、あまり長い時間が経ってしまうと、そこでプロジェクトの問題に気づいても改善するのが不可能なタイミングになってしまったり、決めた時から時間が経ちすぎてそのときの記憶が曖昧になってしまったりします。

振り返りでは、タスクやマイルストーンの見直し、きちんとチーム内で言いたいことが言い合える心理的安全性を築けているかといったチーム状況など、問題になり得そうなさまざまなことを確認していきます。

また、振り返りの際に、そのプロジェクトを通して得たナレッジを記録に残しておき、未来の資産へと繋げていくことも大切です。

 

 

プロジェクトの問題を早期に顕在化する

前述の通り、プロジェクトスプリントは柔軟に変化に対応しながらよりよいゴールを目指すためのものです。この方法をとると、プロジェクト管理の上で問題となり得るさまざまな点でのメリットがあります。

例えば、進行の遅れという観点では、定例会議で皆の進捗や課題、トラブルを報告しあうので、早い段階で把握・対処することができます（05）。遅れというのは完了を予定していたスケジュールの直前にわかると大きな問題ですが、早めにわかっていればその作業に人手を増やしたり、納期やローンチのスケジュールを見直したりと、対処の方法はいろいろ考えられます。

また、基本的に会議では皆で発言をするので、専門的な知識がない別の人が決めたことによる不合理な作業も生じにくくなります。周りは気づかなかったけれど実は担当の人はすごく苦しい思いをしていたり、何かプロジェクトにおける問題を抱えていたということも、問題が大きくなる前に把握しやすいです。そもそもタスクにどれくらいの時間をかけるかというのは、個人の判断によって差が出ることがあります。指示する人は1日くらいで済むレベル感のつもりだったのに、作業する人は10日くらいかけるレベル感でやるべきだと受け取ったというようなズレが出ることもあります。しかし「次の定例会議までにやれるレベルのタスク」という時間の区切りをつけることで、そうしたズレも少なくなります。

偉い人が決定権を持ち、若い人は言われたことをやればいいという関係性では、もし早い段階で問題点に気づいていたり、何か不安を感じる点があったりしても、どうしても問題が小さなうちに声を上げにくく、深刻化してしまう場合があります。問題が大きくなってから可視化・共有されては手遅れになるので、そうならないためにも定例会議は有効です。自身に発言の機会があることでプロジェクトを自分ごと化しやすく、モチベーションが上がりやすいというメリットもあります。

リーダーが会議のアジェンダを用意してくれ、参加して聞いているだけでよいという一般的な会議と違い、慣れるまでアジェンダの提出は難しく感じるかもしれません。コパイロツトでも、初めての方にはいきなりアジェンダを書いてもらうのではなく、最初はこちらできちんとファシリテーションし、少しずつ「ここをお願いしてもよいですか」という風に依頼し、慣れてもらうようにしています。慣れ具合に応じて、少しずつ試してみてください。