CARTA HOLDINGSサマーインターンTreasure2026参加体験記

2026年8月10日から8月28日までの3週間、CARTA HOLDINGSのサマーインターン「Treasure2026」に参加した。全体は3チームに分かれる形式で、自分たちは4人チーム。今年のテーマは、CARTA社内で実際に行われている「技術力評価会」というイベントの価値を最大化するプロダクトを提供すること(具体的に何を作ったかはここでは伏せておく)。

結果から書くと、私たちのチームはグランプリを獲得できた。ただこの記事で残しておきたいのは、賞そのものより、この3週間で自分の中に「価値を生み出すための考え方」が一本通ったことだ。

[CARTA HOLDINGSのオフィス入り口]

何を学びに来たのか

参加する前、自分の中には3つの目標があった。

「動くもの」ではなく「価値を生むもの」を作れるようになること
設計・技術選定の意思決定力を身につけること
チームで意思決定し、チームを前に進める力を身につけること

それまでの自分は、機能を思いついたら手を動かして実装する、という進め方をすることが多かった。動くものは作れる。でも「なぜこれを作るのか」「これが本当に一番価値のある選択なのか」と聞かれると、裏付けを持って答えられなかった。

正直に言うと、これには苦い元ネタがある。専門学校のサークルで交通費精算アプリを作ったことがあるのだが、結局ちゃんと使われないまま終わった。動くものは作った。でも、それを使う人にとって価値があるかを考えないまま作ってしまった結果だと今なら分かる。この3週間で、その裏付けの作り方そのものを持ち帰りたいと思っていた。

実際にやったこと

3週間はざっくり「体験する週」「設計する週」「作りきる週」に分かれていた。節目ごとに自己評価とチーム評価を100点満点でつける機会があったので、その点数も添えながら振り返る。

1週目:技術力評価会を「体験する」

最初の週は、技術講義を受けながら、自分たちがこれから価値を最大化しようとしている対象そのもの——CARTA社内の「技術力評価会」——を実際に体験するところから始まった。体験した翌日にはそのフィードバックの時間があり、週の中盤にチームキックオフ、ここから4人チームでの旅が始まった。続けてアイデア講義。

いきなり手を動かすのではなく、まず対象を自分の身体で体験させてもらえたのが、後々効いてくる週だった。

[会場となったオフィスビルを見上げたところ]

この週の終わりの自己評価は自分40点、チーム65点。設計(design docとuser journey map)の重要性を頭では理解したものの、実際に手を動かすと本来の目的を見失って考えすぎてしまい、思うように前に進めなかった1週間だった。

2週目:ドメイン理解から設計へ

2週目はアイデア講義から始まり、チームでの検討が本格化する週だった。ここで使ったのが user journey map と design doc だ。

user journey mapは、技術力評価会というドメインを理解するためのフレームワークのようなものとして使った。関わる人たちがどんな場面で何を体験しているのかを可視化することで、自分たちが漠然と想像していた課題と、実際にドメインの中にある課題とのズレに気づけた。
design docは、自分たちのプロダクトのコアバリューを、どんな背景を持つ誰に届けたいのかとセットで明確にし、それをチームの共通認識にするためのものとして使った。

design doc は週の半ば(8/18)が締切で、そのまま発表会があった。その後はチーム開発ガイダンスとAIコーディング講義を受けて実装に着手し、週の最後に中間レビューを迎えた。

この週の自己評価は55点(前週比+15)、チーム70点(+5)。メンバーからの問いかけをきっかけに、自分から人に聞いて思考を整理する動きができ始めた週でもあった。ただ、まだ理解のスピードが足りず、考えを整理しきってから話そうとして、チームに置いていかれる場面もあった。

3週目:作りきって、伝えきる

最終週はひたすらチーム開発。中間レビューを挟みながら手を動かし、週の終盤でコードフリーズと発表資料の締切を迎え、最終発表会で3週間の成果を発表した。発表後は打ち上げで締めくくり。

正直なところ、design doc で固めたコアバリューを実装まで一貫して持ち込めるかどうかは、この最終週の踏ん張りにかかっていたと思う。

[オフィスから見えた東京タワー]

最終的な自己評価は75点(+20)、チーム85点(+15)。3週間を通じて一貫して伸び続けた数字が、そのまま自分の中の変化を裏付けてくれている。

気づき・学び

デザインドックで心が折れかけた1週目から、チームを引き戻す人になった3週目へ

1週目、design docを書いている最中に、自分は本来の目的を見失って「これって他に意図があるんじゃないか」と余計なことまで考え込み、パンクしかけた。今振り返ると滑稽だが、当時は本気で苦しかった。

その苦しさが、3週目には別の形で自分の武器になっていた。開発が進むにつれて、チームが「もっとこれも作りたい」という作りたい衝動(いわゆるロマン)に流されそうになる場面が何度もあった。design docのフェーズで一番苦しんでいた自分が、開発フェーズでは逆にチームをコアバリューへ引き戻す役割を引き受けるようになっていたのだ。機能を足すことより、作らないものを決めることの方がずっと難しい。それを自分の役割として引き受けられたのが、この3週間で一番大きな変化だったと思う。

自己評価で100点から25点減点した理由も、最初は「なんとなくうまくいかなかった」としか言えなかったのが、3週目には「この機能にどんな価値が生まれるのか、今の最優先事項は何かを見落としがちだった」と、自分の言葉で具体的に言えるようになっていた。失敗のパターンに名前をつけられるようになると、同じ失敗を繰り返しにくくなる、という感覚を初めて実感した。

GitHubの使い方が、そのまま「価値を生む設計」の道具になった

チーム開発の中で、issueを小さく分割して1issue1PRで進める、議論の背景や設計判断の理由をissueにログとして残す、というGitHubの運用方法を学んだ。人間の記憶は曖昧だから、後から「なぜあの設計判断をしたのか」を振り返れる場所として使う、という考え方が新鮮だった。

これはdesign docやuser journey mapと同じ思想だと今は思う。その場の思いつきをコードだけに残すのではなく、なぜその選択をしたのかを言語化して残す。これがチームの中で「勘に頼らない意思決定」を積み重ねていくための土台になっていた。

AIに乗っかっているだけの自分に気づいた

学びばかりではなく、素直に凹んだ気づきもある。開発が進むにつれて、自分がAIを軸にして動いていることに気づいた。何かをしたいと思ったら、そこには常にAIが付随している。基礎力は少しずつ上がっている実感はあるものの、Treasureの中で動けている部分の多くはAIとの掛け算によるものだという感覚が強くなっていった。

AIは誰でも使える増幅器で、変わるのは掛けられる側——つまり自分自身の数値——でしかない。だからこそ、残りの期間で何を鍛えるかを自分で選ぶ必要があった。自分が選んだのは、テストとCIの整備だった。派手な新機能ではなく、「AIでコードをぶん回しても壊れないためのガードレール」を自分の役割として選んだ。自分の弱さを気合いで埋めるのではなく、仕組みで埋めにいく、という発想は、そのまま社会人になってからも効くはずだと思っている。

成長するエンジニアの共通点、という言葉

最終盤の面談で、サポートしてくれたメンターから、エンジニアとして成長し続ける人に共通する3つの点を教えてもらった。

フィードバックに素直であること
技術に対して貪欲であること
自分の行動に理由をつけて、選択的に生きること

3週間を振り返ると、自分が数字を伸ばせた場面は、ほぼ全部この3つのどれかに当てはまっていた。ふてくされずにフィードバックを受け止めたこと、わからないことをそのままにせずインプットを増やしたこと、そして「なぜその設計を選んだか」を自分の言葉で説明しようとし続けたこと。この3つは、Treasure2026という環境を離れても、自分の中に置いていける物差しになった。

参加前に掲げた3つの目標との答え合わせ

「価値を生むものを作れるようになる」について: user journey mapでdomainを理解し、design docでペルソナ・背景・課題を洗い出し、そこからコアバリューを定める、という一連のフローを経験したことで、「価値を生む」という抽象的な目標を、具体的な手順として自分の中に落とし込めた。

「設計・技術選定の意思決定力」について: コアバリューを定めるステップを飛ばして、いきなり機能や実装の話に進んでいたのが以前の自分だったと、このフローを経験して初めて自覚した。design docで課題を先に言語化しておくと、機能や技術を選ぶときに「これはコアバリューに効くか」という軸で判断できるようになった。

「チームで意思決定し、前に進める力」について: グランプリを取れたのは、誰か一人の力ではなく、このフローに沿って「なぜこれを作るのか」をチームで何度も検証し直せたからだと思っている。design docという共通のドキュメントがあったことで、意見が割れたときも「コアバリューに立ち返って考えよう」という共通の土台に戻ってこられた。

これから

このフローは、Treasure2026という特殊な環境だけで使えるものではないと感じている。次に何かを設計するときは、思いついた機能に飛びつく前に、まずuser journey mapとdesign docに立ち返り、コアバリューを自分の言葉で説明できるかを確認するところから始めたい。

そしてもう一つ、フィードバックに素直であること、技術に貪欲であること、自分の行動に理由をつけて選択的に生きること。この3つを、Treasureを離れた日常の中でも物差しにしていきたい。

最後に

ここまで読んで、講義の中身やプロダクトの具体的な内容がぼかされていることに気づいた人もいるかもしれない。それは意図的にそうしている。Treasure2026は、自分にとって胸を張って100%おすすめできるインターンだったからこそ、ネタバレをせずに残しておきたいと思った。

ただ、自分たちで作ったプロダクトの名前だけはここに置いておく。

[自分たちが作ったプロダクト「ASHIATO」のロゴ]

ASHIATOという。これが何なのか気になった人は、ぜひ当日サポートしてくれたメンターの方々に聞いてみてほしい。あるいは、自分の目と手で体験しに行ってほしい。

[最終日、修了証書とグランプリの賞状、Treasureのユニフォーム]