ちゅらデータのサマーインターン体験記

はじめに

2Daysのちゅらデータサマーインターンに参加してきました。

簡単に振り返ると、2日間を通してデータサイエンティストとデータエンジニアの両方の体験ができるという何ともお得なインターンでした！！！

ちゅらデータサマーインターンに参加する前の話

インターンを振り返る前に、私がどのような経緯でちゅらデータのサマーインターンに参加することになったのか、インターンに向けて何をやったのかについて少しだけ触れたいと思います。

3月

Twitterでサマーインターンの情報を見つけました。沖縄は世間が狭いので（褒め言葉）、現役ちゅらデータ社員の方や元ちゅらデータ社員の方をフォローさせてもらっています。それでたまたまタイムラインに流れてきました。

3月の時点ではまだ何も就活を始めていなかったので、ちゅらデータのサマーインターンにエントリーしたことで私の就活が開幕しました。

選考は書類選考のみでした。

5月

ご縁があり、インターン参加に関するオファーメールが届きました。

その後、インターン参加するにあたってのやり取りをいくつかメールを通してやりました。

その中には、これまでに触れたことのある技術を答えるアンケートがありました。

どうやら参加者の経験をもとに、インターンで扱う内容を決めてくださっているようでした。

時系列が崩れてしまいますが、ここでインターン中に講師の方がおっしゃっていた話をします。

「このインターンの目的は参加者が成長すること。成長とは今日できなかったことが明日できるようになること。」

この言葉はすごく印象に残っています。

事前アンケートはこういった思いから行っていたのだと振り返って思いました。

交通費・宿泊費補助

私は沖縄在住ですし、ちゅらデータ本社までは車で20分くらいの距離感なので、マイカーを走らせて参加しました。

インターン生のほとんどが沖縄在住の学生だったので、他のインターン生もそのような感じでした。

中には石川県から参加されている方もいて、その方曰く自費で参加しているとのことだったので、おそらく交通費・宿泊費補助はなかったのではないかと思われます。

とはいえ今年のちゅらデータサマーインターンは全国5都市開催だったので、内地（沖縄以外の都道府県の総称）の学生も参加しやすい環境でした。

ちゅらデータのサマーインターンの話

それでは本題、サマーインターンで体験したことの話です。

インターン生は25名、メンターさんは10名ほどいらっしゃいました。

沖縄会場はオフラインのみの開催でした。

1日目：データサイエンティストコース

まずはメンターさんも含めた各テーブルでアイスブレイクとしてカードゲームのitoを行いました。テーブルはたまたま座った座席です。

のちにチームとして活動するので、ゲームを通してワイワイしながら親睦を深めていきました。

次にデータサイエンティストの業務内容や、昨今のLLM事情、RAGの仕組みに関する座学がありました。

その講師はなんと社長の真嘉比さん！！！

非常に贅沢ですね。

その後チームに分かれてRAGアプリケーション開発に取り組みました。

RAGアプリケーション開発

アプリケーション側は事前に用意されているので、欲しいデータをいかに正確に取ってこれるかというチューニングを頑張るタスクです。

どのようなデータを扱うかは自由で、（良識のある）スクレイピングをしてテキストデータを取得するところから始まります。

制限時間は3時間程度。

私たちのチームはいろんな候補を出した結果「ドラえもんのひみつ道具を検索できるRAGアプリケーション」を開発することにしました。

ちなみにこれは私の案です。

案を決める中でまず今回利用するLLM（gemini-1.5-flash-002）といくつか対話をしてみて、何を答えられて何が答えられないのか確認しました。 というのも、作ったRAGアプリケーションが仮に適切な回答をした場合、RAGによる効果なのか、そもそものLLMが答えているのか見分けが付くようにしたかったからです。

いくつか対話をする中で、「タケコプター」のようなメジャーなひみつ道具は妥当な回答をしてくれるのですが、「タイムテレビ」「桃太郎印のきびだんご」「かべ紙ハウス」のようなマイナー（？）なひみつ道具はカスリもしない回答をしてきたので、これだ！と提案しました。

するとチームメンバーも面白そう！と賛同してくれて、テーマが決定しました。

ひみつ道具のまとめサイトは何かしらあるだろうと思っていましたが、案の定ありました。

今回はこのドラえもん秘密道具データベースにあるコミック登場回数上位20個に関するデータをスクレイピングさせていただきました。

www.doraemondb.com

私のチームは4人だったのですが、2人・2人で役割分担をして、データをスクレイピングする担当とデータを処理する担当に分かれました。

私はデータを処理する担当を務めました。

やったこととしては以下のようなものです。

  • テキストをアイテムごとに分割（チャンキング）
  • チャンク単位に分割したテキストをベクトルデータに変換
  • ベクトルデータベースにベクトルデータを格納
  • RAGアプリケーションの実行

工夫したこと

  • テキストをアイテムごとに分割する際に文章をフォーマット化した

フォーマット

{item_name}について説明します。{item_name}は{item_description}

これは全てのテキストに明確な構造を持たせることで、ベクトルの意味合いが統一され、特定のアイテムに関するクエリに対して正確なベクトルを取得しやすくなるかな？という試みです。

  • ひみつ道具の説明文を「。」で区切り、データ数を増やした

例：桃太郎印のきびだんご 元の説明文

桃の絵が描かれた網袋に数十個入っている。味は美味。どんな動物でも、これを食べると言うことを聞くようになる。人間以外の全ての動物に有効で、脳の大きさが小さければ小さいほど効果は長持ちする。目安はハトで30分。作り方はまず、キビというイネ科の実をすり潰し、それを特製液で混ぜ合わせてダンゴにする。腐らないように粉状のオブラートでコーティングし、袋に詰めて出来上がり。このキビダンゴを食べた動物は、生まれたばかりのヒナが初めて見た動くものを母親だと思いこむ“すりこみ現象”と似たような事になる。ダンゴに入っている特製液によって、その動物の脳は生まれた時と同じ状態になる。そして、初めて見た人を自分の主人だと思い込んでしまう。これを食べさせて何度も訓練すれば、しだいに食べさせなくても言うことを聞くようになる。

データ

データ1：桃太郎印のきびだんごについて説明します。桃太郎印のきびだんごは桃の絵が描かれた網袋に数十個入っている。
データ2：桃太郎印のきびだんごについて説明します。桃太郎印のきびだんごは味は美味。
データ3：桃太郎印のきびだんごについて説明します。桃太郎印のきびだんごはどんな動物でも、これを食べると言うことを聞くようになる。
データ4：桃太郎印のきびだんごについて説明します。桃太郎印のきびだんごは人間以外の全ての動物に有効で、脳の大きさが小さければ小さいほど効果は長持ちする。
データ5：桃太郎印のきびだんごについて説明します。桃太郎印のきびだんごは目安はハトで30分。
省略

これはひみつ道具によっては説明文章が短いものがあったので、説明文章の長さに依存せず、クエリに対して正確なベクトルを取得しやすくなるかな？という試みです。

結果

どんな入力文を与えても毎回同じデータを取ってきてしまい、ほとんどのひみつ道具に関する質問に答えられない状態でタイムアップしてしまいました、、、。

ベクトルデータベースから取ってくるデータ数は初期値の4つとしていたのですが、どのような質問をしても「着せ替えカメラ」、「お医者さんカバン」、「桃太郎印のきびだんご」、「タイムふろしき」のデータを取ってきてしまいます。

つまり入力文による（ベクトルデータベースに格納してあるベクトルデータの）類似検索がうまくできていないという状態です。

時間ギリギリまで足掻きましたが、精度改善には繋がらず時間が来てしまいました。

データ加工の問題というよりはRAGアプリケーションの実装でうまくいっていないところがあったんじゃないかなという気はしています。

残念な状態で全体発表をしたのですが、「テーマの着眼点が面白い」「ベクトル化するデータに対してフォーマット化した工夫が素晴らしい」と評価していただけました。

他のチームもアプリケーション側の実装を工夫して音声出力対応をしていたり、面白いテーマにしていたりと発表を聞いていて楽しかったです。

2日目：データエンジニアコース

2日目はスライドを見ながらデータエンジニアのお仕事やデータエンジニアリングに関する技術の変遷に関する座学を受けた後、実際に手を動かしながらデータエンジニアリングの一連の流れを体験するハンズオンに取り組みました。

スライド枚数はなんと150枚越え！！！

決して冗長なのではなく、ハンズオンを進める中で必要な情報が画像付きで記載されており、非常に理路整然としていました。

どうすればいいかわからなかったら手を挙げるとすぐにメンターさんが駆けつけてくれるという神環境でしたが、私はほとんど手を挙げることなくスライドを見ながらどんどん進めていけました。

それだけスライドや講師の方の説明がわかりやすかったということです。

扱った技術は以下のようなものです。

  • AWS：Amazonのクラウドサービス
  • Snowflake：データ分析に強いデータベース
  • Terraform：AWSやSnowflakeの設定をコードで記述できる
  • dbt：データパイプラインを開発するSQL実行ツール
  • Snowsight：データ変換の結果をグラフなどを使って可視化する

名前は聞いたことあるけど触ったことない技術ばかりでしたが、ハンズオンを通してそれぞれの技術に対してイメージが湧くようになりました。

GUIでポチポチすることはほとんどなく、自分が思っていた以上にコードを書いてインフラを構築したりデータを処理したりして非常に楽しかったです。

懇親会

2日目終了後、オフィスにて用意されていたケータリングをいただきながら、社員の皆さんと交流させてもらいました。

日々の業務やカルチャーといったちゅらデータに関する話だけでなく、新卒就活の相談までさせてもらって、非常に有意義な時間でした。

真嘉比さんとも話をさせてもらって、ちゅらデータを立ち上げた経緯や沖縄のエンジニア業界に対する熱い思い、言語処理学会に関するエピソードを伺い、大いに刺激を受けました。

おわりに

名前や概念は知っているけど、実際のところ何をして何ができるのかイメージできなかった技術を、2日間のハンズオンを通してイメージできるようになりました。

スライドを見たり調べたりしながらではありますが、RAGアプリケーションの開発やデータエンジニアリングのプロセスを実行できるようになったのは「成長した」と言えるのではないでしょうか。

ちゅらデータは沖縄県トップレベルの技術力を誇るつよつよ集団なので自分がついていけるか不安もありましたが、講師やメンターさんの手厚いサポートのおかげで、その心配は杞憂に終わりました。

新卒研修も非常に手厚いとのことで、こうやってつよつよがどんどん生み出される良い循環があるんだなと感じました。

最後に、ちゅらデータのサマーインターンに参加しようと思っている方に向けて、私が体験して感じた魅力についてまとめたいと思います。

  • データサイエンティストとデータエンジニアのお仕事を両方学ぶことができる！！！
  • 講師・メンターさんのサポートが充実している！！！
  • ちゅらデータのカルチャーをビシビシと感じることができる！！！

以上、読んでくださりありがとうございました。

2023年に移転した新オフィス

Sansanのサマーインターン体験記

はじめに

1DayのSansanサマーインターンに参加してきました。

簡単に振り返ると、名刺管理のWebアプリケーション開発に関する課題に取り組みながら、React+Railsの開発を学ぶという良い経験ができました！！！

Sansanのサマーインターンに参加する前の話

インターンを振り返る前に、私がどのような経緯でSansanのサマーインターンに参加することになったのか、インターンに向けて何をやったのかについて少しだけ触れたいと思います。

4月

魔法のスプレッドシートを眺めていて、「React+RailsのフルスタックWeb開発 1Day Internship」を見つけました。

magic-spreadsheets.github.io

日程と使用技術の都合が良すぎて、すぐに応募しました。

というのも、9/2（月）〜 9/13（金）の期間は、freeeのサマーインターンに参加する予定だったので、9/14（土）に実施される1Dayインターンは東京に出向いている私にとって最高の日程でした。

また、Railsを使用するというところも、学習コストの面で都合が良かったです。

しかも、選考はなんと書類選考のみ！！！

このお手軽さが非常に魅力的ですね。

5月

ご縁があり、インターン参加に関するオファーメールが届きました。

その後、インターンの詳細に関するオンライン面談を行いました。

6 〜 8月

インターンに向けてRailsのチュートリアルを進めました。Railsを扱った経験がないので少しでもインターンでの開発をスムーズにしたいなと思い進めていきました。

Reactに関しては、ある程度扱った経験があったので、特に何もしなかったです。

交通費・宿泊費補助

私は羽田空港→那覇空港の航空券（13,310円）とインターン当日の宿泊先を手配していただきました！

学生にとってありがたすぎる！！！

私はたまたま東京にいる予定だったので復路の航空券しか補助してもらいませんでしたが、通常は往路の航空券も補助してくれるようでした。

交通費・宿泊費補助は定額としている場合も多く、そうなると私のように地方から参加する学生にとっては金額が足りず、自己負担することも多々あります。

なので、（限度はあると思いますが）このような交通費・宿泊費補助の形はありがたいですね。

Sansanのサマーインターンの話

それでは本題、サマーインターンで体験したことの話です。

当日、インターン生は10名、メンターさんは5名ほどいらっしゃいました。

今回はオフラインのみの開催でした。

タイムライン

12:45 ~ 13:00：　受付
13:00 ~ 13:45：　ワーク内容の説明
13:45 ~ 17:45：　ワーク
17:45 ~ 18:30：　振り返り
18:30 ~ 19:30：　交流会

ワーク

事前に用意されていた名刺管理のWebアプリケーションに関する最低限のコードを、課題を進めることでリッチなものにするというものでした。

課題は大きく以下の3つに分かれていて、どのような順番で取り組んでも問題ありません。

  • フロントエンド課題
  • サーバーサイド課題
  • フロントエンドxサーバーサイド課題

課題は一人で取り組み、課題が完了したらメンターさんにチェックしてもらい、次の課題に進むというような流れでした。

課題に対して少しでもわからないことがあれば、手を挙げるとすぐにメンターさんが駆け寄って、丁寧に教えてくださりました。

全てを解き終えることはできませんでしたが、私はフロントエンド課題、サーバーサイド課題と交互に取り組んでいき、幅広くReact+Railsの開発を体験することができました。

振り返り

まず、メンターさんが全体に向けて、課題の答え合わせをしました。

次に、グループごとにインターン生同士で、ワークを取り組むにあたって「何が良かったか」と「何が足りなかったか」を共有し合いました。

交流会

用意してくださった美味しい食事・飲み物をいただきながら、メンターさん、インターン生といろんな話をすることができました。

メンターさんは新卒でSansanに入社された方が多くいらっしゃったので、どういった経緯や理由でSansanを選んだのかといった就活に関する話をすることが多かったです。

また、Sansanの開発体制や拠点事情のことも聞けて、話を伺う中でSansanの雰囲気やカルチャーを少しは感じれたかなと思います。

おわりに

楽しい時間は過ぎるのが早いもので、1DayのSansanサマーインターンは一瞬でした。

課題を進めながら名刺管理のWebアプリケーションをリッチなものにしていく過程は、非常に楽しく、また学びがたくさんありました。

個人的に印象に残っている課題は、N+1問題を回避し、SQLの発行回数を少なくするというサーバーサイド課題です。

パフォーマンスを考慮した実装というものを課題を通して学ぶことができました。

また、課題が実際にSansanで開発している名刺アプリという設計なのも、Sansanで働くというイメージがしやすくて良かったです。

最後に、Sansanのサマーインターンに参加しようと思っている方に向けて、私が体験して感じた魅力についてまとめたいと思います。

  • 短時間でReact+Railsの開発を体験することができる！！！
  • メンターさんのサポートが充実している！！！
  • Sansanで働くというイメージがしやすい！！！

以上、読んでくださりありがとうございました。

表参道本社（どうやら渋谷に移転するらしい）

美味しすぎたオリジナルクラフトビール

ユニークすぎるノベルティ

freeeのサマーインターン体験記

はじめに

2週間にわたるfreeeサマーインターンに参加してきました。

簡単に振り返ると、インターン生、メンターさん、チームの皆さん、インターン生のサポートをしてくださった新卒採用担当の皆さん、関わってくださった全ての方々のおかげで、非常に充実した2週間を過ごすことができました！！！

「あえて共有」という意味でも、私の体験を公開したいと思います。

freeeのサマーインターンに参加する前の話

2週間を振り返る前に、私がどのような経緯でfreeeのサマーインターンに参加することになったのか、インターンに向けて何をやったのかについて少しだけ触れたいと思います。

4月

freee沖縄ネスト（拠点）に関する記事をたまたま読んだことがきっかけで興味が湧き、HPを見ていたところインターンの募集を見つけました。 すぐに応募して、カレンダーを開いてインターン期間の予定を「freeeインターン」にしました。

その後、説明会→コーディングテスト→面接1回を全てオンラインで行いました。

コーディングテストや面接の内容については学生にとって一番気になるところだと思うので、覚えている範囲で紹介します。あくまで私が受けたものはこうだったよということなので、絶対ではありません。

コーディングテスト

コーディング試験サービスを使って行われる、よくある形式のコーディングテストでした。アルゴリズム問題2問を時間制限内に解いて提出するという内容でした。時間制限は覚えていませんが、十分解き切れる時間設定でした。また、コーディングの意図を自然言語で説明することもできました。

面接

エンジニアの方1名と40分程度の面接でした。お互いの自己紹介から始まって、終始穏やかに面接を進めることができました。私は履歴書を事細かに書いていたので、学生時代に頑張ったことは何か？と聞かれた際に、それをなぞるように詳しく説明していきました。

5月

ご縁があり、インターン参加に関するオファーメールが届きました。思わずガッツポーズしてしまうくらい嬉しかったのを今でも覚えています。

その後、インターンの詳細に関するオンライン面談を行いました。そこではなんと面接のフィードバックまでしていただき、自分のどこが評価されたのかを教えていただきました。 freeeでは最終面接後に採用したい人に対してオファーレターを送るという風習があることは知っていましたが、インターン生に対しても丁寧にフィードバックしていただき、素直に嬉しかったです。

6月

前の記事でも話しましたが、「freee技術の日」に参加しました。

funakun2735.hatenablog.com

これはインターンに受かったからとかではなく、ただただ興味本位で参加しました。

この日に初めて東京本社を伺ったわけですが、人の雰囲気がとても良くて、さらにオフィスがお洒落すぎて、「インターンも絶対現地参加するぞ！！！」と決意しました。

7月

インターンの配属希望アンケートがありました。各チームの事業内容、魅力、使用技術についての紹介があり、それをもとに第3希望まで選択するのですが、どのチームも魅力的で、悩みに悩んで回答しました。

結果はなんと、第1希望のチームに配属されました。ですが、このチームは東京本社がメイン拠点ではないらしく、私が2週間東京で現地参加すると知った担当の方が気を利かせてくださり、配属先を変更してくださりました。

個人的にリアルでのコミュニケーションを楽しみにしていたところもあったので、非常にありがたかったです。

8月

インターンに向けてRailsのチュートリアルを進めました。Railsを扱った経験がないので少しでもインターンでの開発をスムーズにしたいなと思い進めていきました。

交通費・宿泊費補助

拠点からの距離等の条件で金額は変動するのですが、今回私は5万円の交通費・宿泊費の補助をいただきました！

学生にとってありがたすぎる！！！

私はこれをフル活用して、自己負担額は2000円に抑えました！

  • 那覇空港→羽田空港の航空券：16,410円
  • カプセルホテル9泊：35,620円
  • 合計：16,410 + 35,620 = 52,030円

帰りの航空券代がないという異変に気づくと思うのですが、私はインターンをハシゴして帰りの便は次のインターン先に補助してもらうことになっていたので、このような額に収めることができました！

また、週末は都内や千葉に住んでいる友人宅に泊まらせてもらうことで、宿泊費も抑えました。

私が2週間オフライン出社できたのも、交通費・宿泊費補助や優しい友人が周りにいたからです。

freeeのサマーインターン自体、ハイブリッド開催なので、多くの方がオンライン参加されていました。

地方学生にとって、参加すること自体が難しいインターンやイベントがあるので、こういった補助やオンライン参加できる仕組みがあるのはありがたいですね。

freeeのサマーインターンの話

それでは本題、サマーインターンで体験したことの話です。

私は2週間がどのような毎日だったのかを忘れないために、その日が終わる前に
「何をして、何を学び、何がよかったか」についてコツコツとまとめていました。

また、インターンの内容とは全く関係ありませんが、オフィス周辺で食べた昼ごはんや夜ごはんについても紹介します。

メンターさんからは「俺よりオフィス周辺のお店知ってるね」って言われるほど、結構調べて食べに行っていました（笑）。

オフィス周辺のご飯屋は大事ですからね。

前置きはこの辺にして、それでは1日ごとに振り返っていきましょう！

1日目

ついにインターンが始まるということで、期待と不安が入り混じった感情の中、前泊していた友人宅から1時間半かけて電車で東京オフィスに向かいました。 電車が遅延していてバタバタしながら、ホテルに荷物を預けることもできないまま、指定場所に向かいました。

実は1日目はオンラインでの開催だったので、出社していたインターン生は私だけでした。

沖縄に貸与PCが届くのと私が沖縄から東京に向かうのとが重なってすれ違う可能性があったのと、せっかく沖縄から東京に来ているということで、担当の方が1日目にオフラインでのPC受け渡しを許可してくださりました。

私は度々、freeeの寛大な心と対応に救われました。ある程度の限度はあると思いますが、比較的融通が利く会社だと思います。無理かなと思うことでも、1人で抱え込まずに伝えてみると対応してくださるかもしれません。

やったこと

  • PCキッティング作業
    • なんとPCはインターン生用にと、新品を用意してくださっていた！！！
  • 全体オンボーディング
    • 全体として共有するような注意事項等を確認
    • 次に全体として集まるのは5日目の中間報告みたいなので、意外とインターン生同士で交流する機会がなさそう
  • チームオンボーディング
    • チームに分かれての活動開始！！！
    • まずはインターン生、メンターの皆さんで自己紹介
    • 最初の難関、環境構築に挑んだ
  • 夕会
    • 進捗の共有

わかったこと

  • 前評判通りのマニュアル・サポートの手厚さ
    • 説明が事細かに書いてある
    • インターン生内でどうしても解決できなそうなことはSlackで質問するとメンターさんがすぐ駆けつけてくれる
  • やっぱりオフィスが広いし綺麗
    • 技術の日にもオフィスツアーがあったが、想像以上にオフィスが広かった
    • 同じフロアの会議室に向かうだけでも結構歩くくらい広い
    • 今日は使わなかったがコンセプト会議室を使ってみたい

よかったこと

  • インターン生同士で環境構築を終えることができた！！！
  • インターン生で解決できなそうなことに時間をかけず、メンターさんに対して助けを求めることができた！！！
  • なぜうまくいかなかったのか、どうやったら問題を解決できたのかといったことを整理して、Slackにて共有することができた（あえて共有）！！！

昼ご飯

  • オフィスで売っていたお弁当を購入
    • 13時過ぎに買いに行ったが残り5つほどだった
    • 松屋の自販機は売り切れていた
    • お供に無料ドリンクバーのコーヒーを飲んだ
      630円のお弁当

2日目

1日目の夜からオフィスから1駅のところにあるホテルに泊まっていたので、なんと出勤時間は10分程度でした！！！

オフィス近くに住むのは正義だなと実感しました。

2週間でリュックとナップサックだけだったので、周りの人に驚かれました（笑）。

カプセルホテル

やったこと

  • プロダクトを好きに触る
  • PdMさんを交えて開発トピックに関するミーティング
    • 以下の項目を確認した
      • Who（誰の課題か、ターゲットは誰か）
      • As is（現状の課題）
      • To be（理想の状態）
      • Gap（理想と現実の差分）
      • How, What（差分をどのようにして埋めるか）
      • 競合はどのようにしているか
      • 目標リリース時期
      • 効果測定イメージ
      • デザイン
  • 該当機能周りを触る
  • 参考にできる実装箇所を探す
  • 理想ドリブンで追加したい機能を考える
  • やらないことを決める
  • 夕会
  • Design Docを書き始める

わかったこと

  • 情報が非常に整備されている
    • 開発に必要な情報は開発環境に全て書かれている
  • 開発フローの丁寧さ
    • Design Docをしっかり書いている
    • 何のためのDesign Docなのかについてチーム内で議論して共通認識を持っている
  • マジ価値・理想ドリブン・あえて共有といったカルチャーが開発にも反映されている
    • 理想ドリブンの議論は意外と意識しないとできない
    • フォーマットとして用意されていて意識が向けられる

よかったこと

  • 実際にプロダクトに触れて、開発トピックに対するイメージが湧いた！！！
  • freeeで実際に行われている開発フローを体験できた！！！
  • やらないことを決めることができた！！！
    • 理想ドリブンで考えると欲しい機能はたくさんある
    • スピード感を意識すると、本スプリントで実装するべきものとそうでないものの切り分けをする必要がある

昼ご飯

  • 同じチームメンバーのインターン生とお弁当を探しつつ、セルフオフィスツアー開催！
  • 18, 19, 20, 21Fと巡っていき、21Fで売っていたお弁当を購入
    • 13時過ぎに買いに行ったが1日目より残っていた（おそらく出社人数が少なかったから）
    • 松屋の自販機は売り切れていた（やっぱり人気）
    • 別チームのインターン生とも合流し、活動報告や就活の話をしながら食べた！
      680円のお弁当

夜ご飯

  • 同じチームメンバーのインターン生とオフィスと同じビルにある中華料理屋へ！
    • インターン中ではなかなかできないパーソナルな話までできた！
      フカヒレあんかけ炒飯

3日目

朝6時から度々他の人のアラームで目覚め、完全に寝不足、、

カプセルホテルは寝るまではいいのですが、朝が完全に辛いです。

やったこと

  • Design Docを書き進める
  • チームの皆さんとランチ！！！
  • PdMさんと仕様のすり合わせミーティング
  • チームメンバーとコードリーディング
  • 夕会
  • メンターの方とコードリーディング

わかったこと

  • コードの規模感
    • わかってはいたけど今まで経験したことないくらい大規模だった
  • Rails等の知識不足
    • 付け焼き刃のRails力ではコードリーディングに全くついていけなかった
    • 同じチームメンバーのインターン生はRailsを使い慣れているみたいだからとても頼もしかった
  • チームの特徴
    • M&Aによって生まれたという背景もあり、他のチームのプロダクトと技術的な観点で少し毛色が違うみたい

よかったこと

  • 開発トピックの仕様について気になるところをPdMさんに確認できた！！！
  • どういう実装をすればやりたいことを実現できそうかという議論ができた！！！
  • チームの皆さんのパーソナルなところを少しだけ知れた！！！

昼ご飯

  • チームの皆さんがお寿司屋さんに連れてってくださりました！！！
    • 自己紹介から始まり、いろんなお話をしながら美味しい海鮮丼をいただきました。
    • 個人的には拠点間の移動について聞けたのがよかったです。
      日替わり丼

夜ご飯

  • 同じチームメンバーのインターン生とオフィス近くの焼肉丼屋へ！
    • 今日は2人ともお疲れモードでした。
      カルビ焼肉丼

4日目

インターンの疲れが溜まってきたのか、寝不足が原因なのかわかりませんが、一日中眠気が取れない状態でした、、

やったこと

  • Design Docを書き進める
  • PdMさんと仕様のすり合わせミーティング
  • PSIRTの方にDesign Docのレビュー依頼
  • タスク分解（Issue作成）
  • 夕会
  • Design Docを愛でる会（読み合わせ）

わかったこと

  • マジ価値の視点
    • PdMさんとの仕様のすり合わせミーティングは昨日で1度終えていた
    • こういう実装をした方がユーザー体験を向上することができるのではないか？というアイデアを思いついたので、再度開いてもらった
    • 既にPdMさんの中でも考慮していた点であったらしく、理由があって今回のリリースでの仕様からは除いたみたい
    • インターン生内にもマジ価値の視点が芽生えたことを実感できた
  • セキュリティ意識の高さ
    • セキュリティレベルの定義がありつつも、専門としている方の意見をもらうような仕組みづくりがしっかりしていた

よかったこと

  • Design Docを書き上げることができた！！！
  • 想定しうるバグを列挙し、セキュリティの観点で議論をすることができた！！！
    • メンターさんが想像していたことよりも多くバグを挙げることができたらしくて、良い議論ができていたかなと思う

昼ご飯

  • 同じチームメンバーのインターン生とオフィス近くの天ぷら屋へ！

元祖オールスター天丼 小うどんセット

夜ご飯

  • 同じチームメンバーのインターン生とオフィス近くの居酒屋へ！
    • Design Docを書き上げたことを記念して（？）初めて一緒にお酒を飲みました！！！
      飲み放題2hで3000円くらい

5日目

1週目ラストということで、なんとか1週間乗り切ることができてよかったです。

終業後は友人宅に泊まらせてもらうために千葉に向かいました。

やったこと

  • 実装
  • 夕会
  • 中間振り返り会

わかったこと

  • Rails等の知識不足
    • コードリーディングの時にも気づいていましたが、いざ実装となった時にも改めて自分の実力不足に気づいた
  • ペアプロの難しさ
    • 出社しているチームメンバーとペアプロをした（私がドライバー、相手がナビゲーター）
    • Railsに慣れているとはいえ、初見のコードを読みながらドライバーに指示するのは至難の業
    • 相手はとてもやりにくかったかなと思う、、
  • インターン生の様子
    • インターン生全体を半分に分けて、中間振り返り会を行った
    • 文字での自己紹介はあったが、顔を合わせるのはこれが初めて
    • インターン生のパーソナリティやどんなチームに配属されて何をしているかを知ることができた
  • 東京オフィスのドリンクバー情報
    • アイスコーヒーは氷の量を調整するのが難しい（わかる）
    • 21Fの来客用コーヒーは美味しいらしい
    • ペプシではなく、コーラを飲めるサーバーはないらしい
    • ホットの麦茶が美味しいらしい

よかったこと

  • ペアプロで恐れず自分の考えや質問を伝えることができた！！！
  • すでに実装されている似たような機能（参考にできるもの）がどのように実装されているのかを見つけて理解することができた！！！
  • インターン生の様子を知れて良い刺激になった！！！

昼ご飯

  • 同じチームメンバーのインターン生とオフィス近くのラーメン屋へ！
    • 家系は好きなのですが、これが初町田商店でした！！！
      味玉ラーメン大

6日目

2週目スタートということで、リリースに向けて開発頑張るぞと意気込み、友人宅から1時間かけて出社しました。

やったこと

  • 実装
  • 夕会

わかったこと

  • CIがしっかりしている
    • PRまで出したかったが、1個テストが通らず出せなかった
  • 国際化がしっかりしている
    • 日本語だけ用意しておけば、他の言語は自動翻訳によって用意してくれるコマンドが神だった
  • PRで大切なのはレビュアーがわかりやすいかどうか
    • 粒度も大切だが、根本としてあるのはレビュアーがわかりやすいPRを意識すること

よかったこと

  • 少しずつコードを理解するスピードが速くなってきた！！！
  • インターン生で解決できなそうなことに時間をかけず、メンターさんに対して助けを求めることができた！！！

昼ご飯

  • チームのお二方がランチに連れてってくださりました！！！
    • お二方ともfreeeに中途入社されている方だったので、新卒で入った会社の話やfreeeを選んだ理由などお聞きしました。
    • 錚々たる企業を渡り歩いて来られた方が「freeeはチーム開発が上手」という話をされていて、改めて凄さを感じました。
      週替わりプレート・肉

7日目

7日目にして睡眠革命が起きました。

友達にダイソーで耳栓を勧められたので購入して耳栓して寝たら、朝6時から鳴り響く周りのアラームで起きることなく、ぐっすり眠れました！！！

私が悩んでいたことは100円で解決できるものでした、、、

やったこと

  • 実装
  • 夕会

わかったこと

  • 開発時間が足りない
    • QA依頼を出すことを考えると、じっくり開発できるのは明日まで、、、
  • Flipperによるアクセス制御
    • コード変更や再デプロイせずにアプリケーションの機能を有効・無効にできるの便利！

よかったこと

  • PRを出せたこと！！！
  • フロントの実装は一応できたこと（レビュー待ち）！！！

昼ご飯

  • 同じチームメンバーのインターン生とオフィス近くのとんかつ屋へ！
    • そろそろオフィス周りのご飯屋を探すのも難しくなってきた、、
      和幸御飯

8日目

リリースに向けてQA依頼もするので、じっくり開発できるのは今日が最後の日でした。

やったこと

  • レビュー修正
    • 昨日出したフロントエンドのPR修正
  • 実装
    • バックエンド開発
    • 機能は開発できたが、テストがまだ
  • 夕会
    • 残り時間とタスク量を見直して、リリース対象のスコープを狭くした方が良いのではないかという議論をした
  • リリース作業
    • フロントのPRがapproveされたのでマージしてリリース作業を行った
    • あとはアクセス制御をいじれば一般に公開される

わかったこと

  • テスト書くの難しい
    • RSpec書くの初めて & 思ってる以上にテスト項目が多かった
  • レビューでよく使われる略語のあれ（LGTMとか）
    • 正直見たことないやつもあって調べた

よかったこと

  • フロントはリリースまでできたこと！！！
  • 現状（残り時間とタスク量）を把握して、リリース対象のスコープを狭くする判断ができたこと！！！
    • 夕会で議論したこと
    • ざっくり言うと2画面作る予定だったが、1画面に変更した
    • ユーザーから困っているというFBをいただいている方に注力することを選択した
    • 全て中途半端で終わるよりは良いと思っている
    • ユーザーにマジ価値を最速で届けるという観点で決断できたのはよかった

昼ご飯

  • 同じチームメンバーのインターン生とオフィス近くのネパール・インドレストランへ！
    • ナン・ライスおかわり無料は最高！！！
      2種類のカレーとめちゃうまなナン

夜ご飯

  • freee東京オフィスで働いている大学の先輩と肉バルへ！
    • リリース作業で予定より1時間遅れたのに待っててくださりました🙏（神）
    • 身近な先輩だからこそ聞けるfreeeの話や共通の知人の話で盛り上がり、時間が過ぎるのがあっという間でした。
      五反田にあるワインが美味しい肉バル

9日目

リモート参加していたメンバーが東京まで来てくれて、全員揃ってのオフライン出社となりました！！！

やったこと

  • レビュー修正
    • 昨日出したバックエンドのPR修正
  • 実装
    • 対象としていた1画面分の実装が終わり、もう1画面もリリースに間に合うかもしれないという状況
    • QA依頼までのリミットは15時として、残りのタスクをホワイトボードに書き出し、みんなで作業を分担してラストスパート！
  • 夕会
  • 新卒採用担当人事の方との1on1
    • 本選考開始時期や選考内容などの採用に関する話だけでなく、今後のキャリアプランに関する相談にも乗ってくださって、非常に有意義な時間でした！！！
  • リリース作業
    • 当初目標としていた2画面分の実装を終えることができ、リリース作業を行なった
    • QAで問題がなければ、あとはアクセス制御をいじれば一般に公開される

わかったこと

  • オフラインコミュニケーションの凄さ
    • 明らかに開発スピードが違っていた
    • 相手がどういう状況で、何をしていて、何に困っているかなどがすぐにわかる状況がスピードに繋がったのだと思う
  • オンラインコミュニケーションの難しさ
    • リモート参加していたメンバーにどういうことが困ったかについて話を聞いた
    • 音声、画面共有、ミーティングに入るタイミングなど、課題が山積みだったことが発覚

よかったこと

  • 当初目標としていた2画面分の実装を終えることができたこと！！！
    • 昨日時点でどのタスクも8割程度は進んでいて、ラストスパートで残りを全て押し切った感じ
    • とはいえリミットが迫っている中、みんなで協力して無事終えることができたのは正直すごいし、達成感が半端なかった
    • お忙しい中、早くレビューしてくださったり、リリース作業を手伝ってくださったりしたメンターさんに感謝！！！

昼ご飯

チキン南蛮定食

  • 焼き鳥が食べたくて、オフィス近くの焼き鳥屋へ！
    • ランチは焼き鳥提供してないとのことでした（笑）。
    • しかし定食はご飯お代わり無料で最高！！！

夜ご飯

よだれ鶏定食と焼き鳥

  • 焼き鳥リベンジということで、昼と同じ焼き鳥屋へ！
    • 店員さんにも覚えられていました（笑）。
    • 実装終了を記念してみんなで一緒にお酒を飲みました！！！
    • インターン中ではなかなかできないパーソナルな話までできました！

10日目

ついに最終日となりました。

無事完走できてホッとした気持ちと、今日でもう終わってしまうのかという寂しさが入り混じった感情の中、いつも通り東京オフィスに向かいました。

貸与PCに貼られていたシールも10日間でこんなにすり減りました（手汗のせい）。

貸与PCに貼られていたシール

やったこと

  • 最終成果発表会の資料作成
  • リリース手順書の作成
  • チーム振り返り会
  • 成果発表会
  • 懇親会

わかったこと

  • 振り返りもしっかりしている
    • うちのチームでは振り返りフレームワークORIDをよく使っているみたい
      • Objective: 事実
      • Reflective: 反応
      • Interpretative: 解釈
      • Decision: 決断
  • 他チームの成果
    • 各チーム10分
    • 自己紹介、背景・課題、解決すべきこと、実装したこと、学んだことを発表
    • 誰がどんなタスクに取り組んでいるか初めて知った
    • どのチームも2週間で取り組んだことだとは思えないほどマジ価値を生み出していてすごかった（語彙力）
  • 人の雰囲気
    • イベントごとがあればすぐに立つわいわいスレ
    • 成果発表会わいわいスレにはなんと402件の返信が！！！
    • 発表開始時には太鼓や鈴が鳴り響き、終始明るい雰囲気で成果発表会が行われ、3時間があっという間に終わった

よかったこと

  • 活動を振り返ることができたこと！！！
    • やりっぱなしではなく、しっかり振り返って共有することができた！
  • 他のインターン生と親睦を深めることができたこと！！！
    • 初めましての人ばかりだったが、時間を忘れてみんなで楽しく食べ飲みした！
  • freeeサマーインターンに参加できたこと！！！
    • これに尽きる！

おわりに

2週間とは思えないほど充実した毎日を過ごさせていただき、私自身少しは成長できたかなと思います。

Web開発経験はありますがRails初心者だったので、正直完走できるか不安でした。

ですが、私の初歩的な質問にもチームメンバーやメンターさんが優しく答えてくれて、技術的に負担をかけてしまったところもあるとは思いますが、なんとか完走することができました。

インターン中にはQAが間に合わなかったので、一般に公開するところまではいけなかったですが、今回実装した機能がリリースされて、多くの方に価値を届けることができれば嬉しいです。

懇親会ではお世話になったメンターさんから、「本当にバランスの取れた良いチームだったね！」と言ってもらえて、とても嬉しかったです。

また、私個人の話にはなりますが、「ふなくんのリーダーシップは素晴らしい」と評価していただきました！

自分の強みとして活かしていきたいと思っていたことを評価していただけて、本当によかったです。

最後に、freeeのサマーインターンに参加しようと思っている方に向けて、私が体験して感じた魅力についてまとめたいと思います。

  • 現場で行われている開発フローを体験できる！！！
  • 大規模プロダクトの開発を体験できる！！！
  • freeeのカルチャーを開発を通して体験できる！！！
  • 人・環境がとても良い！！！

以上、だいぶ長くなってしまいましたが、読んでくださりありがとうございました。

最後にインターン生、メンターさん、チームの皆さん、インターン生のサポートをしてくださった新卒採用担当の皆さん、関わってくださった全ての方々へ

「:azasu-4630:」

オフィスとノベルティ

freee技術の日に現地参戦した

先日、freee技術の日に参加してきました。

freee-tech-day.freee.co.jp


場所は東京は大崎にある、freee本社（大崎オフィス）で開催されました。
全てはこの投稿から始まりました。

開催期間のうち6月1日（土）に、学生の方10名を抽選でご招待（交通費を15,000円まで補助）


この投稿を見た時、直感で当たる！と思いました。

結果は残念ながら落選してしまい、完全自費で参加してきました。

そもそも当選したとしても沖縄からだと完全に補うことはできませんが（笑）。

ですが地方学生にとってとてもありがたい制度ですね。


freee技術の日当日、1個上でfreee本社で働かれている大学の先輩とランチをしてからオフィスに向かいました。

先輩には就活の相談に乗ってもらい、ご馳走までしていただきました。

ありがとうございました！！！（見ていないだろうけど、ここでもお礼をしておく）


オフィスに着くと、どのフロアもとてもお洒落で田舎者には眩しかったです。

他の参加者に配慮すれば写真撮影可だったので、たくさん撮りました。

観光地でなくても写真を撮ってしまう田舎者あるあるですね（笑）。

優しいスタッフさんが撮ってくれた写真


コンテンツとしては、エンジニアリング、プロダクトマネジメント、組織作りなど開発にまつわるさまざまな技術についてのトークセッションが用意されていました。

個人的に印象に残った話をメモしていたので、そのままの状態でいくつか紹介します。

  • PdM・エンジニア・デザイナーの関わりが密接で、互いのドメインを理解しているからこそ、頼りまくったという話が素敵。
  • 現状を踏まえて積極的に勉強会を開いているのが良い。スクラム開発を用いており、QAの依頼にエンジニアが同じスプリント内で対応できたこともあるほど迅速に対応している。実際のユーザーの利用を見ることで解像度が上がった。
  • 「開発速度 = プロダクトの価値 ÷ プロジェクトに使う時間の総和」。ユーザーの声を元にした意思決定をすることで、高い確率でユーザーに提供できる価値を向上させた。各担当者の責任範囲を明確化し、短い時間で意思決定できるようにした。この2つが開発速度に繋がった。
  • ドメイン知識の壁を業務ワークショップを開いて解決した。言語の壁を翻訳ツールやチーム独自の言葉やスタンプを用いて解決した。各パーツを同時に開発し、先行販売やみんなでQAを行うことでスピード感ある開発を行った。
  • 良いプロダクトとは好きなプロダクト。ユーザーの本質的な課題を知り、自社ならではのイノベーションを起こすことが良いプロダクトに繋がる。
  • 良いプロダクトチームとは達成したいものが同じチーム。良いプロダクト、良いチーム、速さの定義などがバラバラだと良くなくて、共通言語として定義して一緒に同じゴールに向かって走ることが大事。強みを活かした役割分担や良きリーダーがいることも大事。
  • 極めることも大事だが、ある程度自立した後に滲み出て、周辺を知ることも大事。


多くのセッションに参加してお話を聞かせていただきましたが、
どれも「スモールビジネスを、世界の主役に。」というMISSIONを実現するために、
ユーザーに*1「マジ価値」を届けるためにというゴールや指針は同じでした。


また、トークセッション以外にも遊び心溢れるコンテンツがたくさん用意されていて、私は射的、カプセルトイ、オフィスツアー、Sweeeグリーティングに参加しました。

オフィスツアーでは普段見せない会議室まで見せてもらいました！

部屋ごとに考え尽くされたテーマがあって、正直カルチャーショックを受けました（笑）。


今回現地参加したことで、リアルな社風だったり、カルチャー、人間味といったところを少し知れたような気がします。ほんとに素敵な企業でした！


以上、freee技術の日に参加した話でした。

実はfreeeさんには今年のサマーインターンでお世話になります。

今回freee技術の日に参加して学んだ「マジ価値」のための開発プロセスだったり思考だったりを、今度はインターンを通して体験してみたいと思います。

2週間を通してどんどん攻めて攻めて、学びある失敗をして、*2ジブンゴーストを見つけたいです。

インターンも絶対現地参加するぞ！！！

いただいたノベルティ

*1:ユーザーにとって本質的な価値

*2:なりたい自分になることを邪魔しているジブン

PyData Okinawaに参加してSnowflakeを学んだ

先日、PyData Okinawaに参加してきました。

pydataokinawa.connpass.com

PyData Okinawa は Python + Data に興味のある方が交流できる沖縄を拠点にしたコミュニティです。


4年ぶりの開催だそうで、私は今回が初参加でした。

参加者のほとんどがデータ分析事業を行っている企業の方々で、学生は私だけでした。

内容はLT会で、SnowflakeエヴァンジェリストであるKTさんをゲストでお招きしていたこともあり、Snowflakeに関する話題がほとんどでした。

Snowflakeはデータの一元管理ができるクラウド型のプラットフォームです。

www.snowflake.com

データを管理することはもちろん、プラットフォーム上で開発やデータエンジニアリングなどもできるという優れものです。

環境差なく作業ができるという点がありがたいですよね。

また個人的には、他者の保管データにアクセスできる点が驚きです。

私は正直、PyData Okinawaに参加するまではSnowflakeという名前も知りませんでした。

ですが、今回参加したことで名前やサービスを知っているという段階にはなりました。

LTの中でSnowflakeはチュートリアルが用意されているというお話があったので、無料トライアルが切れる前にかじってみたいと思います。

オフラインイベントということもあり、SNSで繋がっていた方とお話しできたり自己紹介で名前と顔を売れたりしたので、少し緊張しましたが参加して良かったです。

次回のPyData Okinawaにも参加したいと思います！

Gitの基本的な操作

はじめに

私がTAを担当している講義のカリキュラムにGit入門という回があったので、具体的に何を講義でするのかはまだわかりませんが、基本的な操作についてまとめてみました。

ローカルにある3つのエリア

ワークツリー

ファイルを編集し、作業を行うディレクトリ。ここにあるファイルはまだGitの追跡下には置かれておらず、変更内容もコミットされていない。

ステージ

ワークツリーで変更したファイルの中から、次のコミットに含めたい変更を選択してステージするエリア。ここに追加された変更はGitに追跡されているが、まだローカルリポジトリの履歴には含まれていない。

ローカルリポジトリ

ローカル上にあるリポジトリで、ここにコミットされた変更はバージョン履歴に保存される。ステージされた変更をコミットすると、それらはローカルリポジトリに永続的に記録される。

コミット：ワークツリーでの変更をローカルリポジトリの履歴に記録するプロセス

コマンド

リポジトリの作成

# ローカルリポジトリを作成
$ git init

# リモートリポジトリのコピーを作成
$ git clone <リモートリポジトリパス>

変更をステージに追加

# 指定したファイルをステージに追加
$ git add <ファイル名>

# 指定したディレクトリにあるファイルを全てステージに追加
$ git add <ディレクトリ名>

# カレントディレクトリにあるファイルを全てステージに追加
$ git add .

コミット(変更を記録)

$ git commit

# gitエディタを立ち上げることなくメッセージ付きで変更を記録できるオプション
$ git commit -m "<メッセージ>"

# gitエディタでファイルに変更内容（どのような変更か）を表示させるオプション
$ git commit -v

現在の変更状況を確認する

$ git status

表示内容

  • ワークツリーとステージの間で変更されたファイル
  • ステージとローカルリポジトリの間で変更されたファイル

ファイル間の変更差分を確認する

# ステージに追加する(git addする)前の変更分
$ git diff

# 指定したファイルのステージに追加する(git addする)前の変更分
$ git diff <ファイル名>

# ステージに追加した(git addした)後の変更分を表示するオプション
$ git diff --staged

リポジトリのコミット履歴を確認する

$ git log

# 1行で表示するオプション
$ git log --oneline

# ファイルの変更差分を表示
$ git log -p <ファイル名>

# 表示するコミット数を制限
$ git log -n <コミット数>

ファイルの削除を記録する

# 指定したファイルを削除（ワークツリーからもファイルが削除される）
$ git rm <ファイル名>

# 指定したディレクトリを削除（ワークツリーからもディレクトリが削除される）
$ git rm -r <ディレクトリ名>

# ワークツリーにファイルを残すオプション
$ git rm --cached <ファイル名>

ファイルの移動を記録する

$ git mv <旧ファイル> <新ファイル>

同様の操作を行うコマンド

$ mv <旧ファイル> <新ファイル>
$ git rm <旧ファイル>
$ git add <新ファイル>

リモートリポジトリ（GitHub）にpushする

# リモートリポジトリを新規追加する
$ git remote add <リモートリポジトリ名> <リモートリポジトリURL>
  • 指定したリモートリポジトリ名でリモートリポジトリとのやりとりが可能になる
  • 慣習として「origin」と命名する
# リモートリポジトリへ送信する
$ git push <リモートリポジトリ名> <ブランチ名>

コマンドにエイリアスを付ける

$ git config --global alias.<エイリアス> <コマンド>
  • エイリアス：別名
  • コマンドの入力を短縮することが目的

バージョン管理しないファイルを無視する

「.gitignoreファイル」に無視するものを指定する

# ファイル指定
ignore.txt

# ディレクトリ以下を指定
ignore_dir/

# 拡張子を指定
*.txt

# 無視しないファイルを指定
!index.html

ファイルの変更を取り消す

# 指定したファイルの変更を取り消す
$ git checkout -- <ファイル名>

# 指定したディレクトリにあるファイルの変更を取り消す
$ git checkout -- <ディレクトリ名>

# 全てのファイルの変更を取り消す
$ git checkout -- .

ステージに追加した変更を取り消す

# 指定したファイルの変更をステージから取り消す
$ git reset HEAD <ファイル名>

# 指定したディレクトリにあるファイルの変更をステージから取り消す
$ git reset HEAD <ディレクトリ名>

# 全てのファイルの変更をステージから取り消す
$ git reset HEAD .

直前のコミットを修正する

# ファイルを修正しステージに追加(git add)してから
$ git commit --amend

リモートリポジトリの情報を表示する

# リモートリポジトリ名を表示
$ git remote

# 対応するURLを表示するオプション
$ git remote -v

リモートリポジトリから情報を取得する(フェッチ)

# リモートリポジトリの情報をローカルリポジトリに取得する
$ git fetch

# 指定したリモートリポジトリの情報をローカルリポジトリに取得する
$ git fetch <リモートリポジトリ名>

# 指定したブランチの情報をローカルリポジトリに取得する
$ git fetch <リモートリポジトリ名> <ブランチ名>

# 取得したリモートリポジトリの情報をワークツリーに反映させる
$ git merge <リモートリポジトリ名>/<ブランチ名>

リモートリポジトリから情報を取得する(プル)

# リモートリポジトリの情報をローカルリポジトリに取得してワークツリーに反映させる
$ git pull <リモートリポジトリ名> <ブランチ名>

# コマンドは省略可能
$ git pull

同様の操作を行うコマンド

$ git fetch <リモートリポジトリ名> <ブランチ名>
$ git merge <リモートリポジトリ名>/<ブランチ名>

リモートリポジトリの詳細情報を取得する

$ git remote show <リモートリポジトリ名>

表示される情報

  • fetchとpushのURL
  • リモートブランチ
  • git pullの動き
  • git pushの動き

リモートリポジトリを変更・削除する

# リモートリポジトリを変更する
$ git remote rename <旧リモートリポジトリ名> <新リモートリポジトリ名>

# リモートリポジトリを削除する
$ git remote rm <リモートリポジトリ名>

ブランチを新規追加する

# ブランチを作成する
$ git branch <ブランチ名>

ブランチの一覧を表示する

$ git branch

# リモートリポジトリを含めた全てのブランチを表示するオプション
$ git branch -a

ブランチを切り替える

$ git checkout <既存ブランチ名>

# ブランチを新規作成して切り替える
$ git checkout -b <新ブランチ名>

変更を取り込む(マージ)

$ git merge <ブランチ名>

# リモートリポジトリにあるブランチの変更を取り込む
$ git merge <リモートリポジトリ名/ブランチ名>

ブランチ名を変更する

作業ブランチの名前を変更する
$ git branch -m <ブランチ名>

ブランチを削除する

# maseter(main)にマージされていない変更が残っている場合ブランチを削除しないオプション
$ git branch -d <ブランチ名>

# 強制削除するオプション
$ git branch -D <ブランチ名>

コンフリクトの解決

  • コンフリクト：管理する複数のデータに、重複や競合が発生している状態
  • コンフリクトを起こしたファイルの内容を書き換える
<<<<<<< HEAD
<p>コンフリクト</p>
=======
<p>conflict</p>
>>>>>>> feature

ファイルが表すもの

  • << HEAD　から == が表すもの：HEAD(作業ブランチ)の変更分
  • == から >> feature が表すもの：マージしてきたブランチ(feature)の変更分

変更を取り込む(リベース)

# 親となるコミットを移動して変更を取り込む
$ git rebase <ブランチ名>

マージとの違い

  • マージ：変更内容の履歴(コミット)はそのまま残るが、履歴が複雑化する
  • リベース：履歴は単純になるが、元の変更内容の履歴が消える

タグを付ける

コミットを参照しやすくするために、名前を付ける

# 注釈付きタグ（名前、コメント、署名を付けることができる）
$ git tag -a [タグ名] -m "[メッセージ]"

# 軽量タグ（名前を付けることができる）
$ git tag [タグ名]

# 昔のコミットに後からタグを付ける
$ git tag [タグ名] [コミット名]

# タグのデータを表示する
$ git show [タグ名]

# タグをリモートリポジトリに送信する
$ git push [リモート名] [タグ名]

# タグを一斉に送信する
$ git push origin --tags

作業を一時退避する

作業が途中でコミットしたくないが、別のブランチで作業しないといけない時に使う

$ git stash

# 退避した作業を確認する
$ git stash list

# 退避した作業を復元する（ステージの状況は復元されない）
$ git stash apply

# 特定の作業を復元する（ステージの状況は復元されない）
$ git stash apply [スタッシュ名]

# ステージの状況も復元する
# git stash apply --index

# 退避した作業を削除する
$ git stash drop

# 特定の作業を削除する
$ git stash drop [スタッシュ名]

# 全作業を削除する
$ git stash clear

スクラムによるアジャイル開発の実践記

学部3年次に「ICTを活用するIoT時代のイノベーション人材育成のためのビジネスアプリケーション / システムデザイン実践教育ネットワークenPiT-BizSysD」を修了しました。

bizsysd.enpit.jp

enPiTビジネスシステムデザイン分野(通称:BizSysD)は、社会やビジネスニーズに対する実用的なソリューションとしてのビジネスアプリケーションやシステムデザインを自ら提案、開発し、顧客の潜在的要求を満たすことのできる人材育成を目指します。


私のチームは大学内の渋滞問題を解決するべく、相乗りアプリを作りました。

私が在籍する大学は、学内に大きな池があるせいで橋がかかっていたり、信号機があったりと、全国的に敷地面積が大きい大学です。

そんな大学内は移動がとても大変なので、車やバイクでの移動がほとんどです。

自転車に乗る人もいますが、坂が多いのであまり向きません。

そんな中、車もバイクもないという学生は、移動に大変苦労しています。

こうした学内の移動に苦労している学生の声を元に、このアプリを考案しました。

このアプリは、移動に悩んでいる学生と、それを助けてあげたい学生ドライバーをつなぎます。

このアプリを使うことで、同じ目的地に向かう学生ドライバーを見つけることができ、車やバイクを持っていなくてもスムーズな移動が可能になります。

プロダクトの紹介1

プロダクトの紹介2


このアプリ開発を行う中で、スクラムによるアジャイル開発を学びました。

アジャイル開発とは、小さな単位で動くソフトウエアを作っていく考え方（概念）で、スクラムはその手法の一つです。

スクラムはスクラムマスター1人、プロダクトオーナー1人、複数人の開発者で構成されるチームです。

機敏な開発を行えるための十分な小ささと、作業を完了できる十分な大きさが必要で、一般的に10人以下で構成されます。

スクラムマスター

  • スクラムチームをまとめるリーダー

  • スクラムの理論や活動をチームメンバーに理解してもらえるように支える

プロダクトオーナー

  • プロダクトの価値を最大限に引き出すことを責務とする責任者

  • プロダクトゴールを決定する

  • プロダクトバックログ（プロダクトの改善に必要なものに優先順位をつけたリスト）を作成する

  • プロダクトバックログアイテムを並び替える

開発者

  • プロダクトの価値を生み出し、品質を守り抜く専門家

  • スプリントバックログ（スプリントで行う作業リスト）を作成する

  • スプリントゴールに向けて計画を実行する

スクラムを組み、スプリントと呼ばれる1ヶ月以内の決まった期間に4つのスクラムイベントをこなすことで、「無駄を省き、本質に集中する（リーン思考）」ことができます。

スプリントプランニング
  • スプリントで実行する作業の計画を立てる
デイリースクラム

  • 計画された今後の作業と、スプリントゴールに対する進捗を確認し、必要に応じてスプリントバックログを調整する

  • スプリント期間中は毎日同じ時間に開催する

スプリントレビュー

  • スプリントの成果を確認し、今後の活動を決定する

  • スクラムチームは、ステークホルダー（利害関係者）に成果を示し、プロダクトゴールに対する進捗について議論する

スプリントレトロスペクティブ

  • スクラムチーム内で、今回のスプリントがどのように進んだかを確認する

  • スプリント中にうまくいったこと、発生した問題、そしてそれらの問題がどのように解決されたか、されなかったかについて議論する

  • スクラムチームの効果を高めるために必要な改善点を特定する

私のスクラムチームはスクラムマスター1人、プロダクトオーナー1人、開発者2人の計4人で構成されており、私はプロダクトオーナーを務めました。

大変だったこと
  • 限られた時間の中で、どの機能を優先すべきかを決めること

授業の一環として取り組んだ内容だったので、チームとして定期的に集まれるのは限られていました。

そんな中で、どの機能を実装すればリリースできるかといった線引きが難しかったです。

  • ユーザーの視点になって物事を考え、最大の価値を提供する機能を選ぶこと

ユーザーのニーズを理解し、それらを満たす機能を特定することは困難でした。

相乗りアプリのユーザーは「車を運転する人」と「車に乗せてもらう人」に分かれます。

「車を運転する人」がアプリを利用するメリットを見出すことに苦労しました。

工夫したところ
  • タスク管理ツールTrelloの導入

私はプロダクトオーナーとして、「プロダクトバックログを可視化し、理解しやすくする」ことを意識しました。

可視化と並べ替えのしやすさを考慮して、タスク管理ツールTrelloを導入しました。

活動のほとんどが遠隔だったこともあり、Trelloを導入したことで、コミュニケーションが一段と取りやすくなりました。

タスク管理ツールTrello

  • ユーザーに使ってもらうこと

私の身近に、学内の移動に苦労している学生がいたので、定期的にアプリの使用レビューをしてもらいました。

実際に使ってもらうことでユーザーの需要がわかり、私が考えるユーザーの視点と、実際に使ったユーザーの視点のギャップを埋めることができました。

おわりに

授業の一環で、スクラムによるアジャイル開発を体験しました。

私はこの期間で「振り返りの大切さ」を再認識しました。

授業という細切れの作業時間では、目標に対してどこまで進んでいて、どこから始めないといけないということが把握しにくいです。

そこでスクラムイベントに従ってチーム活動をすることで、意識的に振り返りをすることができ、チームの状況を客観的に見つめ直し、今後の活動の方向や今何をすべきかを明確にすることができました。

もっと実装したかった機能もありましたが、短いスパンで一連の開発工程を繰り返すことで、ユーザーのニーズに対応したプロダクト開発やスクラムチームのコミュニケーションの改善がしやすく、最終的に相乗りアプリとして形になりました。

スクラムが基づくリーン思考はさまざまな領域で活用できるアプローチだと思うので、鍛えていきたいと思います。

enPiT修了証