開発前の調査

開発手法
ウォータフォール
「要件定義」「外部設計」「内部設計」「プログラム設計」「プログラミング」「テスト」の行程に分割し、一つの工程が終わったら、次の行程に移るという手法
メリット
・進捗管理しやすい
・経験しているエンジニアが多いので導入が楽
・一つの工程が終わった際に品質確保ができているので手戻りが最小限になる
デメリット
・仕様変更などがあった場合の負担が大きい。それゆえに、ユーザーの意見を反映しにくい

アジャイル
要件定義は最小限にし、開発内容を分割した小さい単位ごとに設計⇨実装→テストを繰り返す手法
メリット
・各単位のテスト段階でも反映させられるので、ユーザーの意見を反映しやすい
・小単位でテストするので、原因究明を容易で修正工数が少なくなる
・ウォータフォールに比べて、短時間で納品できる
デメリット
・明確な期限を切らないため進捗管理がしにくい
・開発途中でも良いアイデアを反映できる反面、方向性がぶれやすい

プロトタイプ
簡単な試作を作成し、それを用いてユーザーの反応を確認することで、見えなかった要件や不要な要件を早い段階で発見できることで大きな手戻りを防げる手法
メリット
・ユーザーの反応を早めに確認できるので、プロジェクトが成功しやすくなる
・試作は容易に変更ができるので、柔軟な対応が可能
・大きな手戻りを防げる
デメリット
・ユーザーの意見に左右され、方向性がぶれやすい
・計画や見積りが困難

スパイラル
アジャイルのように小さい単位で設計からテストまで行い、プロトタイプのようにユーザーに試作を提供する手法
メリット
・プロジェクトが成功しやすくなる
・柔軟な対応が可能
・大きな手戻りを防げる
デメリット
・計画や見積りが困難
・開発の負担が大きい

DevOps
開発と運用の両チームが連携して、「リリース」「ユーザーの声」「計画」「設計」「実装」「テスト」「リリース」を回す手法
メリット
・柔軟な対応が可能
・大きな手戻りを防げる
・開発の負担が減る
デメリット
・開発と運用の連携の質が品質に大きな影響を与える

ラピッドアプリケーションデベロップメント
「要件定義」「ユーザー設計」「作成」「カットオーバー」のフェーズが存在し、製品が全ての要件を満たしていることをユーザーが確認するまで要件定義を行う。
メリット
・時間的制約のある中小規模（ビジネス目標とユーザー・グループの定義が明確で、処理が複雑でない）プロジェクトに有効
デメリット
・技術力の高い開発者の安定したチームとユーザーへの深い知識が必要

ブランチ戦略
Git Flow
5種類のブランチ（main、develop、feature、release、hotfix）を用いて開発する。各々の開発者はdevelopからfeatureを作成して作業を行い、作業完了後にプルリク・マージをしていく。そして、スプリントの区切りなどでdevelopからreleaseにマージしてステージング環境で動作確認し、問題ない場合はmainにマージしてデプロイとなる。ただし、デプロイ後にバグが発覚した場合はhotfixを作成し、修正する。
メリット
・ブランチ環境と紐づけて管理しやすい
デメリット
・マージのパターンが複雑でコンフリクトが起きやすい
・ブランチを理解する工数がかかる

GitHub Flow
2種類のブランチ（main, feature）を用いて開発する。開発者はfeatureブランチで作業し、プルリク・マージを行う。そして、ステージング環境で確認後に本番環境にデプロイ。
メリット
・git flowよりも管理しやすい
デメリット
・ブランチと環境が紐づかない

トランクベース開発
2種類のブランチ（trunk, feature）を用いて開発する。開発者は featureで作業するが、1~2日以内にマージする。trunkブランチはいつでも本番環境にデプロイできる状態となっている。
機能フラグやCIが欠かせない要素となっている。（機能フラグとは機能のON、OFFを操作するフラグ）
メリット
・コンフリクトが起きにくい
・プルリクは小さい単位なのでコードレビューしやすい
デメリット
・マージ前の過剰なコードレビュー
・コミット前の自動テストが必要
・プルリク中に他の作業を行うとマージが遅れるので、許可されるまで待機する必要がある

機能フラグに関係するフィーチャーフラグ
機能ごとに有効にするかどうかのフラグを導入することで、中途半端なコードをtrunkにマージしても影響が出ないようにすることができるため、フィーチャーフラグはトランクベース開発に必要となる。
実際にフィーチャーフラグを導入する場合はサードパーティ製のフィーチャーフラグ管理システムを利用した方がいい。

if(feature.isActive("holiday-greeting")) {
     print("Happy holidays," + user.name + "!");
}

メリット
・新しい機能のプルリクの際に影響などを気にしなくていい
デメリット
・各機能ごとにフラグがあるので、定期的に整理して不要なフラグは削除する必要がある

アーキテクチャ特性

運用特性

構造特性

横断的特性

その他

ドメインの関心事をアーキテクチャ特性に変換した場合

引用元：ソフトウェアアーキテクチャの基礎　エンジニアリングに基づく体系的アプローチ

• モノリシック
  • レイヤードアーキテクチャ
  • パイプラインアーキテクチャ
  • マイクロカーネルアーキテクチャ
• 分散
  • サービスベースアーキテクチャ
  • イベント駆動アーキテクチャ
  • スペースベースアーキテクチャ
  • サービス指向アーキテクチャ
  • マイクロサービスアーキテクチャ

分散アーキテクチャのメリット・デメリット
メリット
高いスケーラビリティ、パフォーマンス、可用性

デメリット
データの整合性・完全性の犠牲

アーキテクチャの選択例

• モノリシックか分散型化（判断要素例：単一のアーキテクチャセットか別々のアーキテクチャセットか）
  • モノリシックなら レイヤード か モジュラーモノリス か（両者の違いは技術視点で層を分割するか、ドメイン視点で層を分割するかの違い？）

データアーキテクチャ

定義
組織のデータ要件を特定し、それに基づいてデータモデルやデータストア、データフローなどの構成要素を設計し、データの有用性、効率性、信頼性、セキュリティを確保するためのプロセス。

目的
データの一貫性と信頼性の向上
データの標準化、品質管理、整合性の維持などの手法を用いて、データの正確性と信頼性を向上させる。

データマネジメント
効率的に管理するために設計とルールを提供する。データの組織化、分類、分割、保管、アクセスの仕組みを整備することで、データの取得や利用、変更、削除などを効率的に行う。

柔軟性と拡張性の確保
データの構造や統合方法の設計において、将来の拡張や新しい要件への対応を考慮することで、システムやプロセスの変更がスムーズに行える。

リスクの軽減とセキュリティの向上
データの保護策やアクセス制御の仕組みを設計し、データの機密性や完全性を確保することで、セキュリティリスクを軽減させる。

データアーキテクチャの設計プロセスでの成果物

エンタープライズデータモデル
エンティティ（データの種類や要素）、属性（データの特徴）、関係性（データ間の関連や結びつき）などを定義する。

データアーキテクチャデザイン
組織やシステムにおけるデータの構造、組織、および関係を計画的に設計するプロセス。

考慮する要素

• データモデル
  データの構造や関係を定義するためのモデルです。エンティティ、属性、関係、およびデータの流れを表現することがあります。適切なデータモデルを設計することで、データの生合成や一貫性を確保

• データストレージ
  データベースシステム、データウェアハウス、データレイク、クラウドストレージなどがある。

• データ統合
  異なるデータソースやシステムからのデータを統合し、一貫性のあるデータセットを作成するプロセス。

• データセキュリティとプライバシー
  アクセス制御、暗号化、監査などのセキュリティメカニズムを組み込む

データフロー
データがシステムやプロセス内でどのように移動し、変換されるかを示す概念。
データーフロー図やデータフローダイアグラムは要素を視覚的に表現できる。データフローの可視化によってデータの流れを理解しやすくなる。

データバリューチェーン
データを収集、加工、利活用する一連のプロセスを指す概念。データをビジネス価値に変換するための手順やステップを示す。