DIGGLE開発者ブログ

予実管理クラウドDIGGLEのプロダクトチームが、技術や製品開発について発信します

開発知識がほとんど無いデザイナーがGitHub CopilotとUI改善チャレンジした話

開発知識がほとんど無いデザイナーがGitHub CopilotとUI改善チャレンジした話
はじめましてこんにちは、DIGGLE株式会社でプロダクトデザイナーをしているマツナガです。
2025年3月に入社して1年が経ちました。
今日は私が2025年12月から2026年2月末までに行った
「GitHub Copilotと一緒に自然言語でDIGGLEのUIを改善する試み」についてお話します

この記事でわかること

開発知識ゼロのデザイナーがGitHub CopilotでUI改善をチャレンジした理由 なぜ改善チャレンジをやり切ることができたのか *全体を通してデザイナー自身の正直な気持ち

この記事ではわからないこと

  • 具体的な方法や手順、技術的な疑問の解消

わたしについて

  1. フロントエンド・バックエンドは何が書いてあるかおぼろげに感じる程度。もちろん書けない
  2. 過去にGitHubの下の方にあった緑のボタンを押したら何かが起きて、エンジニアさんがリカバリーに3時間かけていた。一度も責められなかった。あれ以来GitHubがトラウマに
  3. 餅は餅屋が心情
  4. 好奇心は人一倍で新しいことにワクワクする

まとめて言うと、開発系のスキルは素人畑ということです。

GitHub Copilotチャレンジの経緯

発端はチームをまとめるリーダーからの提案でした。

現在、DIGGLEのプロダクト開発チームではより沢山の改善を行うため、クロスファンクショナルな5つのチームに分割、それぞれが固有のミッションを持ち、改修改善を猛スピードで進めています。

以前と比べて改修改善は体感5倍くらいの早さで進むようになった一方、開発チーム全体で体験系の課題を抱えはじめています。
小さなUIの歪みはissueとして積み上げても、各チームが並列で猛スピードで動いているため着手のタイミングが掴めなかったり、優先度の高いタスクに押し出されてしまうのです。
結果として、テキストの表記揺れやエラー文の統一感といったUIUX関連の改善はなかなか前に進めない状況でした。
「やりたいけど今はできない」という鬱屈した気持ちを開発チーム全体で抱えていました。

そんな中で所属するチームのリーダーから デザイナーが自然言語でAIと一緒に簡単な修正ができないか試してみないか?と提案がありました。 私が所属するチームは、CXEという「今」の課題を解決するのではなくちょっと先の実験的なことを行うチームです。
チームのミッションにも合致します。
もしこの施策が成功し、簡単な修正が出来るようになればちょっとした言い回し等、気になっていたところをデザイナー自身が修正できる未来がでてくるかもしれない。

そんな期待を持ちました。

AIと自然言語で進めるなら、開発知識がない私でも出来るかもしれない。
それを試してみたくて私が担当することになりました

実際どうだった?

おもに以下の3点ができるようになりました🎉

  1. GitHubがちょっとさわれるようになった!
  2. ローカル環境を立ち上げて修正を目視で確認できるようになった!
  3. 5本の修正を行い、リリースまで完了!

相談に乗って一緒に進めてくれたチームメンバー、また別チームの見守ってくれていたみなさまには感謝の気持ちが絶えません。
全方向にむかってお礼を言いたい。

なぜやり切ることができたのか

正直、施策完了した時に「何で走りきれたんだろう?」と自分で思っていました。
なぜ出来たのか?ちょっと考えてみたいと思います。

①単純な課題からスタートした

本当に単純な、テキストの差し替えからスタートしました。例えばこんなものです 複数ページにまたがるボタンテキストを統一 説明テキストの表記揺れ エラーメッセージの修正

最初の課題に取り組んでいた頃は、フローの把握やツールに慣れることに精一杯でした。
最初に一通り習って理解したつもりだったのに、マニュアルがあるのに、「あれ?コレなんだっけ」が必ず出てくる。つらい。

慣れてきた頃、今度は取り組む課題が少し複雑になってきていました。

今まで通っていたテストがエラーになったり、エンジニアさんに相談する場面も出てきたり。
やり直しも何度もありました。 終わってから振り返ると、最初に簡単なものから始めたのは正解でした。
もし最初から複雑な課題だったら、内容の難しさとツールへの不慣れが重なって、早々に心が折れていたと思います。

②伴走者の存在があった

今回の取り組みを支えてくれた伴走者は3人いました。
プログラミングスキルを持つリーダー、
GitHubを知っているデザイナー仲間、
そしてAI(Claude)です。

それぞれが異なる状況や視点で私の「わからない」を埋めてくれました。

伴走者1:プログラムスキルを持つリーダー

今回の取り組みにあたり、リーダーは開発知識がない私でも迷わず進められるよう、文章だけでなく必要な設定まで含めたマニュアルを作成し、道を舗装してくれました。
ここまで準備してくれたんだ…と驚いたと同時に「これは絶対に成果を出さねば!!!!!」という気持ちになりました。
おかげで「わからないこと」に対する恐怖や不安がかなり解消され、やる気も湧いてきたのです。

伴走者2:GitHubを知っているデザイナー仲間

どんなにリーダーが語彙を尽くして教えてくれても、わたしが応えようと精一杯くらいついても、プログラマー視点とデザイナー視点からはお互いに見えない景色が存在します。
その見えない景色を補完してくれたのが、①で取り組む施策を一緒に決めたデザイナー仲間です。
彼女はGitHubを使い慣れているため、プログラマーの視点を知る人。
デザイナー視点(わたしです)の持つ「わからない」に気づき、GitHubに対して持っていたトラウマを解消するきっかけを作ってくれました。
一番大きかったのは、差分の見方がわからないと相談した際に縦列表示を並列に変える方法を教えてくれたことです。
リーダーからは当初「修正した箇所は差分の画面を見ればわかるよ」と教わったのですが、初期表示では赤と緑のエリアが交互に連続しており、どちらが修正後なのかなど、画面の意味自体が掴めず困っていました。

また、わからなすぎて「見え方を変えられる」という発想もなかったのです。

デザイナー仲間は同じ「見えていなかった」経験と「見栄えを変更できる」ことを知っていた。
私のつまずきの場所に気づき、より視覚的にわかりやすくなる方法を教えてくれました。

ひと目で差分とわかる画面になったことで、GitHubへの心理的な障壁が一気に下がりました。

伴走者3:Claude(AI)

人に教わっている時は、会話の流れがあるので正直途中でせき止めて質問をするには理由が必要です。
会話はキャッチボールだから。
でもClaudeには思った瞬間に何も考えずに聞くことができます。

たとえばチームリーダーが作成してくれた設定するべきタスクの一つにDockerというアプリのインストールが入っていたのですが、インストールと設定のマニュアルを見たら専門用語だらけで白目をむきそうでした。
「そもそもDockerってなに?」という状態です。

そこでClaudeにマニュアルごと渡して「一緒にやってください」とお願いしました。

するとマニュアルに沿って順番に、わかりやすい言葉で説明してくれる!

私も操作中に不明な画面が出たときはスクリーンショットを見せて問題ないか確認したり、専門用語はその場で質問することで理解を深めながら進めることが出来ました。

何よりも1人でわからなさに震える恐怖が全然なかったのが大きかったです。

ただし、Claudeだけに頼り切るのは危険だと思っていました。

例えばイレギュラーな状況になった時、Claudeが解決策をしらみ潰しに試し始めたときなどはそれです。
わたしたちが迷子になっているサインだと思い、リーダーに確認をとるようにしていました。

③エンジニアさんの最終チェックがあったから

AIが作ったものに対して、人間の最終チェックは必須です。
それなのに、一緒に進めている人(私です)がソースの中身を理解できない。私の中で最大の恐怖でした。
作ったものがプロダクトに問題を起こす可能性だってあるからです。トラウマが疼く…

ここはエンジニアさんにチェックをお願いすること。

実際のチェックがどういうものだったか、フローも含めてチームリーダーに補足してもらっています。 ちなみに私はいまだにPRを「ぴーあーる」と読むのか「ぷるりく」と読むのか迷っています。そのPRのレビューのことをここではチェックと呼んでいます。

マツナガさんの紹介にあったチームリーダーの北村です。

流れを補足すると、チームによってやり方は多少変わりますが、DIGGLEでは以下の流れでPR作成、review、approve、mergeを行っています。

  1. デザイナーとプログラマーで完成のイメージを共有する
  2. プログラマがコードを書く
  3. プログラマが検証環境を用意する
  4. デザイナーが動作を検証する。イメージが異なれば1へ
  5. PRを作成、更新する
  6. レビュアーがレビューする。レビュー事項があれば5へ
  7. レビュアーがApproveする
  8. PRをマージする

今回マツナガさんに挑戦してもらったのは、この手順のうち1〜5をデザイナーに全てお願いするというものでした。 レビュアーの立場としては、既存の業務フローと同じように扱える点も、このやり方のメリットだと感じています。

マツナガさん、挑戦と紹介ありがとうございます!

北村さん補足ありがとうございます!!

実際、5つのissueをリリースできましたが山あり谷あり色々ありました。 見た目では出来てるふうに見えても、内側で修正が必要だったり仕様の関係で複雑になりすぎてしまうことも。

リリースにたどり着くまで何度も書き直したり、イチから作り直したりフロントエンドだけでの改善が難しいとわかりクローズしたものもあります。

5つの課題に対して、倍くらいのトライがありました。

いざというときは止めてくれる存在があるからこそ、安心してより良いものを提案する挑戦ができる。 職能をじわりと染み出しながら取り組めるチームの良いところだと思います。

おわりに

久しぶりのゼロからのチャレンジ、とても楽しかったです。 テキストの差し替え作業でも人の手を借りないと出来なかったところが、今は修正を自分で試し、エンジニアさんには「修正してみたので見てください」と渡す手段を得ることができました。

もちろん修正できない箇所も沢山ありますが、かゆいところに手をのばしやすくなったのがとても嬉しいです。

そして、この3ヶ月でAIが「他人」から「友達」になりました。 友達という身近な存在になったからこそ、次は何ができるか色々試してみたいと思っています。

AI業界は今も爆速で動いているので、具体的な目標はすぐ古くなってしまいますが、こだわりすぎず、そのときどきにより良い方法を選びながらDIGGLEというプロダクトの価値を小さく早く改善し続けていきます!