デベロッパーとして生きていく ー 認定スクラムデベロッパー になりました！
先日、 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 で再開し、向こうでもいろいろとお世話になったりと、 勝手に何か不思議な縁を感じています。
これは本当にただただエモいだけで、自分にしか当てはまらないのですが、 自分の中での要素としては他と比べても全く遜色ないほど大きな割合を締めています。
まとめ
タイトル通りモブプロが好きな理由を長々と語ってみました。
改めて整理してみたことで、学びや合理性といった論理的な面と、楽しさや縁といった情緒的な面が混ざり合って「モブプロが好きだ」という感情を形成していることがわかりました。
この記事の目的は、モブプロが最高だからみんなやろう！と言いたいわけではありませんし、モブプロを普及しよう、というところにはありません。 モブプロがワークするか、効果的に働けるかはそのチームのコンテキストに強く依存するはずですし、そもそもみんなが同じ働き方をする必要はないと思います。
自分にとって今年の大きな変化出会ったモブプロについて整理したかったのと、好きなことを伝えたいと思っただけのいわゆるチラ裏案件ですが、 モブプロに興味がある、やってみたいと思っている方の背中を少し押すようなことが起これば幸いです。
パパエンジニアがITと分析を駆使して保活した話
この記事は、 子育てエンジニア Advent Calendar 2018 の ８日目の記事です。
TL;DR
この記事では、ITを使って
- 完全に無料で
- 時間を掛けずに
- 特殊な技能を使わず
- 現実的に入れる保育園を探す
方法を紹介します。 具体的には、Googleのサービスを駆使して、以下を作ります。
これを見ながら、全体の申込み倍率とその推移を見て自分たちの世帯がどれくらいリスクが取れるかを判断し、 「通える範囲で」「現実的に入れるチャンスがある」認可保育園を特定して申し込みます。
なぜやるのか？の前提が必要ない方は こちら からご覧ください。
はじめに：モチベーション
昨年の９月から４月（＝保育園にはいれるまで）にかけて、育児休暇を取得しました。 振り返ってみると、育児休暇はじっくり子供と向き合い、信頼関係を築く時間がとれた素晴らしい経験でした。
しかし休んでいる最中はやはり辛いことや不安も多くありました。 その中でもダントツで辛かったのが "保活" です。
保活は基本、体力勝負です。 説明会はもちろん訪問が基本。 認証園は説明会に参加することが申し込みの前提である場合がほとんどですし、認可園の説明会もいかないわけにはいきません。 各園の説明会が本格化する10月~からは、毎週どこかの保育園の説明会に参加することになります。 小さな子どもを連れての移動は、男性の自分でもかなり体力を消耗しました。
また、役所も保育園も基本アナログ体質です。 散在する情報の収集、大量の手書きの申込書類や説明会で配られるプリント、書類提出などのスケジュール管理に容赦なく時間を奪われます。 選考方法についても事前に説明がないケースがほとんどで、かつ説明会の日程や園の住所、電話番号が一覧できる場所すらありません。紙にすらまとまっていません...
極めつけは、申し込みは指定された期間に書類を市役所に直接持ち込んでで行わなければならず、期間中の窓口では職員のキャパを完全に超えていて、長蛇の列で６時間ち、という状態でした。 0歳の子供を連れて朝出かけて、街で６時間過ごすのがどれだけ大変か...
重複した項目を何度も書かされる書類、目視によるエラーバリデーション（まあ検出率は相当に高いはずですが）、etcetc...
育児の負担を少しでも減らすため、こういうところにこそ投資してITを導入してほしいと切に願います。
それに加え、保活に失敗したら仕事に復帰できない、最悪職を失うリスクがある、という事実が非常にストレスになりました。 冷静に考えれば、育児休暇は子供が１歳２ヶ月になるまでは伸ばせるし、５，６月に追加枠でどこかの園に入れる可能性もそれなりにあると思うのですが、体力の消耗と相まって精神をすり減らしました。
愚痴っぽくなってしまいましたが、時間がない中で、得られる情報を整理し、客観的に分析して最善の選択をするためにエンジニアリングを用いました。 おなじように保活に不安を抱えるパパママに、少しでもその不安を和らげるお手伝いができればと思い、この手段を共有します。
背景
ご存知の通り、東京都の保育園は大きく３つに分類できます。
- 認可保育園
- 認証保育園
- 認可外保育園
調布市では認可外保育園は多くなく、また評判も良くないため対象外としました。
認証保育園
認証保育園については、定員の数こそ公開されますが申込数や選考プロセスは公表されないため、できることは多くありません。 住所をデータ化しておいて、GoogleMapで距離を確認しておく、スケジュールをカレンダーアプリで管理する... くらいでしょうか。
私の観測範囲でですが、認証園の選考の方法は主に３つです。
- 完全抽選
- 先着
- ”園独自の基準”による選考
この中で時間を使うべきは "園独自の基準" による選考、を謳っている園で、 実際に、この選考方針を取っている複数の認証園から内定をもらうことができました。
完全抽選の認証園は通わせても良いと判断できれば申し込んでおくに越したことはないと思います。
認可保育園
認可園を決定するプロセスは自治体ごとに事細かに決められており、公開されています。 完全にポイント制で、機械的に決められるため感情を持ち込む余地はありません。
事前に役所に問い合わせたところ、多くの家庭がいわゆる「満点」の状態になっており、 実質的に「行きたい」保育園を選べる余地はほとんどなく、「入れる」保育園を探すデータ勝負になることはわかっていました。
というわけで、エンジニアリングでの主戦場はこちらです。 この後の話はすべて、認可園の情報を集めて整理し、判断材料にする話になります。
大前提として、自分の大切な子供の命を預ける場所です。 もちろん入れれば何処でもいい、というわけには行きません。 今回は申し込みする可能性のある全ての保育園の説明会に足を運び、「付近の認可園であれば、どこでも安心して預けられそうだ」という確証が得られたのでデータ勝負としました。
「ここには預けられない」と判断した園がある場合でも、そこを除外して選定すればよいと思います。
作り方
1. データ収集
データと言っても、判断材料として得られる情報は多くありません。 調布市では定員数と申込数/実申込数と、その推移くらいです。
３年分くらいは過去にさかのぼって取得できると思われるので、まずは自治体のサイトに行き、申込状況のデータを探します。 今年の分だけでなく過去データも確認する目的は、去年までの経験談などコミュニティから得られた情報と突合して、今年の状況を客観的に判断する材料にすることが主な目的です。 また、変化の傾向から、その自治体がどれくらい保育の充実に力を入れているかをうかがい知ることができます。
調布市では園名、定員数、申込数がPDF形式で表になっていました。おそらくどこもこんな程度なのではないかなと思います。
これをまずは Google スプレッドシート にデータ化します。 もしデータがPDF形式である場合は、内部の表からデータをコピーするのは骨が折れるので、適当なオンラインサービスを探して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 データソースをコピー
予め「データソース」をコピーしておきます。 「データソース」とは、レポートに表示するデータの接続先の定義になります。
ちょっとややこしいですが、以下の手順でコピーを行い、「２．データ整形」で作成したスプレッドシートにデータソースを接続します。
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サービスのみを利用しているので、新しいスキルを身につけることなく、現実的な時間でその投資に見合う情報を得られると思っています。
我が家では、去年一次申し込み後に発表される申込状況を見てこの可視化を行ったことで、 家から通える距離で、かつ申込み倍率が低い保育園があることに気づき、希望園変更手続きを出して無事その園で内定を得ることができました！
働きたいけど保育園が... と悩むすべてのパパママに、少しでもお役に立てていただければと思います！
