ikuo’s blog

育児やエンジニアリングについて

仕事大好きエンジニアが半年間パパだけの育休をとった話

f:id:martin_lover_se:20190605234656j:plain

件の育休復帰に関する一連のニュースを見ていて、居ても立ってもいられない気持ちになったので筆を執りました。

かれこれ1年前になりますが、7ヶ月ほど育児休業を取りました。 入れ違いで妻は仕事に復帰し、パパ1人での育児休業だったので、期間的にもそうですが今日でもそこそこレアケースではないかなと思います。

自分もそうでしたが、仕事が好きな人ほど長期間職場を離れることに不安や抵抗があると思います。 自分の経験を共有することで、そんなパパの育休取得を少しでも後押しすることができれば...

TL;DR

  • なぜ育休をとったの?
    • 夫婦間での公平性。育児で女性だけがキャリアにビハインドを負う合理的な理由ってあります?
  • 育休どうだった?
    • 辛いことや不安も多かったけど、それを差し引いても息子との時間は代えがたいものでした。
  • 復帰したあとどうだった?
    • 半年休んだ程度なら、キャリアとかスキルとか知識に何の問題もなかったです!

件の事件のようなこともまだまだ存在し、手放しに「みんな育休取りましょう!」とは言えない世の中かと思うのですが、 少なくとも自分にとっては貴重な体験でしたし、もっとパパ育休が増えると良いと思っています!

背景

都内在住、30代で夫婦共働きです。 タイトルの通り、私はITエンジニアを生業にしています。 妻は理系大学院を出て研究職として働いており、適切な言葉かはわかりませんがいわゆる「バリキャリ」の部類だと思います。

妻も私も実家は遠く、両親の援助は得られない状況でした。

私は仕事が大好きで、結婚してからも子供ができるまではワーカーホリックのような働き方をしていました。 今でも仕事は大好きですが、少し「好き」の表現の仕方が変わっていて、子供が生まれてからは完全定時ダッシュおじさんになりました。 理解のあるチームで本当に感謝です。

というわけで、このお話は「仕事大好きな人が半年仕事をしない決断をした話」と解釈いただければと思います。

どれくらいの期間?

8月末から、4月頭に保育園に入るまでの7ヶ月と少しです。 最初の半月ほどは、引き継ぎも兼ねて妻に休みをオーバーラップしてもらいました。 9月中旬に妻が職場復帰し、それから4月1日に保育園に入れるまでの期間、パパ1人で奮闘しました。

半年という期間はやはり長くて、最初の一ヶ月を終えた頃は

「やっと一ヶ月か... これが永遠に続くような気がする...」

みたいな感覚でいたのを思い出します。

なぜ育休をとったの?

2017年の1月、息子が生まれました。

早生まれで、(ギリギリ預けられたのですが)0歳で保育園に預けるのは心もとないな... とはいえ、1歳で保育園に入れるまでまるまる妻が休むと1年以上仕事を離れる事になる...

という事情から、妻とお互いのキャリアについて話し合いをする中で、育児休業を取ることを打診され、考えるようになりました。

半年間仕事を休んで子育てにフルコミットしたらどうなるんだろう...と、少しの好奇心が働いたことは否定できませんが、 最終的には以下のことが決め手となり、育休を取ることを決心しました。

育休は法律... だけど、会社の理解があったこと

まず前提として、男性の育児休業は会社の制度ではありません。法律で定められている労働者の権利です。 と書きましたが、恥ずかしながら私も育児休業が法律に定められていることは妻に教えてもらうまで知りませんでした。

...とはいえ現実を見ると、この事自体が知られていなかったり、封殺してしまうような会社が存在することも事実です。

私はサイバーエージェントという会社で働いています。 前述の通り半年以上育児休業を取得し、何の問題もなく復帰を果たしました。 会社にはパパの育休をはじめ、リモートワークなど育児を支援する様々な制度が整備されており、心理的にも実務的にもかなり助けられました。というか今でも助けられています。

今の「社会」では、(残念ながら)この環境は決して当たり前だったり、法律だから前提...などといえる状況ではなく、 とても恵まれている環境なんだと認識しています。

お互いのキャリアにおける「公平」さ

「出産、育児において女性だけがキャリアにビハインドを負う合理的な理由ってあるんだっけ?」

これは妻から言われたのではなく、自問するうちたどり着いた問いです。 もちろん各家庭の状況によると思いますが、結局自分のコンテキストでは答えを見つけられませんでした。

合理的でないから休まない、ということが言いたいわけではありません。

手前味噌ですが、私の妻は仕事人としてとても優秀です。 その妻が働けないことや、キャリアを諦めること自体が間違いなく社会損失ですし、妻を差し置いて自分だけ働く理由がありません。 収入の多寡も関係なく、私にとって、妻と私のキャリアにおいての「公平さ」は決断における大切なファクターでした。

もちろん妊娠中の仕事への影響や、出産前の休暇など含めるとどうしても妻のほうが仕事への影響は大きかったと思うのですが、それでも休んだことに意義はあったと考えています。

そもそも父親です

「自分の息子を(妻はできるのに)一人で世話して育てることが出来ないの?」

という問いがもう一つ決断の柱になりました。 出産や授乳は変わることはできないけど、それ以外のことはパパでもできるし、やるのが当然だと思います。

育休を取る前も、土日は息子と一緒に過ごすことが多かったとはいえ、自分が育児の主体になった経験は今でも非常に役立っています。 たとえば、妻の宿泊を伴う出張にも、何の問題もなく対処できます。

冗長化、大事ですよね!

育休を取る前の仕事の様子は?

育休を取ると決めてからすぐ上司相談にして、そのあと人事に相談しました。 息子が生まれるよりも前、育休に入る9ヶ月以上前でした。早めの相談は会社、チームと自分双方にとって大切だと思います。

初めてその話を上司に切り出したとき、快諾してもらえて、ずいぶん安心したのをよく覚えています。いい会社で働いているなー、と。

その後、同じ部署でチームを異動したり、ということはありましたが、一貫して「自分にしかできない仕事をつくらない」ことを心がけていました。 私はエンジニアなので、担当したタスクのドキュメントを詳細に残す、であったり、基本仕事を進めるときに誰かを巻き込んでバックアップ体制を取る、といった具合です。

もちろん「この人は半年後に休む予定だから...」といって不当に簡単なタスクを割り当てられるようなことはなく、 休みに入る直前まで今の自分のスキルをフルに活かして貢献できる責任ある仕事をやらせてもらっていたし、それをこなしていたと自負しています。

その甲斐もあってか、チームからも快く送り出してもらうことが出来ました。

余談ですが最近では育児休業をとらなくても、普段から属人化を減らしておいたほうが良いなと感じています。 若い頃は「この仕事は自分にしか出来ない...」という謎の使命感、というか自己満足な感情があったのですが、 まあそこそこの規模の会社であれば大体代わりの人はいますし、そうあるべきだと思います。

なお最近では、チームの働き方としてモブプロを採用しており、バス係数=チーム人数でとても安心感があります。

martin-lover-se.hatenablog.com

ITエンジニアは育児休業取りやすい職業なのかな?...と思っていたんですが、なんで取りやすいのか理由を考えてみたら特に浮かばなかったです。 他の業種はやったことがないのでわからないですが。会社が先進的だ、というだけかもしれません。

何れにせよ、会社や上司の理解があること、はもっとも重要なファクターであると考えます。

育休中の様子は?

平日の過ごし方

全力で専業主夫をこなしていました。

とはいえ家事は妻と折半ですし、ママ友の話を聞いていてもほかの専業主婦ママよりはだいぶユルかったと思いますが... まあ、あまり頑張りすぎないのも大切だったかなと思います。 (世のママさん、パパの家事のアラは少し大目に見てやってください...)

朝ごはんを作って、息子と妻に食べてもらって妻を送り出して、
日中は公園にお散歩に行ったり、公民館や地域のイベントに出かけたり。
帰ってきたら息子といっしょに「おかあさんといっしょ」見て、ブンバボン歌って。
晩御飯の準備して、息子をお風呂に入れたらあっという間に夜... という具合ですね。

なお我が家では家事と育児は私と妻で2等分です。 私が働いて妻が休んでいるときもそうでしたし、共働きに戻った今でもそうしています。

全力で1週間育児にコミットした方ならご理解いただけると期待するのですが、特に子供が小さいときは、仕事より育児のほうが負荷が高いです。 もちろん業種業態にもよると思いますが、少なくとも私にとってはそうでした。 冗長な構成を取ることはやはり大切だと考えます。

良かったこと

何をおいても、息子とゆっくり、たくさんの時間を共有し、成長著しい時期を共に過ごせたことが最高でした。

育休に入った頃にはおすわりもおぼつかなかった息子が、
ハイハイを初めて、タッチできるようになって、高ばいできるようになって。
歩き始め... る前に残念ながら休み明けてしまいましたけど。
言葉が出始めて、「ママ」より「パパ」をたくさん言ってくれたり(一緒にたくさん練習したからね)
食べ物を選び始めて、人見知りしだしてずーっとパパにしがみついてて。

時間は巻き戻りません。長い仕事人生の中でたった半年キャリアを欠損したとしても、代えがたい思い出を得られました。 もちろん育児休業を取らなくても思い出は作れると思いますが、長い時間を共にして、しっかりと息子と信頼関係も築けたと考えています。

最近「ママがいい〜」とか言われますけど...。

特筆事項として、電動自転車の導入でとても心が軽くなったことを書き残しておきます。 1歳くらいから乗れるようになるのですが、それまではベビーカーや抱っこ紐、あるいは両方持っての移動でした。

抱っこ紐やベビーカーでの移動はとても大変だし、公共交通機関を使うにも気を使うし、遠くに移動できないし...行動範囲も狭くなりがちです。 それが電動自転車の導入で移動がとても楽になり、行動範囲も広がってそれだけで心がとても晴れやかになったのをよく覚えています。

コスパ最高なので1歳になったら是非購入をご検討ください。

辛かったこと

一番つらかったのは、「社会から隔絶されている」と感じてしまうことです。 いま冷静に考えると実際にはそんなことはないし、完全な勘違いなのですが、やはり大人とのコミュニケーションが減って、視野が狭くなりがちだったと思います。

具体的な辛かったことと、その対処をいくつか紹介します。

子供の命を預かる不安

これは完全に当たり前で、世の中のすべてのパパママがそうなのですが、 休日を息子と2人で過ごすことは多くあったにもかかわらず、最初のママがいない平日の不安な気持ちをよく覚えています。

少しのミスが息子の命にかかわるのではないか...という。

この不安は慣れによってだんだん緩和されていったのですが、 育児本を読んだり、地域イベントの小児救急ワークショップに参加したりして「もしも」に備える行動を取ることで、少しずつ自信がついて解決していきました。

パパコミュニティがないのが辛い

平日の昼間に、1歳の子供と遊びに行くところといえば

  • 公民館
  • 子育てセンター
  • 保育園(主にイベントごと)
  • 公園

あたりがメインになると思うのですが、驚くほどパパと子供だけで遊びに来ている親子が少なかったです。 半年間で片手に収まる程度、とかそういうレベルです。 パパも5%くらい育休取得しているはずなのですが... 。 たしかに、私も初期のころはパパと子供だけでイベントごとに遊びに行くことの心理的なハードルは結構高かったです。

当然、地域の子育てコミュニティはママで構成されていて、パパ育休の不安や悩みを共有できる人がいないのが辛かったです。

地域のママたちと共通の話題はもちろんあるのですが、やっぱりママだけのところにパパが居ると、授乳のこととか話しづらい話題もあるんだろうな...と言う空気を勝手に感じてしまっていたりしました。

これも時間が解決してくれて、結局、解は「ママコミュニティに参加すること」でした。 だいたい曜日替わりでイベントごとがあるのですが、毎週通っているとよく会うママや子供と自然に会話します。 ママたちも、パパの参加は珍しいのでよく話しかけてくれます。こちらが壁を作らなければ、案外あっさり溶け込めました。

とくに「プランケット」というイベントに参加できたことはとても幸運でした。 ここで出会ったママ友のみなさんと、助産師の田中先生には本当に救われました。 気兼ねなく話せて、悩みを相談&共有できる場で、毎週楽しみに通わせていただきました。

仕事も勉強もしてない、という事実が辛い

育休を取りながらの勉強、できる人はできると思いますが、自分にはほぼ無理でした。

技術が進んでるんじゃないか...
仕事が進んでるんじゃないか...
勉強できてない... 本を読むことすらできてない...

と、ネガティブ思考の悪循環に陥ってしまう期間もありました。

子供が寝る30分とか、寝付いたあととか、ちょっとした空き時間は毎日できます。

勉強しなきゃ... コード書かなきゃ...
でも自分も疲れてて寝てしまう... ああ、明日こそ...

後述しますが結論、半年休んだ程度でエンジニアとしてのウデはどうこうならないので、まったく心配する必要はなかったです。 そんなことで頭と心を悩ますぐらいならいっそきっぱり忘れて、息子と笑顔で過ごすことのほうがよっぽど大切で有意義だったと思います。

保活が辛い辛い&辛い

保活の辛さと、それをどう乗り切ったかは以前ブログに書きました。

martin-lover-se.hatenablog.com

東京の保活はとにかくヤバイです。語彙が貧困で申し訳ないのですが、本当にヤバイです。

世のパパたち、絶対にママひとりに保活を任せてはいけません。
世のパパたち、絶対にママひとりに保活を任せてはいけません!!!

復帰したあと

結果的に、育休前に所属していたチームに戻れることになって最高でした。

PCのセットアップやら、慣らし保育のための早退やらで1週間位はあたふたしましたが、まあ自分で言うのもアレですが半年間働いてなかったんだっけ?というくらいスムーズに職場復帰できたと思っています。 自分の中でも、すごく自然に「働いている自分」に戻る事ができました。

これはやはり会社、そしてチームと上司の理解が大きいです。 安心して働ける環境だったからこそ、すぐに自分の最高のパフォーマンスを発揮できたと思います。

「技術の進歩は早い!学び続けないと!」はエンジニアにとってもちろん常にTrueです。 ですが、ぶっちゃけたった半年休んだ程度で追いつけなくなるほどではないと思います。 半年も働かなかったらコードの書き方とか綺麗サッパリ忘れちゃうんじゃないかな?とか心配していたのですが、全く、一ミリもそんなことはかったです。

何より、この経験を通じて会社とチームに対するエンゲージメントがMAXに高まりました。 復帰してから、以前にもまして会社のため・チームのために自分ができることを考え、自分で自分をモチベートして実践するようになりました。 会社から見ても、これは長期的な視点で費用対効果があるのではないでしょうか?

まとめ

共同参画によると、2017年ではパパ育休の取得率は5%ちょっと、2020年には13%を目指しているそうです。 Twitterなどを見ていても、冒頭紹介した記事のようにパパが育休を取得するケースは確実に増えてきているように感じます。

一方、半年以上育児休業を取得するケースはあまり見かけないし、ママが職場に復帰してパパと子供だけになるケースはもっと稀だろうと思い、経験を共有してみました。

再三ですが、私は半年以上休みましたが何の問題もなく復帰していますし、休む前と同様に、いや休む前以上に仕事を楽しんで、成果を出していると思っています。

こういう事例もあるんだよ、ということが少しでも伝わり、男性の育休取得の後押しになれば。

女性が活躍する社会が叫ばれて久しい昨今、保育園の拡充や、職場復帰しやすい、子育てしながらでも働きやすい社会制度はもちろん重要です。
同様に、パパの育児へのコミットと、それに対する社会の理解も重要なファクターではないでしょうか。

その意味では、僕が働いているサイバーエージェントは最高に働きやすい会社ですが、 世の中ももっともっと多様性に寛容になって、子育て世代が働きやすくなるといいな、そんな未来の実現に少しでもこの記事が役に立つといいなと思います。

追記 2019.6.10 「育児休暇」ではなく「育児休業」とご指摘をいただき、文中の該当箇所を修正しました。

デベロッパーとして生きていく ー 認定スクラムデベロッパー になりました!

先日、 David Bernstein 氏の 認定スクラムデベロッパー研修に参加し、Certified Scrum Developer(CSD)を取得しました。

www.jp.agilergo.com

5日間に渡る研修で、たくさんのことを学びました!

TL;DR

f:id:martin_lover_se:20190530230034p:plain

これでした!

今まで学んできたことが1つのストーリーのもとつながり、明確な目的を得ることができました。 何より、デベロッパーとして生きていく自信と勇気を、その方法と一緒にもらったように感じています!

お急ぎでない方向け:詳細

Agile, Scrum, XP

価値、原則、プラクティスのフラクタル構造

XPにおいて、価値、原則、プラクティスは以下のように説明されます。

価値(values):達人が良し悪しを判断する高度な感覚。ある状況における好き嫌いの根源にあるもの
ラクティス(practice):疑う余地のない、簡単に実施できる「良い行動」
原則(principle):価値とプラクティスのギャップを埋める架け橋
価値とプラクティスの間には、大きな隔たりがある。価値は普遍的である。... 一方、プラクティスは状況によって大きく異なる。
-- Extreme Programming Explained 2nd Edition

目的なくプラクティスだけ実践していると、すぐにあらぬ方向に行ってしまう。 でも、価値は抽象的すぎて理解が難しい...と感じていました。

これを、中間に適度な抽象度の「原則」のレイヤーを置くことで

  • 抽象度が高い価値から、解像度を上げる形でプラクティスに向かう
    • 原則が虫眼鏡のように働く
  • ラクティスから価値を考えるとき、価値に狙いを定めやすくなる
    • 原則がボウリングのスパットのように働く

... このように、双方からより深く理解できるように感じています。

研修で教わったことも、このレイヤーに適応してまとめると自分的にしっくり来たので、冒頭の図が誕生しました。

ラクティスの中でも抽象度のレイヤーがあって、フラクタルを形成している... ような気がしています。

価値:変化に対応する - Agile マインドセット

世の中は複雑(Complex)で、その世の中でソフトウェアで価値を提供し続けるためには、 実験と探索的な活動ーつまり「変化し続けること」ーが必要である... というアイディアがいま自分の根底にあります。

これは Scrum Guide にある経験主義の説明とも合致すると考えています。

経験的プロセス制御の理論(経験主義)を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。
-- Scrum Guide

Agile Manifesto にも、「計画に従うことよりも変化への対応を」とあります。 もちろん他の価値と補完し合いながら、複雑な世の中でソフトウェアが価値を提供し続けるために必要なマインドセットを教わったと考えています。

余談ですが、ボブおじさんも Clean Architecture でソフトウェアの価値について以下のように書いていました。

すべてのソフトウェアシステムは、ステークホルダーに2つの異なる価値を提供する。それは「振る舞い」と「構造」だ。
ソフトウェアはソフトでなければいけない。つまり、簡単に変更できるようになっておくべきだ。
-- Clean Architecture

違うところで同じことを言っている物を見つけると、より真実に近づいているように感じて嬉しくなります。 (彼も Agile Manifesto にサインした1人なので、当然といえば当然なのかもしれません。)

Scrum と XP

懇親会の場で、 David にこんな質問を投げかけてみました。

スクラム開発者に最も大切なスキルはなんですか?」

間髪入れず、 David はこう教えてくれました。

「XPだよ。」

これは自分にとっては目からウロコでした。

研修中、 David はよく言われる Build(do) the Right Thing と Build(do) the Thing Right を用いて、XPとScrumを以下のように説明してくれました。

  • (探索的に) 適切なものを構築する ... Scrum
  • (探索的に進めるための) 適切なやり方で構築する ... XP

たしかにいままでプロジェクト的アプローチで、数ヶ月に1度結合して結合試験してリリース...のようなやり方で開発していたチームに、いきなり「今日からスクラムやります!スプリント期間は2週間です!スプリント期間ごとにインクリメントを作ってください!」と武器をなにも与えずに初めても、「じゃあ設計スプリントやろう!」「結合試験スプリントをやってリリースだ!」... みたいになってしまうと思います。私はそんな経験があります...。

これを補完するため、スクラム開発者にはインクリメンタルにソフトウェアを設計・実装するスキルが必要で、その役割を担うのがXPである、と理解しています。

ラクティス:XPプラクィスと設計

TDDやデザインパターンを始め、多くの開発プラクティスを座学と実践によって学びました。

その多くは、今日では広く知られているものだと思います。 自分にとっても知っている/習得していると思っていた(と誤解していた)ものも多かったのですが、各プラクティスに対する解像度を高めることができました。 そして何より、全てのプラクティスをこの研修で定義された「価値」に関連付けられたことが大きな学びでした。

また、5日間の 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 は2つの点で価値を提供していると教わりました。

  • 動いていること、 Behavior を保証する
  • 変更が容易なソフトウェアをインクリメンタルに、創発的につくる

結局、ユニットテストを書くことを目的にするのではなく、価値を提供するために必要なことに集中しよう、という点で、同じものを違う側面から見ている...のではないかな? と考えています。

ペア/バディ/モブプログラミング

DevOps Days Tokyo の基調講演でもこの話をしていたと記憶しているのですが、 David に教わった大好きなメタファを紹介します。

マネジャー:「ペアプロ?やめたまえ。」「私のチームのリソースを半分にすることはできない。」
David: 「まず第一に、僕たちはリソースじゃない。」「一人では運べない荷物でも、2人なら運べる。ペアプロは、そういうことをやってるんだ。」

幸運にも、最近自分のまわりでは David の例のようなマネジャーとは遭遇していないのですが、 過去 SIer で働いてた頃は自分で「ペアプロやるとリソース半分になるよなぁ...」とか考えていました。 そんな体験から、このメタファはとても心に刺さりました。

私のチームでは、チームのデフォルトの働き方としてモブプロを採用しています。

martin-lover-se.hatenablog.com

その経験からも、「2人なら重い荷物を運べる」というメタファはとても納得感のあるものでした。

設計 - OOP, Design Pattern

オブジェクト指向完全に理解した、と多分人生5回めくらいに思いました。 そろそろ入り口くらいにはいるでしょうか...。

オブジェクト指向デザインパターンについて新たな気付きや学びが非常に多くあったのですがとても書ききれません。 特に印象的だったのはこれです。

デザインパターン意図UMLにも、ソースコードにすら現れない。」

研修の後、勧められた「オブジェクト指向のこころ」を読んで、研修で時間が足りなくて理解が浅かったパターンについても補完できました。 著者の Al Shalloway 氏は David 氏の師匠だそうで、この本の内容は研修にも色濃く反映されており、復習&より理解を進めるのにぴったりでした。

その他感想とか

達人のメタファ

達人はメタファがすごいです。 聞く人を納得させ、かつ解像度を一段高めるような... そして何より、心に響き、心を動かします。

研修のフィードバックを何度か社内でやって、David と同じメタファを説明してみたんですが、全く響きませんでした。 達人は秀逸なメタファを作れることもそうですが、それを納得させるだけの含蓄ある言い回しやそれを支えるバックグラウンドがあってこそなんだな、と気付きました。

デベロッパーとして生きていく勇気

かれこれ10年以上ソフトウェア開発に携わってきたなかで、プロマネ、エンジニアリングマネジャー、プロダクトオーナー... など、コードを書くこと以外でも様々なロールにチャレンジさせてもらってきたのですが、自分が一番得意なことはやっぱりコードを書くことだと感じています。

かたや年をとって、自分が超絶強いプログラマでも、その器でもないというのも痛感しています。 最も得意なところをせいぜい人より2〜3倍の速さで終わらせるのが関の山かな、という感覚で、コードを書くことだけにフォーカスしているとこれ以上はスケールしません。

ここにずっと後ろめたさというか、デベロッパーとして生きていく踏ん切りのつかなさを感じていました。

今回の研修を終え、自分はもっとデベロッパとして成長できる、という自信とともに、

今回得たような知識を伝えていくことで、自分が書いたコード以上の価値を生み出せるのでは?
チームや会社がうまくいくなら直接自分の手を通してでなくても構わなくて、これも一つのスケールの形なのではないかな?

と考えるようになりました。 同時に、それを実現するために必要なスキルや学ぶべきことも教わりました。

コードを書く時間や量の多寡は状況によって変わると思うのですが、自分はデベロッパーに軸足をおいてやっていくんだ!という勇気をもらったように感じています!

まとめ

今回の研修での最大の収穫は、今まで学んできたことが1つのストーリーのもとつながったことでした。 プラクティスを実践するとき、目的を持って正しい方向へ進んでいるという自信が持て、 また新しいことを学ぶ際にも今何故これを学ぶのか?を価値と原則に照らして判断できるようになり、更に学びの意欲が高まりました!

こうして振り返ってみても、いろいろな角度で自分のソフトウェアエンジニアとしてのキャリアや考え方に大きな影響を与えた研修でした。

当たり前ですが、資格自体には何の価値もありません。 Cope も「認定資格を取ったからといって明日からスクラムマスターになれるわけではない」と言っていたし、今回の研修でも、スクラムデベロッパーとなり、学び続けことを自分で認定しました。 研修で学んだことを咀嚼し、実践し、また学び続けるデベロッパーでありたいと思います!

5日間という長期研修であるためかなり高額なのですが、それを遥かに上回る見返りがありました。 David氏はまた日本でCSD研修をやりたいという旨おっしゃっていたので、また日本で開催されることを期待しています。 ソフトウェアエンジニアリングに軸足をおいてキャリアを積もうと考えている方に、投資先としてもおすすめできます!!

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

この記事は モブプログラミング Advent Calendar 2018 の22日目の記事です。

前日の投稿は huideyeren さんの 「軽い気持ちでモブプログラミングを行ったら失敗した話」、 次の日は nihonbuson さんの「モブプログラミングをやっている人(及部さん)にレビューを語ってもらった話 #JaSSTReview」です。

モブプロはもはや説明の必要もないほど浸透していると思っていますが、敬愛の意も込めて大好きな動画を張っておきます。

動機

私とモブプログラミングとの出会いは2017年ごろ、どういう話の経緯だったか忘れてしまいましたが、 私の Agile 師匠の一人に教えていただいたのが最初だったと記憶しています。

Mob Programming – A Whole Team Approach by Woody Zuill

これを読んで、これは面白そうだということで、はじめは開発合宿のような特別なイベントを企画してチームで試してみました。

その後育児休暇で半年ほど休んだ り、後述しますがこの論文を書いた Woody 氏との出会いがあったりと本当にいろいろあったのですが、 最近ではチームのほとんどの開発作業をモブプロで行っていて、「みんなでやる」のが自然な姿になっています。

チームにこの働き方が根付くまで、いろいろな試行錯誤や紆余曲折があったのですが、モブプロが好き、と言う気持ちがその行動を促していたことは疑いようがありません。

というわけで、自分で率先してモブプロを導入することに労力を割いてもいいと思える程度にはモブプロが好きなのですが、 自分にとって今年の最大の変化とも言えるモブプロと言う働き方が自分にとって何なのか、という振り返りと、 「好きだ」という曖昧な感情だけで働き方を決めるのもどうかなぁと思うところもあり、 思考の言語化ということでその気持ちの構成要素を分解、整理してみたいと思い至った次第です。

要素と言語化

マインドマップで頭の中を整理してみたところ、大きく4つの象限がありました。

  • 楽しさ
  • 合理性
  • 学び
  • 人の縁

順に言語化してみます。

楽しさ

モブプロがなぜ好きか、その要素を考えたとき、まっ先に頭に浮かぶ言葉が「楽しいから」でした。 楽しいことはもちろん好きです。

せっかく仕事をするなら楽しくありたいし、楽しく働く権利があると思っています。 こう思える様になったのは割と年をとってからですが、今では「楽しい」ことがチームの価値の1つであっても良いなと考えています。

プログラミングの楽しさの再発見

私は社会に出てからプログラミングを学びました。 それから10年以上が過ぎた今でもプログラミングがとても好きなのですが、モブプロをしていると、 初めて自分で書いたコードが動いたときの喜びを追体験するするような、そんな嬉しさを感じます。

これは、後述のチームとしての一体感や達成感と関連していると考えています。

一体感と達成感の共有 - "Ba"

チーム開発は楽しいです。モブプロをやっていると、チームで仕事をしている、ということをとても実感できます。

はじめは「1つのワークアイテムを終わらせたら、みんなでバンザイする」のように意図的に大げさに祝福するスキームを共有して、 楽しさや一体感を演出していました。 実際これはとてもワークして、「モブプロは楽しい」という原体験がチームに定着したと考えています。

前述の通り最近私のチームではモブプロは特別なことではなくなっていて、普通にオフィスフロアやオープンなミーティングスペースで実施しているので、 あまり大げさな祝福イベントはやってないのですが、それでもコンパイルが通ったとき、UTが通ったとき、 結合試験で思い通りの結果が出たときには自然にメンバーに笑顔がこぼれます。

最近、 Jim Coplien 氏の CSM研修を受けました。 研修の中で、課題ワークなどでチームに一体感が生まれたように感じた瞬間、彼が

「Guys, "Ba(場)"」

といってくれて、それがすごく嬉しかったのをよく覚えています。 そのときの感覚、"場" がモブプロによって自然に育まれているように感じます。

個人の精神的負荷の低減

また逆に、「辛いこと」もモブプロならチームと分かち合うことができます。

私のチームは歴史もそれなりにあり、いわゆる「技術的負債」というやつにぶつかることもそれなりの頻度であります。 例えばあまりうまくないコードに出会って、そこを直さなければならないときや、コードから仕様や実装者の意図がまるでわからないとき、 老朽化したインフラで単調な作業をやらなければならないとき... など。

その不透明さ、不確実性に起因する恐怖や不安といった負荷も含めて、個人で負担する「辛さ」がうまく分かち合えていることも、「楽しさ」につながっています。

合理性

大学で物理を専攻したせいもあってか、合理的なものが好きです。

モブプロが合理的なものを目指して生まれたのではなく、自然とその働き方が発生した、というのをどこかの記事で読んだように記憶しているのですが(ソース忘れました、、)、 その生い立ちが逆に真理に近づいているような気がして、また魅力を感じてしまいます。

Efficiency/効率

モブプログラミングは効率が良いのか?という話題はしばしば耳にします。 過去に自分も同じような考察を書いてしまったのですが、今はその手の質問は的外れである場合が多いと考えています。

まず、概ねベロシティやスループットの多寡だけが問題にされている場合、つまり暗黙的にリソース効率を比較しているケースが挙げられます。 リソース効率を意図的に最大化したい場合(Waterfallの大規模開発とか?)であれば、モブプロを選ぶべきではない、という意味で問題ありませんが。

モブプロでは複数名が同時に同じ作業項目に取り掛かるため、自然とチームのWIP(work in progress)が小さい方に制限されます。 これは自然とフロー効率を高める方向に働きますし、さらに依存と待ち時間、マルチタスクのスイッチングコストを最小化することでフロー効率が最大化される... というのはこの資料にもある通りです。

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

Effectiveness/効果

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

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

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

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

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

学び

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

伝える側としての学び

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

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

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

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

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

チームとしての学び

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

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

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

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

人の縁

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

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

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

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

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

まとめ

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

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

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

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

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

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

TL;DR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

背景

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

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

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

認証保育園

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

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

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

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

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

認可保育園

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

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

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

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

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

作り方

1. データ収集

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

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

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

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

PDF to EXCEL

2. データ整形

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

生データ

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

集計済みデータ

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

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

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

3. 可視化1:ダッシュボード

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

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

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

3.1 データソースをコピー

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

H31 調布市 生データ

H31 調布市 集計済みデータ

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

f:id:martin_lover_se:20181209100615p:plain 1. コピーボタン > 「データソースのコピー」を選択

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

f:id:martin_lover_se:20181209171943p:plain 3. 先ほど作成したスプレッドシートを選択

f:id:martin_lover_se:20181209172216p:plain 4. わかりやすい名前に変更

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

3.2 レポートをコピー

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

f:id:martin_lover_se:20181209172250p:plain この画面で、先ほど作成した2つのスプレッドシートを選択してください。

f:id:martin_lover_se:20181209172307p:plain これで、作成したデータで冒頭と同じ形式のレポートが作成できます!

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

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

4. 可視化2:地図プロット

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

4.1 地図用データ を作る

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

地図用データ

ID 略称 保育所 所在地 定員 1歳-募集 1歳-申込 倍率
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と申込み状況書類とで保育園の記載順や呼称が異なる!なんてことも往々にしてあります。 1自治体なら数も多くないですし、手間ですが目視で確認しながらがんばります。 IT化...

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

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

Google マイマップ にアクセス

f:id:martin_lover_se:20181209172754p:plain

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

Googleマップハンバーガーアイコン(メニュー) > マイプレイス > マイマップ

からも呼び出せます。

f:id:martin_lover_se:20181209172827p:plain

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

f:id:martin_lover_se:20181209172848p:plain

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

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

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

f:id:martin_lover_se:20181209173234g:plain

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

f:id:martin_lover_se:20181209174022p:plain

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

まとめ

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

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

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

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

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