厳しさとゆるさの間で迷う人に捧げる個人開発記

Transcript

1. 厳しさとゆるさの間で迷う人に 捧げる個人開発記 2025-02-08 mizzsugar @Pycon mini Shizuoka 2024 continue 1
2. ！！注意！！ • Pythonの話はあまりしません。 • これからなにか作りたい人に対してハードルを下げることが目的です。 • 開発経験がない人もターゲットに含めています。 2
3. 自己紹介 • mizzsugar(みずきと呼んでください) ◦ X(Twitter): mizzsugar0425 • 静岡県静岡市在住 • 東京の開発会社でバックエンドエンジニア ◦ BtoBWebサービスの開発 ◦ 社内若手エンジニア教育プロジェクト 3
4. Lambda Scaleの紹介　 • レシピの分量を多めまたは少なめに計算するアプリ。 • レシピのURLと何倍かを入力すると、分量が計算される。 ◦ 「人分」だけでなく様々な単位に対応できるようにするために何倍かを入力 • 材料1つずつ計算機を使って計算する手間が省ける。　 4 https://lambda-scale.fun アイコンはこちら
5. 今日伝えたいこと 人と比べない！！自分が作ったものに自信をもとう！！ • 開発する前に、何を大事にするか優先順位 を決めておくと、開発中にトラブルが起 こった時に悩む時間が少なくなる。 • 「無理なくやる」と「ダラダラやる」は違う。無理なくメリハリつけて開発しよう。 • 個人開発は自分で決めることの連続。 • どんなに小さい開発でも、決めるというプロセスの連続は大きな糧と自信になる 。 5
6. 目次 • きっかけ • ネタ探し • 開発 ◦ 優先順位を決める ◦ 何を作るか決める ◦ 開発計画を立てる ◦ どう作るか決める ◦ 実際に作る ◦ 公開する ◦ 次の開発へ • やってみての振り返り 6
7. きっかけ 2023年の年末。1年の振り返りをしている時。 仕事での立場も変わってあまり実装しなくなった +プライベートもInput重視であまりプログラミングしていないと気がつく。 →2024年はプライベートでなにか作りきりたい！と思い開発スタート🔥 7
8. ネタ探し 思いつくものを書き出す。普段からメモしておくとなおよし。 趣味の料理に関するツール 趣味のゲームに関するツール 仕事で使えそうなツール … 8
9. ネタ探し コワーキングスペースで大量に料理をよく振る舞う（10人とか） 大体のレシピは2人分や4人分 毎回各材料の分量を手計算するのがめんどくさかった →分量を自動計算してくれるアプリを作ることに決定！ 9
10. 開発の流れ 10 優 先 順 位を 決 める 何を 作る か 決 める どう 作る か 決 める 公 開 する 実 際 に 作る 次 の 開 発 へ 開 発 計 画を 立 てる 今回はあくまで個人開発をリリースするまでの工程です。 仕事の開発ではテストや保守運用という工程を含みます。仕事でよくある工程については こちらの記事を読んでください。 テストもしながら
11. 優先順位を決める 11 優 先 順 位 を 決 め る 何を 作る か 決 める どう 作る か 決 める 公 開 する 実 際 に 作る 次 の 開 発 へ 開 発 計 画を 立 てる
12. 優先順位を決める 12 Done is better than perfect. 壮大な計画で挫折 したくない (小さくリリース) できるだけお金かけ たくない (1ヶ月1000円以内) React使って みたい 3か月くらいで公開 したい 平日は1日0-30 分しか使えない
13. 優先順位を決める • やりたいことはたくさんあるが、制約も多い。 ◦ 時間やお金には限りがある。 • あれもこれもと一気にはできないので、何を優先するか判断する指針 を作ってお く。 ◦ トラブルが起きた時にどう進めるか決めるのに迷う時間が少なくなる。 • 迷ったときのなんとなくの判断が少なくなり、メリハリができる 。 13
14. 優先順位を決める 優先順位の考え方にQCDSというものがある。 14 略称 名前 要望、制約 Q Quality 品質。製品やサービスの出来栄えや性能など。 例: バグの少なさ、セキュリティ C Cost 開発にかかる費用。 例: インフラ費、人件費 D Delivery 開発にかかる時間、期限 例: リリース日、ある機能をいつまでにリリースできる状態にするか S Scope 開発する範囲 例: 開発する機能、やらないこと
15. 優先順位を決める 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を使いたい
16. 優先順位を決める 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を使いたい これの扱い？
17. 優先順位を決める 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。 技術的な興味を満た す個人開発だってい いじゃないか。個人 だもの。
18. 優先順位を決める 優先度を考え、優先度が高い順に並べるとこうなった 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 壮大な計画で挫折したくない (小さくリリース)
19. 何を作るか決める 19 優 先 順 位を 決 める 何 を 作 る か 決 め る どう 作る か 決 める 公 開 する 実 際 に 作る 次 の 開 発 へ 開 発 計 画を 立 てる
20. 何を作るか決める 大まかに機能や画面イメージをアウトプットする。 20 この画像はdraw.ioというツールを使って作成した図だが、手書き や他ツールでも問題ない
21. 何を作るか決める 具体を詰める。 • どのレシピサイトをサポートする？ • XX倍のXXに入る数値の範囲は？　少数や分数は？ • 利用されるのは日本だけ？ • アクセス制限は必要？　どう定義する？ • などなど… 21
22. 何を作るか決める 具体を詰める。 • どのレシピサイトをサポートする？ • XX倍のXXに入る数値の範囲は？　少数や分数は？ • 利用されるのは日本だけ？ • アクセス制限は必要？　どう定義する？ • などなど… 22 機能要件という。エンドユー ザーが直接触る部分のあ るべき姿を定義する。 非機能要件という。エンド ユーザーが直接触らない 部分でシステムがどう動作 すべきかを定義する。
23. 何を作るか決める どのレシピサイトをサポートする？ • 食品の製造をしている企業が提供しているサイトは表記揺れが少なそうなので、ま ずはそちらで開発する方針を立てる。 • 目星をつけたサイトがスクレイピング可能か利用規約を調べる。 →3サイトに絞る。 （後ほど変わる） 23
24. 何を作るか決める XX倍のXXに入る数値の範囲は？　少数や分数は？ • 2人分のレシピを7人や9人分にして作ることが多いので少数か分数はほしい →1以上の整数、小数、分数を入力できることにした。 （しかし入力フォーマットは後ほど変えた） 24
25. 何を作るか決める 利用されるのは日本だけ？ • そもそも当初は自分だけが使うつもりだった →日本からのみアクセスされる想定で進める。 25
26. 何を作るか決める アクセス制限は必要？　どう定義する？ • 今回のサービスはスクレイピングを行うので、攻撃者に大量にアクセスされると自 サービスだけでなくレシピサイトにも迷惑がかかる。 →攻撃っぽいアクセスがあったら遮断できるようにする。 ◦ 1秒間にXX回以上アクセスできないようにする ◦ 攻撃のようなアクセスがあったら遮断する 26
27. 何を作るか決める より詳しく、何を作るか決める方法を知りたい方はこちらがおすすめ。 • システムを作らせる技術 エンジニアではないあなたへ （本） • IPA 『非機能要件グレード グレード表』（Webサイト） • はじめよう！ 要件定義 ～ビギナーからベテランまで （本） 27
28. 計画を立てる 28 優 先 順 位を 決 める 何を 作る か 決 める どう 作る か 決 める 公 開 する 実 際 に 作る 次 の 開 発 へ 開 発 計 画 を 立 てる
29. 計画を立てる 現実的に抽出できる時間から逆算する。 • 平日は1日0〜30分 • 休日は1日1〜2時間 • ここまでの開発の計画を立てるのに2週間ほど使ったので、残り2ヶ月半 29
30. 計画を立てる • p.18〜26で決めた「何を作るか」をベースにタスクを洗い出し、それぞれに期限を つける。 • 最初は大きいタスクを洗い出し、徐々に小さく分解する。 • 最初から完璧にタスク分解しなくてもOK。 • 実装してから気がつくことも多いので、都度タスクを追加していく。 30
31. 計画を立てる 31
32. 計画を立てる • 残りの期間で3サイトサポートするのは無理そうだと気づく →Deliveryの方がScopeよりも優先順位が高い＋計算を楽にするというこのアプリ の価値はあまり変わらなそう →2サイトに変更 32
33. 計画を立てる • タスクを洗い出したら、いつまでに何をやるか管理ツールに登録する。 • 今回はGithub Projectでタスクの作成と期限の設定をしているが別のツールでも OK。 33
34. 計画を立てる • どんなタスクが残っているか確認できる。 • TodoとIn Progressは優先順位が高い順に並べると良い。 34
35. 計画を立てる • タスクの詳細にはやることと完了条件を書くと良い。 • Template機能を使うと便利。 35
36. どう作るか決める 36 優 先 順 位を 決 める 何を 作る か 決 める どう 作 る か 決 め る 公 開 する 実 際 に 作る 次 の 開 発 へ 開 発 計 画を 立 てる
37. どう作るか決める 作り切ることが第一優先だが、慣れていないReact.jsを使いたい。 →新しいことをするのは同時に 1つまでとする。今回はReact.jsだけとする。他は慣れ た技術で開発する。 37
38. どう作るか決める フロントエンド: React.js • 自分用でSEOを気にする必要がないのでNext.jsではなくReact.jsにした ◦ Next.jsだとSSRという技術という技術を使っていて SEOに有利 • ある程度慣れているのでTypeScriptを使用 • Linterは慣れているのでESLint • その他ライブラリは実際に作る過程で選定する 38
39. どう作るか決める フロントエンドは決まったので、その他は慣れた技術から選定。 • バックエンド: Python • インフラ: AWS ◦ フロントエンド: S3, Cloudfront ◦ バックエンド: Lambda, API Gateway, EC2, ECS on Fergateのうちどれか 39
40. どう作るか決める バックエンド: スクレイピングの部分だけコードを書いて、倍量計算はAIさせたらいいの では？ • いい感じに計算してくれそう（品質高め？） • GPTなどAIサービスをファインチューニングする場合、月 3000円以上かかることが発覚。（費用オーバー 確定） • 自分のPCで機械学習モデルをファインチューニングする場合、 PCのスペックが足りない +不慣れ（納期 オーバーの可能性大） →費用（C）と納期（ D）のほうが品質（ Q）優先順位が高い ので、AIは使わないことにし た。 （ただし、1回作りきってから「やっぱAIのほうがいいな」となったらAIに乗り換えを検討す る） 40
41. どう作るか決める バックエンド: Python • リリースから約3ヶ月しか経っていない3.12か、1つ前のバージョンの3.11か ◦ 安全をとって3.11 ◦ 3.12にあげる意思はあるので、あげやすいようにテストやコードの整備は最初から意識する ▪ 単体テストはPythonのunittestモジュール ▪ 静的型チェックはmypy ▪ Linter、コード整形はblack • その他ライブラリは実際に作る過程で選定する 41
42. どう作るか決める インフラ: 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
43. どう作るか決める インフラの構成図はこうなった 43
44. 実際に作る 44 優 先 順 位を 決 める 何を 作る か 決 める どう 作る か 決 める 公 開 する 実 際 に 作 る 次 の 開 発 へ 開 発 計 画を 立 てる
45. 実際に作る 挫折しないような順番で作る。 まずは得意なバックエンドが動く状態にする →フロントエンドへのつなぎこみ →AWSで検証環境の構築（本番環境は「開発の流れ」の次の工程の「公開する」の時 に） 45
46. 実際に作る 30分でやりきれる範囲ずつ、段階的に作る。 1. リクエストを受け取るだけ 2. ”Hello World”というレスポンス返すだけ 3. バックエンドからスクレイピング対象のページにアクセスするだけ 4. スクレイピングでレシピのタイトルを取得するだけ 5. … 46
47. 実際に作る 実装内容が難しいときは、処理の図を描くだけの日にする。 47
48. 実際に作る 少しでも進める工夫はすれど、うまくいかないことは多々ある。 当初立てたスケジュール通りにいかない。 そういうことはよくある… 48
49. 実際に作る 2週間おきにうまくいった場所、うまくいかなかった場所を振り返る。 都度開発する機能の優先順位や期日を見直す。 49
50. 実際に作る 50 優 先 順 位を 決 める 何を 作る か 決 める どう 作る か 決 める 公 開 する 実 際 に 作 る 次 の 開 発 へ 開 発 計 画を 立 てる 作りながら見えてくることも たくさんあるので、 随時計画を調整する
51. 実際に作る 起きたトラブルを3つを紹介 51
52. 実際に作る 3ヶ月でリリースする予定だったが、私用で2〜3月が忙しすぎてまったく平日に開発でき ない＋休日も体力が残っていない。 →無理して嫌になるのはよくないので、いったん3月末リリースを諦めた。 →機能開発はほそぼそ続けながらGWリリースを目指す。 52
53. 実際に作る 何倍かを入力するフィールドで整数だけでなく小数や分数を受け付けると、実装が非常 に難しいことに気がつく。 →ChatGPTやCopilotに聞いても、良い回答を得られなかった →人数を固定値（0.5倍〜5.0倍を0.5きざみで選択） →機能の範囲（S）を削って、早く実装できる（D）方に 53
54. 実際に作る みそ汁やカレーなど汁物の水分量は、単純に倍にすれば良い訳ではないことに気がつ く。 →汁物の水分量を学習させた機械学習モデルに計算させたほうがよいのでは？ →とはいえ費用がかかる上に不慣れなので、いったんそのまま作り切ること（D）を優 先。 →今できないけど後でやるのを検討することは、Github Projectのタスクに書いて忘れ ないようにしておく。 54
55. 公開する 55 優 先 順 位を 決 める 何を 作る か 決 める どう 作る か 決 める 公 開 す る 実 際 に 作る 次 の 開 発 へ 開 発 計 画を 立 てる
56. 公開する 公開作業前に検証環境で公開前のチェックリストを満たしているか確認する • スマホやタブレットサイズの画面で表示したときにUIが崩れないこと • 画像（<img>）のalt属性が適切に指定されていること • … ※Webサービス公開前のチェックリストから一部抜粋 56
57. 公開する 本番環境に公開する手順書を書いておくと安心。 • 本番環境用のURLなど環境に依存する値をまとめておく。 • 操作の手順を書いておく。 • チェックボックスつき手順書だと、どこまでやったか分からなくなるのを防ぎやすい。 57 ※Lambda Scaleでは本番環境反映作業はすべて自動化済
58. 公開する 公開作業は気合がいるので、まとまった時間で一気に進める。 失敗しても翌日に続きができるようにする。 →予定のない土日にやる。 58
59. 公開する 無事公開できたのでTwitterに動画あげた🎉 59
60. 次の開発へ 60 優 先 順 位を 決 める 何を 作る か 決 める どう 作る か 決 める 公 開 する 実 際 に 作る 次 の 開 発 へ 開 発 計 画を 立 てる
61. 次の開発へ Github Projectから次やることを決める。 いったん最初のリリースが終わったので、QCDSIも見直す。 →CQDISの順番にした。 →UIに関するフィードバックや読みにくいコードがあるのでDよりもQの優先度高めに。 61
62. 次の開発へ 初期版 62
63. 次の開発へ 2版 63
64. 次の開発へ 3版 64
65. やってみての振り返り • 優先順位を決めておいたおかげで悩む時間や脱線を減らせた。 • 優秀な人と比べず、自分が何をしたら満足できるかに向き合うのが大事（あくまで 趣味なので！） • 小さいことでもやりきったら自信になるので、もっとやれそうと前向きになれた。 65
66. ありがとうございました！ 66