この記事について

2026年8月、3週間のインターン「Treasure」に参加してきました。
グランプリをいただくことはできませんでしたが、チーム開発における役割や自分自身の課題感が見えた3週間になったと思います。
せっかくなので忘れないうちにそのとき考えていたことを残そうと思います。

インターン概要

• 企業：CARTA HOLDINGS
• インターン名：Treasure
• 期間：3週間
• 内容：講義＋チーム開発

  

参加前に感じていた自分の課題

応募した時点で、自分には課題が2つあると感じていました。

1つ目は、バックエンドの経験がないこと。過去の開発ではバックエンドは他のメンバーに開発を任せるか既存のサービスを使用するかで、中で何が起きているかを把握できていませんでした。

2つ目は、チーム開発における言語化能力について。過去のチーム開発で漠然と疑問に思ってもうまく質問できず、そのままモヤモヤしたまま進んでいってしまうことが何度かありました。これに対して、言語化能力が低いのが課題であると捉えていました。

この2つの解決策を見つけにいきたいと思い、参加しました。

課題1つ目）講義パート

扱われたテーマは、フロントエンド（React）・バックエンド（Hono）でした。技術以外に、CARTAのエンジニア組織としての考え方やチーム開発をする上でのスタンスに関する講義もありました。

技術的に一番印象に残っているのは、Honoを使ったバックエンドの講義です。
細部まで理解できたとは言えませんが、バックエンドで何が起きているかを想像できるようになりました。また、今まで用語がこんがらがっていた部分についても調べ直すきっかけにもなりました。地味ではありますが、自分にとっては嬉しい変化でした。

チーム開発

チーム構成はメンバー3人＋メンターさん3人で、お題は「技術力評価会を技術で改善する」というものでした。

実装よりも何よりも、作るものを決めるフェーズがもうとにかく圧倒的にキツかったです。
きつかった理由としては、テーマが「自分にとっての課題」ではなかったことだろうと思っています。

技術力評価会は、自分にとってこう改善したいという課題は特に見つからなかった。なんなら話を聞けば聞くほど、年々改善されていっていて1学生1部外者が口出しできるような完成度のものはなかった。

そのため最初のうちは、課題を解くべき問題としてではなく、与えられたお題という解像度で捉えており、どんな問題が発生しているか・どんな状態だったら嬉しいのかが分かりませんでした。ここをどう詰めるかが、3週間を通して一番難しかったです（ここは長くなるので省きます）。

課題2つ目) 必要なのは言語化ではなく信頼することだったということ

参加前、自分は「言語化ができないから質問が苦手なのだ」と思っていました。ですが3週間終えてみて、言語化のせいではなく、メンバーを信頼して質問する勇気が足りていなかっただけだったと分かりました。

チーム開発では、全員が仲間で同じ方向を向いて進もうとしています。だとすれば、わからないメンバーがいるならば足並みを揃えて同じ方向へ進めるように手伝ってあげるべきです。となればもし質問が理論として整っていなくても投げてしまっていいはずです。「なんかキモい！」でも、「これ分からないんですけど、何が分からないのかも分からないです」でも、こういう粗い解像度の状態で口に出すことに価値があるのだと思います。整えてから出そうとすると、整うまでの時間だけチームが止まってしまい、納得感がないまま前に進んでしまいます。

必要だったのは、伝える勇気と拾ってくれる仲間を信頼することでした。言語化能力の問題として捉えている間は、この結論には辿り着けなかったような気がします。

さらに掘っていくと、根っこにあったのは「自分がやらなくては」「自分が軸になって進めなくては」という思いだったように思います。

振り返るとその思いが強い時ほど抱え込んでしまい、共有すべき情報まで自分の中に持ったままになっていました。引っ張ろうとしていたことがそのままチームを止める原因になっていたという皮肉な構造でした。

新しく知れた自分の強み

そんな中でどんなプロダクトを作るかの話し合いを続けていると、新しい自分の強みを知ることもできました。

特に私のチームメンバーは、抽象度の高い状態深く考えられる人たちでした。一方で、個々が考えすぎるあまり話し合いが停滞してしまって先が見えない状態になることもありました。そのため私自身は、このチームはどうしていけば良いものに近づくことができるか、を中心に考え「どこで考えるのを一旦止めるべきか」「チームとして同じ課題へ向き合い、個々ではなくみんなで答えを出すことがどうすればできるか」を悩んでいました。

正直、私自身は抽象度の高い話し合いは得意ではなく、すぐ具体的な話へ落とし込もうとしてしまいます。これは詳細な設計について話し合っている場面では有用ですが、もっとプロダクトの最初の場面では視野を狭めてしまうことになってしまいます。

そのため、今個々が考えている深掘りや振り返りを一旦止めてチームで共通認識を作って前へ進んだ方が結果的にいいものなのか、いや逆にここでもう少し掘り下げた方がいいのではないか、という判断をずっとしていたように思います。

最終的に私がやったことは、2つです。

始めに方向性を提示すること

自分が勝手に決めていいのか分からなかったため、最初は「いいと思う」とメンバーに言われるまで舵を切らないようにしていました。ですが途中からは、朝の段階で一日の予定を立て、なぜこれで行きたいのかを一緒に説明するようにしました。今これをやらないといけないと思っている根拠としては、今日中にここまで行くと決めたからだ、と。

それでも悩んでいるようであれば、一旦合意が取れているメンバーで区切りのいいところまで進めてしまい、進捗や意思決定は見れば分かる形に書き残しておく、逆引きのように進捗を確認してもらってどこが引っかかっていたのかを探す手がかりを見つけてもらう、という方法を取りました。

理由とともに方向性を提示する、それでも決まらなければ一旦進めてみる、進捗を可視化する。

とはいえ判断の根拠自体は、正直なところ最後まで直感でした。ロジックで詰め切ったわけではないので、あの判断が正しかったのかは今も分かりません。ですが、結果的にメンバーやメンターさんに推進力を持って進めてくれてありがとう、と言ってもらえたので、間違ってなかったと思います。

情報を整理する

詰まったら見える形に整理する、という進め方です。議論が進まないときは、口頭でのやりとりをやめて、ホワイトボードに情報を書き出すようにしていました。全員が同じものを見ている状態を先に作ってから、それぞれがどこに悩んでいるのか可視化する、どこを話したいと思っているのかを共有してからまた話す、という形です。

このようなやり方で停滞している中でもなんとか前に進むことができたと思います。

方向性を提示すること、つまり迷っている状態を選択肢のある状態に変えること、情報を整理して一旦の共通認識を作ること、つまり議論が発散したときに全員の認識を同じ地点に戻すことの2つです。この強みは、参加前には自覚的に持っていませんでした。

（ついてきてくれたメンバーには本当に感謝）

新しく見つけた自分の課題

代わりにはっきりした課題もあります。

一つ目は、抽象的な話が苦手なことです。一つ前で話したように、抽象的な話にはなかなかついていくことができず、何度か説明し直してもらう場面が多々ありました。

もうひとつは、質問されて咄嗟に答えられないことです。考えれば答えられることでも、その場で言葉にするのに時間がかかってしまいます。

両方とも具体に落ちていない話を捉える力が、足りていないのかなと今のところは思っています。

その他の振り返り

結局グランプリは取れませんでしたが、それでも自分たちが一番いいものを作ったと思っています。これは負け惜しみではなく、プロダクトとして本気でそう思っています。

ただ、選ばれなかったという事実がある以上、何かしら足りなかったものがあるはずで、それは実際に使われている想定の詰めの甘さだったのかなと思っています。そして結局、「他人事を自分事にする」という最初の壁に戻ってくるのではないかな、と考えています。

これが、3週間で一番難しかったことであり、まだ完全に解けきっていないことでもあります。

また他には、AI駆動開発の中で、実装前に画面のデザインファイルを作成することの利点と欠点について知ることができました。

UI/UXがノイズであると、届けたい価値もそのままでは届かないと考えているため、これまでの個人開発でもずっとデザインファイルを作成してきました。ただ今回は、それがチーム開発でどのように影響するのかを知ることができました。

利点として実感したのは、実装前に全員が同じものを見て議論できる点です。言葉だけの議論は抽象度が上がりすぎて噛み合わないことがありますが、画面があると「ここのこの操作」という粒度で話すことができます。また、AI駆動開発でもUIがブレない、というのも利点でした。生成に任せる範囲が広くても、新たにAIに機能を追加させても出力が発散しません。

逆にいうと、最初に作ったデザインが突貫すぎたため、議論がそのデザインに引っ張られてしまう問題も発生しました。具体があると話が進む、というのは利点の裏返しでもあって、まだ固まっていない段階で具体を出してしまうと、そこから先の議論が具体の中に閉じてしまうのだと思います。

これからやりたいこと

1つ目は、もっと人を信頼することです。これは、チーム開発やエンジニアリングの文脈だけではなく、自分の人生においての課題だと感じました。相手が自分を信頼してくれていると確信できないと信頼できないとか、抱え込みすぎて潰れてしまうとか。人生単位の課題を見つけにいくぞ！なんて意気込みで参加していたのではないですが、幸運にも見つけることができました。これもCARTAの皆さんがいつでも暖かく見守ってくれていたおかげだと思います。

2つ目は、自分の直感を言語化することです。これまでの個人開発では自分自身がペルソナだったため、課題も価値も意識的に考えるまでもなく進めることができていました。実際、これまで自分が作ってきたプロダクトについて、ありがたいことにメンターの方にもメンバーにも褒めていただけました。ですが今回のチーム開発では、そのやり方をそのまま持ち込むことができず、自分の強みを最大限発揮しきれなかったという感覚が残っています。

今回それが通用しなかったのは、今までの開発で何を課題と見なし、どこに価値があると判断してきたのかを自覚していないからだと考えています。なので、今までのプロセスを他人に説明できるレベルまで言語化して、自分がペルソナでない場合でも再現性のある形にしていきたいと思っています。

3つ目は、Treasureで学んだことを自分用のドキュメントにすることです。まだ整理しきれていないので、忘れないうちに、読み返せば当時の状態を思い返せるように書き残しておきたいと思います。

また他には、おすすめされた「ユーザーストーリーマッピング」の本を読みたい（買いました）だとか、アドバイスいただいた個人開発をもっと進めたいとか、指摘された理解が曖昧な技術用語（認証・認可とか）を整理することとか、おすすめされたご飯屋さんに行きたいとか...上げだしたらキリがないですが、この3週間でたくさんの刺激を受けることができました。

本当に本当に参加させていただきありがとうございました。人生で一番忘れられない夏休みになりそうです。