ソフトウェアを作る会社でエンジニアチームのマネージャーをやってます。
サッカーが大好きで、特に戦略・戦術といったあたりが大好物なので最近気になる「ゲームモデル」の本を読みました。
『プレー経験ゼロでもできる実践的ゲームモデルの作り方』
プレー経験ゼロでもできる実践的ゲームモデルの作り方 (footballista)
- 作者: 脇真一郎
- 出版社/メーカー: ソル・メディア
- 発売日: 2019/07/27
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
ソフトウェア開発とサッカーは共通点が多いと確信してまして、こういう本から仕事のヒントを得られるのが楽しいです。
以下は『プレー経験ゼロでもできる実践的ゲームモデルの作り方』のエッセンスをソフトウェア開発のチーム作りに活かせるかを考えたメモです。
そもそもゲームモデルとは（p.21、p.50）
- チームそのものの「IDカード」
- チームが向かうべき「目的地」
- チームが立つべき「土台」
- チームが戦うための「取説（取扱説明書）」
- チームを評価する「物差し」
抽象的な「ゲームモデル」を5つのポイントに落とし込んでます。
これはそのまま組織作り・チーム作りに活かせそうです。
プロジェクト単位でいうと、PMBOKにおける「プロジェクト憲章」やアジャイル開発でよく使う「インセプションデッキ」と似たようなアプローチでしょうか。
組織作りだとミッション・ビジョン・バリューのようなイメージかな？（ちょっと違う気もする）
いずれにせよ抽象的なものを段階化して言語化し、メンバーが理解できるものに落とし込む作業です。
チームのIDカード作り（p.75）
まずはステップ1。IDカード作りです。
「君のチームってどんなチームなの？」 皆さんはどう答えますか？
まずは「チーム内用語」からです。
抽象的な「ゲームモデル」を考えるにあたり、まずは我々のやっていることの構成要素を出してチーム内の共通言語（用語集）を作り、そこからチームのアイデンティティとは何かを考えます。
ただ、サッカーだとなんとなくわかる気がするのですが、組織作りでこのステップから始めるのは違和感があります。
構成要素の抽出は自分達の仕事を言語化するのに役立ちますし、そこから色々見えてきそうなので良さげ。
開発チームだと自社・クライアントのビジネスにどういう貢献をするのか、ということを定義することでも良さそうです。
ここはちょっと要検討。
チームの目的地作り（p.81）
ステップ2。
「チームはどうありたいのか」ということと「チームはどうあれるのか」
理想と現実とも言い換えられる。
目標やマイルストーンです。
長期、中期、短期と区分したほうがよいとのこと。短期的な目標がより日々の行動に直結することになるのでそこを意識すること。
マイルストーンを決めて、そこで何を達成するか、どういう状態になっていたいかを決める。良さげです。
チームの土台作り（p.88）
ステップ3。
サッカーというスポーツが「意思決定のスポーツ」である限り、チームにはその「意思決定の根拠」となるものが必要です。
チームのプレー原則を落とし込みます。より具体的な行動規範となるものでしょうか。
サッカーでは局面（ボール保持時/非保持時）ごとに行動の原則を定義します。
（ボール奪取時、ボール喪失時を含めて4局面とすることが多いです）
ソフトウェア開発では様々な局面の軸がありそうです。
自チームがどのようなポジションにいるのかを把握した上で考えるべきでしょう。
・自社プロダクトの開発や運用をやっているチーム：新機能開発 / 技術的負債の改修
・ウォータフォール型の開発をやっているチーム：開発工程（設計/開発/テスト）
ビジネス的なポジション（新領域/既存領域、First-mover/Second-mover）も大事な要素になりそうです。
チームの取説作り（p.93）
ステップ4。ここがキモ。
チームにおける各プレーに「再現性」を与えることが大切なのは皆さんもおわかりだと思います。ステップ3で定めた「プレースタイル（主原則）」を実現させるためのより具体的な「プレー原則（準原則）」を言語化・整理して、チームの取説を作ってみましょう。
より具体的に局面ごとに意思決定ができる状況と行動を定義します。
要するに優先順位の決め方なのかな、と。アジャイル開発における計画ミーティングでの「優先順位をどう決めるのか」をある程度決めておきましょう、という取り組みでしょうか。
アジャイル開発（スクラム）ではプロダクトオーナーが優先順位を決めることになっていますが、「なぜこの優先順位なのか」がしっかり説明され腹落ちしていない状態ではチームは良いパフォーマンスを出せません。
優先順位をどう判断するのかがチームで言語化されていると腹落ち度は高まるでしょう。
チームの物差し作り（p.116）
ステップ5。最後のステップ、というか定期的に行うものですね。
「ゲームモデル」を1つの共通尺度として作成・共有しておけば、選手個人に対してもチーム全体に対しても「その場限り」ではない評価軸が存在することになります。
それはきっとチームが進んでいく上で「迷走」を避けていく非常に有用な手段ではないでしょうか。
「チームの迷走」。これは耳が痛い。
その場限りの評価や意思決定を重ねていくことはマネージャーとして恥ずかしいことです。
またこれはアジャイル開発における「ふりかえり」そのもの。
ふりかえりの手法はいくつかありますが、王道である「目標に対してどうだったか」をベースにする考え方でしょう。
評価軸が共有されていれば出来た事・出来なかった事がわかりやすくなります。
その他気になったところメモ
試合のために練習がある、練習のヒントは試合にある
練習メニューを作るヒントがどこにあるかって言ったら試合なんです。練習でしなきゃいけないことはその試合の中で全部起きてますから、練習メニュー本なんで開いている暇があったら今目の前の試合を見てくれって話ですよ
とても大事なことです。現場で何が起きているのか、何ができていて何ができていないのか。
フッサールの現象学「今-ここ(here and now)」の話。
プレーモデルとは
僕はピッチ内における『ビジョン』なのかと思っています。未来の『ありたい姿』『あるべき姿』なのかなと。
あなたのチームのゲームモデルはなんですか？と聞かれた時に一言で答えられるくらいのものという
解釈は様々なようですが、シンプルに言えるくらい突き詰めることが大事そうです。
公開して共感してもらう
他と差別化するためにゲームモデルを一目でわかるように明らかにしてSNSで発信して、ビジョンも掲げました。うちに入りたいと思ってくれる人をいかに増やすかというところに力を割いてます。
ビジョンやゲームモデルでいかに共感を得るか
共感を得ることの重要性。組織作りでも同じですね。「我々はこういう会社です」がわかりやすいほうが採用もしやすいし共感を持ってくれた人がきてくれるのは嬉しい。
オープンな議論
「ゲームモデル」に留まらず、自分自身のブラッシュアップを望むのであれば、情報公開は1つの大きな選択肢になるはずです。
「今日の弱みをさらしてでも明日の強さを手に入れたい」と願い指導者も存在しています。私自身がまさにそうで、わからないことやできないことを誤魔化すのではなく、堂々と乗り越えていきたいと思って行動してきたつもりです。
なぜなら、自チームの選手たちにそうあってほしいからです。
「指導者がやりもしないことを選手たちに求めるのはナンセンス」という信念を持っているゆえに、ゲームモデル公開も自然なこととして行いました。
「ゲームモデル」は本来ならチーム内部で共有するものであり、あえてSNSなどで外部発信することはライバルチームに弱点を見せてしまことでもあります。
それでも発信するのは指導者としてもう1歩進むため。さらにサッカー界の発展に貢献するため。
『今日の弱みをさらしてでも明日の強さを手に入れたい』いい言葉です。
感想
「ゲームモデル」を組織作りに活かせそう、と感じたものの何からやればよいのか悩んでる時にこの本を読み始めました。
落とし込み方の1例にすぎないと著者も書いてますが、具体的なステップはとても参考になりました。
そして組織作りは一朝一夕で出来るものではなく積み上げていくものであり、ゲームモデルを定義することも大事だけど、決めるプロセス（皆で話し合う）も同じように大事なのだと思います。
俺たちのゲームモデル、と言えるチームが良いチームなのでしょう。
そして「指導者がやりもしないことを選手たちに求めるのはナンセンス」にドキッとして以下の言葉を久しぶりに思い出したのでした。
Social change starts with you.
始めるのはいつも自分自身から。さぁ行こう。
