未来への一歩

ソフトウェアアーキテクチャレビュー — 全体を俯瞰する

ShimaLinkが1年を迎えた今、コードベース全体を見直す時が来た。

Yuki: 「アーキテクチャは建物の設計図。1年間の増築で歪みが出ていないか、一度立ち止まって確認しよう。」

アーキテクチャとは？

ソフトウェアアーキテクチャとは、システム全体の構造と、各部品がどう連携するかの設計図です。

ShimaLinkのアーキテクチャ（1年目の状態）:

[ブラウザ] → [CDN] → [フロントエンド (React)]
                          ↓
                    [APIサーバー (Express)]
                    ↙        ↘
            [PostgreSQL]   [Redis]
                    ↘        ↙
                   [外部API]
                   (AI, メール, 決済)

アーキテクチャパターン

モノリス（Monolith）

すべてが1つのアプリケーション:
┌─────────────────────────┐
│   フロントエンド          │
│   API                    │
│   ビジネスロジック        │
│   データアクセス          │
└─────────────────────────┘

マイクロサービス（Microservices）

機能ごとに独立したサービス:
┌────────┐ ┌────────┐ ┌────────┐
│ 店舗   │ │ 予約   │ │ レビュー│
│サービス │ │サービス │ │サービス │
└────────┘ └────────┘ └────────┘
     ↕          ↕          ↕
    [メッセージキュー / API Gateway]

Yuki: 「ShimaLinkの規模ならモノリスで十分。マイクロサービスは大規模チーム向け。早すぎる分割は悪手だよ。」

SOLID原則

良いアーキテクチャの基盤となる5つの原則。

実践: 単一責任の原則

// 悪い例: 1つのファイルに複数の責任
// shopController.ts
export class ShopController {
  async getShop() { /* HTTPレスポンス処理 */ }
  async calculateRevenue() { /* 売上計算ロジック */ }
  async sendNotification() { /* メール送信 */ }
  async generateReport() { /* PDF生成 */ }
}

// 良い例: 責任を分離
// controllers/shopController.ts — HTTPリクエストの処理
// services/revenueService.ts — 売上計算のビジネスロジック
// services/notificationService.ts — 通知の送信
// services/reportService.ts — レポートの生成

レイヤードアーキテクチャ

┌─────────────────────────────┐
│  Presentation Layer          │ ← ルーター、コントローラー
│  (リクエスト/レスポンス処理)   │
├─────────────────────────────┤
│  Application Layer           │ ← ユースケース、ワークフロー
│  (ビジネスロジックの調整)     │
├─────────────────────────────┤
│  Domain Layer                │ ← エンティティ、バリデーション
│  (ビジネスルール)             │
├─────────────────────────────┤
│  Infrastructure Layer        │ ← DB、外部API、ファイルシステム
│  (技術的な実装詳細)           │
└─────────────────────────────┘

技術的負債の管理

1年間の開発で溜まった「後で直す」リストを整理しよう。

# 依存パッケージの更新確認
npm outdated

# セキュリティ脆弱性の確認
npm audit

ポイント

• アーキテクチャはシステムの設計図。定期的に見直す
• ShimaLink規模ならモノリスが適切。早すぎるマイクロサービス化は避ける
• SOLID原則で保守しやすいコードを書く
• レイヤードアーキテクチャで責任を分離する
• 技術的負債は避けられないが、管理はできる

オープンソース貢献 — コミュニティに恩返しする

ShimaLinkは多くのOSSライブラリに支えられている。今度は自分たちが貢献する番だ。

Yuki: 「React、Express、PostgreSQL——全部オープンソース。私たちはその恩恵を受けてShimaLinkを作った。次はコミュニティに返す番だよ。」

オープンソースとは？

ソースコードが公開され、誰でも使用・修正・配布できるソフトウェアです。

ShimaLinkが使っているOSS

貢献の種類

コードを書くだけが貢献ではない。

最初の貢献（First Contribution）

Step 1: 貢献するプロジェクトを見つける

探す場所:
- GitHub の "good first issue" ラベル
- "help wanted" ラベル
- 自分が使っているライブラリのIssue
- https://goodfirstissue.dev/

Step 2: リポジトリをフォーク＆クローン

# 1. GitHubでForkボタンを押す

# 2. フォークをクローン
git clone https://github.com/YOUR_NAME/project.git
cd project

# 3. アップストリームを設定
git remote add upstream https://github.com/ORIGINAL/project.git

# 4. ブランチを作成
git checkout -b fix/typo-in-docs

Step 3: 変更を加えてPRを作成

# 変更を加える
# ...

# コミット
git add .
git commit -m "docs: fix typo in installation guide"

# フォークにプッシュ
git push origin fix/typo-in-docs

# GitHubでPull Requestを作成

Step 4: PRの書き方

## 概要
インストールガイドの誤字を修正しました。

## 変更内容
- `npm instal` → `npm install` の修正
- コマンド例のインデントを統一

## 関連Issue
Fixes #1234

## テスト
- [x] ドキュメントのビルドが通ることを確認

コミットメッセージの規約

多くのOSSプロジェクトはConventional Commitsを採用しています。

自分のOSSプロジェクトを公開する

ShimaLinkで作ったユーティリティを公開してみよう。

# 新しいリポジトリを作成
mkdir shimalink-date-utils
cd shimalink-date-utils
npm init -y

# ライセンスを追加（MIT推奨）
# LICENSE ファイルを作成

# READMEを書く
# - プロジェクトの説明
# - インストール方法
# - 使い方の例
# - ライセンス

# npmに公開
npm publish

ライセンスの基本

Yuki: 「迷ったらMITライセンス。ShimaLinkの共有ライブラリもMITで公開しよう。」

ポイント

• OSS貢献はコードだけじゃない。ドキュメント改善やバグ報告も立派な貢献
• “good first issue” ラベルのIssueから始める
• フォーク → ブランチ → 変更 → PR の流れを覚える
• Conventional Commitsでコミットメッセージを統一する
• 自分のライブラリをOSSとして公開する経験は大きな成長になる

テックキャリアパス — エンジニアとしての道

ShimaLinkの経験を積んだ今、エンジニアとしてのキャリアを考える時が来た。

Yuki: 「技術を学ぶことと、キャリアを作ることは別の話。自分の強みと興味を知って、進む道を選ぼう。」

エンジニアのキャリアパス

                    ┌──── CTO / VP of Engineering
                    │
              ┌─────┤
              │     └──── Engineering Manager
              │
  Junior ── Mid ── Senior ──┤
                            │
                            ├──── Staff Engineer
                            │
                            └──── Principal Engineer

2つのトラック

Yuki: 「マネージャーにならなくても、技術のスペシャリストとしてキャリアを伸ばせる。どちらが正解ということはない。」

エンジニアの専門分野

ポートフォリオの構築

ShimaLinkの経験をどうアピールするか。

GitHubプロフィール

# あなたの名前

## ShimaLink — 沖縄のローカルビジネスプラットフォーム
- React + TypeScriptでフロントエンドを構築
- Express + PostgreSQLのREST API設計
- Docker + GitHub Actionsでci/CDパイプライン構築
- OpenAI APIを統合したAI機能の実装

🔗 [デモ](https://shimalink.example.com)

技術ブログ

学んだことを記事にすることで、知識が定着し、アウトプットの実績になる。

記事のアイデア:
- 「ShimaLinkを1年運用して学んだこと」
- 「N+1問題を解決してAPIが100倍速くなった話」
- 「AIチャットボットを自作した記録」
- 「初めてのOSS貢献で学んだこと」

技術面接の準備

STAR法の例

質問: 「困難な技術的課題をどう解決しましたか？」

S（状況）: ShimaLinkのピーク時にページ表示が8秒かかっていた
T（課題）: 2秒以下に改善する必要があった
A（行動）: Lighthouseで計測し、DBインデックス追加、画像最適化、
          Redis キャッシュ導入を実施
R（結果）: 1.8秒に改善、ユーザークレームがゼロに

フリーランスという選択肢

Yuki: 「私はフリーランスだけど、最初は企業でしっかり基礎を身につけた。どちらのルートも正解。大事なのは自分の価値を高め続けること。」

ポイント

• エンジニアのキャリアにはマネジメントとテクニカルの2トラックがある
• 自分の強み・興味に合った専門分野を見つける
• GitHubプロフィール、技術ブログ、ポートフォリオで実績を可視化
• 面接準備はコーディング、システム設計、行動面接の3本柱
• キャリアの正解は1つではない。学び続けることが最大の強み

継続的な学習 — エンジニアの成長戦略

技術の世界は常に変化する。大事なのは「学び方を学ぶ」こと。

Yuki: 「1年前、あなたはターミナルも知らなかった。でも今、AIを統合したサービスを運用している。この”学ぶ力”こそが最大の武器。」

学習のフレームワーク

T型スキル

  広い知識（浅く広く）
──────────────────────
          │
          │  深い専門性
          │  （1つの領域を深く）
          │
          │

70-20-10の法則

効果的な学習戦略

1. 公式ドキュメントを読む

最も信頼できる情報源:
- React: react.dev
- TypeScript: typescriptlang.org
- Node.js: nodejs.org/docs
- PostgreSQL: postgresql.org/docs

Yuki: 「ブログ記事やQiitaも参考になるけど、まずは公式ドキュメント。古い記事の間違った情報に惑わされないためにも。」

2. 手を動かして学ぶ

効果的な学習サイクル:
1. 概念を読む（10分）
2. 実際にコードを書く（30分）
3. 壊してみる（10分）
4. 直してみる（10分）
5. 自分の言葉で説明する（10分）

3. アウトプットする

4. コミュニティに参加する

沖縄のテックコミュニティ:
- もくもく会（黙々と作業する会）
- LT（ライトニングトーク）イベント
- ハッカソン
- オンライン: Discord, Slack, X (Twitter)

今後注目すべき技術トレンド

学習のアンチパターン

ShimaLinkの旅で学んだこと — 全25チャプターの振り返り

Ch.01-05 [創業期]  基礎の基礎
├── ターミナル、HTML/CSS、Git、HTTP
├── 最初のクライアント、デプロイ
└── 学び: 小さく始めて、まず動かす

Ch.06-10 [成長期]  技術スタックの拡充
├── JavaScript、TypeScript、API設計
├── データベース、認証
└── 学び: 正しい技術選択が成長を加速する

Ch.11-15 [試練期]  品質とセキュリティ
├── React、状態管理、パッケージ管理
├── バージョン管理、セキュリティ
└── 学び: 守るべきものがあるから、強くなれる

Ch.16-20 [拡張期]  インフラとDevOps
├── Docker、CI/CD、クラウド
├── チーム開発、モニタリング
└── 学び: 自動化と監視が安定運用の鍵

Ch.21-25 [飛躍期]  さらなる高みへ
├── Python自動化、テスト、パフォーマンス
├── AI統合、アーキテクチャ、キャリア
└── 学び: 学び方を学べば、何でも身につけられる

最後に

エンジニアとして最も大切なこと:

1. 好奇心を持ち続ける
2. 手を動かして学ぶ
3. 失敗を恐れない
4. コミュニティに貢献する
5. 学び続ける

Yuki: 「技術は変わるけど、学ぶ力は一生もの。あなたはこの1年で、その力を手に入れた。次の冒険が楽しみだね。」

ポイント

• T型スキル: 広い知識 + 1つの深い専門性
• 70-20-10: 実践70%、他者から20%、座学10%
• アウトプット（ブログ、登壇、OSS）で知識を定着させる
• チュートリアル地獄を避け、自分のプロジェクトで実践する
• 学び方を学ぶことが、エンジニアの最大の武器

$ git log --oneline | tail -1
a1b2c3d ShimaLinkの最初のランディングページを作成

$ git log --oneline | head -1
f9e8d7c AI紹介文ジェネレーター v2.0をリリース

$ git log --oneline | wc -l
     1,247