チームでプロダクトを作るということ。 – 1ヶ月間のCX事業本部での研修が終わったので個人的に振り返りをしていく –

１ヶ月間のCX事業本部での研修が終了し、無事にMVPを完成させることができました！

#CX事業本部

#働き方

#会社紹介

#クラスメソッド

たいがー

2020.11.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

先週の金曜日で1ヶ月のCX事業本部での研修が終わりました、新卒エンジニアのたいがーです?

現在クラスメソッドの新卒一期生として入社した私たちは、風神、雷神という2チームに分かれ、各部署で研修をさせていただいています。それぞれの部署で出される課題に取り組み、年明けには正規配属される予定です。

4月からの研修はこのような形で進みました。

ES(エンプロイーサクセス)部: 1ヶ月
AWS事業本部
- コンサル部: 3ヶ月
- オペレーション部: 2ヶ月
IT推進室: 1ヶ月
CX事業本部: 1ヶ月

そして、私の所属している雷神チームは本日からDA事業本部で研修させていただく予定となっています。\よろしくお願いいたします!/

気がつけば社会人になり研修が始まり、約7ヶ月。そろそろどこに希望を出すのか考えなければならない時期がやってきます。その際、どんなことをしたのか思い起こせるようにブログを書いておこうと今回ブログを書き始めました。

クラスメソッドの新卒研修、どんなことしてるの?と気になっている方は是非読んでいただけたら嬉しいです！

CX事業本部での研修

研修では疑似案件として、企画からMVP(Minumum Viable Product:検証可能な最小限のプロダクト)の作成を雷神チームみんなで協力して行います。サーバーサイドとフロントエンドで使用する言語はTypeScriptが指定されており、1dayスプリント形式でスクラム開発でプロダクトを作成していきます。

研修が始まる1ヶ月前には、事前に研修についての説明をしていただきました。

研修で得るべきこと、期待されていること

研修で得るべきことは、こちらの3点。

CX事業本部でやっていることを知り、配属希望部署を決める時の材料にして欲しい
できればCX事業本部の事業に魅力を感じて欲しい
CX事業本部にいる人を1人でも多く知って欲しい

"技術やスキルなどを持ち帰ってもらうことが目的ではない"と事前のアナウンスがありました。また、研修中に期待されていることはこちらの4点でした。

なるべくたくさん、いろいろな人に質問すること
うまくやろうとするのではなく、体験して自分の感想を持つことを心がけること
やったことがない役割があれば、率先してとってみること
- やりたいことは、やってみたことの中から見つかることがある

研修の流れ

座学
- CX事業本部について
- アプリ開発の進め方のワークショップ(2回)
アプリ開発実習

研修期間ではCX事業本部の先輩方がオブザーバー(観察者)となり、質問をすれば答えてくださる体制をとっていただいていました。

期間中には各チームの方々との懇親会もあり、マネージャーさんとの1on1もあり、実際のお客様の定例も見学させていただけるというなかなか山盛りの内容でした。

コミュニケーションがなかなか進まないプロダクト企画会議

今回は"クラスメソッド社員が使うヘルスケアアプリ"というテーマが与えられました。私たち新卒チームは、そのテーマに沿った企画を考えプロトタイプを作成、実際に開発します。

皆さんはヘルスケアアプリといえば、どのようなアプリケーションを思い浮かべるでしょうか。歩数計のアプリ、カロリー計算用のアプリ、いろいろありますよね。

そこで、研修の始めに私たちが企画するためのワークショップを開催していただきました。

プロダクトバックログ(PBL)の作成

実際のワークショップの流れはこちらです。

目的・ゴール・ステップの説明(10分)
リーンキャンバス作成(30分)
インセプションデッキ実施(20分)
ユーザーストーリーマッピング練習(20分)
休憩(10分)
ユーザーストーリーマッピング実施(50分)
PBL作成(30分)
まとめ/質疑応答(10分)

そのワークショップではそれぞれのツールがどういうものなのかを解説していただき、実際にチームメンバーで完成させてこれから作っていくプロダクトのプロダクトバックログ(以下、PBL)を作成していこう!というものでした。

1回目のワークショップで作成したものをあとで編集したため、私たちが始めに作成したリーンキャンバス、エレベーターピッチが残っていませんでした… 一部私の記憶に頼ったことから曖昧な部分がありますが、なぜそのような結論にしたのかは最後に記載しているのでよろしければ最後までお付き合いください!

今回のワークショップで作る最終目標、PBLとは

プロダクトバックログは、プロダクトに必要だと把握しているものをすべて順番に並べた一覧である。プロダクトに対する変更要求の唯一の情報源である。プロダクトオーナーは、プロダクトバックログの内容・可用性・並び順に責任を持つ。プロダクトバックログは決して完成しない。構築の初期段階には、明確でよく理解できている要求が並べられている。その後、プロダクトや使用環境に合わせて進化する。プロダクトバックログは動的であり、適切で競争力のある有用なプロダクトに必要なものを求めて絶えず変化する。プロダクトが存在する限り、プロダクトバックログも存在し続けるのである。プロダクトバックログは、今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正をすべて一覧にしている。プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。プロダクトバックログアイテムには、「完成」時にそれを確認するためのテスト記述も含まれていることが多い。

スクラムガイドスクラム公式ガイド:ゲームのルール 2017年10月版より

つまり、PBLとはプロダクトに必要なものは何かがすべて順番に並べられて記されたものです。PBLはプロダクトや使用環境に合わせて耐えず変化して行きます。その何かに当たるそれぞれはプロダクトバックログアイテム(以下、PBI）と呼ばれています。ちなみにPBIは2020年版のスクラムガイドでは以下のようにより分かりやすく記されています。

スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異なる。

リファインメントが何であるかは2017年版の方が明確に記載されています。

プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。

よって私たちはリファインメントを行って、PBIの追加、見積もり並び替えを継続的に行い、説明・並び順・PBI自体のサイズ(規模)などの詳細を追加して行きます。ワークショップ中は、チームメンバーそれぞれがMiroを編集しながら話し合いました。

制限時間をオーバーしたリーンキャンバスの作成

リーンキャンバスとは、誰のどの課題を解決するためのアプリかを考えていくためのものです。

課題(Problem): 顧客の課題
顧客(Customer) / アーリーアダプター(Early Adopters): 顧客は誰か / 最初の顧客は誰か
独自の価値提案(Unique Value Proposition): 価値を解決する価値
解決(Solution): 課題を解決する
販路(Channel): サービスの届け方
収益の流れ(Revenue Streams): マネタイズプラン
主要指標(Key Metrics): ビジネスの評価指標
コスト構造(Cost Structure): 価値を提供するためにかかるコスト
圧倒的な優位性(Unfair Advantage)：　真似できない強み

これらを、上記の順番の通りに考えていきます。制限時間は30分でした。大体課題は3つ程度考えようと事前に説明がありました。

初めに課題を考えた時、チームの話し合いで出たのはこちらの二つです。

リモートワークによる運動不足
コミュニケーション不足

それらを解決するために私たちが価値として考えたのは、運動に関する記録を"シェアする場"の提供でした。最初なかなか話し合いがうまく進まず、事前に設定されていた制限時間に達したのにも関わらずリーンキャンバスを完成させることができませんでした。もう少し時間を延ばしていただき、次は時間内に完成させるように話し合いを進めて行きました。

この時点で作成予定だったのは、実際に自分の運動の情報をシェアし、その情報に対してアドバイスをしてくれるアプリケーションです。

医学的に証明できないアドバイスをすることは難しいのではないか、どのようにアドバイスをするのか、など話し合っている内容がリーンキャンバスに関する内容から逸れてしまうことが多くあり、制限時間を超過してしまいました。また、話し合い自体もどのように進めていけばいいのかチーム内で掴めていなかったため、なかなか会話が弾まなかったという原因もあったのかもしれません。

その後、なんとか作成したリーンキャンバスを元にインセプションデッキの中でもエレベータピッチを作成しました。インセプションデッキは10個の質問と課題から構成されており、関係者全員の認識を合わせるために実施しているものですが、今回のワークショップではその中のエレベーターピッチのみを作成しました。

何をアピールするかをエレベーターピッチで考える

"30秒以内に2文でプロジェクトをアピールする時、何を伝えるのか"を考えるものです。エレベーターピッチとは、エレベーターに乗っているくらいの短い時間でプレゼンする手法のことを言います。

今回、考えていく2文はこちらです。

[潜在的なニーズを満たしたり、潜在的な課題を解決したり]したい[対象顧客]向けの、[プロダクト名]というプロダクトは、[プロダクトのカテゴリー]です。
これは、[重要な利点、対価に見合う説得力のある理由]ができ、[代替手段の最右翼]とは違って、[差別化の決定的な特徴]が備わっている。

[]内に描いてある文面をプロダクトの内容によって変更して行きます。この時点ではプロダクト名が決まっていなかったため[プロダクト名]と記載しておきます。

[リモートワークによる運動不足を解消したり]、[身も心も健康に]したい[一人暮らし、リモートワークの社員]向けの[プロダクト名]というプロダクトは、[状況シェアアプリ]です。
これは、[社員の状況のシェア]ができ、[Slack]とは違って、[アドバイス機能]が備わっている。

オブザーバーの方々からのフィードバックは、このようなものでした。

差別的な特徴や機能の分かりやすさが欲しい
プロダクトカテゴリーをもっとしっかり絞ったら、あとの開発がやりやすくなる
課題の明確さがない
- "身も心も健康に"なりたいのは全員ではないのか
- ターゲットが広いため、ぼやけてしまう

目から鱗でした。確かに、身も心も健康になりたくない人なんているのでしょうか。"運動のシェアによって、メンタル面のヘルスケアもできたらいいよね。"という目的でこのような文面を入れていたのですが、プロダクト自体をボヤけさせてしまうことに繋がるとは想像できませんでした。今回のワークショップは"企画の仕方を学ぶ"という目的だったため、このエレベータピッチのまま進めたのですが、チームメンバーで次の日に考え直そうとなりました。(最終的にどのようなリーンキャンバス、エレベーターピッチにしたのかというものは後述します。)

実際にユーザーが使う流れを考えるユーザーストーリーマッピング

実際にどのようにユーザーに使ってもらうのか、流れを考えて行きます。

まず、先ほど作成したリーンキャンバス、エレベーターピッチを元にアプリのユーザーストーリーを10~20枚程度書き出して行きます。ユーザーストーリーの書き方は"〇〇(例: クラスメソッドの社員)は〇〇(例: 自分の状況を投稿すること)をしたい。なぜなら、〇〇(例: 他の社員に自分の状況を知らせたい)からだ。"という風に、誰<ユーザーの種類>が何<ゴール＞を達成したいのか。その<理由>はなにか。を考えて行きます。次に、それらを時系列(横軸)、優先順位順(縦軸)に並び替えて行きます。そしてその中から、MVPを決めます。最後に、それぞれのストーリーがどれくらいの規模なのかを見積もり、TシャツのサイズのようにSMLで記載して行きます。

S: 簡単
M: 普通
L: 難しい

そしてそれぞれSMLを2p、5p、8pとし、合計して全体的な規模を出して行きました。

ここで、1日目のワークショップが終了しました。先ほども言った通りに考え直そうとなっていた私たちは次の日のワークショップまでにユーザーストーリーマッピングまでを完成させておく必要があったので、次のワークショップの前に話し合いました。

今度は課題を"運動不足"と"1人で働くことの寂しさ"と設定しました。また顧客を1人で働いている"リモート勤務をしている社員"に限定することにしました。販路はSlackでの告知、収益の流れは研修で作る社内向けツールのため無し、主要指標はログイン人数と投稿人数を元に決定します。

しかしその後、⑨圧倒的優位性のところで話し合いが止まってしまいます。ただ状況を書いてシェアするだけではSlackの雑談チャンネルと変わらないのではないか。私たちのプロダクトの優位性となるものは何なのか。

話し合いがなかなか進まず、他の連絡手段や共有はどのようにしているのかと方向性を変えたりしていると"チャットでお礼を伝えることは大切だけど、直接伝えることには少し気恥ずかしさを感じる"という話題が上がりました。

"名前が見えるからこそ気恥ずかしくて言いにくい"のであれば、匿名にしてしまえばいいのでは？となり、私たちのツールは匿名性で作ろうと優位性が決定しました。そこからエレベーターピッチを考えて行きました。

[リモートワークによる運動不足を解消したり]、[孤独感を取り除いたり]したい[一人暮らし、リモートワークの社員]向けの[invi]というプロダクトは、[状況シェアアプリ]です。
これは、[社員の状況のシェア]ができ、[Slack]とは違って、[匿名であること]が備わっている。

無事プロダクト名も決まり、最後はユーザーストーリーマッピングを考えて行きました。(プロダクト名の由来は後述しています。)

オブザーバーの方からのフィードバックは…

次のワークショップの始めに私たちが考え直したリーンキャンバス、エレベーターピッチ、PBLを発表し、そのフィードバックをいただきました。

"ヘルスケア"アプリなので継続して使ってもらえるかが重要
- その工夫はどこにあるのか
正直使ってみないと今の段階ではわからない
MVPは最小限にした方がいい
- 例えば通知機能はMVPに入れるのかどうかなど
差別化の決定的な特徴をわかりやすくした方がいい
Solutionからプロダクトを作っていないか

確かに私たちは"匿名性"を考えついたが故にそこから"私たちが作りたいもの"を作り上げていました。しかし顧客の課題を解決するためにプロダクトを作成することからずれていたため、もう一度考え直す必要がありそうだとなりましたが、次のワークショップでは作り替えたPBIを使っていくことになりました。

スプリントの練習ワークショップ

今回の開発は、1dayスプリント形式で行います。その練習として、プロトタイプ制作をスプリント形式で行うワークショップでした。

スプリントは、それぞれの行動に対して時間が厳しく決められています。前日のリーンキャンバス作成で制限時間を守れなかった私たちも、このワークショップでは制限時間を意識せざるをない状況になりました。

PBIを作成するために私たちがすべきタスクは何なのか

スプリントの進め方はこのように進めて行きます。

スプリントプランニング(5分)
スプリント(15分)
スプリントレビュー(5分)
レトロスペクティブ(5分)

スプリントプランニング

スプリントで完成させられそうなPBIを選択し、そのPBIを実装するためのタスクを全て付箋に書き出します。

スプリント

先ほど書き出したタスクをAdobe XD上でプロトタイプとして作成して行きます。

スプリントレビュー

完成したプロトタイプをチームで見て、フィードバックを集めます。この時は、"プロダクトについてのみ"話し合うようにします。

レトロスペクティブ

プランニング、スプリント、レビューのやり方について、改善案を話し合います。この時は、"やり方についてのみ"話し合うようにします。

それぞれ時間を意識しながら進めないと気づいたら次の時間がやってくるというのがスクラムです。今回のワークショップでは、1人がタイムキーパーとして残り時間をチームに伝えるようにしました。

実際にスプリントで書き出していったタスクがこちらです。

そうして、2つ目のワークショップが終了しました。次から開発に入っていくという選択肢もあったのですが、やはりもう一度PBLを考え直した方がいいのではないかと話し合い、次のような形に出来上がりました。

PBLの作成 Part3

さて、先ほども書いた通りもう一度PBLを考え直すため、リーンキャンバス、エレベータピッチ、ユーザーストーリーマッピングを作成し直しました。

考え直したリーンキャンバス

課題をリモートワークによるコミュニケーションの難しさ、つまりメンタル面のヘルスケアに絞るように変更しました。投稿内容はユーザー自身が自由に投稿できるようにしようと話し合いました。

新しく考え直したリーンキャンバスで特に大切にしようとなったのは"気軽さ"です。気軽さを重視することによって、より他の社員を身近に感じ、ともに社員として働いていることを実感し、安心感のようなものを感じてもらえるようなアプリを作ろうとなりました。

クラスメソッド社員の中のアーリーアダプターを考える際に、やはり焦点になったのはコミュニケーションでした。コミュニケーションが難しい人はどのような人だろうかと話し合った時、身近に家族やパートナーなど話し相手よりもひとり暮らしをしていて話し相手が身近にいない相手こそ、より誰かを感じたいと思うのではないかと考えました。

考え直したエレベーターピッチ

先ほど考えたリーンキャンバスの結果を元に再びエレベーターピッチを考え直しました。

[社内で身近に感じられる話相手が見つかったり]、[自分に共感してくれる相手を見つけたり]したい[一人暮らしや身近に話し相手がいない]社員向けの、[invi]というプロダクトは、[状況シェアアプリ]です。
これは[社員の状況のシェア]ができ、[Slack]とは違って、[匿名であること]が備わっている。

考え直したユーザーストーリー、PBL

再び考え直したユーザーストーリーは、このようなものでした。

クラスメソッドの社員であるかの認証を行う
inviでの会員登録をする
inviでログインする
投稿の一覧を表示する
他の投稿へのリアクションができる
自分の状況の投稿ができる
マイページの表示ができる
他の社員の検索ができる

考え直したユーザーストーリーからPBIを考え、MVPとしてどこまで作成するかを選択して行きました。ようやくMVPで何を作るかが決まったので、そこからプロトタイプを完成させました。

さて、いよいよ開発を進めて行きます。

私たちは実際何を作ったのか

ここからは実際に開発で使ったツールや反省などを交えながら、私たちが実際に作ったinviというアプリケーションについて説明して行きたいと思います。

私たちのプロダクト inviとは？

inviはこちらの二つの単語の頭文字4文字からきています。

invisible / 見えない
invite / 招待する

"見えないからこそ、互いに招待しあって盛り上がって欲しい"という願いを込めて、この名前をつけました。inviのユーザーは、匿名であるため誰であるかはわかりません。しかし、クラスメソッドの一員の"誰か"ではあります。タイムライン上に並んでいる投稿は全てクラスメソッドの社員による投稿です。

emailアドレスでログインを行い、inviの中でのアイコンと名前を選択します。アイコンと名前はカメラボタンを押すとランダムに変更されるようになっています。

ログインすると他の社内の方々の投稿一覧が表示されます。"誰なのかが見えないからこそ発言はしやすく、同じ会社の社員であるからこそ共感しやすい"のではないかと考え、みんなが盛り上がっている雰囲気を投稿の流量で感じて欲しいというところからタイムライン形式にデザインしました。。また、他の社員への共感も示せるようにリアクションボタンも設置しました。

どのように開発を進めて行ったのか

雑に書くと、このような順番でした。

front-end(3人) / back-end(2人) 側の担当を決める
front-end / back-endチームで、それぞれどのようなツールを使うか決める
実際に開発していく

私は今まであまりチーム開発の経験もありませんでしたし、チームの誰よりも学生時代に開発をしてこなかったのはわかっていたのですが、一度やってみたかったfront-endに手を上げました。チームのメンバーがいなければ本当に完成出来ていなかっただろうと思えるほど、チームメンバーが優秀でした…

今回の研修で、チーム開発のなかのfront-endの経験ができて本当に良かったです。

開発は1dayスプリント

最初の方に記載した通り、開発は1dayスプリントでした。1日の流れはこちらです。

10:30~ プランニング
14:00~ デイリースクラム
18:30~ スプリントレビュー＆レトロスペクティブ

初め、ファシリテーター（スプリントのイベントの司会）は私が担当していたのですが、オブザーバーの方からのコメントを受け、毎日新卒メンバーで交代していくように変更しました。

プランニング

それぞれ今日何をするのか、達成するPBIはどれかを話し合います。

デイリースクラム

朝立てたプランニングがそのままで行けそうか、確認します。

スプリントレビュー＆レトロスペクティブ

今日、完成したPBIを発表して行きます。

レビューの時間には完成したPBIを見せなければならなかったのですが、なかなかfront-endとback-endが繋ぐことが難しく、私たちにとって厳しいレビューの時間が多かったです。PBIも大きすぎたからという理由もありますが、結果を見せたいけれど、見せられる結果がない状態が続きました。開発を始めた頃はもどかしく、しんどかったです。

使ったツールやライブラリ

front-end

ライブラリ: React
デプロイ先: Amazon S3
CI/CDツール: AWS Amplify

back-end

Framework: Serverless Framework
データベース: Amazon DynamoDB
CI/CDツール: GitHub Actions

プロジェクト管理はGitHub Projectsで

GitHub ProjectsのissueにPBIを実現するためのタスクを書き出し、assigneeを決め、実際に開発して行きました。Projectsでは、それぞれのissueの状態によって9列で移動させていました。

PBI: "誰<ユーザーの種類>が何<ゴール＞を達成したいのか。その<理由>はなにか。"というユーザーストーリー
To do: PBIを達成するべきのタスク
Weekly PBI: その週で達成させる目標のPBI
Weekly Task: Weekly PBIを達成するために行うissue
Todays' tasks: 今日行うissue
In Progress: 現在取り組んでいるissue
In Review: 現在PRを出しているissue
Todays' done: 今日終わったissue
Done: 今日以前に終わったissue

確定事項はNotionに記載する

APIの仕様やdata baseの中身がどのようになっているのかをNotionに記載してもらっていました。それを見ながらfront-end側は開発を進めていました。

まずは、開発する中での反省点をまとめて行きたいと思います。

開発における反省点

開発を始めた頃、issueにAssigneeを設定していなかった

最初の方はAssigneeを設定していないため、誰が現在どの作業をしているのか分からず作業全体がやりにくい状況になりました。そもそも全員がリモートの状態で開発が進んでいるため、誰が何を行っているかを把握できる場所がGitHub Projects上しかありませんでした。開発を始まってから見直し、タスクを書き出したタイミングや朝のプランニングなどで誰がそのタスクに取り組むかを決め、assigneeを設定していました。

PBIとタスクの細かさが全然足りなかった

開発を始めてからすぐはissueの書き出しをどこまで細かく選定すべきか分かっていなかったため、完了条件も記載しておらず、後からどんどんタスクが増えていくという状況に陥りました。front-endであれば、local hostでの表示なのか、デプロイしたのかなど環境で分けたり、表示させるだけなのか、実際APIを叩くのかなど機能面で分けたりすることもできます。とにかく細かくタスクを書き出すべき、それ以前にPBIをもっと細かくしておくべきだったとだんだんわかってきました。(確実に意識が出来始めたのは、研修が終わる週でしたが…)

PBIがclose出来ないことにより、私たちにとっても完成が遥か遠くに感じられたので、次回からは細かく意識して閉じられた！という達成感を感じられるようなPBIを設定できたらなと思います。

確定事項はNotionに"全部"そして"分かりやすく"書いておくべきだった

確定事項はなぜそのような結論にたどり着いたのか、理由も含めて全て細かく記載しておくべきでした。この結論に至った理由が書いていないため、見返した時になぜその選択をしたのか思い出す時間が必要でした。

また、ページの分け方を曖昧にしてしまったせいでどのページに何が記載してあるのかが見辛くなっていました。初めからどのようにページ分けをするか決めておけば、後から記載する人も記載しやすくなりますよね。

続いて、せっかくなので良かった点も書いて行きたいと思います！

開発における良かった点

純粋にチームメンバーと仲良くなった

現在私たち新卒メンバーは、日本、韓国、ベトナムとそれぞれ離れた拠点にいます。ですので、気軽に話すことはmeetを繋ぐかSlackでチャットするかしかありません。チーム開発を通して、よりお互いのことを理解できたような気がします。同じ大学出身の韓国のお2人の掛け合いが漫才みたいでよく笑っていました。

新卒間で分からないところを教えあったりできたのは本当に良い経験だったと感じています。material-UIのことを教えてくれたギーさん、front-end周り全般の相談に乗ってくれたビョンヒョンさん、本当にありがとうございました！！！

会話のやり方を柔軟に変えてみた

最初の企画の時はなかなか難しかったコミュニケーションですが、口頭の日本語で会話することが難しければチャットを併用したり、英語を交えて話してみたり、それぞれ会話の仕方を工夫しながら進めていくように変えていきました。自分の英語力が足らず、時々伝わらない時もあり、どうしていいのかわからなくなる状況も多くありました。他の海外在住メンバーはいつもこのような状況で仕事をしていると考えると本当にすごいなと思いました…!

開発が始まった頃は一度のミーティングだけでうまく伝わらず、ミーティングが終わった後にもう一度同じことを伝えることがありました。"もし分からないことがあるのであれば、その場でその都度止めてもいいということ"、"少し理解している状態なのであれば、今はどのように理解したのかを伝えること"をお願いしました。そうすることでお互いにどの程度理解しているのかを測ることができるし、よりミーティングの時間を短くすることができると伝えました。コミュニケーションのやり方を模索することで、意思疎通がやりやすくなり、お互いの時間を削ることがなくなりました。

初めてのことをたくさん経験できた

そもそもfront-endの開発自体も初めてでしたし、チーム開発も立ち上げの段階からいる状況は初めてでした。今回、React、material-UI、TypeScript、CI/CDなど様々な新しい技術を触ることができました。

少しコードを書いたことがあった私は、経験が少ないこともあり自分にはあまりコードが書けないと思っていました。APIを叩いて実際にDBの一部を表示させるところは同期がやってくれたので、そこから私が引き継ぎ、狙っていた通りに表示できた瞬間とても嬉しかったです。(喜びすぎて、同期からは宝くじでも当たったのかと思ったと言われました。笑)

経験が足らないが故にやりたいことがあるのにやり方がわからないことも多く、チームメンバーにたくさんフォローしてもらうことも多かったです。もっと勉強して、経験を積み、できることを増やしていけるように頑張りたいです！！

質問の仕方を学んだ

まずは自分で考えるということが大切だとは思っています。しかし、本当にどこから手をつけていいのかわからない場面に出会った時、どのように質問したらいいのかわからないことがありました。その時はどうしたらいいのかとオブザーバーの方に質問をすると"どこがわからないのかがわからない"と伝えたらいいと教えてくださいました。悩む時間を決めて、その時間まで悩んでもわからなければそのように質問してみたらどうかとおっしゃっていただいただけで、個人的にとても気持ちが軽くなりました。

自分の得意分野や好きなことを実感できた

どうやったらチームが進みやすくなるのかを考えること、コミュニケーションを取ること、プレゼンテーションが好きだということを改めて実感しました。メンバーとコミュニケーションを取ることや初めに発言することはあまり苦にはならないタイプなので、(開発はあまり得意ではない分)とにかくチームの潤滑油になれるように意識していました。オブザーバーの方に対しても、私ではなく、分からないメンバー自らから質問した方が良いのでは？と思い、よく"やっちゃえいっちゃえ"と背中をガンガン押していたタイプでした。笑

せっかく質問に答えてくださる方がたくさんいらっしゃるのだから、プロダクトをより良く、開発をより早くするためにはガンガン質問すべきではないかと考えていたからです。うまく動けていたと信じたいです。笑