株式会社はてなに入社しました
久々の更新です。今は株式会社プレイドで労働しています。
前回のMeetupから早3ヶ月、ついに第2回目が開催されましたので毎度勝手ながらのレポ。概要などは前回記事を参照ください。
前回 → 育児タスクのカンバン管理 離乳食編 // Speaker Deck
在宅制度、弊社でも制度としてあって子持ちの人にも便利なのですが、本当に育児に有用な手立てなのか?というのを改めて見直すきっかけをくれたような気がしました。
「家に入ればどうにかなる」という曖昧な判断だと危なく、ちゃんと育休を取る・仕事部屋との隔離・作業時間(コアタイム)をしっかり確保する、という計画建てが大事そうです。一度だけ在宅時に娘と二人っきりになる日があって、自分自身も「なんとかなるやろ」の精神でいたのですがなんともなりませんでした(娘大号泣で仕事どころじゃなかった)。
Googleカレンダーでの仕事のものとプライベートのものを連携というのはなるほどでした。会社でのおおよそのスケジューリングを可視化しておくとパートナーにもその様子が分かる・それぞれの予定のバッティングを回避するように考えるきっかけになりそうだと思いました。
あと育児と同じく家族看護も同様に危険性があるので、在宅作業ではなく休むときはしっかり休むようにしないととも感じました。
前回 → 自作育児サポートアプリのその後 // Speaker Deck
エンジニア=非同期処理。自動化というイメージのもと、自動化できるものがあればそれに頼っていきましょう、楽していきましょうという紹介。
家電系は前回のMeetupで紹介されていたので割愛ですが、アプリ関連でも色々とあるのだなぁと思いました。写真関連は特に、スマートフォンなどをもっていない親世代でも共有できるものを使っていくのは良さそうだなと思いました。あとAmazon Prime Photosは完全に知りませんでした…あとで見る案件です。
ランドロイド、間違いなく値下げ化を望んでいる人は子持ち家庭以外でもいるだろうなと思いました。高すぎる(当たり前ですが)。
以下Cloud FunctionsをWebhookに指定
'use strict'; var request = require('request'); var config = require('config'); var iftttKey = config.IFTTT.key; var requestToken = config.IFTTT.request_token; exports.callIFTTTWebhook = (req, res) => { if(req.body.secret != requestToken) return; var triggers = req.body.triggers; for( var i in triggers ) { var url = 'https://maker.ifttt.com/trigger/' + triggers[i] + '/with/key/' + iftttKey; var options = { url: url, method: 'POST', headers: { 'Content-Type' : 'application/json' } }; request(options, callback); } function callback(error, response, body) { if (error == true) { console.log(body); } } // send status res.status(200).send('ok'); };
個人的には映像コンテンツノンストップという仕組みをとっているというのが驚きでした…自分の娘もYoutubeに齧りつきになっている事が多く、それだったら浴室にはタブレットを、寝室にはプロジェクターを…という徹底ぶりに恐れ入りました(自分は怖くてできない…)。
エルサゲートも問題視されているので、親と一緒にコンテンツを吟味して見るべきものを考えるきっかけにはなれるのかなぁとも思いました。Super Simple Songsのような楽しみながら学べるコンテンツもあることなので、探してみてそれを子育てエンジニア間でも共有できればいいのかとも感じました。
それとSNSで実名が飛び交うこの昨今、娘さんにソーシャルネーム(?!)をつけてSNSに投稿できるようにしたというのは面白かったです。ウチもなんか付けるか。
前回 → 家庭をプロジェクトとして運営した話 // Speaker Deck
個人的ガチ勢のお方。今回は家事のステータスの可視化・動線の改善についてをどう考えるかがテーマでした。
家事のステータスというと夫婦間でDoneなのかDoingなのかが変わってくるかもしれません。共通認識とするのと、いまどこまで進んでいるのかを可視化できるようにすれば各自でのストレスは軽減(=コントロール)できるのではないか?とのことでした。逐一自分たちの頭で考えなければならないのも形にすればいいよなーと感じます。
動線を変える点でも、ただやみくもに新しいものを導入するのではなく、まずは既存のものを使ってみて、そこからどう形にするかを考えるというのも課題解決の。あとはここの部分の仕様を厳密にとらえず、「ひとまずこういう形はどうか」と7割程度のものでレビュー段階にもっていく、家庭でのプルリクエストを実行してみてはどうかとのことでした。
3Dプリンタ、家庭で導入されているものだと遊び用に使われている感じの印象でしたが、家事を助けるための小物づくりとしても有用だということに気付かされました。ただ導入するには、値段的な部分で、検討が必要な場合がありそうなので、まずは3Dプリンタのある店で出力してもらってモノにしてみるのも手のようです。
リクルートマーケティングパートナーズの保育園と保護者をつなぐサービス「kidsly」の中の人による保活問題への取り組み事例と現状どういう実情があるかの発表でした。
保活は子どもをこれから産むお母さんにとてつもないストレスがかかっている。何故かというと、保育園自体の数が少ないことや入るに辺りどこまで点数を満たしているかの検討、見学に行ったり区役所・市役所に行ったり、厳しかった場合お金をかけてまで認可外にするのか、育休が終わるまでになんとかなるのか…と複合的な要因でこれからの出産に大変な不可になることが多い。
ちなみに都内で現在待機児童が多いのは目黒区。
保活を行うにあたり、点数計算はもとより、どこにどういう保育園があるのか・人数はどれくらいまでか・認可か認可外か、という一括で管理しているマスタというものは現状ない(近いものはあるがあくまでも人力)。あとは各自治体での信用できる情報もCSVやPDFデータなど編集しづらい日本らしいデータでしか設置していない問題もある。
また、ママ友などでのコミュニティ形成はあるにしても保育園との連絡や情報の共有は電話などのすぐ確認できるかわからないものだったり、そうした部分も地味にストレスになりうる。
kidslyがそうした問題を解消するために、以下のアプローチを掲げている。
保護者間でのコミュニケーションを充実させたり、園からの情報を共有しやすくしたり、何よりアナログでやっていたやり取りをデジタルに落とし込むといった方法をとろうとしている。
保活問題へのこうしたアプローチがリクルートじゃないとできないと思うのは、収益化の問題に対応できる(潤沢なリソース)、ママユーザー基盤が充実しているから。この部分は、大きな社会問題として切り込むためにも、たしかにそうだとしか言えません。
kidslyの導入園は今年3月の時点で1000に達成したとのことで、この輪がどんどん大きなものに変わっていけばいいなと思います。
夫婦揃って最近noteの記事でバズりを見せていた旦那のshikicheeさんによる発表。夫婦で共働きの際に問題となる「収入の管理」と「家事のステータス」のそれぞれを認定スクラムマスターがスクラムで解決。
スクラムの3つの重要要素は以下とおり。これらをルーティンさせていく。
お金の管理や家事のステータス化ではお互いの状態があまり透明化されていないのがストレスとなることがある。そのためにもまずどういうことになっているのか、共通にすべきものはなにかを考えてみる。
お金であれば家庭内で使うものは共有口座で管理し、残りはお互いの口座で管理。家事であればどういう手順を組むのか、そして今どれだけやってるかどこまで終わったかをカンバンサービス(Trelloなど)で可視化していく。こうした目に見えるものにしていくことでストレスをなくし、お互いの幸福度につなげていく。
あとはこうした解決方法でいく!としてもパートナーがそれに乗り気になるか、そもそも興味をしめしてくれるかというのもある。そうした場合ひとまず1人で進め、相手が触れやすい状態にしていく、今後もやってくれるよう声がけをするなど、ただやるだけではなく巻き込んでやることを意識した取り組みが必要になる。
いずれにせよこうした解決をするためには、まず夫婦間での意識の共通化と、お互いを理解しておくということが大切とのことでした。
便利な家電を買う場合の以下式は非常に参考になるなと思いました(購入金額より勝るならGOサイン)。
購入金額 < 耐用年数 * 1年の使用回数 * 1回の削減時間 * 自分の時給
今回も実りある内容ばかりでした。前回はアプリエンジニアの視点でのフォローという印象があったのですが、今回はエンジニア思考の視点においてどう家庭補佐するか、という感じだったので「何かモノをつくる」ということだけに徹しなくても、また別のエンジニアリング手法(スクラムなど)でフォローは出来るのだなと感じました。
更に根強い保活問題にも切り込んだ発表もあったので、ここから解決の方向へ広がる共有があれば、技術的解決をもって大きな課題に一矢報いることはできるのではないのかなぁと更なる可能性も感じました。
このブログをまとめる間に思っていたこととして、OSSプロジェクトみたいなのを設立して、子育てプロダクトをみんなで育てていく、という動きもあればいいのかなぁと思います。やっぱり都内での開催になるので、少しでも場所を問わずに多くの方が参入できるものを徐々に広げていくと、もしかしたら国内のみならず諸外国での「子育てエンジニア」の知見もあるまるのではなかろうか…と軽く妄想です。
次回はそろそろ登壇側として何か提供できるものがないかなぁなどと考えたりしています(できるとは言ってない)。些細な内容でも、受けた影響により動いてみた内容など、他の人の背中を押すきっかけになればいいのかなぁと。
こちらからは以上になります。
興味が有る方は以下よりJoinをばどうぞ。
子育てエンジニアSlack Join
子育てエンジニアScrapbox Join
https://scrapbox.io/projects/childcare-engineer/invitations/f61f79a4c64999afc3deb04887af0530
connpass.com 10/25(水)に、さくらインターネットが主催の「さくらの夕べ」にてVue.jsの業務内活用についての発表がありましたのでそれの個人的まとめです。こういう話聞くと久々にやるかみたいなモチベになります。(はやくやれ)
さくらクラウドの料金シミュレーションをVue.jsで作った https://cloud.sakura.ad.jp/payment/simulation/
もとはAngular1系。UIはそのままで一部のみ変更。URLでの記憶機能や時間割計算も対応できるようにした。
メンテコストがキツイ。フロントと何故かバックエンドのダブルメンテ。
コンポーネントの構成を決める際に、テストしづらい、使いまわせない、分割できないといったものにならないように気をつける ItemContainerという親を作るとItemGroupの場合はどっちが親?となる
<ItemGroup> <ItemContainer> <= こういった構成なら分からなくもないが単体だと分からない <Item /> <Item /> </ItemContainer> </ItemGroup>
Catrgory、ItemListなどの的確な名前づけをした。親子関係と役割を想起しやすいようにしよう
<Category> <ItemList> <Item /> <Item /> </ItemList> </Category>
<components>
<layouts>
buttons ├─ AddFieldButton.vuw ├─ RemoveFieldButton.vue └─ SaveButton.vue
bill ├─ bill.vue └─ bill.scss
<pages>
Store構成 => コンポーネント内部だけで知っておくべきこと(タブの開閉)、全体として知っておきたいもの(合計金額)を洗い出していく。
アプリケーションが大きくなると見通しが悪いが、Vuexのmoduleで見通しをよくするようにしておく。
const moduleA = { state: { ... }, mutations: { ... }, actions: { ... }, getters: { ... } } const moduleB = { state: { ... }, mutations: { ... }, actions: { ... } } const store = new Vuex.Store({ modules: { a: moduleA, b: moduleB } }) store.state.a // -> `moduleA` のステート store.state.b // -> `moduleB` のステート
さくらインターネット上にはさまざまなwebサービスがあるが、実はフレームワークが乱立している問題があった(好きにやっていい裁量がある)
そんな中、社内SlackにVue.jsを推す影響力のある人がおり、反応してみた。 実はウェブアクセラレータや幾つかの過去のプロダクトにはVue.jsが使用されていた模様。
何とかして良さそうなVue.jsを普及してみたい。が、実績についてはあまり無かった(ウェブアクセラレータくらい)。 そのため、社内での利用事例を増やすために小さいプロダクトからVue.jsを導入してみることにした。
さくらインターネット20周年に際して、TOPページのリニューアル案件が立つ。そこで一部にVue.jsを導入してみることにした。
色々ある #さくらの夕べ pic.twitter.com/7XUOfeiJ2l
— 28歳 (@yamanoku) 2017年10月25日
ダーシノさん https://twitter.com/bc_rikko
www.slideshare.net
静的型付ができることで最近話題になっている(ことにしてほしい)TypeScript。 Vue.jsでもせっかくなので使ってみたいと思ったけどVue2.4以前ではかなりつらいことが多かったのだが、Vue 2.5からTypeScript統合の改善がされ、だいぶ楽になったよという話。
今回はサーバーサイドエンジニアもメンテナンスができるように、ということで型定義がおそらく好まれているだろうことを推測し、TypeScriptを全面導入。
this
や props
の型推論ができて、class構文ベースの記述が以前は必要だったがそれがいらなくなるなど改善された箇所が多く、つらくなくなった。
jp.vuejs.org
便利なVue.js + TypeScript体験一式も配布。ありがたい。 github.com
Nuxt.js とはユニバーサルな Vue.js アプリケーションを構築するためのフレームワークです。
を他にも検討しているが、Vue記法をつかいたいため、Nuxt.jsを推したい。
"scripts": { "dev": "nuxt", "build": "nuxt build", "start": "nuxt start", "generate": "nuxt generate" }
SPAにする場合は --spa
オプションを付与。