開発技術 on モリサキブログ

Kotlin Multiplatform、2025年の現状を調べてみた

Mon, 08 Dec 2025 00:00:00 +0000

「Kotlin/Nativeってまだ実験的でしょ？」

そう思って3年ぶりに調べてみたら、2025年にはKotlin Multiplatform（KMP）全体が完全に別物になっていた。

2022年頃に触ったときは「将来性はあるけど、iOSの並列処理が死んでるし…」って感じで諦めたのだが、気づいたら大手企業が本番環境で採用し、技術的な問題もほぼ解決されていた。

この記事では、Kotlin Multiplatformが2025年時点でどこまで進化したのか、何ができて何ができないのかを、事実ベースで整理していく。

Kotlin Multiplatformって何？

まず基本から。Kotlin Multiplatform（KMP）は、Kotlinコードを複数プラットフォームで共有する技術の総称だ。

KMPの構成

KMPは以下の要素で構成されている：

Kotlin/Native – iOS/macOS等でビジネスロジックをネイティブバイナリにコンパイル
Kotlin/JVM – Android/サーバー向けのJVMバイトコード生成
Kotlin/JS – Web向けのJavaScript生成
Compose Multiplatform – UI共通化フレームワーク（オプション）

この記事で主に扱うのはKotlin/Nativeの進化だ。

Kotlin/Nativeの立ち位置

重要なのは、Kotlin/NativeはUI技術ではないということ。

Kotlin/Nativeの役割はビジネスロジックを共通化すること。

つまり：

API通信
データベース処理
認証ロジック
バリデーション
ビジネスルール
データ変換

こういった「UIに依存しない部分」を一度書けば、全プラットフォームで動く。

実際の使われ方

2025年現在、主流の構成：

【Android】
UI: Jetpack Compose
ビジネスロジック: Kotlin/Native ← 共通

【iOS】
UI: SwiftUI
ビジネスロジック: Kotlin/Native ← 共通

【Web】
UI: React / Vue
ビジネスロジック: Kotlin/Wasm ← 共通

UIは各プラットフォームのネイティブ技術を使い、ビジネスロジックだけKotlin/Nativeで共通化する。

これがFlutterやReact Nativeとの最大の違いだ。

※補足：Compose Multiplatformを使えばUIも共通化できるが、2025年現在の主流は「ネイティブUI + Kotlin/Native」という構成。

対応プラットフォーム（2025年12月時点）

Android – 完璧に対応

Firebase開発環境統一の完全ガイド – コンソール操作から脱却してCI/CD自動化まで

Thu, 27 Nov 2025 00:00:00 +0000

Firebase開発をしていると、開発環境と本番環境の管理が煩雑になりがちです。最初はコンソールでポチポチ設定していたものの、「あれ？開発と本番で設定が違う…」「デプロイのたびにコンソール操作するの面倒…」と感じることが増えてきました。

今回は、手動のコンソール操作から完全自動化まで、実際の開発体験を交えて環境統一の方法を紹介します。

📱 対象プロジェクト Firebase Functions + Firestore + Storage + Hosting + Extensions を使ったクイズアプリ

GitHub - morisakisan/quiz_firebase_functions

クイズアプリのFirebase Functions実装リポジトリ

github.com

Firebase開発で環境を分ける場合、開発用と本番用で別々のFirebaseプロジェクトを作るのが一般的です。しかし、これが意外と管理が大変なんです。

😅 よくある問題 「開発環境で動いてたのに本番で動かない…」「あれ？Firestoreのルール設定、本番に反映し忘れた」「Extensionsの設定、手動で両方に設定するの忘れそう…」

手動でのコンソール操作は楽ですが、環境が増えるほど管理が困難になります。設定の差異、デプロイミス、属人化など、様々な問題が発生しがちです。

最初は開発環境でコンソールで直接

開発初期は、Firebase Consoleでの手動設定が一番楽です。

// 開発中の典型的な流れ
1. Firebase Console でプロジェクト作成
2. Authentication で Google ログイン有効化
3. Firestore でデータベース作成
4. Storage でバケット作成
5. Functions をコンソールからデプロイ

この段階では全てが順調です。コンソールの UI は直感的で、設定も簡単。「Firebase最高！」と思える瞬間です。

本番環境への手動複製で問題発生

しかし、本番環境を作る段階で問題が見えてきます。

// 本番環境作成時の作業
1. 新しいFirebaseプロジェクト作成
2. 開発環境と同じ設定を手動で再現
3. Firestoreのルールをコピペ
4. Storageのルールもコピペ
5. Extensionsも手動でインストール

💸 実際にあった問題 「本番環境のFirestoreルール設定し忘れて、セキュリティホールが…」「Extensionsの環境変数、開発と本番で微妙に違ってた」「どっちが正しい設定だっけ？」

Freezed入門：Flutterで型安全なモデル設計

Mon, 29 Sep 2025 00:00:00 +0000

Flutterアプリ開発において、データクラスの作成で冗長なコードを書いていませんか？equals、hashCode、toString、copyWithメソッドを手動で実装するのは面倒で、バグの温床にもなりがちです。そんな問題を解決してくれるのがFreezedです。

今回は、実際のクイズアプリプロジェクトを例に、Freezedを使った型安全なモデル設計の実践方法を紹介します。

参考プロジェクト：https://github.com/morisakisan/share_quiz

Freezedとは何か？

Freezedは、Dartでimmutable（不変）なデータクラスを簡単に作成できるコード生成ライブラリです。アノテーションを使って宣言するだけで、equals、hashCode、toString、copyWithなどのメソッドを自動生成してくれます。また、JSON serialization/deserializationにも対応しており、APIとの連携も簡単に行えます。

使い所

Freezedは主にデータモデルクラスの作成に使用します。特にFirestoreなどのデータベースとの連携、API通信でのデータ転送、状態管理でのデータ保持など、アプリケーション全体でデータを安全に扱いたい場面で威力を発揮します。immutableなオブジェクトを簡単に作成できるため、予期しないデータ変更を防ぎ、バグの少ない堅牢なアプリケーションを構築できます。

ライブラリの読み込み

pubspec.yamlに以下を追加します：

dependencies:
 freezed_annotation: 3.1.0

dev_dependencies:
 freezed: 3.2.3
 build_runner: 2.8.0
 json_serializable: 6.11.1 # JSON対応が必要な場合

実際のコード例

ここからは、実際のクイズアプリプロジェクトで使用しているFreezedのコードを見ていきましょう。Clean Architectureを採用したプロジェクトで、domain層とdata層でFreezedを活用している例です。

ドメインモデルでの基本的な使用

アプリのコアとなるQuizモデルの例です。

import 'package:flutter/foundation.dart';
import 'package:freezed_annotation/freezed_annotation.dart';

part 'quiz.freezed.dart';

@freezed
abstract class Quiz with _$Quiz {
 const factory Quiz({
 required String documentId,
 required String title,
 required String question,
 required List choices,
 required int correctAnswer,
 required DateTime? createdAt,
 required double? correctAnswerRate,
 required int? answerCount,
 required int? goodCount,
 required List imageUrls,
 }) = _Quiz;
}

ポイント：

RxDart入門：Flutterでリアルタイムデータ管理の完全ガイド

Wed, 24 Sep 2025 00:00:00 +0000

Flutterアプリ開発において、複数のデータソースを効率的に管理したいと思ったことはありませんか？Firebase AuthとFirestoreのデータを同時に監視して、リアルタイムに画面を更新したい場面などで威力を発揮するのがRxDartです。

注意：現在はpackage:asyncのStreamGroupという選択肢もあり、シンプルなStream結合であればそちらの方が適しているケースもあります。

今回は、実際のクイズアプリプロジェクトを例に、RxDartの基本的な使い方を紹介します。

参考プロジェクト：https://github.com/morisakisan/share_quiz

RxDartとは何か？

RxDartは、ReactiveXのDart実装で、Flutterアプリケーションでリアクティブプログラミングを行うためのライブラリです。標準のDart StreamにRxの強力な機能を追加し、複数のデータソースを効率的に組み合わせることができます。

使い所

RxDartは主にリアルタイムデータなどに用いられるStreamを結合する時に使用します。例えば、Firestoreの複数のコレクションからのデータを組み合わせて、一つの画面で表示したい場合などです。Firebase Authの認証状態とFirestoreのデータを同時に監視し、ユーザーの状態に応じて画面の表示を動的に変更する際に威力を発揮します。

ライブラリの読み込み

pubspec.yamlに以下を追加します：

dependencies:
 rxdart: 0.28.0

そして、使用したいファイルでimportします：

import 'package:rxdart/rxdart.dart';

実際のコード例

ここからは、実際のクイズアプリプロジェクトで使用しているRxDartのコードを見ていきましょう。Clean Architectureを採用したプロジェクトで、Repository層でRxDartを活用している例です。

例1: 設定画面での基本的な使用

アプリの設定画面で、アプリ情報とユーザーのログイン状態を組み合わせる例です。

結合されるエンティティ：

class Setting {
 final PackageInfo packageInfo; // アプリのバージョン情報など
 final bool isLogin; // ユーザーのログイン状態
}

なぜ結合が必要？

設定画面では「アプリのバージョン情報」と「ログイン状態によって表示を変える項目」を同時に表示する必要があります。例えば、ログインしている場合のみ「ログアウト」ボタンを表示したり、ユーザー情報を表示したりするためです。

class SettingRepositoryImpl extends SettingRepository {
 final _userDataStore = FirebaseAuthStore();

 @override
 Stream fetch() {
 return CombineLatestStream.combine2(
 Stream.fromFuture(PackageInfo.fromPlatform()),
 _userDataStore.listenToUserChanges(),
 (info, user) => Setting(
 packageInfo: info, 
 isLogin: user != null
 )
 );
 }
}

ポイント：

Flutter Clean Architecture実装ガイド：構造からテストまで完全解説

Mon, 15 Sep 2025 00:00:00 +0000

FlutterアプリケーションでClean Architectureを実装する方法を、実際のクイズアプリを例に解説します。この記事では、理論だけでなく実践的な実装方法とハマりポイントも含めて紹介します。

📱 記事で使用したプロジェクト

GitHub: share_quiz

Google Play: クイズ共有アプリ

実際にリリースされているFlutterアプリのソースコードと動作を確認しながら読み進めることをお勧めします。GitHubでコードを参照し、Google Playで実際のアプリを体験できます。

Clean Architectureとは

Clean Architectureは、ソフトウェアの依存関係を整理し、保守性・テスタビリティを向上させる設計手法です。Flutterアプリケーションでは、UI・ビジネスロジック・データアクセスを明確に分離することで、変更に強いアーキテクチャを構築できます。

3つの主要レイヤー

┌───────────────────────────────┐
│ Presentation Layer │
│ (UI・状態管理・Provider) │
└─────────────┬─────────────────┘
 │ depends on
 ▼
┌───────────────────────────────┐
│ Domain Layer │
│ (Entity・UseCase・Repository) │
└─────────────┬─────────────────┘
 ▲ implements
 │
┌───────────────────────────────┐
│ Data Layer │
│ (Repository実装・DTO・API) │
└───────────────────────────────┘

依存性逆転の原則：

Presentation層はDomain層に依存
Data層はDomain層に依存
Domain層は他の層に依存しない

プロジェクト構成

Clean ArchitectureをFlutterで実装する際のディレクトリ構造を紹介します。各レイヤーを明確に分離し、依存関係を一方向に保つことが重要です。

lib/
├── data/ # データ層
│ ├── firestore/ # Data Store（Firestore）
│ ├── repository_impl/ # Repository実装
│ ├── mapper/ # DTO→Entity変換
│ └── storage/ # ストレージ関連
├── domain/ # ドメイン層
│ ├── models/ # エンティティ
│ ├── repository/ # Repository抽象化
│ └── use_cases/ # ユースケース
├── presentation/ # プレゼンテーション層
│ ├── common/ # 共通UI
│ ├── screen/ # 画面
│ └── widget/ # ウィジェット
└── provider/ # 状態管理

Domain層（ドメイン層）

Domain層は、アプリケーションのコアとなるビジネスロジックを含む層です。他の層に依存せず、純粋なDartコードで構成されます。エンティティ、Repositoryのインターフェース、ユースケースを定義します。

コードフォーマット論争はもうやめよう。IDEデフォルトで十分な理由

Fri, 05 Sep 2025 00:00:00 +0000

開発現場で働いていると、必ずと言っていいほど遭遇するフォーマット議論。「インデントは2スペース派vs4スペース派」「if文の後に空行入れるか問題」「アノテーションは改行すべきか論争」…。正直、こんな議論に時間使ってる間にバグ一個直せるよね？😅

フリーランスエンジニアとして色んなプロジェクトに参画してきた中で、「フォーマット警察」が開発効率を下げている現場を何度も見てきました。CIでフォーマットチェック失敗してPRブロック、独自ルール覚えるのに新人が1日潰す、レビューで本質的じゃない指摘ばかり…。

本当にそこまでフォーマットにこだわる必要あるの？現代の開発環境を踏まえて、改めて考えてみましょう。🤔

コードフォーマットとは何か

コードフォーマットとは、ソースコードの見た目やスタイルに関するルールのこと。具体的には：

インデント：スペースかタブか、何文字分か
改行とスペース：括弧の前後、演算子の周り
命名規則：camelCaseかsnake_case
構造的ルール：import文の順序、メソッドの並び順

Kotlinならktlint、JavaならGoogle Java Style、PythonならBlackみたいな自動フォーマッターが代表的ですね。

フォーマットの本来の意義

そもそもなぜフォーマットが重要視されるようになったのか？

チーム開発での統一性

複数人で開発する際、各自が勝手なスタイルで書くとコードが読みにくくなる。統一されたフォーマットで可読性向上。

レビュー効率の向上

スタイルが統一されていれば、レビュアーは本質的な部分（ロジック、設計）に集中できる。フォーマットの指摘に時間を取られない。

新メンバーの学習コスト軽減

プロジェクト固有のコーディングスタイルを覚える手間を減らし、新しいメンバーがすぐにコードを理解できる。

diffの見やすさ

フォーマットが統一されていると、Git diffで実質的な変更点が分かりやすくなる。

これらは確かに理にかなった理由です。しかし…

IDEの進歩が変えたフォーマット事情

昔と今では開発環境が大きく違います。

昔の開発環境（2000年代前半）

テキストエディタでのコーディングが主流
シンタックスハイライトも限定的
自動補完機能が貧弱
手動でのフォーマット管理が必須

現在の開発環境

強力なIDE：IntelliJ IDEA、Android Studio、VS Code
リアルタイム補正：タイプ中に自動でフォーマット
スマート機能：自動import、リファクタリング支援
統合された品質管理：リアルタイムエラー検出、警告表示

Android Studioを使っていれば、Ctrl+Alt+L一発で標準的なフォーマットに整形されます。わざわざ手動でぐちゃぐちゃなコードを書く方が難しい。

よくあるフォーマット論争の不毛さ

実際の現場でよく見る、時間の無駄な議論たち：

インデント戦争

// 2スペース派
if (condition) {
 doSomething()
}

// 4スペース派
if (condition) {
 doSomething()
}

結論：どっちでも読めます。

括弧の位置論争

// K&Rスタイル
if (condition) {
 
}

// Allmanスタイル 
if (condition)
{
 
}

結論：どっちでも読めます。

Androidプロジェクト改善術：10のモダンなTipsとハマり話

Thu, 04 Sep 2025 00:00:00 +0000

Androidプロジェクトにフリーランスエンジニアとして参画すると、「うわ、このコードちょっと古いな…」ってなること、ありますよね？😅 小規模チームだと特に、歴史的経緯で謎実装が残りがち。

でも、新機能追加や機能改善、リグレッションテストのタイミングでコツコツ（または一気に）リファクタリングすれば、ビルド時間短縮、コードのメンテナンス性アップ、開発スピード爆上げも夢じゃない！

ここでは、実際のプロジェクトでやった（orやりたかった）改善点を、リアルなエピソード交えて紹介します。全部一気にフルリプレイスしたわけじゃないので、キラキラ系エンジニアっぽく見えないはず（笑）。🚀

CircleCIからGitHub Actionsへ：全部GitHubでいいじゃん

課題

CircleCIは悪くないけど、並列実行増やすと課金圧が…。PRとの連携もちょっと面倒。依存関係の整理やビルド時間短縮を考えると、GitHubのエコシステムに統一したくなる。

改善

GitHub Actionsに移行。PRトリガーでテストやデプロイ自動化、Marketplaceのアクションで設定も楽。リグレッションテストのタイミングで一気にCI/CDパイプラインを移行した。

効果

無料枠で十分動くし、GitHubネイティブでPRやイシューとの連携がスムーズ。ビルドパイプラインがシンプルになった。

ハマった話

CircleCIのキャッシュ設定が恋しくなる瞬間はあった（笑）。でも、GitHub Actionsのキャッシュも慣れればOK。yamlの書き間違いで初回ビルド失敗したのは内緒だよ。😅

Tips

actions/setup-javaで環境構築、actions/cacheでビルド高速化。チームに「これで十分じゃん」って納得された。Marketplaceのアクションは宝の山！

DeployGateからFirebase App Distributionに移行：シンプルで無料！

課題

DeployGateを使ってたけど、コストがかかるし、もっとシンプルで無料のソリューションが欲しい。テスター管理や配布フローを効率化したい。

改善

Firebase App Distributionにデプロイを移行。GitHub Actionsでワークフロー作って、無料でスッキリ。CIを変更するだけで単独で進めた。

効果

コスト削減、ビルド安定、配布がスムーズに。Firebaseの直感的なUIとテスター管理で、チームのデプロイ作業も楽々。Crashlytics連携で安定性チェックも強化。

ハマった話

GitHub Actionsの設定ミスでビルド失敗連発。yamlのインデント地獄、わかるよね？😭 デバッグに半日溶けたのはいい思い出（？）。

Tips

Firebase CLIやwzieba/Firebase-Distribution-Github-ActionでCI/CD自動化。テスター招待はメールで簡単。Firebaseコンソールのグループ管理を活用すると吉。

謎のクリーンアーキテクチャもどき設計を本物に

課題

ViewModelとRepositoryだけの設計で、ViewModelにビジネスロジックがギッチリ詰め込まれて超肥大化😓 さらに、ViewModelがRoomのFlowを直で監視し、Flowが更新されるたびにViewがUIをリフレッシュする謎仕様。データ更新は「Roomのテーブル全クリア→APIからデータ再取得→Roomにインサート」の無駄なループで、キャッシュの意味ゼロ。Room周りのコードが散らかりバグの温床に。機能ごとにテーブル乱立で、DBスキーマはカオスそのもの。メンテするだけで頭痛い…。😅

改善

UseCaseを追加してビジネスロジックを分離、Repository＋StateFlowでデータ管理をシンプルに。過剰かつ意味ないRoom周りのコードも削除して、APIから都度取得する設計に変更。バグ修正や機能改善時にコツコツ移行。新機能実装時は初めから上記の設計でコーディング。

参考コード

以下は、Todoリストを取得するGetTodoUseCaseと、それをTodoViewModelで使って状態管理する例。RepositoryはシンプルにListを返し、UseCaseでResultをラップ。ViewModelは軽く、ビジネスロジックはUseCaseに任せてスッキリ！

package com.example.todo

import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
import dagger.hilt.android.lifecycle.HiltViewModel
import kotlinx.coroutines.flow.MutableStateFlow
import kotlinx.coroutines.flow.StateFlow
import kotlinx.coroutines.flow.asStateFlow
import kotlinx.coroutines.launch
import javax.inject.Inject

// ドメインモデル
data class Todo(val id: Int, val title: String, val isCompleted: Boolean)

// 結果型
sealed class Result {
 object Loading : Result()
 data class Success(val data: T) : Result()
 data class Error(val message: String) : Result()
}

// Repositoryインターフェース（data層の実装は省略）
interface TodoRepository {
 suspend fun getTodos(): List
}

// UseCase: Todoリスト取得のビジネスロジック、エラーハンドリング
class GetTodoUseCase @Inject constructor(
 private val repository: TodoRepository
) {
 suspend operator fun invoke(): Result> {
 return try {
 // Repositoryからデータ取得、Roomなしでシンプルに
 Result.Success(repository.getTodos())
 } catch (e: Exception) {
 Result.Error(e.message ?: "Failed to fetch todos")
 }
 }
}

// ViewModel: UseCaseを使って状態管理、ビジネスロジックは持たない
@HiltViewModel
class TodoViewModel @Inject constructor(
 private val getTodoUseCase: GetTodoUseCase
) : ViewModel() {
 private val _todoState = MutableStateFlow>>(Result.Loading)
 val todoState: StateFlow>> = _todoState.asStateFlow()

 fun fetchTodos() {
 viewModelScope.launch {
 _todoState.value = Result.Loading // ローディング開始
 _todoState.value = getTodoUseCase() // UseCaseでデータ取得
 }
 }
}

効果

ViewModelがUI状態管理に集中できるようになり、ビジネスロジックがUseCaseに集約されてテストしやすくなった。依存関係もスッキリして、コードレビューが楽に。バグも減った（気がする）。

Dependabotの運用課題と効率化のポイント

Sat, 15 Feb 2025 00:00:00 +0000

ソフトウェア開発において、依存ライブラリの管理はプロジェクトの安定性やセキュリティを確保する上で不可欠だ。Dependabotは依存関係の自動更新を支援するツールとして重宝されるが、運用には課題が山積している。プルリクエストの氾濫によるCI/CDリソースの圧迫、予期せぬエラーのリスク、テスト負担の増大など、単純に導入しただけでは問題が表面化する。

この記事では、Dependabotの利点と落とし穴を整理し、運用上の課題や代替手段、さらにはライブラリ更新の真の必要性について掘り下げる。開発者がDependabotを賢く活用し、生産性を維持するための現実的な視点を提示する。

更新の信頼性

マイナーアップデートやパッチアップデートでも予期せぬエラーが発生することがある。そのため、「パッチだから大丈夫」と油断せず、結局すべての更新で適切なテストが必要になる。特に依存ライブラリ同士の相性問題や非互換な変更が含まれる場合、動作確認なしにマージすると本番環境で障害を引き起こすリスクがある。

さらに、イシューをチェックして変更点を確認した上でマージしても、結局バグが発生するケースも起こりうる。これは、開発者が想定していない環境依存の問題や、他のライブラリとの相互作用による不具合が原因となることがある。したがって、DependabotのPRを単にマージするのではなく、実際の運用環境で十分にテストする必要がある。

DependabotのPRによるCI/CDコストの増加

Dependabotが生成するPRごとにCIパイプラインが実行されるため、頻繁なアップデートが続くとリソースを大幅に圧迫する。特に、ビルドやテストに時間がかかるプロジェクトでは、単一のライブラリ更新でも長時間のテストが走り、無駄な計算リソースの消費が発生する。複数のPRが並行するとCIサーバーのキューの遅延やクラウドサービスのコスト増大を招く。開発チームの規模が小さく、リソースが限られている場合、この負担は開発速度の低下や予算超過に直結する。

ライブラリ更新の失敗事例

Dependabotによる自動更新には注意が必要だ。安易にライブラリを更新すると、依存関係の問題が発生する。

たとえば、Reactを最新版にアップデートする際、既存のライブラリとのpeer dependency競合により、npm installが全て失敗するケースが頻発している。単純にReactだけ更新しても、関連ライブラリが対応していなければアプリケーション全体が動かなくなる。

こうした事例は、Dependabotの提案を鵜呑みにせず、段階的な更新と十分なテストが重要であることを示している。

ライブラリ更新のリスクと一括テストの工夫

Dependabotは依存関係の自動更新を提案してくれるが、個別のPRをそのままマージするのはリスクが高い。ライブラリの更新が互いに影響し合う場合や、環境依存の問題が潜んでいる可能性があるためだ。そこで、複数のライブラリをまとめて更新するIssueを作成し、一括で管理するアプローチが有効だ。

この方法なら、関連するライブラリの更新を一度にテストでき、個別マージによる部分的な不整合を防げる。さらに、テスト範囲が重複する部分をまとめて検証できるため、アプリケーション全体の動作確認を効率的に進められる。結果として、更新の影響範囲をしっかり把握した上でマージでき、複数ライブラリのエラーや相性問題も一気に洗い出せる。

ただし、複数のライブラリをまとめて更新すると、テスト範囲が広がり、結果的にアプリケーション全体のテストに近くなるケースが多い。理想的には、ライブラリの更新内容を見てテスト範囲を制限することも可能だが、実際には多くの場合、アプリケーションの主要な機能を一通り確認する必要がある。そのため、テストの負担が増えるのは避けられないが、リスクを考えれば仕方ない選択肢と言える。

Dependabotの代替手段

とはいえ、ライブラリのアップデート情報を自動で通知してくれるのは便利だ。手動で依存関係をチェックする手間が省けるし、セキュリティアップデートを見落とすことも減る。一方で、ライブラリのアップデートを確認する手段はDependabot以外にもある。例えば：

Web → Webpackやnpm/yarnのaudit機能で依存関係の更新を確認可能
Android → GradleのVersion Catalogで依存管理ができ、アップデートの追跡も容易
Python → pip list --outdated で古いライブラリをチェック可能
Node.js → npm outdated や yarn outdated でアップデート状況を確認

こうしたツールを活用すれば、わざわざDependabotに依存しなくてもライブラリのアップデート状況を把握できる。Dependabotは便利だが、プロジェクトによっては不要な場合もある。

言うほどライブラリのアップデートは急務か？

Dependabotのせいで無駄な作業が増えていると感じることもある。意識の高いエンジニアや几帳面な開発者は、常にライブラリを最新に保ちたくなる衝動に駆られがちだ。しかし、実際のところ、今のままで問題がなければ、ライブラリを無理に更新する必要はない。特に、セキュリティ上の問題がなければ、バージョンを上げること自体にほとんど意味はなく、逆に予期せぬリスクを招く可能性がある。

結果として、Dependabotの通知に無理に対応しようとすることで、意味のないリスク管理を強いられ、不要な作業が発生しているとも言える。アップデートすることが目的になってしまい、本来の開発作業の時間を削られるのは本末転倒だ。

Dependabotを使わない場合の運用方法

Dependabotを使用せず、ライブラリの更新を効率的かつ安全に管理するための手動運用方法を提案。

定期確認

毎月1回、チームで「依存関係メンテナンス」の時間を設け、ライブラリの更新状況を確認（例：npm、pip、Gradleの標準機能を使用）。

優先度に応じた対応

高優先度（セキュリティパッチなど）: Issueやタスクを立てて個別にテスト・適用。
低優先度（マイナーアップデートなど）: まとめてIssueを作成し、四半期ごとのメンテナンスウィンドウで一括更新。更新後は主要機能のリグレッションテストを実施。

ドキュメント化:

更新履歴や問題点をWikiやNotionに記録し、チームで共有。

Dependabotを使う場合の運用法

Dependabotを活用し、PRの氾濫やCI負荷を抑えつつ、効率的にライブラリを更新する運用方法を提案。

PRのグループ化

dependabot.ymlで更新頻度を「月1回」に設定し、関連ライブラリをグループ化してPR数を削減。

Node.jsの例

version: 2
updates:
 - package-ecosystem: "npm"
 directory: "/"
 schedule:
 interval: "monthly"
 groups:
 frontend-libs:
 patterns:
 - "react*"
 - "@types/react"
 update-types:
 - "minor"
 - "patch"

これで、React関連の更新が1つのPRにまとまり、CI負荷とテスト負担が軽減。

スカッシュマージのデメリットと解決策｜Issue単位運用の実践ガイド

Sat, 15 Feb 2025 00:00:00 +0000

Git を使って開発を進める際、コミット履歴が煩雑になってしまうことはよくあります。そんなときに便利なのが スカッシュマージ（Squash Merge） です。本記事では、スカッシュマージのメリット・デメリットと、デメリットを最小限に抑える実践的な使い方を解説します。

スカッシュマージとは？

スカッシュマージとは、ブランチをマージする際に 複数のコミットを1つにまとめて 取り込む方法です。通常のマージでは個々のコミットがそのまま残りますが、スカッシュマージを使うと履歴がスッキリします。

スカッシュマージのメリット

スカッシュマージは単に履歴を整理するだけでなく、開発の効率性と保守性を大幅に向上させる手法です。特にチーム開発において、その真価を発揮します。

コミット履歴が整理される

不要な「修正」や「調整」コミットがなくなり、履歴が見やすくなります。開発者が本質的な変更に集中でき、履歴を追跡する際の認知負荷が軽減されます。

レビューがしやすい

大量の細かいコミットを追う必要がなく、変更内容を簡単に把握できます。レビュアーは機能やバグ修正の全体像を一度に理解でき、より効率的で質の高いコードレビューが可能になります。

バグ追跡・原因特定が容易

Issue単位でコミットがまとめられているため、バグが発生した際に「どの機能追加・修正が原因か」を素早く特定できます。

具体例：

「ログイン機能のバグ修正 (#123)」というコミットがあれば、そのコミット前後での動作比較が簡単
細かいコミット（「typo修正」「スペース調整」など）に惑わされることなく、本質的な変更箇所を追跡可能
問題のある変更をリバート（取り消し）する際も、Issue単位でまとまっているため、関連する変更を漏れなく元に戻せる

この利点は、特に本番環境でのトラブルシューティング時や、複雑なバグの原因究明において非常に価値があります。

チーム開発がスムーズに

きれいな履歴は、他の開発者が理解しやすく、共同作業がしやすくなります。新しいチームメンバーが参加した際も、プロジェクトの変更履歴を迅速に把握できるため、オンボーディングが効率化されます。

スカッシュマージのデメリット

スカッシュマージはコミット履歴を整理し、開発フローを効率化する便利な手法ですが、当然トレードオフも存在します。ここでは一般的に指摘されるデメリットを正直にまとめた上で、後述するIssue単位の運用でどこまで軽減できるかも解説します。

git bisect による原因特定が難しくなる

git bisect は、バグが混入したコミットを二分探索で特定する強力なデバッグツールです。しかしスカッシュマージで複数のコミットを1つにまとめてしまうと、bisectの探索粒度が荒くなり、「この巨大コミットのどこかにバグがある」としかわからない状況になります。

通常のマージであれば細かいコミット単位で原因を絞り込めるため、デバッグ効率に差が出る場面があります。

revert の粒度が荒くなる

スカッシュマージされたコミットをリバートすると、PR全体の変更が一括で取り消されます。「この修正だけ戻したいが、他の変更は残したい」というケースでは、手動で該当箇所だけ切り出す作業が必要になります。

通常のマージであれば個々のコミット単位でリバートできるため、より柔軟な対応が可能です。

cherry-pick がしづらくなる

特定の変更だけを別のブランチに持っていきたい場面（ホットフィックスやバックポートなど）で、スカッシュマージされた巨大コミットの中から一部だけを cherry-pick することは困難です。結果として、手動でのパッチ適用が必要になることがあります。

PRが大きいと意味不明な巨大コミットが生まれる

スカッシュマージは「PRの変更を1コミットにまとめる」手法のため、PRそのものが大きいと、数百行〜数千行の変更が1コミットに圧縮されます。こうなると履歴を整理するどころか、「色々やった」としかわからない爆弾コミットが生まれ、本末転倒です。

これはスカッシュマージの問題というよりPRの粒度の問題ですが、スカッシュマージを採用するならPRを小さく保つ運用とセットで考える必要があります。

コミット履歴の消失による作業の形跡の喪失

スカッシュマージを行うと、ブランチ内の個々のコミット履歴が1つのコミットにまとめられ、詳細な履歴が失われます。これにより、以下のような影響が考えられます：

作業の形跡が消える: 開発中にどのような変更が段階的に行われたか（例: 「初期実装」「バグ修正」「コード最適化」など）がわからなくなります。後から特定の変更を追跡したい場合に、詳細なコンテキストが失われるため、デバッグや問題の原因究明が難しくなる可能性があります。
複数人での作業における影響: チームでブランチを共有し、複数人でコミットしていた場合、個々の貢献者のコミットが統合されてしまい、誰がどの変更を担当したかが不明瞭になります。これにより、協力者の貢献が見えづらくなることがあります。

コミット内容を評価指標にしている場合の影響

一部の組織では、コミット数やコミット内容を個人の評価指標として利用する場合があります。スカッシュマージを採用すると、個々のコミットが消滅するため、評価の難しさが生じます。

ただしこれは稀なケースです。ほとんどの組織では、Issueの完了内容やプルリクエストの質、プロジェクト全体への貢献度をもとに評価を行っており、コミット数に依存した評価は一般的ではありません。またGitHubではマージ後のPRページからすべてのコミット・レビューコメント・会話履歴を永久に閲覧可能なため、貢献度の確認に支障はほとんどありません。

Issue単位の運用でデメリットの多くは軽減できる

ここまで挙げたデメリットの多くは、PRの粒度が大きすぎる場合に深刻化します。逆に言えば、Issue単位で小さなPRを作成し、スカッシュマージを行う運用であれば、これらの問題は大幅に軽減されます。

git bisect: Issue単位の小さなコミットなら、原因の特定範囲は十分に絞れる
revert: Issue単位でまとまっているため、機能ごとの取り消しが容易
cherry-pick: 1コミット＝1機能/1修正なので、そのまま別ブランチに持っていける
巨大コミット: そもそもPRが小さければ発生しない

次の章では、このIssue単位でのスカッシュマージ運用を具体的に解説します。

よくあるスカッシュマージの誤解

よくある誤解 「スカッシュマージを使うと、子ブランチをマージする際にコンフリクトが発生しやすくなる」「コミットハッシュが変わることでGitが混乱してコンフリクトが起きる」

理想を捨て現実と向き合ったコードレビュー｜トラブル回避の実践ガイド

Sun, 22 Oct 2023 00:00:00 +0000

「品質の高いコードを書くべき」「可読性を追求すべき」これらは全て正論です。

しかし、この理想を追求した結果、人が辞め、チームが崩壊し、プロジェクトが炎上する—— そんな現場を何度も見てきました。

本記事では、理想を捨て、現実と向き合った「トラブルを起こさないコードレビュー」の方法論を共有します。綺麗事抜きの、生存戦略としてのコードレビュー術です。

コードレビューの目的とは

コードレビューは、プロジェクトのコード品質を向上させるための重要なプロセスです。しかし、何をもって「品質が良い」と言えるのでしょうか。以下は品質の良いコードの基本的な要件です。

バグが存在しない
プロジェクトの設計方針を正確に反映している
使用している言語の機能を適切かつ簡潔に活用している
クラスや変数は明瞭で適切に命名されている
不必要な処理が排除され、処理が最適化されている

これらの要件を満たすコードは、ユニットテストが容易に行え、保守性が向上します。このようなコードは長期的な運用においても効果的に機能し続けます。

理想のコードレビュー

プロジェクトにcommitするコードは、前述の品質基準を満たすべきです。故に以下の方針が理想的なコードレビューと言えます。

問題のあるコードを見つけた際は、遠慮せず修正案を提示する。
コントリビューターとの意見が合わない場合、議論を重ねて最善の解を見つけ出す。
徹底的な議論の結果、最終的にcommitされるコードは、そのプロジェクトの高品質を保証するものとなる。

コードレビューの現実

理想的なコードレビューと現実にはギャップが存在します。たとえ品質向上を目指して、率直に自分の意見や修正提案をコメントしても、全てがスムーズに進むわけではありません。実際、多くのコントリビューターは、直接的な指摘や修正要求に反発することがあります。特に主張を強く押し通すと、あなたをめんどくさい奴と感じる者も出てくるでしょう。

こうした状況は、コードの品質だけでなく、チーム内の人間関係やコミュニケーションの質にも影響します。一つのレビューコメントが原因で、深刻な対立や人間関係の摩擦が生じることも珍しくありません。

そのため、現実的なアプローチを取ることが求められます。自分の意見や提案を伝える際には、相手の立場や感情を考慮し、適切なコミュニケーションを心がけることが重要です。

コードレビューの過度な追求がもたらす弊害

前章で触れたような理想を過度に追求する行動は、時として思わぬ弊害を生むことがあります。具体的には以下のような問題が生じる可能性があります。

チームの関係性の悪化

繰り返し厳しいレビューコメントが続くと、チームの信頼関係や協調性が損なわれることがあります。

人材の流出

特定のメンバーがコードレビューで常に厳しい指摘を受けることで、そのメンバーが会社を去る、あるいはプロジェクトから離脱する可能性があります。

生産性の低下

チーム内の緊張や不信感が増大すると、プロジェクトの進捗が遅くなる可能性があります。

コミュニケーションの障壁

コードレビューに関する過度な議論や対立が続くと、メンバー間のオープンなコミュニケーションが難しくなることが考えられます。

経営的なコスト

上述したように、人材が退職する場合、新しい人材の採用や教育に時間とコストがかかります。

上記に挙げた弊害は大袈裟な話に聞こえるかもしれませんが、エンジニアの業界は売り手市場であり、その流動性は非常に高いのが現実です。人間関係の摩擦やチーム内の微妙な不和が、エンジニアの転職を検討する大きな要因となっていることが珍しくありません。このような背景から、適切なバランスとコミュニケーションが組織の持続的な成長や人材の確保・維持において、非常に重要な要素であると感じています。

トラブルを避けるコードレビュー5箇条

コードレビューを効果的に行うための、基本となる5つの方針を以下にまとめました。これらの心得は、次の章で詳しく説明する具体的な対策を取り入れる上での根本的な心構えとして考えてください。

モラルを持ってレビューする

レビューは誠実さをもって行うもの。それは技術的なアドバイスよりも重要な意味を持ちます。

主観的な指摘を避ける

オブジェクティブな視点からのレビューがトラブルを回避し、チームの一体感を保つ鍵となります。

客観的な評価を元にレビューを行う

レビューの基準となる方針や規約を共有し、明確にすることで、コードレビューに於ける摩擦を減少させることができます。

過度なコードの品質の追求をやめる

品質の追求は重要ですが、それが過度になるとチームのコミュニケーションに影響することも。適切な基準の設定が求められます。

期限を守ってレビューする

レビューの遅延は、指摘内容以上にストレスを生みます。コントリビューターは既に次の作業に着手している可能性があり、後から指摘が来ると、頭の切り替えコストや手戻りの負担が大きくなります。理想は24時間以内、遅くとも48時間以内にレビューを完了させることで、多くのトラブルを未然に防ぐことができます。

これらの考え方は、より具体的なレビューの技法や対策を採用する際の基盤となります。適切な心構えを持ちながら、次の章での詳しい手法や考え方を取り入れていきましょう。

設計方針のドキュメント化

設計方針の明文化は、プロジェクトの一貫性と方向性を保つために不可欠です。具体的には以下の点をドキュメントとして整理することを推奨します。

プロジェクトのアーキテクチャの選定

例としてMVC, MVP, MVVMなど、どのアーキテクチャパターンを採用しているのかを明示します。

組み合わせる設計方針

テスト駆動設計やドメイン駆動など、その他の設計方針との組み合わせも明記します。

サンプルコードの提供

実際のコードをより理解しやすくするため、それぞれの設計に関連するサンプルコードをドキュメントに添付することが効果的です。

自動テストのサンプル

品質を保証するための自動テスト（ユニットテスト、結合テストなど）の例もドキュメントに掲載。

これらをドキュメントにまとめることで、チームメンバーがどのような設計方針でコードを書くべきかが、客観的かつ明確に共有されるようになります。

統一されたコーディング規約の重要性

コーディング規約は、チーム全員が同じルールのもとでコードを書くための指針となります。これにより、チーム内でのコードの一貫性が保たれ、結果的に可読性が向上します。

可読性と品質の向上

統一されたコーディングスタイルは、他のメンバーが書いたコードを理解しやすくするだけでなく、バグの発見も容易にします。