ドットリくん

iOSアプリを開発しています。 主にソフトウェア開発に関係する感じのポエムを書きます。

ドットリくん

iOSアプリを開発しています。 主にソフトウェア開発に関係する感じのポエムを書きます。

最近の記事

iOSDC Japan 2023でLTしてきました

プロポーザル 今回はLT1本だけ応募して運良く採択されました。 応募のタイミングで「こういうの作ってみようかな〜」と思ってたアイデアがあり、iOSDCで発表することになったら絶対に実現しないといけなくなるので、己に制約と誓約を課すことで念の威力を向上させる意味で応募しました。 ガチャ演出の開発 どう実現するか全然わからない状態から始めたのですが、まあ無理なら無理だったでそれをおもしろく話せばいいだけなので気楽に取り組んでいました。 Xcodeでの開発自体は2~3時間で

    • iOSDC2022に参加してきました

      day0、day1はオンラインで、day2は現地参加とLTしてきました。 https://fortee.jp/iosdc-japan-2022/proposal/922ece05-9a10-4e88-9c7f-f87312f9b550 2017/2018/2019と登壇してきたので今年で登壇は4回目。 去年・一昨年は息子が生まれて余力がなかったのでオンラインで視聴のみ参加。 久々にリアルで人と会えたかつての同僚や前職のメンティーたちと再会して話せて感慨深かった。 も

      • 男性会社員が育休を取ってみた話

        先月末に子供(第一子)が誕生したので、8月は育児休業+特別休暇(5日)で1ヶ月ほどお休みさせていただき、新生児の育児をしていました。 男性が育休を取るということ大前提として私(夫)が育休を取得するのは子育てを「手伝う」ためではありません。 むしろ自分が子育てを担当することで出産後の奥さんに休養してもらいつつ、休んでもらっている奥さんに必要な場面で子育てを手伝ってもらうという立ち位置です。 育児に対する理解を深めつつ今後の家族での生活環境を整備していければなーという感じで

        • 開発期間1週間でAppStoreに個人開発アプリをリリースするためにやったこと

          『ActGazer』というシンプルなヘルスケアiOSアプリを1週間で作ってさっき審査通過して公開ボタンを押して反映されるのを待ってる間に書き起こしています。 これまで仕事でiOSアプリ開発を6~7年ぐらいやってきて、いくつものアプリのリリースを経験してきたのですが、実は個人でアプリをリリースしていませんでした。 経緯会社でヘルスケアサービス開発していて、ウィジェットとかApple Watchアプリを作ってみたいなーと思ってました。 しかし実際のプロダクションに入れるには

        iOSDC Japan 2023でLTしてきました

          iOSエンジニアを5年やって鍛えられた能力

          私が仕事でiOSアプリを開発/運用保守するようになってから今月でちょうど5年になります。 私は元々Webアプリの開発者だったのですが、担当者不在になったiOSアプリの開発担当のお話を頂いて、「世界で一番時価総額の高い企業のプラットフォームのアプリケーション開発、チャレンジしてみる価値はあるのではないか」という俗な思惑で引き受けたところからiOSエンジニアとしてのキャリアが始まりました。 この5年間で価値観や開発スタイルに大きく影響を受けたり、鍛えられたなーと思うことを書き

          iOSエンジニアを5年やって鍛えられた能力

          自分という存在に体重を乗せる技術

          自分に自信を持てない人、周囲に結構いませんか。 めっちゃ優秀で力量も情熱もあるのに自分に自信が持てない同僚や元同僚、非常にもったいないのと、何より本人がしんどそうだなーと話していて思うことがあります。 しかし「自信を持て!」という励ましは「自信」という根拠のないものと同じぐらい根拠がないと思うので、(私自身も度胸MAX人間という訳でないのですが)自分という存在をどっしり構えられるまでに至った考え方などをアウトプットします。 --- 失敗の価値を説明できれば、失敗を恐れ

          自分という存在に体重を乗せる技術

          自分がユーザになれないプロダクトを作るということ

          BtoB向けサービスのプロダクト開発において、開発者が「自分が使わないものを作るということ」にどう向き合ってきたか、というポエムです。 TL;DR・自分が使わない仕組みを作る機会 ・職業エンジニアとしてプロダクトにどう向き合うのか ・ユーザになれないことは、ユーザのことを想像しなくていい理由にはならない ・「作る人」と「分かってる人」の歩み寄り ・得た学び --- 自分が使わない仕組みを作る機会仕事としてシステムを開発するにあたって、自分が使わない仕組みを作る機会はかな

          自分がユーザになれないプロダクトを作るということ

          判断の質を担保するためにやっていること

          プロダクト開発の仕事で判断する時に気をつけていることなど。 TL;DR・ファクトチェック ・軽重緩急の切り分け ・動機と文脈の把握 ・施策の有効性の明確化 ・実行前のシミュレーション ・その他テクニックなど --- ファクトチェックまず事柄が事実なのか、事実かどうかさらに確認が必要な状態なのかを把握する。 例えば、エンジニアの言う「できません」は結構曖昧だったりする。 実際には ・現代の技術では実現不可 ・今いるメンバーの技量では実現が難しい ・やればできるけどコ

          判断の質を担保するためにやっていること

          ベンチャーがだいたい宗教か軍隊になる理由

          知人がタイトルのようなことを話していたので考察。 前提ベンチャーはリスクを取って事業に取り組んでいる。ベンチャーは結果を出せなくて資金が尽きると死ぬ。 リソースは有限なので優先度判断することになるけど、結果を出す(もしくは結果を出したように見える)ことが最優先になる。 意思決定速度・判断の質を担保する全員がめっちゃ優秀なメンバーで揃うのは稀であり、めっちゃ優秀な人のまわりにそこそこ優秀な人や微妙な人が集まるのがほとんどなのでは。 そこで民主主義的に意思決定しようとする

          ベンチャーがだいたい宗教か軍隊になる理由