「いまここ」を受け入れる ~ RSGT2020に参加しています ~
まだ最終日のOSTを残していますが、ブログはアツいうちに書け...ということで参加レポートを！
TL; DR
- ことしは登壇しました
- "It is NOT good, It is NOT bad."
- 心に留めて生きていきます
- チームと組織
- 組織ってなにものなのかよくわからなくなりました
- 来年も参加したい！
今年は登壇しました
32/175, 採択率 18% ...！ 多くの魅力的なプロポーザルの中、自分のプロポーザルを採択いただいたのは素直に嬉しかったです。 その分プレッシャーも大きく、年末年始は気が気じゃなかったのですが...
資料はこちらになります。
日本語 speakerdeck.com
English speakerdeck.com
僕たちのチームの一年間分のトライを、一ヶ月かけてじっくり言語化しました。 完全にパーキンソンの法則で年末年始もすべて注ぎ込んでしまったのですが、おかげさまでセッションは概ねご好評いただき、 気づけばはてブホットエントリにも入って多くの方の目に届けることができ感謝感激です。
事前のレビューを手伝ってくださった方々にもう一度感謝を！
"SPEAKER" のバッジも、登壇後のサインも、憧れの遠い世界のように感じていたことが、ちゃんとつながっているんだなぁ...というのが登壇後の率直な感想です。 会場の優しさに助けられて、登壇自体はとても楽しく終えられました。 「笑顔でやる」というXP祭りの反省も活かせたと思います。
反省点としては...、とにかくぼくは喋りたいことを喋りたいだけ喋るセッションになりがちで、またやってしまいました。
要点を絞って、一つのアイディアを、聞いてくれる方が受け取れるスピードで話す...
と、去年は４回位発表させて頂く機会があって毎回感じているのに改善できていないです。 スライド書き直すたびに量が増える病に... まあ言い訳ですね。 具体的な改善方法がわからないのです、一回全部捨てて組み直すとか...？
あと英語スライドを別途準備したのですが、スライドの内容減らしてでも同じスライドの中に書くべきでした。 スピードも早かったので英語話者の方を置き去りにしてしまい、実際英語話者の方から「わからなかった」とフィードバックいただきました。 せっかくの同時通訳セッションだったのに申し訳ないことをしたな、というのが心残りです。
"It is NOT good, It is NOT bad."
初日のKeyNoteは、CSMで鍛えてもらった Cope こと Jim Coplien氏。 竹刀を持って 'Do you have some sake?' と言いながら入場してくる彼の世界に一発で引き込まれてから、あっという間に時間が過ぎました。
一応メモです。
"It is NOT Good, It is NOT Bad. It is about where you are." 「良いとか悪いとかじゃなくて、あなたの 'いまここ' だ」
と繰り返しおっしゃっていたのが非常に印象的で、深く心に残っています。
あと「これはスクラムか？」という質問は間違っている、という旨の発言があったと思うのですが、 このあと自分のセッションで
「スクラムガイドに書いてあることちゃんとやってるでしょ。これは正しいスクラムですね。」
みたいな主張をしようとしていた自分に気がついて猛省しました。
とかくなにかを良いとか悪いとかで評価しがちで、また人の評価をすごく気にしてる自分がいるなと。 よかったですか？おもしろかったですか？とか。 それは一回置いといて、ありのままのいまここをとりあえず認めよう。
...とか思ってたら、しいばさんの資料で同じようなことがでてきました。すごい。
残念ながらしいばさんのセッションは聞けなかったのですが、資料はストライクど真ん中でぶっ刺さりました。 これは聞きに行きたかった...
チームと組織
２日めはMichael K Sahota氏のKeyNoteから。こちらも一応メモを。
Management3.0とも近いものを感じました。 Agileやるにはやっぱり組織の後ろだてがいるかー、と。 トップのマインドセットから変えるのが大事だ。非常に納得感のある話でした。 一方、トップのマインドを変えるのが一番難しいのでは、ぼくみたいな一兵卒がやれることとは...とも考えました。
午後はきょん@kyon_mm さんと及部@TAKAKING22 さんの、チームに関する深いセッションを続けて。
きょんさんのセッションは去年初めて聞いた時は完全にキャパオーバーで、半分くらいで 「ライフはもうゼロよ！」 だったのをよく覚えているのですが、今年は最後までついていくことができました。
超個体を目指す上で一番自分が邪魔だった... #RSGT2020
— Ikuo Suyama (@martin_lover_se) 2020年1月9日
自分でこれ言えるのすごい...。
この気付きも収穫でした。
@kyon_mm さんありがとう
— Ikuo Suyama (@martin_lover_se) 2020年1月9日
きっとぼくもそうだ。だからモブが好きなんだ
#RSGT2020 pic.twitter.com/IXBpgWdDdt
異なるプロジェクトのメンバーが同じチームとして働く、というコンセプトだったと思うのですが、これは応用できるかも。
及部さんのセッションはチームごと移籍した「team based team」の話。 隣の人と議論してください！でぱっと右をみたらなんといくお@dora_e_mさんという軌跡ｗ
記念写真を @martin_lover_se さんと！ #RSGT2020 pic.twitter.com/mo2Qe7RvRs
— ikuodanaka (@dora_e_m) 2020年1月9日
「チームはいつ死ぬのか？」というタフクエスチョンに始まり、ライフサイクルに応じたチーミングやゲーミングモデルなど、「チームとは？」について多くの新しい気付き、学びがありました。
突然の死もある #RSGT2020 pic.twitter.com/boIB6pbgRb
— Ikuo Suyama (@martin_lover_se) 2020年1月9日
どちらもチームに関する認識をアップデートする、素晴らしいセッションでした。
最後にあらた@aratafujiさんのセッションへ。
きっちり笑いを取り、参加者を勇気づける最高のセッションでした。エネルギー、パッションにただただ圧倒されます。
ほんと尊敬してます。
尊敬します #RSGT2020 pic.twitter.com/OfUa6AU2I5
— Ikuo Suyama (@martin_lover_se) 2020年1月9日
見習います #RSGT2020 pic.twitter.com/357bj4f5aE
— Ikuo Suyama (@martin_lover_se) 2020年1月9日
「組織目線でスケールを目指さず、チーム目線で始める」
なるほど、と。
ここまで今日聞いた話を自分の中で消化しようとしていたら、混乱してきました。 僕は目線がチームで、組織については正直ほとんど学んでいません。今のところあまりモチベーションがない、というのもあります。 今日の話を聞いて、チームの境界は認識できるのですが、組織というやつがよくわからなくなってしまいました。 多分そのポジションにいないというのもあると思うのですが。
チームが組織に与える影響ってなんだろう、あるいはその逆は。 というかそもそも組織ってなんだ。 ちょっとまだうまく言語化できてないですが、あしたのOSTで議論したいことがぼんやりと浮かび上がってきました。
最後に、これトイレに張った人天才だと思います。
トイレで発見。天才か。
— Ikuo Suyama (@martin_lover_se) 2020年1月9日
ギャザる！！ #RSGT2020 pic.twitter.com/POl2HLpKyJ
来年も参加する！
まだ一日ありますが、やっぱりRSGTは最高に楽しい場。 今年は一日目が登壇で頭が一杯で怒涛に過ぎ去ってしまって、もっとこの場に居たいという気持ちが強いです。
来年も参加したい！いや、ぜったい参加する！ コミュニティでシェアしたい内容が見つけられたら、またプロポーザルにもチャレンジしたいと思います！
あなたのチームはどんなモブ？モブプログラミング・フォーメーション！
この記事はモブプログラミング Advent Calendar 2019 ７日目の記事です。
モブプログラミング(以下モブプロ)とは... いつものやつ貼っておきますね。
モブプロが大好きでして、実務でもチームのデフォルトの働き方としてモブプロを採用しています。 今年はXP祭りなどでもモブプロについて発表させていただきました。
開発フォーメーション
あるきっかけで、「カイゼンジャーニー」「正しいものを正しくつくる」の著者である市谷 聡啓(@papanda)さんと「開発フォーメーション」についてお話しさせていただく機会がありました。
そう、フォーメーションです。全然詳しくないんですが、サッカーとかラグビーとかのスポーツにもこういう概念がありますよね？ 攻撃的な陣形！とか。もちろんこんな低解像度の理解でやってないと思いますが...
僕が一番遊んだサッカーゲームといえば「ロックマンズサッカー」ですが、それにも確かあったような。。 まあサッカーでこんなドマイナーゲームが出てくる程度にはスポーツ素人とお考えいただければと思います。
とにかく、フォーメーションは模倣することで意図する効果を引き出しやすくするための "カタ" であり、またそのフォーメーションの意図をチームが理解し、練度が高まれば、フォーメーションが決まれば戦術も決まるという具合に専門家の会話のような効果もあるのかなと思います。 これをソフトウェア開発でもやってみよう、と。
開発フォーメーションは、市谷さんにより「曳光弾開発」や「雁行陣開発」が紹介されています。
モブプロ自体が一つの開発フォーメーションだな、と思う一方、もっと解像度を上げてみると、モブプロをやっているときでもチームやコンテキストによって色々なやり方を取っていることに気が付きました。
フォーメーション、つまり "カタ" を知っておき、その時のコンテキストや対応したい問題に合わせてフォーメーションを選択できるようになれば、先人たちが踏み抜いた地雷 - アンチパタンを無駄に踏むこともなくなり、より良いモブの発展に貢献できるのでは、と。
市谷さんとお話したことを思い出して、（これも詳しくもないのに、、）フォーメーションをパタンの形式でまとめてみることにしました。 これがモブプロのパターンですと言いたいわけではなく、なんとなく直感的にパタンの形式で記述したほうが説明しやすそうだなと感じたのでやってみました。 パタンを抽出できるほどモブの場数を踏んでないですし、フォーメーション間の関連とか全く整理できてないですし、誰とも議論できてないのでパタン・ランゲージでもなんでもないのですが、練習ということでご容赦いただければと思います。
パタンの形式は Learning Pattern と、大好きな Fearless Change を参考にしました。
learningpatterns.sfc.keio.ac.jp
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
- 作者:Mary Lynn Manns,Linda Rising
- 出版社/メーカー: 丸善出版
- 発売日: 2014/01/30
- メディア: 単行本（ソフトカバー）
コラ！と感じられた方、お手数ですが是非フィードバックをいただければ🙇
なお、モブプログラミングのパタンについては、Agile2019で Harvesting Mob Programming Patterns: Observing how we work1 というExperience Report で報告されています。
ロールなどベーシックなものから、僕たちのチームでも遭遇したことのあるアンチパタンまでモブプロあるあるが集まっており納得感があります。 日本でやっている人たちとも是非、こういう共通点を見つけるような議論をしてみたいです。 スライドも面白かったのでチェックしてみてください。 なんとなく、今回紹介するフォーメーションと関連しそうなパタンもいくつかあったのですが分析不足です。。
前置きが長くなりましたが、これまで発見したモブプロ・フォーメーションをいくつかご紹介します。 タイトルの先頭の数字は人数の振り分けを擬似的に表すものです。フォーメーションぽいかなと思い。 モブプロは最大５〜６人程度でやるのが良いと感じていて、以下は６人あるいは５人の割り振りとお考えいただければと思います。
1 - 5: Smart Input Operator2 / 賢い入力手
チームを正しいことに集中させる
状況
モブプロを始めたい、あるいは始めた。
問題/フォース
ドライバが入力しているのをナビゲータが眺めている。会話が少ない。
- チームが議論に慣れていない
- ドメイン知識/専門性が深い人がずっとドライバ
- 交代時間が長い
- e.g. キリのいいところまでやる
解決
- Strong Style3 のルールに従う by Llewellyn Falco
- "For an idea to go from your head into the computer it MUST go through someone else's hands"
- "アイディアがコンピュータに入力されるためには、誰か他の人の手を介さなければならない"
- ドライバはタイマーで交代する
- ドライバはナビゲータを 信頼 し、議論の結果をコードに落とすことに集中する
- ナビゲータはドライバの理解度に応じて指示の抽象度を上げ下げする
結果状況
オリジナルの論文4で紹介された、最もオーソドックスなフォーメーションであり、この先のすべてのフォーメーションの基本となる。 モブプロで良い結果を出すには、チームメンバー感の信頼関係が土台になる。ドライバはナビゲータの判断に敬意を払い、ナビゲータはお互いを尊重することで、モブは効果を発揮し始める。 複雑なソフトウエアをこれまでにない速度で構築できるようになる。 チームや（いる場合は）ファシリテータがモブの練度が高くない場合に、議論の収集がつかないなどモブを制御できなくなる場合がある。 その場合は、助手席から始めよう。
1 - 1 - 4: Front Passenger Sheet5 / 助手席
助手席に乗った人が一番ナビしやすい
状況
モブプロの経験が浅いチーム/ファシリテーター。 あるいはワークショップなど、モブのスケールアップの必要性に迫られている。
問題/フォース
メンバーの発言回数に極端に偏りが出る。あるいはナビゲータの議論がまとめられず、ドライバが手を動かせない。
- ドメイン知識/専門性が高い/声が大きいメンバがいて、その人ばかりがしゃべる(a/k/a Ridin’ Shotgun Anti-Pattern6)
- 積極的に議論に参加したがらないメンバーがいる
- 理解が薄い
- 内向的
- 大きな規模で開催したい
- チームがモブに慣れていない
解決
主にナビゲーションを行う「プライマリナビゲータ」を置く。
- プライマリナビゲータを置く
- 基本的に指示はプライマリナビゲータが出す
- 他のナビゲータも発言しても良い
- プライマリナビゲータが喋らないと進まないので、発言したがらないメンバーにも発言の機会が与えられる
- ３〜５分など、頻繁に交代する
- '非アクティブ/アイドル' な状況が続くと集中を持続することが難しい
- 一人がひたすら喋る状況を回避する
結果状況
Llewellyn Falco氏のモブプログラミングワークショップセッションでよく見かける。 Agile2019 Conf の際、野良で行われていたモブプロセッションに参加したとき(冒頭の写真)もこの形式だった。 主に発言する人間を置くことで、制御がしやすくなる反面、アイドル時間が増え、リソース効率が悪くなる上、モブ本来の効果が薄まるというデメリットもある。 ファシリテーションのしやすさや、スケールさせやすいというメリットを活かし、導入時やワークショップなどで用いると良い。
6: One Team / ワンチーム
"アイディアがコンピュータに入力されるためには、チームの 合意 を得なければならない"
状況
チームの成熟度が上がってきて、全員がモブプロを効果的に行うために必要なことを理解した。 チームは更に複雑な実装/これまでに経験したことのない技術に取り組もうとしている。
問題/フォース
ドライバの手が頻繁に止まる。
- ナビゲータ全員の知恵/目線を持ってしても原因を特定できない
- チームに現在取り組んでいる領域の専門家がいない
- モブに参加している人数が少なく、意見に多様性がない
解決
ドライバも議論に参加する
- Strong Style の拡張
- "For an idea to go from your head into the computer it MUST go through team's agreement"
- ドライバの権限はたいへん強いため、チームの合意をもって入力する
- 必要に応じて調査を分散して行う。時計を止める必要はないが、止めておいても良い。
- 一番スジの良さそうなものをメイン画面で調査する
- 時間を決めて情報の同期をとる
結果状況
ドライバも議論に加わることで、シンプルにモブの多様性を増加することができる。 ただし多様性が増加する分、制御が難しくなる。 ドライバ/ナビゲータともモブのやり方に精通しており、お互いを尊重すること、ドライバの独壇場にならないようにする必要がある。
3 - 3: Sync-Mob / 同期モブ
同じ場所で、同時に、 違うことを
状況
モブプロにチームが慣れ、リードタイムは定常的にモブプロ導入以前よりも短くなっている。 取り組むタスクの並列数（WIP）が常に１であるため、スループットが上がらない。
問題/フォース
チームのスループットの低下
- 規模の大きなタスクに取り掛かり、他のタスクが進まない
- モブのサイズが大きくなり、リソース効率が低下する
解決
２つのモブを同じ場所で、同時に行う
- ディスプレイ、マシンをそれぞれ準備し、同じ場所で２つのモブ、２つのタスクを実行する
- いつでもモブ間のコミュニケーションを取れるようにする
- 常に同期をとることで、２倍のタスクをこなしつつ１つのモブとして動く
- 同じPBIに対する分割したタスクを実装する
- e.g. 片方のモブでフロント、片方のモブでバックエンド
結果状況
モブプロの利点の一つは場所の局所化によるコミュニケーションコストの最小化である。この方式を崩すことなく並列度を上げることができれば、チームはそれまでの２倍の仕事ができるようになる。 また、同じ場所でコミュニケーションが開けていることで、並列で進める場合の結合リスクも最小限に留めることができる。隣のチームにインターフェースを常に確認しながら進めば良い。 ６人を分けた場合は３-３人となり、モブの最少人数になってしまう。必要に応じてそれぞれでワンチームも併用する。
2 - 1 - 2: Double-Linking / 接続
２人がつらければ、モブを繋いでみよう
状況
スループットの問題を解消するためモブを２つに分けたいが、５人しかメンバーが揃わなかった。
問題/フォース
ペアの方が負荷が高く、モブよりも進捗が悪い
- ペアの負荷がモブと比べて高い
- ドライバが回ってくる頻度が多い
- ナビゲータは喋りっぱなし
- ナビゲータの目線が少ないので、モブ本来の効果が得られない
解決
Linking-Navigator / 接続ナビゲータ を置く
- ナビゲータの一人が、２つのモブを繋ぐ役割をする
- 両方で起こっていることをナビゲーションする
- 擬似的にペアを避ける
- 接続ナビゲータはセッション中はドライバに参加しない
- ２つのモブのドライバ交代時間・セッション終了時間の時計を合わせる
- 接続ナビゲータの負荷が高いため、１セッションごとに交代する
結果状況
接続ナビゲータにより、５人のときでも擬似的に同期と同じ効果が得られる。 ただし接続ナビゲータの負荷が高く、一日中やるには向いていない。 タスクの難易度や重要度によって並列を解除しワンチームへ移行するなど、フォーメーションを柔軟に変更しながら対応しよう。
まとめ
いかがでしょうか。 先に述べたとおり再現性も確認できていないのですが、コミュニティの議論のきっかけになり、モブプロの発展に少しでも貢献できればいいなと思います。
そして、モブプロにはまだまだいろんなフォーメーション/パタンがあると思います。 今考えているところだとスケール、複数のモブチームの協調にもフォーメーションがありそうです。 モブプロを実践していてフォーメーションやパタンを感じたら、ぜひ教えてください！
-
モブプロの創始者 Woody Zuill 氏がドライバーのことを “Smart Input Operator” と呼んでいたことにちなむ。↩
-
The way things work in Llewellyn's world: Llewellyn’s strong-style pairing↩
-
Harvesting Mob Programming Patterns: Observing how we work より↩
モダンイクメン
この記事は 子育てエンジニア Advent Calendar 2019 ４日めの記事です。
ちょっとセンシティブな話題かと思うのですが、当然特定の個人や団体を非難する目的は一ミリもありませんので、 優しい心で、楽しんで読んでいただけたらと思います。
TL; DR
- イクメンに対するもやもや
- モダンイクメンとは
- モダンイクメン is 何
- Make Safety a Prerequisite / 安全を必須条件にする
- 育児に安全を、家族にコミュニケーションを
- Adapt & Learn Rapidly / 高速に学習＆適応する
- 常に変化する状況に適応を
- Deliver Love Continuously / 継続的にラブを届ける
- 愛を示す継続的な行動を
- Make Family Awesome / 家族 を最高に輝かせる
- 家族全員が無理なく輝ける最善な選択を
- Make Safety a Prerequisite / 安全を必須条件にする
「イクメン」に対するもやもや
先月２人目の息子を授かり、絶賛２回めの育児休業中です。新生児かわいいです。 ママの出産からの回復を全力でサポートするべく、すべての家事を引き受けつつ、できるだけママが休めるように心がけています。
またかれこれ二年前ですが、長男のときは、妻の職場復帰を助けるためパパ一人の育児休業を８ヶ月ほど取得しました。 その時の様子や、考えたことはこちらの記事に記しています。
martin-lover-se.hatenablog.com
自分で言うのはアレな感じがしますが、俗に言う「イクメン」であると自負しております。
アレではあるのですが私、名前を漢字で書くと "育男" でして、生粋のネイティブイクメンであり、イクメンを名乗るのに誰にも遠慮することはないと思うところであります。
しかしながら、悲しいかなこの「イクメン」、最近では批判的...とまでは行かないまでも、否定的な意見もしばしば見かけます。 ママだけでなくパパからも、「イクメンと言われると違和感がある」という旨の発言を聞いたことがあります。
最たる例は「イクメンではなく父親です」でしょうか。
『イクメン』って言葉、もうやめませんか？育児をする男性は「父親」です。
おっしゃるとおりで、個人的には完全同意です。
でも、少しずつでも変わろうとしている現状をシャットアウトしてしまうような気もして、ちょっともやっとするんですよね。
イクメンとは
そもそもイクメンという単語はどういう意味でしょうか。
イクメンとは、子育てを楽しみ、自分自身も成長する男性のこと。または、将来そんな人生を送ろうと考えている男性のこと。 --- イクメンプロジェクト
「イクメン」とは「子育てする男性(メンズ)」の略語。単純に育児中の男性というよりはむしろ「育児休暇を申請する」「育児を趣味と言ってはばからない」など、積極的に子育てを楽しみ、自らも成長する男性を指す。実際には、育児に積極的に参加できていなくても、将来的にそうありたいと願う男性も含まれる。 2010年6月、長妻昭労働大臣が少子化打開の一助として「イクメンという言葉を流行(はや)らせたい」と国会で発言し、男性の子育て参加や育児休業取得促進などを目的とした「イクメンプロジェクト」を始動させたのをきっかけに、同語は一気に浸透した。 --- イクメン - コトバンク
2010年に有名になったようですね。厚生労働省のイクメンプロジェクトが発端のようです。 定義がちょっと曖昧な気はしますね。
また、今の僕の価値観だと、育児に "参加" という表現には違和感があります。 育児の主体がママにある前提になっちゃってますよね。
１０年前（から変わってないかどうかはわかりませんが）にできた言葉なので、今の価値観とそぐわないところがあっても仕方ないところもあるかなぁ、という気もしますが、 現実を見ると、そうでもないことを思い知らされます。
男性の育児 "参加" の現実
（２）育児休業者割合 平成 28 年 10 月１日から平成 29 年９月 30 日までの１年間に配偶者が出産した男性のうち、平成 30 年 10 月１日までに育児休業を開始した者（育児休業の申出をしている者を含む。）の割合は 6.16％
（３）育児休業の取得期間 男性は「５日未満」が 36.3％（平成 27 年度 56.9％）と最も高く、次いで「5日～２週間未満」35.1％（同 17.8％）となっており、２週間未満が７割を超えている（表３,図３,付属統計表第６表）。
6%のパパしか育休を取得しておらず、うち 70% が２週間未満なんだそうです。 率直な感想としては、「進捗ダメです」ですかね。
個人的な経験としても、まだまだパパの育児は浸透してないな、と感じることはしばしばあります。 前回の育休のとき児童館や保育園のイベントなど、平日に子供と遊びに行くところで、パパと子供の組み合わせを見ることは非常に稀です。 ママといっしょのケースは極々稀にありましたが、パパだけで、特に乳児を連れて遊びに来ているケースはほぼなかったと思います。 ちなみに今でも殆ど見かけません。２０人に１人のパパが育児休業を取得して家にいるはずなのに...？
国際社会と比較するとどうでしょうか。
USやイギリスやら、日本よりアレな国もありますが、
スウェーデン 1974 年時点では、両親手当の受給可能期間の 99.5% を女性が、0.5% を男性が受給してい た(87)。これが、クオータ制の導入された 1995 年には女性 90.4%、男性 9.6%、2016 年では女性73.0%、男性 27.0% となり、男女間の支給期間の差は縮まっている。
ノルウェー クオータ制が導入された 1993 年には、調査対象の男性のうち、両親休業を取得した者は 4.1% であったが、翌 1994 年には 45% に上昇した(100)。両親手当の受給率は、公的な統計により公表されている。ノルウェー労働福祉局が 2007 年 9 月生まれの子について行った調査では、両親手当の受給資格がある父親のうち、実際に受給した父親は 99% に達している。
イクメンの国として有名どころのスウェーデン、ノルウェーとはだいぶ差がありますね。
もちろん、育児休業を取得するか否かだけで育児へのコミットを判断しようという話ではありません。 が、現実として最も大変な新生児の時期や、ママの仕事への復帰の助けになれていないのは明白で、 まだまだ男性が育児にコミットできてない、あるいは関与が薄い社会であるように思われます。
この状況を打破、改善しようとする志や取り組みは歓迎されるべきものであるはずです。 そして今日もイクメンはその役割を果たしたとは言い難い ー つまりはまだイクメンは必要だ、と言えるのではないでしょうか。
イクメンに対するマイナスイメージ
にもかかわらず、冒頭で記したようにイクメンという単語にマイナスのイメージを持つ人が少なからずいるようです。 この原因は大きく２つあると考えます。
- 期待値の相違
- バイナリ思考
期待値の相違
イクメンという言葉は、もともとは育児をする/しようとする男性を肯定的に捉える言葉であったようなのですが、 それ以上に、「普通よりも育児にコミットする男性」を指す言葉として捉えられているように感じます。 この「普通」と言うやつが曲者です。
近年、特に働く女性を中心に、男性に求める育児へのコミットメントのレベルが高まっているのを感じます。 おそらく年代によってもかなり違うかと思いますし、あくまで僕の観測範囲での個人の感想ではありますが。
父親に求める子育てや家庭へのコミットー「普通」のレベルが10年前と比べて相対的に高まっているにもかかわらず、イクメン自体の定義がアップデートされておらず(調べてないですが、時代の変化に追いついてないことは確かと思ってます)、かつ曖昧です。 結果「イクメン」という言葉に対する期待に大きな幅が生まれ、パパ・ママの当事者間ですら相違がある、という状況が起こっているのではないでしょうか。
「イクメンではなく父親です」はまさにこれで、"ふつうの父親"に期待する働きの高まりと、イクメンへの期待値のブレによる失望から生まれた発言ではないかと考えます。
期待値の相違を減らすためには、もう少しイクメンの定義の具体性を上げる必要がありそうです。 しかしながら、たとえば
「イクメンたる行動の要素を集めて、これらの要素のうちN%以上を満たしたらイクメン認定！」
みたいな定義に意味があるとも思えません。
特に働き方の多様化により、家庭ごとの制約があまりにも異なり、同じものさしで図ることが困難、というかほとんど意味を成さないと思われるからです。
「何かをやる」という特定の行為にとらわることなく、しかしもう少し具体的な、かつみんなが納得できる定義が必要ではないでしょうか。
バイナリ思考
「育児休業を取得したらイクメン」 「子供をお風呂に入れた程度でイクメン（じゃないよ）？」
これら イクメン or Not の思考は、いわゆるバイナリ思考といわれる認知バイアスの一種です。 気をつけていても、この思考に陥ってしまっていることが結構あります。
そもそもイクメンかどうかなんてどうでもいいはずなんですよね。 各家庭のコンテキスト/制約において、男性が育児にコミットしている状態を実現することが目的なはずです。
ゼロイチのバイナリ思考を止めて、イクメンをグラデーションで捉えましょう。
今の社会、みんなそれぞれ少しずつイクメンの要素をもっているものです。 でも自分で「僕はイクメン」って思ってしまうと、それ以上先に進めなくもなりそうです。 （冒頭自分で言ってましたけど、、）
この状況を打破するには、さらなる高みを目指して、イクメンを磨いて成長していけばいいと思います。 実はオリジナルの定義にも、ちゃんと書いてあるんですよね。
イクメンとは、 ~自らも成長する男性を指す。
そのためには、規範とする姿、ともすると到達不能と思えるような高い目標が必要です。
モダンイクメン宣言
というわけで、「イクメン」という単語を、特定の行動ではなく、今の時代の父親が備えておくべきマインドセットとして再定義する必要があると考えます。
その目指すべき姿として、「モダンイクメン」を提唱します。
Modern Agile から着想を得ています。
具体的には、以下の４つにより構成されるマインドセットです。
Make Safety a Prerequisite / 安全を必須条件にする
子育てにおいて、安全は最重要＆最優先課題であると言えます。 物理的な安全はもちろん、家庭内での心理的な安全も大切だと考えます。
物理的な安全
- ３歳までにどんなスケジュールで予防接種を受けますか？
- 乳幼児で最も多い事故は？その対策は？
- かかりつけの病院は？アレルギーは？飲めない薬は？
- 心肺停止時など、救急車が到着するまでの間適切な対処をするための訓練を受けていますか？
などなどなどなど。挙げればキリがないですが、特に乳幼児期は事故や病気などの危険がいっぱいです。 子供の命、身の安全を守れることは、親としての最低限の責務と言えます。
ママに任せきりになっていませんか...？
心理的な安全
先程も述べたように、パパとママそれぞれのお互いへの期待値をすり合わせることが大切です。 この共通認識から醸成されるパパとママの間の信頼関係は、子育ての土台であると言えます。
そしてこの信頼関係の構築には、頻繁で濃密なコミュニケーションが不可欠です。
その日あったことを食事などの機会に毎日報告し合うことはもちろん、作業をともにしてお互いのやり方を共有したり、 今週の予定を確認しあったり。中長期的な家庭ビジョンについても定期的に振り返り、話し合う必要があるでしょう。
Adaption & Learn Rapidly / 高速に学習＆適応する
子供の成長は早いです。 そして、子育てにおいて状況は刻一刻変化します。
昨日できなかった寝返りが、たっちが今日できるようになったり。 できることが増えたら危険が増えます。
興味のあるもの、好きなものが増えたり減ったり。 遊び方もすごい速さで進化します。
突然癇癪を起こしてみたり。 いきなり体調を崩してみたり。
これらの変化に対応するためには、やはり密なコミュニケーションが土台として必要となります。 変化を適切に捉え、適応していく必要があります。
Deliver Love Continuously / 継続的にラブを届ける
ラブです。愛です。
次男と対面したとき、宇宙の真理を感じました。
「無限って２で割っても無限なんだ...」
そう、親の愛情は無限です。
しかしながら、感じているだけ、溢れさせているだけではダメです。届けましょう。
「大好きだよ」「愛してるよ」
ちゃんと伝えられていますか？ 言わなくても伝わる？意外と伝わってないものです。
言うだけではなく、行動で示しましょう。 見返りを求めず、率先して与えましょう。
義務だから育児を、家事をやるのではありません。 愛しているからやるのです。
時々ではなく頻繁に、継続的に、です！
Make Family Awesome / 家族 を最高に輝かせる
家族の全員が誰も無理をせず、持続可能なペースで、子育てを楽しみながら、自分の人生の目標の達成にも邁進できている。 そんな「家族が輝いている」状態にコミットしましょう。
現代の日本の子育ては、明らかにママへの負担が高いです。 もちろん各家庭の差はあると思います。 ママだけが育児を理由に何か人生で大切なものを諦めることなど、あってはなりません。
そして、家族にはもちろんパパも含まれます。 自己犠牲的になるのではなく、家族全員が輝ける「最善」を、コミュニケーションを通じて家族で考え実践しましょう。
まとめ
いかがでしたでしょうか。
肝心のイクメン再定義がモダンアジャイルをもじったもので、正直半分くらいは「モダンイクメン」が言いたかっただけですが、 「何をやったか」ではなく、今の時代に沿った「マインドセット」としてイクメンを再定義する、という点については、割と真面目に考えています。 また、きっとみなさんにとっての「モダンイクメン」なマインドセットがあるはず、と思います。
もちろん僕がこれらすべてを備えているかというと、そうではありません。 まだまだ父親としても未熟ですが、実際に育児休業を過ごす中で、この４つの心得を自分の父親としての振る舞いの指針としています。
もっともっと、パパもママも最高に輝ける社会になっていけば良いなと思います！
Agile 2019 に行ってきました！
8/5-8/9 の日程で、Washington D.C. で開催された Agile 2019 に参加してきました。 Agile Conference は去年に引き続き二回目です。
カンファレンスの様子、セッションの概要や感想は会社のブログにまとめましたのでそちらをご覧いたただければと思います。 ここでは、個人的な出来事や感想をまとめておこうと思います。
TL; DR
- LTしてきました
- 笑いも取れたし、ちょっと自信がつきました
- Mob Mentality Show に出ました
- ラッキーパンチのおまけ出演ですが、いつも見ているチャンネルに出演でき感慨深かったです
- モブプロしてきました
- モブならUSでも働けそう！
- 学びについて思うところがありました
- とりあえず英語をもう少しなんとかします
- たくさんの出会いがありました
- 友だちが増えて嬉しいです！
今年も 最 & 最 of 高のカンファレンスでした！！！
LTしてきました
今回の自分にとってのハイライトはこれでした。
AgileConfには事前応募＆投票で話す人が決まる Lightning Talk のセッションがあります。
今年は日本からの応援もいただいて（投票いただいた皆様ありがとうございました！）発表することができました。 資料も貼っておきます。
たった５分間の発表でしたが、海外カンファレンスの、しかも憧れの人たちと同じ場で発表できたことは自分にとってとても良い経験になったし、 このために１年間英語を練習してきたので、少し自信にもなりました。
直前は緊張しきってこんな顔をしていて、
川口さんに「こんな顔してますけど大丈夫ですか？」とこの写真を見せてもらいながらお声がけいただいて、正気に戻れました（笑
このセッションでは事前に発表順が決まっていなく、発表者が１つのテーブルに集まって、次に発表する人がマイクを取ることで自分たちで自己組織化して順番を決めるというルールです。 この緊張状態を保つのは限界だーと思っていたので、思い切って一番に志願しました。
会場の優しい雰囲気にも助けられて、話している間はすごく楽しめました。
渡米前に資料はできていて、スクリプトも丸暗記して臨んでいたんですが、前日に川口さんにレビューしていただいていて、結構構成をガラっと変えました。 これがドハマリして、結局追加したスライドが一番ウケるという。
いらすとや、ありがとうございますありがとうございます
とにかく、決められたことをちゃんとやることより、聞いてくれる人のことを考えて作ったスライドのほうが刺さるんだなぁと。 冷静に考えると当たり前のことなんだと思うのですが、経験できたことはやっぱり大きいです。
発表が終わったあとも「良かったよ」「いいアイディアだね」「僕も同じようなこと考えてるよ」など聞いてくれた人たちからお声がけいただけました。
チョット大変だったけどがんばってよかったなという気持ちです。
Mob Mentality Show に出させてもらいました＆撮影に潜入しました
Mob Mentality Show というYouTubeチャンネルがありまして、モブプロ大好きなのでウォッチしています。
で、これも川口さんに出演の依頼があって、川口さんから僕も出ませんか、とお声がけいただけました。
この Mob Mentality Show(@mob__mentality) 、ホストはご存知 Chris Lucian(@ChristophLucian) 氏と Austion Chadwick 氏です。 ゲストも超豪華で、自分の前回がモブプログラミングの提唱者 Woody Zuill(@WoodyZuill) 氏、 自分の後ろが Modern Agile の Joshua Kerievsky(@JoshuaKerievsky)氏という...。
同僚や友達になかなかこの凄さが伝わらないのがもどかしいのですが、僕にとっては世界のスーパースターの中に突然モブキャラの僕が放り込まれたような感覚です。モブだけに。 AgileConfではこういうすごいことがナチュラルに起こるんですね...。 とにかく、収録してきました。
英語あんまし得意じゃないから、事前にアイディアを共有させておいてくれ、の図
Recording an episode of The Mob Mentality Show with @nagworld @kawaguti @martin_lover_se and @ChristophLucian at #Agile2019 @AgileAlliance
— Mob Mentality Show (@mob__mentality) August 6, 2019
What joy it was to discuss with such great people topics such as #MobProgramming in Japan and the "Fun! Done! Learn!" #retrospective pic.twitter.com/lCIlEErd6W
Chirs とはもともと去年の AgileConf で会えて話を聞いていて、去年の RSGT でもモブプロや NoEstimate について多くのアドバイスを貰いました。 Austin とは Twitter で「モブプロの話しようぜ！」と言っていて、カンファレンスで直接お会いできました。
ふたりとも今回もとても良くしてくれて、紹介したアイディアを「いいね」と言ってくれたり、アドバイスをくれたりしました。 主にLTで話した内容について話したんですが、まあもっと英語やろう... というモチベーションに繋がりました。
また、木曜日は、前述の Josh の会の撮影に潜入することができました。
これは本当に神回で、現場に居られたことが凄まじくラッキーでした。 公開が楽しみです。エンジニアの方にはぜひ見ていただきたいです。
この収録を聞いててすごく感じたのが、「They write codes」でした。 Joshは会社を運営する立場ですし、Chrisにしてもディレクターという立場ではあるのですが、 今の時代にシステムを作る、コードを書くということがどういうことか、ということへの理解、解像度がものすごく高いというか。 そもそも自分でもコード書いてるぜっていうレベルなんですね。
それが日本のマネジャー、経営層と比べてどうかとか、どちらがいい、ということが言いたいわけではありません。 シンプルに違いはあるなと感じたところです。
アメリカでモブプロしました
Falco(@LlewellynFalco), Austin, Chris が中心と思うのですが、非公式で朝のセッションが始まる前の時間帯でモブプロをやっているという噂を聞きつけて、一も二もなく参加してきました。
最初は「言われてること、起こっていることにまるでついていけなかったらどうしよう...」とチョット緊張してたのですが、 Javaコードは世界共通、やっていることは5分程見ていてすぐ理解できて、ナビゲーターとしてもドライバーとしても貢献することができたと思います。
「あー僕モブプロならアメリカでも働けるな」
なんて脳天気なことを考えていたんですが、改めて冷静になって考えると言語の壁を超えるのって結構すごいことだなと思えて、 またモブプロが好きにもなりました！
レトロの後、ホストのFalcoと。
学びについて思うところがありました
前回参加した時は何もかもが新しくて斬新で、「世界にはこんな新しいことがあるのか！」という感じでした。
その後Agileにドハマリしてまかりなりにも一年間勉強、実践してからの今回は、 インプットについては前回ほど斬新さを感じられたか、新しいアイディアを仕入れられたか... というとそうではないかなと言うのが正直なところです。
多少は自分の成長もあるのかもしれませんが、慣れによるところもあると思うし、今回はネットワーキングと知り合いのセッションに参加することを優先したのでその影響もあるかと思います。
それでも、これからは今の知識や経験と照らしてより深く洞察したり、スピーカーの方や参加者とのインタラクションの質をより高めて、よりそれぞれのトピックに深く潜ることが必要だなと感じました。
もともと何かを深く考えるのはあまり得意ではなくて、どちらかというと違いの中から抽象を取り出す操作のほうが得意だとは思っているのですが、 何れにせよ英語がボトルネックだとまた感じたので、改めてまた１年練習しようと思います。
人々との出会いがありました
今年もとても多くの出会いがありました。 趣味で２人セルフィーを撮らせてもらっています。 今年はこれ僕の趣味なんだー、って言いながら撮りました。
去年このカンファレンスで出会って、日本に休暇できた時に会社でプレゼンしてくれた Cherifa
間違いなく僕が Agile に傾倒する一因となった Woody
CSD 研修で５日間みっちり鍛えてもらった David 師匠
彼女の著書「Fearless Change」が大好きで、直接お会いして＆セッションを聞いて大ファンになってしまった Linda
他にも世界の第一線で活躍するディベロッパー、アジャイルコーチたち...
日本からももちろん、第一線で活躍されているアジャイルコーチの方々が今年も多数参加されています。 また非常に良くしていただいて、たくさんの思い出を共有できて嬉しかったです。
みなさんともセルフィーしてもらえばよかった。日本人同士のほうが恥ずかしさが出る。。
５日間同じ場所で同じ興味のイベントに参加する、仕事以外でこれだけ経験を共有できることってなかなか無いですし、コミュ障な自分にとって友達をつくるよい機会にもなっています。
ある方がこれを "修学旅行" と表現していて、なるほどそれだなと思いました。
まとめ：僕にとっての "Agile"
'Agile is Mindset' 去年このカンファレンスで、この言葉が腹落ちしたように感じています。
でもこれは結局人の表現でしかなくて、 では自分にとってAgileとはなにか？と考えた時、
なにかを「絆ぐもの」かなあと考えるようになりました。
チームを、 ビジネスと開発を、 人と人を、 世界と自分を。
これがAgileの定義ですと言いたいわけではなくて、少し自分の好きなことを言葉で整理してみようと思ったときにこうなったというだけなのですが、チラ裏に残しておこうと思います。 また、これからも自分の中で変わっていくはずです。 今回またこのカンファレンスに参加できて、去年よりは Agile が自分の血肉になっていて、少しは進んでいるかなと感じることができました。
今年も本当にたくさんの素敵な出来事があって、「ああ行けてよかったな」というのが心からの感想です。 そして、すでに「また行きたいな」と思っている自分がいます。
自分の成長への気づき、新しい知識と経験、新しい友だちとの出会い、そして新たな情熱！
今年も忘れられない、最高のカンファレンスになりました！
仕事大好きエンジニアが半年間パパだけの育休をとった話
件の育休復帰に関する一連のニュースを見ていて、居ても立ってもいられない気持ちになったので筆を執りました。
かれこれ１年前になりますが、７ヶ月ほど育児休業を取りました。 入れ違いで妻は仕事に復帰し、パパ１人での育児休業だったので、期間的にもそうですが今日でもそこそこレアケースではないかなと思います。
自分もそうでしたが、仕事が好きな人ほど長期間職場を離れることに不安や抵抗があると思います。 自分の経験を共有することで、そんなパパの育休取得を少しでも後押しすることができれば...
TL;DR
- なぜ育休をとったの？
- 夫婦間での公平性。育児で女性だけがキャリアにビハインドを負う合理的な理由ってあります？
- 育休どうだった？
- 辛いことや不安も多かったけど、それを差し引いても息子との時間は代えがたいものでした。
- 復帰したあとどうだった？
- 半年休んだ程度なら、キャリアとかスキルとか知識に何の問題もなかったです！
件の事件のようなこともまだまだ存在し、手放しに「みんな育休取りましょう！」とは言えない世の中かと思うのですが、 少なくとも自分にとっては貴重な体験でしたし、もっとパパ育休が増えると良いと思っています！
背景
都内在住、３０代で夫婦共働きです。 タイトルの通り、私はITエンジニアを生業にしています。 妻は理系大学院を出て研究職として働いており、適切な言葉かはわかりませんがいわゆる「バリキャリ」の部類だと思います。
妻も私も実家は遠く、両親の援助は得られない状況でした。
私は仕事が大好きで、結婚してからも子供ができるまではワーカーホリックのような働き方をしていました。 今でも仕事は大好きですが、少し「好き」の表現の仕方が変わっていて、子供が生まれてからは完全定時ダッシュおじさんになりました。 理解のあるチームで本当に感謝です。
というわけで、このお話は「仕事大好きな人が半年仕事をしない決断をした話」と解釈いただければと思います。
どれくらいの期間？
８月末から、４月頭に保育園に入るまでの７ヶ月と少しです。 最初の半月ほどは、引き継ぎも兼ねて妻に休みをオーバーラップしてもらいました。 ９月中旬に妻が職場復帰し、それから４月１日に保育園に入れるまでの期間、パパ１人で奮闘しました。
半年という期間はやはり長くて、最初の一ヶ月を終えた頃は
「やっと一ヶ月か... これが永遠に続くような気がする...」
みたいな感覚でいたのを思い出します。
なぜ育休をとったの？
2017年の１月、息子が生まれました。
早生まれで、（ギリギリ預けられたのですが）０歳で保育園に預けるのは心もとないな... とはいえ、１歳で保育園に入れるまでまるまる妻が休むと１年以上仕事を離れる事になる...
という事情から、妻とお互いのキャリアについて話し合いをする中で、育児休業を取ることを打診され、考えるようになりました。
半年間仕事を休んで子育てにフルコミットしたらどうなるんだろう...と、少しの好奇心が働いたことは否定できませんが、 最終的には以下のことが決め手となり、育休を取ることを決心しました。
育休は法律... だけど、会社の理解があったこと
まず前提として、男性の育児休業は会社の制度ではありません。法律で定められている労働者の権利です。 と書きましたが、恥ずかしながら私も育児休業が法律に定められていることは妻に教えてもらうまで知りませんでした。
...とはいえ現実を見ると、この事自体が知られていなかったり、封殺してしまうような会社が存在することも事実です。
私はサイバーエージェントという会社で働いています。 前述の通り半年以上育児休業を取得し、何の問題もなく復帰を果たしました。 会社にはパパの育休をはじめ、リモートワークなど育児を支援する様々な制度が整備されており、心理的にも実務的にもかなり助けられました。というか今でも助けられています。
今の「社会」では、（残念ながら）この環境は決して当たり前だったり、法律だから前提...などといえる状況ではなく、 とても恵まれている環境なんだと認識しています。
お互いのキャリアにおける「公平」さ
「出産、育児において女性だけがキャリアにビハインドを負う合理的な理由ってあるんだっけ？」
これは妻から言われたのではなく、自問するうちたどり着いた問いです。 もちろん各家庭の状況によると思いますが、結局自分のコンテキストでは答えを見つけられませんでした。
合理的でないから休まない、ということが言いたいわけではありません。
手前味噌ですが、私の妻は仕事人としてとても優秀です。 その妻が働けないことや、キャリアを諦めること自体が間違いなく社会損失ですし、妻を差し置いて自分だけ働く理由がありません。 収入の多寡も関係なく、私にとって、妻と私のキャリアにおいての「公平さ」は決断における大切なファクターでした。
もちろん妊娠中の仕事への影響や、出産前の休暇など含めるとどうしても妻のほうが仕事への影響は大きかったと思うのですが、それでも休んだことに意義はあったと考えています。
そもそも父親です
「自分の息子を（妻はできるのに）一人で世話して育てることが出来ないの？」
という問いがもう一つ決断の柱になりました。 出産や授乳は変わることはできないけど、それ以外のことはパパでもできるし、やるのが当然だと思います。
育休を取る前も、土日は息子と一緒に過ごすことが多かったとはいえ、自分が育児の主体になった経験は今でも非常に役立っています。 たとえば、妻の宿泊を伴う出張にも、何の問題もなく対処できます。
冗長化、大事ですよね！
育休を取る前の仕事の様子は？
育休を取ると決めてからすぐ上司相談にして、そのあと人事に相談しました。 息子が生まれるよりも前、育休に入る９ヶ月以上前でした。早めの相談は会社、チームと自分双方にとって大切だと思います。
初めてその話を上司に切り出したとき、快諾してもらえて、ずいぶん安心したのをよく覚えています。いい会社で働いているなー、と。
その後、同じ部署でチームを異動したり、ということはありましたが、一貫して「自分にしかできない仕事をつくらない」ことを心がけていました。 私はエンジニアなので、担当したタスクのドキュメントを詳細に残す、であったり、基本仕事を進めるときに誰かを巻き込んでバックアップ体制を取る、といった具合です。
もちろん「この人は半年後に休む予定だから...」といって不当に簡単なタスクを割り当てられるようなことはなく、 休みに入る直前まで今の自分のスキルをフルに活かして貢献できる責任ある仕事をやらせてもらっていたし、それをこなしていたと自負しています。
その甲斐もあってか、チームからも快く送り出してもらうことが出来ました。
余談ですが最近では育児休業をとらなくても、普段から属人化を減らしておいたほうが良いなと感じています。 若い頃は「この仕事は自分にしか出来ない...」という謎の使命感、というか自己満足な感情があったのですが、 まあそこそこの規模の会社であれば大体代わりの人はいますし、そうあるべきだと思います。
なお最近では、チームの働き方としてモブプロを採用しており、バス係数＝チーム人数でとても安心感があります。
martin-lover-se.hatenablog.com
ITエンジニアは育児休業取りやすい職業なのかな？...と思っていたんですが、なんで取りやすいのか理由を考えてみたら特に浮かばなかったです。 他の業種はやったことがないのでわからないですが。会社が先進的だ、というだけかもしれません。
何れにせよ、会社や上司の理解があること、はもっとも重要なファクターであると考えます。
育休中の様子は？
平日の過ごし方
全力で専業主夫をこなしていました。
とはいえ家事は妻と折半ですし、ママ友の話を聞いていてもほかの専業主婦ママよりはだいぶユルかったと思いますが... まあ、あまり頑張りすぎないのも大切だったかなと思います。 （世のママさん、パパの家事のアラは少し大目に見てやってください...）
朝ごはんを作って、息子と妻に食べてもらって妻を送り出して、
日中は公園にお散歩に行ったり、公民館や地域のイベントに出かけたり。
帰ってきたら息子といっしょに「おかあさんといっしょ」見て、ブンバボン歌って。
晩御飯の準備して、息子をお風呂に入れたらあっという間に夜... という具合ですね。
なお我が家では家事と育児は私と妻で２等分です。 私が働いて妻が休んでいるときもそうでしたし、共働きに戻った今でもそうしています。
全力で１週間育児にコミットした方ならご理解いただけると期待するのですが、特に子供が小さいときは、仕事より育児のほうが負荷が高いです。 もちろん業種業態にもよると思いますが、少なくとも私にとってはそうでした。 冗長な構成を取ることはやはり大切だと考えます。
良かったこと
何をおいても、息子とゆっくり、たくさんの時間を共有し、成長著しい時期を共に過ごせたことが最高でした。
育休に入った頃にはおすわりもおぼつかなかった息子が、
ハイハイを初めて、タッチできるようになって、高ばいできるようになって。
歩き始め... る前に残念ながら休み明けてしまいましたけど。
言葉が出始めて、「ママ」より「パパ」をたくさん言ってくれたり（一緒にたくさん練習したからね）
食べ物を選び始めて、人見知りしだしてずーっとパパにしがみついてて。
時間は巻き戻りません。長い仕事人生の中でたった半年キャリアを欠損したとしても、代えがたい思い出を得られました。 もちろん育児休業を取らなくても思い出は作れると思いますが、長い時間を共にして、しっかりと息子と信頼関係も築けたと考えています。
最近「ママがいい〜」とか言われますけど...。
特筆事項として、電動自転車の導入でとても心が軽くなったことを書き残しておきます。 １歳くらいから乗れるようになるのですが、それまではベビーカーや抱っこ紐、あるいは両方持っての移動でした。
抱っこ紐やベビーカーでの移動はとても大変だし、公共交通機関を使うにも気を使うし、遠くに移動できないし...行動範囲も狭くなりがちです。 それが電動自転車の導入で移動がとても楽になり、行動範囲も広がってそれだけで心がとても晴れやかになったのをよく覚えています。
コスパ最高なので１歳になったら是非購入をご検討ください。
辛かったこと
一番つらかったのは、「社会から隔絶されている」と感じてしまうことです。 いま冷静に考えると実際にはそんなことはないし、完全な勘違いなのですが、やはり大人とのコミュニケーションが減って、視野が狭くなりがちだったと思います。
具体的な辛かったことと、その対処をいくつか紹介します。
子供の命を預かる不安
これは完全に当たり前で、世の中のすべてのパパママがそうなのですが、 休日を息子と２人で過ごすことは多くあったにもかかわらず、最初のママがいない平日の不安な気持ちをよく覚えています。
少しのミスが息子の命にかかわるのではないか...という。
この不安は慣れによってだんだん緩和されていったのですが、 育児本を読んだり、地域イベントの小児救急ワークショップに参加したりして「もしも」に備える行動を取ることで、少しずつ自信がついて解決していきました。
パパコミュニティがないのが辛い
平日の昼間に、１歳の子供と遊びに行くところといえば
- 公民館
- 子育てセンター
- 保育園（主にイベントごと）
- 公園
あたりがメインになると思うのですが、驚くほどパパと子供だけで遊びに来ている親子が少なかったです。 半年間で片手に収まる程度、とかそういうレベルです。 パパも５％くらい育休取得しているはずなのですが... 。 たしかに、私も初期のころはパパと子供だけでイベントごとに遊びに行くことの心理的なハードルは結構高かったです。
当然、地域の子育てコミュニティはママで構成されていて、パパ育休の不安や悩みを共有できる人がいないのが辛かったです。
地域のママたちと共通の話題はもちろんあるのですが、やっぱりママだけのところにパパが居ると、授乳のこととか話しづらい話題もあるんだろうな...と言う空気を勝手に感じてしまっていたりしました。
これも時間が解決してくれて、結局、解は「ママコミュニティに参加すること」でした。 だいたい曜日替わりでイベントごとがあるのですが、毎週通っているとよく会うママや子供と自然に会話します。 ママたちも、パパの参加は珍しいのでよく話しかけてくれます。こちらが壁を作らなければ、案外あっさり溶け込めました。
とくに「プランケット」というイベントに参加できたことはとても幸運でした。 ここで出会ったママ友のみなさんと、助産師の田中先生には本当に救われました。 気兼ねなく話せて、悩みを相談＆共有できる場で、毎週楽しみに通わせていただきました。
仕事も勉強もしてない、という事実が辛い
育休を取りながらの勉強、できる人はできると思いますが、自分にはほぼ無理でした。
技術が進んでるんじゃないか...
仕事が進んでるんじゃないか...
勉強できてない... 本を読むことすらできてない...
と、ネガティブ思考の悪循環に陥ってしまう期間もありました。
子供が寝る30分とか、寝付いたあととか、ちょっとした空き時間は毎日できます。
勉強しなきゃ... コード書かなきゃ...
でも自分も疲れてて寝てしまう... ああ、明日こそ...
後述しますが結論、半年休んだ程度でエンジニアとしてのウデはどうこうならないので、まったく心配する必要はなかったです。 そんなことで頭と心を悩ますぐらいならいっそきっぱり忘れて、息子と笑顔で過ごすことのほうがよっぽど大切で有意義だったと思います。
保活が辛い辛い＆辛い
保活の辛さと、それをどう乗り切ったかは以前ブログに書きました。
martin-lover-se.hatenablog.com
東京の保活はとにかくヤバイです。語彙が貧困で申し訳ないのですが、本当にヤバイです。
世のパパたち、絶対にママひとりに保活を任せてはいけません。
世のパパたち、絶対にママひとりに保活を任せてはいけません！！！
復帰したあと
結果的に、育休前に所属していたチームに戻れることになって最高でした。
PCのセットアップやら、慣らし保育のための早退やらで１週間位はあたふたしましたが、まあ自分で言うのもアレですが半年間働いてなかったんだっけ？というくらいスムーズに職場復帰できたと思っています。 自分の中でも、すごく自然に「働いている自分」に戻る事ができました。
これはやはり会社、そしてチームと上司の理解が大きいです。 安心して働ける環境だったからこそ、すぐに自分の最高のパフォーマンスを発揮できたと思います。
「技術の進歩は早い！学び続けないと！」はエンジニアにとってもちろん常にTrueです。 ですが、ぶっちゃけたった半年休んだ程度で追いつけなくなるほどではないと思います。 半年も働かなかったらコードの書き方とか綺麗サッパリ忘れちゃうんじゃないかな？とか心配していたのですが、全く、一ミリもそんなことはかったです。
何より、この経験を通じて会社とチームに対するエンゲージメントがMAXに高まりました。 復帰してから、以前にもまして会社のため・チームのために自分ができることを考え、自分で自分をモチベートして実践するようになりました。 会社から見ても、これは長期的な視点で費用対効果があるのではないでしょうか？
まとめ
共同参画によると、2017年ではパパ育休の取得率は5%ちょっと、2020年には13%を目指しているそうです。 Twitterなどを見ていても、冒頭紹介した記事のようにパパが育休を取得するケースは確実に増えてきているように感じます。
一方、半年以上育児休業を取得するケースはあまり見かけないし、ママが職場に復帰してパパと子供だけになるケースはもっと稀だろうと思い、経験を共有してみました。
再三ですが、私は半年以上休みましたが何の問題もなく復帰していますし、休む前と同様に、いや休む前以上に仕事を楽しんで、成果を出していると思っています。
こういう事例もあるんだよ、ということが少しでも伝わり、男性の育休取得の後押しになれば。
女性が活躍する社会が叫ばれて久しい昨今、保育園の拡充や、職場復帰しやすい、子育てしながらでも働きやすい社会制度はもちろん重要です。
同様に、パパの育児へのコミットと、それに対する社会の理解も重要なファクターではないでしょうか。
その意味では、僕が働いているサイバーエージェントは最高に働きやすい会社ですが、 世の中ももっともっと多様性に寛容になって、子育て世代が働きやすくなるといいな、そんな未来の実現に少しでもこの記事が役に立つといいなと思います。
追記 2019.6.10 「育児休暇」ではなく「育児休業」とご指摘をいただき、文中の該当箇所を修正しました。
デベロッパーとして生きていく ー 認定スクラムデベロッパー になりました！
先日、 David Bernstein 氏の 認定スクラムデベロッパー研修に参加し、Certified Scrum Developer（CSD）を取得しました。
５日間に渡る研修で、たくさんのことを学びました！
TL;DR
これでした！
今まで学んできたことが１つのストーリーのもとつながり、明確な目的を得ることができました。 何より、デベロッパーとして生きていく自信と勇気を、その方法と一緒にもらったように感じています！
お急ぎでない方向け：詳細
Agile, Scrum, XP
価値、原則、プラクティスのフラクタル構造
XPにおいて、価値、原則、プラクティスは以下のように説明されます。
価値（values）：達人が良し悪しを判断する高度な感覚。ある状況における好き嫌いの根源にあるもの
プラクティス（practice）：疑う余地のない、簡単に実施できる「良い行動」
原則（principle）：価値とプラクティスのギャップを埋める架け橋
価値とプラクティスの間には、大きな隔たりがある。価値は普遍的である。... 一方、プラクティスは状況によって大きく異なる。
-- Extreme Programming Explained 2nd Edition
目的なくプラクティスだけ実践していると、すぐにあらぬ方向に行ってしまう。 でも、価値は抽象的すぎて理解が難しい...と感じていました。
これを、中間に適度な抽象度の「原則」のレイヤーを置くことで
... このように、双方からより深く理解できるように感じています。
研修で教わったことも、このレイヤーに適応してまとめると自分的にしっくり来たので、冒頭の図が誕生しました。
プラクティスの中でも抽象度のレイヤーがあって、フラクタルを形成している... ような気がしています。
価値：変化に対応する - Agile マインドセット
世の中は複雑(Complex)で、その世の中でソフトウェアで価値を提供し続けるためには、 実験と探索的な活動ーつまり「変化し続けること」ーが必要である... というアイディアがいま自分の根底にあります。
これは Scrum Guide にある経験主義の説明とも合致すると考えています。
経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。
-- Scrum Guide
Agile Manifesto にも、「計画に従うことよりも変化への対応を」とあります。 もちろん他の価値と補完し合いながら、複雑な世の中でソフトウェアが価値を提供し続けるために必要なマインドセットを教わったと考えています。
余談ですが、ボブおじさんも Clean Architecture でソフトウェアの価値について以下のように書いていました。
すべてのソフトウェアシステムは、ステークホルダーに２つの異なる価値を提供する。それは「振る舞い」と「構造」だ。
ソフトウェアはソフトでなければいけない。つまり、簡単に変更できるようになっておくべきだ。
-- Clean Architecture
違うところで同じことを言っている物を見つけると、より真実に近づいているように感じて嬉しくなります。 （彼も Agile Manifesto にサインした１人なので、当然といえば当然なのかもしれません。）
Scrum と XP
懇親会の場で、 David にこんな質問を投げかけてみました。
「スクラム開発者に最も大切なスキルはなんですか？」
間髪入れず、 David はこう教えてくれました。
「XPだよ。」
これは自分にとっては目からウロコでした。
研修中、 David はよく言われる Build(do) the Right Thing と Build(do) the Thing Right を用いて、XPとScrumを以下のように説明してくれました。
- (探索的に) 適切なものを構築する ... Scrum
- (探索的に進めるための) 適切なやり方で構築する ... XP
たしかにいままでプロジェクト的アプローチで、数ヶ月に１度結合して結合試験してリリース...のようなやり方で開発していたチームに、いきなり「今日からスクラムやります！スプリント期間は２週間です！スプリント期間ごとにインクリメントを作ってください！」と武器をなにも与えずに初めても、「じゃあ設計スプリントやろう！」「結合試験スプリントをやってリリースだ！」... みたいになってしまうと思います。私はそんな経験があります...。
これを補完するため、スクラム開発者にはインクリメンタルにソフトウェアを設計・実装するスキルが必要で、その役割を担うのがXPである、と理解しています。
プラクティス：XPプラクィスと設計
TDDやデザインパターンを始め、多くの開発プラクティスを座学と実践によって学びました。
その多くは、今日では広く知られているものだと思います。 自分にとっても知っている/習得していると思っていた（と誤解していた）ものも多かったのですが、各プラクティスに対する解像度を高めることができました。 そして何より、全てのプラクティスをこの研修で定義された「価値」に関連付けられたことが大きな学びでした。
また、５日間の 1/3 ほどの時間をコーディング実習に使ったという点でも、非常に実践的でした。 コーディングはすべてペアプロで行い、ペアと議論しながら進めることで、より理解が深まったと思います。
TDD
よく言われるように、TDDという単語は人によってその意味するところが大きく異なります。 この研修では、TDDは「テストファースト である」ことと定義されました。
コーディング実習はすべて TDD で進めることが義務付けられ、TDDの良さを再認識できました。
TDDについては、以下が印象に残りました。
- TDDはテスト手法 ではなない
- デザイン の手法である
- テストもまたコード
- テストもリファクタ（クリーンアップ）せよ
- Unit とは一つの計測可能な 「振る舞い(Behavior)」
- 振る舞いのための簡単なシナリオ
- 安定なインターフェースとそのテストを手に入れた後は、小さい実装にはテストを付けずリファクタする
Unit Test is MUDA by Cope vs TDD is important practice by David
昨年 Jim Coplien 氏の CSM 研修を受けた際、「Unit Test is ムダ！」と一喝されたことが、強烈に印象に残っています。
「ほとんどのユニットテストは価値に寄与していなく、設計に良い影響を与えているという科学的根拠もない。」
このときは、「これは世の中の多くのデベロッパーが適切なユニットテストを実装するスキルがない、という証拠であって、ユニットテストが価値がないという証拠ではない」ーという具合に考えていました。 そして研修が終わってからも結局、「やっぱり必要だから...」と心の中で言い訳をしながら、同じようなUTを書いてしまっていました。
研修中、アギレルゴの川口(@kawaguti)さんに何気なくその話をしたところ、
「Cope の「ムダ」はTPSの「ムダ」。つまり価値を提供してないすべての作業のこと。これをどうやって減らすかを考えろ、と言っている。」
と教えていただきました。
一方 David からは、 TDD は２つの点で価値を提供していると教わりました。
- 動いていること、 Behavior を保証する
- 変更が容易なソフトウェアをインクリメンタルに、創発的につくる
結局、ユニットテストを書くことを目的にするのではなく、価値を提供するために必要なことに集中しよう、という点で、同じものを違う側面から見ている...のではないかな？ と考えています。
ペア/バディ/モブプログラミング
DevOps Days Tokyo の基調講演でもこの話をしていたと記憶しているのですが、 David に教わった大好きなメタファを紹介します。
マネジャー:「ペアプロ？やめたまえ。」「私のチームのリソースを半分にすることはできない。」
David: 「まず第一に、僕たちはリソースじゃない。」「一人では運べない荷物でも、２人なら運べる。ペアプロは、そういうことをやってるんだ。」
幸運にも、最近自分のまわりでは David の例のようなマネジャーとは遭遇していないのですが、 過去 SIer で働いてた頃は自分で「ペアプロやるとリソース半分になるよなぁ...」とか考えていました。 そんな体験から、このメタファはとても心に刺さりました。
私のチームでは、チームのデフォルトの働き方としてモブプロを採用しています。
martin-lover-se.hatenablog.com
その経験からも、「２人なら重い荷物を運べる」というメタファはとても納得感のあるものでした。
設計 - OOP, Design Pattern
オブジェクト指向完全に理解した、と多分人生５回めくらいに思いました。 そろそろ入り口くらいにはいるでしょうか...。
オブジェクト指向やデザインパターンについて新たな気付きや学びが非常に多くあったのですがとても書ききれません。 特に印象的だったのはこれです。
「デザインパターンは意図。UMLにも、ソースコードにすら現れない。」
研修の後、勧められた「オブジェクト指向のこころ」を読んで、研修で時間が足りなくて理解が浅かったパターンについても補完できました。 著者の Al Shalloway 氏は David 氏の師匠だそうで、この本の内容は研修にも色濃く反映されており、復習＆より理解を進めるのにぴったりでした。
その他感想とか
達人のメタファ
達人はメタファがすごいです。 聞く人を納得させ、かつ解像度を一段高めるような... そして何より、心に響き、心を動かします。
研修のフィードバックを何度か社内でやって、David と同じメタファを説明してみたんですが、全く響きませんでした。 達人は秀逸なメタファを作れることもそうですが、それを納得させるだけの含蓄ある言い回しやそれを支えるバックグラウンドがあってこそなんだな、と気付きました。
デベロッパーとして生きていく勇気
かれこれ１０年以上ソフトウェア開発に携わってきたなかで、プロマネ、エンジニアリングマネジャー、プロダクトオーナー... など、コードを書くこと以外でも様々なロールにチャレンジさせてもらってきたのですが、自分が一番得意なことはやっぱりコードを書くことだと感じています。
かたや年をとって、自分が超絶強いプログラマでも、その器でもないというのも痛感しています。 最も得意なところをせいぜい人より２〜３倍の速さで終わらせるのが関の山かな、という感覚で、コードを書くことだけにフォーカスしているとこれ以上はスケールしません。
ここにずっと後ろめたさというか、デベロッパーとして生きていく踏ん切りのつかなさを感じていました。
今回の研修を終え、自分はもっとデベロッパとして成長できる、という自信とともに、
今回得たような知識を伝えていくことで、自分が書いたコード以上の価値を生み出せるのでは？
チームや会社がうまくいくなら直接自分の手を通してでなくても構わなくて、これも一つのスケールの形なのではないかな？
と考えるようになりました。 同時に、それを実現するために必要なスキルや学ぶべきことも教わりました。
コードを書く時間や量の多寡は状況によって変わると思うのですが、自分はデベロッパーに軸足をおいてやっていくんだ！という勇気をもらったように感じています！
まとめ
今回の研修での最大の収穫は、今まで学んできたことが１つのストーリーのもとつながったことでした。 プラクティスを実践するとき、目的を持って正しい方向へ進んでいるという自信が持て、 また新しいことを学ぶ際にも今何故これを学ぶのか？を価値と原則に照らして判断できるようになり、更に学びの意欲が高まりました！
こうして振り返ってみても、いろいろな角度で自分のソフトウェアエンジニアとしてのキャリアや考え方に大きな影響を与えた研修でした。
当たり前ですが、資格自体には何の価値もありません。 Cope も「認定資格を取ったからといって明日からスクラムマスターになれるわけではない」と言っていたし、今回の研修でも、スクラムデベロッパーとなり、学び続けことを自分で認定しました。 研修で学んだことを咀嚼し、実践し、また学び続けるデベロッパーでありたいと思います！
５日間という長期研修であるためかなり高額なのですが、それを遥かに上回る見返りがありました。 David氏はまた日本でCSD研修をやりたいという旨おっしゃっていたので、また日本で開催されることを期待しています。 ソフトウェアエンジニアリングに軸足をおいてキャリアを積もうと考えている方に、投資先としてもおすすめできます！！
モブプロが大好きなので熱い想いを言語化する
この記事は モブプログラミング Advent Calendar 2018 の22日目の記事です。
前日の投稿は huideyeren さんの 「軽い気持ちでモブプログラミングを行ったら失敗した話」、 次の日は nihonbuson さんの「モブプログラミングをやっている人（及部さん）にレビューを語ってもらった話 #JaSSTReview」です。
モブプロはもはや説明の必要もないほど浸透していると思っていますが、敬愛の意も込めて大好きな動画を張っておきます。
動機
私とモブプログラミングとの出会いは2017年ごろ、どういう話の経緯だったか忘れてしまいましたが、 私の Agile 師匠の一人に教えていただいたのが最初だったと記憶しています。
Mob Programming – A Whole Team Approach by Woody Zuill
これを読んで、これは面白そうだということで、はじめは開発合宿のような特別なイベントを企画してチームで試してみました。
その後育児休暇で半年ほど休んだ り、後述しますがこの論文を書いた Woody 氏との出会いがあったりと本当にいろいろあったのですが、 最近ではチームのほとんどの開発作業をモブプロで行っていて、「みんなでやる」のが自然な姿になっています。
チームにこの働き方が根付くまで、いろいろな試行錯誤や紆余曲折があったのですが、モブプロが好き、と言う気持ちがその行動を促していたことは疑いようがありません。
というわけで、自分で率先してモブプロを導入することに労力を割いてもいいと思える程度にはモブプロが好きなのですが、 自分にとって今年の最大の変化とも言えるモブプロと言う働き方が自分にとって何なのか、という振り返りと、 「好きだ」という曖昧な感情だけで働き方を決めるのもどうかなぁと思うところもあり、 思考の言語化ということでその気持ちの構成要素を分解、整理してみたいと思い至った次第です。
要素と言語化
マインドマップで頭の中を整理してみたところ、大きく４つの象限がありました。
- 楽しさ
- 合理性
- 学び
- 人の縁
順に言語化してみます。
楽しさ
モブプロがなぜ好きか、その要素を考えたとき、まっ先に頭に浮かぶ言葉が「楽しいから」でした。 楽しいことはもちろん好きです。
せっかく仕事をするなら楽しくありたいし、楽しく働く権利があると思っています。 こう思える様になったのは割と年をとってからですが、今では「楽しい」ことがチームの価値の１つであっても良いなと考えています。
プログラミングの楽しさの再発見
私は社会に出てからプログラミングを学びました。 それから１０年以上が過ぎた今でもプログラミングがとても好きなのですが、モブプロをしていると、 初めて自分で書いたコードが動いたときの喜びを追体験するするような、そんな嬉しさを感じます。
これは、後述のチームとしての一体感や達成感と関連していると考えています。
一体感と達成感の共有 - "Ba"
チーム開発は楽しいです。モブプロをやっていると、チームで仕事をしている、ということをとても実感できます。
はじめは「１つのワークアイテムを終わらせたら、みんなでバンザイする」のように意図的に大げさに祝福するスキームを共有して、 楽しさや一体感を演出していました。 実際これはとてもワークして、「モブプロは楽しい」という原体験がチームに定着したと考えています。
前述の通り最近私のチームではモブプロは特別なことではなくなっていて、普通にオフィスフロアやオープンなミーティングスペースで実施しているので、 あまり大げさな祝福イベントはやってないのですが、それでもコンパイルが通ったとき、UTが通ったとき、 結合試験で思い通りの結果が出たときには自然にメンバーに笑顔がこぼれます。
最近、 Jim Coplien 氏の CSM研修を受けました。 研修の中で、課題ワークなどでチームに一体感が生まれたように感じた瞬間、彼が
「Guys, "Ba(場)"」
といってくれて、それがすごく嬉しかったのをよく覚えています。 そのときの感覚、"場" がモブプロによって自然に育まれているように感じます。
個人の精神的負荷の低減
また逆に、「辛いこと」もモブプロならチームと分かち合うことができます。
私のチームは歴史もそれなりにあり、いわゆる「技術的負債」というやつにぶつかることもそれなりの頻度であります。 例えばあまりうまくないコードに出会って、そこを直さなければならないときや、コードから仕様や実装者の意図がまるでわからないとき、 老朽化したインフラで単調な作業をやらなければならないとき... など。
その不透明さ、不確実性に起因する恐怖や不安といった負荷も含めて、個人で負担する「辛さ」がうまく分かち合えていることも、「楽しさ」につながっています。
合理性
大学で物理を専攻したせいもあってか、合理的なものが好きです。
モブプロが合理的なものを目指して生まれたのではなく、自然とその働き方が発生した、というのをどこかの記事で読んだように記憶しているのですが（ソース忘れました、、）、 その生い立ちが逆に真理に近づいているような気がして、また魅力を感じてしまいます。
Efficiency/効率
モブプログラミングは効率が良いのか？という話題はしばしば耳にします。 過去に自分も同じような考察を書いてしまったのですが、今はその手の質問は的外れである場合が多いと考えています。
まず、概ねベロシティやスループットの多寡だけが問題にされている場合、つまり暗黙的にリソース効率を比較しているケースが挙げられます。 リソース効率を意図的に最大化したい場合（Waterfallの大規模開発とか？）であれば、モブプロを選ぶべきではない、という意味で問題ありませんが。
モブプロでは複数名が同時に同じ作業項目に取り掛かるため、自然とチームのWIP（work in progress）が小さい方に制限されます。 これは自然とフロー効率を高める方向に働きますし、さらに依存と待ち時間、マルチタスクのスイッチングコストを最小化することでフロー効率が最大化される... というのはこの資料にもある通りです。
モブプロはフロー効率を高める手段として合理的である、ということが言えるかと思います。
Effectiveness/効果
さらに、そもそもフロー効率であれリソース効率であれ、「効率」だけをソロワークと比較して判断しようとすると、モブプロの持つパワーを過小評価する可能性が高いです。 アウトプットされたものの（曖昧さをあえて包含しての）品質や、それが生み出した成果まで含めて比較することで初めてその真価を評価できます。
初めて Woody 氏にお会いした際、「モブプロしているときのメトリクスとして、何を計測しているのか？」という旨の質問をしてみたところ、 「ほとんどメトリクスは取ってない」との回答をいただきました。 だけど「自分たちが正しいことをやっているのは知っている」と。
当時「メトリクスを取ること」はある種正しいやり方であることを証明するための前提条件のように考えていて、この言葉を聞いたときには衝撃を受けると同時に「流石にナイーブすぎるのでは...」と感じましたが、いま自分が多くの仕事をモブプロでやるようになって、その意味が少しずつ理解できてきたように思います。
これはメトリクス - 特にアウトカムを計測する必要がない、という主張ではありません。
モブプロはチームが「effectively:効果的に」働くことを「最適化」する働き方であり、この意図を持って合理的だ、と考えています。
学び
新しいことを学ぶのが好きです。 ソフトウェアエンジニアリングを愛する人であれば、程度の差はあれど理解してもらえるのではないでしょうか。 そしてモブプロでは、情報伝達が常に顔を合わせてのコミュニケーション、という最高密度の手段となるため、 ソロワークと比べ学びの [機会 x 密度 = 量] が圧倒的に多いです。
伝える側としての学び
モブプロでは仕事を進めるために絶えず対話し、自分の知識を相手に伝わるように言語化しなければなりません。 その作業を通じて、たとえば既存のシステムの仕様が整理されている箇所、されていない箇所が明らかになったり、自分の理解の及んでいないところが明らかになります。
テクニカルスキルについても同様で、「ドライバーの理解度に応じた説明をする」というプラクティスを通じて、自身の技術への理解や習熟度も上がります。
伝えられる側としての学び
「ナビゲータを信頼する」プラクティスの副作用として、自分の認知バイアスをうまく回避して新しい概念を取り入れることができるように思います。 書き終わったコードにレビューされる場合や、手順書やTipsなどのドキュメントを読む場合と比べると、自分の知識や技能の欠陥に気づいた際の歪みが小さいように感じるのです。
これはおそらくフィードバックのタイミングと、文字と対面のコミュニケーションの性質によるところが大きいのだろうと考えています。
チームとしての学び
伝えることと伝えられること、２つをチームが高頻度で濃密に経験することによって、チームの "練兵" というか、 チーム全体でのシステム習熟度や技能向上がすごい勢いで起こります。
この効果はモブプロの経験回数が少ないほど高くなります。 またこの効果の多寡はチーム/チームメンバーの継続年数への依存が小さく、メンバー間のコミュニケーションの密度に大きく依存すると考えています。
つまり、長く存在するチームでもコミュニケーション密度が低ければ効果は高く、 ペアプロをプラクティスとして取り入れているチームにとっては効果は高くない、ということが起こり得る、ということです。
何れにせよ、モブプロはソロワークと比べより多くの学びが得られるスキームであると考えています。
人の縁
最後の要素として、モブプロの第一人者である Woody Zuil 氏との出会いと、不思議な縁が挙げられます。
今年同僚に誘ってもらって AgileJapan に初めて参加したのですが、彼はその基調講演で日本にいらしていて、 当時からすでに私は彼のファンだったので、ネットワーキングセッションで話しかけていろいろとお話を伺う機会を得ることができました。
半分くらいはモブプロや、ソフトウェアエンジニアとしてのキャリアの話をお伺いしていたのですが、 Twitterアカウントを交換しようとして、私のTwitterのアイコン(D-28)を見て「ギター弾くの？」という話になり、 その流れで私が大学時代にやっていた Bluegrass という音楽を彼が昔かなりやっていたことがわかり、それから延々音楽の話をさせてもらいました。
その後、Agile2018 に参加して San Diego で再開し、向こうでもいろいろとお世話になったりと、 勝手に何か不思議な縁を感じています。
これは本当にただただエモいだけで、自分にしか当てはまらないのですが、 自分の中での要素としては他と比べても全く遜色ないほど大きな割合を締めています。
まとめ
タイトル通りモブプロが好きな理由を長々と語ってみました。
改めて整理してみたことで、学びや合理性といった論理的な面と、楽しさや縁といった情緒的な面が混ざり合って「モブプロが好きだ」という感情を形成していることがわかりました。
この記事の目的は、モブプロが最高だからみんなやろう！と言いたいわけではありませんし、モブプロを普及しよう、というところにはありません。 モブプロがワークするか、効果的に働けるかはそのチームのコンテキストに強く依存するはずですし、そもそもみんなが同じ働き方をする必要はないと思います。
自分にとって今年の大きな変化出会ったモブプロについて整理したかったのと、好きなことを伝えたいと思っただけのいわゆるチラ裏案件ですが、 モブプロに興味がある、やってみたいと思っている方の背中を少し押すようなことが起これば幸いです。
