個人開発を7年以上続けて分かった技術選択のコツ
技術革新に適応しようとするイヌさんInkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR最初はとにかく最速でリリースする事を最優先する迷ったら「ときめく方」を選べ程よいところで切り上げて開発を進める使っているモジュールがdeprecatedされるなんてザラだと覚悟する古いから悪いとは限らないシンプルにしていく老舗から継続の秘訣を学ぶ運ゲー要素は排除しきれない最初はとにかく最速でリリースする事を目標に技術選定する開発計画とビジネス計画は切っても切り離せな
独学でiOSアプリ開発をできるようになりたかった私の学習ロードマップ（2019-2020年） - Qiita
はじめに ちょうど去年の2019年10月頃に、SwiftでiOSアプリ開発をしたいと思い学習を始めました。iOSアプリ開発に関して全く未経験だったので、初めは初心者向けの書籍だったり、Udemyの講座から学習を初めました。そして1年と少し経過した現在、良い手応えを感じつつちょっとしたアプリを作成できるようになってきました。 私が学習する中で、教材選びや実際にアプリを作るときに多々困ることがありました。これからiOSアプリ開発を初めたい方や、初心者向けの教材を終えたけど次何をしよう…と困っている方の一助になれば幸いです。 この記事の対象者 iOSアプリ開発を新しく始めたい方 初心者向けの本を読み終えたけど次何をしたら良いか分からない方 実際にアプリを作ろうとしていて悩んでいる方 英語がちょっと分かる方（紹介する講座が英語のため。センター試験のリスニングレベルで十二分です） 私の通ってきた学習
Webデザイナーだけど初めてのiPhoneアプリを7日間で開発した手順
初めてのiPhoneアプリを7日間で開発しました。 ウェブサイトの企画・制作が本業の僕にとって、アプリの制作はまったくの未経験。そのくせApp storeでリリースするところまで達成できたのは、 アプリ作成に挑む前の「気持ちの作り方」 技術不足を補ってくれるツール この2つのおかげだと思っています。 アプリの制作に挑戦し、途中で挫折してしまう失敗の原因に多いのは、身の丈に合わない難しすぎるアプリを作ろうとしてしまうことです。 僕の場合は、とにかくアプリを完成させることをゴールとして設定。開発期間を短縮してくれそうなツールがあれば利用することをアリとしました。 その結果、わずか1週間で初めてのアプリの制作を終えられたのです。 アプリをApp Storeからリリースしたことが「ある」と「ない」の差は自分にとっては大きく、ゼロから1にできたことへの達成感は今でも心に残っています。（この記事はアプ
Cloudflareに入社して1年が経ちました - ゆーすけべー日記
今日でCloudflareに入社してちょうど1年が経ちました。 DevRelチームに所属し、Developer AdvocateとしてHonoの開発をメインに活動してきました。 41歳にして初めての会社員ですが、楽しい時間を過ごしています。今日はそのことについて書いてみます。 入社までの経緯 詳しいことは入社時のブログに書いたのですが、その経緯を再び。 2021年の12月にHonoというCloudflareで動くWebフレームワークをつくり始めて、それがだんだんと人気を得ていきました。 2022年の10月、CloudflareのエンジニアGlenが「Cloudflareで働くのに興味はないか？」と声をかけてくれました。当時UKに住んでいた彼が、地元のオーストラリアに戻りたいので、同じタイムゾーンのエンジニア仲間を探していたのです。ちなみに、GlenはCSS in JS「styled-com
クレディセゾンでDXを進めてきた5年間を振り返る｜小野 和俊
はじめにクレディセゾンに来てちょうど５年が経ったので、これまでの取り組みをまとめてみようかと思う。書き進めていくうちにとても長くなってしまったので、1年につき3トピックに絞ってあとはカットした。それでも5年分なこともありかなり長くなったので、目次から各トピックに飛んでもらえればと思う。社内の関係者も読むかもしれず、「自分のやったことが載ってない！」と思うこともあるかもしれないが、内製開発案件だけでも53案件あり全部載せるととんでもない量になるので許してほしい。それから、振り返ってまとめると退職すると勘違いされるかもしれないけれど、退職するわけではありません！ 2019年：ゼロからのスタート1-1. 内製開発エンジニア募集を始める「日本のそれなりの規模の事業会社の中に、内製開発チームを立ち上げることはできるのだろうか？」 2019年3月、クレディセゾンに来たばかりの私にとってはこの質問への答
先達エンジニアに学ぶ 思考の現在地 Online Conference (2024/04/16 12:00〜)
先達エンジニアに学ぶ 思考の現在地 Online Conference エンジニアリングの未来を牽引してきた各分野のエキスパートたちが一堂に会するオンラインカンファレンス。 普段からよく知っているあの人がどう考えているのか、今何に興味を持っているのか、その「頭の中」を覗いてみたい、と思ったことがある人も多いはず。設計、コーディング、技術のキャッチアップ、アウトプット…皆さんの周りで抜きん出た技術を持っている方の背後にも、独自の思考法や勘所が存在します。彼/彼女らは日々どのようにして新しいアイディアや技術を取り込み、現在何に最も興味を持ち、情熱を傾けているのでしょうか。 本カンファレンスでは、各分野で第一線を駆け抜ける皆さんに登壇いただき、その瞬間の興味や技術に焦点を当て、リアルなエンジニアリングの舞台裏に迫ります。そして、ご参加者が、登壇者たちの独自の思考法やアプローチに触れ、自身のスキル
こんなマネージャーと仕事がしたい────カケハシいくおさんインタビュー
2023年末に「こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと」というブログ記事が話題になりました。この記事で注目を集めたエンジニアリングマネージャーは、株式会社カケハシの「いくおさん」こと小田中 育生さん。 今回はそんな素晴らしいマネージャーである、いくおさんに日々意識しているチームコミュニケーションについてお話をお聞きしました。 どうしたらチームメンバーとの強い信頼を築けるのか、良いマネージャーになるにはどうしたら良いのか、気づきが得られる内容になっていると思います。どうぞ最後までお読みいただければ幸いです。 株式会社カケハシ エンジニアリングマネージャー。 2009年に株式会社ナビタイムジャパン入社。研究開発部門に配属。プロダクトや開発プロセスのカイゼンを推し進め、アジャイルとの出会いから社内でスクラムを積極的に導入し、ナビタイムジャパン VPoEを務
時雨堂創業 12 年目
2013 年 3 月 8 日に時雨堂を創業し、2024 年 3 月 8 日で時雨堂創業 11 年、そして 12 年目にはいりました。あっという間です。 起業のきっかけは、ある経営者に「貴方がどんなに一生懸命に製品を作ってもそれは会社のものでしかないので、自分の会社を持って自分の製品を作って、売った方がいい」といわれた事なんですが、それから 11 年立ちました。 起業したときから状況も大きく変わりました。自社製品の売り上げだけで会社が回っています。今後の時雨堂について雑に書いて行きます。 少人数でスケールする製品を作り続ける時雨堂はパッケージソフトウェアのサブスクリプションで稼いでいる会社です。営業もいないため、買いたいといってくれる企業に売るだけです。 社員が社内にあるライセンス発行サーバーに Tailscale でリモートで繋いでライセンス (JSON ファイル) を発行し、ライセンスフ
Androidエンジニアあんざいゆき氏×RIZAPエンジニア座談会｜RIZAPテクノロジーズ株式会社
最先端で活躍するAndroidエンジニアであるあんざいゆきさんが、このたびRIZAPテクノロジーズ社の技術顧問として就任しました！ 今後、chocoZAPアプリの開発支援や若手育成に携わっていただくことになります。そこで今回は、RIZAPテクノロジーズのエンジニア２人と話し合っていただきました！ ▶︎プロフィール あんざいゆき／株式会社ウフィカ代表取締役社長。Google Developer Expert for Android。Android App Developer。Android 黎明期よりアプリ開発に従事し、長年の経験や知識をもとにさまざまな企業でアプリ開発の支援や技術顧問・アドバイザリーを行う。また、カンファレンスでの講演や著作などコミュニティ活動に力を入れている。著書「Android Pattern Cookbook マーケットで埋もれないための差別化戦略」（インプレス）、「
キャッシュを活用するために必要な知識と勘所 - そーだいなるらくがき帳
どうもキャッシュバスターズ、 id:Soudai です。 Cache（以下、キャッシュ）は特定の場面に置いて劇的な効果を発揮し、様々な問題を解決する反面、新たなコンポートやミドルウェアが追加され、複雑性が上がり、運用のレベルが上がるため、扱いに注意する必要があります。 キャッシュを活用することで、パフォーマンスの改善や負荷軽減が行われ、コンピュータリソースの最適化によるサーバコストの削減や、レスポンスの改善によるユーザエクスペリエンスの改善がされます。 反面、その劇的な効果に毒され安易に多用すると、サービスが強くキャッシュに依存してしまい、非常に壊れやすくなり、運用が難しくなってしまいます。これをWeb界隈では「キャッシュは麻薬」と比喩されて、戒められてきました。 そのためキャッシュを使わずにサービスが運用できるのであれば使わないに越したことはないのですが、ある一定以上の規模になった際にコ
飲食店経営してないときだけアホになる個人開発 - データで見る世界
個人開発、やってまっか？ まいど！個人開発の調子はどうでっか？ え？個人開発してない？なんで？ 令和は個人開発の時代でっしゃろ？それやのに個人開発してないっちゅうのは、ちょっと聞き捨てなりまへんな もしかしたらあんさんは個人開発のおもろさを知らんってことやろか？ カーッ！！ ほんまかいな。ビックリ仰天やわ。まぁちょうどええわ。ほなワイが今から教えたるさかいな。よう聞いときや。この話が終わるころにはあんさんも個人開発しとーてしとーてたまらんくなるはずやで まずな、人間っちゅうもんはやな、消費だけじゃ満足感が得られん生き物なんよ。テレビやらYouTubeやらゲームやら、いろいろおもろいもんあるやろ。それは楽しんだらええよ。ワイも好きやで でもな、それはどこまでいっても消費やねん 他の誰かが作ったものを楽しむのは消費やねん。人間、それだけじゃあかんで。ほんまにおもろいのはな、生産や 生産っちゅう
東京都初のアジャイル型開発はいかにして導入され、実践されたか – 調達、スクラムの工夫、展望を聞いた - Agile Journey
「初！都庁職員、アジャイル型開発に参加する」 東京都デジタルサービス局デジタルサービス推進部の公式note（2023年1月公開）には、かつて“試みたことのない開発手法”であったアジャイル型開発を東京都が採り入れ、複数のソフトウェアを開発した経緯が綴られています。 これまでAgile Journeyでは、さまざまな組織、企業のアジャイル導入事例を紹介してきましたが、それぞれの組織がそれぞれのモチベーションを持ち、課題に向き合いながら、導入に取り組んできました。では、それが自治体の場合では？ 東京都がアジャイル型開発を導入し、運用していくための動機、準備、事業者との契約の方法、そして実践のありようを、東京都デジタルサービス局の石川秀之さん、下家昌美さんに聞きました。 コロナ禍で浮き彫りになった、「迅速」の重要性 「システムをアジャイル型開発で作ってみませんか」メールで呼びかけ、アジャイル型開発
受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入5000社に行くまでの振り返り - ヴェルク - IT起業の記録
2024年1月9日にboardの有料登録社数が5000社を突破したので振り返りです。 boardの正式リリースは2014年8月20日なので、約9年半ほどで、推移はこんな感じでした。 ＊「社数は累計ですか？」と聞かれることがよくあるのですが、累計ではなくその時点のアクティブな数です。 1000社刻みで定点観測的に書いているので、過去の記事も貼っておきます。 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入1000社に行くまでの経営・受託とのバランス（BPStudy発表時の補足） 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入2000社に行くまでの振り返り 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入3000社に行くまでの振り返り 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入4000社に行くまでの振り返り boardとは 見積書・請求書
ソフトウェアに関わる人が知っておくといいかもしれない法則10個
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション）」という興味深いポストをX（旧Twitter）で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション） コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
「Honoはあくまでオープンソースプロダクト」開発者でコントリビューターの私が会社員になった理由 - Findy Engineer Lab
▲ YAPC::Asia Tokyo 2013でベストトーク賞1位を獲得し表彰される和田裕介さん（写真提供：Japan Perl Association） エッジコンピューティング環境に適したWebフレームワークとして注目を集める「Hono」の開発者として知られる和田裕介（@yusukebe）さん。大学院卒業後に就職の道を選ばず起業し、その後は17年にわたりフリーランスのエンジニアとして活躍してきましたが、2023年4月に初めて就職しました。 世界最大級のCDN（Contents Delivery Network）プラットフォームを提供するCloudflareが「Hono」に注目し、和田さんをスカウトしたことがきっかけです。Cloudflareに入社した和田さんはサーバレス環境「Cloudflare Workers」上での開発者体験（Developer Experience）の向上を職務と
野良社内ツールと開発生産性、プラットフォーム・エンジニアリング - Runner in the High
よくある野良の社内ツールは、開発生産性を向上させるための手段としてスポットで生まれることが多い。 たとえば、定期的に依頼されて手作業でキックしているバッチ処理を誰かがAPI化したり、それがCLIで実行できるようになったり、あるいは不特定多数の人々が手でやっている作業が有志で自動化されツールになるなど。そして社内の口コミや告知で伝搬され、使われていく。 出来の良い社内ツールは、野良だとしても開発チームが普段の開発プロセスのなかで意識したくない複雑性や実装の詳細をうまく抽象化し、認知負荷を下げる役割を果たしている。見方を変えれば、社内ツールはチーム・トポロジー*1でいうところのX-as-a-serviceインタラクション・モードの具象化のひとつだと言える。開発チームと社内ツールを開発する人間を社内ツールがインターフェイスとなって接続している。広い目線で見ると、これはプラットフォーム・エンジニア
古いコードに向き合い、未来に何を遺すか - たきざわの日記
ここ数年は仕事で「最後のコミットが10年前」みたいなコードを触ることが多く、古いコードに対してどのように向き合うかと同時に、 コードを長く維持していく上でどのいう振る舞いをするとよいかを考えることが多くなった。 年末なので、自分が特に最近意識していることをを紹介する。 要らないコードはさっさと消す 年末といえば大掃除、ということで年末らしい話題。普段仕事をしている中で「これは使われてなさそうだけど、消していいかわからないな」とか、「これは今は使わなくなったけど、残しておいたらあとで使うかもしれないし残しておく」という場面がある。 消すためにもちょっと調べないといけないし、消すより残しておいたほうが安全だし、面倒なので残しておくか・・・ということをやったことはないだろうか。僕はある。 しかし必要のないコードなのであればさっさと消したほうがよい。現代だと大抵gitなりなんなりで管理されているの
プロダクト開発はなぜ直観に反するのか - 弁護士ドットコム株式会社 Creators’ blog
この記事は、弁護士ドットコム Advent Calendar 2023の25日目の記事です。 前日は tsuchiya さんの「ログや例外についてレビューや実装時に意識していること」でした。 はじめに: 人と成りては童子のことを棄てたり インターネットの海には、不幸な開発プロジェクトの話が溢れています。例えば「とにかく言われた通りに作ればいいんだ」「スケジュールにコミットしろ」「遅れは徹夜で取り戻せ」「障害を起こしたら減給だ」など*1。 プロダクト開発に携わる人であれば、こうしたやり方が無意味どころか逆効果であることはご存知でしょうか。では、なぜこうしたやり方が提唱されてしまうのでしょうか。 それは、旧来のビジネスの常識*2に照らせば、ある意味でまっとうなやり方だからです。問題は、プロダクト開発においてはビジネスの常識が通じないことにあります。 (加えて、にも関わらず旧来の常識が押し通され
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ひろゆきがRubyの父・まつもとゆきひろに聞く「弟子募集しないんですか？」 - エンジニアtype | 転職type
サービスを軌道に乗せるまで一人でやったすべてのこと
