色々な開発方法を学習しよう！　デイトラJava中級編37「現場での開発の流れ（後編）」

※前半の記事はこちら。

Mermaid記法について学習しよう

Mermaid記法は、テキストベースのフローチャートや図を作成するための記法です。プログラムの流れやデータ構造などを視覚的に表現する際に使われ、コードの形で図を記述できるため、ドキュメントやREADMEファイル内で直接図を描くことが可能になります。

「Markdown拡張機能」のチェック項目に「Mermaid」のチェックボックスが無い！？

講義では『言語とフレームワーク（Language&Framework）を選択し、その中から Markdown を選択するとMermaid のチェックボックス表示されます。』とありましたが、自分のIntelliJのバージョンではMermaid のチェックボックスがありませんでした。
ChatGPTに確認したところ以下のような回答でした。

IntelliJ IDEAでは、MermaidがMarkdown内の一つの機能として組み込まれていることもあれば、独立した項目として「言語＆フレームワーク」内に存在することもあります。
プラグインや機能によっては、IDEのバージョンアップやプラグインのアップデートに伴い、設定画面での位置が変わることがあります。

Mermaid記法で表現した３つの図をIntelliJ上で確認しよう

クラス図

ER図

シーケンス図

その他

開発プロセスのフレームワークを学習しよう

プロセスモデルに沿って実際に開発を始める際には、開発プロセスのフレームワークを採用します。
開発プロセスの考え方としては「ウォーターフォール開発」と「アジャイル開発」が有名です。

ウォーターフォール開発

ウォーターフォール開発とは、滝の流れるように一方通行で各段階を順に進める古典的なシステム開発手法です。顧客の要望を基に、要件定義、設計、コーディング、テストを段階ごとに行い、一つの段階が完了するまで次には進めません。過去の工程の見落としを後で修正するのは難しいですが、その明確な工程の区切りが管理をしやすくしているため、大きなプロジェクトに向いています。

ウォーターフォール開発のメリット

ウォーターフォール開発では全てのプロセスを初めから把握し、明確なタスクとスケジュールに基づいて進めるため、進捗管理が容易です。各段階での要件がクリアで、計画に沿って進むことで予算や納期の変動リスクを減らせます。また、開発メンバーに変更があってもタスクの明確さがスムーズな引き継ぎを可能にし、計画どおりにプロジェクトを進行させることができます。

ウォーターフォール開発のデメリット

ウォーターフォール開発の大きな欠点はその計画の硬直性です。要件の変更があると全体の計画を見直す必要が生じ、契約やスケジュール上の問題で計画の変更が難しくなることがあります。また、開発完了後のバグ発見が工数や納期に影響を与えることがあり、途中でユーザーの要望を取り入れにくいため、最終的に要求と異なる製品が完成するリスクがあります。従って、最初の要件定義の正確さが極めて重要になります。

アジャイル開発

アジャイル開発は、変化への柔軟な対応とスピーディな価値提供を目指す開発手法です。この手法はユーザーのニーズを最優先し、頻繁なリリースを通じて進行する小さな開発サイクルを特徴とします。計画、設計、実装、テストの工程を繰り返しながら、顧客のフィードバックに応じて製品を進化させていきます。仕様変更が起こりやすいプロジェクトや迅速なリリースを求める状況に適しています。

アジャイルのメリット

アジャイル開発の利点は、発注者との頻繁なコミュニケーションにより、システムの機能理解が容易になること、小規模な開発単位で進めるため不具合発生時の修正範囲が小さく、対応が迅速になることです。詳細な仕様書に依存せず、仕様変更にも柔軟に対応できるので、品質向上のためのミスと修正を繰り返しながら進むことが可能です。変更が頻繁なプロジェクトや迅速なユーザーフィードバックを求める場合に最適です。

アジャイルのデメリット

アジャイル開発では、詳細に決まった仕様書を前提にせず、開発を進めますが、これが方向性が不明確になったり、進捗管理が困難になる原因となり得ます。小単位での開発を繰り返す工程では、全体の進捗を見失い、納期遅延のリスクが増加します。また、頻繁な仕様変更は柔軟性をもたらす一方で、スケジュールが延びる要因にもなりかねません。開発チームの日々の短いミーティングでは、全体像を見失いがちで、結果的にリリースの遅れや予算超過に繋がる可能性があります。

アジャイル開発の具体的な手法を学ぼう

アジャイル開発には複数の具体的な手法があり、それぞれが異なるアプローチや焦点を持っています。
そのうち講義では「スクラム開発」について学びました。

ここでは「スクラム開発」と、講義外で自身で調べた「XP（eXtreme Programming）開発」について紹介します。

スクラム開発

スクラムでは実施しなければならない事項が明確に定義されています。スクラムのイベントと開発体制についてそれぞれ紹介します。

スクラムのイベント

スクラムのイベントでは、以下の５つの重要な会議があります。

• スプリント…一定期間の開発サイクルのことで、この期間中に完成を目指す機能の開発を行います。
• スプリントプランニング…そのスプリントで何をするか決定する計画会議です。
• デイリースクラム…毎日行われ、進捗の共有や問題の特定を行う短いミーティングです。
• スプリントレビュー…スプリントの終了時に開発した機能をチーム外の人も含めてレビューする会議です。
• スプリントレトロスペクティブ…次のスプリントを改善するために、前のスプリントを振り返る会議です。

スクラムの開発体制

スクラムの開発体制は、プロジェクトの進行を円滑にするために、以下のように役割が明確に定義されています。

• スクラムチーム…スクラムの基本単位で小さなチームを指します。通常、プロダクトオーナー１人、スクラムマスター1人、開発者複数人で構成されます。
• プロダクトオーナー…プロジェクトのビジョンと最終的な製品の価値を司る重要な役割を担い、プロジェクトの要件やタスクの優先順位を定め、バックログを管理します。
• スクラムマスター…チームのコーチであり、スクラムの原則と実践の導入、チーム間の障害の除去などを行います。彼らはプロジェクトがスクラムの原則に従って進むようにチームを導き、障害が発生した際にそれを取り除く役目を担います。
• 開発者…製品の実際のコーディングやテストなど、技術面を担当する実務者です。POが明確にしたゴールに向けてプロダクトをデリバリーすることが求められます。

スクラムでは、各役割が製品改善とプロジェクト進行の透明性を保つため重要です。自己組織化したチームは迅速に成果を出し、環境の変化に柔軟に対応します。

スクラム開発の流れ

実際にスクラム開発を行う流れを紹介します。

• プロジェクト開始時にまず開発対象の機能や改善点をリストアップしてプロダクトバックログを作成します。
• 次にスプリント計画を立て、バックログから優先度の高いタスクを選定し、具体的な実行計画を策定します。
• スプリント期間中は毎日デイリースクラムを行い、タスクの進捗状況をチーム内で共有し、計画通りに作業が進んでいない場合はその場で調整します。
• スプリントの終わりにはスプリントレビューを実施し、開発した機能をチーム外の関係者にも見せてフィードバックを受け取ります。
• スプリントレトロスペクティブでチーム内でスプリントの振り返りを行い、改善点を次のスプリント計画に生かすことで、継続的に開発プロセスの改善を図ります。

この一連のプロセスを繰り返し行うことで、変化に柔軟に対応し、効率的にプロダクトを開発していくことが可能になります。

XP（eXtreme Programming）開発　※自習部分です

引用：【簡単解説】アジャイル開発とスクラム開発の違いを初心者向けに解説！ | Hello Scrum

XP（eXtreme Programming）開発は、アジャイル開発の一手法であり、少人数の開発に適用しやすく、変更を許容する柔軟性を実現しています。XP開発はスクラム開発ほど広く知られていませんが、アジャイル開発手法として利用されています。

５つの価値と19のプラクティス

XPでは５つの価値と19のプラクティスが定義されています。

５つの価値

XP開発の5つの価値は、開発プロセスの基盤となる重要な原則です。これらの価値を理解し、実践することで、チームはより効果的なコラボレーションと高品質なソフトウェア開発を目指します。

1. コミュニケーション（Communication）：
   • チーム内でのオープンで率直なコミュニケーションを重視します。
   • 問題やアイデアを効果的に共有することで、誤解を減らし、より良い解決策を見つけ出すことができます。
   • 開発チーム内だけでなく、顧客とのコミュニケーションも重視します。
2. シンプル（Simplicity）：
   • システムをできるだけシンプルに保つことを目指します。
   • 現時点で必要な機能のみを実装し、不要な複雑さを避けることで、保守が容易なソフトウェアを作成します。
3. フィードバック（Feedback）：
   • 顧客やチームメンバーからの早期かつ頻繁なフィードバックを積極的に求めます。
   • 継続的なテストやデモを通じて得られるフィードバックを用いて、製品を継続的に改善します。
4. 勇気（Courage）：
   • 困難な決断や変更に直面しても、正しい行動を取る勇気を持ちます。
   • リファクタリングや仕様の変更など、製品の質を高めるために必要な決断を恐れずに行います。
5. 尊敬（Respect）：
   • チームメンバー間で互いに尊敬し合うことを大切にします。
   • それぞれの貢献を認識し、個々の違いを尊重することで、協力的なチームワークを促進します。

19のプラクティス

XP開発では、効果的なソフトウェア開発を支援するために、いくつかの実践（プラクティス）が提案されています。これらは共同プラクティス、開発プラクティス、管理者プラクティス、顧客プラクティスの4つのカテゴリに分けられます。

共同プラクティス

• 反復…開発プロセスを約１～２週間の短いサイクルで繰り返し行います。これにより、柔軟性を持って変更に対応しやすくなります。
• 共通の用語…チーム内で統一された用語を使用することで、コミュニケーションの齟齬を減らし、効率を上げます。
• オープンな作業空間…開発チームと顧客間がお互いにコミュニケーションしやすいオープンな空間で作業することで、進捗の共有や協力を促進します。
• 回顧…スプリントやイテレーションの終わりに振り返りを行い、プロセスの改善点を探します。

開発プラクティス

• テスト主導型の開発 (TDD)…コードを書く前にテストを書き、そのテストをパスするコードを開発します。これにより、信頼性の高いコードの開発を促進します。
• ペア・プログラミング…2人の開発者が一つの作業を共同で行います。１人がコードを記述し、もう１人はそれを確認・補佐します。
• リファクタリング…コードの機能を保ったまま内部構造を改善し、可読性と保守性を高めます。
• 集団的な所有権…コードに対する所有権をチーム全体で共有します。これにより、どの開発者もコードの改善ができるようになります。
• 継続的インテグレーション…頻繁にコードを統合し、自動テストを行うことで、問題を早期に発見し、修正します。
• YAGNI (You Ain’t Gonna Need It)…必要になるまで機能を追加しないことで、無駄な労力を削減します。

管理者プラクティス

• 責任の受け入れ…プロジェクトの責任をチーム全体で共有し、各メンバーが自己責任を持って取り組みます。
• 援護…チームが円滑に作業を進められるよう、障害物の除去やサポートを積極的に行います。
• 四半期ごとの見直し…定期的にプロジェクトの進行状況を見直し、計画を調整します。
• ミラー…プロジェクトの進捗をリアルタイムで可視化し、状況を把握しやすくします。
• 持続可能なペース…チームが長期間にわたって健康的に作業を続けられるよう、適切なペースで開発を進めます。

顧客プラクティス

• ストーリーの作成…開発する機能を短いストーリーとして表現し、優先順位付けと計画の基礎とします。
• リリース計画…ストーリーを基にして、リリースのスケジュールを立てます。頻繁なリリースを通じて、早期にフィードバックを得ることを目指します。
• 受け入れテスト…顧客が定義した条件を満たしているかを検証するテストを行い、品質を確保します。
• 頻繁なリリース…小さい機能単位で頻繁にリリースを行うことで、早期に市場への投入を目指します。

まとめ　　たくさん説明しましたが、暗記は必要ありません

前編と後編で現場での開発の流れについて解説しました。
沢山の用語を解説してきましたが現段階ですべて暗記する必要はなく、実務でこなしていく内に学んでいく知識であると思います。

以上で今回の学習記録を終えます。

ここまでご覧いただきありがとうございました。