個人開発を7年以上続けて分かった技術選択のコツ
技術革新に適応しようとするイヌさんInkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR最初はとにかく最速でリリースする事を最優先する迷ったら「ときめく方」を選べ程よいところで切り上げて開発を進める使っているモジュールがdeprecatedされるなんてザラだと覚悟する古いから悪いとは限らないシンプルにしていく老舗から継続の秘訣を学ぶ運ゲー要素は排除しきれない最初はとにかく最速でリリースする事を目標に技術選定する開発計画とビジネス計画は切っても切り離せな
12のソフトウェア・アーキテクチャの落とし穴とその避け方
これは、多数派が支配すべきだという意味ではない。委員会によって設計されたアーキテクチャは、肥大化し、焦点が定まらない傾向がある。私たちの経験では、理想的なバランスとは、多様な経験と視点を持つ数人の仲間が、より良い情報に基づいた決定を下すために、主張に異議を唱えることである。 再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。 コード、コンポーネント、設計、あるいはコンフィギュレーションの再利用は、最初は良いアイディアのように聞こえる。経営陣は、再利用によってコストが削減され、納期が短縮され、品質が向上すると信じて、このコンセプトを推進したがる。チームは、MVPをより早く提供するために既存のアプリケーションの大部分を再利用することを決定するかもしれないし、かなり成功した製品を提供するために作成された既存のアーキテクチャを再利用す
【個人開発】爆速で書籍管理システムを作って大幅な時間削減をした - Qiita
はじめに こんにちは！！@Sicut_studyです！ 今回は個人開発で「書籍管理システムYomuYomu」を作成したので紹介したいと思います。 サービスでやりたかったことがシンプルでなおかつユーザーの作業時間を大きく削減することができたというところから 個人開発に挑戦してみたいけど何を作ればよいかわからない このような方にとてもおすすめのサービスになっています。 私も実装していて「この内容はプログラミングコーチングJISOUの中でも1つの教材として今後使っていこう」と思うくらい良い題材でした 書籍管理システムYomuYomuとは 書籍管理システムYomuYomuは購入した本を登録できる簡単なアプリです 以下の機能が利用できます 1. 登録書籍一覧 登録した書籍を50音順で見ることができます 詳細検索を利用することで「あ行」などで書籍を絞ることができます 2. 書籍自動登録 書籍を登録する
チーム・組織デザインの良し悪しはプロダクト開発フローの効率を左右する｜mtx2s
依頼、調整、合意、承認、etc. こういったコミュニケーションがチーム境界を越えて頻発すると、ソフトウェアプロダクト開発のフローは遅々として進まなくなります。いずれも、機能追加や機能改善を進める上でのクリティカルパスを引き伸ばす要因を生み出すからです。 機能追加や機能改善といったひとつひとつの開発は、アイデアを生み出し、それを価値に変えるまでのフローです。フローが進む過程で、組織内の様々な人の手で、様々なタスクが実行されます。その全てを1つのチームで完結することは、プロダクトの規模が大きくなるほど困難になり、より多くの人々が関わるようになります。そこに、チーム境界を越えた「依頼、調整、合意、承認」といったコミュニケーションが発生するのです。 開発フローのクリティカルパスを悪化させるこのようなコミュニケーションの頻度をどれだけ減らせるか。組織設計、チーム設計で最も注視すべき観点の1つは、そこ
実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
設計・ソフトウェアアーキテクチャを学べるGitHubリポジトリ 16選
はじめに 今回の記事では、設計やソフトウェアアーキテクチャを学べるGitHubリポジトリを16個紹介する。 対象とする読者 設計やソフトウェアアーキテクチャに興味関心があるエンジニア GitHubをエンジニアリングの情報収集に活用したいエンジニア タイトルで気になった人 Architectural Patterns システムの基本的な構成を理解するためのパターンやテンプレートを提供している。これらのパターンを学ぶことで、システムの構造やコンポーネントの関連性、相互作用を理解できる。これが開発者にシステムをより効率的かつ効果的に設計・実装する能力をもたらす。 Design Patterns for Humans 設計パターンを人間が理解しやすい形で説明している。デザインパターンは特定の問題に対して再利用可能なソリューションを提供する。これによって、開発者はより効率的にコードを記述でき、メンテ
エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく｜mtx2s
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
開発組織の貢献は売上として直接語るのはやはり無理があるのではないかという考察
先日サーバントワークスさんが公開した 計測によるスクラムチームのパフォーマンス向上 を読んで、 以前自分が書いた 開発の改善はKPIに翻訳しなければいけないのか をもうちょっと言語化することができそうだったのでメモ。 TL;DR 結論としては、開発の改善はKPIに翻訳しなければいけないのか でも書いた通り 開発組織はビジネスの実現を担っている職能であり、理想的には 「永久に持続性がある状態」で 「0秒 でしかも 並列数を無限」 でモノが実現されて、「不具合やパフォーマンスの劣化は 0」 であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない から考え方は変わってないが、改めて整理して 開発組織は、Ability to Innovate と Time to Market 2つのケイ
要件定義失敗と改善の歴史 ~ その時、要求・ユーザーストーリーをどうまとめ、どう改善してきたか ~ - 株式会社ヘンリー エンジニアブログ
こんにちは。ヘンリーCEOの逆瀬川です。 開発する上で、難しい部分の一つである要件定義。 最近、社内では「要求仕様」と呼ばれるようになり、要求仕様化のプロセスとフォーマットの改善に取り組んでいます。しかし、3年間にわたって苦労し、失敗と改善を繰り返してきた歴史があります。 本ブログでは、主にプロセスとフォーマットの失敗について触れますので、詳細は割愛します。「ココもっと深く知りたい！」という方は、ぜひカジュアルにお話しましょう。その場で深堀りいただいた内容を元に、更にブログで考察していきたいと思います。 では、過去私たちが体験した5つの時代と今後訪れるだろう要求開発黄金時代についてお話しましょう。 ユースケースで仕様漏れた時代 要求導入混沌時代 要求を全員で書くぞ時代 プロダクト要求と仕様を分けて書き始めた時代 CSと連携して速度が上がり始めた夜明け前 将来訪れるだろう要求開発黄金時代へ
10年弱エンジニアをやってきてわかった、あなたの開発効率を倍にしてくれるツール37選｜苦しんでプログラミングを学んだ柴犬（くるしば）
※こちらの記事がはてブの総合人気エントリ、noteの「先週もっとも多くよまれた記事」「先週もっともスキされた記事」に入りました！ こんにちは。 苦しんでプログラミングを学んだ柴犬こと、くるしばです。 元々コンサルタントの仕事をしていましたが、独学でプログラミングを学習し、Webサービスを作って起業しました。 その後個人で開発したサービスを売却したり、また別のIT系の会社を創業したりしています。 今年の8月から下記のTwitterにてプログラミング学習に関して発信し始め、ありがたいことに6000人以上の方々にフォローして頂きました。 プログラミング初心者に絶対覚えてほしい、ググる時の効率が10倍上がるコツ pic.twitter.com/hK1ZhNavwh — 苦しんでプログラミングを学んだ柴犬（くるしば） (@shiba_program) September 13, 2022
バッチ処理 プラクティス
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。
今年できたチームの生産性を向上させたプラクティスの紹介 / Kaigi on Rails 2022
sdevtalks.org開発報告 / reporting that sdevtalks.org was launched
月5ドルの自作サービスで最初の500人を集めるまでにやったこと
顧客はいったん継続課金を開始すると、特に大きな問題に遭遇しない限り概ね何ヶ月も継続して利用する傾向があります。最近のチャーンレート(解約率)は2~3%で、驚くほど低いものでした。ターゲット層である開発者はこだわりが強いため、彼らは熱心に他のMarkdownエディタを何年もかけていろいろ試しています。そして僕のアプリを最終的に選択しました。だからそう簡単に他に移ったり辞めないのでしょう。ちょうど彼のように： Your application is a life changer. I’ve tried numerous markdown based applications over the years and I’m so pleased to finally find a keeper! Awesome work! — James Lilliott しかし彼らは常によりよいツールを探し求め
ロックスターになれなくてもいい。ソフトウェア開発に長く携わる技術「メタエンジニアリング」とは - Findy Engineer Lab
Developers Summit 2020に登壇 こんにちは！ 塩谷啓（@kwappa）と申します。ヘイ株式会社（2022年10月よりSTORES 株式会社）のエンジニアリング室という部署で、マネージャーをしています。 エンジニアとしてのキャリアを家庭用ゲームソフトの開発からスタートし、SESや受託開発を経て、いくつかのWebサービスの会社で働いてきました。2011年ごろから、エンジニアリングと並行して採用の仕事も担当するようになり、現在ではマネジメントとメタエンジニアリングを主な業務領域としています。 並の腕前のエンジニアが発見した新しい適性 ごく平凡なエンジニアであることの焦燥感 突然の採用担当 メタエンジニアリングのめざめ 技術広報・採用・組織開発でそれぞれ何をするのか？ 技術広報 ─ アウトプットを実現して社外から信頼を得る 採用 ─ 公開情報のメンテナンスと選考プロセスの整備
求人票の作り方: QAリードを実例に5ステップのフレームワークと中間成果物を公開します - MonotaRO Tech Blog
こんにちは、鈴木です。 求人票の作成を経験しました。実際に公開した求人票を実例として、どのように考え、どのようなプロセスで、どのような中間成果物を生み出しながら取り組んだのか。具体的な内容を共有します。 「先に知っておきたかった！」と思うものや、検索しても見つからなかったものなど、多くの知見を得ることができました。 それらを公開することで、これから求人票の作成に関わる人のお役に立てれば幸いです。 QAリード採用はじめました はじまりは兄弟会社の組織図 求人票を書こう! ってどうすれば!? 求人票作成のフレームワーク 1. 現在を書き出す 1.1. 思っていることを書き出す 1.2. 現在使っているモノを書き出す 1.3. 現在おこなっているコトを書き出す 2. 未来を書き出す 2.1. 将来おこなっているコトを書き出す 2.2. 将来使っているモノを書き出す 3. その職種が必要な理由を書
エンジニアの技術土台となる知識を得るための本の紹介 - Qiita
はじめに の参加記事になります。 個別の技術ではなく、エンジニアの成長のステップで読むと良い本の紹介 エンジニアとして成長していくときに、個々の技術を深く理解し使いこなしていくことは必要ですが、個々の技術を選ぶときにもどんな成長ステップがあるかを理解することも重要です。 実装をするという範囲をエンジニアの中心なのはありますが、実装以外の部分を理解するとその技術が最大限に活きるのかを理解するには周辺についても理解していく必要があります。そこで、実装を始める前の構造のパターン、実装を進めるエンジニアの環境などを知ることで、もっと効率的な開発が出来るようになるのかを理解していきたいけると良いと考えています。 この記事では私が経験した中でより良いWebシステムを作るという観点に立ったときに、広く理解しておくと良いと感じた本を紹介します。 これからエンジニアリングでどのような勉強をすればよいかを考え
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
現代的システム開発概論
要件定義とはそもそも何か
サクッとAWS入門＋モダン開発の基本
インフラエンジニアBooks 30分でわかる「Dockerコンテナ開発・環境構築の基本」
