Tweet
Tweet

Slide 1

Slide 1 text

厳しさとゆるさの間で迷う人に 捧げる個人開発記 2025-02-08 mizzsugar @Pycon mini Shizuoka 2024 continue 1

Slide 2

Slide 2 text

！！注意！！ ● Pythonの話はあまりしません。 ● これからなにか作りたい人に対してハードルを下げることが目的です。 ● 開発経験がない人もターゲットに含めています。 2

Slide 3

Slide 3 text

自己紹介 ● mizzsugar(みずきと呼んでください) ○ X(Twitter): mizzsugar0425 ● 静岡県静岡市在住 ● 東京の開発会社でバックエンドエンジニア ○ BtoBWebサービスの開発 ○ 社内若手エンジニア教育プロジェクト 3

Slide 4

Slide 4 text

Lambda Scaleの紹介　 ● レシピの分量を多めまたは少なめに計算するアプリ。 ● レシピのURLと何倍かを入力すると、分量が計算される。 ○ 「人分」だけでなく様々な単位に対応できるようにするために何倍かを入力 ● 材料1つずつ計算機を使って計算する手間が省ける。　 4 https://lambda-scale.fun アイコンはこちら

Slide 5

Slide 5 text

今日伝えたいこと 人と比べない！！自分が作ったものに自信をもとう！！ ● 開発する前に、何を大事にするか優先順位 を決めておくと、開発中にトラブルが起 こった時に悩む時間が少なくなる。 ● 「無理なくやる」と「ダラダラやる」は違う。無理なくメリハリつけて開発しよう。 ● 個人開発は自分で決めることの連続。 ● どんなに小さい開発でも、決めるというプロセスの連続は大きな糧と自信になる 。 5

Slide 6

Slide 6 text

目次 ● きっかけ ● ネタ探し ● 開発 ○ 優先順位を決める ○ 何を作るか決める ○ 開発計画を立てる ○ どう作るか決める ○ 実際に作る ○ 公開する ○ 次の開発へ ● やってみての振り返り 6

Slide 7

Slide 7 text

きっかけ 2023年の年末。1年の振り返りをしている時。 仕事での立場も変わってあまり実装しなくなった +プライベートもInput重視であまりプログラミングしていないと気がつく。 →2024年はプライベートでなにか作りきりたい！と思い開発スタート🔥 7

Slide 8

Slide 8 text

ネタ探し 思いつくものを書き出す。普段からメモしておくとなおよし。 趣味の料理に関するツール 趣味のゲームに関するツール 仕事で使えそうなツール … 8

Slide 9

Slide 9 text

ネタ探し コワーキングスペースで大量に料理をよく振る舞う（10人とか） 大体のレシピは2人分や4人分 毎回各材料の分量を手計算するのがめんどくさかった →分量を自動計算してくれるアプリを作ることに決定！ 9

Slide 10

Slide 10 text

開発の流れ 10 優 先 順 位を 決 める 何を 作る か 決 める どう 作る か 決 める 公 開 する 実 際 に 作る 次 の 開 発 へ 開 発 計 画を 立 てる 今回はあくまで個人開発をリリースするまでの工程です。 仕事の開発ではテストや保守運用という工程を含みます。仕事でよくある工程については こちらの記事を読んでください。 テストもしながら

Slide 11

Slide 11 text

優先順位を決める 11 優 先 順 位 を 決 め る 何を 作る か 決 める どう 作る か 決 める 公 開 する 実 際 に 作る 次 の 開 発 へ 開 発 計 画を 立 てる

Slide 12

Slide 12 text

優先順位を決める 12 Done is better than perfect. 壮大な計画で挫折 したくない (小さくリリース) できるだけお金かけ たくない (1ヶ月1000円以内) React使って みたい 3か月くらいで公開 したい 平日は1日0-30 分しか使えない

Slide 13

Slide 13 text

優先順位を決める ● やりたいことはたくさんあるが、制約も多い。 ○ 時間やお金には限りがある。 ● あれもこれもと一気にはできないので、何を優先するか判断する指針 を作ってお く。 ○ トラブルが起きた時にどう進めるか決めるのに迷う時間が少なくなる。 ● 迷ったときのなんとなくの判断が少なくなり、メリハリができる 。 13

Slide 14

Slide 14 text

優先順位を決める 優先順位の考え方にQCDSというものがある。 14 略称 名前 要望、制約 Q Quality 品質。製品やサービスの出来栄えや性能など。 例: バグの少なさ、セキュリティ C Cost 開発にかかる費用。 例: インフラ費、人件費 D Delivery 開発にかかる時間、期限 例: リリース日、ある機能をいつまでにリリースできる状態にするか S Scope 開発する範囲 例: 開発する機能、やらないこと

Slide 15

Slide 15 text

優先順位を決める P.11で考えたことQCDSに当てはめていく。 お金とか品質とか… 15 略称 名前 要望、制約 Q Quality Done is better than perfect. C Cost できるだけお金かけたくない (1ヶ月1000円以内) D Delivery 3か月くらいで公開したい 平日は1日0-30分しか使えない S Scope 壮大な計画で挫折したくない (小さくリリース) ? その他 React.jsを使いたい

Slide 16

Slide 16 text

優先順位を決める P.11で考えたことQCDSに当てはめていく。 お金とか品質とか… 16 略称 名前 要望、制約 Q Quality Done is better than perfect. C Cost できるだけお金かけたくない (1ヶ月1000円以内) D Delivery 3か月くらいで公開したい 平日は1日0-30分しか使えない S Scope 壮大な計画で挫折したくない (小さくリリース) ? その他 React.jsを使いたい これの扱い？

Slide 17

Slide 17 text

優先順位を決める P.11で考えたことQCDSに当てはめていく。 お金とか品質とか… 17 略称 名前 要望、制約 Q Quality Done is better than perfect. C Cost できるだけお金かけたくない (1ヶ月1000円以内) D Delivery 3か月くらいで公開したい 平日は1日0-30分しか使えない S Scope 壮大な計画で挫折したくない (小さくリリース) I Interest React.jsを使いたい Interest。 技術的な興味を満た す個人開発だってい いじゃないか。個人 だもの。

Slide 18

Slide 18 text

優先順位を決める 優先度を考え、優先度が高い順に並べるとこうなった 18 略称 名前 要望、制約 D Delivery Done is better than perfect. C Cost できるだけお金かけたくない (1ヶ月1000円以内) I Interest React.jsを使いたい Q Quality Done is better than perfect. S Scope 壮大な計画で挫折したくない (小さくリリース)

Slide 19

Slide 19 text

何を作るか決める 19 優 先 順 位を 決 める 何 を 作 る か 決 め る どう 作る か 決 める 公 開 する 実 際 に 作る 次 の 開 発 へ 開 発 計 画を 立 てる

Slide 20

Slide 20 text

何を作るか決める 大まかに機能や画面イメージをアウトプットする。 20 この画像はdraw.ioというツールを使って作成した図だが、手書き や他ツールでも問題ない

Slide 21

Slide 21 text

何を作るか決める 具体を詰める。 ● どのレシピサイトをサポートする？ ● XX倍のXXに入る数値の範囲は？　少数や分数は？ ● 利用されるのは日本だけ？ ● アクセス制限は必要？　どう定義する？ ● などなど… 21

Slide 22

Slide 22 text

何を作るか決める 具体を詰める。 ● どのレシピサイトをサポートする？ ● XX倍のXXに入る数値の範囲は？　少数や分数は？ ● 利用されるのは日本だけ？ ● アクセス制限は必要？　どう定義する？ ● などなど… 22 機能要件という。エンドユー ザーが直接触る部分のあ るべき姿を定義する。 非機能要件という。エンド ユーザーが直接触らない 部分でシステムがどう動作 すべきかを定義する。

Slide 23

Slide 23 text

何を作るか決める どのレシピサイトをサポートする？ ● 食品の製造をしている企業が提供しているサイトは表記揺れが少なそうなので、ま ずはそちらで開発する方針を立てる。 ● 目星をつけたサイトがスクレイピング可能か利用規約を調べる。 →3サイトに絞る。 （後ほど変わる） 23

Slide 24

Slide 24 text

何を作るか決める XX倍のXXに入る数値の範囲は？　少数や分数は？ ● 2人分のレシピを7人や9人分にして作ることが多いので少数か分数はほしい →1以上の整数、小数、分数を入力できることにした。 （しかし入力フォーマットは後ほど変えた） 24

Slide 25

Slide 25 text

何を作るか決める 利用されるのは日本だけ？ ● そもそも当初は自分だけが使うつもりだった →日本からのみアクセスされる想定で進める。 25

Slide 26

Slide 26 text

何を作るか決める アクセス制限は必要？　どう定義する？ ● 今回のサービスはスクレイピングを行うので、攻撃者に大量にアクセスされると自 サービスだけでなくレシピサイトにも迷惑がかかる。 →攻撃っぽいアクセスがあったら遮断できるようにする。 ○ 1秒間にXX回以上アクセスできないようにする ○ 攻撃のようなアクセスがあったら遮断する 26

Slide 27

Slide 27 text

何を作るか決める より詳しく、何を作るか決める方法を知りたい方はこちらがおすすめ。 ● システムを作らせる技術 エンジニアではないあなたへ （本） ● IPA 『非機能要件グレード グレード表』（Webサイト） ● はじめよう！ 要件定義 ～ビギナーからベテランまで （本） 27

Slide 28

Slide 28 text

計画を立てる 28 優 先 順 位を 決 める 何を 作る か 決 める どう 作る か 決 める 公 開 する 実 際 に 作る 次 の 開 発 へ 開 発 計 画 を 立 てる

Slide 29

Slide 29 text

計画を立てる 現実的に抽出できる時間から逆算する。 ● 平日は1日0〜30分 ● 休日は1日1〜2時間 ● ここまでの開発の計画を立てるのに2週間ほど使ったので、残り2ヶ月半 29

Slide 30

Slide 30 text

計画を立てる ● p.18〜26で決めた「何を作るか」をベースにタスクを洗い出し、それぞれに期限を つける。 ● 最初は大きいタスクを洗い出し、徐々に小さく分解する。 ● 最初から完璧にタスク分解しなくてもOK。 ● 実装してから気がつくことも多いので、都度タスクを追加していく。 30

Slide 31

Slide 31 text

計画を立てる 31

Slide 32

Slide 32 text

計画を立てる ● 残りの期間で3サイトサポートするのは無理そうだと気づく →Deliveryの方がScopeよりも優先順位が高い＋計算を楽にするというこのアプリ の価値はあまり変わらなそう →2サイトに変更 32

Slide 33

Slide 33 text

計画を立てる ● タスクを洗い出したら、いつまでに何をやるか管理ツールに登録する。 ● 今回はGithub Projectでタスクの作成と期限の設定をしているが別のツールでも OK。 33

Slide 34

Slide 34 text

計画を立てる ● どんなタスクが残っているか確認できる。 ● TodoとIn Progressは優先順位が高い順に並べると良い。 34

Slide 35

Slide 35 text

計画を立てる ● タスクの詳細にはやることと完了条件を書くと良い。 ● Template機能を使うと便利。 35

Slide 36

Slide 36 text

どう作るか決める 36 優 先 順 位を 決 める 何を 作る か 決 める どう 作 る か 決 め る 公 開 する 実 際 に 作る 次 の 開 発 へ 開 発 計 画を 立 てる

Slide 37

Slide 37 text

どう作るか決める 作り切ることが第一優先だが、慣れていないReact.jsを使いたい。 →新しいことをするのは同時に 1つまでとする。今回はReact.jsだけとする。他は慣れ た技術で開発する。 37

Slide 38

Slide 38 text

どう作るか決める フロントエンド: React.js ● 自分用でSEOを気にする必要がないのでNext.jsではなくReact.jsにした ○ Next.jsだとSSRという技術という技術を使っていて SEOに有利 ● ある程度慣れているのでTypeScriptを使用 ● Linterは慣れているのでESLint ● その他ライブラリは実際に作る過程で選定する 38

Slide 39

Slide 39 text

どう作るか決める フロントエンドは決まったので、その他は慣れた技術から選定。 ● バックエンド: Python ● インフラ: AWS ○ フロントエンド: S3, Cloudfront ○ バックエンド: Lambda, API Gateway, EC2, ECS on Fergateのうちどれか 39

Slide 40

Slide 40 text

どう作るか決める バックエンド: スクレイピングの部分だけコードを書いて、倍量計算はAIさせたらいいの では？ ● いい感じに計算してくれそう（品質高め？） ● GPTなどAIサービスをファインチューニングする場合、月 3000円以上かかることが発覚。（費用オーバー 確定） ● 自分のPCで機械学習モデルをファインチューニングする場合、 PCのスペックが足りない +不慣れ（納期 オーバーの可能性大） →費用（C）と納期（ D）のほうが品質（ Q）優先順位が高い ので、AIは使わないことにし た。 （ただし、1回作りきってから「やっぱAIのほうがいいな」となったらAIに乗り換えを検討す る） 40

Slide 41

Slide 41 text

どう作るか決める バックエンド: Python ● リリースから約3ヶ月しか経っていない3.12か、1つ前のバージョンの3.11か ○ 安全をとって3.11 ○ 3.12にあげる意思はあるので、あげやすいようにテストやコードの整備は最初から意識する ■ 単体テストはPythonのunittestモジュール ■ 静的型チェックはmypy ■ Linter、コード整形はblack ● その他ライブラリは実際に作る過程で選定する 41

Slide 42

Slide 42 text

どう作るか決める インフラ: AWS ● フロントエンドはCloudfrontとS3で管理 ● バックエンドはECS on Fergate vs ECS on EC2 vs Lambda vs LambdaとAPI Gatewayの組み合わせ ○ 費用とやりたいことで決めた。 ○ 費用のざっくり計算は ざっくりAWSを利用。 ○ 費用の面でEC2とECS on Fergateは候補から外した。 ○ 「攻撃っぽいアクセスがあったら遮断できるようにする。」は Lambdaだけではできない。 ○ API GatewayとLambdaに加え、AWS WAFが必要。 ○ AWS WAFを使うと費用オーバーになるが、スクレイピング先のサイトに迷惑がかからないよう AWS WAFを利用することにした。 42

Slide 43

Slide 43 text

どう作るか決める インフラの構成図はこうなった 43

Slide 44

Slide 44 text

実際に作る 44 優 先 順 位を 決 める 何を 作る か 決 める どう 作る か 決 める 公 開 する 実 際 に 作 る 次 の 開 発 へ 開 発 計 画を 立 てる

Slide 45

Slide 45 text

実際に作る 挫折しないような順番で作る。 まずは得意なバックエンドが動く状態にする →フロントエンドへのつなぎこみ →AWSで検証環境の構築（本番環境は「開発の流れ」の次の工程の「公開する」の時 に） 45

Slide 46

Slide 46 text

実際に作る 30分でやりきれる範囲ずつ、段階的に作る。 1. リクエストを受け取るだけ 2. ”Hello World”というレスポンス返すだけ 3. バックエンドからスクレイピング対象のページにアクセスするだけ 4. スクレイピングでレシピのタイトルを取得するだけ 5. … 46

Slide 47

Slide 47 text

実際に作る 実装内容が難しいときは、処理の図を描くだけの日にする。 47

Slide 48

Slide 48 text

実際に作る 少しでも進める工夫はすれど、うまくいかないことは多々ある。 当初立てたスケジュール通りにいかない。 そういうことはよくある… 48

Slide 49

Slide 49 text

実際に作る 2週間おきにうまくいった場所、うまくいかなかった場所を振り返る。 都度開発する機能の優先順位や期日を見直す。 49

Slide 50

Slide 50 text

実際に作る 50 優 先 順 位を 決 める 何を 作る か 決 める どう 作る か 決 める 公 開 する 実 際 に 作 る 次 の 開 発 へ 開 発 計 画を 立 てる 作りながら見えてくることも たくさんあるので、 随時計画を調整する

Slide 51

Slide 51 text

実際に作る 起きたトラブルを3つを紹介 51

Slide 52

Slide 52 text

実際に作る 3ヶ月でリリースする予定だったが、私用で2〜3月が忙しすぎてまったく平日に開発でき ない＋休日も体力が残っていない。 →無理して嫌になるのはよくないので、いったん3月末リリースを諦めた。 →機能開発はほそぼそ続けながらGWリリースを目指す。 52

Slide 53

Slide 53 text

実際に作る 何倍かを入力するフィールドで整数だけでなく小数や分数を受け付けると、実装が非常 に難しいことに気がつく。 →ChatGPTやCopilotに聞いても、良い回答を得られなかった →人数を固定値（0.5倍〜5.0倍を0.5きざみで選択） →機能の範囲（S）を削って、早く実装できる（D）方に 53

Slide 54

Slide 54 text

実際に作る みそ汁やカレーなど汁物の水分量は、単純に倍にすれば良い訳ではないことに気がつ く。 →汁物の水分量を学習させた機械学習モデルに計算させたほうがよいのでは？ →とはいえ費用がかかる上に不慣れなので、いったんそのまま作り切ること（D）を優 先。 →今できないけど後でやるのを検討することは、Github Projectのタスクに書いて忘れ ないようにしておく。 54

Slide 55

Slide 55 text

公開する 55 優 先 順 位を 決 める 何を 作る か 決 める どう 作る か 決 める 公 開 す る 実 際 に 作る 次 の 開 発 へ 開 発 計 画を 立 てる

Slide 56

Slide 56 text

公開する 公開作業前に検証環境で公開前のチェックリストを満たしているか確認する ● スマホやタブレットサイズの画面で表示したときにUIが崩れないこと ● 画像（）のalt属性が適切に指定されていること ● … ※Webサービス公開前のチェックリストから一部抜粋 56

Slide 57

Slide 57 text

公開する 本番環境に公開する手順書を書いておくと安心。 ● 本番環境用のURLなど環境に依存する値をまとめておく。 ● 操作の手順を書いておく。 ● チェックボックスつき手順書だと、どこまでやったか分からなくなるのを防ぎやすい。 57 ※Lambda Scaleでは本番環境反映作業はすべて自動化済

Slide 58

Slide 58 text

公開する 公開作業は気合がいるので、まとまった時間で一気に進める。 失敗しても翌日に続きができるようにする。 →予定のない土日にやる。 58

Slide 59

Slide 59 text

公開する 無事公開できたのでTwitterに動画あげた🎉 59

Slide 60

Slide 60 text

次の開発へ 60 優 先 順 位を 決 める 何を 作る か 決 める どう 作る か 決 める 公 開 する 実 際 に 作る 次 の 開 発 へ 開 発 計 画を 立 てる

Slide 61

Slide 61 text

次の開発へ Github Projectから次やることを決める。 いったん最初のリリースが終わったので、QCDSIも見直す。 →CQDISの順番にした。 →UIに関するフィードバックや読みにくいコードがあるのでDよりもQの優先度高めに。 61

Slide 62

Slide 62 text

次の開発へ 初期版 62

Slide 63

Slide 63 text

次の開発へ 2版 63

Slide 64

Slide 64 text

次の開発へ 3版 64

Slide 65

Slide 65 text

やってみての振り返り ● 優先順位を決めておいたおかげで悩む時間や脱線を減らせた。 ● 優秀な人と比べず、自分が何をしたら満足できるかに向き合うのが大事（あくまで 趣味なので！） ● 小さいことでもやりきったら自信になるので、もっとやれそうと前向きになれた。 65

Slide 66

Slide 66 text

ありがとうございました！ 66