前回の記事では、QuinQueの長期インターン最初の2週間として、開発環境の構築から用語の学習、相互レビュー、そしてポートフォリオサイトの制作までを振り返りました。続く3〜4週目は、作ったものの理解をさらに深めつつ、いよいよ配属プロジェクトである開発案件管理ツールの開発そのものに踏み出した2週間でした。この記事では、その期間に取り組んだことと、そこから学んだことを振り返ります。
この2週間の全体像
3〜4週目は、大きく分けて次のような流れで進みました。
- ポートフォリオサイトを本番に出せる状態に調整し、コードを隅々まで理解する
- リサーチ学習の相互レビューMTG — 書いて伝えることと、話して伝えること
- TypeScript・レンダリングの基礎を学ぶ
- 開発案件管理ツールの開発に着手し、最初のIssueをレビューまで出す
「学ぶ・理解する」が中心だった前半から、「実際のプロダクトに手を入れる」側へ、少しずつ重心が移っていった2週間でした。
Week 3：ポートフォリオの本番調整とコード理解（6/1–6/5）
3週目は、前週に形にしたポートフォリオサイトを本番に出せる状態へ調整しつつ、コードの一つひとつが何をしているのかを自分の言葉で説明できるように読み解いていこうとしました。正直、コード理解に関しては、ReactやNext.js観点からはわからず、TypeScriptからAIに解説書を作ってもらい勉強していきました。
具体的には、page.tsx や各セクションのコンポーネントを順に追い、TypeScriptの型定義（経歴やスキルを表す type など）、配列でデータと表示を分けて map() で繰り返し描画する書き方、そしてレンダリング戦略を確認していきました。特に整理できてよかったのが、このサイトは基本的にSSG（あらかじめ静的に生成）で表示を軽く保ち、入力やクリックなど動きが必要なHeaderとお問い合わせフォームだけを "use client" でクライアント側に分けている、という設計の考え方です。前週に「使い分けがある」と知った段階から、「どのセクションがどちらで動いているか」を一つずつ確かめる段階に進めました。
あわせて、コードの各所が何をしているのかを説明する解説ドキュメントも整えました。
やってみて感じたのは、「動くもの」と「説明できるもの」の間には、もう一段の距離があるということです。AIエージェントに頼れば動くものは作れますが、「なぜこの構成なのか」を追っていくと、分かったつもりで素通りしていた箇所が次々に出てきました。その一つひとつを潰していく作業が、3週目の中心でした。
Week 4：リサーチ学習の相互レビューMTGと、開発案件管理ツール開発への着手（6/8–6/12）
4週目は、学んだことを人に伝える場と、いよいよ実プロダクトに触れる体験が重なった週でした。
リサーチ学習の相互レビューMTG
Next.js・Vercel・Supabase・リポジトリ・CIについて調べたリサーチ学習を、インターンのメンターの方の同席の中で、もう1人のインターン参加者とMTG形式でレビューし合いました。
2週目にも相互レビューはしましたが、あのときは互いの調べたまとめを文章で書いてまとめる形でした。今回は、その内容を口頭で説明し合う場です。そこで強く実感したのが、書いて伝えることと、話して伝えることの難しさの差でした。文章なら時間をかけて構造を整えられますが、口頭ではその場で順序立てて話す必要があり、頭では分かっているはずのことが、うまく言葉にならない場面が何度もありました。書ける状態と話せる状態は別のスキルなのだと、身をもって感じました。同時に、相手の説明の組み立て方から学ぶことも多く、同じテーマでも伝え方の引き出しは人によって違うと改めて思いました。
TypeScript・レンダリングの基礎学習
並行して、TypeScriptの「型」やNext.jsのレンダリングといった、開発の土台になる考え方の基礎用語・概念を学習しました。まだ基礎を押さえている段階ですが、ポートフォリオの実際のコードと結びつけて学べたことで、「教科書の用語」が「自分の書いたコードの中の動き」として少しずつつながってきました。
Issue #7：案件の「手動アーカイブ・解除」を実装する
そして4週目の後半、いよいよ配属プロジェクト本体である開発案件管理ツールの開発に着手しました。担当したのは Issue #7「案件の手動アーカイブ・解除」です。IT開発のビジネスマッチングプラットフォームから届く案件は数が多く、対応が終わったものや見送るものを一覧に残したままだと、本当に見るべき案件が埋もれてしまいます。そこで、案件詳細画面からワンクリックで手動でアーカイブし、必要なら手動で解除して通常の一覧に戻せるようにする、という機能です。
一見すると「ボタンを押したらデータベースの値を一つ書き換えるだけ」に見えました。実際、最初はそのくらいの感覚で考えていました。ところが手を動かすほど、「画面のボタン」から「データの書き換え」までの間に、思っていたよりたくさんの段差があることが見えてきました。今回はその段差を一つずつ確かめながら、5つのファイルにまたがって実装しました。
ボタンそのものは、案件詳細のツールバーに置きました。今アーカイブ済みかどうかで表示を「アーカイブする／アーカイブを解除」と切り替える、いわゆるトグルです。ここで前週に学んだ「サーバーコンポーネントとクライアントコンポーネントの使い分け」が、初めて自分の判断として効いてきました。クリックという動きが必要なツールバーだけをクライアント側に置き、それ以外の画面は極力サーバー側のまま保つ—概念として理解したことを、今回は設計の理由として使えた、という手応えがありました。
ボタンを押したあとの処理は Server Action として書きました。これは「画面（クライアント）から呼び出すと、実際の処理はサーバー側で安全に動く」仕組みです。ここで一番なるほどと思ったのは、ボタンを表示しているかどうかと、実際に処理してよいかどうかは別物として扱う、という考え方でした。画面側で権限のない人にボタンを隠していても、サーバー側でもう一度「この人はアーカイブしてよい権限を持っているか」を確認する。表側の見た目だけで安心せず、データを触る一番手前でもう一度門番を立てる、という発想です。実際に emails.archive という権限を新しく定義し、どの役割（ロール）に許可するかを決めるところまでが、一つの機能の中に含まれていました。
そして一番学びが大きかったのが、データベースを書き換える部分です。「archived_at という日時の列を、アーカイブなら現在時刻に、解除なら空にする」だけなのですが、ここを丁寧に書こうとすると考えることがいくつも出てきました。たとえば、すでにアーカイブ済みの案件にもう一度アーカイブ操作が来たらどうするか。今回は「状態が変わらないなら何もしない」ようにして、二重に処理が走らないようにしました。また、二人が同時に同じ案件を操作する状況を想定して、処理中はその行に鍵をかけ（行ロック）、一連の書き換えを途中で破綻させない「トランザクション」という単位でまとめて実行する、ということも実装しました。さらに、「いつ・どの状態から・どの状態へ・なぜ変わったか」を履歴として残す処理も加えました。あとから「この案件はなぜアーカイブされているのか」を追えるようにしておく、という考え方です。
最後に、アーカイブした案件を一覧から消し、アーカイブ一覧に出すために、関係する画面のキャッシュを更新（再検証）する処理も入れました。「データを書き換えたら、それを映す画面も更新する必要がある」という、当たり前のようでいて、抜けがちな一手です。
実装できたらPull Requestを出して、メンターにレビューをリクエストする—1〜2週目に「作法」として学んだ一連の流れを、初めて実プロダクトのIssueで一周できました。この Issue を通して一番強く感じたのは、「一つの機能は、一つのファイルでは完結しない」ということでした。画面のボタン・呼び出しの入り口・権限の確認・データの書き換え・履歴の記録・画面の更新と、役割の違う部品が連なって初めて一つの「アーカイブする」が動く。2週目に「用語は単独ではなく関係で理解すると腑に落ちる」と書きましたが、実装でもまったく同じで、機能もまた部品同士の関係の中で成り立っているのだと実感しました。
この2週間で学んだこと
書いて伝えることと、話して伝えることは、別のスキル
相互レビューMTGで一番痛感した点です。文章は整えられても、口頭ではその場で構造立てて話さなければなりません。理解しているつもりでも、説明できなければ理解は半分だと感じました。
「動く」と「説明できる」の間には、もう一段の距離がある
ポートフォリオのコードを読み解く中で、動かせること自体と、なぜそう書くのかを説明できることは別だと分かりました。その距離を縮める作業こそが、理解を深めるということだと思います。
学習用の制作と、実プロダクトの開発は手触りが違う
一人でゼロから作る制作と、チームで動いている既存コードに変更を加える開発は、別の難しさがありました。まず存在するものを読み解いてから加わる—この順番が、実プロダクトでは欠かせないと実感しました。
小さなIssueでも、レビューまで通すと開発の一周が見える
Issue #7の実装からPull Request、レビューリクエストまでを通したことで、ばらばらに学んでいた作法が一本の流れとしてつながりました。
さいごに
この2週間で、学習が中心だった日々から、実際のプロダクトに変更を加える側へ、一歩踏み出すことができました。ポートフォリオで「自分の言葉で説明できる状態にする」練習をしました。今回のコードでも仕様やコードなどAIに解説書を作ってもらい振り返りました。仕様上の工夫や必要な機能など本質的なことは学べました。コードの細部の理解はこれからの課題です。だからこそ、土台のTypeScriptから着実に進めていきます。
ここからは、開発案件管理ツールの開発を本格的に進めていきます。最初のIssueをレビューに出せたことは小さな一歩ですが、学んできた環境・ワークフロー・用語が、実際のプロダクトの中で初めて一つにつながった手応えのある2週間でした。次のIssueへ、引き続き取り組んでいきます。
