こんにちは！！
生まれてブログを書きます！！やりみずです！！
日本語が不自由ってよく言われますが、頑張って書いていこうと思います。
さて、今回のブログの内容ですが、
自分は直近ゲーム開発に携わっておりまして、
しばしばプロジェクトの失敗やチーム内の衝突を経験しております。
その度によく「どうやったらプロジェクトってうまく行くのだろう」と考えます。
この場合の「うまく行く」というのは事業的な話ではなく、組織（チームビルディング）的な話です。
言い換えると、
「どうやったらチームメンバーが全員同じ方向を向いて気持ちよく仕事できるだろう」
という感じでしょうか。
そうこうして色々調べて得た知見や、自分自身のマネジメント経験（遥か昔のことなので当時の記憶を掘り起こしつつ、）
を踏まえ、
「いいチームを作るためにこうしたらいいんじゃないか/こういう知識が必要なのでは」
というtips的なものをいくつか紹介したいと思います。
タックマンモデル
まずは基本的なところから。
組織形成の分野で有名な理論としてタックマンモデルというモデルが存在します。
心理学者のタックマンが組織進化を5段階のモデルで表現できるとしたものです。
具体的な内容については以下の記事を参考にしていただくといいかもしれません。
https://heart-quake.com/article.php?p=396
理想は「機能期」までチームを持って行くことです。
この状態になると、各々が自分の役割を完全に理解し、自走できる状態になっています。
こうなるともはやマネジメントは必要ありません。
ここで大事なことは、こうした理論を知ることで、
自分の組織の現状把握や改善のためのネクストアクションが自ずと見えてくるということです。
心理的安全性と責任
「心理的安全性」という言葉は個人的には「良いチーム作り」において避けて通れないものであると考えています。
これは各メンバーが「チームの中でどんな発言をしても、自分の立場が脅かされることはないだろう」というような心理状態であることです。居心地がいいとかよりも、「遠慮なく発言できること」です。
下図は『チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ』という書籍で紹介されているものです。
基本的に、そのチームが最もベストな状態になるのは、責任が大きくて心理的安全性が大きい状態を指します。（図の右上の状態）
この状態になると、メンバーはは学習をしながらチームできちんと問題を解決していく状態になります。
自分の経験上ゲームの運用タイトルは図右下の状態になりやすい気がしています。（特定の人に負荷がよってしまっている状態です）
この場合人が辞めやすい傾向にあるので改めて負荷を均一化したり開発効率化に注力したりする必要があります。
1 on 1でフレーミング
これも最近出版された『ヤフーの１ｏｎ１―――部下を成長させるコミュニケーションの技法』で有名になりましたね。
いわゆる一対一の面談です。自分がマネジメントを行なっていた時代はこれを特に気をつけて行なっていました。
何を意識していたかというと「フレーミング」と言われるものです。「期待値調整」ともいいます。
マネージャーから「こういうことやってほしい」と伝えるだけじゃなくて、物事の見方をなるべく正しい方向に持っていくのがフレーミングです。これをちゃんとやるというのが、組織マネジメントをする上で最も根本的に利いてくるそうです。
実際自分もよくメンバーと意見の食い違いや、自分の期待通りに動いてくれないことが多々ありましたが、月一の面談でフレーミングを意識して対話することで最終的にはチームを学習の場まで持って行けたと思っています。
愚者は経験に学び、賢者は歴史に学ぶ
長々と書いてきましたがまとめに入ります。
これまで本やネットで調べたような知識を紹介する形になりました。
とはいえ実際の現場は千差万別、一般知識など通用しないと思われるかもしれません。
しかしながら、僕個人はこうした知識を得ることは決して無駄ではないと思っています。
古今東西、多くのプロジェクトがチームビルディングで悩んできました。そうして悩んだ末に出た答え、共通化した手法が書籍やネットで公開されています。
その知恵を学ばない手はありません。
ドイツの名宰相であるオットー・ビスマルクは「愚者は経験に学び、賢者は歴史に学ぶ」と言いました。
この言葉はめちゃくちゃ意訳されているので、丁寧に訳すと、
「私は最初から自分の誤りを避けるため、他人の経験から学ぶのを好む。」
ということらしいです。
市場のクオリティ向上に伴いゲーム開発期間はどんどん伸びて行きます。仮に3年,4年とかけた結果、プロジェクトが失敗に終わった時、その一回の失敗からかけた年月分の知見を得られるでしょうか。自分はそうは思いません。自分の経験だけでは足りないのです。
プロジェクトの成功確度を上げるためには自分の経験だけでなく、社内、他社などに広く教訓を求め活用することが大切だと思います。
また、失敗してしまったプロジェクトがなぜ失敗してしまったのかをしっかりと分析し、知見として広めることで他のプロジェクトを救うことにもなります。
なぜ失敗したのかを経験則ではなく、しっかりと振り返り言語化できるように標準化したプロジェクトマネジメント手法をおすすめしたいのですが、それはまた別の機会に紹介します！
それでは！