見出し画像

ジーズアカデミーの卒制でチーム開発ってどうなん？に少しでも答えたいノート

udonDsuki

WHY ME?（本編は次のセクションへ）

チーム開発に関心を持つまでの私

　私は週末DEVコース＠東京校に入学しました。
ジーズアカデミーに入学した皆さんのほとんどが、入学時の時点で
「自分の思い描いたプロダクトを世に出したい」
そう思っている方がほとんどかと思います。
私の場合は「世の中にないモノだけど、当たり前に必要だと思うモノを具現化したい。」とは思っていたものの、
これといって具体的なプロダクトのイメージがない状態でのスタートでした。入学式の時点で目的意識のはっきりした動機の自己紹介を聞いて面食らったのを覚えています。

　そんな私でもこんなプロダクトが作れたらいいなというものが徐々に固まってきて、さぁ卒業制作の企画どうしましょうか…というタイミングのことでした。

プロダクトの発想自体はすごく面白いと思うけど、ビジネス的にどうなん？
そもそも需要あんのか？最初のユーザーはどこにいる？
本当に価値はある(課題解決できる)？

大ちゃん「心の声」

色々と考えていくと、想いの強さとは裏腹に、現実的な課題がどんどん出てきます。「俺のプロダクト最強だぜ。熱いぜ」と思っていても、指摘一つでその存在意義が揺らぎかねないことに気づきました。

マネタイズ回りを全く考えていなかったのと、短い卒制期間で満足なものを作れるか怪しい。そこで少し切り口を変えて、今自分にとって決定的に欠けていて必要な要素を得るためのアクションをとってみてはどうかと考えました。　　
「まずはビジネスの立ち上げと、他者とチームを組んで一緒にプロダクトを作る経験をすべきでは…？起業狙いならなおさら重要な要素だろう。」
もちろん、同期の中には初期構想を貫き形にしている素晴らしい方々がいる。自分のプロダクトに賭けて突き進む。そういう選択もあったよな。と今では思えるのが面白いところ。どのみち今とは違った何かを得られたことでしょう。

　さて、チーム開発について興味を持ち始めたわけですが、卒制は個人開発が主流なのか(という印象を持っていた)、チーム開発はDEVコースのカリキュラムで扱うこともないので、人づてに情報収集するしかありません。チーム開発ってどうなん…？情報ないけど…普通やらないってことよね…？という風に最初は思っていました。
その後、担任のちぇるさんはじめ、DEV25期の先輩方々からお話を聞く中で、得るものはでかそうだなとポジティブな印象に変わっていきました。

だから、こんな人に届けたい

チーム開発に取り組んでみてわかりましたが、チームによって人員構成やキャラクタもバラバラ、作るプロダクトの方向性も違うので卒制におけるチームの在り方は10チームあれば10通りあります。しかも、上手くいくチームもあれば、いかないチームもある。正直、何が正解かは変数が多すぎてわかりません。「チーム開発の虎の巻」的なハウツーを書けたらいいのですが、自分たちスペシャルの結果論にしかなり得ないでしょう。ということで、あくまで私がチームの一員として取り組んだことや、マインドを中心にまとめ、参考情報だけでも充実させたものを書きたいと思いました。
個人開発・チーム開発を並べたときにチーム開発に関する情報が明らかに不足している状況を少しでも変えておけば判断の一助になるかなぁと思いましたので、
・チーム開発に興味がある方
・プロダクトのアイディアがわかないけど、技術は任せて！な方
・心から応援したい、むしろ実現に協力したいプロダクトがある方
・個人開発こそ正義だと思っている方
そんな人に読んでいただきたい。（だいたいみんなw）

※個人vsチームの優劣を示したいわけではないので、その前提をお忘れなく。自分のであれ、他者のであれ、自分信じるプロダクトにコミットしてください。

チーム加入の経緯

モチベーション

チーム開発やるかー。と思ってすぐやろう！となるわけではありません。私の所属したチームでは当初CEO単独のプロダクトで、企画書提出前にメン募のプレゼンをしてくれました。ぶっちゃけ聞く前から決めてましたよ。注目していたポイントは４つ
ポイント①「価値が明確」だが仕組みとして「不完全」
ラーメン屋さんのファストパスをという話は当初から話は聞いていたので、普通に欲しいよな。と思っていました。ただ、店側からはネガティブな声があったり、ファストパスを販売することが、善にも悪にもなりそうな不安定さをはらんでいる。ファストパスが爆売れしないような工夫がそもそもなくてはならないので、ちゃんとした仕組み込みで構築する必要があると感じました。そんな不完全さが、まず気になっちゃうポイントでした。
「当たり前にあってほしい・あるべき」もの。でもよくわからんしがらみに阻まれ実現できずにいる…ほっとけません。

並んで食う飯が美味いのは、「並んだからには…」というバイアスと単に待ち時間でおなかが減った効果のアシストがあるわけですが、並ばなくてもめちゃくちゃ美味いのを私は知っている。利用者は文字通りその味を高く買ってくれる人。それってめちゃくちゃ健全なシステムじゃないか…！
↑
私の行列感的には絶対に実現されるべき仕組み。だから一緒に作るまでいかなくてもアイディア出しだけでも協力したいなと思っていました。

だいちゃん心の声

ポイント②「プロダクト名が常軌を逸していて好き」
こればっかりはレインボーさんの手柄かもしれない(笑)
ラーメン屋さんのファストパスを扱うプロダクトで「お先ご麺」
ファストパスを取り巻く正負の感情を「ごめんねー（テヘペロー）」で片づける痛快さがすごく良かった。こういう世界観もアリだよねという表現としてこれ以上ないネーミングだと思いました。
ポイント③「ただのファストパスにとどまらない可能性」
ファストパスの値段を決めるためのロジックだったり、購入データをどう活かすかについても意識されていました。まだ先の話にはなるけど、技術的にも面白いし、実用レベルで標準化されて活用されているものを私は見覚えがない分野だったので「そそるぜ…」ってなりました。
※詳細は一応伏せておく
ポイント④「CEOが人間として普通に好き」
CEOの人柄、価値観がいいね！と思ったのも大きいです。今となってはプレゼンの進行上、ささやかなイントロとなった「南アフリカで価値観が変わった経験に」に基づく時間に対する価値観、すごく良いと思いました。私も時間を奪われる日々にイライラｘ1京していて人生をスポイルされていると感じる中、成り立ちは違えど、共感できる部分が非常に大きかったのです。
そして特筆すべきは皆さんご存じのあのえちえちキャラクターと尋常じゃない行動力。
はっきり言って異常ですよ。君は(賞賛)
すごい経営者は人を惹きつけるというようなことをよく聞くけど、まさにそういうタイプだなぁと感じたのでした。

いいハンターってやつは
　　　　　動物に好かれちまうんだ…

個人開発はどうする？

結論から言うと、私が選択したのは「お先ご麺に全額ベット」でした。

当時の私は、
努力と積み上げの可視化をテーマにしたプロダクトを作ろうと思っていました。人知れずヤバいもの作る人。一生懸命継続する人。そういう人の取り組みを表現して応援したり称賛したりする仕組みを作ろうとしていました。
目標に向かって努力する姿こそが美しさが尊いと感じているからです。
結果とセットならなお至高だけど、主役はあくまで「過程」

一方で、関わろうとしているプロダクトの課題はとてつもなく大きく、解決には相当な努力が必要になるという点が非常に面白いと思いました。
これを成立させた先にみられる景色はさぞかし美しいことでしょう。
これに取り組むことは巡り巡って自分のプロダクトのコンセプトの価値を裏付けるものにもなる。そうだったらいいなぁと思ったんです。

結果として、GGAまでの道のりにおいて、見たかった景色は何度も見れました。これからもこれ以上の感動が続くと思うとわくわくします。

それと、行列。お前だけは絶対に許さん。戦う理由はそれで十分だろう？

おっと、なぜチーム開発一本に絞ったのかというお話でした。
どちらのプロダクトも全力で取り組むという選択はありました。ですが、両方やるということは仕事をしながら、自分のプロダクトを作る時間を確保して、さらに空き時間を作る必要があります。私は持ってる時間の100%を使わないと気が済まないタイプなので、余力なんて生まれるはずないと感じました。どちらも中途半端にしたくなかったので、答えは考えなくても出てきました。
かくして、自分自身の体験よりも仲間とビジネスを作る経験を優先することになったのです。

チームに入ってから取り組んだこと

①技術スタックはデプロイを中心に考える

一応CTOなので、ちょっと技術まわりの話をさせてください。
チームに入って、まず初めに現状を整理しました。
使用する技術スタックはある程度事前に決まっていたので、求められる機能に対して、ざっくり問題なさそうか見ておきました。

～当初の状態～
フロントエンド：Next.js (参加メンバーが日頃使っていたもの)
サーバーサイド：Vercel Postgres(とりあえず仮で組んだものが動いている)
デプロイ先：未定(上手くいっていない)

サーバーサイド言語に関してはphp系かnode.js系など(表現違ったらごめん)実行環境を備えたホスティング先をセットで選ぶ必要があります。
なので、サーバーサイド、デプロイ先の選定は同時に行う必要があります。フロントエンドのフレームワークのデプロイのしやすさでデプロイ先を選定することがあるなら、まず検討しているサーバーサイドの言語が動作する環境であることを確認する必要があるので注意しましょう。
私の加わったチームでは整理券システムを内包したプロダクトを想定していたので、

～スタート時～
フロントエンド：Next.js (参加メンバーが日頃使っていたもの)
サーバーサイド：Firebase (NoSQL)
デプロイ先：Firebase hosting

という構成で動き出すことになりました。
上記は私たちの例ですが、フレームワーク選定はよほどの機能要求がない限り、ぶっちゃけ選択肢の範囲ならなんでもＯＫです。(使いこなせる人は別)
なぜなら学習コストはあるにしても、最終フェーズまで生き残っているG's生なら新しい技術であろうと「そんなのかんけーねー！」でやり切る力があるからです。そもそもプロダクトのピボットもあり得るし、DBの設計も見直す可能性がある。これらに伴って技術構成を見直すことも必要になります。得意なものだけで走り切れるなんてことはほぼないと言っていい。あまりこだわりすぎないのが精神的にもちょうどよいかと思います。柔軟さが大事。

②チームの開発環境ってどう作っていく？

私が開発を始める前に結構な時間を使って取り組んだ内容を簡単に書きます。（細かい話はいつかqiitaあたりで供養する）

　Githubにベースとなるプロジェクトをメインブランチを作る

  • next.jsのベースのフォルダ構成は事前に整えておき、「このファイルはここで管理しているよ」という情報をまとめて共有　(図１) 

  • ブランチ名、ファイル、各種コンポーネントの命名規約を定める。

  • gitignoreに.envに書き込んでおく。ファイルの中身は別途共有

  • privateリポジトリにしておいて、チームメンバーを招待

図1.　 各種ファイル・フォルダの意図（サンプル）

　開発フローの選定・運用決め

  • ブランチの構成がシンプルに保てるGithubフローを選択（図２）

  • シンプルなフローなのでGitコマンドを限定しやすく誤操作を防げる。

  • 使用するGitコマンドを規定し、それらのすべてをVScodeのGUI経由で行えるようにする。（下記リンク）
    ※ノリで公開したらなんかちょっとバズって草生えました。

図２. 　開発フローを書き起こして共有

＜補足＞
開発フローを決めたところで、当初はみんなgitのコマンドなんてcommit/pushくらいしか使っていませんでした。このままでは変更を上書きしてしまったり、間違って重要なファイルを消してしまったり、いろいろと問題が起こるにおいがプンプンです。
なので、まず私がGitの基本的な情報をまとめ、メンバーにわかりやすく伝える必要がありました。しかしながらコマンドを教えたところで、ヒューマンエラーは起きてしまう。エラー対処まで含めると付け焼刃の勉強はあまり役にも立たない。そして知識のレベルを合わせている時間もない。開発期間との兼ね合いもあり、今回はコマンドを限定し、GUI上＠VScodeのボタン操作ベースの作業にに落とし込むことにしました。臨機応変な対応を除外した運用にしたおかげでGitの操作に不慣れなメンバーでも開発フローを稼働させることができました。
(CTOは不測の事態に備えてそれなりに勉強したけどね…それにコマンド打ってカチャカチャッターン！でモテたい私はコマンドで本当はやりたい)

そのほか、Mac/Winユーザーが混在する開発環境だったこともあり、その対策をしたり色々と準備をしました。（長くなるので割愛）

こういった内容は準備するに越したことはありません。実際には大人数でガツガツ更新をかけるような開発ではなかったので、そこまでやらなくてもよかったのかも説はありますが、これはこれでやっておくと開発データやプロジェクトフォルダ階層への理解が深まるので、最低1人はこういうことをやっておいた方がいいでしょう。

③デプロイルートを確保せよ

ベースとなるプロジェクトの構成ができた段階で絶対にやっておくべきです。ここをガッチリ先行しておいたこともあり、後にGithubフローが真価を発揮しました。
まず、適当なフロントとAPIやDBへのアクセス➡データ取得（実際の実装と異なってもいい）を仮組した段階でデプロイが問題なくできることを確認しておきます。
慣れた環境であればそこまで問題にはならないかと思いますが、
私は知っている。
ジーズの卒制では紆余曲折あって初トライの技術構成になることもざらなんだということを…
firebase hostingでのデプロイ手順を確認し、github actionを組んで、プッシュ時に自動デプロイできる仕組みを作ったりしておくと、後にめちゃくちゃ楽です。自動デプロイが回るようになると、ビルド、デプロイ時のエラーがすぐにわかるので、完璧な動作を確認したのちにmainブランチにマージすることができます。
つまり完成はしてないにせよ、常に公開できる状態(卒制提出可の状態)を維持したまま、プロダクトの完成度を段階的に引き上げることが可能となります。

【裏話】
その後なんやかんやあり、最終的にsupabaseのRDBを使うことになり、その際もデプロイの確認を一番最初にやりました。vercelコンボは噂通り簡単だったので、スムーズに確認できました。ドキドキした。

④MVP定義は断捨離に限る※私見です

WHYME地獄の次にみんなが地味にハマるであろう地獄。
それが「What's MVP?」地獄です。(今作った)
ユーザーにプロダクトの価値を伝える最小限の機能構成やらなにやらと…おなじみの自転車とか車のイラストが思い浮かぶ。すごくわかりやすいイラストの「アレ」。
～ここから先、抽象度高め～
ところが、自分たちのプロダクトに置き換えると、なかなかどうしてこれが難しいのです。なぜなら、ユーザーが感じるであろう価値が「自分の想像の中」に最初はあるからなんだと思います。
最初は自身のWHY MEや経験に基づき、「仮説としての価値」は想定します。そしてそれが価値だと感じられるまでの流れをイメージし、どんどん分解していくと、小さな喜びだったり、安心感だったり、優越感だったり、感情が動くきっかけが見つかるはずなんです。この一連のちょっとした出来事を再現する仕組みがまさしくMVPの機能要件となります。
買い物する過程が価値ならば、購入～帰宅までのストーリーはなくても成立するし、ひょっとしたらお目当ての商品を見つけた瞬間だけでもいいのかもしれません。〇分クッキングのような芸当も価値に直結しない部分なら「～の体で」置き換えたモックで十分許容できるのがMVPです。ユーザー体験のコアの部分に的を絞ると、ぶっちゃけアプリじゃなくても価値は伝えられるものもあるでしょう。ユーザー体験の演出上アプリというインターフェースを選択して、尖った部分特化して作りこんでいく。
（エッジを立たせることの重要性はメンターさんから学びました）

私の所属するチームでは卒制提出でもGGAでもなく、まずは実際のユーザーの目に触れるPOCを経ての改善をする前提でプロダクトづくりを進めてきました。POCで実際にユーザーが体験するシナリオの範囲内の機能に的を絞り機能要件について議論しながら開発を進めました。
結果として、DB連携は最小限のCRUD処理のみの簡素なものとなり、「どういうロジック」で「どこ」に「どんな」情報を表示すればユーザー的にいい体験ができるかという所にフォーカスできました。そしてPOCでのユーザーヒヤリングを通して現状の最新版のUIに近づけていく作戦をとりました。
私の所属するチームでは「それは今回検証したいユーザー体験的にいらんだろ」が積極的に言い合えるチームだったので、MVPのイメージは比較的早い段階で現在の形に近いものになりました。時間が余ったら味付けしましょうというくらいのイメージです。
技術に特化したCTOが技術を特化させすぎず、断捨離をガンガン進めていくという現実主義なところはちょっと変わってるのかもしれません。
CEO➡こんな機能を実現したい
CTO➡こんな尖った技術盛り込みたい
デザイナー➡こんなUIにしたい
それぞれの行き過ぎた部分をお互いにセイセイできる関係性はプロダクトの価値が何なのかの共通認識を維持することにもつながります。要はブレない。

※ビジネス面を意識すればするほど、自分のやりたかったこととの乖離が出てくるはずなので葛藤があると思います。実際に顕在化したニーズを狙うのか、新たな価値を提案するのかによっても、このあたりのバランスは変わると思いますね…

【裏話】
技術のCTOも自ら、機能を断捨離しまくっていたので、技術的な面でプロダクトとビジネスモデルが過小評価されないかがすごく心配で、GGA前の一週間は「負けたら絶対俺のせいだ…」とちょっとGGAブルーに入っていました。テンション下がるから言わなかったけどね。それくらいビジネス面で魅せられるプロダクトになっている自信があったんですよ。

⑤困難は燃料とせよ

これは本当に大事です。そして自分にとって一番強みだと思っている価値観(精神論ｗ)。短い開発期間とはいえ、本業の仕事をしながら開発ペースを保つのは本当に大変でした。その上とにかく色んな課題が発生します。
・POC先がなかなか見つからない
・ユーザー認証の実装が詰んでてやばい
・DBをNoSQL➡RDBに変更したい(DB設計からリスタート)
・仲間以外からの言葉が全体的に舐めててテンション下がる

同期の場合だと、
・デプロイができない(卒業認定赤信号)
・chatGPTが嘘を教えてくる(不具合が知らず知らずのうちに複雑化)
・AWSがうんともすんとも言わない(ドメインの反映がされないだか)
・提出2週間前にピボット(それでもやり遂げる強者…)
なんてのもありました。

万事問題なく過ごせた人がいるとするなら「逆に損してないか？」というくらい当たり前のように多種多様な課題が降りかかります。
これはそういうものだと思って自分を鼓舞しましょう。
むしろこれを乗り越えるということは
・「ピンチを乗り越えた強者」の実績解除
・実装経験(課題解決)のｎが増える
・新技術を習得した「一つ上の開発者」となる
ということに繋がるからです。良いことしかない。
だから辛くても喜ぶべき展開です。

私の場合は、同期との日常的なチャットのやり取りだったり、Xでひたすらアチアチなツイートをすることで、自分に言葉を課し、自意識を高めてました(やけにエモいことばっかり言ってる時期は大体そういう時)。

【救済】マジでつらいときの支え➡共感力を養っておくと救われた
とはいえっても、やっぱり辛いときは辛い。人間だもの。
そうなってしまった時のTipsを私の実体験を踏まえて共有します。

①「向かう方向は違えど同じように全力で走っている仲間の存在を忘れない」
別々の環境でそれぞれの課題に取り組む我々ですが、ゴール地点で祝杯上げようぜと約束している状態だと思い返してください。
ちゃんと乗り越えないと笑顔で会えないじゃない…
ちょっとしたことで腐ってられないし、必ずたどり着かねば…と思えば、力が湧いてくるものなのです。

②「共感の永久機関をつくる」※共感力高めの人向け
結局は考えるのも実行するのは自分。いかにチームや仲間があろうと、各々の課題を乗り越えるのは自分自身。どん詰まりの最後にモノを言うのは、そう「あなたの心」です。
実はここだけの話、これを無限に高める裏技を偶然発見しました。ヒソヒソ
それが上記の発展形、いうなれば共感の永久機関です。
狙ってやってたわけではないですが、振り返るとこういう仕組みだったんだと思った言語化を試みます。
↓
プロダクトに対する想いだったり、取り組みの姿勢に共感できる仲間がいるとします。たまに負担にならない程度の小さなコミュニケーションをとって、今どこで頑張ってる！問題クリアした！はやく酒が飲みたい！なんてことを言うわけです。
共感力を高めることで、苦難を乗り越えた他者の喜びは自分の喜びになり、自分の活力に変わります。自分の頑張りも他者にいい影響を与えたい！と思うとさらに頑張れます。（以降無限ループ）
永久機関の実現に関わってくれた同期にはノーベル物理学賞級の感謝を送りたい。

【謝辞】
一緒に頑張ってくれたみんな。本当にありがとう！
今後よしなによろしくたのむぜ！

⑥GGAに向けたアクション：メンバーだって登壇者。でしゃばろうぜ！

卒制を乗り越えたら次はセレクション、GGAがあります。
GGAを通過点と考えるならば、チームメンバーにもやるべきことはありますよ！
ミッションは2つ。
・自チームの発表を演出含め最高の状態に引き上げること
・GGAというイベントを過去一目指して盛り上げること

これらを実現するために下記アクションをとりました。

(1) プレゼンの構成とパフォーマンスのFBをめちゃくちゃする
　(構成、間の取り方、動き、発表態度、言葉のニュアンス、感情表現、etc)
(2) UIのブラッシュアップ(プレゼン上効果的な部分のみ)
(3) セレクション前日にCEOにえちえち画像をDMで送る(奥さんご麺…)
(4) GGA前日にCEOにえちえち画像をDMで送る(奥さんご麺…)
(5) 出場決定直後から勝手に宣伝を始める(意味のないテキストの発信)
(6) 発表者が想定できていないであろうステージ上の状況を想定してあげる
(7) 登壇者全員のプレゼンにFBしまくって全体のレベルを上げる。
　  良いところを極限まで伸ばす。(自チームにもいい刺激になる)
(8)当日プレゼンの送りボタンが機能しない可能性があったので、
     電波感度確保のため5分間PCも持ち上げて保持

FBに関してはとにかく何から何まで最初は突っ込みました。発表者の良さ、キャラクターを伝えられるようなユニークさを残しつつ、締めるところところはガッチリ締めるような構成になるように一緒に考えました。「ここはこういう感じの方が絶対面白い」「ここはこういう伝え方をするのがカッコイイ」「ここはこういう感情だそうよ」など、こだわりポイントが実はたくさんあります。
そして、私含め様々な人からもらったFBを確実に生かして、自分のプレゼンに落とし込んだうちのCEOやばくない？最高のプレゼンテーションを本番で決めるKOKI RAMEN SAITO氏最高にかっこええ。

最高のプレゼン完成まで　～裏の立役者～
発表表現で最後まで納得のいかなかったポイントを最後にOKをくれたのはCEOの奥さん(令和の虎ファン)でした。
第三者的にどう見えるか次第だと思い、セカンドオピニオンを依頼。
こうして彼のプレゼン資料は完成したのでした。
また、CEOの息子さんは動画編集サポートをしてくれた。今度おじさんがpaypay送ってやるから待っててな！

また、開発同様、練習環境と本番環境は勝手が違うので、それを早い段階から意識できるように情報収集したりもしていました。緊張すると喉乾くタイプ？トーク走っちゃうタイプ？とかを聞いておいたり、自分の立ち位置とスクリーンの関係を想定したFBをしてみたり、最高のプレゼンテーションを実現するために想定できる限りのあらゆることをやった気がします。

(7)はイベントを盛り上げる上で特に重要です。イベントの成功を全力サポートしましょう。ここの自由度はチームメンバーだからこそ余裕をもってできた部分でした。ピッチ練習に参加できる限り参加して、自分のチームにＦＢしていたような内容の少し優しい版をプレゼント。副次的に自チームの発表者が油断せずに最後まで集中できるという効果も期待できます。
気づいたらみんなのプロダクトに思い入れがある…
ここまで来たら誰が優勝しても勝ちなんじゃないだろうか…という変な感じになります。

当日はクリッカーの電波100％受け取るためにこんなかんじでPCを持ち上げていた！

当日CTOが取り組んだ技術課題は物理


さいごにチーム開発で心がけたいこと・反省点

最後。心がけたいことは４つ。
①世界観に共感できること
　➡同じ方向を向いて進むことができる
②程よく守備範囲がばらけていること
　➡各々の見えていないところをカバーしあえる
③プロダクトの魅力を自分の言葉で語れること
　➡何が価値なのかブレない
④お手伝いさんでいないこと
　➡課題を乗り越えるための突破口は自分が切り開くぜマインド

これがうまく噛み合っていたの我々のチームだと思います。

反省点は
・飲みすぎて二日酔い状態でプロフィール用の写真撮影をしたこと。（しかも遅刻）
・打ち上げでたまたま同じリュックを持っていた福岡の同期のリュックを間違えてしょって帰ってしまったこと
お酒の飲みすぎにはくれぐれも注意してください。

といったところで以上となります。
いかがでしょう？チームを組むことの参考に少しでもなります…？
色んなことを盛り込みすぎてメッセージ性乏しいかもしれませんが、

普通ただのチームの一員がここまで思い入れをもって文章書くでしょうか？
考えてみてください。

それがチームってことなんやで…(適当ｗ)

よし、締まった！
それでは皆さん、また未来でお会いしましょう。お先ご麺ッ！！！🍜😊

この記事が気に入ったらサポートをしてみませんか？