Enjoyした2ヶ月間の育休から復職する
Enjoyすること
8月、9月と取得していた育休からきょうで復職する。家族のためにフルコミットできた、とても充実した2ヶ月間だった。
これから色々書き並べるけどEnjoyすること、楽しむということを一番大事なこととして記しておきたいと思う。
もし時間があれば、アン・ハサウェイの国際女性デーの基調演説はぜひ見てもらいたい。男性の育休取得の社会的意義について考えさせられるのではないかと思う。
彼女は産後2週間歩くこともままならなかったらしい。この動画を見て、妻をしっかり支援しなければという思いを強くした。
動画ではアメリカの育児休暇制度について述べられているが、比較すると給付金も出る日本は保障が厚いように感じた。
中小企業7割が育休義務化に反対というニュースがあったが、当たり前のように育休を取る雰囲気づくり、職場のカルチャーが占める部分は大きいのではないかと感じる。
アン・ハサウェイは育休はただの休みではなく、役割の決定、時間の投資の選択、そしてポジティブなサイクルを作り出すことだと述べている。
"Paid parental leave isn't about taking days off work. It's about creating the freedom to define roles, to choose how to invest time, and to establish new positive cycles of behavior"
そして、ポジティブなサイクルを生み出していくためにはEnjoyすること/楽しむことが大事なのではないかと2ヶ月間の育休をとってみた強く感じた。
世の中には色々と育休の情報が溢れているが、とかく大変なことを強調されることが多かったように感じる。
そんなこともあり、育休取得前に色々と不安だったので1on1で世間話としてお子さんのいる人にアドバイスを色々もらっていたんだけど、そのうちの一人に夜泣きとか大変だったりするかもしれないけど、とにかくEnjoyすることだよ(英語の会話だったので意訳)と教えてもらった。
沐浴はどうしようとか、睡眠時間は取れるのかとかいらぬ心配をしてしまっていたんだけど、コンセプトとして育休をEnjoyすることに決めたら気持ちがだいぶ楽になった。
2ヶ月間あまり眠れないときがあっても、自分は一生のうちでほとんど過ごすことのできない貴重な時間を過ごしているんだと思うことができて笑顔で過ごすことができた。
このアドバイスをくれたことに本当に感謝している。
ここまでで伝えたいことの95%は伝え終わった。このあと育休取得やその準備について書いているけど、だいたい何とかなる。育休を楽しむということが最高のソリューションだと感じている。備えあれば憂いないしくらいで読んでもらえると嬉しい。
育休を取得するまで
"男性の育休取得率80%"という会社に所属していて、育休を取得するのはもはや「当たり前」の環境にいたので取得することにそこまで迷いはなかった。
もっと言うとこの記事を読んだときに「100%じゃないんだ」と感じてしまうほど周囲の人たちは育休を取得している。これは経営陣がしっかりと育休を取得している影響がとても強いと思う。
そのような環境なので自分自身も、一従業員として、(Managerなので)Managerとして、取得しない理由はないと感じた。
一方で、すべての会社がこうではなく、世間一般的な男性の育休取得の難しさも感じている。自分自身も以前正社員数が25人未満、業務がシフト制の会社に所属していたことがあったが、そこで育休を取得する男性はいなかったと思う。
当時は若かったこともありあまり疑問には感じていなかったが、その会社では「難しい」「仕事はどうなるんだ」という雰囲気が漂っていたように感じていて、無言の圧力もあったのではないかと感じる。
育休への準備
3ヶ月前から上長や関わるメンバーに頭出しを始めた。Managerを務めているので自分が不在のときの代理(1on1や評価など)、報告フローなどを早い段階で調整し始めた。
いろいろな人と話している過程で「1ヶ月にしようか」と考えたが、COVID-19の影響もあり親の支援を望めなかったので特に育児が大変だと言われる2ヶ月はフルコミットすることを決めた。
育児休業給付金の盲点
育休を取得すると国から"育児休業給付金"がもらえるらしく、育休中の2ヶ月間はこれを使って生活しようと思っていたのだけど、これは2ヶ月後から支給されるものらしく最低2ヶ月分の蓄えは必要ということになる(育休終わるけどまだ支給されていない)。
貯金が全然ない、とかだと困ったことになるので蓄えておく必要あり。
育休中
自分の場合はみんなに伝えていた予定日よりも一週間早く生まれたので、それに合わせて休みを早めた(実際の育休期間は変更せず期限切れになってしまう有休を活用、もちろん引き継ぎも休みに入る前に終わらせた)。
そんな感じで休みに入ったのだけど、最初の3日くらいを過ごしたあたりで自分が育児をなめていたことに気がついた。
大変だったこと
「1時間ごとにミルク/授乳をしないといけない」というのを本で読んではいたんだけど、1時間ごとなら結構休めそう、くらいにしか思っていなかった。
が、実際には赤ちゃんが飲み終えるのに20分、その後おむつの交換などで20分、服が汚れたりしたら着替えさせたりしないといけない(+5分)など。これに加えて自分たちのことをしていると気がついたら次のミルク/授乳の時間になっている。
ちゃんと考えてみれば当たり前のことなんだけど、予想以上に一つ一つのことに時間がかかることがあとから分かった。
また生活リズムも最初の一ヶ月は2-3時間の仮眠を取りながら24時間を過ごしている感じで、眠れるタイミングで昼寝をする、という状態だった(これは事前に取得していた情報通りだった)。
夜中のミルク/授乳で起きたり、最初の一ヶ月は自分が3食用意していたんだけど、そういうことをしているととにかく立っている時間が長くそれだけで結構疲れる。
Apple Watchでスタンド時間を見てみると、この時期(8月)は立っている時間が多いことがわかる。
COVID-19の影響
出産前から影響がとても大きかったが、結論から言うとなんとかなった。
親が遠方に住んでおり5月-7月の雰囲気だと帰省するわけにもいかず来てもらうわけにもいかず、という状態で親の支援は受けることは早々に諦め割り切って自分たちで頑張ることにしていた。
また区役所等で通常受けられるはずの両親学級などが受けられなくなってしまい、本や動画などで予習をするしかなかったが、幸い今の時代はいろいろな方法が提供されているのでそれらを活用した。
育児グッズもお店に行って色々比較したかったけど、Amazonやたまひよでほとんどのものを購入し特に困ることはなかった。
振り返り
2ヶ月目に入ったあたりから子供にもリズムができてきたこともあって、後半は思っていた以上のことができた(リズムができるかは個人差あると思うけど)。
ミルク/授乳の間にKindleで本を読んでいたこともあって4-5冊本を読むことができたし、子供が昼寝したり寝静まってからSwiftUIで機能をいくつか作ってみたりとスキル向上の時間にすることができた。自分のキャリアについて、忙殺されがちな仕事から離れて達観することもできたし、そういう点でも良かった。
最初に書いたけど、やはりEnjoyすること、楽しむことが一番だと思っているので、十分に備えて、育児にフルコミットできるようにしていけると良いと思う。そして、男性の育休が当たり前になっていくと良いなと思う。
iOSDC Japan 2020に"初"参加した #iosdc #iwillblog
iOSDC Japanに"初"参加してきました！
2016年から4年間コアスタッフとして主催者側にいたのですが、初めて純粋に参加者として参加することができました。
過去2年のレポートブログはこちら。
motokiee-blog.hatenablog.com motokiee-blog.hatenablog.com
9月は育休取得中で家のことで色々と忙しくオープニングとエンディングをちょっと見れたくらいだったのですが、トークの資料やtwitterのTLを夜な夜な眺めながら雰囲気を感じ取っていました（いや、それってほとんど参加していないのでは...というのはごもっとも）。
今回は初めてのオンラインでの開催でこれまでとは異なったiOSDCとなりましたが、エンディングの盛り上がりを見ていてとても素晴らしいものだったんだな〜と感じました。
これまでスタッフをやったり海外カンファレンスなどにも参加してきて、オンラインで容易に情報が得られる時代だからこそオフラインで集まることにこそ意味がある、と考えていたのですが、それよりも場作りが重要なんだな〜と感じさせられました。
スタッフの方たちの創意工夫や頑張りが伝わってきました...!! ニコ動であとから見返せるので課金してぽつぽつ見ようと思います。
今年は最低限スポンサーとしては貢献(主に稟議)できたくらいなかな〜と思うので来年こそはCfP出して話せるといいな〜なんて思っています。
あと来年は...オフラインで参加できるといいな！
Engineering Managerは何人のメンバーを見るべきか？
最近 An Elegant Puzzle: Systems of Engineering Managementを読んでいたら “Sizing teams“ というチームサイズについて解説している節が面白く、自身の経験を振り返りながらこの「何人まで見れるのか」を考えてみた。
著者のWill LarsonさんはUberやStripeのGrowth期にEM(Engineering Manager)として在籍しており、スケーリング期の実体験を元にチームサイズについて論じている。
6-8人を見るべき、これより多くても少なくてもイマイチ
この本では “Managers should support six to eight engineers” と定義している。結論としてEMは6-8人のメンバーを持つべきだと。面白いのは少なすぎてもダメ出し、多すぎてもダメだという点。
もちろん色々なチームがあってチームによってEngineering Managerに求められる役割は異なってくると思う。この本では担当する人数ベースで例外を2つ示している。
- Tech Lead Manager: 4人未満
- Coach: 8-9人
TLM(Tech Lead Manager)は4人まで、Coach(People Management)に専念する場合は8-9人のメンバーをセーフティネットとしてマネジメントすることを推奨している。
ただしあくまで例外で、TLMはマネジメントとしての成長機会を与えることが難しくなりマネジメントのスキルアップを阻害することになる。Coach、つまり8-9人のメンバーを持つことも、より安定したチーム構成への移行期間の間であれば良いが、担当するEMが忙しくなりすぎてしまい望ましいことではないとしている。
これを見て個人的には目から鱗が落ちるようなことはなかった。ただ「そのとおりだよな」と。
最大で10人をEMとして見たことがあるが、10人を超えると1on1を隔週にせざるを得なくなったり、PJも複数となって関われる時間に偏りが出ていた。
おそらく、というよりは実際の経験に照らし合わせると、EMがこれくらいの人数を見ざるを得ないということはPJに対する人員配置に何かしらの課題があるはずだと思っている。均等に目を配らせると言うよりは緊急度の高いPJに多くの時間をケアするようになり、緊急度の低いPJに使う時間は相対的に低くなってしまう。そしてこれがEM本人が意図している/いないに関わらず不公平感を生んでしまう。
言い訳のように聞こえるかもしれないが、これは能力の問題ではなく構造的な問題だと思っている。1on1やコーチングなど、EMはメンバーとの継続的で一貫性のある関わり方が非常に重要だと感じており、そのために見る人数の抑制はSLO(Service Level Objective)的な意味合いで必要になると思っている。
自分も最初はスキルが上がったり工夫次第で人数が増えても対応できるようになっていくものだと思っていたけど、EMにとって何人のメンバーを持つかというのは思っていた以上に重要なファクターであると今は確信している。
コアスタッフが見たiOSDC Japan 2019 & コアスタッフの卒業 #iosdc #iwillblog
発表者の皆さま、参加者の皆さま、スポンサーの皆さま、そしてスタッフの皆さん、iOSDC Japan 2019お疲れさまでした！！
コアスタッフとして4回目のiOSDCでした。今年はトークもなく、純粋にスタッフとしてカンファレンスに関わっていました。
今年は、
- 撮影スポット制作担当
- Track E隊長(開催期間中)
の2つが担当でした。
タテ2m x ヨコ5m の撮影スポットを手動でダークモードに切り替えるという滑稽な演出、我ながらやってよかったと思いましたw
あらゆる面（お金、人）でコストが2倍にかかるのですが、こういうところにエネルギーを使うのがiOSDCらしくて良いな〜としみじみ感じました。
今年は初めて参加者が1,000人を超えるなど、本当に大きなカンファレンスになったんだな〜、と感慨深い年となりました（人数とか関係なく毎年感慨深さを感じてはいるのですが）。
スタッフとして最後のiOSDC
さて、完全に個人的なことなんですが、初開催の2016年から4年にわたって続けていたiOSDCのスタッフを今回で卒業することにしました。
去年くらいからEM(Engineering Manager)になりコードをあまり書かなくなったとか、引きづられてスタッフ業に時間をかけられなくなったとか、丸4年で一区切りとか、理由は色々あるのですが、一番大きいのは技術カンファレンスのスタッフをやっているのに自分がコードをほとんど書けていないことです。
なので、スタッフを卒業したら趣味プロジェクトや自分のプロダクトづくりをしていこうと思っています。iOSDCが終わってからは暇を見つけては数年前の趣味プロジェクトを開き、少しずつエラーを修正するリハビリをしていますw
一番最初のiOSDCの年、2016年は結婚したり転職したり引っ越ししたりといった感じでした。あまり趣味プロジェクトに割く時間を作れずにそのまま3年くらい経過してしまった、という感じです。
別に並行してやればいいじゃないかと思われるかもしれません。まぁでも結論としてできなかったんですよね。
それこそiOSDCは自分のプロダクトだと思って関わっていましたし、iOSDCも開催は9月のどこかで3日間だけではあるのですが、準備は年明け1月から始まります。常に忙しいわけではないのですが頭のなかにどこかしらiOSDCがあり、そういう状態を一度リセットして自分のやりたい、個人的なクリエイティブなことをやろう、と考えました（ダラダラするだけかもしれないけど）。
去年と一昨年の開催期間中は、副隊長やHQ担当として全体を見ていたこともありトークをほとんど聞くことができず、技術カンファレンスに参加したのかどうか自分でもよくわからない状態でした。
今年はTrack E担当として適度にトークを聞くことができ、またそれがとても楽しかったです。トークを聞きながら、やっぱり自分もあっち側に立てるように何か作ろう、という気持ちが固まりました。
4年間でできた強い文化
iOSDCへの思い入れはとても深く、いまのiOSDCの文化を作ることに貢献できたという自負もちょっぴりあったりします。毎年スピーカー・参加者の方が楽しみにしてくれるような仕掛けだったりネタをめちゃくちゃ考えて準備をしていました（今年のダークモードとか）。
オープニングムービーもそうです。
2016年
2017年
2018年
2019年
2016年, 2017年のオープニングムービーは僕が作りました（2018年と2019年はプロが作っています）。
2016年は初開催だったので素材となる写真もなければ、オープニングムービーをわざわざ作るカンファレンスもそこまでなく何を参考にしたら良いのか全然わかりませんでした。なので本当に構成を苦労して、ひねり出して作りました。
iOSDCのオープニングムービーは毎年必ず最後に「Enjoy iOSDC Japan 20xx」と表示されるのですが、これは2016年にひねり出した構成であり、メッセージです。
それがいまも生きていて、さらにはオープニングムービーを作ったことで、（なぜか）映像にこだわったりするiOSDCの文化形成に一翼を担えたのではないか、と。
あとはスタッフ全員、とにかく「みんなを楽しませよう」「最高のカンファレンスにしよう」という気持ちだけで動いています。動画制作だったり、カンファレンスアプリの実装だったり、ノベルティの制作だったり。
ほぼ全員エンジニアなので、普段は「電話なんか嫌だ〜」とか言っているはずなのに、ノベルティ制作のときはそんなことも厭わずちゃんと電話して業者と細かいスペックや納期を詰めたりしています。
「iOSDCだったらこれやるよね。でも、それはやらないよね」という明文化されてないんだけどコアとなるバリューを共有できる人たちがコアスタッフに集まっていて、それがこの4年間でできた強い文化だと思っています。
カンファレンス運営もそうですが、こういう人たちと一緒にプロダクト作りたいですよね。
"Please stay connected with us"
去年のiOSDCブログで、「いつか参加者として参加したい」 と書いていたのですが、来年はようやくその夢が叶います。
ただ、一度辞めるということが二度と戻れなくなることを意味しないとは思っています。もう一度やりたくなったら「スタッフ足りてます？やってもいいですか？」と長谷川さんに聞こうかなと。聞くだけかなと。
（※長々と書いていますが、別にスタッフの入れ替わりというのは珍しいことでもなんでもありません）
「Please stay connected with us」であり、間違いなくスタッフだけがコミュニティに貢献する方法ではないと思っています。
そういう意味では、せっかくクリエイティブなことをするためにスタッフを卒業するので、来年はなんかトークを話そう！という気持ちで溢れていたりします（これでCfP落選するところまでがネタ）。
Enjoy iOSDC Japan 2020(?)
思い出はたくさんあるのですが一つだけ上げろと言われたら、2016年の一番最初のiOSDCスタッフミーティングの時に「誰も来なかったら俺たちだけでもくもく会やろう」という長谷川さんの言葉だったりします。というわけで最初のスタッフミーティングの写真を貼っておきます。
長谷川さん！もくもく会、もう杞憂になりましたね！
そんなわけで、来年のiOSDC Japan 2020(?)は純粋な参加者として楽しみにしています！
エンジニアリングマネージャーになってから守っているたった3つのこと
この記事は Engineering Manager Advent Calendar 2018 5日目の記事です。
2018年10月にEM(Engineering Manager)なりました。
たった2ヶ月しか経過しておらず、何一つ成し遂げることができていないので、エンジニアリングマネージャーになってから守っている個人的なことを3つ紹介しようと思います。
続きを読むコアスタッフが見た "いつか参加したい" iOSDC Japan 2018 #iosdc #iwillblog
iOSDC Japan 2018が8/30 ~ 9/2の3.5日間にわたって開催されました。2016年に始まり、2018年で3回目です。
©iOSDC Japan
僕自身はコアスタッフとしてもスピーカーとしても3回目の参加となるのですが、年々規模が大きくなるに連れて知名度が上がっていることを肌で実感しています。
コアスタッフ
今年は2つをメインでやりました。
- 横断幕担当
- HQ
開催期間中はHQでこんな感じでスタンバイしていました。
みなさんのブログ一覧は → https://t.co/QuS6PiBU2G … です！
— iOSDC (@iosdcjp) August 30, 2018
ブログを書いて下さった方、 https://t.co/RHtI4yZDpq … からお知らせください！🙏
事前＆会期中にブログを書いてくれた方に、ちょっとしたプレゼントをご用意しています！ブログを書いた方は、1階のHQまでお越しください！😀 #iosdc pic.twitter.com/RW7PXqZtzn
ブログのステッカーを渡すことは副業で、各部屋のツイートを見たり、今年導入したインカムから入ってくる情報を聞きながら指示を出したり聞いたりしていました。
LT
今年は以下の内容でLTしました。「OK Google」から「Alexa」に変わりました。
Google アシスタントで実装する場合は、Dialogflow + Heroku + Vaporという構成を想定していたのですが、我が家でメインで使用しているスマートスピーカーがGoogle HomeからEcho Spot に変わったことにより変更しちゃいました。
発表の一週間前に急遽変更したこともあり、準備不足でデモに失敗するなど情けないトークになってしまったことが残念でなりません。
LTで題材としてあげたスキルは、実はiOSDC期間中も毎日審査に提出し、LTで「公開されました！」というカッコいいやつを目指したのですが見事に失敗しました。 審査がすごくしっかりしているところがスゴいなと感じています（言い訳）。
そのうちストアで公開できると思うので、Alexa Skillの開発や審査については別でブログにまとめてみようかな、と思っています。
定番が出来始めたiOSDC
仕事やWEB+DB PRESSの特集の執筆でなかなかスタッフ業をする時間が取れず、残念ながら今年はコアスタッフとしての貢献がほとんどできませんでした。
毎月開催されているスタッフミーティングも5月ごろから参加できなくなってしまい、2016年、2017年と僕が制作を担当していたオープニングムービーも今年は作ることができませんでした。
そんな状態でオープニングムービーは一切タッチしていなかったんですが、出来上がったものを見て自分がこの2年間くらい悩んで作り上げた構成に近いものができており、着実にiOSDCの定番ができあがってきていることを実感しました。
他にもタオマフを持っての記念撮影やハイタッチでの解散など、ある程度流れができはじめたんだな、と今年は強く感じました。
まとめ
次はiOSDC Japan 2019ですね(たぶん)。
2年前(2016年)はiOSDCは一度も開催したことがなかったので、もちろん知っている人はいるはずがなくサポートや告知に苦労した記憶があります。このときは「果たして人が来てくれるのだろうか...?」という状態で、今では考えられないかもしれませんが誰も来ないことも想定したりしていました。
1年前(2017年)は一度目の開催がそれなりの規模になったこともあって、実績とそれなりの知名度をもって開催することができました。「ある程度人は来てくれるだろう」という希望を持てた年でした。
そして今回は3度目。"iOSDC"というカンファレンスがそれなりに認知され、日本で最も大きなiOS関連技術のカンファレンスと呼んでもおかしくない状況になったと思います。
そんな状況でも1年目の不安が頭を過ることがあり、「参加者の皆さん、スピーカーの方々、スポンサーの皆さま、そしてスタッフの力があってiOSDCは成り立っているんだ」という気持ちは今年も変わりませんでした。
個人的なことを話すと、スピーカー、スポンサー、スタッフの3つの立場は体験しているのですが、まだ純粋に「参加者」としてiOSDCに参加したことがありません。
去年くらいから 「いつか参加者として参加したい」 と思うようになりました。
来年あたりは「参加者として見てみようかな」と考えていたのですが、「いつか参加者として参加したい」 iOSDCを作ることが自分にとって最大の楽しみなんだな〜、と終わったあとに強く思いました。
それではまた来年（？）お会いしましょう！
WEB+DB PRESS Vol.106のAndroid/iOSアプリ設計を執筆しました #wdpress
平成最後の夏のWEB+DB PRESSである、WEB+DB PRESS Vol.106のAndroid/iOSアプリ設計をメルカリのエンジニア6人（@motokiee、@sota1235、@rkowase、@callipan、@86、@sue__71）で執筆しました。
- 作者: 成田元輝,杉浦颯太,小和瀬塁,山中大輔,末田正樹,藤野真聡,竹馬光太郎,桑原仁雄,倉長拓海,牧大輔,秋山卓巳,前田雅央,星北斗,末永恭正,久保田祐史,池田拓司,はまちや2,竹原,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2018/08/24
- メディア: 単行本
- この商品を含むブログを見る
自分は1章と2章の一部の執筆を担当し、iOSサンプルアプリ開発とAndroidサンプルアプリ開発のお手伝いをしました。Androidの方はガッツリ実装というよりもiOSとの差分の調整を行っていました。また全章くまなくレビューしています。
本ブログでは特集の見どころと、執筆の進め方について簡単にまとめてみました。特集を読んでいただけるとより楽しめるかと思うので、ぜひ手にとって読んでみてください。
モバイルアプリの設計に悩んだり、より良いコードを目指す方々の役に立つと幸いです。
特集の見どころ
設計という幅広いテーマを扱うので、どこまで盛り込むべきか/盛り込まないべきかを執筆メンバーでかなり議論した上でDI/MVVM/Fluxという構成になりました。
1章では本格的な解説に入る前に、モバイルアプリの設計はなぜ重要なのかを簡単にまとめています。また特集の解説のためのサンプルアプリも用意しており、その仕様についても解説しています。
特集を執筆するにあたって最もこだわったのは、共通の仕様でAndroidとiOSそれぞれのサンプルアプリを実装している点です。いまのサービス開発において、AndroidとiOSで共通の実装をすることは珍しくないというよりも、そうでない方が珍しいと思います。ただ、技術スタック的に両方を深いレベルで書ける人はそんなに多くないと思うので、執筆メンバーが豊富だったこの機会に実現できてよかったです。
現場でiOSの開発者はAndroidの開発者と、Androidの開発者はiOSの開発者と仕様について話し合うこともあると思うので、お互いの認識を合わせるのにも役立つのではないかと思います。
さて、1章でも記載していますが、2章以降は一貫して次のパターンで書かれています。
基本的には設計パターンとその概念についてをしっかりと理解することが重要だと思っています。iOS or Android特有の部分については必要に応じて学べば問題ないはずです。
それを踏まえて2章以降について簡単に説明します。
2章はDIパターンをテーマとしているのですが、最も長い9ページになりました。DIパターンは応用範囲の広い概念なので、これをわかりやすい言葉にすることに腐心しました。SwiftでもKotlinでも読めるに工夫をしているので、DIパターンがよく分からないという方はじっくり手を動かしながら読んでみてください。Swiftの解説ではSwiftの言語仕様を活用しながらDIパターン+抽象化を手厚く解説し、AndroidはDaggerを使って解説をしています。
3章はMVVM(Model-View-ViewModel)をテーマとしています。データバインディングのためにライブラリを導入しながらMVVMについて解説しています。iOSではRxSwiftをデータバインディングのために導入していますが、RxSwiftの詳細な説明はページの都合上少なめになっています。そもそもRxSwiftを導入すべきかどうかを議論し、RxSwiftについては最低限の説明にとどめ、MVVMの解説を手厚く行っています。
解説にまでは組み込めませんでしたが、個人的なこだわりとしてiOSのViewModelのテストをサンプルコードにしっかりと書いています。ViewModelのテストで困っている方の参考になるかもしれません。
4章はFluxアーキテクチャがテーマです。サンプルアプリはこの章で完成します。データフローを役割分担によってシンプルにすることで複雑な状態管理を解決しています。サンプルアプリの要件を整理しながら解説していて、その整理の流れを読んでいただけると実際の開発にも応用しやすくなると思います。
特集のまとめにも書いていますが、本特集で紹介したものをそのまま採用するのではなく、その知識をベースに工夫することをオススメします。
また、コードは一度書いたら終わりではなく日々進化していくものです。より良いコードへと進化していくことを前提にリファクタリングに励みましょう。
執筆の進め方
執筆はGitHub上で進められました。textlintやDangerを使って用語の統一を試みました。他にもPULL_REQUEST_TEMPLATE を使うなど仕組み化に力を入れてみたのですが、最後は人の手で頑張ることになったように思います。
プロの編集
今回は@inaoさんが編集をしてくださいました。もともと執筆経験のメンバーから「@inaoさんは厳しい」という話を聞いていてドキドキしていたのですが、噂通りの厳しさでした。
特集全体を通しての整合性や細かなワード一つに対するこだわりがすごくて、「これがプロの編集者なのか...!!」ということを身をもって実感することができました。技術書典で2回執筆したことがあるのですが、そのフィードバックとは全く違うレベルでした。
自分たちもコードを書くときは同じくらいのこだわりを持って書いているので、やはり神は細部に宿るのだな、ということをあらためて実感しました。
一方で一緒に執筆していたメンバーも同様にかなり厳しかったので、@inaoさんだけが厳しいというわけではありませんでした。
設計をテーマにすることは、ソフトウェアエンジニアの皆さんであれば分かると思うのですが、なかなかドキドキするものです。比較的マサカリを飛ばしやすいテーマでもあると思います。
そういう前提を執筆メンバー全員で共有できていたこともあって、各メンバーが緊張感を持って執筆に臨むことができたと思います。
自分の中では「厳しい」=「ツラい」ではないので、とても楽しむことができました。
まとめ
「執筆してみませんか」という話は社内で頂きました（補足するとバイネームではないです）。去年くらいまでは、普段の仕事+副業orカンファレンス運営という状況でとても執筆する気持ちにはなれずにいました（前述したように技術書典で少し書くくらいはやっていました）。
それでも執筆した理由は3つあって、1つは厳しいと評判の@inaoさんからお話が来ていたこと、もう1つは母親が「文章うまいんだから本でも書いてみたら」と昔から言われていたので親孝行になると思ったこと、そして最後はWEB+DB PRESSという歴史の一員になりたかったことです。
@inaoさんと関われたことはとても良い経験でした。論理を組み立てて一貫性を持った説明をするための視点は執筆に限らず役立つもので、そういった力を執筆を通して育むことができたと思います。
母親は「内容はよく分からなかった」ものの「家宝にするわ」と言っており、喜んでいることが窺えたので親孝行ができたと思います。
そして、WEB+DB PRESSという歴史の1ページに加わることができたのは本当に嬉しいです。執筆をしている過程で以下のスライドを見つけたのですが、WEB+DB PRESSは"エンジニアのハブ"です。
いままでたくさん読んできたことはもちろん、特集を書きながら過去のWEB+DB PRESSを読み返したり、知り合いの執筆経験者に連絡をとってアドバイスをもらったり、一緒に執筆しているメンバーと議論したりと「あぁ、WEB+DB PRESSはハブなんだ」ということを確かに実感しました。
読むこともそのハブに参加することなので、ぜひ読んでみてください。フィードバックお待ちしています。
最後に、ただでさえ忙しい中、一緒に執筆をしてくれた@sota1235、@rkowase、@callipan、@86、@sue__71に感謝！
