Contents
- 1 リスクマネジメント
- 2 ITIL
- 3 解決プロセス
- 4 総合的制御プロセス
- 5 RCM
- 6 RPA
- 7 WBS
- 8 マトリックス組織
- 9 EA
- 10 CAD
- 11 CAM
- 12 SLA
- 13 RFI
- 14 RFP
- 15 NDA
- 16 SaaS
- 17 ソフトウェアライフサイクルプロセス
- 18 SoE
- 19 SoR
- 20 アジャイル開発
- 21 コンカレントエンジニアリング
- 22 リバースエンジニアリング
- 23 UML
- 24 親和図法
- 25 PMBOK
- 26 アローダイアグラム
- 27 ガンチャート
- 28 UX
- 29 UI
- 30 スケールアウト
- 31 スケールアップ
- 32 サイト設計書ハンズオン
- 33 マーメイド(Mermaid)で表現可能な図の種類と向いてるケース
リスクマネジメント
リスクマネジメントのプロセス
- コミュニケーション及び協議
- 適用範囲,状況及び基準
- リスクアセスメント
- リスク特定 … リスクを洗い出し
- リスク分析 … 発生頻度・確率などを分析、被害を検討
- リスク評価 … 受容可能か判断
- リスク対応
- モニタリング及びレビュー
- 記録作成及び報告
対処方法
- リスク回避:リスクの発生原因を元から絶ったり、別の手段に変更して、リスクの発生を防ぎます。
- リスク移転、リスク共有、リスク転嫁:情報システムの運用を他社に依頼したり、保険に加入するなどして、リスク発生時の損失を他者に肩代わりさせます。
- リスク低減、リスク軽減
代替のシステムを用意するなどし、リスクの発生率を減らします。
- リスク保有、リスク受容:リスク対策費用のほうが大きくなる場合、リスク対策を行わない
ITIL
- ITIL(Information Technology Infrastructure Library)とは、
- ITSM(ITサービスマネジメント)のベストプラクティス
解決プロセス
インシデント管理
- インシデント発生時に、応急処置
- チャットボット
問題管理
インシデントの根本的解決
総合的制御プロセス
構成管理
サービスを体系化
変更管理
変更が与える影響をを考慮してリリースを承認
リリース管理
変更管理プロセスで承認された変更作業を行うスケジュール、手順を管理して実装
RCM
- リスクコントロールマトリクス
- リスクの低減の程度を評価
RPA
- RPA(Robotic Process Automation)
- 人がしていた、定型的な事務作業のソフトウェアによって自動化
WBS
コスト見積もり、スケジュール作成を行えるレベルまで要素分解
マトリックス組織
技能部門と事業を遂行する部門、両方に所属
EA
- エンタープライズアーキテクチャ
- 企業構造の計画
- ギャップ分析で理想との差を埋める
CAD
- Computer Aided Design
- コンピュータ支援設計
- コンピュータで設計、作図
- データの管理や共有、修正、再利用
CAM
- Computer Aided Manufacturing
- コンピュータ支援による製造
SLA
- SLA(Service Level Agreement:サービスレベル契約)
- サービスの提供者がサービスの品質を保証する契約
- サービス提供者とその利用者との間で交わされる
SLM
- SLM(Service Level Management:サービスレベル管理)
- SLAに基づいて、サービスの品質を継続的・定期的に点検・検証
RFI
- 情報提供依頼書(Request for Information)
- ベンダの技術を情報収集

RFP
- RFP(Request For Proposal:提案依頼書)
- システムの発注元の企業が開発ベンダに提出される文書
- システムの概要や調達条件等を明示
NDA
- NDA(Non-Disclosure Agreement:秘密保持契約)
- 機密情報を取引先に公開する際に、目的以外で使用や漏洩したりすることを防ぐための契約
SaaS

ソフトウェアライフサイクルプロセス
ソフトウェアライフサイクルプロセスとは、企画、要件定義、開発、運用、保守のそれぞれのプロセスについて、各プロセスで行うべきことをまとめたガイドラインです。

- 企画プロセス:システム化方針を査定し、システム化計画を作成。開発順序や概算コスト、費用対効果やリスク、納期
- 要件定義:業務上実現すべき性能や、機能などを明確にし、業務要件を定義
- 開発
- システム開発:要件定義、方式設計、結合、適格性確認
- ソフトウェア実装:要件定義、方式設計、構築、結合、適格性確認
- 運用
- 保守
結合テスト
モジュールをつなげてテスト
システムテスト
定めた性能をチェック
受入れテスト
- 仕様書の内容を満たしているかチェック
- 利用者主体
回帰テスト
- リグレッションテスト
- 修正した時、修正箇所以外に問題が発生していないかテスト
SoE
- System of Engagement
- 企業とユーザをどう繋ぐかを重視したシステム
SoR
- System of Record
- 企業内の情報を安全に運用管理することを重視したシステム
アジャイル開発
ソフトウェア開発プロセスのプログラミングやテストを重視し、要件定義やシステム設計を柔軟に見直しながら進めていく手法です。
イテレーション
- アジャイル開発で繰り返す工程の単位
- 繰り返すことで、システムの完成度を高めます。
XP
- エクストリーム・プログラミング
- ソフトウェア品質を向上させ、変化する顧客の要求への対応力を高める
- ペアプログラミング、リファクタリング推奨
- 変更や削除の勇気
ペアプログラミング
二人1組、コーディングとレビュー
リファクタリング
- 内部構造をすっきり
- メンテナンス性向上
- 外から見て影響がないように作業
スクラム
- アジャイル開発の手法の一つ
- 3つのロール
- プロダクトオーナ
- 開発チーム
- スクラムマスタ
- 5つのイベント
- スプリント
- スプリント計画
- デイリースクラム
- スプリントレビュー
- スプリントレトロスペクティブ
- 3つの作成物
- スプリントバックログ
- プロダクトバックログ
- インクリメント
コンカレントエンジニアリング
各プロセスを並行して進める

リバースエンジニアリング
既存のシステムを解析 → 設計
UML
オブジェクト指向型のシステム開発の記法
- 構造を表現: クラス図
- 振る舞いを表現: シーケンス図
クラス図

アクティビティ図

親和図法
似たものをグループにまとめて問題解決
PMBOK
- プロジェクト管理の手法をまとめたもの
- 10種類の知識エリア
- プロジェクト統合マネジメント
- プロジェクト検証
- プロジェクト・スコープ・マネジメント
- プロジェクトの成果物と作業の過不足を管理
- プロジェクト・スケジュール・マネジメント
- プロジェクト・コスト・マネジメント
- プロジェクト品質マネジメント
- 品質を保つ
- プロジェクト資源マネジメント
- プロジェクト・コミュニケーション・マネジメント
- プロジェクト・リスク・マネジメント
- プロジェクト調達マネジメント
- プロジェクト・ステークホルダー・マネジメント
プロジェクト検証
- 初めに作る
- プロジェクト統合マネジメントでつくる
- プロジェクトの取り決め
アローダイアグラム

ガンチャート
UX
- User Experience
- 優れたインターファイスを利用することで得られるポジティブな概念
UI
User Interface
スケールアウト
サーバの台数を増やす
スケールアップ
サーバをより高性能のものに変える

サイト設計書ハンズオン
Markdown(.md)で設計書をまとめる
Markdownファイルでまとめるメリットがあります。
- .md ファイルはVSCodeのプレビュー機能で確認
- GitHub上では .md が自動でHTMLに変換されて綺麗に表示、ドキュメントとしてそのまま使える(README.md)
- リンクや画像も埋め込める
- Markdown → PDF変換も可能
- 構造化してまとめることができる
/project-docs
├── README.md ← 全体概要やリンクまとめ(GitHubのトップにも)
├── overview.md ← プロジェクトの目的・背景・構成概要
├── setup.md ← 環境構築(Next.js / PHP / Docker)
├── deploy.md ← デプロイ手順(手動・git pullなど)
├── structure.md ← ディレクトリ構成・技術スタック説明
├── url-mapping.md ← URL設計・CMS連携などの一覧
├── process-flow.md ← 処理フロー・ページ生成・API連携など
└── faq.md ← よくある質問・トラブルシュートなど
overview.md
# プロジェクト概要
## プロジェクトの目的・概要
本プロジェクトは、もともと外部制作されたPHPベースのWebサイトを、
自社内で保守・運用・再構築しているWebアプリケーションです。
Next.js による静的生成(SSG)と、既存の PHP 構成を組み合わせたハイブリッド構成で運用しています。
## なぜ再構築したのか
- ビュー(HTML)と PHP のバックエンド処理が混在しており、保守性が低かった
- 共通パーツがモジュール化されておらず、修正コストが高い
- SSR(PHP)構成では表示速度やSEOに課題があり、
Webサイトパフォーマンスを強化するため Next.js の SSG を採用
## 技術スタック
| 技術 | 役割 |
|------------|------------------------------------------------------------------|
| PHP | 旧来のフォームページやバックエンド処理 |
| Next.js | SSGによる静的サイトの高速表示(トップページやSEO記事) |
| WordPress | ヘッドレスCMSとして使用し、Next.js側でGraphQL経由でコンテンツ取得 |
| Git | バージョン管理 |
| Docker | ローカル開発環境の構築(PHP + Apache) |
setup.md
# 環境構築手順
## ローカル開発環境(Next.js)
Next.js の開発環境は以下の手順でセットアップできます。
### 手順
1. **Node.js / NVM / npm をインストール**
- Node.js の推奨バージョン(例:18.x など)をインストール
- `nvm` を使うと複数バージョンの管理が楽になります
2. **プロジェクトリポジトリをクローンして移動**
```sh
git clone https://github.com/your-org/your-project.git
cd your-project/frontend
```
3. **依存パッケージをインストール**
```sh
npm install
```
4. **開発サーバーを起動**
```sh
npm run dev
```
http://localhost:3000 でNext.jsの開発環境が確認できます。
---
### Next.jsの環境変数
- `frontend/.env.local` にAPIキーやWordPressのエンドポイントなどを記載します。
- 例:
```env
NEXT_PUBLIC_API_URL=https://your-wp-site/graphql
NEXT_PUBLIC_API_KEY=your-api-key
```
---
## ローカル開発環境(PHP)
PHP部分の開発環境は Docker を使用して構築します。
### 手順
1. **Docker Desktop をインストールして起動**
- https://www.docker.com/products/docker-desktop/
- Windows の場合は **WSL2 の有効化** が必要です
2. **Docker設定ファイルを準備**
- `Dockerfile` および `docker-compose.yml` を、コーダードライブまたは所定の場所から取得して `backend/` ディレクトリに配置
3. **Dockerを起動**
```sh
cd backend
docker compose up -d
```
4. **ブラウザで確認**
```text
http://localhost:8080
```
---
### PHPの環境変数
- `.env` ファイルを使用する場合、`backend/.env` に設定を記載します
- 例:
```env
API_URL=https://api.example.com
DEBUG=true
```
---
deploy.md
# デプロイ手順
## デプロイ方法
Next.jsで生成された静的ファイルを、さくらのレンタルサーバーにアップロードして本番反映を行います。
---
### 1. SSGファイルをビルド
Next.js のプロジェクトルート(`frontend/`)で以下のコマンドを実行し、静的ファイルを出力します。
```sh
npm run build
npm run export
```
出力先の `out/` ディレクトリに HTML/CSS/JS ファイルが生成されます。
これらを本番環境の該当ディレクトリに**上書き配置**します。
---
### 2. 本番環境にSSH接続
```sh
ssh username@sakura.ne.jp
cd /path/to/project
```
※ `username` やパスはサーバー設定に応じて変更してください。
---
### 3. Git操作(本番サーバー上)
```sh
git pull origin main
```
または必要に応じて、特定のタグ・ブランチを指定して pull してください。
更新内容が静的ファイルに反映されていれば、公開が完了です。
---
> 注意:`out/` ディレクトリは **ビルド済み静的ファイル** なので、サーバーにあるものと差し替える必要があります。旧ファイル削除やパーミッションに注意。
マーメイド(Mermaid)で表現可能な図の種類と向いてるケース
VSCodeではマーメイド図をプレビューで確認できます、PDF出力も可能で、便利です!
以下が代表的なものだ:
図の種類 | 用途 | 適用例 |
---|---|---|
flowchart | フロー制御のざっくり説明(if/elseや順番など) | 簡易な処理の流れ、問い合わせ対応フローなど |
sequenceDiagram | 時系列ベースの通信・イベント順序 | フロント→バック→APIのPOST処理とか |
stateDiagram | ステート遷移(UI/ワークフロー向き) | 入力ステップ遷移、確認→完了画面とか |
classDiagram | クラスや構造の説明 | モデル設計やオブジェクト構成 |
entityRelationshipDiagram | DB構造(ER図) | フォームデータがDBにどう保存されるか |
断片的な実装混在案件なら、sequenceDiagram一択。
- フロント(Next.js SSG)
- フォーム表示・送信
- PHPバックエンド
- 外部APIへのPOST
flowchart(フローチャート)
処理の流れをざっくり追いたい時。条件分岐や処理の全体像を把握するのに使う。
✘ 欠点:どこで誰が処理してるかまでは不明瞭(PHPなのかJSなのかなど)
✔ 使いどころ:フォーム入力→バリデーション→分岐(成功 or エラー)→外部API呼出→結果処理、みたいな処理フロー
entityRelationshipDiagram(ER図)
✅ 生成AIに依頼する場合の手順
① 必須ファイルの添付
form.tsx
/form.html
(フォームのUIコード)api.php
など(バックエンド処理)- Next.js側の
getStaticProps
や API Routes(あるなら) - 外部APIの呼び出しコード(curlかaxiosか知らんが)
② 指示例(テンプレ)
このフォーム処理全体の処理フローを、Mermaidの`sequenceDiagram`形式で出力してください。
要件:
- ユーザーがフォームを開いて入力、送信するまで
- バックエンド(PHP)で受信・バリデーション
- 外部APIにPOSTリクエスト送信
- 処理結果に応じてサンクスページ or エラーメッセージ表示
添付ファイルに、フロント、バックエンド、外部連携のソースコードを含めています。