はじめに
今回この記事を書こうと思った背景として、チーム内や他プロジェクトの若手社員から「PJの進め方に迷っている」「PLの立場になったけどどう進めればいいかわからない」といった声をよく聞くようになったことがあります。ちょうど自分自身の考え方を整理する良いタイミングだと感じ、改めてこの「自分の仕事の進め方」を言語化してみました。
私のやり方は “テキストドリブン・マネジメント” とでも呼べるもので、「書いて共有すること」を中心に据えたスタイルです。以下で詳しく紹介していきます。
#この名称はChatGPTにつけてもらったものですので、非公式になります！
PJについて
この手の話を進めるうえでどういった開発案件、体制なのかは重要になります。所属する会社のチームはAWSを用いたクラウド開発プロジェクトが主です。規模間としては10名以下のチームがたくさんあるような小規模～中規模多めになります。開発手法はアジャイル寄りで、短いサイクルで要件や成果を柔軟に見直しながら進めています。
チーム構成は比較的若く、年齢的にも私はちょうど真ん中（30歳前後）くらい。開発ツールやコラボレーション環境もある程度自由度があり、Jira、Confluence、Backlog、Teams、Slackなど、好きなものを使っていい前提です。
また、基本は私もメンバも在宅勤務になります。
ですので、リモートワークが中心の中での開発リードする必要があります。
書くコミュニケーションを軸にしている理由
まず大前提として、私は 「書けない人は退プロ対象」 と言い切るくらい、書くことを大切にしています。ここでいう “書く” とは、Jiraチケットのコメント、Teamsでのちょっとした発信など、すべてを含みます。
「うまくいっていない」「まだ成果が出ていない」そんなときでも、とにかく “今どうしてるか” を残す。これは自分の中では絶対ルールで、私自身も毎日何かしらの発信をするようにしています。
書くことには以下のような効果があります：
- 履歴が残る：トレーサビリティ確保の観点で重要。
- 思考が整理される：書いているうちに、自分の中でも考えがまとまる。
- 伝わりやすい：読み手にとっても、情報を咀嚼しやすい形で届く。
正直、口頭で話すのが苦手なメンバーも多いですし、テキストの方が気楽というのもあるかもしれません。私自身、過去に尊敬していた上司が「とにかく丁寧に書く」タイプだったこともあり、自然と影響を受けてきました。
話すコミュニケーションももちろん大事
ただし、「書けばいい」だけではプロジェクトは回りません。特に今のようなスピード感のあるAWS開発では、口頭で話すほうが早い場面もたくさんあります。
そこで私が意識しているのが、1on1やスポット打ち合わせの活用です。何か相談が来たら、5分でもいいのですぐ時間を取る。迷っているJiraチケットやコメントに反応して、さっと声をかけるといったことをしています。この「ちょっと話そうか」で一気に解決することも多いです。
とはいえ、忙しいときもあるので、毎日のデイリー枠を固定しておき、ベースラインは確保。不要そうならキャンセルしてOK、という緩い運用にしています。
会議設計の工夫
全体会議は週1回だけ。ここはある程度情報共有の場として機能させつつ、内職OKにしています。というのも、全員に関係ある話ばかりではないので、「必要なときは聞く」「あとで聞き返せる設計」にした方が効率がいいからです。
ただし、 チャットや1on1だけでは「一体感」や「チームとしての温度感」が薄れる 懸念もあると思っています。そこで、飲み会やオフ会などの非公式イベントをあえて設けるようにしています。こうした“オフ”のコミュニケーションは、日頃テキスト中心で足りなくなりがちな関係構築を補完してくれる、大事な仕掛けです。
書く文化をチームに浸透させるには
「書けない人は退プロ」と言う一方で、もちろんいきなり完璧にできるとは思っていません。最初はテンプレや見本を用意して、「この粒度で書いてくれればOK」という基準を示すようにしています。慣れてきたら、チームメンバや若手が自発的にConfluenceにナレッジをまとめてくれるようになることも増えてきました。
これは自分がまず模範として「書く」を徹底してきた成果だと思っています。
この進め方のメリット・デメリット
“テキストドリブン・マネジメント”の進め方には、以下のようなメリットがあります
- プロセスや思考のトレースがしやすい
- 情報が蓄積され、ナレッジシェアが加速する
- メンバーが自走しやすくなる
- リモート環境やチームスケーリングとの相性が良い
一方で、デメリットももちろん存在します
- 書くこと自体が苦手・億劫なメンバーにはハードルが高い
- テキストコミュニケーションに偏りすぎると、温度感や雑談が欠落しやすい
- 情報量が多くなりすぎると、逆に見えづらくなることもある
このため、適切な“読みやすさ”の設計や、非テキストでの補完（会話・オフ会など）が必要です。
私が一番大事にしていること──成果に集中するチーム設計
私がプロジェクトリードとして一番大切にしているのは、メンバーが無駄なく、迷わず、成果に集中できる設計をすることです。そのためには、単に「頑張って進める」のではなく、“やらなくてもいいこと”を見極める力が非常に重要になります。
・不要な試験項目は根拠をもって削る
・過剰なレビューや承認フローはスリム化する
・会議も目的が曖昧ならやらない
この考えの延長線上に、私は「テキストを中心としたコミュニケーション」があると考えています。
話すだけでは抜け落ちてしまう情報を、書くことで整理・蓄積し、メンバーの自走を促す。つまり、“仕事を増やすため”のコミュニケーションではなく、 “仕事を減らして成果に集中するため” のコミュニケーションということです。
決して、書く作業工数を増やしたいわけではないことが言いたいです。
最後に
プロジェクトリードとして大切にしているのは、メンバーが迷わず動けるような設計をし続けることです。「書く」「話す」を目的ごとに使い分け、状況に応じて最小のコミュニケーションで最大の成果を出せるチームを目指しています。
このやり方がすべてではありませんが、同じような立場の方や、PJ運営に悩んでいる方のヒントになれば嬉しいです。ご意見・ご質問などあればコメントください！
あなたのチームでは、どんな進め方をしていますか？