はじめに
今年は変化した一年だったなぁ。一番の変化というと個人の課題からチームの課題へと視座感が変わったところで、それまでは個人のスキルアップが目標のほとんどだったけど、チーム状況の変化を目の当たりにして今のままだとダメだなと感じ、チームの課題を自分の課題と思って取り組めるようになったのが大きな変化だった。
それによって主体的に動き・提案したり既存フローを変えたりして、これまでマネージャー層が現場の意見を聞きながら少しずつ調整かけていたものを現場の目線でいい感じに変えられるようになったし、実際手応えも感じることができた（あとは、変化したやり方がまだ浸透しきっていない感じはするので、文化として当たり前の状況にしていけるといいのだけれど）
これは2025年末に、私がSlackに残したつぶやきです。
カケハシでAI在庫管理プロダクトの開発に携わっている清水（@_smzst）と申します。この記事では、この1年間で私の中に起きた「視座の変化」が何をきっかけに生まれ、具体的にどんな行動につながったのかを振り返ります。
転機 ―― 「なんとかしてくれる誰か」がいなくなった
正直に言うと、以前の私はチームの課題に対してどこか他人事でした。チーム運営上の課題はマネージャーがなんとかしてくれるだろう。技術的・ドメイン的に難易度の高い仕事はテックリードがなんとかしてくれるだろう。私の役割は担当する機能をきっちり仕上げること。それ以上は誰かの仕事だと心のどこかで思っている節がありました。
その前提が崩れたのはチーム体制の変化がきっかけです。テックリードやそれに類するクラスのメンバーが別プロジェクトに異動したのです。つまり、私が「なんとかしてくれるだろう」と頼りにしていた人たちがいなくなったということです。
これまで有識者に任せていたシステムの知見を残ったメンバーで引き継いでいく必要がある。運用を自動化して少ない人員でも業務が回せるようにする必要もある。「このままじゃダメだ、なんとかしないと」――そう思ったとき、チームの課題が初めて自分ごとになりました。
ここで踏ん張れなければエンジニアとしての自分はどこに行っても変わらない。誰かが解決してくれるのを待つのではなく自分から動かなければ状況は変わらない。ここからは、そうした思いから具体的に取り組んだことを紹介します。
レポート機能のテンプレート化（2025年4月）
以前の私なら自身の担当する機能をきっちり仕上げることに注力していたでしょう。でも視座が変わってからは、次の人が同じ苦労をしない仕組みを作ることを優先するようになりました。その最たる例がレポート機能のテンプレート化です。
コピペ開発の何が問題だったか
AI在庫管理の本部管理機能にはいくつかのレポート画面があり、UIの大部分は共通しています。しかし当時は、新しいレポート画面を作るたびに既存のコードを丸ごとコピーし、異なる部分だけを修正するという方法で実装していました。
一見すると手っ取り早い方法ですが、以下の問題を抱えているのは明白です。
- バグの連鎖: コピー元にバグがあるとすべてのコピー先に同じバグが存在する。修正するときも漏れなく直さなければならない
- 変更コストの増大: 共通部分のデザインや振る舞いを変えたいとき、全レポートに手を入れる必要がある
- 認知負荷の高さ: そもそもどこが違うのかを理解するためにコード全体を読む必要があり新規メンバーが手を出しにくい
UIの抽象化とビジネスロジックの分離
そこで、共通部分をテンプレートとして切り出すリファクタリングを行いました。
具体的には、以下の3つの方針で進めました。
- UIコンポーネントの共通化: レポート履歴一覧のテーブル、セル、カラム定義などを、各ページの中に直接書かれていた状態から
features/downloadReport/配下の共通コンポーネントとして抽出しました。このコンポーネントはreportTypeを受け取るだけで動作します - hooksの汎用化: レポート種別ごとに個別に存在していたGraphQLクエリやデータ変換ロジックを、
reportTypeパラメータで切り替える単一のhookに統合しました - ページ側はパーツを渡すだけ: テンプレートに
reportTypeと、そのレポート固有のパーツ（日付選択コンポーネントやレポート作成用hookなど）を渡すだけで画面が完成する設計にしました
つまり、同じところは共通コンポーネントとして再利用し異なるところだけを外から渡せるようにした、という設計です。
実装工数が半日から1時間に
このテンプレート化により、新規レポート画面の実装工数は大きく変わりました。
| フェーズ | 工数 | 内訳 |
|---|---|---|
| 共通化前 | 半日 | 既存コードをコピペして実装・テスト |
| 共通化＋生成AI | 1時間 | テンプレート利用 + 生成AIにテストを書かせた場合 |
最終的にこのテンプレートは6つのレポート機能に適用されました。
そして何より印象的だったのは、私が風邪を引いて数日休んでいた間にバックエンドメンバーだけで新規レポートの実装を完遂してくれたことです。フロントエンド専任のメンバーがいなくても開発を進められる。テンプレート化によって属人性を排除できていることが図らずも実証されました。
リリースプロセスのショートカット版導入（2025年12月）
チームのリソースが限られる中でもう1つ気になっていたことがありました。リリースの手続きコストです。
安全性とコストのジレンマ
AI在庫管理では、機能をリリースする際にリリースドキュメントというものを作成し、仕様やリスクを網羅的に確認するプロセスがあります。顧客に影響のある変更に対してはこのプロセスは必要不可欠です。
しかし、ライブラリアップデートやリファクタリングといった顧客影響の比較的少ないと考えられる内部変更でもフルセットのドキュメントが求められていました。リリース物の規模に対して手続きコストが見合っていないのです。一方で、何も証跡を残さずにリリースするのはリスクが高い。障害が起きたときに、どこまで確認して何を根拠に大丈夫と判断したのかを後から辿れなくなります。
以前の私なら、これはマネージャーなどプロセスを決める人の仕事だと思っていたでしょう。でも人が減った今、この非効率を放置する余裕はありません。自ら提案書を書くことにしました。
リスクに応じた3段階のプロセス
策定したのは変更のリスクに応じてリリース手続きの粒度を変える3段階のワークフローです。
| 区分 | 対象 | 必要な対応 |
|---|---|---|
| 通常版 | 機能追加・変更（ダークローンチ含む） | リリースドキュメントの作成とレビュー |
| ショートカット版（新設） | リファクタリング、Major/Minor更新 | Slackワークフローで4観点（概要・影響範囲・リスク・確認事項）を記載 |
| スキップ | Tidy、テストコード修正、Patch更新 | PR上での確認のみ |
ポイントは、リスクに応じて手続きの粒度を変えるという設計思想です。ショートカット版でも影響範囲とリスクの判断根拠は証跡として残ります。安全性を担保しつつ少人数でもリリースサイクルを維持できる仕組みを目指しました。
この提案書をまとめてチームに共有した結果、導入が決定。リリース手続きにかかる時間は30分から3分に短縮されました。
譲渡対応のLambda自動化（2025年11〜12月）
有識者の異動に伴い、手作業で行われていた運用の自動化にも取り組みました。
薬局の統廃合に伴い定期的に発生する手続きがありました。頻度は2〜3ヶ月に1回程度、1回あたり15分ほどの作業ですが、早朝や土日の稼働を余儀なくされるという負担がありました。
この課題に対して、私がまずやったのはチームで課題意識を揃えることでした。レーン内で負荷の高い運用について議論する場を企画・先導し、譲渡対応や解約対応などの自動化優先度をチームで決めました。
温度感が揃った上で、まずは自分一人から動き始めました。Lambda化の実装、テスト計画書の作成、リリースまでを旗振りしました。DevinやClaude Codeをフル活用し、既存の運用ドキュメントをもとにコアロジックを生成。レビューで指摘を受けながらリファクタリングを重ね、事前条件チェックやダミーコードの動的割り当てなど、安全かつ効率的に運用できる形に仕上げました。
結果として手作業で行っていた処理はLambdaの手動トリガーに置き換わりました。提案から実装・リリースまでを一人で主導して完遂できたことは、今後の運用自動化のモデルケースにもなったと思います。将来的には社内の管理コンソール画面からビジネスサイドでも実行できるようにしたり、スケジュール実行で自動化するところまで持っていきたいと考えています。
DeepDive会によるシステム知見の獲得（2025年12月）
有識者の異動によってもう1つ顕在化した課題がありました。特定の領域の知見が一部のメンバーに閉じておりチーム全体で活用できていないという問題です。
その一例が医薬品マスタ取り込み処理のローカルシミュレーターでした。このシミュレーターを使えば運用時のトラブルシュートや事前検証が格段に容易になるにもかかわらず、動かし方を知っている人がほとんどいない状態でした。
チームでは2025年8月からDeepDive会という取り組みを続けており、各メンバーが自分の詳しい領域や調査した内容を発表・共有しています。私はこの場でこの処理フローとシミュレーターの使い方について取り上げました。
共有の効果はすぐに表れました。2026年4月の薬価改定に向けた準備で、意図した薬価に正しく反映されるかを事前に検証する必要がありますが、このシミュレーターが大いに活躍しています。これなしでは薬価改定を乗り切ることは難しいでしょう。
AI/LLMツールのチーム基盤整備（2026年1月〜）
AIツールをチームの開発基盤として整備する取り組みも行いました。Claude Codeのプラグインとして、リポジトリのPRテンプレートを自動検出しコード差分からPR descriptionを生成するツールや、Gitの変更差分からテストファイルを検出して自動実行するツールを開発し、チームの共有ツールとして提供しています。
特にPR description自動生成ツールはレビューの質に直結する効果がありました。PRのdescriptionが十分に書かれていないケースでは、レビュアーがコードの変更意図を推測しながら読む必要がありました。このツールを使うことで文脈を知らないレビュアーでも何をやったのかが分かるdescriptionが自動で生成されるようになり、レビューの効率が上がりました。
最初は特定リポジトリのカスタムコマンドとして作ったのですが、メンバーから「プラグインとして管理するといいよ」とアドバイスをもらい、さらにそのメンバーが実際に手を動かしてプラグインへの変換まで行ってくれました。私もそれに倣って別のツールをプラグイン化したところ、今度はプラグインの構成についてアドバイスをもらい、改善した結果ツールの動作速度も向上しました。
自分が始めた取り組みにチームが主体的に加わり、一緒に改善していく。こうした循環が自然に生まれたのは嬉しい変化でした。
やってみて分かったこと
この1年間で視座が変わり、それに伴って行動を変えてきました。その過程で得た気付きを3つ書き残しておきます。
一人で抱えない、でも一人で始める
Lambda自動化では、提案から実装・テスト計画書・リリースまでを一人で旗振りしました。意思決定や機動力の面では一人で動くのは速いのですが、モチベーションの波に煽られてなかなか手が進まない時期もありました。
一方で、先にチームの温度感を合わせていたおかげで、テスト計画書の内容について相談を持ちかけたときにはスムーズに助けを得ることができました。共通認識があったからです。
この経験から感じたのは、課題に気づいたらまずチームに共有して温度感を合わせておくこと、そして自分一人からでも動き始めることの大切さです。そして、できればペアなど2人以上で進めるのがよいと思います。一人の身軽さはあるもののペアで取り組んでいればモチベーションが落ちたときにも前に進めたのではないかと思います。
マネージャーを待つのではなく、現場から変える
リリースプロセスの改善では、既存の重厚なプロセスに対して「本当にこのコストが必要か？」と問い直しました。
以前の私だったら、これはマネージャー層が現場の意見を聞きながら少しずつ調整していくものだと思い、1on1で課題感を伝えるだけで改善されるのを待っていたでしょう。でも人が減った今、待っている余裕はありませんでした。自分一人でも提案書を書いてチームに共有して一緒に考えてもらう。周りを巻き込んで変えていく。
実際に提案書を書いてチームに共有してみると意外なほどスムーズに受け入れられました。現場で感じている非効率は、言語化して提案すれば変えられる。誰かが変えてくれるのを待つのではなく自分で提案して巻き込むことで、プロセスは現場から変えられるのだと実感しました。
専門外にも踏み込む
DeepDive会では自分が詳しくない医薬品マスタ取り込み処理のシミュレーターについて調査しチームに共有しました。
実際に踏み込んでみると、調査の過程で自分自身の理解も深まり、共有した知見が薬価改定の準備で実際に役立ちました。専門外だからといって避けるのではなく、まず自分で調べて相手に伝わるように咀嚼してみる。その一歩がチーム全体の対応力を底上げすることにつながると実感しました。
おわりに
この1年間でチーム全体にも変化がありました。自分たちでシステムの面倒を見るために何が必要かを考え、自分たちのために頑張ろうとする姿勢が芽生えてきています。もちろんまだ道半ばです。変化したやり方がすべて浸透しているわけではなく、文化として当たり前の状態にしていくことがこれからのテーマです。
振り返ると、以前の私は暗黙的に誰かがやるだろうと思っていたのだと思います。自分の担当範囲の外側に無意識のうちに線を引いていました。その線を少しだけ外に広げてみたら思いがけない手応えが返ってきました。自分の取り組みにメンバーが加わって一緒に改善してくれたり、共有した知見がチームの武器になったり。最初はやるしかないと思って踏み出した一歩でしたが振り返ってみるとやってよかったと素直に思える一歩でした。そして、この記事が誰かの「誰かがやるだろう」を「自分がやってみよう」に変えるきっかけになれば幸いです。
