コアスタッフが見たiOSDC Japan 2019 & コアスタッフの卒業 #iosdc #iwillblog

発表者の皆さま、参加者の皆さま、スポンサーの皆さま、そしてスタッフの皆さん、iOSDC Japan 2019お疲れさまでした!!

コアスタッフとして4回目のiOSDCでした。今年はトークもなく、純粋にスタッフとしてカンファレンスに関わっていました。

今年は、

  • 撮影スポット制作担当
  • Track E隊長(開催期間中)

の2つが担当でした。

f:id:motokiee:20190911184555j:plain
iOSDC2019_ライトモード撮影スポット

f:id:motokiee:20190911184322j:plain
iOSDC2019_ダークモード撮影スポット

タテ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ブログで、「いつか参加者として参加したい」 と書いていたのですが、来年はようやくその夢が叶います。

motokiee-blog.hatenablog.com

ただ、一度辞めるということが二度と戻れなくなることを意味しないとは思っています。もう一度やりたくなったら「スタッフ足りてます?やってもいいですか?」と長谷川さんに聞こうかなと。聞くだけかなと。

(※長々と書いていますが、別にスタッフの入れ替わりというのは珍しいことでもなんでもありません)

「Please stay connected with us」であり、間違いなくスタッフだけがコミュニティに貢献する方法ではないと思っています。

そういう意味では、せっかくクリエイティブなことをするためにスタッフを卒業するので、来年はなんかトークを話そう!という気持ちで溢れていたりします(これでCfP落選するところまでがネタ)。

Enjoy iOSDC Japan 2020(?)

思い出はたくさんあるのですが一つだけ上げろと言われたら、2016年の一番最初のiOSDCスタッフミーティングの時に「誰も来なかったら俺たちだけでもくもく会やろう」という長谷川さんの言葉だったりします。というわけで最初のスタッフミーティングの写真を貼っておきます。

f:id:motokiee:20190911195546j:plain
2016年1月19日 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回目です。

f:id:motokiee:20180910172808j:plain ©iOSDC Japan

僕自身はコアスタッフとしてもスピーカーとしても3回目の参加となるのですが、年々規模が大きくなるに連れて知名度が上がっていることを肌で実感しています。

コアスタッフ

今年は2つをメインでやりました。

  1. 横断幕担当
  2. HQ

開催期間中はHQでこんな感じでスタンバイしていました。

ブログのステッカーを渡すことは副業で、各部屋のツイートを見たり、今年導入したインカムから入ってくる情報を聞きながら指示を出したり聞いたりしていました。

LT

今年は以下の内容でLTしました。「OK Google」から「Alexa」に変わりました。

Google アシスタントで実装する場合は、Dialogflow + Heroku + Vaporという構成を想定していたのですが、我が家でメインで使用しているスマートスピーカーGoogle HomeからEcho Spot に変わったことにより変更しちゃいました。

発表の一週間前に急遽変更したこともあり、準備不足でデモに失敗するなど情けないトークになってしまったことが残念でなりません。

LTで題材としてあげたスキルは、実はiOSDC期間中も毎日審査に提出し、LTで「公開されました!」というカッコいいやつを目指したのですが見事に失敗しました。 審査がすごくしっかりしているところがスゴいなと感じています(言い訳)。

そのうちストアで公開できると思うので、Alexa Skillの開発や審査については別でブログにまとめてみようかな、と思っています。

定番が出来始めたiOSDC

仕事やWEB+DB PRESSの特集の執筆でなかなかスタッフ業をする時間が取れず、残念ながら今年はコアスタッフとしての貢献がほとんどできませんでした。

motokiee-blog.hatenablog.com

毎月開催されているスタッフミーティングも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)で執筆しました。

WEB+DB PRESS Vol.106

WEB+DB PRESS Vol.106

自分は1章と2章の一部の執筆を担当し、iOSサンプルアプリ開発Androidサンプルアプリ開発のお手伝いをしました。Androidの方はガッツリ実装というよりもiOSとの差分の調整を行っていました。また全章くまなくレビューしています。

本ブログでは特集の見どころと、執筆の進め方について簡単にまとめてみました。特集を読んでいただけるとより楽しめるかと思うので、ぜひ手にとって読んでみてください。

モバイルアプリの設計に悩んだり、より良いコードを目指す方々の役に立つと幸いです。

特集の見どころ

設計という幅広いテーマを扱うので、どこまで盛り込むべきか/盛り込まないべきかを執筆メンバーでかなり議論した上でDI/MVVM/Fluxという構成になりました。

1章では本格的な解説に入る前に、モバイルアプリの設計はなぜ重要なのかを簡単にまとめています。また特集の解説のためのサンプルアプリも用意しており、その仕様についても解説しています。

特集を執筆するにあたって最もこだわったのは、共通の仕様でAndroidiOSそれぞれのサンプルアプリを実装している点です。いまのサービス開発において、AndroidiOSで共通の実装をすることは珍しくないというよりも、そうでない方が珍しいと思います。ただ、技術スタック的に両方を深いレベルで書ける人はそんなに多くないと思うので、執筆メンバーが豊富だったこの機会に実現できてよかったです。

現場でiOSの開発者はAndroidの開発者と、Androidの開発者はiOSの開発者と仕様について話し合うこともあると思うので、お互いの認識を合わせるのにも役立つのではないかと思います。

さて、1章でも記載していますが、2章以降は一貫して次のパターンで書かれています。

  • 設計パターンとその概念の解説
  • iOS/Swiftでの実装方法の解説
  • Android/Kotlinでの実装方法の解説

基本的には設計パターンとその概念についてをしっかりと理解することが重要だと思っています。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に感謝!

プロジェクトをリードする前に読みたかった本

この1年ほど、プロジェクトのリードを任せてもらえるようになりました。2017年の夏くらいから「プロジェクト推進役」→「PJO」→「Tech Lead」, 「Project Lead」など、正式ではないものの「肩書」のようなものがついていますが、実際にやっていることは「プロダクトの成功に向かってプロジェクトを行動で引っ張っていくこと」で統一されています。

これは別に偉くなったとかではなくて、そういう責任を持ってPJに関わる役割だと思って臨んでいますし、実際マネージャーからもそのように言われています。

自分なりに試行錯誤をして時には成功し、時には失敗しながらなんとかかんとかやってきていているのですが、「あー、この本に救われた」とか「ちょっと前にこの本読んでおけばよかった...」という本があったので何冊か紹介したいと思います。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

読もう読もうと思って忙しさでなかなか手を付けられていなかったのですが、最近ようやく読むことができました。

何回かプロジェクトのリード含めてマネジメントをやっていると「あ、これいけそう」とか「むー、ヤバい感じになってきたな」とかプロジェクトの状況が肌感で分かるようになってきます。これをもう一段階掘り下げて「なぜそうなのか」が僕の場合はよく分かるようになりました。

この本は不確実性をエンジニアリングで解決する方法について述べています(と僕は思っています)。

企業活動は、市場に存在する不確実性と、複数人のコミュニケーションの不確実性とを相手にした「エンジニアリング」です。 - P300

いまPMの@kyosu_keとTech Leadとしてタッグを組んで とあるプロジェクトを進めているのですが、2人ともめっちゃ「不確実性下げよう」って言ってます。もはやブーム。

kyosu_keと僕の「不確実性」は若干異なっていて、彼の場合はPM視点での「目的不確実性」のことをよく言っていて、僕は「方法不確実性」のことをよく言っています。

これは「どうやって正しく作るか」が命題であるエンジニアと、「何を作るか」を考えるプロデューサーの視点の違いだな、と思っています。

それからメンタリング、アジャイル、技術的負債など、Web業界だと当たり前の用に使われていながら本質的な意味が取り残されてしまいがちなワードがたくさんあるんだな、ということにも気が付きました。

この本を読んでからの変化としては「可視化」にめちゃくちゃこだわるようになりました。「なんかヤバそう」とかスケジュールに関することは、いつ、どの段階で、何を、何人でやらなければならないのかをビジュアライズして数字に落とし込みます。

ボリューム感が分からないくらいデカいプロジェクトだったら、超ざっくりでも良いから見積もりを出しながら経験則が働く状態に持っていて見積もりのサイクルを回す、というイメージです。

「可視化」はコミュニケーションにも当てはまります。目を見て挨拶するとか、相手の話していることにリアクションするとかは「自分から相手への承認」の「可視化」です。

プロジェクトマネジメントや人とのコミュニケーション全て含めて「エンジニアリングだったんだ」というなんとなく気づきながらエンジニアリングと線を引いていた自分には目からウロコというか言われるまでそう認識することができませんでした。

推進役, PJO, Tech Lead, Project Leadなど肩書は何でも良いのですが、プロダクト/プロジェクトの成功に向かうとき、読んでいくときっと救われると思います。

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

僕の勤めているメルカリではOKR(Objectives and Key Results)を目標管理システムとして採用しています(OKRについての細かな説明は省略します)。

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

メルカリに1年半以上働いていながらOKRの仕組みや目標の設定がうまくできず困っていたところにこの本が出るのを知ってソッコーで買って読みました。

Webの記事や会社のwikiなどでOKRの説明を読んでもあまり理解できなかった自分にはこの本が本当にありがたかったのですが、それは「目標設定」の方法が書かれている以上に「運用」の方法がしっかりと書かれていたからです。

  1. Qのムーンショットな目標を作る(長期)
  2. フォーカスすることを週ごとに必ず設定する(短期)
  3. 次の月にできていることをイメージして週ごとに更新する(中期)
  4. 健全性の指標を作る

本の内容とほぼ同じ通りに以上の4つをマトリックスにして1枚のシートで管理しています。短期的にフォーカスすることと長期的に見据えなければいけないことのバランスがどうしても悪くなってしまうのがプロジェクト進行上の悩みだったのですが、この方法を導入してからあまり悩まなくなりました。

OKRで困っていたらマストで読みましょう。

まとめ

たぶん「リードよろしく」と言われる瞬間は突然来るんじゃないかと思います。他にも読んでおきたい本はあるのですが、実務に影響を及ぼしたのはこの2冊なので、そのときは思い出してみてください。

近況 2018年3月

近況

コアスタッフが見たiOSDC Japan 2017 #iosdc #blog | wearable44 というブログを書いて以来半年ぶりにブログを書きます。

今まではWordPressでブログを運用していたり、GitHub Pagesで書いてみたりいろいろ試していたものの運用が一番ラクなはてなブログにすることにしました。

特にWordPressは色々と面倒なので早く後片付けをして閉じてしまいたいと思う一方、ログとして残しておきたい気持ちもあるので悩ましいところではあります。

仕事

ソフトウェアエンジニアとしての仕事をしながらプロデューサー的なポジションをこの半年ほどやっていたのですが、個人的にはとても良い経験だったと思います。

自分で分析して何をしたら伸びるか企画を考え実行に移す、というのは本当に面白いことです。

一方でチームはiOSエンジニア1人しかいなかったこともあり、企画と実装を平行に進めことがどうしても難しくそれがフラストレーションにもなっていました。

プロデューサーとしてのスキルがまだまだ足りないこともあり、基礎的なフレームワークを使いこなせていないことが原因だったな、といまとなっては感じています。

一時期はプロデューサーへの転向を考えていてかなり真剣に方向性を考えていたのですが、色々と事情が変わりiOSを専門にもうしばらく続けていくことになりそうです。

直近では新規事業サービスであるメルカリ カウルのiOS開発と並行してメルカリのiOS開発をしています。iOSでは自動化周りしっかりと時間を作って行えたことが良かった一方で、あまり技術的に面白いことに取り組めなかったとも思っています。

プロデューサーのチャンスは巡ってくると思うので、その時までにそっちのスキルもしっかり磨いていきます。

プライベート

家計の見える化

昨年10月に1年越しの新婚旅行を終えてから家計の整備をはじめました。

まずは「可視化」ということで、自分と妻の収入と支出をMoney Fowardで見える化しました。プレミアムプランに入って家計レポートも出るようにしています。

自分の支出に戦々恐々としていたものの、常識的な支出の範囲内だったので夫婦揃って安心しました。

その過程でいまさら格安SIMに乗り換えたのですが非常に満足しています。これまでauを使っており、家の回線をauひかりに変えるなどして節約を試みましたが、結論から言うとau関連のサービスをすべてやめたことが家計にとって最も良かったです。auひかりもビッグローブ光より結果的に高くなってしまい、時間とお金をかけて無駄なことを積み重ねてしまい公開してます。

やたらと無用なオプションを付けられることは半分しょうがないと思いつつ、その解約忘れでかなり損をしました。結果的に違約金を払ってLINEモバイルに乗り換えました。

これをやるとやらないかで10万円の差があることが分かったためです。もしまだ3大キャリアを使っている方がいたら一度年間でかかる金額を計算して比較してみることをオススメします。

ファイナンシャルプランナーの方に一度相談した際に言われたのですが「生活のコストを全く変えずにすぐに節約できる唯一の方法」とのことで、言われたその日にやっておけばよかったな、と後悔しています。

生命保険

生命保険にも加入しました。

生命保険に「え?」と思う方もいるかもしれませんが家族がいることを考えての選択です。ドル建ての外貨終身積立型保険です。年金代わりになりつつも、利率最低保証付きで積立になり、さらには自分に何かあった時にリカバリできることも考えてこれにしました。

妻が保険会社で働いていることもあって、以前から加入について相談されていたのですが、どうしても抵抗がありました。ファイナンシャルプランナーへの相談をきっかけに自分で色々と調べてみて、金融系の商品としての面白さを感じたこともきっかけの一つです。

そんなこともあり、どちらかというと資産運用をメインで加入しています。iDeCoやNISAも検討中ですが、基準としては所得控除になるものを選ぼうと思っています。

収入を上げること同時に節税も大事な。そう考える年頃になったようです。

昨年から副業の収入が一定金額を超えてしまったことによって確定申告に迫られ、いままで年末調整で面倒くさいとしか思っていなかった税金周りのことに面白みを感じてきたことも取り組んだ原因の一つです。

Web系の会社はストックオプションや株の話はしょっちゅうするのにこういうお金の戦略的な運用について話す人は少ないな、と感じています。センシティブな問題なことと、個々人の環境によって異なるので話さないだけなのかもしれませんが。

パーソナルトレーニング

今年の頭からパーソナルトレーニングを始めてみました。普段通っている会社から最寄りのジムで1時間約6000円でお願いしています。

ジムは10年以上通っているのですが、この数年はあまり良い成果が得られていなかったので試してみました。数字でハッキリと効果が見えたので隔週でお願いしています。

ただしこの一ヶ月くらいはいろいろな事情で行くことができなかったのでお休み中です。まだしばらくお休みするつもりで5月からまたお願いしようと思っています。

トレーニングをしっかり見てもらえるだけでなく、普段の食事内容にも気をつけるようになるのでオススメです。初心者でも1on1だと聞きやすいので、特にジムに通ったことがない人ほどお願いした方が良いのではないかと思っています。

まとめ

上で書いた以外のことでも大きめのことに取り組んでいるのですが、気が向いたら書いてみようと思っています。この半年くらいはソフトウェア周りのことにしっかりと取り組めていなかったので、何か作りたいなと思っています。

これだ!というアイデアができたのでそれを形にすべく動き始めています。iOS以外で取り組むこともテーマの一つなので時間がかかると思います。

Time 型安全に時間を扱うSwiftのライブラリ

GitHubで気になったライブラリをまとめていこうと思い立ったのではてなでブログを始めてみた。

きょう気になったのはdreymonde/Time。型安全に時間を扱えるSwiftのライブラリ。

github.com

続きを読む