はじめに
この記事は、社会人1〜2年目のエンジニアが「次に何を読めばいいか」で迷わないための、学習順リンク集です(厳選101本)。
社会人1年目が終わる頃、ブラウザのブックマークは310個に膨れ上がっていました。「これ後で読む」「これは絶対使う」と保存し続けた結果です。でも読み返すと、リンク切れ・質の低い記事・テーマから外れたもの・似た内容の重複——実際に繰り返し参照したのは、ほんのひとにぎりでした。
そこで Claude(生成AI)の力も借りて全部読み返し、死んでいるリンクや低品質なもの・脱線を除外して、本当に役立つものだけを学ぶ順に並べ直しました。最後に息抜きの番外編も少しだけ用意しています。
この記事が約束すること
- 実際に読み返して、リンク切れ・低品質・脱線を除いた本物だけを載せています
- 上から「学ぶ順」に並べているので、先頭から読んでいけます
- 各リンクに「なぜ勧めるか」を一言添えています
約束しないこと
- 全分野を網羅するカタログではありません(抜けがある分野は意図的に外しています)
- 各技術の詳しい解説はリンク先に任せています(ここは地図です)
- 普遍的な正解ではなく、1年目の自分に効いた主観的なセレクトです
この記事の使い方
全部は読まなくていい。最短コースは「★必読の13本」だけ
101本は辞書です。全部読もうとしなくていい。まず各節の ★必読(全10節で計13本) だけ追えば、1年目に必要な背骨は通ります。もっと絞るなら、すぐ下の「まず3本」から。無印は余裕が出てから拾えば十分です。上から順に読む必要もありません——いま困っている節だけ開いてOKです。
厳選の数字:集めた310個から、死リンク・低品質・テーマ外を外し、似た記事は代表1本に集約して101本に絞りました(本編96本+番外5本)。リンクの生存チェックや、各記事を実際に開いての絞り込みには Claude(Claude Code)も活用しています。
記号の意味
- ★必読:その節でまず読む1〜2本。迷ったらここだけ読めばOKです
- 無印:おすすめ。余裕があれば読んで損はないものだけを残しています
- 🔰超入門:前提知識ゼロでも読めます。初日〜1か月目向けです
迷ったら、まずこの3本
掲載リンクはすべて2026-06-18時点で生存を確認済みです。なお、関連する節には筆者自身の記事も2本だけ混ぜています((筆者) と表記。厳選101本とは別枠です)。
目次
- 心構え・原則
- 読みやすいコードを書く
- 設計の考え方(心構え / デザインパターン / 要件定義)
- アーキテクチャとDDD
- リファクタリングと技術的負債
- テスト
- Gitとコードレビュー(Git操作 / コードレビュー)
- チーム・仕事術・伝え方
- AI時代の開発
- 土台になる教養と学習リソース
1. 心構え・原則
技術の話に入る前に、まずここを読んでほしいです。「どう考えるか・どう動くか」の話なので、1年目のどのタイミングでも効きます。SOLID原則や達人プログラマーといった古典から、メンタル面の話まで。
-
プログラマが知るべき 97 のこと ★必読
→ 心構え・コードの質・チームとの関わり方まで、97の短いエッセイ。読んだら、背筋が伸びた。 -
プログラマーのための原則(2 万字)
→ SOLIDやDRYなど主要原則を2万字で体系整理。設計の全体地図が頭に入る。 -
何かのときにすっと出したい、プログラミングに関する法則・原則一覧
→ 法則・原則の早見表。名前を知ることで、チームの会話にひと言添えやすくなる。 -
プログラマーの三大美徳 - 怠惰、短気、傲慢
→ 三大美徳(怠惰・短気・傲慢)を組織・チーム運営に当てはめる短編集。「怠惰」の章だけでも読む価値がある。 -
イラストで理解するSOLID原則 🔰超入門
→ SOLID原則をイラストで図解。文章だと伝わりにくい概念が視覚的につかめる。 -
プログラマの心の健康(抜粋) ★必読
→ 「完璧にやろうとしない」「ひとりで抱え込まない」——プログラマの働き方と心の持ち方を短い章で扱った本の抜粋(無料)。しんどくなる前に読んでほしい。 -
達人プログラマーまとめ
→ 名著『達人プログラマー』の要点まとめ。読む前にエッセンスを先取りできる。 -
元ヤフーエンジニア社長が考える、新人エンジニアの成長を阻害する悪習5選
→ 成長を止める悪習5選を早めに知っておくと、やりがちな罠を事前に避けられる。 -
実践的思考入門
→ 職場の対人・組織スキルを体系整理した無料本。思考術より人間関係の土台に効く。 -
「できない」は「まだイメージできていないだけ」— フリーレンに学ぶ個人開発の思考術(筆者)
→ 手前味噌ですが、「できない」を「手順がまだ見えていないだけ」と捉え直す話で、今も自分の指針にしています。
2. 読みやすいコードを書く
とはいえ、原則を頭に入れただけではコードは変わらない。「動くものは書けるのに、レビューで毎回命名を直される」——1年目に最初に突き当たる壁がここです。命名・依存関係・メンテナンス性を中心に、手元のコードを見直すきっかけになれば。
-
読みやすいコードを書く ★必読
→ コードレビューで毎回命名を直されていた頃に読んで、やっと何を直されているかわかった。 -
後輩「具体じゃなくて抽象に依存してもらえませんか?」〜命名編〜
→ フロントエンドの例で「抽象に依存」と命名を会話形式で解説。テンポよく読み進められる。 -
【若手プログラマー向け】メンテナンス性の高いコードを書くための心得
→ 若手向けにメンテしやすいコードの心得が一通りそろう。今日のコードにそのまま当てはまる。 -
(あなたの周りでも見かけるかもしれない)インスタンス変数の間違った使い方
→ Rubyの例でインスタンス変数の誤用パターンを図解(2014年初出・原則は今も有効)。 -
文脈と名前で設計をマスターする本
→ 命名と設計のつながりを学べる無料本。「名前の悩み」は設計の問題だと気づかされる。 -
保存版!プログラミング英単語リファレンス大全
→ 命名で迷ったとき辞書代わりになる。プログラミング英単語を網羅した実用リファレンス。 -
プログラマのための英語表現
→ GitHub/PRで使う英語表現集(OSS実務向け)。命名や読解より、実務コミュニケーションに効く。 -
命名レビューでトラウマ植え付けられてそうな新人に贈る処方箋
→ check/data/notなどNGになりがちな命名を具体例で修正。レビューで指摘される前に読める。
3. 設計の考え方
自分が「なぜ設計が必要か」を実感したのは、数か月後に自分の書いたコードを直そうとして手が止まったときでした。この節はその「動けばいいから抜け出す」一歩のために作りました。設計の基本→パターン→要件定義の順で置いた。上流は後でいいと思ったので。
設計の心構え
-
クラスや関数を設計する時に何を考えればいいのか 🔰超入門
→ 凝集度・結合度をKotlin例で学ぶ入門。設計の言葉と実装の感覚がセットでつかめる。 -
『動けば別に良くない?』と言っていた二年前の自分にシステム設計の話をしてみる ★必読
→ 「動けばいい」から設計へ踏み出す過程を追体験できる。設計を学ぶ動機がここで生まれる。 -
ソフトウェアアーキテクチャの基礎:凝集度からコンポーネント分類まで
→ 凝集度やコンポーネント分類など設計の土台用語を整理。中〜上級者向けの体系整理。 -
抽象クラスによる汎化のすごさを理解してみる
→ 抽象クラスの汎化を具体例で解説。継承をどこで使うべきか、判断の感覚がつかめる。 -
不適切な抽象化を防ぐ|開発メモ(プログラミング編)
→ Zenn書籍の一節(第4章への直リンク)。過剰抽象化を避ける判断軸がつかめる。 -
【感想】良いコード/悪いコードで学ぶ設計入門
→ 設計入門本の感想まとめ。購入前に何が学べるかイメージが湧く。 -
SOLID原則完全に理解した!になるための本 ★必読
→ SOLID原則を腹落ちまで噛み砕いた体系本。レビューで先輩が使っていた言葉の意味が、やっとここで揃った。 -
ソースコードは設計書であり、コーディングは設計作業である
→ コードこそ設計書という論を展開する。コーディングへの向き合い方が変わる。 -
リレーショナルデータベース設計の完全ガイド
→ RDB設計の完全ガイド。正規化やテーブル設計の基礎を通しで把握できる。
デザインパターン
-
デザインパターン一覧 [23種類]
→ GoF23種を一覧で俯瞰できる。パターンの名前と使いどころの全体像がまず頭に入る。 -
Java言語で学ぶデザインパターン入門
→ GoFパターン入門の定番書から、TemplateMethod/Iterator/FacadeをJavaコードで追える解説。 -
コードを複雑化させないために意識したいパターン集
→ 複雑さを避けるパターン集。実コードを通じて設計のさじ加減を肌で覚えられる。 -
フロントエンドのデザインパターン
→ JS/React向けの18パターンを無料で読める邦訳書籍。フロントエンド実践に直結する内容。 -
ITエンジニアはSQLアンチパターンを読むべし! 軽いまとめ
→ 個人ブログ・SQLアンチパターンの要点まとめ。概要把握に使い、詳細は原書で補う運用で。
要件定義
-
要件定義ガイド
→ 要件定義のやり方を体系的にまとめた本。上流工程の最初の一歩がここから踏み出せる。 -
ユーザのための要件定義ガイド第2版2刷
→ IPA公式PDF・第2版の要件定義ガイド。上流工程の古典的な考え方を無料で押さえられる。
4. アーキテクチャとDDD
設計の考え方が身についてくると、今度は「クラス単体ではなくシステム全体をどう組むか」という問いが浮かんできます。アーキテクチャの基本的な考え方から、技術選定の指針、DDDのエッセンスまで。1年目の終わりに読んで「そういう世界があるんだ」とわかれば十分です。
-
ソフトウェアアーキテクトが知るべき 97 のこと
→ 設計の勘所が97個。アーキテクチャの考え方を幅広く押さえられる無料書籍。 -
[解説] なぜ、ソフトウェアアーキテクチャは重要なのか? 🔰超入門
→ アーキテクチャがなぜ必要かを基本から解説。「設計って何のため?」が解消される超入門。 -
私のよく使うソフトウェアアーキテクチャの雛型
→ TypeScriptでヘキサゴナル+CQRS構成の具体例。設計経験が出てきてから読むと刺さる。 -
技術選定/アーキテクチャ設計で後悔しないためのガイドライン ★必読
→ 技術選定やアーキ設計で後悔しない指針が言語化されている。個人開発でも繰り返し開いてる。 -
ドメイン駆動設計完全に理解した
→ DDDの全体像をつかむ入門に適した読み物。タイトルどおりのトーンで読みやすく、入門として取り組みやすい。 -
ドメインモデルとは(「現場で役立つシステム設計の原則」より)
→ 「現場で役立つシステム設計の原則」からドメインモデルを解説した節。DDDの肝をコンパクトに押さえられる。 -
【DDD入門】TypeScript × ドメイン駆動設計ハンズオン
→ TypeScriptで手を動かすDDDハンズオン本。読むより手を動かした方が早い、という人向け。 -
「ソフトウェアアーキテクチャの基礎」を読む Part.1
→ アーキテクチャスタイルや品質特性を扱う技術書の第1部読書メモ(個人ブログ)。概要把握の足がかりとして使える。
5. リファクタリングと技術的負債
でも、設計の型を学んでも現実のコードはその通りにならない。書いたコードは必ず老います。リファクタリングとは「きれいにする行為」ではなく「変化し続けるコードを扱う技術」だと気づいたとき、向き合い方が変わりました。やりすぎてかえって壊す——そういう失敗例から、負債との付き合い方まで。
-
リファクタリング自爆奥義集 ★必読
→ 良かれと思ったリファクタが逆効果になる失敗例集。やらかすパターンを先に知れる。 -
実践 よくないコードに立ち向かう整理術
→ 独自の色付け手法でコードの問題を可視化する無料本。手法はユニークで、慣れるまで少し時間がかかる。 -
技術的負債とどうやって戦うか
→ 技術的負債とどう向き合うかを具体的に論じる。「なぜ負債が生まれるか」から「どう返すか」まで順を追って解説している。 -
保守性の高いソフトウェア開発のTips集
→ 保守性を上げるTipsが体系的にまとまっている。負債を作らない設計の感覚をつかめる。 -
レガシープロジェクトを引き継いだ時、最初にするべき7つのこと
→ レガシーを引き継いだとき何から手をつけるか、優先順位の型が見えてくる。
よく見つけたね!ここには何もないよ!
6. テスト
壊さず直すには、壊れていないと確かめる手段が要ります。テストへの向き合い方が変わったのは、テストを書いたことで設計のまずさに気づいた日でした。何をテストすべきかの方針から、テストしやすいコードの書き方まで。
-
【初心者向け】テストコードの方針を考える ★必読
→ 何をテストすべきかを初心者向けに整理(Ruby/Rails向け・考え方は汎用)。方針の軸が立つ。 -
テストが書きやすいコードを書く
→ テストしやすいコードが良い設計だと気づかされる。設計とテストの橋渡しになる記事。 -
ソフトウェアテスト技法まとめ【初心者〜実務向け】
→ 境界値や同値分割などテスト技法を一通り網羅。初心者が実務で使う技法の全容が見渡せる。 -
テストケースに必要な項目
→ QA管理表の項目設計の一例(特定チームのメモのため汎用性は限定的)。そのまま使うより参考・アレンジ用として。 -
実務でしか身につかないソフトウェア品質開発の話
→ 実務でしか身につかない品質感覚を先取りできる本。テスト観の土台が築かれる。
7. Gitとコードレビュー
この節だけは「学ぶ順」の例外です。GitとコードレビューはDay1から使う道具なので、7番目に並んでいますが、操作に慣れていない人がいつでも戻ってくる”型”の置き場として読んでください(コードレビューの観点は、設計を学んだ後だとより深く刺さります)。Gitを怖いと感じるのは誰もが通る道ですが、型を覚えれば迷わなくなります。まずは操作系の記事で型を固めてください。コードレビューの節は、出す前・受ける前の準備として手元に置くと役立ちます。
Git操作・運用
-
Git初心者の「なんやねん!」を解消! 現場で使える知識まとめ
→ .gitignoreや環境変数管理など初歩的な疑問に絞った入門書(Git全般の体系本ではない)。 -
レアゾン・ホールディングス 2024新卒エンジニアGit研修 - Gitを恐れない
→ 新卒向けGit研修の教材。「Gitが怖い」から「怖くない」へのメンタル転換ができる。 -
業務でよく使うGitコマンド10選とその使いどころ🔰初心者向け🔰 🔰超入門
→ 業務でよく使うGitコマンド10選と使いどころ。手元に置いて都度参照する実用リファレンス。 -
Gitを用いたチーム開発で意識すること
→ チーム開発でGitをどう運用するかの作法が一通り把握できる。 -
Pull Requestのマージ方法にはいくつか種類があるんだぜ
→ PRのマージ方法ごとの違いを解説。レビュー後の操作で何を選ぶか判断できるようになる。 -
【業務効率化】もうやめましょうよ〜コミットメッセージ考えるのは
→ IntelliJ AI Assistantでコミットメッセージを自動生成する方法(JetBrains IDE利用者向け)。 -
【GitHub Actions 入門】GitHub Actions について基礎から徹底解説
→ GitHub Actionsを基礎から体系的に学べる本。CIへの入口として読みやすい。 -
よく使うGitコマンド集
→ 日常のGitコマンドをまとめた早見表(2022年以降未更新)。手元に置いておける。
コードレビュー
-
コードレビュー依頼前のセルフチェックリスト ★必読
→ PR出す前にこれを通すようにしてから、先輩からの指摘の往復が目に見えて減った。 -
知っておきたいコードレビューで指摘されがちなポイント14選
→ レビュー指摘の頻出14選を初心者向けに解説。事前に読むとよくある落とし穴を避けられる。 -
メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆に爆速で成長した話
→ 厳しめのレビュー施策がなぜ成長につながるかを解説。レビュー文化への向き合い方が変わる。
8. チーム・仕事術・伝え方
気づいたのは、同じチームでも評価が分かれるのはコードの質より「伝える力」のほうだった、ということです。工数見積もり・結論ファーストの説明・ドキュメント作成・リモートコミュニケーション——どれも「後で学べばいい」と後回しにしやすいのですが、早く身につけるほど得をします。この節は1年目の早い段階で先に戻ってきても損はありません。
-
伝わる説明を書くスキル ★必読
→ 伝わる説明文を書くコツがまとまっている。ドキュメントにも報連相にもそのまま効く。 -
初心者エンジニアに最初に読んでほしい工数見積もりの話 ★必読
→ 工数見積もりの考え方を1年目向けに丁寧に解説。見積もりで詰まる前に読んでおきたい。 -
面接して気づいた。「調べない人」に社内SEは任せづらいという話
→ 面接官視点で「調べて考えて動く」自走力の重要性を説く。社内SE志望者にも参考になる。 -
「結局何が言いたいの?」私が時間泥棒を卒業した方法
→ 結論ファーストの基本を実例で解説。「結局何が言いたいの」を言われなくなるための処方箋。 -
新卒2年目の考える8つの仕事術
→ ゲームクリエイターの知見を仕事術へ応用した2年目視点の8実践。等身大で真似しやすい。 -
タスク管理を噛み砕く
→ タスク管理の考え方を基礎から噛み砕いた無料本。段取りの立て方が整理できる。 -
タスクばらし入門
→ 作業を小さく割る技術の本。ばらすだけで見積もりも着手もしやすくなる理由がわかる。 -
フルリモートで相手に気持ちよく仕事をしてもらうためのコツあれこれ
→ フルリモートで相手が気持ちよく動いてくれる伝え方のコツ集。テキスト文化の現場に刺さる。 -
成功する実践的モブプログラミング
→ モブプロの実践ノウハウが具体的。チーム開発の進め方を試したいときの参考になる。 -
エンジニアなら知っておきたいトラブルシューティングのセオリー
→ トラブルシューティングの型を解説。障害に直面する前に動き方の骨格が手に入る。 -
ドキュメント作成時のあるあるアンチパターン20
→ 文書のアンチパターン20連発。書く前に読むと、やりがちな失敗を未然に断ち切れる。 -
Markdown記法 チートシート
→ Markdown記法の定番チートシート。書き始めは手元に置いて都度参照する運用で十分。 -
ダメな発表はなぜ聞いていてつらいのか?
→ 発表のアンチパターン3つを解剖し改善策を提示。登壇前に読むと失敗の型を先に知れる。
9. AI時代の開発
AIがコードを書く時代に、エンジニアは何を学べばいいのか——1年目にこの問いを持つのは当然です。技術と伝え方の土台が固まったうえで、いまの時代特有のこの問いと向き合ってほしい。「基礎スキルはむしろ大事になる」という視点を軸に、プロンプトエンジニアリングの入門からAIと設計の関係まで。
なお、この節は変化がとても速い領域です。リンク先の情報は本稿作成時点(2026年6月)のものなので、最新の状況もあわせて確認してください。
-
AI時代はプログラミングスキルがさらに重要になる ★必読
→ AI時代でも基礎スキルが効くという論考。学習の優先順位を定める根拠になる。 -
AIが便利になって焦らないといけないの、実はプログラマーじゃない説
→ AIで焦るべきは誰かを冷静に整理した論考。視野を広げるための読み物として有用。 -
MCPを超理解する
→ MCPの戦略的意義を概念寄りに解説。実装より「なぜMCPか」の直感が先に得られる。 -
サクッと始めるプロンプトエンジニアリング
→ LangChainでプロンプト実装を体系的に学べる無料本。コードを動かしながら覚える構成。 -
ITエンジニアのためのプロンプトエンジニアリング
→ エンジニア向けに絞ったプロンプト本。実務に近い切り口で実際の業務に持ち込みやすい。 -
エンジニアにも知って欲しいChatGPT基本テクニック
→ ChatGPTの基本テクをエンジニア視点でまとめた記事。読んだ当日から試せる内容が揃う。 -
AIと進めるテスト設計・リファクタリングの実践
→ ReactとAIツールを組み合わせた実践例(個人体験記)。ワークフローを整えるヒントが得られる。 -
生成AIの時代にレイヤードアーキテクチャは古いかなと思った
→ AI時代に設計がどう変わるかを問う考察。アーキテクチャへの固定観念を揺さぶられる。 -
「AIがあるんだからもっと安く早く作れるでしょ?」と言われた時に読む記事
→ 「AIで安く早く」という誤解に論拠で反論する記事。非エンジニアとの会話で論点が整理できる。 -
【Claude Code】小手先で最強テクニック8選(筆者)
→ 恐縮ですが、Claude Codeで実際に効いたテクニック8選。手元ですぐ試せます。 -
精度90%のAIで10機能作ると、全体が動く確率は35%——規模・寿命・保守コストの数学(筆者)
→ AIの精度が複数機能に積み重なると全体品質がどう落ちるかを数式で示した記事。規模感とリスクの感覚がつかめる。
10. 土台になる教養と学習リソース
最後は「どんな本・記事から学ぶか」の地図です。この記事はいずれ古くなる——だから、この地図を自分で更新し続けるための「学び方の学び方」を置く場所が必要でした。技術書の選び方リスト・数学とアルゴリズムの学び直しルート・Webの仕組みといった教養系まで——「何を学ぶか迷ったとき」に開く地図として。
-
新人プログラマに正月休み中を使って読んでみてほしい技術書をセレクトしてみた。 ★必読
→ 正月に開いて、結局このリストを元に半年分の読書計画を立てた。定番の力がある。 -
駆け出し時代の自分に読ませたかった技術書18選
→ 駆け出しに読ませたかった18冊を紹介。「何から読むか」で迷ったときの羅針盤になる。 -
東大・東大生が公開しているエンジニアが読むべき資料まとめ
→ 東大・東大生が公開した資料を集めたまとめ。学ぶべき領域の地図として参照できる。 -
【図解】Webの仕組み 🔰超入門
→ Webの仕組みを図解で解説する超入門。HTTPやサーバーの役割が視覚的に頭に入る。 -
【11万文字越え】プログラミング初心者に贈る即戦力ガイド
→ 11万字の初心者ガイド。基礎を丸ごとカバーする辞書として脇に置いておける。 -
エンジニア向け数学・統計知識総復習【50選】
→ エンジニアに効く数学・統計を50個に整理したリファレンス。土台の穴を埋めるのに使いやすい。 -
高校レベルの数学から大学の教養数学くらいまでを学び直す
→ 高校〜大学教養の数学を学び直す道筋がまとまっている。独学を始める前の地図として機能する。 -
アルゴリズムの歴史
→ アルゴリズムの歴史を辿る無料本。教養として読み物として、技術の文脈がわかって面白い。 -
アルゴリズム×数学の学び直し
→ アルゴリズムと数学を学び直すZennシリーズの入口ページ。各記事はシリーズ内で展開する。 -
個人的に超絶為になったので新人エンジニアに勧めたい記事まとめ
→ 新人に勧めたい記事のまとめ。次に読むものを探すとき、あたりをつける起点として使える。 -
こわくない関数型プログラミング
→ 関数型の考え方を怖がらずに学べる無料本。発想の引き出しが一つ増える。 -
新人研修
→ Javaスタック中心の新人研修向け無料本。最初の足場固めとして通読しやすい構成。
番外編 〜息抜き〜
技術一辺倒にならない余裕も、1年目には大事だと思っています。知識スタックからは少し外れるけれど、読んで面白かったもの・思わず笑えたものを5本だけ。
-
プロジェクト・マネジャーが知るべき 97 のこと
→ PM視点の97個。仕事の全体像を俯瞰したいときの読み物。 -
ギャル「オタクくんのVSCodeって黒くて見にくいよね」
→ ピンク系VSCodeテーマの設定例。タイトルはネタだが中身はカラーテーマ紹介。 -
PRがマージされたらマツケンサンバが流れてライトが光るシステムを作ってみた
→ PRマージでマツケンサンバが流れる工作記事。笑える息抜きの脱線ネタ。 -
会社勤めのエンジニアが開発したサービスを買い取って独立した話
→ 会社員が自作サービスを買い取って独立した実話。読み物としてテンポよく読める。 -
優秀な技術者を追い出してしまう方法
→ 優秀な技術者を追い出す組織のアンチパターン集。マネジメント視点で反面教師として読める。
おわりに
「技術的負債」の記事を最初に読んだときは、正直なんとなく読み流しただけでした。でも設計の節を一通り学んでから読み直したら、当時の自分が書いたコードの粗が具体的に浮かんで、初めてちゃんと怖くなった。同じ記事なのに、です。
量より、順番。
役に立ったと思ったら、ストック・いいねしておくと後で見返しやすくなります。
宣伝
Xアカウント:@mryocode123
普段はこんなものを作っています:
- コピペを題材にしたインクリメンタルゲーム
- なろう小説をマッチングアプリ式に探索できるアプリ
- 素数ガチャ(超大桁の素数をガチャで引いて、新発見かどうかを判定する謎アプリ)
リリースしたら、ぜひ遊んでください!
開発の進捗は X(@mryocode123)で発信しているので、よかったらフォローしてもらえると嬉しいです。
Qiitaもフォローお願いします
この Qiita では、今後も実体験にもとづいた開発者のリアルな情報を発信していく予定です。
「実際に使って効いたテクニック」を中心に、個人開発での生きた知見をシェアしていきます。
役に立ったら、フォローやこの記事へのいいねが次の記事の励みになります!