twadaさんによるTDDワークショップ2026を開催しました！

はじめに

Classiでは5年ぶり2度目となるTDDワークショップを『テスト駆動開発』の翻訳者として知られる t_wada さんこと和田卓人さんにオンラインで開催していただいたので、その様子をお伝えします。
前回の記事はこちらになります！ ​​

tech.classi.jp

概要

ワークショップは午前と午後の2部制で午前中は講義、午後にはTDD実践という流れで1日をまるまる使って実施していただきました。

午前の講義では、「AIとの協業を支える自動テスト」をテーマにAIとの向き合い方やAIと開発をするうえでのテストの立ち位置についての講義を行っていただきました。

午後からはAIを使わず、TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング - YouTubeや講義で出てきたTDD例を参考に「整数の閉区間」というお題で4つのレベルの中から選んでTDDを実践し、t_wadaさんにレビューをしていただきました。TDDを行う中で参考にしたのが以下になります。（参考: 【翻訳】テスト駆動開発の定義 - t-wadaのブログ]）

1. 網羅したいテストシナリオのリスト（テストリスト）を書く

2. テストリストの中から「ひとつだけ」選び出し、実際に、具体的で、実行可能なテストコードに翻訳し、テストが失敗することを確認する

3. プロダクトコードを変更し、いま書いたテスト（と、それまでに書いたすべてのテスト）を成功させる（その過程で気づいたことはテストリストに追加する）
4. 必要に応じてリファクタリングを行い、実装の設計を改善する
5. テストリストが空になるまでステップ2に戻って繰り返す

参加した人の感想

いもり
エンジニアに求められるのは「やりたいことを正確に言語化・設計する力」だと再認識できた1日でした。
午前の講義で特に印象深かったのは「AIとの伴走パターン」のテンプレートです。事前に設計書を作成・レビューしてから実装させる手法は、その後のコーディング精度を劇的に向上させると感じ、普段の開発にもすぐに取り入れられた内容でした。
午後のワークショップではTDDに初挑戦しましたが、最初のリスト作成以上に、開発サイクルの中での「TODOリストの軌道修正」に苦戦しました。原因としてはリスト単位の機能実装に集中するあまり、全体像を見失ってしまった点にあります。部分と全体を行き来し、時には柔軟に設計方針を見直す視点こそが、開発を行う上での重要なスキルなのだと痛感しました。

kanapiii22 ( id:kanapiiii )
今回のTDDワークショップで特に印象に残ったのは、「テストはコードで書く仕様書である」という言葉でした。これまでの私は、RSpecを「実装したコードが意図通りに動いているかを確認するためのもの」として書いており、テストは実装の後追いになっていました。しかし、事前動画やワークショップを通して、使用や振る舞いを先に言語化し、それをテストとして表現するという体験をし、テストそのものが仕様書の役割を果たす感覚をつかむことができました。
将来このコードを読むチームメイトが、テストを読むことで使用を理解できるようにするためにも、今回ワークショップでつかんだ「テストをドキュメントとして書く」という感覚を忘れず、チームに戻ってからも振る舞いを表現にするテストを書くことを意識していきたいと思います。

akinko
本講義を通じ、AI時代におけるエンジニアの真価は「知識に基づいたディレクション能力」にあると再認識しました。直感的な「Vibe Coding」に留まるのではなく、専門知識を駆使してAIを自律的に制御する「Agentic Coding」へと昇華させることが、プロのエンジニアには不可欠であると身が引き締まる思いになりました。
午後のワークショップでは、テストリストの作成を通じて自身の設計スキルの現在地を痛感しました。実装前に設計を言語化し、思考の解像度を高めることが、成果物の品質を左右するのだと改めて学びました。今回の気づきを糧に、より一層スキルアップに励みたいと思います。

すずまさ
受講前は、TDDの概要こそ知っていたものの「一気に実装してからテストを書く方が効率的に書けるのではないか」と考え、実践したことはありませんでした。
しかし、今回TDDを体験したことで、むしろ実装が複雑なものほど全体的なスピードが上がりそうだと感じました。

ワークショップでは小さめのお題を対象に取り組みましたが、当初作成していたTODOリストは次々と更新され、最終的には2倍近い数の項目になっていました。
実際の業務でも、TODOに漏れが見つかり想定より時間がかかることはよく経験しているので、Red→Green→Refactorのサイクルを小さく回すことで素早く漏れに気づけるのはTDDの強みだと感じました。
また、小さくステップを刻むことで、複雑な仕様でどこから着手していけばよいかわからない場合も、設計を練りながら「とりあえず書いてみる」ことができるのも魅力的でした。

AIとどう協働していくかの話も含めて、明日から実践できる学びを多く得られたので早速取り入れていきたいと思います！

しらたき
講義の中で言及されていた「AIと作業するときは細かく指示するより、広く使われているテクニックを一言伝える方が正確」という教えは、目から鱗でした。 デザインパターンなどの標準的な語彙を学ぶことは、単なる実装技術の向上以上に、AIとのコミュニケーションコストを下げるために不可欠だと痛感しました。
また、私がやっていたのは「Vibe Coding」であり、「Agentic Coding」ができていなかったなと気づきにもなりました。
データエンジニアリングの領域でも、標準的なアーキテクチャやパターンを意識的に取り入れ、AIと共通言語で対話できるスキルを磨いていきたいです。

マイン
午前中はAIと開発についての話でした。いろいろな新しいキーワードが出てきて、とても面白かったです。AIが進化しても、人間がテストを書いて「何が正しいか」を決めることが大切だとわかり、勉強になりました。

午後は実際にTDDを体験しました。テストを先に書くやり方は初めてでしたが、少しずつコードを作る感覚がよくわかりました。今まではテストを「最後にするもの」と思っていましたが、これからは「作りながら考えるための道具」として使っていきたいです。

とても役に立つワークショップでした。明日からの仕事でも頑張って使ってみます。

いしかわ
テスト駆動開発を理論だけで終わらせず、手を動かして学べたのは大きな収穫でした。 特に印象的だったのは、オープンな場でのコードレビューです。自分ひとりの視点だと気づけない「詰まりどころ」や、それに対する回答を周りと共有できたことで、学びの解像度がぐっと上がりました。

また、AIコーディングの難しさについても改めて実感しています。ハルシネーション以上に「AIが自分に合わせすぎてしまう（イエスマン化）」（シコファンシー）の方が意外と厄介だなと感じています。AIは自分の考えを肯定して増幅させるツールだからこそ、流されないように主導権を持って使っていきたいです。

アイン
今回のTDDワークショップを通して、開発における「考える順番」の重要性を改めて実感しました。特に印象的だったのは、テストを書くことで「何を作るべきか」「何が正しい振る舞いか」を先に決められる点です。

午後のワークでは、TODOリストを何度も見直しながら進める難しさと同時に、その過程自体が設計を洗練させていくことを体験できました。
また、AIを使った開発においても、人が設計と判断を担う重要性を強く感じました。今後からの開発でも、小さなサイクルで考え、確認し、改善する姿勢を大切にしていきたいです。

daichi ( id:da1chi24 )
普段サービス開発をしていると「ユーザー視点で考えろ」と言われます。これはUIに限った話ではなく、インターフェース設計やアーキテクチャにも通じる考え方です。今回の研修を通じて、テスト駆動開発とは「実装するメソッドを利用者としてどう使いたいか」から設計を考えるプロセスであり、Red / Green / Refactor の手順を行う中で自然と利用者視点の設計になる手法だと腹落ちしました。これは大きな学びでした。

研修全体を通して、テスト駆動開発だけでなく、エンジニアリングの歴史やAIとの向き合い方、t_wadaさんご自身の学習の姿勢に至るまで、幅広い内容に触れられました。知識として理解するだけではなく、リアルタイムに質疑しながら学べたことは研修ならではの価値だったと思います。一流のエンジニアの思考に触れて、刺激になりました。ありがとうございました。

ねこびっと
TDDワークショップの中で一番手が止まってしまったのは、最初のリストを作るフェーズでした。その原因は全体から詳細までを決めてからテストを書き始める必要があるからだと思い込んでしまっていたためです。ですが、ワークショップやレビューを通して、TDDにおいてリストは途中で変更をしても良いものであり、さらにはテストコードまでも状況によっては変更をしても良いという柔軟性のあるものであることを学ぶことができました。
開発、設計におけるプロセスは成果物では体験しづらいので、ワークショップを通してTDDにおける試行錯誤のプロセスを体験できたのは非常に良かったです。今回得られた感覚を大切にして日々の開発に活かしていきたいと思います。

開催の背景

lacolaco ( id:lacolaco )
プラットフォーム部のlacolacoです。Classiでは2020年に一度t_wadaさんのTDDワークショップを開催し、参加者からは非常に好評でしたので、またお呼びしたいとずっと思っていました。2025年は、社内でも生成AIを使ったAgentic Codingの導入も本格的になり、コードを読み書きする仕事の形や意味が変わっていく時期でした。特に、新卒エンジニアにとっては生成AIと共に行う業務が最初の経験になります。開発のスピードがどんどん加速する状況の中で、ソフトウェアの開発をいかに安心できる、地に足ついたものにするかということは、これまで以上に深刻な課題になっていると感じていました。そこで、いまこそテスト駆動開発の考え方が必要だと思い、t_wadaさんにお声がけをしました。とてもいいタイミングで実施できたと思います。

おわりに

今回、研修を行っていただいた t_wada さんに改めてこの場で感謝申し上げます。講義中、コードレビューの際にSlack上や口頭での質問に一つ一つ丁寧に答えていただいたため、TDDにとどまらず、AIとの協業についてや設計、開発における考え方を得ることができたと思います。TDDワークショップを通して得られた知見を今後の開発に活かしていきたいと考えています。ありがとうございました！

Classiエンジニアの「OSSやっていきの集い」 〜活動1年を経て得られたプロセスによる学び〜

こんにちは、id:da1chi24 です。

Classi では、チーム横断でOSS活動に取り組む「OSSやっていきの集い」を行っています。早いもので活動開始から1年が経過しました。 発足の経緯や過去の活動は、前回の記事をご覧ください。

tech.classi.jp

ここでは、OSSやっていきの集いを通して、私自身が実際にOSSへコントリビュートした経験と、活動を通じて実感したメリットについてお話しします。

HTML Parser の修正（Herb へのコントリビューション）

社内では Rails サービスの開発をする際に、ERBの静的解析ツールとして Herb を利用しているリポジトリがあります。

github.com

ある日、HerbでHTMLをパースしているコードにおいて <div></DIV> のように大文字・小文字が混ざっていると、Parser エラーになることが分かりました。この挙動は普段ブラウザでは見かけないため、違和感がありました。

実際に発生していたエラー

Errors (2 total)

  1. MissingClosingTagError at sample.erb.html:1:0
     Opening tag `<div>` at (1:1) doesn't have a matching closing tag `</div>` in the same scope.

  2. MissingOpeningTagError at sample.erb.html:1:5
     Found closing tag `</DIV>` at (1:7) without a matching opening tag in the same scope.

そこで、改めて HTML Living Standard を確認すると「タグ名は case-insensitive である（大文字小文字を区別しない）」と明記されていました。

In the HTML syntax, tag names, even those for foreign elements, may be written with any mix of lower- and uppercase letters that, when converted to all-lowercase, matches the element’s tag name; tag names are case-insensitive. refs. https://html.spec.whatwg.org/multipage/syntax.html#elements-2

つまり、Herb Parser と HTMLの標準仕様は振る舞いに乖離がありました。特に深い意図がない限りは、基本的に Herb は HTMLの標準仕様に準拠するべきだと考え、Issue で報告しました。

さらに一歩踏み込んで原因を探るため、Herb Parser の内部実装も読んでみることにしました。Herb Parser は HTML + ERB を Abstract Syntax Tree (AST) という木構造に変換して解析しています。この AST を解析する処理を追っていくと、開きタグと閉じタグの比較が大文字・小文字を区別して行われている実装箇所がわかりました。その調査内容も Issue に追記しました。

github.com

報告後、オーナーの方から「確かにその通り、原因分かってるならぜひ直して欲しい！」というコメントをいただいたので、修正のPull Requestを作成、無事にマージされました。

github.com

1年間活動して感じた変化、当初の目的を達成できたのか

前回の記事では、活動を通じたアウトカムとして「OSSに関わる心理的ハードルを下げる」「実践を通じた学び」「チームを越えた交流」などが挙げられていました。実際に私が1年間参加してみて、これらは得られたのかを振り返ります。 https://tech.classi.jp/entry/2025/06/23/120000

OSSへの「心理的ハードル」が下がり、日々の仕事の質が上がった

以前の私は、問題の再現性をとってIssueを立てたり、普段開発をしないリポジトリに対して Pull Requestを作成したりすることに、ハードルを感じていました。しかしOSSやっていきの集いの中で、気軽に相談し、事象の再現方法を一緒に考えてくれる場があったことで、OSS活動へどのように関われば良いかという視点が得られました。その結果、私自身のOSSに対する心理的ハードルはかなり下がりました。

また、この「OSSに関わる観点やプロセス」は、普段の仕事にも直結していると感じています。Classi には社内ライブラリやデザインシステムがあります。こういった普段の自分が関わらないプロダクトに対しても、バグを見つけた際に「ここが原因だと思うので直していいですか？」と直接 Pull Request を出しています。こういった課題を拾い、原因調査をして、改善の提案をするまでの動きが早くなったという実感が得られました。

単なる指摘にとどまらず、解決策を提案するコミュニケーションを取るかどうかで、問題解決までの速度が上がるという話は、以下のブログで挙げられている「提案のレベル」の話に繋がっています。OSS活動での経験が、結果的に日々の仕事の「提案のレベル」を引き上げてくれたのだと思います。

konifar-zatsu.hatenadiary.jp

チーム横断で問題を解決する地力を育てる場になってきた

OSSやっていきの集いでは、新卒1年目のジュニアエンジニアからアーキテクトまで、チーム横断で様々なエンジニアが参加しています。同じチームでなくても、フラットにコミュニケーションを取る場になっています。 実際にOSSにコミットするために、仕様書を読み込んだり、内部実装をデバッグし状況が再現するようなエビデンスを集める必要があります。今ある課題を特定し、問題が再現する最小のコードを探していくプロセスは、普段の業務でのバグ修正や障害対応に直結しています。こういった実践的な学びを得られる場として、OSSやっていきの集いは機能していると思います。

社内のレベルを底上げするOSSやっていきの集い

この1年間で、OSS活動はコントリビュートするという結果だけでなく、「課題を発見し、他人に伝わる形で再現し、実際に手を動かして解決するというプロセスそのものに重要な学びがある」と感じました。こういったプロセスを複数のメンバーと取り組むことで、個人の学びを組織の学びに昇華できる重要な機会になっています。今後も続けていきたい活動です。

今回の記事を読んで、1つでも得られるものを持ち帰っていただければ幸いです。

学習記録をもっと使いやすく。「一日の振り返り」改善ができるまで

こんにちは。Classi のコーチング／校務支援チームの とみやま（id:tommy1038）です。

この記事では、過去に担当した学習記録の「生徒の一日の振り返り」に関する改善施策を題材に、 Classi では日々どのように機能改善を進めているのかを、具体的な事例を通じてご紹介します。

今回題材にする機能

今回取り上げるのは、先生用の画面で

• 生徒の「一日の振り返り」の記入履歴
• それに対する先生のコメント数

を、生徒ごとの詳細画面を開かなくても 「生徒一覧」画面でまとめて確認できるようにした改善 になります。

もともとは、振り返りやコメントの状況を確認する際、

生徒の詳細画面を開く→ 内容を確認する → 一覧へ戻る → 次の生徒を開く……

という操作が必要でした。 この導線を見直し、一覧画面上で状況を把握できるようにしたのが、今回の改善です。

改善後の生徒一覧画面

なお、本機能については、ヘルプページでも紹介されています。

support.classi.jp

この改善に取り組むきっかけ

先生方からは、次のような声が寄せられていました。

• 生徒が数日前や1週間前にさかのぼって振り返りを記録した場合、見逃してしまうことがある
• 週初めや休暇明けなど、複数日の記録をまとめて確認したい場面で、ひとつずつ画面を開くのが大変

特に、“記入された振り返りへ、きちんとコメントを返したい” という思いが強い学校ほど、見逃しが発生しやすい構造になっていました。

そこで今回は、

• 生徒ごとに「一日の振り返り」の記入がある、最新3件の日付
• それぞれの日付に対する先生からのコメント数

を、生徒一覧画面に表示するようにしました。 これにより、生徒ごとの状況を詳細画面を開かなくても把握しやすくなることを目指しました。

タスクの選定

Classi では、機能ごとに担当チームがあり、そのチームの中で新機能の実装・改善・保守運用を行っています。

改善要望を確認したあとは、次のような観点で「どういった時期に対応するか」を検討します。

• 緊急度・優先度
• ユーザーへのインパクト
• 実装および運用コスト

今回の改善は、学校現場での困りごとが明確であり、比較的小さな実装で先生の負担感が改善される見込みがあったため、対応することに決めました。

対応決定後は、

• どの画面で、どう見えると先生は使いやすいか
• 既存 UI との整合性はどうか
• どのように実装するとシンプルで保守しやすいか

といった観点で、もう少し深く検討を進めていきました。

UI案の検討

仕様の方向性がある程度見えたところで、UI モックを作成し、複数案を検討しました。

例えば、

• 先生が最後にコメントした日時を表示する案
• 生徒の振り返りコメント日をすべて表示する案

なども候補に挙がりました。

検討した表示案

しかし、これらの案には

• 情報量が多くなりすぎる
• 一覧画面としての見通しが悪くなる

という課題がありました。

最終的に

• 生徒ごとに「一日の振り返り」の記入がある、最新3件の日付
• それぞれの日付に対する先生からのコメント数

という形にすることで、必要な情報を保ちつつ、一覧としての見やすさも損なわないバランスを実現できると判断し、現在の仕様に落ち着きました。

多職種での協働

今回の改善では、開発チームだけでなく、

• CS チーム
• QA チーム
• 学校現場を支援している社内メンバー

とも相談しながら進めました。

さらに、実際に学習記録を活用いただいている先生にもヒアリングの機会をいただき、

• どのような表示だと確認しやすいか
• 現場の運用イメージと合っているか

といった観点でご意見を伺いながら検討しました。

こうした 多職種での連携を自然に行える体制 は、Classi の開発の大きな強みだと感じています。

実装から QA 検証へ

UI 案と仕様の方向性が固まった段階で実装に進み、一覧画面への表示追加や、必要なデータ取得の調整を行いました。

検証環境で動作を確認した後、QA チームと連携してリグレッションテストを実施します。

今回の改善に限らず、実際の利用シーンや権限の違いなど、さまざまなパターンを想定して確認してもらっています。

開発側だけでは気づきにくい観点も多く、QA チームにはいつも支えてもらっています。

リリースと先生の反応

QA を通過したのち、本番環境へリリースしました。 リリース後、営業メンバーを通じて

夏休み直前のタイミングでリリースしてもらえて、本当に助かりました

といった声もいただきました。 実際の現場で役立っている様子を伺えるのは、開発者として本当に嬉しい瞬間です。

おわりに

今回ご紹介した改善は、学習記録をより使いやすくするための取り組みの一つです。

その中で、

• 学校現場での困りごとを拾いあげ
• チームで検討し
• 関係者と連携しながら形にしていく

というプロセスを続けていくことが、 Classi の使いやすさ向上につながると考えています。

今後も、いただいた声を参考にしながら、学校のみなさまにとって使いやすいサービスを目指して改善を続けていきます。 ここまで読んでいただき、ありがとうございました。

学習トレーニング機能の「メモ機能」のリリースと開発プロセスの振り返り

学習トレーニングチームのいもりです。

学習トレーニングは11月初旬に新機能として、画面上にメモを取ることができる「メモ機能」をリリースしました。

chienowa.classi.co.jp

リリース後の活用は徐々に伸びており、特に計算が必要な数学で活用いただいています。

この機能は他プロジェクトと並行して進めていたため、検討に割けるリソースは限られていました。今回は要件定義のフェーズでAIによるプロトタイピングを活用し、チームの認識合わせを効率化するアプローチを取りました。

「動くもの」をベースに議論することで、検討開始から仕様確定までを約1ヶ月で完遂し、顧客に必要な機能を素早く届けることができました。本記事では、その開発プロセスについて紹介します。

開発経緯

「学習トレーニングの画面内でメモを取りたい」という要望は、学習トレーニングリリース当初からいただいている改善要望でした。

とはいえ、私が現在のチームに所属してからの半年間は、より緊急度や要望数の高い別の課題への対応を優先して進めていました。しかし、それらのクリティカルな課題を一つひとつ解消していくにつれて、ユーザーの不満点が「より良い学習体験」へとシフトし、結果としてメモ機能への要望が以前よりも顕著に届くようになりました。

メモ機能がないことが学習体験における最大のボトルネックになった今こそ、この要望に向き合うべきタイミングだと判断し、本格的な開発に着手しました。

「動くもの」を共通言語に

まずは現状分析を行いました。データサイエンティストが主導してVoC分析を行い、顧客が直面している課題を浮き彫りにしていただきました。

印象的だったのが、「紙を用意するのが面倒なだけでなく、PCのメモ帳アプリを横に開いて計算している生徒もいる」という事実です。いかなるデバイスであっても学習を画面内で完結させたいニーズがあることがわかったため、すべてのデバイスで利用可能なWebの機能として実装する方針が固まりました。

ですが、いざ要件定義に入ると既存の解答画面への影響やどの機能が必要か？という懸念が生まれ、具体的な実装イメージが定まりませんでした。

そこで、社内で開催されている「フロントエンド互助会」に相談を持ち込み、先行事例や方向性のアドバイスをいただきました。いただいた知見をベースに、AIコーディングを活用してプロトタイピングを実施し、解答画面上に被せてメモが取れる機能を20分程度で作成しました。

画像内に登場する画面は開発環境になります

実際に動くものができたことでチーム内の議論の解像度が一気に高まり、具体的な機能要件へ踏み込むことができるようになりました。

「引き算」の意思決定

AIコーディングを活用すれば機能追加を行うこと自体は難しくありません。実際に何が必要な機能かを見極めるために、開発当初は既存ペイントツールにあるRedo/Undoなどの様々な機能を搭載したメモ機能をプロトタイプで作成し、社内ドッグフーディングを行いました。

社内ドッグフーディングを経て見えてきた課題は、スマートフォンでの限られた画面領域における操作性でした。多機能を搭載したメモはキャンバスエリアが狭くなり、ボタンの押し間違いも発生しやすく使い勝手を損なうことがわかりました。

そこで私たちは「ペイントツールではなく問題を解くための補助的なメモ機能である」という原点を思い出し、学習中のメモを取る際にストレスなく利用できるシンプルさを最優先事項としました。誤操作により体験を損なう可能性のあるRedo/Undoなどは搭載せず、必要な機能だけに絞り込む「引き算」の意思決定を行いました。

この決断で各機能の要件がシンプルになり、要件定義がスムーズに進行したことが短期間のリリースに繋がりました。

リリース後の反響と振り返り

リリースから1ヶ月以上が経過しました。グラフは1日ごとのメモの利用回数ですが、利用状況は順調に推移しています。また、リリース当初は解答UU数に対して1日あたり6%程度の利用数だったのに対し、現在は13%程度まで増加しています。

特に近い時期にリリースした数学Ⅲの問題での活用はトップクラスであり、当初の狙いであった「紙を用意する手間をなくし、学習に集中する環境を作る」という価値を必要としているユーザー層に届けられたと実感しています。

社内からの反応も励みになりました。ドッグフーディングでは早くリリースしたほうがいいと感想をいただいたり、窓口対応チームからは「特に良い改善だった」という声をいただいたことは素直に嬉しかったです。作り手として自信を持ってユーザーに案内できる機能を提供できたことはプロダクト開発における理想的な形を実現できたのではないかと考えています。

今回の開発を振り返って個人的に最大の収穫だったのは、AIなどの技術を活用することで、エンジニア個人の「要件定義の質とスピード」を劇的に向上させられると実感できたことです。 「どう実装するか（How）」をAIや互助会の知見でショートカットできた分、チームの議論が「何を作るべきか（What）」という本質に迫ることができ、機能の「引き算」といった意思決定に時間を割くことができました。

新しい技術を適切に活用することで、エンジニアは顧客の課題により深く向き合えるようになります。今後も技術の力を借りながら、ユーザーにとっての正解を最短距離で探り当てるプロダクトエンジニアリングを追求していきたいです。

ディップ×ココナラ×ギフティ×Classi 合同勉強会 開催記｜若手エンジニアが「外」に出て見つけた、技術の先にあるもの

こんにちは、Classi エンジニアの yuu.kun です。

2025年12月2日、ディップ、ココナラ、ギフティ、Classiの4社合同勉強会「大規模Webサービスの技術負債、どう向き合う？？」を開催しました。

今回のイベント、Classiからは新卒メンバーとエンジニアリングマネージャーの鳥山が参加しました。私はその中で、企画・運営担当として携わりました。 本記事では、イベントの裏側である「開催に至るまでの経緯」や「運営サイドから見た気づき」を私から、そしてイベント本編のテーマである「技術負債に関する知見」を鳥山から、それぞれレポートします。

開催に至る経緯

今回の合同勉強会は、会社からのトップダウンで決まったものではなく、現場のエンジニア同士の繋がりから生まれました。まずは、開催までのプロセスを振り返ります。

1. きっかけは社外イベントへの参加

スタートは、私自身が「Kaigi on Rails 2025」や「TSUDOI by giftee Tech #1」といった社外のイベントへ継続的に参加していたことでした。

普段はフルリモートワークで開発していますが、積極的に外の場へ足を運ぶ中で、他社のエンジニアとの接点が増えていきました。その中で出会ったのが、ココナラの新卒エンジニアの方です。 同世代のエンジニアとして交流するうちに意気投合し、「自分たちの会社を巻き込んで、合同でイベントをやりましょう」という話が持ち上がりました。

2. 個人の繋がりを「公式イベント」へ

今回のイベントは、ディップ株式会社と株式会社ココナラの共同主催という枠組みの中で、私たちClassiも運営・登壇企業として参画させていただく形となりました。 「一緒にやろう」という合意の後は、この大きな枠組みの中にClassiとして正式に参加するための調整フェーズに入りました。

• 企画内容のすり合わせ： ディップ・ココナラ両社ですでに策定されていたテーマ（技術負債）やターゲット設定について共有を受け、Classiとしてどのように参加するか、認識のすり合わせを実施。
• 社内調整： 上長への企画提案、開催承認の取り付け。
• 関係各所への確認： Classiのロゴを使用し、看板を背負って開催するため、PR室（広報）への確認やコンプライアンスチェックなどを実施。

単なる個人の勉強会ではなく、複数社が関わるオフィシャルなイベントとして、必要な手順を一つひとつクリアし、Classiとしての参画を実現しました。

---

当日のセッションと技術負債への向き合い方

このセクションは、社内で誘いを受けて実際に登壇した鳥山（to_lz1）の執筆です。 最初に、当日発表に使った資料をリンクしておきます。

speakerdeck.com

以下、資料の内容とも重複しますが、執筆にあたって考えたことをいくつか記したいと思います。

1. 技術的負債の原義と定義

発表前にまず気づいたのは、「自分は『技術的負債（Technical Debt）』の原義についてあまり知らない」ということでした。

t-wadaさんのブログで国内でも有名になった「負債のメタファー」¹というものがありますが、ここでも「負債」とだけ言われていて「技術的負債」とは必ずしも言われていません。調べてみると「技術的」という形容詞を付けて使い始めたのはまた別の方らしく、こうした経緯は発表に当たって調査をすることで初めて知ったので勉強になりました。

このように定義付けがハッキリしていないのにも関わらず、我々エンジニアは確かに「技術的負債」なるものがあると認識し、この概念について語ることをやめられません。執筆を通し、この言葉に宿るそんな不思議な魔力を感じました。また、発表に当たっては定義が曖昧になって聞き手の理解を損ねてはならないので「本発表における技術的負債の定義」を序盤に説明するように注意を払いました。

2. 借入のポジティブな側面

細かい内容は資料に譲りますが、私は個人のキャリアを通して「頑張りすぎず、かつ作りすぎなかった時にこそ最良の結果が得られた」という経験を複数持っています。

もちろん、困難な技術的課題を解決する腕力とでもいうべき技術力はエンジニアに必須です。しかし、その持てる力を全て注いだコードというのは得てして複雑になりがちです。また、そうしたコードが保守しきれずに腐っていくというシーンも目にしてきました。

それよりも、エンジニアとしての様々な経験から来る「この課題に対してなら、より実装工数の軽いこういう設計があるのでは？」といったアイデアやアーキテクチャの方が、成功を導くことが多かったりするのです。そうしたソリューションはリリースも早く出来ますから、結果としてビジネス的な成果にも繋がりやすくなります。この中で、「今はXXXを実装しない」という判断が効率的に下されていたならば、それは「事業価値を生み出す借り入れ」と呼んでも良いのではないでしょうか。

「技術的負債」にはネガティブな側面も多くあります。しかし、私は今回こうした「負債のポジティブな側面」について実感を伴って理解してもらえると良いな、と思って資料作成と発表に臨みました。

また、こうしたやり方で本当に価値を生み出すためには、いわゆる「要件定義」への食い込みや、社内外との交渉も必要になってきたりします。今回のイベントではいわゆる若手の方も多いと事前に聞いていました。そうした技術力を伸ばしたい盛りのエンジニアには嫌われがちな「要件定義」フェーズですが、逆に「技術力を活かすフィールド」として再解釈してみると面白いんじゃない？という私からの提案として、今回の発表資料をまとめさせて頂きました。

---

運営を通じての気づき・発見

ここからは再び、運営担当の yuu.kun が、イベントを通じて感じた「組織文化」や「技術広報」への気付きについてお話しします。 今回、運営サイドとして参加して強く印象に残ったのは、共催であるディップ株式会社の運営体制と文化 です。

1. 同世代からの刺激と「負けられない」という思い

会場（ディップ株式会社の四谷オフィス）では、私と同世代である20代前半のエンジニアの方々が主体となって、運営を回していました。

印象的だったのは、彼らが単に決められたタスクをこなすだけでなく、どうすれば社内の風土が良くなるか、どうすればイベントが盛り上がるか、彼ら自身も手探りで模索しながら動いている様子が伝わってきたことです。 同じ若手エンジニアとして、組織をより良くしようと奮闘する彼らの姿に、「自分も負けていられない」という強い活力を貰いました。

2. 「技術広報」が根付く文化

運営の方々と話をする中で、ブログの発信頻度の高さや、月に数回のペースでイベントを開催していることなど、組織として「技術情報を発信する」「技術ブランディングする」という文化が深く根付いていることを知りました。

素晴らしい技術を持っていることと、それを外部に認知してもらうことは別の筋肉が必要です。 技術力はもちろんですが、それを届けるための「発信力」や、エンジニアが集まる「場を作る力」。これらもまた、エンジニア組織にとって不可欠な要素であることを、ディップ株式会社の体制から学びました。

おわりに：今後の展望

個人の繋がりから始まった企画でしたが、実際に4社合同という規模で開催できたことは、私自身にとって大きな手応えとなりました。

今回のイベントを一過性のものにせず、得られた知見を社内に還元するとともに、今後も積極的に社外との接点を作り、Classiのエンジニア文化をより外に開かれたものにしていきたいと思います。

---

1. https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor↩

2025年のAIを活用した伴走型エンジニアリングを振り返る

はじめに

背景

普段はエンジニアとして、Classi で提供している学習トレーニング機能の問題を管理するCMSの機能強化などを行っています。それが2025年度からは開発だけでなく「コンテンツチーム」にも兼任という形で所属することになりました。 目的はシンプルで、「コンテンツ制作の現場と連携を強化し、その知見をCMS開発へダイレクトに反映していくこと」です。

趣旨

この記事で伝えたいことは以下の3点です。

• CMSへの「入稿前段階（コンテンツデータ作成）」に関わることで、エンジニアの貢献ポイントが劇的に増えた。
• Vibe Coding（Claude Code等）で「使い捨てスクリプト」を量産し、AI（Gemini等）で「中身」を補完することで、開発・制作双方の工数を圧縮した。
• 「100点を目指さない（AI活用）」×「汎用化を目指さない（ワンショットスクリプト）」という割り切りが、最大の成果を生んだ。

※このエントリーで取り扱っている「コンテンツ」は、Classiの「学習トレーニング」上で生徒さんが取り組む「問題」のことを指しています。さまざまな科目、利用用途に合わせて問題群を充実させていくようにコンテンツチームが中心となって制作をおこなっています。

発見：「入稿」の前にエンジニアの仕事があった

プロダクト共有会のご紹介

プログラマ兼、プロダクト共有会司会の onigra です。本日は、私が所属するプロダクト本部で定期的に開催している「プロダクト共有会」をご紹介します。

プロダクト共有会の様子

プロダクト共有会とは？

プロダクト本部が行った、Classiサービスの機能追加・改善などのリリースについて広く共有する会です。主に、マーケティング本部（セールスマーケティング、カスタマーサポート&サクセス等を行う本部）に向けて開催しています。 ¹

リリース情報の共有は日々行なわれていますが、Classiとtetoruはサービス内に複数の機能が存在し、デプロイも1日に平均して7~10回行われているため、それらを全て、背景や目的を含めて把握することは困難です。

そこで、これらのリリースについて、実際に企画・開発に関わったメンバーから紹介・解説・デモを行い、フィードバックをもらったり、営業活動に活かせる情報を提供することを目的としています。

営業活動に活かす

Classiではマーケティング、セールス、カスタマーサクセスが連携して営業活動を行っています。この体制において、プロダクト本部とマーケティング本部の連携は生命線です。

そのためプロダクト共有会は、単なる機能紹介にとどまらず、プロダクトマーケティングの一環として機能の価値を正しく伝え、営業活動を支援する取り組み（セールスイネーブルメント）にしていきたいと考えています。

機能が解決する課題や開発の意図、活用事例を共有し、日々の提案活動に活かしてもらうことで、プロダクト本部のメンバーも間接的に営業活動に参加し、全社で顧客価値を届けるための場所にしていきたいという狙いがあります。

開発者の声を届けたい

スペックや操作方法だけならドキュメントを読めば分かります。しかし、プロダクト共有会で大切にしたいのは、「なぜこれを作ったのか」や「何に苦労し、どこにこだわったのか」という、生産者の顔が見える情報です。

ストーリーを開発者・企画者自身の言葉で語ってもらうことで、機能は単なる記号から、熱の通ったソリューションへと変わります。その熱量は、営業やCSメンバーを通じて、必ずお客様にも伝播すると信じています。

また、新しくClassiに入社したメンバーはチームでサポートしつつ発表の機会を設け、成果とともにメンバーの紹介を行うことで、成功体験を積むオンボーディングの場としても活用しています。

まとめ

プロダクト共有会は、情報の伝達場所というだけでなく、プロダクト本部とマーケティング本部をつなぎ、組織全体でプロダクトの価値を最大化するためのハブとして運営しています。

今後も、部門の垣根を超えてClassiをより良く、より多くの方に届けるために、楽しく運営していきたいと思います。

おまけ: プロダクト共有会の前身

プロダクト共有会は、Classiの 「申請・提出物/カスタム名簿」機能の開発チームが行っていた「共有会」を前身にしています。

良い取り組みであり、毎回盛り上がっていたため「もっと共有対象を広げよう」ということになり、現在のプロダクト共有会に発展しました。

「申請・提出物/カスタム名簿」開発チームのメンバーにはこの場を借りてお礼を申し上げます。

---

1. 参加者に制限は設けていないので、さまざまな組織のメンバーが参加しています↩