最終更新日 2026年7月24日
ゲーム会社を辞めて、ITスタートアップでプロジェクトマネージャーになった頃の話です。
チームの空気が、どこかどんよりしていました。
僕の名前は水野遼太。
もともと大手ゲーム会社でプランナーをしていて、5年間「面白さとは何か」を考え続ける仕事をしていました。
今はフリーランスでプロジェクトコンサルタントをやりながら、このブログを書いています。
あの頃のチームは、誰かがサボっていたわけじゃない。
むしろ真面目な人ばかりでした。
でも、朝のミーティングで目が輝いている人が一人もいなかった。
「やることはやるけど、それ以上のことはしない」
その空気を変えたのが、今回書く「仕事の意味を書き換える」という考え方です。
ゲーム業界にいた僕には、これがびっくりするぐらい腑に落ちました。
目次
「作業」のままだと、人はどんどん鈍くなる
ゲーム会社で叩き込まれたことが一つあります。
「同じことの繰り返しは、プレイヤーを飽きさせる」。
これ、仕事でもまったく同じです。
スタートアップでPMを始めた当初、チームメンバーの多くが「作業をこなしている」状態でした。
タスク管理ツールに並んだチケットを上から順番に消化していく毎日。
締め切りには間に合う。品質も問題ない。でも、それだけ。
特に気になっていたのが、入社2年目のエンジニアの変化でした。
入社直後はあれこれ質問してきて、勉強会にも自主的に参加していたのに、いつの間にか定時ぴったりに帰るようになっていた。
能力は確実に伸びている。でも目が死んでいる。
会議で「何か改善案はありますか？」と聞いても、沈黙。
別に不満があるわけでもなく、ただ「特にないです」という感じ。
振り返ってみると、みんな自分の仕事を「作業」としか認識していなかったんだと思います。
データの集計、レポートの作成、メールの返信。
全部「やらなきゃいけないこと」で、「やりたいこと」じゃなかった。
ジョブ・クラフティングとの出会い
転機になったのは、あるビジネス書を読んでいて「ジョブ・クラフティング」という言葉に出会ったことです。
2001年にイェール大学のエイミー・レズネスキーとミシガン大学のジェーン・ダットンが提唱した概念で、ざっくり言うと「従業員が自分から仕事のあり方を変えていく」という考え方です。
CULTIBASEの解説記事によると、ジョブ・クラフティングには3つの種類があります。
- 仕事のやり方や内容そのものを工夫する「タスク・クラフティング」
- 職場の人間関係を自分から変えていく「関係性クラフティング」
- 仕事に対する見方や意味づけを変える「認知的クラフティング」
僕が特にハッとしたのは3つ目です。
仕事の中身は何も変わらないのに、「どう捉えるか」を変えるだけで、やりがいが変わるという話。
病院の清掃スタッフの研究が有名で、同じ掃除の仕事をしていても「患者さんの回復を支えている」と捉えている人は、そうでない人より仕事への満足度が高かったという結果が出ています。
これを聞いて、「あ、ゲームの設計と一緒だ」と思いました。
ゲームだって、やっていること自体は「ボタンを押す」「敵を倒す」の繰り返し。
でもそこに物語や目的があるから面白い。
逆に言えば、どんなに面白いゲームでも、ストーリーや目的を全部取り除いたら、ただの単純作業になる。
仕事が退屈に感じるのは、仕事から「意味」が抜け落ちている状態なのかもしれない。
そう考えたら、やるべきことが見えてきました。
僕がチームで試した3つのこと
理論を知ったところで、すぐチームで試してみたくなるのが僕の性格です。
全部うまくいったわけじゃないですが、効果があったものを3つ紹介します。
タスクに「ミッション名」をつけてみた
最初にやったのが、タスク管理ツールのチケット名を変えること。
たとえば「月次レポート作成」というチケット。
これを「クライアントの意思決定を加速させるデータパック作成ミッション」に変えました。
正直、最初はメンバーに笑われました。
「何これ？」と。
でも、「これ誰のためにやってるんだっけ」という会話が自然に生まれたんです。
「月次レポート作成」だと、目的は「レポートを完成させること」になりがちです。
でも「クライアントの意思決定を加速させる」と書くと、「じゃあこのデータも入れたほうがいいかも」という発想が出てくる。
ゲーム会社にいた頃、クエストの名前には必ず「プレイヤーに何をさせたいか」が込められていました。
「洞窟を探索せよ」と「失われた王冠を取り戻せ」では、やることは同じでもプレイヤーの気持ちが全然違います。
全部のタスクにミッション名をつけるのは現実的じゃないので、週に1〜2個、特に退屈になりがちなルーティン業務を選んでやっていました。
他にも「テスト仕様書の更新」を「品質防衛ラインの強化作戦」にしたり、「問い合わせ対応の集計」を「ユーザーの本音を読み解くリサーチ任務」にしたり。
ネーミングのセンスはともかく、「この作業って結局何のためにやってるんだっけ？」と考える習慣がチームに根付いたのは大きかったです。
「誰のためにやっているか」を見える化した
2つ目は、チームの仕事とエンドユーザーをつなげること。
当時のチームは、クライアント企業の担当者とはやりとりしていましたが、その先にいる「実際にサービスを使っている人」の顔は見えていませんでした。
そこで、クライアントにお願いして、エンドユーザーからのフィードバックを月1回共有してもらうようにしました。
良いものも悪いものも、どちらも。
「この機能のおかげで作業時間が半分になりました」
「ここが分かりにくくて困っています」
こういう声がチームに届くようになって、明らかに変化がありました。
バグ修正のチケットに対する取り組み方が変わったんです。
「不具合を直す」から「困っている人を助ける」に、頭の中のフレームが切り替わった感じ。
あるメンバーが「これ、前にフィードバックで困ってるって言ってた部分ですよね。優先度上げましょう」と自分から言ってきたときは、正直ちょっと感動しました。
ちなみに、この仕組みを始めるときのコツが一つあります。
ポジティブなフィードバックだけを共有するのではなく、厳しい声もそのまま見せること。
「ここが使いにくい」という声は、裏を返せば「ここを直せば喜んでもらえる」という明確な目標になります。
チームにとっては、抽象的な「頑張ろう」より、具体的な「この人のこの困りごとを解決しよう」のほうがずっと動きやすい。
小さな「レベルアップ」を週次で確認した
3つ目。これが一番ゲームっぽいかもしれません。
毎週金曜の振り返りミーティングで、「今週レベルが上がったこと」を一人一つ共有してもらうようにしました。
技術的なスキルでもいいし、コミュニケーションでも段取りでも何でもいい。
- 「今週、初めてSQLで複雑なクエリを自分で書けた」
- 「クライアントへの説明が前より短くまとまるようになった」
- 「初めて後輩にコードレビューのフィードバックを出した」
ポイントは、他人との比較じゃなく「先週の自分」との比較にしたこと。
心理学者のミハイ・チクセントミハイが提唱した「フロー理論」では、人が没頭状態に入る条件の一つに「スキルと課題の難易度が釣り合っていること」があります。
日本の人事部の解説にもあるように、簡単すぎると退屈、難しすぎると不安。
ちょうどいいバランスのときに人は夢中になれる。
最初の2〜3週間は、「特にレベル上がってないです」という回答も多かったです。
でも続けていくと、みんな無意識に「今週は何が成長ポイントだったか」を日々の中で探すようになる。
金曜日に「発表するネタがない」のが嫌で、ちょっと背伸びした仕事を自分から取りに行くメンバーも出てきました。
週次で「レベルが上がった」ことを言語化すると、自分のスキルが今どこにあるか意識するようになります。
すると、「もうちょっと難しいタスクに挑戦してみたい」という声が自然に出てくるようになりました。
なぜ「意味の書き換え」はチームに効くのか
個人的な実感だけだと心もとないので、少し理論的な話もしておきます。
心理学者のエドワード・デシとリチャード・ライアンが体系化した「自己決定理論」では、人間のモチベーションを支える基本的な心理欲求が3つあるとされています。
日本の人事部の解説が分かりやすいのですが、その3つとは以下のとおりです。
- 自律性：自分の行動は自分で選びたい
- 有能感：自分の能力を発揮して成果を出したい
- 関係性：他者から認められ、つながりを感じたい
「仕事の意味を書き換える」アプローチは、この3つすべてに働きかけます。
ミッション名をつけるのは、タスクへの向き合い方を自分で選ぶこと。
レベルアップを確認するのは、成長の実感を得ること。
エンドユーザーの声を共有するのは、自分の仕事が誰かの役に立っていると実感すること。
厚生労働省の「令和元年版 労働経済白書」でも、「働きがい」のある職場環境が定着率や生産性に直結するという分析が出ています。
仕事の意味を書き換えるのは、精神論じゃなく、データの裏付けがあるアプローチです。
一人が変わると、隣の人にも伝わる。
ミッション名をつけて楽しそうにタスクに向き合っているメンバーを見て、別のメンバーが「自分も試してみよう」と思う。
この連鎖が起きると、チーム全体の空気が変わっていきます。
個人のモチベーション施策に見えて、実はチームに効く。そこがこのアプローチの面白いところです。
仕事を「ゲーム」として見る視点
僕がチームで試したことは、要するに「仕事にゲーム的な仕掛けを入れる」ということでした。
ミッション名、レベルアップ、フィードバックの可視化。
どれもゲームでは当たり前の要素です。
最近読んだ本で、この発想をもっと体系的にまとめているものがありました。
コンサルティング会社ギックスの上級執行役員である田中耕比古さんの著書で、仕事を「与えられた作業」ではなく「クリエイティブに攻略するゲーム」として捉え直すという内容です。
田中さん自身、商社系SI企業やアクセンチュア、IBMを経て起業された方なので、理論だけでなく現場感のあるアドバイスが多い。
全部で50個の「ギミック（仕掛け）」が紹介されていて、「仕事の意味を書き換える」「仕事を高速化する」「人を巻き込む」「成長を加速させる」など、章立てもゲームの攻略本みたいで面白い。
たとえば、自分の実力を「レベル」で捉えて短いサイクルでレベルチェックを行うという考え方は、僕がチームでやった「週次レベルアップ確認」と発想が近くて、思わずニヤッとしました。
タスクを「ミッション」として捉え直し、依頼者のゴールを正しく把握して期待を上回ることを目指すというギミックも紹介されていて、これも僕がやった「ミッション名」の工夫と通じるものがあります。
僕がチームでやったことって、せいぜい3つ4つの工夫でした。
50個もあると知ったとき、「まだまだ手札があるんだ」と単純にワクワクしました。
特に「評価を上げる」の章は、PM時代の僕があまり意識できていなかった視点で、今読んでも発見があります。
仕事のマンネリ感に悩んでいる人、チームの雰囲気を変えたいと思っているマネージャーの方には、『仕事を面白くするギミック50』の詳細ページをチェックしてみてほしいです。
まとめ
「仕事の意味を書き換える」というのは、仕事の中身を変えることじゃありません。
同じタスク、同じ業務、同じチーム。
変えるのは「どう見るか」だけ。
僕の場合、ゲーム会社の経験があったから、この発想に自然と馴染めました。
でもゲーム好きじゃなくても関係ないと思います。
要は「意味のない作業」を「意味のある仕事」に変換する工夫を、自分なりに見つけられるかどうか。
うちのチームで言えば、劇的な変化が起きたわけじゃありません。
売上が倍になったとか、離職率がゼロになったとか、そういうドラマチックな話じゃない。
でも、朝のミーティングで冗談が出るようになった。
「このタスク、ミッション名つけるとしたら何？」みたいな会話が増えた。
例の目が死んでいた2年目のエンジニアが、社内勉強会を自分から企画してきたこともありました。
それだけでも、チームの空気は確実に変わります。
完璧じゃなくていい。
小さなギミックを一つ入れてみるところから始めれば十分です。