小さなプロジェクトの開発

【初学者歓迎】東葛.dev in 柏 LT交流会【第5回】
https://toukatsu.connpass.com/event/346233/
にて話した内容です。

Transcript

1. 小さなプロジェクトの開発 m a e 6 1 6 東 葛 . d e v # 5 うまい！
2. 自己紹介 • mae616 (まえ) • Webエンジニア(フリーランス準備中) • 5年くらい: 1000名くらいの大規模プロジェクトに従事(SE) • 3年くらい: 中小規模のフルスタック系のプロジェクトに従事(SE, Web) • 花粉症(疑い)のまま3年くらい放置しています • 春は目がかゆい( ;つд⊂)ｺﾞｼｺﾞｼ @mae616_
3. このLTの主旨 小さなプロジェクトの開発工程を見て、 普段の開発の工程がどういうものなのか確認 し話してみましょう٩( ᐛ )و ただ、昨日気づきました... 「私、ウォータフォールしかやったことない...」 │ᐕ)⁾⁾ アジャイルとかスクラムの場合は 設計と実装を合体させて、いい感じに変換して聞いてね │ᐕ)⁾⁾モダンな開発したい...
4. 目次 • 工程とか • それぞれの役割と個人的な勘所 • 要件定義 • デザイン • 設計 • 実装 • ディレクション • 最近のAIについて個人的に思うこと • まとめ 注: 定義 このスライドで言う 「クライアント」は... 開発するアプリを依頼する事業 会社 • 開発全体の依頼会社や、 • 開発の一部を外注する開発 部署がある会社 のことです。 事業内容に沿って 「このアプリも使ってね」って 公開してるとこ٩( ᐛ )و
5. 大規模開発とかの工程 実装 詳細設計 基本設計 要件定義 単体テスト 結合テスト 総合テスト リリース
6. これを小さなプロジェクトで 全体を見ると...
7. 小規模Web開発とかの工程 実装 詳細設計 基本設計 要件定義 単体テスト 結合テスト 検収 納品 瑕疵契約範 囲の修正 デザイン デザイン チェック 営業→依頼 合意 一次 契約 合意 合意 料金 受取 本 契約 設計 合意 ※ 請負契約の例(実際に経験した業務とは少し変えてます) クライアントの作業 デザイナーの作業 デザイナーの作業 営業の作業 何か起きた時... リリース
8. 一応、それぞれの説明と勘所 (個人談) (꒪⌓꒪) 直前にスライド作ったのでテキストたくさんです...
9. 要件定義 クライアントの要望を聞いて、予算上開発可能な範囲を明確にして作 り込む機能の合意をとる工程。 クライアントが、「何を困って」「どういう目的でアプリ開発を依頼 したいか」を聞き、「開発のプロ」として問題解決の手段を変えた方 がいいならその旨話したり、開発範囲の変更などを提案する。 また... 「何をどこまで作るか」を決め、最初の合意を得る。 細かい詳細部分については、設計を進める中でヒアリングするが、予 算・技術・期間などを考慮して、機能要件に加え、パフォーマンス、 運用、セキュリティなどの非機能要件についても、どこまで対応する かを明確にし、合意を取る。
10. デザイン(デザイナー担当) ユーザーが直感的に理解し、快適に操作できるUI/UXを設計するプ ロセス。 クライアントにとっては、仕様やシステム設計よりも「見た目や使 い勝手」が直感的に理解しやすいため、開発工程の中でも特に重要 なフェーズ 。 こんな流れ クライアントの要望をヒアリング →ワイヤーフレーム(画面構成)の 作成 → デザインの作成 →クライアント確認・フィードバック修正 デザイナーとエンジニアが密接にコミュニケーションを取りながら、 技術的に実現可能なUI/UXを設計することが重要。
11. 設計(基本設計、詳細設計) 設計とは、開発に必要な情報を段階的に詳細化するプロセス。 上位設計者（または要件定義者）の文書や説明をもとに、自分の担 当範囲を技術的に詳細化し、設計書に落とし込む。 また、自身の設計段階でクライアントに確認することが出てくるの で、文書化して合意をとる。 アジャイルでは設計書を作らなくても、ビジネスサイドや受注会社 と細かく意思確認やフィードバックを重ねることで、同じ役割を 担っている。 ちなみに、要件定義で合意した機能以上のものをクライアントから 要望が合ったら、スケジュールや「別料金」などの調整が必要 （ディレクターにエスカレーションし、対応を決める）。
12. 実装 設計説明をしてもらって意図を理解して実装する。 実際やること... • nullチェックとか設計に書いてなくてプログラミングコード上で考 慮しなくてはならないところを考慮 • 設計で意図とずれている箇所や矛盾がある箇所があったら調整 要は、プログラム言語で表現するときに初めて出てくる考慮箇所や 辻褄の調整をして、設計や仕様の意図にあったもので実装する。 また、 • 自身の実装する箇所と連携する機能を作る他作業者と、スケ ジュールやシグネチャ（引数と戻り値）などを調整し、どういう 使い方を想定しているか、設計の意図と合っているかの認識を合 わせる。
13. ディレクション ディレクション(小さな会社のPMも含む)は... • クライアントはクライアントの言葉で話す • 開発メンバーは開発の話をする 使っているコンテキスト(文脈)の違う2つの関係の橋渡しをして • 適切な箇所でクライアントの意思決定を促したり補助 • 適切なコミュニケーションやスケジュールの合意を得る をして、「クライアントの本来作りたいもの」へアプリ開発を主導 する役割。 時には... • クライアントが決めきれないものを状況を見極めて判断し提案 • クライアントの無理な要求を調整しながら現実的な形に導く
14. 結局クライアントの受注で仕事が 成り立っている
15. 今のAIの流行について 結局、今までの開発でも... その工程の作業ができる ↓ だけでなく ◦ 前工程まで と 後工程 を考え、 * 仕様や設計が詰まってない部分 * クライアントとコミュニケーションが取れていない部分 に気づいて、コミュニケーションをしないと、 「クライアントに満足してもらえる仕事」にならない AI で作業を効率化しても、「気づき」や「コミュニケーション」は必要 なので、
16. まとめ (個人的な考え) 適切な工程で、工程の目的にあったことをするのが一番 効率的 作業の中で... • 「ここでこんなこと言っちゃいけないんじゃ 」とか • 「ここでこれ詰めなきゃないのに、なんでみんな理解してくれな いんだ 」とか 思う前に、「何をこの工程ですべき？」とか いろんなことを共有して話してみるのも面白いかなと思いました。
17. よかったら、内容を受けて 雑談しましょう♪ ご清聴ありがとう ございます٩( ᐛ )وﾋｬｯﾊｰ