ProgateのGitインターンに参加した話

インターン概要

プログラミング学習サービス「Progate」を運営しているで有名な株式会社Progateの5daysサマーインターンに参加しました。こちらのインターンはチームで5日間バージョン管理ツール「Git」を開発するインターンです

Day1

予定

10:00 - 12:00 オンボーディング　Git講義
12:00 - 13:00 社員の方と昼食 -> めっちゃうまかった！！
13:00 - 15:00 5日間で使うツール等の説明
15:00 - 19:00 個人でmygit logの実装
19:00 - 21:00 インターン生同士で夜ご飯 -> おかげで仲良くなった！！

学び・気づき

git initコマンドを実行すると/.gitディレクトリ構造が以下のものなるのを知った

.git/
├── HEAD          … 現在チェックアウトしているブランチへの参照
├── config        … このリポジトリ固有の設定ファイル
├── description   … GitWebで使われるリポジトリの説明文
├── index         … ステージングエリア（インデックス）の状態
├── hooks/        … 特定操作の前後に自動実行されるスクリプト置き場
├── info/         … ローカル限定の除外設定などの補助情報
├── objects/      … コミット・ツリー・ブロブなど全データの実体
└── refs/         … ブランチやタグへの参照（ポインタ）

ある程度gitについて理解したと思ってmygit logの実装したが、メンターの人に質問をされたら.... claudeの説明を見て理解していたつもりでgitについて全然理解していなかった 具体的に言うと git addコマンドを実行するとobjects/内にblobオブジェクトが作られるところまでは理解していた。しかし、なぜ40桁のハッシュ値のうち先頭2桁をフォルダ名、残り38桁をファイル名として分割するのかまでは理解が及んでいなかった。宿泊場所に帰ってきて、ホワイトボードを使ってわかったことは以下のとおり

objects\内のオブジェクトが先頭2桁/残り38桁になっている理由 -> もしオブジェクトが多くなったときの探索の効率化のため
git addの段階でindexにblobオブジェクトと階層構造をもっている場合にはパスがステージされるときにはtreeオブジェクトがつくられない
git commitを実行してやっとtreeオブジェクトがindexにあるパスの情報からgitが階層構造を理解しつくられる

Day2

予定

10:00 - 11:00 朝会 (昨日やったこと、わかったこと、困ったことについて共有)
11:00 - 12:00 チームメンバーの発表 (２人チーム <- 自分はここ・３人チームの２チーム構成)
12:00 - 13:00 社員の方と昼食
13:00 - 19:00 designDocの作成と完成

学び・気づき

designDocの作成にあたり、実装中の手戻りをなくすため、先にお互いの意思決定を明確にしておこうとチームに提案した。しかし、いざdesignDocの作成作業にあたると、いくつかの点でチームメンバーと意見が分かれた。

意見が分かれたこと

mygitで実装するコマンドの範囲 mygit add,mygit commit,mygit logを実装することは共通していたが、私はmygit initまで実装しようと考えていたが、メンバーは既存の.git\ディクトリー内で動作するmygitで十分という考えだった。そこでメンターの方からお互いの意見のメリデメをあげていって決めるといいよとアドバイスをもらったので早速オフィス内のホワイトボードを使ってお互いの意見のメリデメを整理し、両方の意見を取り入れる形でmygit initも実装することでお互いが納得した。
mygitにおける共通ロジックのディクトリ内での位置づけプロジェクト内で複数個所から使用する処理を、自分は「再利用される関数」という意味でutils\フォルダ内に置こうとしたが、チームメンバーは「mygitのコア機能となる処理」という意味でcore\に置くべきと考えていた。同じコード・概念を指していても、人によって「それが何のためになっているのか」という捉え方が異なることをメンターの方が議論中に間に入ってお互いの意見を整理して、議論がかみ合ってないことに気づかされた。

この経験から、議論の途中でも適度に立ち止まり「今何について話しているんだっけ？」「そもそも議題・議論の目的は何だったけ？」と俯瞰して第三者の視点を借りる重要性を学んだ。

ホワイトボードで書いた内容

Day 3

予定

10:00 - 10:30 朝会
11:00 - 12:00 実装　＆　チーム別中間発表
12:00 - 13:00 昼食
14:30 - 17:00 インターン生一人ひとりメンターと2on1
13:00 - 19:00 実装

学び・気づき

１日半ほどチーム開発をしてきて感じたことしては、ハッカソンでのチーム開発と、インターン（実務）でのチーム開発の進め方がまったく異なると実感した。

これまで参加したハッカソンでは、「これ作ろう」「この技術を使いたい」「これ面白そう」といった会話の流れでつくるアプリの方針が決まり、そのまま実装に入っていた。これがハッカソンの良いところであって醍醐味でもある。

一方、今回のmygit開発では、たとえば「本家gitのadd・commitコマンドが持つサブオプションをdesignDocで決めた最低限の機能に含めるかどうか」といった議論を重ね、意思決定を１つずつdesignDocに書いていった。ハッカソンのようにスピーディーには進まかった。そして実務では、「ユーザーのことを考える」ことが自分に還元されると思った。そう思った理由は下記のとおりです。（興味がなければスキップしてもOK）

そう思った理由

インターンの5日間という制約もあり、mygitにはサブオプションの実装はしないとチームで決めた。この意思決定を振り返っているうちに、もし仮にmygitをOSSとして公開するとしても、きっと同じ判断をするだろうと自分の中で考えが広がっていった。全部の機能を最初から作り込もうとするのではなく、まず最低限の機能を決めてリリースし、実際に使ったユーザーからあがるissueをもとにブラッシュアップしていく方が現実的だからだ。開発者がいいと思って作り込んだ機能が、実際のユーザーにとってはイマイチということもあり得るからこそ、最初から完璧を目指すのではなく、最低限の機能でリリースしてユーザーの声をベースに改善していく方が、実務での0→1フェーズのプロダクト開発の考え方そのものだと気づいた。このように自分の中で考えを深めていった結果、「ユーザーのことを考える」ということの具体的なイメージにようやく行き着いた。

-> 2on1のときにここまで言語化できなかった悔しい！！

Day 4

予定

10:00 - 10:30 朝会
10:30 - 12:00 実装
12:00 - 13:00 昼食
13:00 - 17:00 実装
17:00 - 17:30 夕会
17:30 - 19:00 実装

学び・気づき

Day4は、自分の課題がめっちゃわかった日でした！昼食後の作業中にメンターの方から声をかけられ、そのままgitの理解度を確認するため別の部屋へ。ホワイトボードを使って「gitについて理解していることを説明して」と言われた。git addを実行するとblobオブジェクトが作られ、パスがindexにステージされるところまでは説明できた。しかし「git addは大きく分けてどういった処理をしているのか」と聞かれた瞬間、私はgitの話ではなく、JSONを例えにした説明を始めてしまった。説明中では自分でも説明が抽象的で、gitに関する知識がまだ浅くて、自信をもって説明できていないと気付いた。振り返ってみると、これまで自分は使ってきた技術についても、実は同じ理解が浅かったんじゃないかと思う。

今後ハッカソンやインターンで開発するときは、自分は使っている技術の裏側ではどのような処理が走っているのかを理解し、そもそもその技術（ライブラリ・フレームワーク）を使う必要があるのかを判断できるようになるために勉強しなおす必要があると思った。

他には、キャリアについての気づきもあった。これまで自分は「エンジニア→テックリード」というキャリアを思い描いていた。技術を磨いてつよつよエンジニアになり、技術力でチームを引っ張っていきたいと思っていた。しかし昼食のとき、社員の方からテックリードとPMの違い、そしてそれぞれに何が求められるのかを聞く機会があった。その話を聞いているうちに、自分はどちらかというとPMとして「プロダクトの価値を最大化し、会社に貢献していく」ことの方が自分に合っているし、私がエンジニアを目指そうした理由と合致していると思った。

Day 5

予定

10:00 - 10:30 朝会
10:30 - 12:00 実装
12:00 - 13:00 昼食
13:00 - 16:00 実装
16:00 - 17:00 チーム別成果発表会
17:00 - 19:00 懇親会

学び・気づき

最終日のため、５日間で自分が学んで・気づいたことをまとめたいと思います。

このインターンを通じて私の大きな課題は「理解が抽象的なままで進んでしまう」ことだと学んだ。このAI時代でのエンジニア学生の多くはそうだと思う。だが、今回のインターンを通じて常にそれが正しいわけではないと思った。技術面での正しい判断やチームへの提案をするときには、自信の裏付けとなる強いバックボーン（知識）が必要だと痛感した。バックボーンがなければ、いくら正しいと思っていても、自信を持って提案することができない。だからこそ、これからはAIに頼るだけではなく自分自身の理解を深め、さらなる「自分の知らない景色を求めて」日々研鑽していきたいと思った。改めて株式会社Progate様この度は貴社のインターンに参加させていただき、本当にありがとうございました！！