VOYAGE GROUPのインターン『Treasure』に参加！【チーム開発編】
VOYAGE GROUPのエンジニアインターン『Treasure』に参加！チーム開発の進め方・KPTによる改善・プロダクト開発のポイントを詳しく解説。学びや成長の記録をシェア！
Treasureの後半に行われたチーム開発について書いています📝
VOYAGE GROUPのインターン『Treasure』参加レポート【講義パート1】2024/6/5 23:272025/3/4 1:39
VOYAGE GROUPのインターン『Treasure』参加レポート【講義パート2】2024/6/5 23:272025/3/4 1:39
VOYAGE GROUPのインターン『Treasure』参加レポート【講義パート3】2024/6/5 23:272025/3/4 1:39
VOYAGE GROUPのインターン『Treasure』に参加！【チーム開発編】2024/6/5 23:272025/3/4 1:40前回の続きです！後半戦のチーム開発チーム発表SOUL決めチームの開発方針8日目 8/21(水)これまでの講義内容に関する補講アイデア講義アイデア出しの手順アイデア出しでのKPT9日目 8/22(木) チーム開発初日チーム開発初日でのKPT振り返り10日目 8/23(金) チーム開発2日目今回開発する「eeNotes」というアプリについて技術選定で意識したことチーム開発2日目でのKPT8/24,25(土日)11日目 8/26(月) チーム開発3日目チーム開発3日目でのKPT12日目 8/27(火) チーム開発4日目チームで良いものを作るために大切なことチーム開発4日目でのKPT13日目 8/28(水) チーム開発5日目チーム開発5日目でのKPT14日目 8/29(木) チーム開発6日目ペアプロ・モブプロについて15日目 8/30(金) チーム開発最終日最終プレゼン後チーム開発を振り返ってみてTreasureを振り返ってみてまとめると開発以外のことシェアハウス15時の差し入れVGクルーさんのサポート体制最後に
前回の続きです！
VOYAGE GROUPのインターン『Treasure』参加レポート【講義パート3】2024/6/5 23:272025/3/4 1:39後半戦のチーム開発
そして、前半の講義が終わってからは学んだことを全力でアウトプットするチーム開発が始まりました！
チーム発表
この日の最後にチームメンバー発表があり、チーム開発を本格的に始める前に事前課題が1つ与えられました。
その内容は、
「チームのSOULを決めてくること！」
でした。
SOULとは
チームの「価値観」「考え方」「想い」などを表すもの
SOULを共有、形にして悩んだときに立ち返ることができるようにする
というものです。
SOULを置く意味
- アイデアを選ぶ際のチームの共通言語
- アイデアへの納得感を確立させるため
SOUL決め
ご飯を食べながら、全員がどんな人になっていきたいのか、どのような思いを持っているのか本音で言い合うことでメンバーみんなの見る方向性が明確になりました。僕は「多くのユーザーの方に幸せ・楽しい・便利と思ってもらえるサービスを提供していきたい！」と思い中心にあるということを話しました。
みんなが持つ共通の思いを言語化していき、最終的に僕たちのチームのSOULは、「世の中のスタンダードに」に決定しました。
また、モラルはわきまえて発言(相手の意図を汲み取る前に否定し強い発言をしないなど)しつつも、まずは自分を信じて考えを伝えることを妥協しない姿勢は大事なことで、お互いを尊重し合えるチームは良いチームだなと思いました。
チームの開発方針
サポーターの方の提案で、実際の業務で徹夜はしないしTreasureもインターンとはいえ、毎晩夜遅くまで開発をして体を壊して欲しくないという考えの元で、僕たちのチームは10時〜18時の決められた時間の中で集中して成果を出そうということを意識して進めていくことにしました。
与えられた時間の生産性を最大化するために、僕たちのチームは最初に、KPTを意識して現状分析し、次に行うべきことを明確にして開発の進め方をブラッシュアップし続けていこうと決めました。KPTとは、Keep(良かったこと)・Problem(現状の問題)・Try(意識していくこと)から構成される振り返り手法の1つです。
また、各々が認識した課題は全員が把握できるように、チームメンバーが見ることのできる日報に書き、日々の課題を可視化したり、毎朝行なったスタンドアップ・ミーティングで共有していました。
進捗や現状の進み具合は、2時間おきに報告し合い、進み具合や各々の担当箇所を考慮してペアプロしたりしていきました。
それでは、日々どのような振り返りをし、得た気付きを元にどのように行動を変化していくことができたのか対比しながら書いていこうと思います。
8日目 8/21(水)
これまでの講義内容に関する補講
午前中には、これまでの講義で質問が多かった部分に対して補講が行われました。
- Vue.js, ReactのXSSについてのセキュリティリスクについて
- state, component設計について
- 2日目のGo講義で使われたアプリケーションのアーキテクチャの補足
アイデア講義
午後からは、価値あるプロダクトのアイデアを考える方法についての講義がありました。
アイデア講義の最初に、成功しているソフトウェアの特徴はどのようなものがあるのか紹介がありました。
成功しているソフトウェア
- 問題を限定しうまく解決をしている
- あらゆる問題を下手に解決するのではなく、多くのユーザーの共通の問題点をうまく解決している
- 複雑さを隠す
- 複雑な事であっても簡単な事をしているように見せるべきである
- 開発者は常にユーザーを意識することが重要
アイデア出しの手順
その後、以下の手順に沿ってアイデア出しを進めていきました。
時流ワークショップ
- たくさん「時流」を洗い出す
- 適切な粒度に揃える
アイデアワークショップ
- 考える領域を一つ決める
- 領域にいるプレイヤーを洗い出す
- 考えるのみ使う時流を選ぶ
- 領域 × 時流をかけ合わせて「その領域で起こっていきそうな事象」を考える
- プロダクト案を考える
アイデア出しでのKPT
Keep
- アイデアの数がたくさん出せたこと
- お互いを尊重し発言できていた
Problem
- アイデアワークショップの領域が広すぎてしまい、お互いの共通認識を具体的に持つことが出来なかったこと
- どのようにアイデアを形にするのか実装イメージが湧かないことがあったこと
- 「趣味」という粒度でアイデア出しをしていた時に、人それぞれ異なるので、プロダクト案をうまく選定出来なかったこと
- 「なぜ」をもっと掘り下げて議論を展開できていなかったのでアイデアを深めていくことが出来なかったこと
Try
- 今回のように早くうまくいかなかったことに気づいた時、Problemを振り返り修正のサイクルを回していくこと
- 時間・集中力は有限なので、限られた中で良い成果を生み出せるように意識する
- 思うことがあったら、（Team Geekの言葉を借りると）HRTの精神を持ちつつ発言したりして積極的にコミュニケーションをとっていく
Team Geekはチーム開発におけるノウハウが非常に多く詰まっているのでオススメです✨
9日目 8/22(木) チーム開発初日
まずは、昨日の反省を踏まえて、再度アイデア出しを行なっていきました。何度か領域選定からプロダクト案の選定までのサイクルを回したのち、全員が納得できるアイデアが固まってきました。
そして、プロダクト案をより固めていくためにホワイトボードにターゲットや、必要な機能などを洗い出していきました。
チーム開発初日でのKPT
Keep
- 「なぜ」をもっと掘り下げて、お互い議論を展開していくことができたので良かった
- 必要な時(領域決め)は時間をしっかりとり、余裕があれば次の手順へいったりでき、時間管理がうまくできていた
- 一回アイデア決めのサイクルを回したがうまくプロダクト案がまとめられず次はどうしようとなった時に、しっかり領域決めから再度話し合うことができたこと
Problem
- 議論が詰まった時に、深めていくのができない時があったこと
Try
- まず全員が同じ認識を持っていけるように、具体的な用語で説明することを意識してUI設計を進めていく
- デザインを伝える際に言語化するだけでは人によってイメージが異なってくることが往々にしてあるので、適度に図を書き伝えていきたい
振り返り
- 議論が止まってしまった時は、視点を変えて(ユーザー・ニーズを具体的にしたり、抽象的になっている自分のアイデアを図を書くなどしてメンバーに伝える)みることは大事
- ユーザーとニーズを最優先で考えることを続けること
10日目 8/23(金) チーム開発2日目
アイデアが固まり、プロダクト案を実装フローに落とし込んでいく段階になりました。
行なったこと
- UI設計
- 技術選定
- DB設計
今回開発する「eeNotes」というアプリについて
一言でいうと
あなたの書いたノードが価値を得る！ノート投稿型シェアリングサービス
ターゲットユーザー
- ノートを投稿する側：電子デバイスでノートを取っている学生
- ノートを閲覧する側：全学生
ニーズ
- ノートを投稿する側：アウトプットがポートフォリオとして評価される
- ノートを閲覧する側：わからない授業を補足できる
特徴
SNS的に公開できる
- ノート検索ができる
- 同じ大学内の学生のノートを一覧で見ることができる
- ノートにいいねがつけられ、お気に入りのノートを保存することができる
マーカー
- 重要な部分をマーカーとして残せる
- ノート投稿の際に、マーカーを簡単に挿入できる
投稿
- マーカーを使って投稿できる
- リッチエディタを用いてノート整形
マーカーとは、ノートの本文をドラッグ&ドロップしたら以下のように強調表示され、右の一覧画面にある「ノートに追加ボタン」を押すとノートに挿入されるというものです。
技術選定で意識したこと
- 現在実装を進める為に、最低限必要ならばそれらの技術を導入することを考える
- 例えば、「propsのバケツリレーが発生してしまったらReduxを導入する必要があるが、基本的にStatelessコンポーネント中心でアプリを形に出来るならReduxを使う必要性はない」など
- 最近流行っているからや、導入メリットを具体的に説明できなければ導入コストのある技術を安易に取り入れてはいけない
チーム開発2日目でのKPT
Keep
- 全員で話し合いながら、UI設計・DB設計・技術選定・必要なタスクやコンポーネントを洗い出すことができ、進捗が順調だったこと
- 根拠を持つために具体的なペルソナを定めて話し合っていくことで、アプリの核となる機能・不要な機能が明確になったこと
Problem
- 話が入り込んでいくと、本質とは異なる内容に議論が逸れていくことがあった
Try
- 今は何を決めるために話し合っているのか常に意識しながら進めていくこと
学んだこと・考えたこと
- 今回のような限られた時間の中で最大限の進捗を出すためには、まず小さいゴール(投稿機能をデプロイすること)をチームメンバー全員で共有しておくことで、次に行うことがより明確になったのでPDCAを小さく刻んで回していきたい
- UMLでユースケース図を書き具体的なロールモデルを想定することで、本当に必要なのか根拠・自信をもって意見を伝えていくことができた
- 技術の選定を行う上で、確かな視点で導入できるように日々キャッチアップすることは重要
- DB設計を見直す際にも、UI画面にデモ値を入れてこのDB設計で本当に表示することができるのか考えることが有効だった
8/24,25(土日)
- フロントエンドは、どのようなコンポーネント設計で実装していこうか決めた
- バックエンドは、SwaggerでAPI設計を行なった
axiosでGET,POSTする際にはSwagger Hubを見ることで、APIのエンドポイントやResponseの形式が一目で分かるため、すごく便利でした。
また、サーバーのAPIが立つまでにSwaggerHubのモックサーバーを叩くことも出来たので、フロントとサーバーサイドをスムーズに繋ぐために動作確認することもできて良かったです。
11日目 8/26(月) チーム開発3日目
この日から、コードをガンガン書いていきました。
最初はフロント2人・バックエンド3人の構成で僕はフロントエンドの開発を始めました。
行なったこと
- Makefileを書き直した
- Gitのブランチ運用・作業把握・レビューについてチームの方針を決めた
- Linterの設定
- ノート投稿機能の開発
中間課題のフィードバック
この日は、中間課題のフィードバックがありました。
- Reactと関係のある処理(setStateなど)はReactの中で記述する必要はあるけど、Reactと関係ないピュアJSのメソッドで切り出せるものは切り出した方がいいよ
- でのデバッグが出来ない今回のケースでは、 を使うと、その処理を通過した部分で、Developer Toolsが止まるのでデバッグしやすいよ〜
- フロントエンドのテスト周りやバリデーションについて(バックエンドと対比して)
などのことを話していて、疑問に思ったことは掘り下げて聞いていたら1時間くらい経っていました😇
丁寧に答えてくださりありがとうございました!!
チーム開発3日目でのKPT
Keep
- ノート投稿機能のUI部分は割とサクッと作ることが出来たのでよかった
- Reduxを導入しなくても、書き方次第(StatelessComponentで実装可能な場合はそのように定義するなど)で任意の処理を書けていたこと
Problem
- 自分が今どのタスクを行なっているのかうまく共有出来ていない時間帯があったため、実装に詰まってしまった場合、どういった問題で苦労しているのか言語化するハードルが上がってしまった
- 今日は、完了までにかかった時間の共有があまり出来ていなかったため、他のタスクの所用時間があまり見えてこなかった
Try
- 議論の時は、今は何を話し合っているのか常に意識していくことが大事だったように、開発の際は、今誰がどのタスクに取り組んでいて進捗はどのくらいなのか全員が把握できることが重要だと感じた
- また、タスクの粒度が大きいほど(個人的な感覚だと45分以上かかるもの)は、タスクの全体像が見えにくくなってしまっているように感じた
- そのため、時間のかかり過ぎるタスクは実装する機能を分割できるはずなので、その点を意識していきたい
- 時間を区切り、15分しっかり考えても解決出来そうになかったら、メンバーやサポーターに自分なりの考えを伝えてから質問する
- せっかくチーム一丸となって開発しているのだから、頼っていける部分や自分１人で悩むより質問したら解決の糸口が見えてくるかもしれない場合は積極的にコミュニケーションを取っていく
- コンポーネントは、スコープのことも意識しながら、使いづらくならないように区切っていく
- メンバー・サポーターの方に今何をしている時間なのかしっかり共有すること
学んだこと・考えたこと
- 親から子へのコンポーネントのやりとりは、設計で工夫できる部分は色々あると学べた
- 他のUIパーツとの連携が容易に行えるを中心にUIを構築したため、propsの値リレーを減らすことができた
- 開発フェーズとなり、意識していくことが先週と比べ変化しているが、チームで開発しているということを第一に意思疎通を心がけていく
- ペアプロする際は、今どのように実装しようとしていて、何で詰まっているのか背景を具体的に説明してから一緒に考えるようにしていきたい
12日目 8/27(火) チーム開発4日目
行なったこと
- ペアプロで作成したAPIのPOSTリクエストを送信できるようにした
- マーカーという概念をチームの共通認識で持てるように話し合った
- マーカーコンポーネントを作成
最終的に「マーカー」という言葉になったのですが、開発の初期は呼び方が曖昧でした(付箋・しおり・ハイライト・クリップボード etc.)。
また、開発をしていて本当にその機能が必要なのか議論する場面もありました。
チームで良いものを作るために大切なこと
- 共通言語で語る
- 具体的なユースケースで考える
- サービスをより良くするために、ユーザー・ニーズを常に意識する
- 本当に必要な機能は妥協しない
チーム開発4日目でのKPT
Keep
- 午前中は、予定通り実装を進めることが出来たので、午後からの議論にスムーズに入れたこと
- 15分考えても前に進んでいなかった場合は、原因やどのような実装を考えているのか伝えて相談して解決することができたこと
- 自分や他のメンバーが取り組んでいるタスクをホワイトボードに貼り見やすい形で管理出来ていたこと
- 2時間起きのミーティングが行えていたこと
- 次は、ミーティングをより有意義にするために、疑問や決めておきたいこと・共有しておきたいことがあれば言っていくようにしていきたい
Problem
- フロントとサーバーサイドが作成してくれたAPIを繋ぐ際に少し詰まったが、流れを注意深く見てデバッグしていきたい
- まずリクエストの形式(特に定義された型になっているか)は正しいのかよく確認すること
- PRがよく上がってくると、コードレビューされずに溜まってしまうことが想定されるのでバックエンド・フロントエンド共にコードレビューしていきたい
- 実装が難しいものほど、エンジニア視点で物事を考えてしまいがちだが、まずは初心に戻りユーザー視点を忘れずに実装フローを考えていきたい
Try
- マーカーという言葉で共通認識を持つことができたので、気になることがあればすぐに言語化・共有したりして迷いのない実装をしていきたい
- マーカーが引かれたら、その情報をDBに保存するPOSTリクエストは、マーカーが引かれるたびに非同期処理で送るようにしたい
- マーカーが引かれる・削除されるたびにPOSTリクエストを送る実装でいく予定
- 非同期の部分は工夫できる箇所がいくつかあるが、時間対効果と相談になりそう
- 連続でマーカーが引かれたり削除された場合、並列処理でPOSTを送る
- すぐに生成されるコンポーネントにはルーティング表示するなど行なってUXを良くしたい
13日目 8/28(水) チーム開発5日目
行なったこと
- マーカー機能のベースを作成
- コンポーネントを切り出し、マーカーが引かれたらPOSTを送る処理の実装
- ペアプロで、マーカーの一覧表示を行えるようにした
- マーカーが追加されたら変更を検知して、一覧表示を再レンダリングする部分も実装
チーム開発5日目でのKPT
Keep
- お互いが実装した部分を繋ぐ際は、ペアプロを有効に行なっていくことができていた
- 行いたいことを似たような流れで他のメンバーが実装している場合は、そのコードの意図などを参考にすることで、開発スピードを落とさずに実装することもできていた
- どのようなUIや配置にしたらユーザーは使いやすいだろうか考えて開発していけていたこと
- 時間のある限り、どんどんヒヤリングや色々なユーザーに触ってもらって、ブラッシュアップしていければ最高
Problem
- 今書いてあるコードを元に、次に実装したいことを考え込んでしまい、結果として複雑な実装になってしまっていることがあったこと
- 時には、一旦考え方を変えてみるとよりスムーズな実装が浮かぶこともあるので、実装に詰まってしまっても現状のコードに捉われずに解決策を思考できるようになっていきたい
Try
- 相互レビューをより良いものにするためには、レビューしてほしいこと・あえて行なったことは、GitHubのコメントに書くこと
- コードに直接コメントを書くよりも、GitHubにコメントがあった方がレビューする際に分かりやすいため
学んだこと・考えたこと
- ネストが深くなりすぎないように、うまくコンポーネントを分割しようとしていたが、結果的に使いづらい形でスコープが切れてしまうことがあったので、機能単位で分割するように心がけた
- propsで親から子へ値を渡す際に、statelessでうまく設計できれば値の受け渡しが減ったり、直感的なコードになったりするので、明日も適切な使い方を心がけていく
- 議論やペアプロ、タスク管理が日々改善されているため、お互いが進捗を最大化できている感じがして、チーム開発がとても楽しいです！
- 開発期間が残り短くなってきましたが、協力しつつより良いプロダクトを作れるように取り組んでいきたい！
14日目 8/29(木) チーム開発6日目
行なったこと
- ガンガンペアプロ最後の追い込み開発
- スモークテスト
- プレゼン用として、DBのseedを作成
ペアプロ・モブプロについて
ペアプロやモブプロをしていて、うまく実装できてモノが動いた時は、
ハイタッチして喜びを共有したり、モチベーションを高め合うようにしていました
(諸説あり？？)
15日目 8/30(金) チーム開発最終日
行なったこと
- 最終デプロイ
- プレゼン資料を作り、発表
最終プレゼン後
最終プレゼンの後、Treasure生とサポーター全員で3週間を振り返り、一言言う場面があったのですが、３週間の色々な思いがこみ上げてきてとても感慨深い気持ちになったのは今も鮮明に覚えています。
懇親会が終わった後も、チームメンバーやサポーター・Goの講師と最終成果物のフィードバックをして下さった すずけんさんで終電くらいまで、色々なエピソードについてみんなでワイワイと話し合い、本当に別れ惜しかったですが、アツい握手を交わしてオフィスを後にしました。
チーム開発を振り返ってみて
- より良いプロダクトを作るために、考え抜き議論し実装するチーム開発が本当に楽しかったです！！
- 後半のチーム開発は、常により良いものを作るために言語化・思考し続けることが出来てよかった
- 各々のKPTを日報やスタンドアップ・ミーティングで共有する習慣があったことで、お互いが意識していることを認識しながら開発を進めることが出来たので、課題の共有は開発を効率化させていく上で重要だと学びました
- 今後のチーム開発でもしっかり行なっていきたいと思います
- 僕たちも全力でコミットしていましたが、サポーターさんも常に様々な視点でアドバイスやコミットして開発を手助けして下さったおかげもあり、エンジニアの生産性効率化の形をたくさん学ぶことができました
- 無駄のないチーム開発をしていくために、その場その場の状況に応じて臨機応変に選択肢を提示していけるようなエンジニアになっていきたいと強く思うようになりました
- そうなっていくために、本当にこの進め方でいいのだろうか・今の開発体制で問題はないのだろうか、現状を常に俯瞰して見ていけるように心がけていきます
- コードを書いていた期間は4日ほどでしたが、自分たちが大事にしているコア機能を実装することが出来たことは自信になりました
Treasureを振り返ってみて
- 一見難しそうでキャッチアップ出来ていなかったことでも、抵抗なく挑戦していくことが出来た3週間だったなと思います
- 常にコンフォートゾーンの外側に身を置くためにKPTを習慣付け、日々Problemを解決するためにTryし、振り返る。そうすることで、今日出来なかったことを明日は出来るようになるために挑戦し続けることができました。
- 日々学びがあり考え方が広がったことで、実装やチーム開発を進める上での引き出しが増えました
- これから先も、Treasureの時に常に心がけていた「なぜ」を掘り下げて考えることを大事にしていきたいです
- 時間的な制約がある中で常にどうしたらより良い開発が行えるだろうか考え、チーム一丸となり妥協せずにプロダクト開発を最後までやりきることができたことは大きな自信になりました
- しかし、まだ未実装の機能であったり修正できていない部分があるので、最後にチームで決めた**「リリースまでもっていく」**という目標を果たせるように取り組んでいきます！
まとめると
前半の講義で幅広いWeb開発の知見を広げ
後半のチーム開発では以下の流れ全般を、常にKPTを意識しながら学ぶことで
- アイデア出し
- 開発の流れの効率化
- タスク管理
- 実装
チームでの、ものづくりの楽しさを改めて感じることが出来ました！
そして、
- 疑問を持つ → 考える → (質問する ) → 解決
のイテレーションを高速で回し続けてきたことで問題をしっかり言語化して解決へ導いていく力が、参加前の自分と比べて向上したかなと思います。
開発以外のこと
シェアハウス
遠方から来る参加者のためにシェアハウスを用意してくださり、8/11から過ごしていました。
みんなバックグラウンドが異なり、初日は日付が変わるまで様々な話で盛り上がりました。(ちょうどMacの充電が切れなかったらまだまだ話しこんでいたでしょうw)
Vue Nativeを書いていた方や機械学習周りも強い方、CG系のスキルも凄い方まで各々でした。
みんなのやってきたことを話すのは、知らないことが知れて有意義ですね。
途中でVGクルーの方も加わり計8人で毎日賑やかに楽しい日々を送っていました。燻製を毎日作っている人も入れば、置いてあるスピーカーでベートーヴェンを毎朝かける文化が生まれたりw
美味しい燻製を作るためには、いかに水分を抜くかがコツらしいです。
3週間一緒に過ごしていて幅広く知見が広がったように感じています。仲間たちと一緒って最高でした！
15時の差し入れ
インターン期間中は、毎日クルーの方が差し入れをして下さりました！バラエティ豊富で、どれも美味しかったです！
VGクルーさんのサポート体制
Treasureではサポートがとても手厚く、僕たちが困った時・迷った時・どうしたら良いかわからない時に一緒に考えたり、解決の糸口になりそうな考え方を幾度となく示してくれました。
チームとして納得感をもって開発するための手助けやアイデア出しや各々のタスク振りの流れを効率化するためのアドバイス、技術的には実装に対する多面的なアプローチをしていただいたおかげで 多くのこと吸収し続けることが出来ました。
最後に
VGクルーの方々・TAさんには、事前課題から始まり、8月の3週間の間最大限サポートしてくださり本当に感謝しています！そして、この8人で一丸となってチーム開発していくことができて本当に良かったです！！
サポートしてくださったみなさんと次に会うときには、今回の学び・経験を活かしてより成長した姿を見せられるように頑張っていきます！！
最後になりますが、一緒に学び合ったTreasure生・3週間共に生活したシェアハウスのみんな・一緒にeeNotesを作ったチームメンバー・本当にありがとうございました❗️
小幡 十矛（Obata Tomu）｜価値を共創するエンジニア
東京を拠点に、アプリ開発・新規事業立ち上げ・ブランドづくりに取り組んでいます。
2021年にサイバーエージェントへ新卒入社後、ABEMA Live や AmebaブログのiOSアプリ開発を担当。
現在はフリーランスとして、複数の新規プロダクトやリアル店舗の立ち上げに挑戦中です。
🎯 Mission｜人の挑戦を加速する仕組みをつくる
── アイデアを形にし、前に進める“土台”や“場”を共創する
📌 「リアルな場 × デジタル」の可能性を探求し、新しい挑戦が生まれる土壌を育てる
🔹 エンジニアリング × ビジネスの視点から、アイデアを形にし、成長を支えていく
🔹 実店舗オーナーを目指し、オーダースーツ・ドライヘッドスパ・セレクトショップの複合店舗の立ち上げにも挑戦中
👥 特に、社会人1〜5年目くらいで
「やりたい気持ちはあるけど、最初の一歩に迷っている」方へ。
「自分の可能性をもっと広げたい」
「モヤっとしたアイデアがあるけど、どう進めていいかわからない」
そんなフェーズにいる方と、一緒に考えたり、手を動かしたりできたら嬉しいです。
🌱 「挑戦したい20代」との出会いも、大切にしています。
「ちょっと話してみたいな」くらいの気持ちで、気軽に声をかけてもらえたら嬉しいです！🙌
🌐 詳しいプロフィールはこちら
https://obata-tomu.jp/