勉強会と呼べるのかどうかあやしいものもあるけど11回参加。月1回ペースなのでそこそこ。XP祭りではパネルディスカッション形式で登壇もした。応援してるFC東京は惜しくも2位だった。8回はここ数年ではかなり多いほうかな。温泉・銭湯、サウナに本格的にはまった2019年だった。ジムで筋トレしてサウナ入るのが習慣になった。春先から大きなプロジェクトの支援に入り、そのまま大変な状況のまま駆け抜けた1年だった。プロジェクトやりながらも2部署の管理職をやるなどオーバーワーク気味。やらなきゃいけないのにできなかったことも多い。やったこと大きなプロジェクトをやりきった(まだ続いてるけど)プロジェクトでいい開発チーム作りができたリスペクトできるクライアント、プロジェクト関係者の方々に囲まれて多くの学びがあった部門長としてチームビルディングの取り組みを始めた大変なプロジェクトにもかかわらず、とても尊敬できる方々から多くの学びを得られたのが2019年の1番の収穫。海外(ベトナム方面)への貢献プロジェクトに集中してしまいこれらにはほぼ関われなかった。2020年どうするかFC東京はアジアチャンピオンズリーグに参戦する。アジアのどっかに観戦ツアー行きたい仕事は選択と集中を引き続きやっていく。自分のキャリアを考えつつ。自分のキャリアってなんだ。11:592019年のふりかえりと2020年の目標的なものTweet広告を非表示にするもっと読むコメントを書く2019-09-10書籍「プレー経験ゼロでもできる実践的ゲームモデルの作り方」から組織作りを考えるソフトウェアを作る会社でエンジニアチームのマネージャーをやってます。サッカーが大好きで、特に戦略・戦術といったあたりが大好物なので最近気になる「ゲームモデル」の本を読みました。単行本(ソフトカバー)この商品を含むブログを見るソフトウェア開発とサッカーは共通点が多いと確信してまして、こういう本から仕事のヒントを得られるのが楽しいです。以下は『プレー経験ゼロでもできる実践的ゲームモデルの作り方』のエッセンスをソフトウェア開発のチーム作りに活かせるかを考えたメモです。抽象的な「ゲームモデル」を5つのポイントに落とし込んでます。これはそのまま組織作り・チーム作りに活かせそうです。プロジェクト単位でいうと、PMBOKにおける「プロジェクト憲章」やアジャイル開発でよく使う「インセプションデッキ」と似たようなアプローチでしょうか。組織作りだとミッション・ビジョン・バリューのようなイメージかな?(ちょっと違う気もする)いずれにせよ抽象的なものを段階化して言語化し、メンバーが理解できるものに落とし込む作業です。チームのIDカード作り(p.75)まずはステップ1。皆さんはどう答えますか?まずは「チーム内用語」からです。抽象的な「ゲームモデル」を考えるにあたり、まずは我々のやっていることの構成要素を出してチーム内の共通言語(用語集)を作り、そこからチームのアイデンティティとは何かを考えます。サッカーだとなんとなくわかる気がするのですが、組織作りでこのステップから始めるのは違和感があります。構成要素の抽出は自分達の仕事を言語化するのに役立ちますし、そこから色々見えてきそうなので良さげ。開発チームだと自社・クライアントのビジネスにどういう貢献をするのか、ということを定義することでも良さそうです。ここはちょっと要検討。チームの目的地作り(p.81)ステップ2。理想と現実とも言い換えられる。区分したほうがよいとのこと。短期的な目標がより日々の行動に直結することになるのでそこを意識すること。マイルストーンを決めて、そこで何を達成するか、どういう状態になっていたいかを決める。チームの土台作り(p.88)ステップ3。サッカーというスポーツが「意思決定のスポーツ」である限り、チームにはその「意思決定の根拠」となるものが必要です。チームのプレー原則を落とし込みます。具体的な行動規範となるものでしょうか。サッカーでは局面(ボール保持時/非保持時)ごとに行動の原則を定義します。(ボール奪取時、ボール喪失時を含めて4局面とすることが多いです)ソフトウェア開発では様々な局面の軸がありそうです。自チームがどのようなポジションにいるのかを把握した上で考えるべきでしょう。・ウォータフォール型の開発をやっているチーム:開発工程(設計/開発/テスト)ビジネス的なポジション(新領域/既存領域、First-mover/Second-mover)も大事な要素になりそうです。チームの取説作り(p.93)ステップ4。チームにおける各プレーに「再現性」を与えることが大切なのは皆さんもおわかりだと思います。ステップ3で定めた「プレースタイル(主原則)」を実現させるためのより具体的な「プレー原則(準原則)」を言語化・整理して、チームの取説を作ってみましょう。具体的に局面ごとに意思決定ができる状況と行動を定義します。要するに優先順位の決め方なのかな、と。アジャイル開発における計画ミーティングでの「優先順位をどう決めるのか」をある程度決めておきましょう、という取り組みでしょうか。アジャイル開発(スクラム)ではプロダクトオーナーが優先順位を決めることになっていますが、「なぜこの優先順位なのか」がしっかり説明され腹落ちしていない状態ではチームは良いパフォーマンスを出せません。優先順位をどう判断するのかがチームで言語化されていると腹落ち度は高まるでしょう。チームの物差し作り(p.116)ステップ5。最後のステップ、というか定期的に行うものですね。「ゲームモデル」を1つの共通尺度として作成・共有しておけば、選手個人に対してもチーム全体に対しても「その場限り」ではない評価軸が存在することになります。それはきっとチームが進んでいく上で「迷走」を避けていく非常に有用な手段ではないでしょうか。