長期インターン1〜4週目は、TypeScript・レンダリングの基礎学習を進め、「Next.jsで何か一つ作ってみる」という課題の中でポートフォリオサイトを作成し、社内ツールで用いる開発案件管理ツールの機能の実装に着手し始めました。
続く5〜8週目は、開発案件管理ツールの開発の中で、条件に合う案件を選びやすくするUXを上げるためのissueを主に担当させていただきました。この記事では、具体的な取り組み内容と工夫・改善したポイント、自己評価を振り返っていきます。
目次
- この期間の全体像
- Week 5–6：自社に合う案件を見つけやすくする機能の実装
- Week 7：操作ログを記録する機能の実装
- Week 8：使う人の判断を助ける機能の実装
- 自分で考えて工夫・改善したポイント
- 自己評価
- さいごに
この期間の全体像
5〜8週目は、大きく分けて次の3つに取り組みました。
①案件一覧を「見やすく・探しやすく」する機能（#8 ページネーションの機能追加、#9 絞り込みの機能追加、#41 並び替えの機能追加） ②アプリ内の操作ログを記録する機能（#36 操作ログと管理者向けログ閲覧ページ） ③案件がマッチではない場合の理由を画面に見せる機能（#35 不適合理由の表示）
①を担当した期間で、「画面 → 入り口 → ロジック → データ → 画面の更新」という流れを、少しずつ具体的なイメージとして持てるようになってきた気がします。
最新mainデータをクローンし、担当issue用にブランチを作成し、Rebase、Pull Requestを出すという一連の流れを実施し、チーム開発の流れを一通り経験できたことは、とても勉強になりました。
| 時期 | Issue | 実装した内容 |
|---|---|---|
| Week 5 | #8 ページネーション | 一覧を件数ごとに分割。件数表示・クリーンなURL。レビュー対応で番号付きページャー化 |
| Week 6 | #9 絞り込み | マッチ/NG・カテゴリ・募集状況で絞り込み。後日1つのパネルに統合 |
| Week 7 | #36 操作ログ・管理者ログ閲覧 | 状態変更の履歴に操作者を記録し、管理者向け閲覧ページを追加 |
| Week 8 | #35 不適合理由の表示 | NG理由を一覧に表示。必須条件と加点要素を分けて評価 |
| Week 8 | #41 並び替え | 受信日時／締切／マッチスコア順。絞り込みは保持しページ番号のみリセット |
Week 5–6：自社に合う案件を見つけやすくする機能の実装
開発案件のマッチングサービスでは、日々案件が更新されていきます。そのため、忙しい中で自社にマッチする案件を一つひとつ丁寧に確認していくことは大変な作業です。開発案件を管理しやすくするツールを作成することにより、条件に合う案件にのみ目を通すことができるようになります。
そのツール開発の第一歩として、「ページで区切る」「条件でしぼり込む」という案件一覧を使いやすくする機能の実装に携わらせていただきました。
上司からは「20件ごとにページで区切ることができる機能（ページネーション）をつける」「URLのクエリパラメータなどで管理し、リロードしても同じページが表示されるようにする」という要件を指示していただきました。要件の指示自体に初めて聞く言葉や概念があったため、勉強になりました。調べて理解しようとする中で、新しいことを知ることができて楽しくもありました。
細かいUIなどについては、上司に確認をとって、イメージをすり合わせて実装することを意識しました。なぜなら、実装をした後に、思っていた要件やUIと異なって作り直しや修正が増えると、お互いの時間や労働力が非効率になってしまうからです。また、少しでも役に立ちたいという気持ちがあるため、期待以上の完成度が高いものを届けたいという気持ちもありました。
また機能実装の中で、使いやすくなるような細かい仕様は、AIと相談しながら取り入れました。例えば、「案件数が1ページ（20件）に満たない場合は、ページ送り自体を出さない」「1ページ目はURLにクエリを付けず /archive のように保つ」といった点です。
最初に出したものはプルリクエスト（PR）の中で「番号付きのページャーにする」「一覧の上部にも件数を表示する」とレビューをしていただきました。「PR → レビュー → 修正する」という流れを、実プロダクトの中で回せた経験も貴重な学びになりました。
「絞り込み機能」では、マッチ/NG・カテゴリ・募集状況といった条件で一覧をしぼれるようにしました。ここで意識したのは、前回学んだ「置き場所を層で分ける」という考え方です。「判定のロジックは lib」「条件を入力する見た目は components」「組み立てる画面は app」というように、既存のプロジェクトの構造に合わせて置き場所を指定しました。
その経験を通して、フロントとロジックを分ける、システム全体を独立した部品（機能単位）に分割して開発するという基本的な開発の考え方を、実践の中で肌感覚として学ぶことができました。
Week 7：操作ログを記録する機能の実装
Week 7では、案件の状況を変更した際に、「いつ・誰が・どの状態へ変えたのか」を記録し、管理者がそれを一覧で見られるページを追加する機能を実装しました。
ここでも置き場所の分担は保っています。記録や読み出しのロジックは lib/emails/ 側に、閲覧ページの見た目は components/ の部品に、「このページは管理者だけが見られる」という権限の定義は lib/auth/permissions.ts に、とそれぞれの持ち場に分担して置きました。
過去のissueで学んだ「見た目でボタンを隠すだけでなく、データを触る手前でもう一度権限を確認する（門番を立てる）」というアイデアを、今回は「管理者だけがログを見られる」という形で活かすことができました。
Week 8：使う人の判断を助ける機能の実装
案件一覧の中の、条件に合わない案件に「必須キーワード未一致」「企業情報条件未達」と理由のラベルをつける機能の実装を行いました。
これまでは合う・合わないの結果だけが出ていて、その判断の中身が見えませんでした。そこで、マッチ判定のロジックを lib/ に切り出してもらい、条件を二種類に分けて扱うようにしました。結果だけでなく理由まで見せることは、使う人が次の判断をするための材料になるため、ユーザー体験の改善を意識した回でした。
#41 並び替えは、この期間の最後に取り組んだIssueです。一覧を「受信日時順（既定）」「締切が近い順」「マッチスコアが高い順」で並べ替えられるようにしました。並び替えのロジックは lib/ に一つ作成し、既存の絞り込みロジックの lib/ と選択肢となる lib/ にコードを追加する構成にしました。「新しく作るより、すでにある構造に馴染ませる」という方針など、AIに提案してもらい、開発する中での考え方を学びました。
どのようなUIやUXにするとツールの使用者は使いやすいかを、AIと相談しながらベストな選択肢を考えて実装し、上司に確認を取ることで、より良いものを届けるということを意識しました。
自分で考えて工夫・改善したポイント
5〜8週目で「自分なりに考えて工夫した／改善した」のは、大きく3点あります。
今の自分にできる形で、プロジェクトに貢献する
「自分の手でコードを書き、コードを説明できるレベルになりたい」——そのために、学び、手を動かしてスキルを磨きたいという想いはありますが、JavaScriptから勉強している段階のため、現在は実現が難しい状態でした。しかし、チームとして、会社の一員としてプロジェクトに貢献したいという気持ちも同時にありました。
実務の開発現場でしか学べない知識や経験もあると考えていますので、このいただいた機会を最大限に活かすためにも、AIを用いながら、構造だけでも理解できるようになろうと考えて取り組むことを工夫しました。あわせて、現在の時点でも考えることができる「ツールの使用者がより使いやすくなる仕様のアイデア」を主体的に伝えることも意識した点です。
実装はAIにしてもらい、後からJavaScript、TypeScript、React、Next.js、仕様・要件視点での考え方を、AIに解説してもらいながら理解していくという方針で取り組んでいました。
実装の手前と後ろは、自分の責任でやる
実装はAIに頼っていた分、手前と後ろの工程は自分の責任で丁寧にやろうと決めていました。コードの品質を担保するために、着手前に仕様を読んで「この機能は何を満たせばよいのか」を確認し、細かい判断が要る部分はAIと相談しながら詰め、迷う点は上司にも確認したうえで手を動かしました。実装後もできる限り、仕様を理解するようにも努めました。
自身の担当issueをチームが安心して受け取れる状態で渡せるように、PRもできる限り丁寧に作成するようにしました。テスト後、レビューする方も視覚的に確認できるように、スクリーンショットを必ず入れるようにしました。また、要件・仕様についての確認を細かく行うことで、自身が進もうとしている方向性が合っているかどうかを調節しながら進めることを意識しました。
AIに任せきりにしないための、自分の物差しを持つ
実装の前後を着実にするために、アーキテクト思考やAIコードレビューについて学びました。アーキテクト思考を学んだことで、ロジックは画面から切り離す、判定などのロジックは lib/、見た目の部品は components/、画面の組み立ては app/、データはDBに、というように、issueに取り組む中で理解の解像度が上がりました。
また、AIコードレビューでは「周りのコードと書き方が揃っているか」「既存の関数を使いまわしているか」「関数の名前は意味がわかる名前か」「1つの関数/ファイルが1つの機能に集中しているか」「エッジケースを扱っているか」「TypeScriptの型が通っているか」など、AIのコードをレビューする際のポイントを実際に活かすことができました。既存のコードと馴染ませることをAIに指示することもできました。自身の手で開発をする際にも、既存のコードと馴染んでいるかやエッジケースをケアできるかなどを、意識していきたいと考えています。
自己評価
この期間の自分を振り返ると、機能の実装そのものは、ほとんどをAIエージェントに頼って進めました。「こういう機能を、この場所に作りたい」と伝えて、出てきたコードを動かし、確かめて、レビューに出す—そういう関わり方が中心です。複数の機能をレビューまで通せたのは事実ですが、コードを自分の力でどこまで書けたかというと、まだこれからだと思っています。
その中でも自分の手でやったと言えるのは、コードの周りの部分です。着手前に仕様を確認し、迷ったところは上司やAIに相談する。実装したら、正常な操作だけでなく、空・0件・解除後などの動きを確かめてから出す。Pull Requestには何をなぜ変えたかを書いてレビューを依頼する。派手ではありませんが、「チームに安心して渡せる状態にする」ところは、自分の役割として続けられたと思います。
一方で、これからの課題ははっきりしています。ReactやNext.jsが内部でどう動くのか、コードの細部を自分の言葉で説明できるところまでは、まだ届いていません。「このコードはどの層に置くべきか」を自分で判断したり、エッジケースを先回りして拾ったりする力も、いまはまだAIやレビューに支えられている段階です。前回「コードの細部の理解はこれからの課題」と書きましたが、その課題は今も同じ場所に残っています。
だからこそ次は、AIに頼る割合を少しずつ下げて、小さな部分でも「自分で考えて書く」ところを増やしていきたいと思っています。土台になるTypeScriptとReact・Next.jsの理解を進めながら、いつか自身の手でコードを書けるレベルまで地力をつけられるように、地道に学習をしながらスキルを磨いていきたいと思います。
さいごに
チーム開発未経験の2ヶ月前から様々なことを学ばせていただき、成長を実感できました。GitHubの仕組みや使い方から調べていた2ヶ月前がずっと昔に感じられますが、この2ヶ月があっという間のような気もしています。濃い経験をさせてくださった代表や、現場で様々なことを教えていただいた上司に感謝しています。
エンジニア見習いとして、1日を大切にして、貪欲に日々学び積み上げていきたいと思うとともに、それを充実したものに、そして楽しいものに思わせてくださるQuinQueは、とても素晴らしい環境であると感じています。
様々なプログラミング言語、システム開発、DXなど磨いていきたい道は多く、歩き始めたばかりですが、一歩ずつ地道に積み上げていきたいと思っています。
改めて、矢部代表や江頭さん、山本さん、共にインターンに参加した福島さん、本当にありがとうございました。
