「家で調べて、次の出勤日に解決策を持っていく。それでダメだったら、また調べる。その繰り返しでした」
そう話すのは、大学で情報科学を学びながら、当社のインフラコースでインターンを経験し、現在は学生エンジニアとしてアルバイトに従事する馬場 光希さんです。
クロジカのインターンに参加した当初、馬場さんはインフラの知識がほとんどなく、最初の課題では「EC2って何なんだろう」というところから一つずつ調べていました。
そこから約2年。現在は学生チームのリーダーとして、自身の担当業務に加え、他の学生が進めた作業をレビューしたり、学生同士で仕事を引き継げる流れを整えたりするなど、チーム全体の仕事の進め方も見直しています。
インフラについてほとんど知らなかった馬場さんが、実際の仕事の中で何を経験し、分からないことにどう向き合い、仕事の進め方をどう見直してきたのかを聞きました。
クロジカでは、一緒に働くメンバーを募集しています。詳しくは、下記の採用情報をご覧ください。
実務未経験者9割以上｜大学生同士でAI駆動開発とAWSが学べる学生エンジニアを募集
「何言ってるかさっぱり分からない」──大学で感じたギャップとインターン参加
── まず、クロジカのインターンに参加する前のことを教えてください。大学でどんなことを学んでいたんですか？
情報系の学科で、プログラミングや統計などを学んでいました。父がシステムエンジニアをしていたこともあり、パソコンやプログラミングには小さい頃から触れる機会があって、高校時代にも少し触れていました。
大学に入ってからは、C言語のような基本的なプログラミングから、データサイエンスに関わる統計学などを学んでいました。ただ、1、2年生の頃は、僕自身「典型的な自堕落大学生」だったと思います。
授業には出て、高い成績が取れればそれで良いと考えていて、自分から課外活動にどんどん参加するような学生ではなかったですね。
── 学業以外では、個別指導塾で講師をされていたそうですね。
はい。当時の塾は人が少なくて、自分が普段勉強していない科目まで担当することがありました。高校の社会を任されたこともあったんですけど、「いや、やってないよ」と（笑）。
なので、授業で扱う範囲の問題集を先に自分で解いて、必要なことをノートにまとめていました。実際の授業では、それを見ながら教えるような感じです。分からない科目でも、まず自分で予習して、教えられるところまで準備していました。
── エンジニアのインターンを探し始めたきっかけは何だったんでしょうか？
大学3年生のときに研究室へ入ったことが大きかったです。僕の研究室は3年生から入ることができて、その頃に企業との共同研究に関連した取り組みが始まりました。
研究室ではAIに関するテーマを扱うことが多く、共同研究に関連した取り組みでは、AIを活用して社会実装を見据えたものを考え、そのプロトタイプを作るために実際にコードを書いたりしました。そうした中で、大学の授業で知っていたこととのギャップを感じたんです。
それまでは基本的な文法を知っているくらいでしたが、実際の開発ではGitHubを使うなど、それまで知っていたことだけでは進められない場面が出てきました。「何言ってるかさっぱり分からない」みたいな状態でしたね。
「これはまずいな」と思っていたときに、指導してくださっていた方から「インターンをやってみたら」「実際に飛び込んでみるのもいいよ」と言われたんです。
それで、Wantedlyで上から順番にインターンを見ながら応募していました。その中でクロジカを見つけて、「とりあえず行ってみよう」と思いました。
── クロジカにはアプリとインフラのコースがありましたが、なぜ未経験だったインフラを選んだんですか？
アプリ開発で使うような言語は大学の授業でも触れることが多かったので、自分でも勉強を続けられると思っていました。
一方、インフラはそれまで経験したことがなく、自分で環境を用意して試すには費用もかかると思っていました。それなら、インターンでは自分でも勉強できるアプリより、まだ経験のないインフラをやってみようと思ったんです。
知らない言葉も実装方法も、一つずつ調べて腹落ちさせる
── 実際にインフラコースのインターンが始まって、最初はどんな課題に取り組んだんですか？
最初は、AWS上で指定されたルールに沿ってサーバーを構築する課題でした。
ただ、そもそも僕はAWSもEC2も知らなかったので、課題を見たときは「全部知らない単語だな」みたいな状態でした。クラウドサーバーって何だろう、というところから始まっていましたね。
やるべきこと自体は書いてあるんですけど、その指示文に知らない言葉が並んでいるので、まず指示の意味を理解しないと進められないんです。
── 知らない言葉ばかりの状態から、どうやって進めていったんですか？
まず検索して、「EC2って何なんだろう」というところから一つずつ調べていきました。「こういうものなのか」と分かったら、次はどこへアクセスすればいいのかを探す。
そうやって指示を一つずつブレイクダウンして、次に何をすればいいか分かるところまで整理してから手を動かしていました。
実際に作業を進める中で、自分だけではどこを確認すればいいか分からないときは、先輩にも見てもらっていました。
自分では見落としていた箇所について「ここが問題っぽいよ」と教えてもらうことがあって、「そういうところを確認するのか」と気づくことも多かったです。
ただ、理解できていないまま進めてしまうこともありました。よく分からないまま記述を追加して、後になってそれが原因で動かなくなって、「これがあると動かないよ」と指摘されたこともあります。
── 6日間のインターンを終える頃には、クロジカでアルバイトとして続けたいと思っていたんですか？
そうですね。技術を勉強しながらお金ももらえるなら、というのは正直ありました。実際に参加してみると、周りの技術レベルが高いと感じて、「ここにいたらスキルアップできるな」と思ったんです。なので、アルバイトとして続けたい気持ちはありました。
ただ、課題自体は全然進められなかった感覚があって、インターンが終わったときは「このままアルバイトとして働くのは難しいだろうな」と思っていました（笑）。
── 実際にはアルバイトとして働くことになったんですよね。その後、インターンのときと比べて仕事の進め方は変わりましたか？
そうですね。アルバイトになってからは、サーバーが必要な設定条件を満たしているかを確認するためのテストツールの開発に関わりました。
テストケースごとに「この条件を満たせるようなコードを書いてください」と求められるんですけど、インターンの課題のように、細かい手順に沿って進めるというよりは、その条件をどう実装するかを自分で考える必要がありました。
当時は知らない言語やライブラリもあって、「分からんよ」と思いながらやっていましたね。
家に帰って、そもそもどういうライブラリを使っているのかを調べて、「ああ、こういうことだったのか」と理解して、次の出勤日に解決策を持っていく。でも、実際に試したら全然使えなくて、また帰って調べる。そういうことを繰り返していました。
「動けばいい」だけではなかった──レビューで初めて見えた仕事の基準
── 実装したコードは、どのように確認してもらっていたんですか？
作ったものは、技術力の高い社員の方にレビューをお願いしていました。
最初の頃は、その方にレビューをお願いするのが不安で怖かったですね。普段あまり話す機会もなかったので、自分でも「ちゃんと要件を満たせているのかな」と思いながら、ドキドキして送っていました。
── 実際にレビューに出すと、どんな指摘が返ってきたんですか？
実装の方向そのものが違うと指摘されて、レビューを受けて初めて「そういうことだったのか」と分かることもありました。
それだけではなくて、「この条件だと危ない可能性があるよ」と指摘されることもありました。コードが動くかどうかだけではなく、条件によってどんなリスクが生まれるのかまで確認されていたんです。
── 当時の馬場さん自身は、コードを書くときにどこまで考えていたんでしょうか？
最初は、「動けばいい」という考え方でしたね。
正常に動けば、とりあえずそれでいいと思っていました。なので、条件によってどういうエラーが起こるのかとか、どういう危ない状態になり得るのかまでは、あまり考えていなかったです。
レビューでそういうところを指摘されて、「そこまで考えるんだ」「考えたことなかったな」と思いました。
── レビューを受ける中で、コードが動くかどうか以外に意識するようになったことはありましたか？
考え方そのものが変わったと思います。
例えば、名前の入力を判定する処理を書いたとき、最初は想定した名前が入っていればOKという条件を書いていました。でもレビューで、「間にスペースが入ったり、後ろに余計な文字が入ったらどうするのか」と指摘をいただいたんです。
そこで、自分が想定した通りに動くかだけではなく、実際に使う人がどう使うのかまで考えないといけないんだと思いました。その経験を踏まえて、実際の案件でプロトタイプを作るときにも、自分目線だけではなく、「お客さん目線で見る」ことを意識するようになりましたね。
自分だけ分かっていても、チームの仕事は回らない──学生が増えて始まった試行錯誤
── その後、馬場さんは学生チームのリーダーを任されることになったんですよね。
そうですね。当時は学生メンバーもまだ少なかったんです。
その後、チームの体制が変わる中で新しく学生リーダーが必要になって、僕が任されることになりました。
僕自身、責任のあることを任されるとワクワクするタイプなので、リーダーを任されたのはうれしかったですね。
── リーダーになったことで、仕事の仕方は変わったんですか？
リーダーになった直後は、そこまで変わらなかったですね。それまで担当していた仕事もそのまま続けていました。
大きく変わったのは、新しい学生が入ってきたときです。それまでは、以前から一緒に仕事をしていた学生と、基本的には二人でDMを中心に仕事を進めていました。そのため、複数人で仕事を進めるためのコミュニケーションの流れ自体がなかったんです。
そんな状況で新しい人が入ってきて、一人ずつプロジェクトを説明したり、作業内容や進捗を記録する作業管理ツール上の「チケット」を見て回ったりする必要が出てきました。当時は本当に「組織として動く基盤がゼロだった」という状態でした。
── 「組織として動く基盤がゼロ」という状態で、まず何から考え始めたんですか？
そもそも組織をどう動かせばいいのかも分からなかったので、「組織ってどうやって動いてるんだろう」と思って、エンジニアの組織づくりに関する本を読みました。
大企業の組織について調べてみたんですけど、複雑すぎてよく分からなくて。それで、立ち上がったばかりのベンチャー企業の組織なども参考にしながら、「引き継ぎが大事なんだな」といったことを勉強していました。
誰かから「こうしてください」と方法を教えてもらったわけではなかったので、知らない領域をまた一から調べている感じでした。でも、それはそれで面白かったですね。「組織ってすごいな」と思いながら、引き継ぎの仕方や仕事の受け渡し方を考えていました。
── 実際に複数人で仕事を進めるときは、最初はどんな形で始めたんですか？
新しく入った人が、いきなり社員の方へレビューを出すのは怖いだろうと思って、「僕に1回投げていいよ」と伝えていました。
最初は、とりあえず僕が仲介人になって、仕事を受け渡せるようにしようと考えていたんです。
── 実際にそのやり方で進めてみて、うまくいかなかったこともありましたか？
結構ありました。
全員の作業を一度僕に集めるようにしていたので、次に出勤したときにレビューなどの通知が20件くらいたまっていることがありました。
それに、僕自身が「これができたらOK」というゴールを明確に伝えられていなかったこともありました。気づいたときには、想定と全然違う方向へ進んでいるものが4、5個あって、まとめて差し戻さないといけなくなったこともあります。
「もっと早く気づけていたら、もっと早く修正できたのに」と思いましたね。
── そこから、仕事の進め方をどう変えたんですか？
まずは、「これができたらOKです」というゴールを明確にするようにしました。
あとは、作業している学生同士で一度レビューしてもらって、そこで共通認識を作ってから僕に渡してもらうようにしました。できるだけ、僕が最後に見たときにゴーサインを出せる状態まで持ってきてもらおうと考えたんです。
他には、チケットの使い方も変えましたね。
結果だけ「これ見てください」と渡されると、「どこで何がどうなったんだ」となってしまいます。だから、どういう作業をして、どう考えてそこに至ったのかをメモとして残してもらうようにしました。
きれいに書かなくてもよくて、「何これ、全然分かんねえ」みたいなことを書いてもいい。そういう途中の考えが残っていれば、「ここで考え方がズレたんだな」と分かるので、そこから一緒に見直せるんです。
── チームで仕事を進めるための流れを整える一方で、一人ひとりとの関わり方で意識していることはありますか？
最初は、めっちゃご飯に誘います（笑）。
まずは「馬場 光希という人間」を知ってもらおうと思っているんです。なので、食事だけではなくて、普段から自分から挨拶したり、話したりするようにもしています。
仕事で分からなくなっているときは、横に座って「どうしてこうしたの？」と聞くこともあります。そこで僕がすぐ答えを言うというより、本人に「こういう処理があるから、こうしました」と説明してもらうんです。
話している途中で、「でも、ここってこうじゃない？」と聞くと、自分で「あ、ここがおかしいのか」と気づくことがある。ラバーダックデバッグみたいに、考えていることを言葉にしてもらいながら、できるだけ本人が自分で問題に気づけるようにすることを意識していますね。
「管理しすぎているかもしれない」──今も答えの出ていない仕事
── 学生が増えて、仕事の進め方もかなり仕組み化されてきたんですね。今はどんな形でチームを見ているんですか？
今は学生の人数も増えていて、僕自身も担当しているプロジェクトがあるので、全員の仕事を一つずつ直接見るのは難しくなっています。
なので、プロジェクトごとにリーダーとサブリーダーを置いて、プロジェクトが終わったら、次はサブリーダーだった人がリーダー役を引き継ぐような流れを作っています。
できるだけ、僕が毎回声をかけなくても次の仕事へ進めるようにしていった感じですね。
── そうやって仕組み化を進めてきた今のチームについて、馬場さん自身はどう感じていますか？
仕事自体は、前より進めやすくなっていると思います。
ただ、自分の中では「良くも悪くも自動化されつつある」という感覚もあって。仕組みを作っていくうちに、「自由がなくなってるな」と感じるようになったんです。
── 「自由がなくなっている」というのは、どういう部分で感じるんですか？
学生チームだからこそ、いろいろなことを試行錯誤したり、「こんなツールがあったんですけど、面白くないですか」と新しいものを持ってきたりできるところは残したいと思っています。
実際、今は仕事自体は管理できていて、うまく進んでいると思います。ただ、進め方をシステマティックにしていく中で、そういう新しいものを試したり、提案したりする余地が少なくなっている感覚もあるんです。
例えば、技術の選び方をあらかじめ決めれば仕事は進めやすくなります。一方で、「こういうものを見つけました」と学生が持ってきても、取り入れにくくなることがあるんです。
そうやって仕組みを決めていくことで、学生が自分たちで試行錯誤する余地まで小さくなっていないか、というのは考えていますね。
そういう意味で、ちょっと管理しすぎてるっていう感覚は結構ありますね。
── そうした試行錯誤の余地を残したいと考えるようになった背景には、馬場さん自身の経験もあるんですか？
そうですね。僕が入った頃はまだ学生も少なくて、今のように「1カ月で一つプロジェクトを終わらせる」といった目標もありませんでした。プロジェクトを進めることよりも、「まずは開発を頑張ろう」という感じだったんです。
その頃は、新しい技術やツールを知ったら自分で調べて、実際に触って試す余地がありました。分からなくても、とりあえず試してみる。うまくいかなかったら、またやり直す。そうやって自分で試行錯誤する中で知識が深まった経験が、今の考え方のルーツになっていると思います。
今は学生の人数も増えて、「1カ月で一つプロジェクトを終わらせる」「1カ月に1本は記事を出す」といった目標があります。そうすると、プロジェクトを進めるために、例えばみんなが使い慣れていてレビューもしやすいPythonを選ぶ、といった判断も必要になってくるんです。
もちろん仕事を進めるためには必要なんですけど、僕自身がそうやって試行錯誤する中で学んできたからこそ、今の学生にも、そうした試行錯誤の余地は残したいと思っています。
── 一方で、試行錯誤できる余地を広げれば、それで解決するわけでもないんですよね。
そうですね。使う技術や進め方の自由度を高くしすぎると、プロジェクトを見る側が確認しないといけない範囲が広がります。それに、想定していない方向へ進んで、余計に時間がかかることもある。そうすると、プロジェクト自体がペンディングになってしまうこともあるんです。
だから、仕事を進めるためにはある程度制限を設ける必要がある。でも、制限しすぎると、今度は学生が試行錯誤する余地が小さくなる。
そのバランスをどうするかは、今も答えが出ていないんです。どうしたらいいかは、今の課題ですね。
── 最後に、今後、学生チームをどんなふうにしていきたいと考えていますか？
学生が担当できる仕事の範囲は、少しずつ広げていきたいと思っています。もちろん、学生が触れられる範囲には制限があるのが大前提です。
あとは、僕が毎回見なくても、学生同士で自立して仕事を進められるような組織にしていきたいですね。
一方で、さっき話したように、学生だからこそ試行錯誤できる余地も残していきたいと思っています。
── 馬場さん、本日はありがとうございました！
クロジカでは、一緒に働くメンバーを募集しています。詳しくは、下記の採用情報をご覧ください。
実務未経験者9割以上｜大学生同士でAI駆動開発とAWSが学べる学生エンジニアを募集
