モブプロが大好きなので熱い想いを言語化する

この記事は モブプログラミング 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）が小さい方に制限されます。 これは自然とフロー効率を高める方向に働きますし、さらに依存と待ち時間、マルチタスクのスイッチングコストを最小化することでフロー効率が最大化される... というのはこの資料にもある通りです。

Mob programming and the power of flow agilejapan 2018 from Kenji Hiranabe

モブプロはフロー効率を高める手段として合理的である、ということが言えるかと思います。

Effectiveness/効果

さらに、そもそもフロー効率であれリソース効率であれ、「効率」だけをソロワークと比較して判断しようとすると、モブプロの持つパワーを過小評価する可能性が高いです。 アウトプットされたものの（曖昧さをあえて包含しての）品質や、それが生み出した成果まで含めて比較することで初めてその真価を評価できます。

初めて Woody 氏にお会いした際、「モブプロしているときのメトリクスとして、何を計測しているのか？」という旨の質問をしてみたところ、 「ほとんどメトリクスは取ってない」との回答をいただきました。 だけど「自分たちが正しいことをやっているのは知っている」と。

当時「メトリクスを取ること」はある種正しいやり方であることを証明するための前提条件のように考えていて、この言葉を聞いたときには衝撃を受けると同時に「流石にナイーブすぎるのでは...」と感じましたが、いま自分が多くの仕事をモブプロでやるようになって、その意味が少しずつ理解できてきたように思います。

これはメトリクス - 特にアウトカムを計測する必要がない、という主張ではありません。

モブプロはチームが「effectively:効果的に」働くことを「最適化」する働き方であり、この意図を持って合理的だ、と考えています。

学び

新しいことを学ぶのが好きです。 ソフトウェアエンジニアリングを愛する人であれば、程度の差はあれど理解してもらえるのではないでしょうか。 そしてモブプロでは、情報伝達が常に顔を合わせてのコミュニケーション、という最高密度の手段となるため、 ソロワークと比べ学びの [機会 x 密度 = 量] が圧倒的に多いです。

伝える側としての学び

モブプロでは仕事を進めるために絶えず対話し、自分の知識を相手に伝わるように言語化しなければなりません。 その作業を通じて、たとえば既存のシステムの仕様が整理されている箇所、されていない箇所が明らかになったり、自分の理解の及んでいないところが明らかになります。

テクニカルスキルについても同様で、「ドライバーの理解度に応じた説明をする」というプラクティスを通じて、自身の技術への理解や習熟度も上がります。

伝えられる側としての学び

「ナビゲータを信頼する」プラクティスの副作用として、自分の認知バイアスをうまく回避して新しい概念を取り入れることができるように思います。 書き終わったコードにレビューされる場合や、手順書やTipsなどのドキュメントを読む場合と比べると、自分の知識や技能の欠陥に気づいた際の歪みが小さいように感じるのです。

これはおそらくフィードバックのタイミングと、文字と対面のコミュニケーションの性質によるところが大きいのだろうと考えています。

チームとしての学び

伝えることと伝えられること、２つをチームが高頻度で濃密に経験することによって、チームの "練兵" というか、 チーム全体でのシステム習熟度や技能向上がすごい勢いで起こります。

この効果はモブプロの経験回数が少ないほど高くなります。 またこの効果の多寡はチーム/チームメンバーの継続年数への依存が小さく、メンバー間のコミュニケーションの密度に大きく依存すると考えています。

つまり、長く存在するチームでもコミュニケーション密度が低ければ効果は高く、 ペアプロをプラクティスとして取り入れているチームにとっては効果は高くない、ということが起こり得る、ということです。

何れにせよ、モブプロはソロワークと比べより多くの学びが得られるスキームであると考えています。

人の縁

最後の要素として、モブプロの第一人者である Woody Zuil 氏との出会いと、不思議な縁が挙げられます。

今年同僚に誘ってもらって AgileJapan に初めて参加したのですが、彼はその基調講演で日本にいらしていて、 当時からすでに私は彼のファンだったので、ネットワーキングセッションで話しかけていろいろとお話を伺う機会を得ることができました。

半分くらいはモブプロや、ソフトウェアエンジニアとしてのキャリアの話をお伺いしていたのですが、 Twitterアカウントを交換しようとして、私のTwitterのアイコン(D-28)を見て「ギター弾くの？」という話になり、 その流れで私が大学時代にやっていた Bluegrass という音楽を彼が昔かなりやっていたことがわかり、それから延々音楽の話をさせてもらいました。

その後、Agile2018 に参加して San Diego で再開し、向こうでもいろいろとお世話になったりと、 勝手に何か不思議な縁を感じています。

これは本当にただただエモいだけで、自分にしか当てはまらないのですが、 自分の中での要素としては他と比べても全く遜色ないほど大きな割合を締めています。

まとめ

タイトル通りモブプロが好きな理由を長々と語ってみました。

改めて整理してみたことで、学びや合理性といった論理的な面と、楽しさや縁といった情緒的な面が混ざり合って「モブプロが好きだ」という感情を形成していることがわかりました。

この記事の目的は、モブプロが最高だからみんなやろう！と言いたいわけではありませんし、モブプロを普及しよう、というところにはありません。 モブプロがワークするか、効果的に働けるかはそのチームのコンテキストに強く依存するはずですし、そもそもみんなが同じ働き方をする必要はないと思います。

自分にとって今年の大きな変化出会ったモブプロについて整理したかったのと、好きなことを伝えたいと思っただけのいわゆるチラ裏案件ですが、 モブプロに興味がある、やってみたいと思っている方の背中を少し押すようなことが起これば幸いです。

パパエンジニアがITと分析を駆使して保活した話

この記事は、 子育てエンジニア Advent Calendar 2018 の ８日目の記事です。

TL;DR

この記事では、ITを使って

• 完全に無料で
• 時間を掛けずに
• 特殊な技能を使わず
• 現実的に入れる保育園を探す

方法を紹介します。 具体的には、Googleのサービスを駆使して、以下を作ります。

これを見ながら、全体の申込み倍率とその推移を見て自分たちの世帯がどれくらいリスクが取れるかを判断し、 「通える範囲で」「現実的に入れるチャンスがある」認可保育園を特定して申し込みます。

なぜやるのか？の前提が必要ない方は こちら からご覧ください。

はじめに：モチベーション

昨年の９月から４月（＝保育園にはいれるまで）にかけて、育児休暇を取得しました。 振り返ってみると、育児休暇はじっくり子供と向き合い、信頼関係を築く時間がとれた素晴らしい経験でした。

しかし休んでいる最中はやはり辛いことや不安も多くありました。 その中でもダントツで辛かったのが "保活" です。

保活は基本、体力勝負です。 説明会はもちろん訪問が基本。 認証園は説明会に参加することが申し込みの前提である場合がほとんどですし、認可園の説明会もいかないわけにはいきません。 各園の説明会が本格化する10月~からは、毎週どこかの保育園の説明会に参加することになります。 小さな子どもを連れての移動は、男性の自分でもかなり体力を消耗しました。

また、役所も保育園も基本アナログ体質です。 散在する情報の収集、大量の手書きの申込書類や説明会で配られるプリント、書類提出などのスケジュール管理に容赦なく時間を奪われます。 選考方法についても事前に説明がないケースがほとんどで、かつ説明会の日程や園の住所、電話番号が一覧できる場所すらありません。紙にすらまとまっていません...

極めつけは、申し込みは指定された期間に書類を市役所に直接持ち込んでで行わなければならず、期間中の窓口では職員のキャパを完全に超えていて、長蛇の列で６時間ち、という状態でした。 0歳の子供を連れて朝出かけて、街で６時間過ごすのがどれだけ大変か...

重複した項目を何度も書かされる書類、目視によるエラーバリデーション（まあ検出率は相当に高いはずですが）、etcetc...

育児の負担を少しでも減らすため、こういうところにこそ投資してITを導入してほしいと切に願います。

それに加え、保活に失敗したら仕事に復帰できない、最悪職を失うリスクがある、という事実が非常にストレスになりました。 冷静に考えれば、育児休暇は子供が１歳２ヶ月になるまでは伸ばせるし、５，６月に追加枠でどこかの園に入れる可能性もそれなりにあると思うのですが、体力の消耗と相まって精神をすり減らしました。

愚痴っぽくなってしまいましたが、時間がない中で、得られる情報を整理し、客観的に分析して最善の選択をするためにエンジニアリングを用いました。 おなじように保活に不安を抱えるパパママに、少しでもその不安を和らげるお手伝いができればと思い、この手段を共有します。

背景

ご存知の通り、東京都の保育園は大きく３つに分類できます。

• 認可保育園
• 認証保育園
• 認可外保育園

調布市では認可外保育園は多くなく、また評判も良くないため対象外としました。

認証保育園

認証保育園については、定員の数こそ公開されますが申込数や選考プロセスは公表されないため、できることは多くありません。 住所をデータ化しておいて、GoogleMapで距離を確認しておく、スケジュールをカレンダーアプリで管理する... くらいでしょうか。

私の観測範囲でですが、認証園の選考の方法は主に３つです。

• 完全抽選
• 先着
• ”園独自の基準”による選考

この中で時間を使うべきは "園独自の基準" による選考、を謳っている園で、 実際に、この選考方針を取っている複数の認証園から内定をもらうことができました。

完全抽選の認証園は通わせても良いと判断できれば申し込んでおくに越したことはないと思います。

認可保育園

認可園を決定するプロセスは自治体ごとに事細かに決められており、公開されています。 完全にポイント制で、機械的に決められるため感情を持ち込む余地はありません。

事前に役所に問い合わせたところ、多くの家庭がいわゆる「満点」の状態になっており、 実質的に「行きたい」保育園を選べる余地はほとんどなく、「入れる」保育園を探すデータ勝負になることはわかっていました。

というわけで、エンジニアリングでの主戦場はこちらです。 この後の話はすべて、認可園の情報を集めて整理し、判断材料にする話になります。

大前提として、自分の大切な子供の命を預ける場所です。 もちろん入れれば何処でもいい、というわけには行きません。 今回は申し込みする可能性のある全ての保育園の説明会に足を運び、「付近の認可園であれば、どこでも安心して預けられそうだ」という確証が得られたのでデータ勝負としました。

「ここには預けられない」と判断した園がある場合でも、そこを除外して選定すればよいと思います。

作り方

1. データ収集

データと言っても、判断材料として得られる情報は多くありません。 調布市では定員数と申込数/実申込数と、その推移くらいです。

３年分くらいは過去にさかのぼって取得できると思われるので、まずは自治体のサイトに行き、申込状況のデータを探します。 今年の分だけでなく過去データも確認する目的は、去年までの経験談などコミュニティから得られた情報と突合して、今年の状況を客観的に判断する材料にすることが主な目的です。 また、変化の傾向から、その自治体がどれくらい保育の充実に力を入れているかをうかがい知ることができます。

調布市では園名、定員数、申込数がPDF形式で表になっていました。おそらくどこもこんな程度なのではないかなと思います。

これをまずは Google スプレッドシート にデータ化します。 もしデータがPDF形式である場合は、内部の表からデータをコピーするのは骨が折れるので、適当なオンラインサービスを探してExcelなどに変換します。 私は今回は以下のサービスを使いました。

PDF to EXCEL

2. データ整形

ここが一番面倒なのですが、コピー＆ペーストなどのエクセル技を駆使して、以下の形式に表を変換し、スプレッドシートに保存します。

生データ

名称	年度	西暦(年)	西暦	年次	募集	申込
上布田	平成２９年度	2017	20170401	０歳児クラス	8	93
下布田	平成２９年度	2017	20170401	０歳児クラス	10	73
仙川	平成２９年度	2017	20170401	０歳児クラス	6	95

集計済みデータ

年度	西暦(年)	西暦	年次	募集	申込	申込者数
平成２９年度	2017	20170401	０歳児クラス	469	3,143	621
平成２９年度	2017	20170401	１歳児クラス	319	3,225	631
平成２９年度	2017	20170401	２歳児クラス	172	1,661	341
平成２９年度	2017	20170401	３歳児クラス	140	851	205

※ 集計済みデータの「申込者数」について 保育園の申込件数に対して、実際に申込をした人の人数です。 どこの自治体でも似たような制度かと思いますが、１人が複数の保育園に申し込むことができるため、保育園への申込数は実際の申込人数と大きく乖離します。 このため、実際の倍率を見積もる上で実申込数は非常に重要な情報であると言えます。 もし公開されていない場合は、申込み可能数で総申込数を割って入力しておいてください。

この後集計＆グラフ化する際、いわゆる「縦持ち」のほうが扱いやすかったので、多少変換は面倒ですが今回はこのような形式を取りました。

3. 可視化１：ダッシュボード

さて、数字の羅列をただ眺めても気づきは少ないので、可視化します。

いろいろ選択肢はあるのですが、今回は Google データポータル（旧データスタジオ） で作りました。 すごく高機能、というわけではないですが、そこそこの見栄えのレポートをGUIですばやく簡単に作れますし、Googleスプレッドシートとの相性がよく、何より無料です。

ちょっと手順がややこしいですが、以下のやり方で違うデータで同等のレポートを実現できるはずです。

3.1 データソースをコピー

予め「データソース」をコピーしておきます。 「データソース」とは、レポートに表示するデータの接続先の定義になります。

H31 調布市 生データ

H31 調布市 集計済みデータ

ちょっとややこしいですが、以下の手順でコピーを行い、「２．データ整形」で作成したスプレッドシートにデータソースを接続します。

1. コピーボタン > 「データソースのコピー」を選択

2. 接続先を編集 「変更された項目」が出ることがありますが次へ

3. 先ほど作成したスプレッドシートを選択

4. わかりやすい名前に変更

これを上記２つのデータソースで行います。

3.2 レポートをコピー

H31 調布市認可保育園申込状況 にアクセスし、コピーアイコンから

この画面で、先ほど作成した２つのスプレッドシートを選択してください。

これで、作成したデータで冒頭と同じ形式のレポートが作成できます！

その他 Google データポータルの使い方は詳しいサイトがありますのでそちらに譲ります。 テンプレートを利用して独自の集計、分析を行うのも良いと思います。

データポータル（旧 Google Data Studio）を使ってみよう！メリットや初心者向け使い方・Analytics連携方法をご紹介します

4. 可視化２：地図プロット

保育園選びでは、保育園の場所も非常に重要なファクターとなります。 いくら入れるとはいえ、家から遠すぎては意味がありません。というわけで、保育園の位置と申し込み倍率を地図上にプロットします。

4.1 地図用データ を作る

地図にプロットしたいので、住所が必要になります。 各自治体のHPで運が良ければ保育園とHPの一覧があると思うので、適宜コピーして園名と住所の一覧をスプレッドシートに作ります。 そして、先に作成していた募集、申込みの人数を入れて一つの表にします。 こんな感じになります。

地図用データ

ID	略称	保育所名	所在地	定員	１歳-募集	１歳-申込	倍率
1	皐月	皐月保育園	調布市小島町2-20-3	130	2	74	37
2	保恵学園	保恵学園保育所	調布市富士見町3-1	110	2	13	6.5
3	八雲台	八雲台保育園	調布市八雲台1-32-1	100	3	63	21
4	ポピンズナーサリースクール調布	ポピンズナーサリースクール調布	調布市西つつじヶ丘2-4-1	50	1	25	25

VLOOKUPなどの関数を利用してサクッとやれればよいのですが、HPと申込み状況書類とで保育園の記載順や呼称が異なる！なんてことも往々にしてあります。 １自治体なら数も多くないですし、手間ですが目視で確認しながらがんばります。 IT化...

余裕があれば、電話番号やHPなども適宜載せておくと、地図に出したとき便利です。

4.2 Google マイマップに表示する

Google マイマップ にアクセス

「新しい地図を作成」 または

Googleマップのハンバーガーアイコン（メニュー） > マイプレイス > マイマップ

からも呼び出せます。

インポート > スプレッドシート > 先程作成したスプレッドシートを選択

先頭（一番左側）のシートが認識されるので、住所の列の名前を選択

同じ要領で、地図上のマークに表示する名前を選択すると完成です。

最後に、申込み倍率に濃淡をつけると、激戦区がわかっていい感じです。

スタイル > 個別のスタイル > 範囲 > 濃淡を選択

GoogleMapにプロットすると、自宅や職場、駅からの道順と距離を出せたりしてとても便利です。 主にこれを見ながら、時間や安全面からこの先通えるかどうか？と倍率のトレードオフを判断します。

まとめ

いかがだったでしょうか。

子育てしてるとき、特に子供が小さいと本当に時間がないですよね。 去年やったときは、子供がお昼寝しているスキマ時間と、夜の時間で作りました。 かかった時間はおそらくぜんぶで 4 ~ 5 時間といったところで、私がそうだったように、フルタイム主夫＆保活前線真っ只中でもなんとか確保できる時間かと思います。

この方法はおそらく多くの人が使えるであろうエクセル＋直感的に使えるGoogleのWebサービスのみを利用しているので、新しいスキルを身につけることなく、現実的な時間でその投資に見合う情報を得られると思っています。

我が家では、去年一次申し込み後に発表される申込状況を見てこの可視化を行ったことで、 家から通える距離で、かつ申込み倍率が低い保育園があることに気づき、希望園変更手続きを出して無事その園で内定を得ることができました！

働きたいけど保育園が... と悩むすべてのパパママに、少しでもお役に立てていただければと思います！