この記事は、READYFOR Advent Calendar 2025 の2日目の記事です。
どうも、READYFOR の まっきー（@Pod0_carp_us） です。
普段はプロダクトマネージャー（PdM）として、開発チームとデザイナー、ビジネスサイドのメンバー、そしてユーザーさんの架け橋になるような仕事をしています。
一方でエンジニアリング、特にプログラミングに関する知識はあまり持っていません。
プロダクトマネージャーになってからは9年目くらいなのですが、
そんな私が、今年になって初めて実装し、それを本番環境へリリースする経験をしました！
今回は、その時の話を書きたいと思います。
🧐 背景：LLMの台頭と「簡単だけど優先度が低い」改修
ここ数年で LLM が既存のソースコードを理解して実装できる土壌ができてきました。
社内のエンジニアの環境整備の賜物で、コーディングをできない自分にも改修できるチャンスが生まれました。
一方、社内の課題として「簡単だけど優先度が低い課題」が取り残されてしまうという問題があります。
どうしても目玉となる施策にエンジニアは掛かりきりになりがちで、限りあるリソースでは行き届かない課題が出てきてしまいます。
そこで、できる範囲で自分でやってみよう！と取り組んでみました。
結果、無事に本番リリースまでたどり着く事ができました！
ご紹介するものは、隙間時間でやったものと、社内のハッカソンでやったものです。
完全に「非エンジニア」の私が、どこまでやれるのか。
ぜひご覧ください！
🛠️ 実装したものとその背景
取り組んだのは、以下の5点です。
1. 社内管理画面の入力欄の文字数制限をユーザー側エディタに合わせる 🔢
ユーザー側では50文字まで可能だった
社内管理画面もそれに合わせて50文字まで可能に！
＜背景＞
社内メンバーが編集対応する時に、ユーザー側での入力内容が元々あるとうまくいかず、文字数調整をすることがありました。
＜変更内容＞
社内管理画面で31文字以上打つと自動で切り捨てしていたが、それを51文字以上に変更
＜改善できること＞
社内サポートチームの対応工数軽減
＜所要時間＞
- 工数：3時間程度
- 工期：2日間
※実装時間はほぼなしですが、初回で開発フローを理解するのに時間がかかりました。
2. 社内管理画面の表にカラム追加 📊
社内管理画面の表
＜背景＞
同じような内容が多く識別しづらいときがある表があり、
データを取り違えて社内メンバーが誤編集する事故が起きていました。
＜変更内容＞
社内管理画面の表に、見分けがつきやすいカラムを追加表示
＜改善できること＞
確認・編集対象を取り違えづらくなり、事故のリスク減少
＜所要時間＞
- 工数：1時間程度
- 工期：3日間
3. 社内管理画面のデータ入力時のヒントを追加 📝
データ入力欄
＜背景＞
URLに使われるテキストを入力する欄で、_（アンダースコア）が使われることがありましたが、 SEO 上は-（ハイフン）を利用すべきで、それに気づいてもらいたいということがありました。
＜変更内容＞
入力欄にヒントとして、-（ハイフン）推奨である旨を記載
＜改善できること＞
意図せず SEO で不利になることを避けられるようになった
＜所要時間＞
- 工数：1時間程度
- 工期：1.5週間
※他業務に忙殺されて放置してしまいました。
4. よく使うボタンを押しやすい場所に追加 🚀
ボタンを追加
＜背景＞
よく使うボタンが縦長のページの下の方や、ワンクリック必要な別タブなど、少しアクセス性の悪いところにしかありませんでした。
このため、「ボタンを押すために数秒かけてページを探す」という無駄な時間が発生していました。
＜変更内容＞
ボタンを追加
＜改善できること＞
ボタンを押すための数秒とスイッチングコストをなくした
＜所要時間＞
- 工数：1時間程度
- 工期：半日
※社内ハッカソンイベントの中でガッと集中してやりました！
5. 社内管理画面の会社ロゴ更新 🖼️
| As-is | To-be |
|---|---|
 |
 |
＜背景＞
会社のロゴが社内管理画面の左上にあるのですが、ずっと旧ロゴのままでした。
新ロゴに差し替えること自体は簡単ですが、周辺の空白や背景色について、ブランドデザインのレギュレーションがあります。
単に差し替えるだけでなく、レギュレーションに沿った見た目にする必要がありました。
＜変更内容＞
- 新ロゴに変更
- 背景を白に指定し、周囲に白い余白を追加
＜改善できること＞
- 新入社員や初めて見た人が「何このロゴ？」と思う、余計な認知の負荷がなくなった
- 普通に「恥ずかしくない」社内管理画面になった🫣
＜所要時間＞
- 工数：5時間程度
- 工期：2日間
※社内ハッカソンイベントの中でガッと集中してやりました！
💭 非エンジニアが実装・リリースしてみての感想
本番リリースまでたどり着き無事に社内のちょっとした不便を解消できたのは、
初めての経験でとても興奮しました。
ただ、非エンジニアとして触ってみて、いくつかの気づきがありました。
😭 よかった点： 自分でもできる...！
これまではどんな小さなことでも、エンジニアに依頼しなければ変更できず、
今やってもらう理由付けや、差し込みタスクをした影響の検討などが必要でした。
それが、簡単な実装なら自分でできるようになったので、考えることが減って、エンジニアへの事前相談も不要になるので、業務が効率的になったと感じました。
🤔 ローカル環境構築なしの功罪
手戻りがない場合に、ローカル環境構築なしで実装できたのはとてもラクでした。
以前環境構築を、エンジニアに面倒を見てもらいながらやったこともあったのですが、準備やメンテナンスが大変で、それ以降機能していませんでした😇
しかし、今回は自然言語で Copilot や Claude Code に指示するだけで、カラムの追加やリンクの追加といった実装ができました。
テキスト変更レベルの簡単な実装には、これらのAIアシスタントはかなり向いていると感じました。
しかし、ロゴの差し替えの際、白い余白を入れたことでロゴが左右に長くなり、意図せずレイアウトが崩れてはみ出てしまうという問題が発生しました。
はみ出した状態
この調整のサイクルが、とにかく開発体験が悪いものでした...
- AIに調整を指示し、実装を数分待つ
- できあがったコードを、ステージング環境に10分〜20分くらいかけてデプロイして確認
- 問題があれば、また 1 に戻る
このサイクルを何度も繰り返すことになり、ちょっとした調整でも時間と手間がかかってしまいました。
面倒さの大部分は上記の2番で、反映に時間がかかることなのですが、今のアプリケーションの作りやデプロイワークフローに起因している問題のため、時間がかかった要因は複合的です。
ただ、ロゴ一つとっても、周辺のCSSを理解して、適切な指示を出すスキルがないと、不正解の指示を何往復もすることになり、結果的にスムーズに進まないことを痛感しました。
学んだこととしては、見た目の調整のような何度も指示を与えたいタスクの場合は、ローカル環境構築をしておくことで、LLM を使ってもうまく進めることができると感じたので、ローカル環境構築なしはメリットとデメリット両方ありそうでした。
🧑🎓 開発フローの堅牢性・大変さが身に染みた
今回本番までリリースしたものは開発フローに則って行なっています。
慣れない以下のようなフローも踏みました。
- プルリクエストを作成
- E2Eテストを通す
- ビジュアルリグレッションテスト有無の確認
- レビューをもらう
戸惑った点は以下の通りです。
- プルリクエストを作成
テンプレートはあるものの、どのようなコメントを書けばいいのか（エンジニアはどのようなことを気にするのか）わからず、不安になりながら書きました 😅
- E2E テストを通す
E2E テストは Autify を使っているのですが、特定の開発環境にブランチを反映して、
GitHub のプルリクエストにラベルをつけると、Slack にテスト結果が通知されるというフローが組まれています。
一度わかると便利ですし、最大限自動化してある素晴らしい仕組みなのですが、
慣れない身からすると、最初はどこで何が起きるのかわかりづらく戸惑いました。
- ビジュアルリグレッションテスト有無の確認
社内管理画面のため自動テストが走らない設定だったので結果的には不要だったのですが、
不要なことがわかりづらく、開発フローには記載されているテストが始まらず戸惑ってしまいました。
- レビューをもらう
LLM に実装してもらった内容が本職のエンジニアのお眼鏡にかなうのかとても不安に思いました。
上記のような普段の業務ではやらないことをやり、エンジニアであっても、軽微な改修でも、
適切なログを残すことや、安全を期すため、
労力がかかっているんだなと実感しました。
「単に面倒」というわけではなく、必要な手順があり、いろいろ手間がかかっているんだなあとしみじみ感じた次第です。
⏱️ スイッチングコストがすごい。だからこそハッカソンは有用
これまでは、大きめなタスクの合間に Slack を眺めて気分転換しつつ仕事をするスタイルが身についていたのですが、
LLM との実装になると、さらにそこにもう一つ「 LLM に実装させる」というタスクが挟まってくることになります。
「これをやってる途中にこれをやる途中にこれをやる」みたいな入れ子構造になっていき、集中力がやや落ちているように感じました🤔
今回事例として挙げた 4番, 5番は社内で業務改善を目的としたハッカソンイベント中に実施したもので、メインタスクとして取り組めたのでササっとリリースまで行けましたが、
そうでないとなかなか進みづらいし、首がしまってしまうような印象です。
実際、ハッカソン終盤で取り組み始めて実装中のまま何日も経ってしまっている別の改善もあります。
ハッカソンの有用性も感じますし、
普段のエンジニアの LLM を活用した実装はこうなっているんだと思うと、大変だな・・と感じました😇
ハッカソンの詳細はこちらをチェック！
🎯 今後の展望：簡易な実装であれば積極的に取り組みたい
今回、簡単な実装であれば非エンジニアでも本番リリースまでできることがわかりました。
ただし、以下のような使い分けはあると感じました。
- ✅ 簡易的な実装：積極的に自分もやりたい！
- ❌ 複雑なUI調整や、データロジックに関わる実装：やはり専門のエンジニアの皆さんにお任せすべき
→結果として、非エンジニアが手を出せる範囲はかなり限定的になるという印象です。
ただ、今回のようにテキスト変更や簡単なリンク追加といった簡易的なものであれば、プロダクトマネージャーだけでなく、他部署（カスタマーサポートやカスタマーサクセスなど）にも実装の門戸を開ける可能性があると感じました。
それが、開発チームの負荷軽減にも繋がり、プロダクト全体の改善スピードを上げることになるかもしれません。
私も、今回得た経験を活かして、これからもプロダクト改善に尽力していきたいと思います！
読んでいただきありがとうございました！
明日12月3日のREADYFORアドベントカレンダー2025は toyoc さんの担当です。
ぜひお楽しみに！
補足：実装未経験について
データ基盤の実装は、去年あたりから始めて、これまでやっていました。
しかし、原則SQLを書くだけのデータ基盤の実装と、社内管理画面の実装では、言語や必要となる知識が大きく違い、難易度が個人的に全く異なるので、やはり挑戦的な出来事でした。
なお、データ基盤の実装がどのような様子かは、データアナリストの toshaba さんが以前書いてくださっていました。
リンク集
過去アドベントカレンダーで書いた記事はこちらです
2024
2023
2022
2021
もしREADYFORのPMに興味があるという方はぜひお話ししましょう〜！🙋♀️
日本初クラウドファンディングの「READYFOR」サービスサイトはこちら
READYFOR採用ページ
READYFORのZenn公式ページ
自分のX
自分のnote
「みんなの想いを集め、社会を良くするお金の流れをつくる」READYFORのエンジニアブログです。技術情報を中心に様々なテーマで発信していきます。 ( Zenn: zenn.dev/p/readyfor_blog / Hatena: tech.readyfor.jp/ )
Discussion