ID:56015さん

# Claude Codeを用いた全社横断の生産性向上PJ # プロジェクト概要 社内で生成AIツールをClaude Codeに一本化することになったが、 部署間での普及率にばらつきがあった。 全社での普及率を上げるために、Claude Codeを用いて開発生産性が上がることを示すエバンジェリストとして活動する # チーム体制 各部署からエンジニアが1~2名選出され、 週次で各部署での取り組み、情報共有を行う # 使用技術 * Claude Code * Claude Code Github Actions * Github Actions # 自身の担当業務・目標 * 自チームで「生成AIって確かに生産性あげてくれるよね」という雰囲気を作ること * コーディング以外のユースケースを見つけること # 状況・課題/工夫した取り組み・自身が意思決定したこと/成果 ## ■ 状況： 育休復帰後、所属チームの約半数が新卒〜2年目のジュニアエンジニアに入れ替わっており、 コードレビューやライブラリアップデートに必要な知識レベルに大きな差がある状態でした。 所属企業では Ruby/Rails のバージョンアップをリリース後すぐに取り組む など、 「常に最新版のライブラリを使う」ことを強みとしていたため、その強みが失われていると感じました。 実際に、Findy の PR 指標を見ると、Dependabot（ライブラリアップデート）のPRのマージまでの時間が明確に長く、 生産性のボトルネックとなっていました。 ジュニアメンバーへのヒアリングでも、「何を確認すべきか分からない」「動作確認の方法が分からない」といった共通の課題が見え、レビュー品質・スピード・心理的負担に問題がある状況でした。 私は、自チームの育成と生産性向上に加え、社内 AI 活用推進（AIエバンジェリスト活動）の一環として、この課題の解消に取り組みました。 ## ■ 行動・判断・成果： 課題を①レビュー観点の不統一、②影響範囲把握の難しさ、③動作確認の属人化の3つに整理し、改善優先度を設定しました。 各ライブラリ更新を 影響のある破壊的変更 / 影響のないバグ修正 / 自チームに無関係の変更 の3分類で整理し、 影響度を体系的に評価できるレビュー基盤を設計しました。 この設計をもとにに生成AIに自動でレビューさせ、開発者は生成AIのレポートをレビュー、動作確認手順を行うようにし、 ジュニアでも迷わずレビューできる環境を整備しました。 運用後、Dependabot Pull Requstがマージされるまでの時間が 従来比で 70% 改善。 レビューの心理的負担が減り、ジュニアメンバーも積極的にレビューへ参加できるようになりました。 社内勉強会で登壇し、この取り組みを他プロダクトチームにも共有したところ、 同様の課題を抱えるチームが多く、生成AI導入初期の社内において 好事例として横展開され、 AI活用文化の定着と組織全体の生産性向上に寄与しました。

電子カルテ連携機能の開発 プロジェクト概要 電子カルテ連携機能の開発プロジェクトのリーダーを担当 # チーム体制 * PdM 1名 * フロントエンド 2名 * バックエンド 3名 * ビジネスサイドとの連携 # 使用技術 Ruby on Rails (APIモード) # 自身の担当業務・目標 * サーバーサイドの設計、実装とそのレビュー # 状況・課題/工夫した取り組み・自身が意思決定したこと/成果 ## ■状況: 既にレセコンとの連携機能は一部実装されていたが、連携先を追加するたびに既存コードへ手を入れる必要があり、 デグレのリスクが高く、開発コストも大きかった。 一方で、レセコン連携数の拡大は事業価値（売上）に直結しており、連携先追加のスピード向上が求められていた。 ## ■行動・判断・成果: 既存コードのOpen Closed Principle に反していた箇所を中心に リファクタリングを実施しました。 Rails の “設定より規約” の思想を活かし、レセコン連携処理の 命名規則・責務分割・クラス構造の指針を策定しドキュメント化しました。 その結果として新規レセコン追加時の変更箇所を局所化し、既存コードをほぼ触らずに拡張できる構造へ改善できました。 結果として未対応の電子カルテを使用している顧客の契約から請求開始までの期間を短くすることに貢献しました。

# プロジェクト概要 地理情報を用いて商業施設とテナントをマッチングするサービスの新規開発。 サーバーサイド開発とインフラ運用を担当し、スクラムで開発を推進。 # チーム体制 PdM兼デザイナー 1名 バックエンド 1名 フロントエンド 1名 外部委託のレビュワー 1名 # 自身の担当業務・目標 • DB設計、認証、API設計・実装、テスト作成 • Pythonでの各種指標算出バッチの実装・運用 • クリーンアーキテクチャによるバッチ基盤の再設計 • 要件定義フェーズにおける仮説検証プロセスの構築 # 状況・課題/工夫した取り組み・自身が意思決定したこと/成果 ## 状況 • PMFを狙うフェーズにも関わらず、参画当初は機能過多でユーザー視点が抜けた開発になっていた。 • コンサル部門から引き継いだバッチコードは、保守が困難な状態だった。 ## 行動・判断・成果 • ユーザーヒアリングへ継続的に参加し、仮説ドリブンで要件を精査しました。 具体的には、PdMとともに社内外の要望を must-have / nice-to-have に分類。 「なぜ必要か（WHY）」を必ず議論し、最小実装でリリース → 学習 → 改善のサイクルを確立。 結果として、1スプリントあたりの完了件数が増え、開発スピード向上。 • バッチ処理をクリーンアーキテクチャで再設計し、保守性・拡張性を向上 原典・原著者の資料を読み込み、外部勉強会で理解を深めた上で導入。 アウトプットを柔軟に変更可能な構造を構築。コンサル部門・アプリ部門のコードを横断的に再整理し、車輪の再発明を大幅に削減。