2020年のふりかえりと2021年の目標的なもの
今更ながら2019年のふりかえりと今年の目標を。
言わずもがな新型コロナウイルス感染症（COVID-19)の影響でワークスタイル・ライフスタイルの両面で大きな変化がありました。
2020年の活動記録
ワークスタイル・ライフスタイル
- 2020年2月末 原則リモートワークとなった
- とはいえ3月下旬まではほぼ毎日出勤していた
- 本格的にリモートワークに切り替えたのは4月に入ってから
- ジムに行けなくなったので早朝ランニングを始めた（4月8日～）
- 2020年4月7日～5月21日緊急事態宣言
- この間はほぼ出勤せず
- 7月くらいからは2～3回/週の出勤とした
- 年末までは同様のペースで出勤
運動
- ランニング
- 147回
- 4/8から開始し平日はなるべく実施
- 結果として週3～4回は走ってたことになる
- 上出来
- サッカー
- フットサル：25回
- フルコートのサッカーはなし
- 所属チームは隔週開催なのでほぼ毎回参加したことになる
- 3/15～6/7まで休止してたのを考えると上出来
- ジム
- 13回
- ほぼ毎週通っていたジムは3/21を最後に行かなくなった
- ジム通いから朝ランに切り替えた
- ゴルフ
- 11回
- ラウンド5回（ショートコース1回）
- 練習6回
- まあまあラウンドをした年だった
- もうちょっと上手くなりたいけど十分楽しいからこんなもんでいいのかも
- 11回
セミナー勉強会参加
10回程度の参加。月に1回と考えるとそこそこかな。
- [DevLOVE]二項対立世界を越えるために何から始められるか
- Developers Summit 2020
- Developers Summit 2020
- リアルの場でのカンファレンスはこれが最後だった
- アンオフィシャルパーティーにも参加したのだった
- PyCon JP 2020
- AWSome Day Online Conference
- Management3.0 Japan Conference 2020
- Agile Tech EXPO 2020 Autumn
- カスタマーサクセス カンファレンス -BRIDGE 2020-
- [デザイン周辺勉強会]第三回 情報設計
- Agile Japan 2020
- 【番外編】クリアソンランニングクラブ
- 陸上元日本代表から学ぶ「走り方の基礎」 30日にオンラインセミナー実施 | Criacao Channel
- 子供（次男、三男）と一緒に参加したのだった
- 元日本代表の方に教えてもらえるとても贅沢な時間
Blog
- 本Blog：2本
- 会社Blog：1本
- 書いたわけではないけど記事にしてもらったもの
その他の活動
- サッカー観戦（スタジアム）
- 読書
- 16冊
- サッカー関連：4冊
- 仕事関連（IT/マネジメント/マーケティング）：12冊
- 電車通勤が減ったので読書量が減った
- 毎年20～25冊くらいだったのだが・・・
- 小説を読まなかった。めずらしい。
- 16冊
- 銭湯・サウナ
- 15回
- 3月17日～8月30日までは行ってなかった
- 池袋の「かるまる」施設の充実ぶりが素敵
- 実家近くの「竹取温泉 灯りの湯」露天風呂から一面の竹林が最高
- 2年前に突然閉鎖した多摩境のホーム銭湯が復活して嬉しい「多摩境天然温泉 森乃彩」
- コーヒー
- 自宅作業増えコーヒーを自分で淹れる機会が増えた
- 豆を選ぶ、淹れ方工夫するなどが楽しい
- 本当に美味しいかどうかより過程が楽しい
- 体重
- 早朝ランニングをはじめ、ランニングついで筋トレもするようになり体重が減った
- 多少筋肉もついたような気がする
- 腕立て：20回×2
- 懸垂：10回×2
- 体幹トレ：片足立ち2種類×2回
2020年トピックス
仕事
- 2019年に引き続き、開発プロジェクトと自社プロダクト部門の責任者として駆け抜けた1年だった
- 2019年から参画した開発プロジェクトをそのままやり抜く結果となった
- 大変なプロジェクトであり、責任もってチームを支えらえた
- 個人的には多少の学びはあるものの、惰性やっている感がある
- 自社プロダクトの開発チームの部門長
- 比較的落ち着いて事業を進められたが、逆に言うともっと成長できるはず
- もっと関わりをもってチームを推進させるべきだった 会社が大きく組織変更をし、そのゴタゴタに直面した年でした。 組織変更あるあるとはいえ、身内のゴタゴタに奔走し消耗してしまうのはツラい。
- 2019年から参画した開発プロジェクトをそのままやり抜く結果となった
手に入れたもの / やったこと
正直、それほどやった感は大きくない1年でした。 本来やりたかった自社プロダクト側のマネジメントにそれほど関与できず、組織のゴタゴタに消耗したような印象です。 ただ、春先までにエンジニア組織の評価制度を大きく変えたことは大きな学びと経験となったと思います。
できなかったこと
- プロダクトをマクロでもミクロでもみること
- 英語の勉強
- 読書
2021年どうするか
大きな学びがないと感じてしまった2020年でした。もったいない。
2021年は、より解像度の高い仕事をチャレンジとなる立場でやっていきたいと感じます。 まだまだ具体的にどうというのはアレですが、何か動いて行こうかと。
Management 3.0 Japan Conferenceに参加しました #m30Jp20
2020/09/12に開催された 『Management 3.0 Japan Conference』に参加してきました。 気になったことなどのメモです。
https://management30.doorkeeper.jp/events/109281 http://management30.jp/m30jpcon/
参加したセッション
- Management 3.0 モデル のエッセンス（前編）
- How we help building happy teams (starting with ourselves!)
- JB(Jean-Baptiste Vasseur)
- http://management30.jp/management-3-0-japan-conference-timetable/#track-b-2
- Management 3.0は組織の対話を促進する
- Navigating The New Ways Of Working
- Managing for Happiness
気になったことメモ
『人ではなく、システムをマネージするべき』
『人ではなく、システムをマネージするべき』 これがManagement 3.0の基本的なテーマということでした。
最後のセッションでファウンダーのJurgen Appeloがアジャイル・リーン・デザイン思考の話をしていましたが、仕組みで現場をよくしていくための方法論がベースにあるのだな、と思いました。 私が普段から意識していることでもあるためとても共感できました。
Management 3.0 モデル のエッセンス
藤井拓さんのセッション（http://management30.jp/management-3-0-japan-conference-timetable/#track-b-1）のメモ
- アジャイル・スクラムにはリーダーシップ・マネジメントで具体的な記載はない
- Management3.0には理論と実践が記載されている
- 線形vs非線形の話
- 予測可能なもの（線形）と予測不可能なもの（非線形）
- システムとその分類
- 構造：複雑⇔単純
- 振る舞い：秩序がある⇔カオス
- ビジネスの状況・環境と組織の関係を考えてみることが大事
- 状況に適応できる組織であるべき
- マネジメント3.0は複雑性思考を適用している
- 複雑適応系（CAS）であるべき
- イノベーションに必要な5要素（知識 / 想像性 / モチベーション / 多様性 / 個性）
- 個性とモチベーションの重要性
- 自己組織化
- 自己組織化は良くも悪くもない（良い方向もあれば悪い方向もある）
- 自己組織化だけでは十分ではない
- 価値のある方向に舵取りをする
- マネージャー３つの役割
- パラメーターを構成する
- 多様性・チーム間のつながり、情報のフローなどを整理すること
- システムを守る
- 安全/公平、気持ちよく快適な状態にする
- システムの方向性を定める
- リーダーシップ
- マネージャーはシステムの外発的目的を設定できる
- パラメーターを構成する
『自己組織化は良くも悪くもない（良い方向もあれば悪い方向もある）』 、『個性の重要さ』 など示唆の富んだ話が聞けました。
対話
高柳さんのセッションで組織の対話がなぜ上手くいかないのか、という話がサラっとありました。 サラっとだったのですが、グサッときたのでメモ。
組織のヒエラルキーをまたいだメンバーでの対話は難しい。 人は自分の階層のことに興味がある。 自分より上の階層の課題・問題はそこにいってみないとわからないため議論のベースが異なってしまう。 課題・問題の捉え方や背景理解が異なるため、容易に対話ができない。
というようなことだったかと思います。 心当たりがありますし、うーん、と考えさせられるお話しでした。
失敗から得た学びを祝おう
失敗は非難してはいけない。そこに学びがあるならば。 非難すれば学びを止めてしまうことになる。 失敗そのものは良くないことではあるが、学びの有無によって振る舞いが変わる。
Jurgen AppeloさんのKeynoteでの学びです。 何よりも学びを大事に。
最後に
その他も沢山よい話が聞け、現場に持って帰れそうなものが発見できました。 『人ではなく、システムをマネージするべき』の精神で今よりもっと良い現場を目指したいと思います。
スピーカー・スタッフの皆様、素晴らしいカンファレンスをありがとうございました。
2019年のふりかえりと2020年の目標的なもの
今更ながら2019年のふりかえりと今年の目標を。
2019年の活動記録
運動
- ジム：37回
- サッカー/フットサル：25回
- ゴルフ（練習/ラウンド）：4回
- ランニング：1回
合計57回。週1回は運動することができた。いい感じ。
セミナー勉強会参加
- Developers Summit 2019
- Criacaoアスリートカレッジ
- DevLOVE X
- Agile Leadership Summit 2019
- メンバーとのコミュニケーションのズレを解消しよう 〜自分と相手を知るワークショップ実践〜
- プロダクト内製化と技術組織づくりの本音と取組み
- XP祭り
- 実践的1on1マネジメント~『エンジニアリング組織論への招待』×『ヤフーの1on1』著者によるスペシャルコラボトーク
- チームビルディングへの招待
- 1on1勉強会 vol.2 リーダーとマネージャーのジレンマ
- Engineer's Recruiting #1 これからのエンジニア採用における経営者の役割
勉強会と呼べるのかどうかあやしいものもあるけど11回参加。月1回ペースなのでそこそこ。
XP祭りではパネルディスカッション形式で登壇もした。
その他
- サッカー観戦：8回
- 温泉/銭湯：13回
応援してるFC東京は惜しくも2位だった。8回はここ数年ではかなり多いほうかな。
温泉・銭湯、サウナに本格的にはまった2019年だった。ジムで筋トレしてサウナ入るのが習慣になった。
仕事
春先から大きなプロジェクトの支援に入り、そのまま大変な状況のまま駆け抜けた1年だった。
プロジェクトやりながらも2部署の管理職をやるなどオーバーワーク気味。やらなきゃいけないのにできなかったことも多い。
手に入れたもの / やったこと
- 大きなプロジェクトをやりきった（まだ続いてるけど）
- プロジェクトでいい開発チーム作りができた
- リスペクトできるクライアント、プロジェクト関係者の方々に囲まれて多くの学びがあった
- 部門長としてチームビルディングの取り組みを始めた
大変なプロジェクトにもかかわらず、とても尊敬できる方々から多くの学びを得られたのが2019年の1番の収穫。本当に感謝。
2020年どうするか
- FC東京はアジアチャンピオンズリーグに参戦する。アジアのどっかに観戦ツアー行きたい
- 仕事は選択と集中を引き続きやっていく。自分のキャリアを考えつつ。自分のキャリアってなんだ。
- サッカーは怪我がちなので治るまでゆるくやる
- 読書量はちょっと増やしたい
- 英語そろそろ勉強したい
書籍「プレー経験ゼロでもできる実践的ゲームモデルの作り方」から組織作りを考える
ソフトウェアを作る会社でエンジニアチームのマネージャーをやってます。
サッカーが大好きで、特に戦略・戦術といったあたりが大好物なので最近気になる「ゲームモデル」の本を読みました。
『プレー経験ゼロでもできる実践的ゲームモデルの作り方』
プレー経験ゼロでもできる実践的ゲームモデルの作り方 (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.
始めるのはいつも自分自身から。さぁ行こう。
組織開発の探求 読書メモ
「組織開発の探求」という本を読みました。
仕事では組織作り、チーム作りなどの課題によく直面するため、組織開発という言葉はなんとなく耳にしたことがありました。
組織をよくするための理論かな、という程度の理解だったので、組織開発の理論を学習するための入門書としてとても参考になりました。
- 作者: 中原淳,中村和彦
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2018/10/18
- メディア: 単行本
- この商品を含むブログを見る
以下は気になったところのメモ。
氷山モデル p.46
見えている部分（問題事象）の背後には「より大きな」原因が隠されている。
それを見える化する。
経験を内省することで「学ぶ」 p.78 p.83
We don't learn from experience. We learn from reflection on our experience. (John Dewey)
我々は経験から学ぶのではなく、経験を内省することで学ぶのだ。（デューイ）
学習や変化の源泉を「経験」とし、変化につながるきっかけとして「ふりかえり」がある。
良い経験も大事だし、よい経験を学びに変えるにはふりかえりが必要。
フッサールの現象学「今-ここ(here and now)」 p.84
現在、起こっている出来事に意識を当て、考えていくこと
対称なのは「あの時、あそこで（there and then）」
組織開発では「今-ここ」を重視し、今からの変化をもたらす場を作る。
フッサールとデューイとフロイト p.95 p.103
- デューイ：
- 「経験」こそが「学習の源泉」である。
- 「経験」を対象化する「リフレクション」から学び、変化することができる
「今-ここ」に焦点をあてる。自明なもの、意識していないものも見える化する。それらをふりかえることで学び、改善できる。
マネジリアル・グリッド p.185
マネージャーの行動スタイルを「人間に対する関心」と「業績に関する関心」の２軸で考えたもの。
組織の効果性と健全性 p.193
ベックバードによる効果性と健全性の定義
<効果性>
- 組織全体、重要な部署・個人が、それぞれの目標達成に向けて、目標と計画に従って業務を行う。
- （組織や職場の）形は機能の従う（問題、課題、プロジェクトによって、どのような人材を組織化するかが決まる）
- 情報源が組織図のどこにあっても、情報源によって/情報源に近いところによって決定がなされる
- 給与の仕組みは、たとえば、マネージャーが以下のことに対して報酬が支払われる（あるいは罰せられる）
- 短期の利益、またはパフォーマンス
- 部下の成長と育成
- 将来性のある仕事をするグループをつくること
- タテとヨコのコミュニケーションは、比較的歪められていない。人々は全体的にオープンで向き合い、気持ちも含めた事実を共有している。
- 個人やグループの間で、勝つか負けるかといった関わりはほとんどない。葛藤や葛藤が生じる状況について、解決すべき問題として、すべてのレベルで常に取り組まれている。
- 課題やプロジェクトについての「葛藤（アイデアの衝突）」がある。そして、対人間のいざこざの衝突にはエネルギーが費やされない。それはすでに解消されているからである。
- 組織とその部分は、お互いに関わり合い、環境とも関わっている。組織は「オープンシステム」になっている。
- 共有された価値観があり、マネジメントはその価値観を支持する戦略を取っている。個人や職場は、それぞれの真摯さと独自性をお互いに助け合いながら維持している。
- 組織とそのメンバーは「アクションリサーチ（行動して-考える）」を行っている。個人やグループは自らの経験から学ぶことができるように、フィードバックのメカニズムが築かれている。
<健全性>
- 合理的に明確で、受け入れ可能で、達成できる、適切な目標がある。
- コミュニケーションの流れが比較的はっきりしている。
- 権力が適切に均衡している。
- リソースの活用、そして、個人の特賞と役割に求められることがうまく一致している。
- 凝集性と組織のアイデンティティが十分にあり、人々がそれに対して積極的につながりたいと感じるくらいの明瞭さと魅力があること。
- モラール（士気）が高い。成長と変革のためには、健全な組織は革新性、主体性、適応性、問題解決力を持っている。
「対人間のいざこざの衝突にはエネルギーが費やされない。それはすでに解消されているからである。」は組織が嫌になる要因として大きい印象がある。
色々と耳が痛い定義...。
X理論とY理論 p.203
X理論は、人は怠けてしまうもので命令・監督をし、目標に達成しない場合には罰を与えることが必要と考える。
Y理論は、人は自己実現をしたい目標のためには自己統制を発揮して主体的に行動すると考える。
組織開発はY理論をベースとしている。
組織開発をする上での倫理観 p.264
①参加すること：自分たちの未来に参加・関与すること
②チーム（職場）を重視すること：組織変革は職場から
③発達・学習を信じること：最も重要な価値観
④人間を「全人格」で見ること（職業<カテゴリー>で見ない/相互尊重/違いを認める）
⑤対話を重んじること
⑥真摯さ、オープンさ、信頼を重んじること
組織開発を行う上で、トレーナー/ファシリテーターは価値観・倫理を重視しなければならない。
自己防御化ルーチン p.284
「組織の欠陥」を見える化は、自分達の失敗をさらけだすことである。
そのため失敗を出すことに消極的になったり、言い逃れをしてしまうことになってしまう。
これが自己防衛化ルーチン。
自己防衛化ルーチンにとらわれたメンバーは問題を隠蔽するようになったり、責任を取ろうとせずにいつまでも改善ができない。
感想
今まで手にしてきたマネジメントやチームビルディングの源流の１つに「組織開発」があることが理解できました。
アジャイル開発でよく用いられるミーティングやワークショップは組織開発の諸々を理解した上で実施するとより効果がありそうです。
（というか今までわからないままやったいたのが少し恥ずかしいくらいです）
また、本に書いてあったように組織開発の知識はマネージャーの大きな武器になるものだと思いました。
今後はもう少し追っていこうと思います。
JSTQB認定テスト技術者資格 Advanced Level テストマネージャ 受験記録
2018-8-25にJSTQB認定テスト技術者資格 Advanced Level テストマネージャを受験し、合格しました。
この資格試験は情報が少なく、手探りでの受験となったこともあり、試験までの対策や試験の傾向など覚えている範囲で記録しておきたいと思います。
何かの役に立てば幸いです。
公式の情報
公式HP
JSTQB認定テスト技術者資格
今回受験したのはAdvanced Levelです。Foundation Levelに合格していることが受験条件になります。
Foundation Levelに合格したのは10年ほど前、JSTQBができた直後だったと思います。受けといてよかったー。
受験に必要なもの
事前に書類審査があり、以下が必要になります。
- Foundation Level認定証番号
- Foundation Levelの認定証（いわゆる合格証書）のコピーが必要です
- 10年前の合格証を探すのに苦労した
- 再発行もしてくれる
- 身分証明書の写し
- 普通に免許証でOK
- 業務経歴申請書
- 公式HPから雛形をダウンロードして経歴を書く
- よくある経歴書と大きく変わりません。記述サンプルがあるので書き方は迷わないはず
「業務経歴の問合せ先」について
サンプルに記載方法の説明があるのですが、
・記入した業務に対して、原則としてすべての承認者を記入してください
・どうしても承認者が記入できない場合は、その理由を記載してください
とあります。
私は転職を数回しており、前職の当時の責任者に連絡が取れる自信がない...。（先方が退職してる可能性も...）
ということでJSTQBに問合せをしたところ、以下の記載で問題ないとのことでした。
「転職したため承認する者と連絡が取れないため氏名は未記入としています」
過去の会社の欄は社名と代表電話番号のみを記載し、氏名は未記入としました。
現職の経歴には現職の上長に押印してもらいました。
申し込みからの受験の流れ
WEB申し込み⇒受験料振り込み⇒書類送付⇒（書類審査）⇒受験票が届く⇒受験
って感じです。
詳しくは公式HPに載ってます。
勉強したこと
シラバス
シラバス（学習事項）
そもそも日本では、Advanced Level試験の学習を公式にサポートする資料が存在しない、とのことなのでシラバスを読むしかないです。
過去問
公式HPから過去問題の資料がダウンロードできます。
「こんな感じの問題がでるのか」が把握できます。
問題数が多ければ対策として有効なんですが仕方なし。
公式の過去問PDF
公式のサンプル問題
どう勉強したか
出題傾向
過去問セミナーの概要資料に載っていました。
- 各章に学習の目的（LO）が明示されている
- 学習の目的（LO）単位で何問出題するか定義されている
- Kレベル（知識レベル）ごとに配点基準が決まっている
これらを把握してシラバスを読むことにしました。
覚えておいたほうがよい箇所
シラバスでリスト形式、箇条書きになっている箇所は怪しいです。受験の対策としては鉄板です。
以下の章はしっかり読み込みました。
- 1. テストプロセス
- 1.3 テスト分析
- 1.8 テスト終了作業
- 2.2.1 テストステークホルダについて
- 2.2.2 その他のソフトウェア開発ライフサイクル活動と成果物
- 2.2.5 経験ベースのテストのマネジメント
- 2.3.1 リスクベースドテスト
- 2.3.1.1 リスク識別
- 2.3.1.2 リスクアセスメント
- 2.3.1.3 リスク軽減
- 2.3.4 テストプロセスにおけるテストの優先度付けと工数の割り当て
- 2.4 テストドキュメントとその他の成果物
- 2.4.1 テストポリシー
- 2.4.2 テスト戦略
- 2.4.3 マスターテスト計画
- 2.4.4 レベルテスト計画
- 2.4.5 プロジェクトリスクマネジメント
- 2.5 テストの見積り
- 2.6 テストメトリクスの定義および使用
- 2.7 テストのビジネスバリュー
- 2.9 業界標準適用のマネジメント
- 各標準が何を目的としているものなのか、適用範囲はどのあたりかをしっかり理解する
- 3.2 マネジメントレビューと監査
- 3.4 レビューのためのメトリクス
- 3.5 公式レビューのマネジメント
- 4.2.1 欠陥ワークフローと状態
- 4.4 欠陥レポート情報によるプロセス能力の評価
- 5.2 テスト改善プロセス
- 5.3 テストプロセスの改善
- 5.4 TMMiによるテストプロセスの改善
- 5.5 TPI Nextによるテストプロセスの改善
- 5.6 CTPによるテストプロセスの改善
- 5.7 STEPによるテストプロセスの改善
- 各手法の特徴、目的をしっかり理解する
- 6.3 ツールのライフサイクル
- 7.2 個人のスキル
- 7.4 組織内におけるテストの適合
- 7.6 コミュニケーション
...多い。ほとんど全部じゃないか疑惑...。
雑感
テスト時間が長い
3時間集中するのは大変です。
終わったらヘトヘトでした。
暗記勝負の問題があったのは少し残念
現場の状況や事情によっては正解っぽい選択肢が２～３あってどれが正解か迷った問題がいくつかありました。
たぶんシラバス通りに書いてあることが正解なんだと思いますが、記憶勝負になっているのはあまり本質的じゃないと感じました。
そりゃ覚えていたほうがよいのですが（覚えるの苦手なので...）、少しテンション下がります。
最後に
久しぶりに資格取得にチャレンジしましたが、とてもためになりました。
体系的な知識は普段から勉強すべきですね。
サッカーの戦術トレンドから考えるソフトウェア開発チームのマネジメント
2018 FIFA ワールドカップが開幕しました。
戦術やプレーモデルが高度化し、個人においても高い戦術理解度が求められる昨今、代表チームにおいても戦術をしっかり仕込んだチームが優位性を持つようになってきました。
（準決勝でドイツがブラジルに7-1で勝ったのは戦術レベルでの優位性が大きかったと言われています）
それから4年を経て、さらなる戦術の高度化を具現化したチームが多くなると言われているのが2018 ロシア大会です。
そんなワールドカップを観つつ、サッカーの戦術トレンドとソフトウェア開発チームのマネジメントについて考えてみます。
サッカーの戦術トレンド「ポジショナルプレー」
モダンサッカーの教科書 イタリア新世代コーチが教える未来のサッカー
- 作者: レナート・バルディ,片野道郎
- 出版社/メーカー: ソル・メディア
- 発売日: 2018/06/04
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
「ポジショナルプレー」とは、プレイヤーはあらかじめ決まったポジションのタスクをこなすのではく、局面においてより適切なポジションとタスクを流動的に遂行するという考え方です。
チェスでは古くから使われてた概念のようです。
サッカーの世界ではかのヨハン・クライフが世界を席巻した「トータルフットボール」をより進化させたものと言えるでしょう。
「ポジショナルプレー」における主要な原則
ポジショナルプレーを考えるにあたりいくつか重要な概念がありますが、この場では以下に注目します。
- 3つの優位性（数的優位性、位置的優位性、質的優位性）
- プレイヤーのタスクの変化
- シームレスな攻守の切り替え
- コーチとしてのマネジメント
３つの優位性
数的優位性
| サッカー | ボールの周囲に多くの人数を配置すること |
|---|---|
| ソフトウェア開発 | 開発に必要なチームを構築すること / 重要な局面にリソースを集中させること |
ソフトウェア開発では十分な人数を揃えること、限られたリソースを必要な局面に集中させることにあたります。
基本的な考えであり、3つの中では重要度が低いものです。これを実施することに意味はありますがこれだけでは圧倒的に優位性は作り出せません。
位置的優位性
| サッカー | 相手プレイヤーの隙間/死角/逆サイドなど戦略的に相手チームが嫌がる位置に人を配置すること |
|---|---|
| ソフトウェア開発 | ソフトウェアの各レイヤーに適切に人を配置すること |
ソフトウェア開発では開発工程、アーキテクチャ的なレイヤー、サブシステムなど様々な分割ができます。
数的優位性として人を集めてワーワーするだけではなく、
リスクのある箇所に適切に人を配置することで強固なチームとなり、より良いシステムとなることでしょう。
質的優位性
| サッカー | 選手のクオリティにより目的達成（得点/守備）の確率を上げること |
|---|---|
| ソフトウェア開発 | 技術レベルの高いメンバーによる高品質の実現 |
最後に質的優位性です。
数的優位性、位置的優位性を実現した上で、仕事の成功率をより高めるための考え方です。
ソフトウェア開発では、質の違いを生み出せる優秀なエンジニアにどこで戦ってもらうのか、という考え方となると思います。
プレイヤーのタスクの変化
ポジショナルプレーの概念においては、決まった固定的なポジションのタスクのみをこなすことはありません。
目的（勝利）を達成するために、その局面において適切なポジションに移動し適切なプレーを選択し続けなければいけません。
ソフトウェア開発では、アジャイル開発手法において「クロスファンクショナルチーム」（マルチファンクショナルチームとも言います）が提言されています。
センターフォワードが守備をしなくてもよかった時代は終わり、味方と連動して守備を行うことが必須なりました。ディフェンスの選手も足元のテクニックやパス技術が要求される時代です。（最近はゴールキーパーにも要求されます）
ソフトウェア開発でも、仕様を考える/プログラムを書く/テストをする、という役割分担ではなくその局面で適切な働きをすることで目的（ビジネスの成功）を目指す必要があるでしょう。
（エンジニアがマーケティングをサポートしたり、営業担当者がデータ分析を行うなど）
もちろんサッカーでもソフトウェア開発でも得手不得手があるのでチームとしてどうなっているべきかに注目すべきです。
シームレスな攻守の切り替え
サッカーでは攻めと守りの区切りがありません。
統計上、ボールを奪ってからの速攻で多くのゴールが達成されており、攻撃と守備の切り替えが重要であることがわかります。
勝利のためには攻撃が重要ですが、同時に失点のリスクを減らすことも求められます。
攻撃的な戦略とリスク低減は一見相反している概念ですが、バルセロナの6秒ルール（ボールを失ってから6秒間激しくボールを奪い返しにかかる）、最近話題の偽サイドバックなどが実装方法として有名です。
いずれも攻撃の戦略が守備の戦略（リスク低減）に繋がっています。
ソフトウェア開発では「DevOps」が該当する概念でしょうか。
「開発」と「保守運用」を分ける/分けないに是非はありますが、流動的なビジネス環境において分業化・固定化することによるリスクは少なからずありそうです。
コーチとしてのマネジメント
最後にコーチとしてチームをどうマネジメントするのか、を考えてみます。
ポジショナルプレーの先駆者であるグアルディオラは、
「前線のアタッカーに良い（クリーンな）ボールを届ける戦術をチームに与えること」
をコーチの重要な仕事の１つとしています。
得点の確率を高めるために３つの優位性、とりわけ質的優位性を考えてクオリティの高いアタッカーに良い仕事をさせる。そこから逆算してチームとしてどう動くべきかを仕込むのです。
"仕込む"ことが重要な仕事です。ただ言葉で説明する、試合中に叫ぶだけでは選手が実践できるとは思えません。
狙い通りのプレーができるように、試合の映像を見せ、狙い通りのプレーの再現性を高める練習メニューを考案し実践します。
ソフトウェア開発におけるマネージャーはどう考えるべきでしょうか。
- チーム・組織の目標とは何か
- 目標を達成するための戦略は何か
- どのような動きをチームに要求するか（再現させたい動きは何か）
上記を考えるために、
インセプションデッキ、OKR、ふりかえりなどのフレームワークを活用してチームに良い戦略を与えるのがマネージャーの仕事と言えるでしょう。