Claude Code のプラグイン tsumiki を非エンジニアが理解するまで AI に説明させてみた
三度の飯より推しが好きなクラスメソッドオペレーションズのはらしまです。どうもこんにちは。
みなさんご存知の Claude Code に、tsumiki という開発プロセスフレームワークのプラグインがあるのをご存知でしょうか？
tsumiki を使うと、要件定義からツールのリリースまでを自然言語の指示だけで進められるんです。非エンジニアでも業務の自動化ツールが作れてしまう、めちゃくちゃ便利なしくみです！
ただ、便利なのはわかっていても、ドキュメントやマニュアルを読んでも非エンジニアには難しすぎるんですよね…。
「tsumiki のコマンドってたくさんあるけど、それぞれ何をするの？」「どういう流れで使えばいいの？」——私自身、感覚的に使えてはいたものの、ちゃんと理解できていなくて、人に説明しようとしたら何ひとつまともに答えられませんでした ／(^q^)＼
そこで、非エンジニア向けの tsumiki ガイドを作りました。この記事では、そのガイドの中身をご紹介します！（エンジニアのみなさまのレビュー済みです）
ちなみにこのガイドはドキュメントを AI に読み解いてもらって作ったものです。その経緯は記事の最後で少しだけお話ししますね。
非エンジニア向け tsumiki ガイド
ではここから、『基礎知識編』の一部と『tsumiki コマンド解説』と『実践ガイド』をご紹介します。
このガイドは、 tsumiki のドキュメント をもとに、非エンジニアでもわかるようにかみ砕いた内容になっています。たとえ話がちょこちょこ出てきますが、たとえ話を「専門的に言うと違うよ」みたいなツッコミはなしでお願いしますね！w
基礎知識編
Tsumiki って何？
一言で言うと：職人さんに渡す「作業マニュアル」
CLAUDE.md と rules が「うちのルール」を伝える仕組みだとすると、Tsumiki は「作業の進め方」を教えるマニュアルです。
Tsumiki は、AI と人間が協力して質の高いソフトウェアを作るための「開発プロセスフレームワーク」です。Claude Code（職人さん）に対して「この手順で、この順番で進めてね」と指示するためのマニュアル集であり、以下の2つの特徴があります。
- 「仕様・設計を先にしっかり固める」（Specification / Design First）
- 「テスト駆動開発（TDD）」で品質を守りながら実装する
Tsumiki を使うことで、職人さんが自己流で作業を始めるのではなく、「まず設計図を書く → 次にタスクに分ける → それから作る」という正しい手順で進められるようになります。
たとえ話で整理すると：
CLAUDE.md / rules = 「うちのルール」を伝える（何を守るか）
Tsumiki = 「作業手順」を伝える（どう進めるか）
Claude Code だけの場合：
あなた「カフェを作って！」
職人さん「わかりました！」→ いきなり壁を作り始める → 途中で水道の配管を忘れていたことに気づく
CLAUDE.md + Tsumiki を使った場合：
あなた「カフェを作って！」
職人さん「ルールブックとマニュアルに沿って進めますね」
→ まず「どんなカフェにしたいか」をヒアリング（要件定義）
→ 次に設計図を書く（設計）
→ 作業を工程に分ける（タスク分割）
→ 一つずつ検査しながら作る（TDD で実装）
→ エラーメッセージは日本語で、設定値は外出しで（ルールブックに従う）
PRD と要件定義の違いは？
どちらも「何を作るか」を書いた文書ですが、具体さのレベルが違います。
| PRD | 要件定義書 | |
|---|---|---|
| 正式名称 | Product Requirements Document（製品要件定義書） | 要件定義書 |
| 中身 | 「何がほしいか」「なぜ必要か」 | 「具体的に何をどう作るか」 |
| 詳しさ | ざっくり | 細かい |
| 誰が作るか | Tsumiki では dcs:feature-rubber-duck が生成 |
Tsumiki では kairo-requirements が生成 |
たとえ話：
PRD は「注文書」です。
→ 「20席くらいのカフェがほしい。Wi-Fi があって、電源も使えて、
ランチメニューも出したい」
要件定義書は「設計図の前段階の仕様書」です。
→ 「座席数：カウンター8席、テーブル席12席（4人掛け3卓）
Wi-Fi：業務用ルーター1台、SSID はゲスト用と業務用を分離
電源：各テーブルにコンセント2口、カウンターに4口
ランチメニュー：日替わり1種、定番3種、提供時間 11:00〜14:00」
つまり、PRD → 要件定義書 の順に具体化されていきます。Tsumiki では、PRD をもとに要件定義書を自動生成できるため、まずは PRD（ざっくりした希望）を作れば十分です。
tsumiki コマンド解説
全体像：4つのコマンド群
Tsumiki には役割の異なる4つのコマンド群があります。
| コマンド群 | イメージ | 役割 |
|---|---|---|
| Kairo（回路） | 「地図と設計図」 | 要件定義から設計・タスク分割・実装まで、全体の流れを一気通貫で進める |
| TDD（テスト駆動） | 「精密な定規と検品機」 | 一つひとつの部品（機能）が正しく動くか、テストで厳密に確認しながら作る |
| Rev（リバースエンジニアリング） | 「レントゲンと解体新書」 | 既にあるコードを分析して、設計書・要件書・テスト仕様書などを書き起こす |
| DCS（開発コンサルティング） | 「相談相手と分析官」 | アイデアの整理、バグ調査、影響範囲の分析など、開発にまつわる相談ごとを AI が支援する |
1. Kairo コマンド群（包括的開発フロー）
「ゼロから新しく作る」ときに使います。上から順に実行していきます。
1.1 コマンド一覧と流れ
| 順番 | コマンド | 何をするか |
|---|---|---|
| 1 | /tsumiki:init-tech-stack |
プロジェクトで使う技術（言語、フレームワーク、ライブラリ等）を決めて記録する |
| 2 | /tsumiki:kairo-requirements |
「どんなものを作りたいか」を AI に伝え、要件定義書を生成する |
| 3 | /tsumiki:kairo-design |
要件をもとに、API の設計・データベース構造・画面構成などの設計書を生成する |
| 4 | /tsumiki:kairo-tasks |
設計を「やるべきタスク」に分割する。各タスクは個別ファイルで管理される |
| 5 | /tsumiki:kairo-implement |
タスクを順番に実装する。内部的に TDD の手順で進む |
1.2 補助コマンド
| コマンド | 何をするか |
|---|---|
/tsumiki:kairo-task-verify |
タスク分割後に、タスク内容を確認・検証する（tasks の後に実行推奨） |
/tsumiki:kairo-loop |
長時間の実装処理を安定して実行する。途中で会話が圧縮されても継続できる |
1.3 各ステップの補足
- ステップ2（要件定義）：コマンドの後に「作りたいものの概要」を書いて実行します
- 例：
/tsumiki:kairo-requirements ECサイトの商品レビュー機能を実装したい。ユーザーは5段階評価とコメントを投稿でき、他のユーザーのレビューを参照できる。
- 例：
- ステップ3（設計）以降：前のステップの成果物を確認し、必要に応じて修正してから次に進みます
- ステップ5（実装）：タスクを指定して実行することもできます
- 全タスク実行：
/tsumiki:kairo-implement - 特定タスクのみ：
/tsumiki:kairo-implement 要件名 TASK番号
- 全タスク実行：
具体的な使用例は「実践ガイド編」を参照してください。
2. TDD コマンド群（テスト駆動開発）
「一つの機能を丁寧に作る・修正する」ときに使います。TDD の仕組みやたとえ話は基礎知識編のセクション1.5を参照してください。
2.1 コマンド一覧と流れ
各コマンドには「要件名」と「TASK番号」を指定します。
| 順番 | コマンド | 何をするか |
|---|---|---|
| 1 | /tsumiki:tdd-requirements 要件名 TASK番号 |
その機能に必要な仕様を明確にする |
| 2 | /tsumiki:tdd-testcases 要件名 TASK番号 |
仕様に対応するテストケースを列挙する |
| 3 | /tsumiki:tdd-red 要件名 TASK番号 |
失敗するテストを書く |
| 4 | /tsumiki:tdd-green 要件名 TASK番号 |
テストを通す最低限の実装を書く |
| 5 | /tsumiki:tdd-refactor 要件名 TASK番号 |
コードを見やすく整える |
| 6 | /tsumiki:tdd-verify-complete 要件名 TASK番号 |
仕様通りになっているか最終確認する |
※「要件名」と「TASK番号」の補足
TDD コマンドで指定する「要件名」と「TASK番号」は、Kairo の kairo-tasks（タスク分割）を実行した際に AI が自動で生成・命名したもの をそのまま使います。自分で名前を考える必要はありません。
たとえ話：
kairo-tasks を実行すると、AI が「作業指示書の束」を自動で作ってくれます。
docs/tasks/
└─ user-auth-system/ ← 要件名（AI が自動で命名したフォルダ名）
├─ overview.md ← タスク全体の概要
├─ TASK-0001.md ← 1番目のタスク（例：基礎を作る）
├─ TASK-0002.md ← 2番目のタスク（例：足場を組み立てる）
└─ TASK-0003.md ← 3番目のタスク（例：骨組みを作る）
TDD コマンドを実行するときは、このフォルダ名とファイル名をそのまま指定します。
実行例：
/tsumiki:tdd-requirements user-auth-system TASK-0001
^^^^^^^^^^^^^^^^ ^^^^^^^^^
フォルダ名 ファイル名（.md は不要）
つまり、手順は以下のとおりです。
kairo-tasksを実行する → AI がタスクファイルを自動生成するdocs/tasks/フォルダを見て、フォルダ名とファイル名を確認する- その名前をコマンドにコピーして使う
2.2 DIRECT コマンド（テスト不要なタスク用）
テスト（検査）が不要なタスクに使うコマンドです。
タスク分割時に「DIRECT」（TDD不要）と判定されたタスクは、TDD の6ステップではなく、以下の2ステップだけで処理します。
| 順番 | コマンド | 何をするか |
|---|---|---|
| 1 | /tsumiki:direct-setup 要件名 TASK番号 |
タスクの内容を確認し、そのまま実行する |
| 2 | /tsumiki:direct-verify 要件名 TASK番号 |
実行結果が正しいか確認する |
DIRECT と判定されるタスクの例
- 設定ファイルの作成（config.json、.env など）
- フォルダ構造の作成
- パッケージ（ライブラリ）のインストール
- 定型的なテンプレートファイルの配置
これらは「正しく動くかテストする」よりも「作るべきものを作って確認する」だけで十分なタスクです。
Kairo 経由の場合は自動判定
kairo-implement を使う場合、各タスクが TDD か DIRECT かは自動的に判定されるため、利用者が選ぶ必要はありません。
TDD コマンドを単独で使う場合
既存ツールへの機能追加で TDD コマンドを単独で使う際に、テスト不要な作業（設定ファイルの追加など）が含まれる場合は、その部分だけ direct-setup → direct-verify で処理できます。
3. Rev（リバースエンジニアリング）コマンド群
「既にあるコードを分析して、ドキュメントを書き起こす」ときに使います。
3.1 どんな時に使うか
- 前任者が作ったツールを引き継いだが、ドキュメントがない
- 昔自分が作ったツールの中身を忘れてしまった
- Tsumiki を使わずに作ったコードを、Tsumiki 管理下に置きたい
3.2 コマンド一覧（推奨実行順）
上から順に実行すると、段階的にコードの全体像がドキュメント化されます。
| 順番 | コマンド | 何をするか |
|---|---|---|
| 1 | /tsumiki:rev-tasks |
コードの中にある機能を「タスク」として洗い出す |
| 2 | /tsumiki:rev-design |
コード構造から設計書（API 設計、データ構造など）を書き起こす |
| 3 | /tsumiki:rev-specs |
テスト仕様書を生成し、テストすべき内容を見える化する |
| 4 | /tsumiki:rev-requirements |
コードが「何を目的としているか」を要件定義書としてまとめる |
3.3 使うとどうなるか
- 複雑なコードを読み解かなくても、AI が日本語で説明してくれる
- 現状の設計図が復元されるため、「どこを直せば機能が追加できるか」がわかる
- Rev で解析した結果をもとに、Kairo や TDD の流れに乗せることができる
3.4 注意事項
- 生成された内容は必ずレビューしてください
- AI が推定した要件は、実際のビジネス要件と異なる場合があります
- テストケースは実装状況からの推定のため、完全ではない可能性があります
4. DCS（開発コンサルティング）コマンド群
「AI に相談しながら考えを整理したい」「問題を調査したい」ときに使います。
4.1 DCS とは
DCS は Developer Consulting Skills（開発コンサルティングスキル）の略で、開発にまつわるさまざまな「相談ごと」を AI が支援するコマンド群です。Kairo・TDD・Rev がコードを「作る・検証する・読み解く」ためのコマンドであるのに対し、DCS は「考えを整理する」「問題を調査する」ためのコマンドです。
4.2 コマンド一覧
| コマンド | 何をするか |
|---|---|
/tsumiki:dcs:feature-rubber-duck |
アイデアを対話で整理し、実現可能な要件定義書（PRD）を作成する |
/tsumiki:dcs:bug-analysis |
バグの原因を段階的に絞り込んで特定する |
/tsumiki:dcs:impact-analysis |
コード変更が他のどこに影響するかを調査する |
/tsumiki:dcs:incremental-dev |
既存ツールへの機能追加を段階的に計画する |
/tsumiki:dcs:performance-analysis |
処理が遅い原因を調査する |
/tsumiki:dcs:sequence-diagram-analysis |
機能の処理の流れを図（シーケンス図）にする |
/tsumiki:dcs:state-transition-analysis |
データの状態変化の流れを分析する |
4.3 ラバーダックコマンド（feature-rubber-duck）の詳細
DCS の中で最もよく使うコマンドです。AI が聞き役になり、質問を投げかけながらアイデアを一緒に具体化してくれます。
何ができるか
- 曖昧なアイデア（「こんな機能がほしい」「これを改善したい」）を対話で具体化できる
- AI が質問を投げかけてくれるので、自分では気づかなかった観点が見つかる
- 必要に応じて、既存のコードや技術情報を AI が自動で調べてくれる
- 最終的に PRD（Product Requirements Document：製品要件定義書）が自動生成される
使い方
コマンドの後にアイデアの概要を書いて実行します。
/tsumiki:dcs:feature-rubber-duck Jira の作業ログを自動でスプレッドシートに出力する機能がほしい
アイデアがまだ固まっていない場合は、コマンドだけ実行すれば AI から質問してくれます。
/tsumiki:dcs:feature-rubber-duck
4.4 その他の DCS コマンドの補足
| コマンド | どんなときに使うか | 実行例 |
|---|---|---|
dcs:bug-analysis |
「エラーが出るが原因がわからない」とき | /tsumiki:dcs:bug-analysis データ取得時にタイムアウトエラーが発生する |
dcs:impact-analysis |
「この部分を変えたら他に影響が出ないか心配」なとき | /tsumiki:dcs:impact-analysis 認証処理の変更 |
dcs:incremental-dev |
「既存ツールに少しずつ機能を足したい」とき | /tsumiki:dcs:incremental-dev CSV出力機能の追加 |
dcs:performance-analysis |
「処理が遅いが何が原因かわからない」とき | /tsumiki:dcs:performance-analysis レポート生成が遅い |
dcs:sequence-diagram-analysis |
「処理の流れを図で見たい」とき | /tsumiki:dcs:sequence-diagram-analysis ログイン処理 |
dcs:state-transition-analysis |
「データがどう変わっていくか整理したい」とき | /tsumiki:dcs:state-transition-analysis 注文ステータス |
いずれもコマンドの後に対象を書いて実行します。結果は .dcs/ フォルダに保存されます。
実践ガイド
1. コマンド群の使い分けガイド
1.1 早見表
| やりたいこと | 使うコマンド群 |
|---|---|
| アイデアを整理して具体化したい | DCS（dcs:feature-rubber-duck で対話しながら整理） |
| ゼロから新しいツールを作る | Kairo（init-tech-stack から順に実行） |
| 既存ツールに機能を追加したい（何を追加するか相談したい） | DCS（dcs:feature-rubber-duck または dcs:incremental-dev） |
| 既存ツールに機能を追加したい（何を追加するか決まっている） | TDD（tdd-requirements から順に実行） |
| 既存コードのドキュメントを整備したい | Rev（rev-tasks から順に実行） |
| ドキュメントのない既存コードを改修したい | まず Rev で分析 → その後 Kairo または TDD |
| バグの原因を調査したい | DCS（dcs:bug-analysis で段階的に原因を特定） |
| 変更の影響範囲を確認したい | DCS（dcs:impact-analysis で関連箇所を洗い出し） |
1.2 Kairo と TDD の関係
TDD は Kairo とは別物ではなく、Kairo の実装ステップ（kairo-implement）の中で自動的に使われる仕組みです。
【Kairo の流れ】
① init-tech-stack … 技術選定
② kairo-requirements … 要件定義
③ kairo-design … 設計
④ kairo-tasks … タスク分割（各タスクが TDD か DIRECT か自動判定される）
⑤ kairo-implement … 実装 ← ここで自動的に分岐
│
├─ TDD 判定のタスク → tdd-requirements〜tdd-verify-complete が順に実行される
└─ DIRECT 判定のタスク → direct-setup〜direct-verify が実行される
TDD コマンドを単独で使うのは、Kairo を経由せずに既存ツールの機能追加や修正を行う場合です。
1.3 TDD コマンドを使うかどうかの判断基準
Kairo の実装ステップ（kairo-implement）では、各タスクが「TDD」か「DIRECT」か自動判定されます。TDD コマンドを単独で使う場合は、以下を参考にしてください。
TDD が不要なケース
- 自分専用のツール（失敗しても自分だけが困る）
- 使い捨てのスクリプト（今回だけ動けばよい）
- 単純な処理（「ファイルを読み込んで変換するだけ」のような一本道の処理）
TDD を使うべきケース
- 重要度が高い（他部署や顧客が使う、お金や個人情報を扱う）
- ルールが複雑（条件分岐が多い）
- 長く使い続ける（今後も機能追加の予定がある）
2. シーン別：具体的な進め方フロー
すべてのシーンは、以下の「2つの基本フロー」のどちらかで進めます。まず基本フローを覚えて、次にどのシーンでどちらを使うかを確認してください。
2.1 2つの基本フロー
基本フロー A：Kairo フロー（ゼロから作る・大きな変更）
全体の設計から始めて、一気通貫で進めるフローです。
① /tsumiki:dcs:feature-rubber-duck → AI と対話しながらアイデアを整理。PRD が生成される
② PRD の内容を確認・修正
③ /tsumiki:init-tech-stack → 技術選定（補足参照）
④ /tsumiki:kairo-requirements → 要件定義
⑤ /tsumiki:kairo-design → 設計
⑥ /tsumiki:kairo-tasks → タスク分割
⑦ /tsumiki:kairo-implement → 実装（TDD / DIRECT は自動選択）
※ rubber-duck の補足： やりたいことが自分の中で明確に言語化できている場合は、①を飛ばして②から始めても構いません。ただし、非エンジニアの場合は rubber-duck から始めることで AI が不足している観点を補ってくれるため、基本的には①から始めることを推奨します。
※技術選定（init-tech-stack）の補足： 非エンジニアの場合、「どの技術を使うか」の判断は難しいかもしれません。CLAUDE.md にデフォルトの技術スタック（例：GAS をメインで使う）を記載しておけば、AI がそれを読み取って適切な技術を提案してくれます。技術選定は AI に任せて、提案された内容を確認するだけで大丈夫です。わからなければ、そのまま AI に聞いてみましょう。
基本フロー B：TDD フロー（小さな追加・修正）
既存ツールの一部を変更するフローです。
① /tsumiki:dcs:feature-rubber-duck → AI と対話しながらやりたいことを整理
② /tsumiki:tdd-requirements → 仕様を明確にする
③ /tsumiki:tdd-testcases → テストケースを列挙
④ /tsumiki:tdd-red → 失敗するテストを書く
⑤ /tsumiki:tdd-green → テストを通す最小限の実装
⑥ /tsumiki:tdd-refactor → コードを整理
⑦ /tsumiki:tdd-verify-complete → 最終確認
各コマンドには「要件名」と「TASK番号」を指定します（詳しくはツール・コマンド解説編のセクション2.1を参照）。テスト不要な作業（設定ファイルの追加など）は、TDD の代わりに direct-setup → direct-verify の2ステップで処理します。
2.2 シーンごとの進め方
新規開発（ゼロからツールを作る）→ 基本フロー A
基本フロー A をそのまま実行
既存システムへ新機能を追加する → 基本フロー A または B
既に動いているツールに機能を追加する場合は、基本フロー B（TDD）で進めるのが効率的です。TDD でテストを作っておくことで「新機能を入れたら既存機能が壊れた」という事故を防げます。ただし、追加の規模が大きい場合は基本フロー A を使います。迷ったら AI に相談してください。
/tsumiki:dcs:incremental-dev 〇〇機能を追加したい
→ AI が既存コードを分析し、適切な進め方を提案してくれる
目安は以下のとおりです。
| 追加の規模 | 使うフロー | 例 |
|---|---|---|
| 小さい（既存の仕組みの延長） | 基本フロー B | CSV 出力機能を追加 |
| 大きい（新しい設計が必要） | 基本フロー A（init-tech-stack はスキップ可） | 月次レポート自動生成を追加 |
既存ツールの困りごとを直す（バグ修正・改善）→ 基本フロー B
基本フロー B を実行
困りごとの内容に応じて、基本フロー B の前に DCS コマンドで AI に相談すると効率的です。
| 困りごと | 事前に実行する DCS コマンド |
|---|---|
| エラーが出るが原因がわからない | /tsumiki:dcs:bug-analysis 〇〇のときにエラーが発生する |
| 変更が他の機能に影響しないか心配 | /tsumiki:dcs:impact-analysis 〇〇の処理を変更 |
| 処理が遅い | /tsumiki:dcs:performance-analysis レポート生成が遅い |
| 原因がわかっている・単純な改善 | DCS 不要。基本フロー B からそのまま開始 |
2.3 補足
既存コードにドキュメントがない場合
先に Rev で既存コードを分析してから進めると安全です。
/tsumiki:rev-tasks → rev-design → rev-specs → rev-requirements
→ 既存コードの構造・仕様をドキュメント化してから、上記のフローに進む
どのシーンでも共通のポイント
- 各ステップの成果物（要件書、設計書、テストケースなど）は必ず内容を確認してから次に進む
- AI の出力が的外れな場合は、ドキュメントを手動で修正してよい
- コマンドには「やりたいこと」をできるだけ具体的に書くと精度が上がる
- 迷ったら DCS コマンドに相談する。自分で判断する必要はない
tsumiki を理解してから使ってみて感じたこと
「使える」と「理解している」は全然違う
振り返ってみると、最初の私は「しくみはよくわからんけど、とりあえずツールを作る流れはつかめた」という状態でした。それはそれですごいことなのでしょうが、自分の『困った』を解消するためには理解が必要になります。
理解してから使うと、世界が違って見えるんです。「あぁ！あの時失敗したのはこのせいだったのか！」という気づきもありました。
全体像がわかると「迷子」にならない
tsumiki にはコマンドがたくさんありますが、この記事で紹介したように「4つのコマンド群」と「2つの基本フロー」を押さえておけば、自分が今どこにいて次に何をすればいいかがわかるようになります。
以前の私は「とりあえずコマンドを打って、動いたからヨシ！」でしたが、全体像を理解してからは「ここは Kairo で進めて、この部分だけ TDD で丁寧にやろう」と判断できるようになりました。迷ったら DCS に相談すればいいという安心感も大きいです。
最後に
このガイドの作り方 —— AI に聞きまくっただけです
冒頭でちらっとお伝えしましたが、今回ご紹介したガイドは、はらしまが自分の言葉で書き綴ったものではありません。公式ドキュメントを読んでも理解できなかったので、AI にひたすら聞きまくって作ってもらいました。
やったことはシンプルで、「公式ドキュメントを読み込んで非エンジニア向けにかみ砕いて説明して」「たとえ話を入れて」「わからないから詳しく教えて」と何度もお願いしただけです。
AI は何度同じことを聞いても嫌な顔をしません（顔なんてないけどw）。相手の時間を気にすることも、申し訳ないと気負うこともありません。わかるまでとことん付き合ってくれます。
一歩を踏み出すきっかけになれたら
「便利なものがあるのはわかっている。だけど、何から始めていいかわからない。」と、一歩を踏み出すところにとてつもなく高い壁を感じていらっしゃる方も多いと思います。特に自分の力では理解が難しい領域に手を伸ばそうとするのは恐怖しかありませんよね。
まずは tsumiki ガイドを読んで全体像をつかむところから。そして、わからないことがあったら AI にとことん聞いてみてください。この2つのステップだけで、驚くほど世界が変わります。
このブログが、次の一歩を踏み出すきっかけになってくれたら嬉しいです。特に非エンジニアの方に「一歩踏み出せたよ」って言ってもらえたら泣いて喜びます。
AI コワクナイヨ！（前回ブログで言いましたが大事なことなので2回言いました）
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました
