初登壇！非エンジニアが気づいたら AIでチームのツール開発を していた件について #devio2026
はじめに
サービス企画部リセールオペレーショングループののんべぇです。
私は普段、AWSアカウントの発行や転入移管などの業務を行うチームに所属していて、エンジニアリングの知識はほぼない非エンジニアです。
そんな私がDevelopersIO 2026 Fukuokaにて社外からの参加者様に向けて初登壇してきました。
本記事では、登壇でお話しした内容をブログとしてまとめます。
結論
非エンジニアでも、AIを使えばツールを作り、自分だけでなくチーム全体の作業効率化に貢献できます。
私がどのようにしてチームのツールを作るようになったのか、その過程と失敗から学んだことをご紹介します。
きっかけは、ごく小さな不便だった
ツールを作りたいと思ったきっかけは、本当に小さなことでした。
私の業務ではJiraというプロジェクト管理ツールを使用していて、チケットの件名とURLをSlackに貼る作業が日常的にたくさんありました。
件名をコピーして貼り、URLをコピーして貼る。
この2回のコピペが毎日、複数回必要で、地味に面倒だなと感じていました。
大きな課題ではないけれど、確実に時間を取られる。Jiraに限らず、似た経験をお持ちの方は多いのではないでしょうか。
この不便を、AIに相談しながら解決してみることにしました。
当時、社内では自社の生成AI環境構築サービスであるAI-Starterの利用が推奨されていました。AIに慣れていなかった私は、まずこの不便を解消できないか、というところからAI利用の一歩を踏み出しました。
「何を、どうやって作るか」からAIに相談し、件名とURLを同時にコピーできるブラウザの拡張機能を作ることに決めました。
こうして完成したのが、1クリックで件名とURLを同時にコピーできるChrome拡張機能です。
チームに配ったら、立ち位置が変わった
このツールは、もともと自分の不便を解消するために作ったものでした。
しかし、自分が不便に感じているのであれば、チームのメンバーも同じように感じているかもしれないと思い、チーム内に共有してみました。
すると予想以上に好評で、思っていた以上に喜ばれました。
自分のために作ったものが、チームメンバーの不便も解消する結果となったのです。ここが私の転機になりました。
その後も、困りごとを見つけてはツールを作っていきました。
すると、いつの間にかチームの中で「ツールを作れる人」という立ち位置になっていました。
今では、自分から効率化を提案することもあれば、「こういうの作れませんか」と依頼されることもあります。
これが、タイトルにある「気づいたら」の実態です。
計画して始めたわけでも、エンジニアになりたいと望んだわけでもありません。小さな不便から生まれたツールをきっかけに、自然と私の業務の幅が広がっていきました。
約2年で24個のツールを作った
現在までに、24個のツールを作りました。
そのうち21個が今も運用中で、約35名が使っています。
作ったのは、お客様への案内メールの自動作成、Jiraの情報を使った連携、定期的な通知やリマインド、案件管理表の自動更新、最初に作ったような補助ツールなどです。どれも派手なものではありませんが、毎日の小さな手間を確実に減らしています。
これらはアカウント管理業務の流れに組み込まれ、日常的に使われています。非エンジニアが作ったものが、仕事の仕組みの一部になっているのです。
また、ツールを作るだけでなく、ツールを作りたいメンバーから相談を受けることもあります。クラスメソッドに入社する前は、これが業務の一環になるとは想像すらしていませんでした。
失敗から学んだこと
ここからは失敗談です。
失敗1：自分の不便しか見ていなかった
起きたこと
最初に作ったJiraコピー機能は、自分が不便だと感じた画面にしか対応していませんでした。チームに使ってもらうと、「別のページでも同じことをしたい」という声が上がりました。
原因
自分の不便にしか目が向いておらず、他の人がどんな場面で使いたいのかを、事前にヒアリングできていませんでした。
対応
リリース後に対応するページを広げ、利用者の要望に応えることができました。改修ももちろんAIを使って行ったため、作業の負担はそれほど大きくありませんでした。
失敗2：ひと月分の事例だけで作った
起きたこと
Jiraのチケット情報から、そのチケットのサブタスクを自動で作成するツールを開発しました。ところが実際に運用してみると、自動で計算されるスケジュールの日付にズレが出ました。
原因
開発の際、ある月の事例だけを見て作ってしまい、複数の月で検証していませんでした。月が変われば日数も曜日も違うのに、複数の月で試すという初歩的なことができていなかったのです。他のパターンを想定した検証が、まったく足りていませんでした。
対応
その後、複数の月で検証して修正しました。
学び：AIに頼む前に、言葉にする
2つの失敗に共通するのは、作る前の整理が足りなかったことです。いわゆる「要件定義」、つまり何をどこまで作るかを決める作業です。
AIは、頼んだとおりに作ってくれます。
裏を返すと、頼み方があいまいなら、あいまいなものができあがります。
そこで今は、AIに頼む前に次の3つを言葉にするようにしています。
- 誰が、何のために、どんな場面で使うか
- 他に考慮することはないか、周りに聞く
- 1つの事例だけでなく、複数のパターンで確かめる
これを先に言葉にしておくと、やり直しが大きく減ります。
エンジニアの方には当たり前のことかもしれません。しかし、非エンジニアの私にはこの意識が決定的に欠けていました。
作ったものは、役目を終えることもある
作ったツールの中には、役目を終えたものもあります。24個のうち3個です。
1個目は、Jiraのデータを拡張機能で取得し、Slackに手動で投稿していたツールです。Jiraのデータを自動で取り出せる仕組みと、Slackに自動で投稿できる仕組みが使えるようになったため、自動投稿に置き換えて別のツールに集約しました。
2個目と3個目は、業務自体がなくなりました。
これは失敗ではなく、成長の一部だと思っています。
また、ツール開発に使うAIの環境も変わりました。
最初に使っていたAI-Starterでは、コードをテキストにまとめて貼り付けていました。今使っているClaude Desktopでは、手元のコードを直接読み込み、反映から変更内容の確認依頼まで、1か所で完結します。
まとめ
非エンジニアでも、AIを使えばツールを作り、チームの作業効率化に貢献できます。
非エンジニアの方こそ、普段の業務の中で、まずは面倒な作業を1つ、AIに相談してみてください。
私のツール開発も、「コピペを1回減らしたい」という、たったそれだけのことから始まりました。
以上が、初登壇でお話しした内容です。最後までお読みいただき、ありがとうございました。
登壇を終えて
初登壇、ガチガチに緊張してしまい色々と失敗もありましたが、とてもいい経験になりました。
印象深かったのは、登壇終了後に参加者の方からいくつか質問をいただけたことです。
その中に「これをきっかけにエンジニアを目指そうと考えたりしましたか？」という質問をいただきました。
私ははっきりと「考えていない」と回答しました（笑）
理由は明確で、エンジニアになることよりも、作業者の目線で不便を解消したいという気持ちが強くあったからです。
今後も私は、作業者だからこその目線でチームの業務効率化に貢献していければと考えています！
