Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
小さなプロジェクトの開発
Search
mae616
March 19, 2025
0
25
小さなプロジェクトの開発
【初学者歓迎】東葛.dev in 柏 LT交流会【第5回】
https://toukatsu.connpass.com/event/346233/
にて話した内容です。
mae616
March 19, 2025
Tweet
Share
More Decks by mae616
See All by mae616
創作系生成AIのプロンプト遊び
mae616
0
22
AIとお友達になりたい
mae616
1
71
エンジニアや人生の中での私の気づき 3つ
mae616
1
16k
Featured
See All Featured
How to train your dragon (web standard)
notwaldorf
91
5.9k
Designing for humans not robots
tammielis
250
25k
Building Applications with DynamoDB
mza
94
6.3k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Embracing the Ebb and Flow
colly
85
4.6k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
102
18k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
30k
Producing Creativity
orderedlist
PRO
344
40k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
It's Worth the Effort
3n
184
28k
A better future with KSS
kneath
238
17k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
30
1.1k
Transcript
小さなプロジェクトの開発 m a e 6 1 6 東 葛 .
d e v # 5 うまい!
自己紹介 • mae616 (まえ) • Webエンジニア(フリーランス準備中) • 5年くらい: 1000名くらいの大規模プロジェクトに従事(SE) •
3年くらい: 中小規模のフルスタック系のプロジェクトに従事(SE, Web) • 花粉症(疑い)のまま3年くらい放置しています • 春は目がかゆい( ;つд⊂)ゴシゴシ @mae616_
このLTの主旨 小さなプロジェクトの開発工程を見て、 普段の開発の工程がどういうものなのか確認 し話してみましょう٩( ᐛ )و ただ、昨日気づきました... 「私、ウォータフォールしかやったことない...」 │ᐕ)⁾⁾ アジャイルとかスクラムの場合は
設計と実装を合体させて、いい感じに変換して聞いてね │ᐕ)⁾⁾モダンな開発したい...
目次 • 工程とか • それぞれの役割と個人的な勘所 • 要件定義 • デザイン •
設計 • 実装 • ディレクション • 最近のAIについて個人的に思うこと • まとめ 注: 定義 このスライドで言う 「クライアント」は... 開発するアプリを依頼する事業 会社 • 開発全体の依頼会社や、 • 開発の一部を外注する開発 部署がある会社 のことです。 事業内容に沿って 「このアプリも使ってね」って 公開してるとこ٩( ᐛ )و
大規模開発とかの工程 実装 詳細設計 基本設計 要件定義 単体テスト 結合テスト 総合テスト リリース
これを小さなプロジェクトで 全体を見ると...
小規模Web開発とかの工程 実装 詳細設計 基本設計 要件定義 単体テスト 結合テスト 検収 納品 瑕疵契約範
囲の修正 デザイン デザイン チェック 営業→依頼 合意 一次 契約 合意 合意 料金 受取 本 契約 設計 合意 ※ 請負契約の例(実際に経験した業務とは少し変えてます) クライアントの作業 デザイナーの作業 デザイナーの作業 営業の作業 何か起きた時... リリース
一応、それぞれの説明と勘所 (個人談) (꒪⌓꒪) 直前にスライド作ったのでテキストたくさんです...
要件定義 クライアントの要望を聞いて、予算上開発可能な範囲を明確にして作 り込む機能の合意をとる工程。 クライアントが、「何を困って」「どういう目的でアプリ開発を依頼 したいか」を聞き、「開発のプロ」として問題解決の手段を変えた方 がいいならその旨話したり、開発範囲の変更などを提案する。 また... 「何をどこまで作るか」を決め、最初の合意を得る。 細かい詳細部分については、設計を進める中でヒアリングするが、予 算・技術・期間などを考慮して、機能要件に加え、パフォーマンス、
運用、セキュリティなどの非機能要件についても、どこまで対応する かを明確にし、合意を取る。
デザイン(デザイナー担当) ユーザーが直感的に理解し、快適に操作できるUI/UXを設計するプ ロセス。 クライアントにとっては、仕様やシステム設計よりも「見た目や使 い勝手」が直感的に理解しやすいため、開発工程の中でも特に重要 なフェーズ 。 こんな流れ クライアントの要望をヒアリング →ワイヤーフレーム(画面構成)の
作成 → デザインの作成 →クライアント確認・フィードバック修正 デザイナーとエンジニアが密接にコミュニケーションを取りながら、 技術的に実現可能なUI/UXを設計することが重要。
設計(基本設計、詳細設計) 設計とは、開発に必要な情報を段階的に詳細化するプロセス。 上位設計者(または要件定義者)の文書や説明をもとに、自分の担 当範囲を技術的に詳細化し、設計書に落とし込む。 また、自身の設計段階でクライアントに確認することが出てくるの で、文書化して合意をとる。 アジャイルでは設計書を作らなくても、ビジネスサイドや受注会社 と細かく意思確認やフィードバックを重ねることで、同じ役割を 担っている。 ちなみに、要件定義で合意した機能以上のものをクライアントから
要望が合ったら、スケジュールや「別料金」などの調整が必要 (ディレクターにエスカレーションし、対応を決める)。
実装 設計説明をしてもらって意図を理解して実装する。 実際やること... • nullチェックとか設計に書いてなくてプログラミングコード上で考 慮しなくてはならないところを考慮 • 設計で意図とずれている箇所や矛盾がある箇所があったら調整 要は、プログラム言語で表現するときに初めて出てくる考慮箇所や 辻褄の調整をして、設計や仕様の意図にあったもので実装する。
また、 • 自身の実装する箇所と連携する機能を作る他作業者と、スケ ジュールやシグネチャ(引数と戻り値)などを調整し、どういう 使い方を想定しているか、設計の意図と合っているかの認識を合 わせる。
ディレクション ディレクション(小さな会社のPMも含む)は... • クライアントはクライアントの言葉で話す • 開発メンバーは開発の話をする 使っているコンテキスト(文脈)の違う2つの関係の橋渡しをして • 適切な箇所でクライアントの意思決定を促したり補助 •
適切なコミュニケーションやスケジュールの合意を得る をして、「クライアントの本来作りたいもの」へアプリ開発を主導 する役割。 時には... • クライアントが決めきれないものを状況を見極めて判断し提案 • クライアントの無理な要求を調整しながら現実的な形に導く
結局クライアントの受注で仕事が 成り立っている
今のAIの流行について 結局、今までの開発でも... その工程の作業ができる ↓ だけでなく ◦ 前工程まで と 後工程 を考え、
* 仕様や設計が詰まってない部分 * クライアントとコミュニケーションが取れていない部分 に気づいて、コミュニケーションをしないと、 「クライアントに満足してもらえる仕事」にならない AI で作業を効率化しても、「気づき」や「コミュニケーション」は必要 なので、
まとめ (個人的な考え) 適切な工程で、工程の目的にあったことをするのが一番 効率的 作業の中で... • 「ここでこんなこと言っちゃいけないんじゃ 」とか • 「ここでこれ詰めなきゃないのに、なんでみんな理解してくれな
いんだ 」とか 思う前に、「何をこの工程ですべき?」とか いろんなことを共有して話してみるのも面白いかなと思いました。
よかったら、内容を受けて 雑談しましょう♪ ご清聴ありがとう ございます٩( ᐛ )وヒャッハー