MENU

KotlinでTDDを活用した複雑なビジネスロジック検証ガイド

Kotlin

KotlinでTDDを使った複雑なビジネスロジックの検証は、信頼性の高いソフトウェアを効率的に開発するための強力な手法です。TDD（テスト駆動開発）は、テストケースを先に作成し、それに合致する形でコードを書いていくアプローチです。これにより、開発プロセス全体でコードの品質を維持しやすくなり、バグの早期発見や修正が可能になります。

ビジネスロジックが複雑であるほど、ロジックの網羅的なテストが求められます。本記事では、Kotlinを用いてTDDを実践し、複雑なビジネス要件を検証する具体的な方法を解説します。TDDの基本サイクルやMockを用いた依存関係のテスト、さらには実際の応用例を通して、効果的なテストとコードの書き方を学びましょう。

目次

TDD（テスト駆動開発）とは


テスト駆動開発（Test-Driven Development、略してTDD）は、「テストを書いてからコードを書く」という開発手法です。従来の開発方法では、機能を実装してからテストを書くのが一般的ですが、TDDではその順序が逆になります。

TDDの基本プロセス


TDDは以下の3つのステップで進行します。これをRed-Green-Refactorサイクルと呼びます。

  1. Red（赤）: まず、失敗するテストを書きます。まだコードがないため、この時点ではテストが失敗します。
  2. Green（緑）: テストをパスするために最小限のコードを書きます。コードがテストを通過すれば、このステップは完了です。
  3. Refactor（リファクタリング）: コードが正しく動くことを確認したら、内部構造を改善します。この際、テストはパスしたままでなければなりません。

TDDの利点

  • バグの早期発見: テストを先に書くことで、バグや問題が早い段階で発見できます。
  • 設計の明確化: テストを書くことで、必要な機能や要件が明確になります。
  • コード品質の向上: リファクタリングを通じて、クリーンでメンテナンスしやすいコードになります。
  • 信頼性の向上: テストに守られているため、変更や追加がしやすくなります。

ビジネスロジックにTDDを適用する意義


ビジネスロジックは複雑であり、要件変更も頻繁に起こるため、TDDを適用することで以下の効果が得られます。

  • 要件の検証: ロジックが要件を正確に満たしているか、明確なテストで確認できます。
  • 変更の安全性: 新しいロジックを追加する際も、既存テストが動作を保証します。

TDDはKotlinの特性とも相性が良く、シンプルで効率的なビジネスロジックの検証を可能にします。

KotlinでTDDを始める準備

KotlinでTDDを始めるには、適切な開発環境とテストツールの準備が必要です。ここでは、開発環境のセットアップと必要なライブラリの導入手順を解説します。

開発環境のセットアップ

KotlinでTDDを行うために、以下の手順で環境を整えます。

1. IDEのインストール

  • IntelliJ IDEA：Kotlin開発で最もよく使われるIDEです。JetBrainsから無償版のCommunity Editionが提供されています。
  • Android Studio：Androidアプリ開発の場合に推奨されるIDEです。

2. Kotlinプラグインの確認


IDEにKotlinプラグインがインストールされていることを確認します。

  • IntelliJ IDEAの場合：
  • 「Settings」→「Plugins」→「Kotlin」で確認・有効化できます。

テストフレームワークの導入

KotlinでTDDを行うには、テストフレームワークが必要です。代表的なフレームワークは以下の通りです。

JUnit 5の導入


JUnit 5はKotlinと相性が良く、シンプルなテスト作成が可能です。
Gradleの依存関係に追加します：

dependencies {
    testImplementation("org.junit.jupiter:junit-jupiter:5.8.2")
}

Mockライブラリ（Mockito）の導入


依存関係のあるオブジェクトをモック化するためにMockitoを使用します。
Gradleの依存関係に追加：

dependencies {
    testImplementation("org.mockito:mockito-core:4.0.0")
    testImplementation("org.mockito.kotlin:mockito-kotlin:4.0.0")
}

ビルド設定の確認

build.gradle.ktsに以下の設定を追加してテストが実行できるようにします。

tasks.test {
    useJUnitPlatform()
}

サンプルプロジェクト作成

  1. 新規プロジェクト作成：
  • IntelliJ IDEAで「New Project」→「Kotlin」→「Gradle」を選択し、プロジェクトを作成。
  1. パッケージ構成：
   src/
   ├─ main/
   │   └─ kotlin/
   │       └─ com.example/
   │            └─ BusinessLogic.kt
   └─ test/
       └─ kotlin/
           └─ com.example/
                └─ BusinessLogicTest.kt

これで、KotlinでTDDを始めるための基本的な準備が整いました。

ビジネスロジックの要件定義

複雑なビジネスロジックをTDDで検証するためには、最初に要件を明確に定義し、テスト可能な形に分解することが重要です。ここでは、要件定義のポイントと、具体的な分解方法を解説します。

要件定義の基本ステップ

  1. 業務プロセスの理解：
    ビジネスロジックの背景や目的を把握し、どのような処理が必要かを明確にします。
  2. 機能要件のリスト化：
    必要な機能や期待される出力をリストアップします。例えば、次のような要件が考えられます：
  • 顧客の注文処理を行う。
  • 在庫がある場合のみ注文を確定する。
  • 合計金額が一定額を超えたら割引を適用する。
  1. ユースケースの作成：
    各機能の具体的な使用シナリオ（ユースケース）を考えます。例えば：
  • 「在庫が5個ある商品に対して、3個の注文を行う」
  • 「割引適用条件を満たす購入を行った場合、割引を適用する」

テスト可能な単位への分解

ビジネスロジックは複数の小さなロジックに分解し、テスト可能な単位（テストケース）を作成します。以下のように分解できます：

例：注文処理ロジックの分解

  1. 在庫確認ロジック
  • 在庫数が注文数以上であれば注文を受け付ける。
  • 在庫が不足している場合はエラーを返す。
  1. 割引適用ロジック
  • 注文の合計金額が10,000円以上であれば10%割引を適用する。
  1. 注文合計計算ロジック
  • 商品単価と注文数を掛け合わせ、合計金額を計算する。

ビジネスルールの明確化

各ロジックに関するビジネスルールを明確に定義し、例外処理も考慮します。

例：割引ルール

  • 合計金額が10,000円未満の場合は割引しない。
  • 特定の会員ランクに対して追加割引を適用する。

テストケースの作成指針

要件定義が終わったら、以下の方針でテストケースを作成します。

  • 正常系：期待通りに動作するシナリオ。
  • 異常系：エラーや例外が発生するシナリオ。
  • 境界値：しきい値の前後での動作確認。

このように、要件を細かく分解し、TDDを適用しやすい形に整理することで、効率的にビジネスロジックを検証できます。

単体テストの作成方法

Kotlinで複雑なビジネスロジックを検証するためには、単体テスト（Unit Test）の作成が不可欠です。ここでは、Kotlinでの単体テストの作成手順とベストプラクティスを解説します。

基本的な単体テストの作成手順

  1. テストクラスの作成
    テスト対象のクラスと同じパッケージ内にテストクラスを作成します。テストクラス名は「対象クラス名 + Test」とするのが一般的です。 例：OrderProcessor.ktのテストクラス
   package com.example

   import org.junit.jupiter.api.Assertions.*
   import org.junit.jupiter.api.Test

   class OrderProcessorTest {
       @Test
       fun `注文が在庫を満たしている場合は成功する`() {
           val processor = OrderProcessor()
           val result = processor.processOrder(5, 3)
           assertTrue(result)
       }
   }
  1. テストメソッドの命名
    テストメソッドは、何をテストし、何が期待されるかを明確に示す名前を付けます。
  • 例: 在庫が足りている場合注文が成功する → orderSucceedsWhenStockIsSufficient
  1. アサーションの活用
    JUnitでは、assertEquals、assertTrue、assertThrowsなどのアサーションを使用して期待結果を検証します。 例：アサーションの使用
   @Test
   fun `在庫が不足している場合はエラーが発生する`() {
       val processor = OrderProcessor()
       assertThrows<IllegalArgumentException> {
           processor.processOrder(2, 5)
       }
   }

依存関係のモック化

ビジネスロジックが他のクラスやサービスに依存している場合、Mockitoを使って依存関係をモック化します。

例：Mockitoを使用したモックの作成

import org.mockito.kotlin.mock
import org.mockito.kotlin.whenever

@Test
fun `在庫確認サービスが在庫ありと返した場合、注文が成功する`() {
    val stockService = mock<StockService>()
    whenever(stockService.isInStock(1, 3)).thenReturn(true)

    val processor = OrderProcessor(stockService)
    val result = processor.processOrder(1, 3)

    assertTrue(result)
}

テストのベストプラクティス

  1. 1つのテストで1つの動作を検証する
    テストメソッドは1つのシナリオに集中し、複数の動作を検証しないようにします。
  2. Given-When-Thenパターンを使用する
    テストコードは以下の3つのセクションに分けると分かりやすくなります。
  • Given: 前提条件の設定
  • When: テスト対象の処理を実行
  • Then: 結果を検証 例
   @Test
   fun `注文が割引条件を満たす場合、割引が適用される`() {
       // Given
       val order = Order(amount = 10000)

       // When
       val result = order.applyDiscount()

       // Then
       assertEquals(9000, result)
   }
  1. テストの独立性を保つ
    各テストは独立して実行できるようにし、他のテストに依存しないようにします。

テストの実行と確認

  • IDEからテストを実行：
    IntelliJ IDEAやAndroid Studioでは、テストクラスやメソッドの横にある「▶」ボタンをクリックして実行できます。
  • Gradleコマンドで実行：
  ./gradlew test

単体テストを適切に作成することで、ビジネスロジックの正確性と安定性を高めることができます。

Red-Green-Refactorサイクルの実践

TDD（テスト駆動開発）の中核となるRed-Green-Refactorサイクルは、テストを書いてからコードを書くというプロセスを繰り返すことで、信頼性の高いソフトウェアを効率的に開発する手法です。ここでは、Kotlinを使ってこのサイクルを具体的に実践する方法を解説します。

Red-Green-Refactorサイクルとは

  1. Red（赤）：失敗するテストを書く
  2. Green（緑）：テストが通るように最小限のコードを書く
  3. Refactor：コードの重複や構造を改善し、品質を高める

このサイクルを繰り返すことで、少しずつ確実にコードを完成させていきます。

具体例で学ぶRed-Green-Refactor

シナリオ：注文金額が10,000円以上の場合に10%割引を適用するロジックを作成します。

ステップ1：Red（失敗するテストを書く）

まず、割引ロジックのテストを書きます。注文金額が10,000円以上なら10%割引が適用されることをテストします。

import org.junit.jupiter.api.Assertions.assertEquals
import org.junit.jupiter.api.Test

class DiscountCalculatorTest {

    @Test
    fun `10,000円以上の注文で10パーセント割引が適用される`() {
        val calculator = DiscountCalculator()
        val result = calculator.calculateDiscount(10000)
        assertEquals(9000, result)
    }
}

この時点ではDiscountCalculatorクラスやcalculateDiscountメソッドが存在しないため、コンパイルエラーまたはテストが失敗します。

ステップ2：Green（テストを通すために最小限のコードを書く）

テストを通すために、DiscountCalculatorクラスとcalculateDiscountメソッドを作成します。

class DiscountCalculator {
    fun calculateDiscount(amount: Int): Int {
        return if (amount >= 10000) {
            (amount * 0.9).toInt()
        } else {
            amount
        }
    }
}

再度テストを実行すると、テストが成功します。

ステップ3：Refactor（コードを改善する）

テストが通ったら、コードをリファクタリングします。割引率や閾値を定数化して可読性と保守性を向上させます。

class DiscountCalculator {
    companion object {
        private const val DISCOUNT_THRESHOLD = 10000
        private const val DISCOUNT_RATE = 0.9
    }

    fun calculateDiscount(amount: Int): Int {
        return if (amount >= DISCOUNT_THRESHOLD) {
            (amount * DISCOUNT_RATE).toInt()
        } else {
            amount
        }
    }
}

テストを再度実行して、リファクタリング後もテストがパスすることを確認します。

Red-Green-Refactorのポイント

  1. Red（失敗するテストを書く）
  • まずは期待する結果を明確にし、失敗するテストを書きます。
  • テストが失敗することを確認することで、テストが正しく機能していることを証明します。
  1. Green（最小限のコードを書く）
  • テストを通すために、必要最低限のコードを書きます。
  • この段階では、コードの美しさや最適化は考えず、テストが通ることを優先します。
  1. Refactor（コードを改善する）
  • テストが通ったら、コードをリファクタリングします。
  • リファクタリング後もテストが通ることを確認し、コードの品質を保ちます。

複数回のサイクルでロジックを拡張

1つのテストが通ったら、次のシナリオを追加し、再びRed-Green-Refactorサイクルを繰り返します。これにより、少しずつ複雑なビジネスロジックを構築できます。

Red-Green-Refactorを繰り返すことで、堅牢で保守しやすいコードをKotlinで効率的に作成することができます。

Mockを活用した依存関係のテスト

複雑なビジネスロジックでは、外部サービスやデータベースなど他のコンポーネントに依存することがよくあります。TDDにおいて、これらの依存関係を直接テストするのは難しいため、Mock（モック）を活用することで効率的にテストを行えます。KotlinではMockitoやMockKが主なMockライブラリとして利用されています。

Mockとは何か

Mockは、実際の依存関係の代わりに使う仮のオブジェクトです。依存する外部サービスやクラスの振る舞いをシミュレートし、テスト時に想定される動作を再現します。

Mockitoを使用したMockの作成

ここでは、Mockitoを使って依存関係をMock化し、ビジネスロジックをテストする手順を紹介します。

シナリオ

「在庫確認サービス」に依存する「注文処理クラス」をテストします。

ステップ1：依存関係のインターフェース作成

interface StockService {
    fun isInStock(productId: Int, quantity: Int): Boolean
}

ステップ2：ビジネスロジックのクラス

class OrderProcessor(private val stockService: StockService) {
    fun processOrder(productId: Int, quantity: Int): Boolean {
        if (stockService.isInStock(productId, quantity)) {
            // 注文処理のロジック
            return true
        }
        return false
    }
}

ステップ3：Mockを使用したテスト

StockServiceをMock化し、OrderProcessorの動作をテストします。

import org.junit.jupiter.api.Assertions.assertTrue
import org.junit.jupiter.api.Test
import org.mockito.kotlin.mock
import org.mockito.kotlin.whenever

class OrderProcessorTest {

    @Test
    fun `在庫がある場合、注文が成功する`() {
        // Given
        val stockService = mock<StockService>()
        whenever(stockService.isInStock(1, 5)).thenReturn(true)

        val processor = OrderProcessor(stockService)

        // When
        val result = processor.processOrder(1, 5)

        // Then
        assertTrue(result)
    }
}

Mockを使ったテストの流れ

  1. Mockの作成
    mock<依存関係の型>()を使ってMockオブジェクトを作成します。
  2. 振る舞いの定義
    whenever(mock.メソッド).thenReturn(期待する値)で、Mockの動作を定義します。
  3. テスト対象にMockを注入
    コンストラクタやメソッド引数でMockをテスト対象に渡します。
  4. テストの実行と検証
    テストメソッドを実行し、期待通りの結果が得られるか検証します。

MockKを使用した場合

Kotlin向けのMockライブラリであるMockKも使いやすい選択肢です。

import io.mockk.every
import io.mockk.mockk
import kotlin.test.assertTrue
import org.junit.jupiter.api.Test

class OrderProcessorTest {

    @Test
    fun `在庫がある場合、注文が成功する`() {
        // Given
        val stockService = mockk<StockService>()
        every { stockService.isInStock(1, 5) } returns true

        val processor = OrderProcessor(stockService)

        // When
        val result = processor.processOrder(1, 5)

        // Then
        assertTrue(result)
    }
}

Mockを使う際のベストプラクティス

  1. 依存関係のみをMock化する
    テスト対象のクラスのロジックはMockせず、依存関係のみをMockにします。
  2. 過度なMock化を避ける
    すべてをMock化するとテストが信頼性を欠く可能性があります。実際の依存関係がテスト可能なら、そちらを使用しましょう。
  3. 振る舞いの検証
    Mockが想定通り呼び出されたか検証する場合、MockitoのverifyやMockKのverifyを使用します。
  4. エラーケースもテストする
    依存関係が失敗するケースや例外を返すケースもテストしましょう。

Mockを活用することで、依存関係に影響されずにビジネスロジックを確実に検証できます。

失敗しやすいケースの対処方法

TDD（テスト駆動開発）を進める中で、複雑なビジネスロジックでは失敗しやすいケースや問題に直面することがあります。これらのケースを適切に対処することで、テストの信頼性を高め、効率的な開発が可能になります。ここでは、よくある失敗例とその対処方法について解説します。

1. 境界値でのエラー

問題：
数値の比較やループ処理で境界値（しきい値付近）において正しく動作しないことがあります。

例：割引適用が10,000円以上の注文で適用されるとき、ちょうど10,000円のケースで誤動作する。

対処法：
境界値を意識したテストケースを作成します。

@Test
fun `注文金額がちょうど10,000円の場合に割引が適用される`() {
    val calculator = DiscountCalculator()
    val result = calculator.calculateDiscount(10000)
    assertEquals(9000, result)
}

2. Null値や空データの処理

問題：
予期しないnull値や空のデータが入力された際にクラッシュする可能性があります。

対処法：
nullや空の入力に対するテストケースを作成し、適切なエラーハンドリングを行います。

@Test
fun `注文がnullの場合にIllegalArgumentExceptionを投げる`() {
    val processor = OrderProcessor()
    assertThrows<IllegalArgumentException> {
        processor.processOrder(null, 3)
    }
}

3. 依存関係の呼び出しエラー

問題：
外部サービスやデータベースへの依存関係が正しく動作しないとテストが失敗します。

対処法：
Mockを使用して依存関係をシミュレートし、想定される結果を返すようにします。

val stockService = mock<StockService>()
whenever(stockService.isInStock(1, 5)).thenReturn(false)

val processor = OrderProcessor(stockService)
val result = processor.processOrder(1, 5)

assertFalse(result)

4. 例外処理の不足

問題：
予期しない入力やエラー状態で例外処理が適切に行われていない場合、プログラムがクラッシュします。

対処法：
例外が正しく処理されているか、例外が発生するシナリオのテストを追加します。

@Test
fun `在庫確認中に例外が発生した場合に注文が失敗する`() {
    val stockService = mock<StockService>()
    whenever(stockService.isInStock(1, 5)).thenThrow(RuntimeException("データベースエラー"))

    val processor = OrderProcessor(stockService)
    assertThrows<RuntimeException> {
        processor.processOrder(1, 5)
    }
}

5. 複数条件の組み合わせによるエラー

問題：
複数の条件が組み合わさった場合に正しく動作しないことがあります。

対処法：
さまざまな条件の組み合わせでテストを行い、ロジックが網羅されていることを確認します。

@Test
fun `在庫があり、割引適用条件を満たす場合に注文が成功し割引が適用される`() {
    val stockService = mock<StockService>()
    whenever(stockService.isInStock(1, 10)).thenReturn(true)

    val processor = OrderProcessor(stockService)
    val result = processor.processDiscountedOrder(1, 10, 10000)

    assertEquals(9000, result)
}

6. テストデータの依存による不安定さ

問題：
テストデータや環境に依存するテストは、環境が変わると失敗しやすくなります。

対処法：

  • テストデータは固定の値を使う。
  • テストごとにデータを初期化する。
  • データベースやファイルシステムをモック化する。

まとめ

失敗しやすいケースに対処することで、TDDをより効果的に活用できます。境界値や例外処理、依存関係のモック化など、さまざまなシナリオを考慮したテストを作成することで、堅牢で信頼性の高いビジネスロジックを構築できます。

複雑なビジネスロジックの応用例

KotlinでTDDを用いて複雑なビジネスロジックを検証する手法を学んだら、次は実際のシナリオに適用してみましょう。ここでは、実際の業務要件に基づいた応用例を紹介し、どのようにTDDを活用するかを解説します。

応用例1：オンラインショップの注文処理システム

オンラインショップで注文処理を行う際、次のような複数のビジネスロジックが関係します。

  • 在庫確認：注文数が在庫を超えないかチェックする。
  • 割引適用：特定の金額以上で割引を適用する。
  • ポイント付与：購入金額に応じてポイントを付与する。

ステップ1：テストケースの作成（Red）

@Test
fun `在庫がある場合に注文が成功し、割引とポイントが適用される`() {
    val stockService = mock<StockService>()
    val discountService = mock<DiscountService>()
    val pointsService = mock<PointsService>()

    whenever(stockService.isInStock(1, 5)).thenReturn(true)
    whenever(discountService.applyDiscount(5000)).thenReturn(4500)
    whenever(pointsService.calculatePoints(4500)).thenReturn(45)

    val processor = OrderProcessor(stockService, discountService, pointsService)
    val result = processor.processOrder(1, 5, 5000)

    assertEquals(4500, result.finalAmount)
    assertEquals(45, result.points)
}

ステップ2：最小限のコードでテストをパスさせる（Green）

data class OrderResult(val finalAmount: Int, val points: Int)

class OrderProcessor(
    private val stockService: StockService,
    private val discountService: DiscountService,
    private val pointsService: PointsService
) {
    fun processOrder(productId: Int, quantity: Int, amount: Int): OrderResult {
        if (stockService.isInStock(productId, quantity)) {
            val discountedAmount = discountService.applyDiscount(amount)
            val points = pointsService.calculatePoints(discountedAmount)
            return OrderResult(discountedAmount, points)
        }
        throw IllegalArgumentException("在庫が不足しています")
    }
}

ステップ3：リファクタリング（Refactor）

依存関係の処理を整理し、各サービスの責務を明確にします。

data class OrderResult(val finalAmount: Int, val points: Int)

class OrderProcessor(
    private val stockService: StockService,
    private val discountService: DiscountService,
    private val pointsService: PointsService
) {
    fun processOrder(productId: Int, quantity: Int, amount: Int): OrderResult {
        require(stockService.isInStock(productId, quantity)) { "在庫が不足しています" }

        val discountedAmount = discountService.applyDiscount(amount)
        val points = pointsService.calculatePoints(discountedAmount)

        return OrderResult(discountedAmount, points)
    }
}

応用例2：金融アプリの口座取引処理

要件：

  • 残高が十分な場合にのみ引き出しを許可する。
  • 1回の取引で引き出せる上限額を設定する。
  • 取引が成功したら残高を更新する。

テストケースの作成（Red）

@Test
fun `残高が十分で取引上限内なら引き出しが成功する`() {
    val account = BankAccount(10000)
    val result = account.withdraw(3000)

    assertEquals(7000, result)
}

最小限のコードでテストをパスさせる（Green）

class BankAccount(private var balance: Int) {
    fun withdraw(amount: Int): Int {
        if (balance >= amount) {
            balance -= amount
            return balance
        }
        throw IllegalArgumentException("残高不足です")
    }
}

リファクタリング（Refactor）

取引上限の追加やエラーメッセージの改善。

class BankAccount(private var balance: Int) {
    companion object {
        private const val WITHDRAWAL_LIMIT = 5000
    }

    fun withdraw(amount: Int): Int {
        require(amount <= WITHDRAWAL_LIMIT) { "1回の引き出し上限は${WITHDRAWAL_LIMIT}円です" }
        require(balance >= amount) { "残高不足です" }

        balance -= amount
        return balance
    }
}

複雑なビジネスロジックをTDDで管理するポイント

  1. 要件を小さく分割する
    複雑なロジックは小さな単位に分け、個別にテストを作成しましょう。
  2. 依存関係をMockで管理する
    外部システムやサービスへの依存をMock化して、独立したテストを行います。
  3. エラーケースを網羅する
    境界値や異常系も考慮し、堅牢なテストケースを作成します。
  4. 継続的にリファクタリング
    コードが完成するたびにリファクタリングを行い、可読性と保守性を向上させましょう。

これらの応用例を通じて、KotlinとTDDで複雑なビジネスロジックを効率的に検証・管理するスキルを身につけましょう。

まとめ

本記事では、KotlinにおけるTDD（テスト駆動開発）を活用した複雑なビジネスロジックの検証方法について解説しました。TDDの基本概念であるRed-Green-Refactorサイクルを中心に、依存関係のMock化や境界値・例外処理など、失敗しやすいケースへの対処法も紹介しました。

具体的な応用例として、オンラインショップの注文処理や金融アプリの口座取引処理を通じて、どのようにTDDを実践するかを示しました。これにより、ビジネス要件を確実に満たす堅牢なコードの作成が可能になります。

TDDを習慣化することで、コードの品質向上、バグの早期発見、変更の安全性確保が実現できます。KotlinとTDDを組み合わせて、効率的で信頼性の高いソフトウェア開発に役立ててください。

Kotlin
テスト駆動開発 TDD ビジネスロジック Kotlin

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次