こんにちは。id:tomoz6o9 です。 大阪開発拠点の所属のソフトウェアエンジニアで、普段はfreeeプロジェクト管理というプロダクトの開発を行っています。最近はマネジメント寄りの役割を担うことが多いです。
freeeでは例年夏にサマーインターンを2週間ほどで実施をしています。今年は例年通りのサマーインターンに加えて、弊社でも初の取り組みとなる「プログラミング未経験者」に向けたサマーインターンという2種類のサマーインターンが実施されました。Wantedlyにも実施報告の記事が書かれています。
www.wantedly.com www.wantedly.com
私の所属しているfreeeプロジェクト管理の開発チームでは通常のサマーインターンを2名、未経験者サマーインターンで5名と、どちらのインターンでも学生を迎え入れたので、数あるチームの中であくまで一例ではございますが、実際にインターンに来ていただいた学生さんたちにどのようなことをやっていただいたのかを担当チームの立場からご紹介できればと思います。
前期サマーインターン(プログラミング経験者向け)
このサマーインターンでは計13名の受入をし、基本的に様々なチームに1名ないしは2名でバラバラに配属されインターンが行われました。 プロジェクト管理チームでは2名の受入をしました。 せっかく2人できていただいたので、別々に課題をするのももったいないというところで、2人で一緒に課題に取り組んでもらいました。
「一覧」ページを改善する
この課題の選定にあたっては、以下のような点を意識しました。
- 折角のサービスのコードベースを触ってもらう機会、「ここだけみてれば解決する」ようなスコープの狭い課題にならないようにしたい。
- 合わせて、広い範囲を触ってもらう過程で様々な機能に触れ、サービス全体としてどのようなものであるかを知ってもらいたい。
- 使ってくださっているユーザーのことが思い浮かぶような課題にしたい。具体的な使い方を思い浮かべて、どのようにすれば価値が届くかを考える経験をしてもらいたい。
そうして選んだ課題が、Webアプリを触っているとよく見るいわゆる「一覧」ページにこれまで実は表示されなかった「全部で何件あるか」という情報を追加してもらうというものです。
サービス内にはたくさんの一覧ページがサービス内には存在していますが、今回は以下のようなことをインターン生2人で調べたり、話し合ったりするところから始めてもらいました。
- どれだけの一覧ページがあるか
- そのそれぞれでどのような全件表示をするのが望ましいか
- それらの全件表示を対応していく優先度はどうか
つまり、「事前の影響調査」「具体的なユースケースの想定」「優先度を決めてやる/やらないのラインを決める」という部分を議論していただきながら自分たちで実装まで進めてもらいました。
「具体的なユースケースの想定」では、その画面が何の機能に紐づくものであるか、そしてそれらはどのように使われているかを把握し、その上で今足りていない要素は何かを考えることが必要になります。 また優先度に関しても、気持ちとしては「全部やらないと!」という考えになりがちなところですが、短期インターンという限られた時間を考えると全てをやりきるのは現実的ではないこともしばしばです。その中でもユーザーへのインパクトという軸でしっかり考えて優先度をつけることは、限られた時間の中で成果を最大化するための非常に重要なポイントだと考えています。
後期サマーインターン(プログラミング未経験者向け)
今回はじめての試みとなる「未経験者」という枠は、エンジニアリング暦・(アルバイト等の)実務経験の有無などを基準にしました。 そのような経緯のためインターン生の知識量もまちまちだったので、初日に全体で簡単な座学を実施していただきました。
この講義は実際にWebページを操作しながら、その動作を一つ一つ観察し、その裏でどのようにサービスが動作しているかを確認していくというものです。
この後各チームに分かれ作業を行いました。今年はモバイルチームで4名、freeeプロジェクト管理のチームで5名のインターン生を受け入れました。
弟子入りスタイルでのインターン実施
(以降は私が担当したプロジェクト管理チームでのお話になります。) 未経験者対象、かつ実質本題にに費やせるのは1週間程度という比較的短めな期間だったため、何をやってもらうかは非常に迷いどころでした。
そこで、「弟子入り」スタイルで課題に取り組んでもらいました。 これは1〜2人のインターン生に対して「師匠」となる社員を一人アサインし、いわゆるメンターという立場を超えて、常に一緒に仕事してもらうというやり方です。
特に今回は、ロードマップの開発とは別に定期的に実施している改善系のタスクや要望などに対応していくというプロセスに一緒に参画してもらうことにしました。
「弟子入り」というと、ちょっと上下関係感がありますが、単にアドバイスする/されるという関係ではなく、一緒にワイワイ作業などをできればいいなという思いでこの方法を選択しました。
実際には3チームに別れての実施となりましたが、今回はそれぞれのチームで別のテーマをすえて実施しました。実際に各チームがどのようなことをやったのかをご紹介します。
課題の内容
チーム1: Webサービスの開発を知る
このチームではエンジニアとしてWebサービスを開発というものが一体どういったものであるかを知るということを中心に進めていきました。すなわち、Webサービスが「正しく」動作するとはどういうことなのか、またそのような「正しく動く」アプリを作るとはどうすればいいのかいうことを実際に開発フローに沿って体験してもらうことで進めていきました。
具体的には、freeeプロジェクト管理に対しUI上の使い勝手の改善の余地があるポイントを伝えた上で、今なぜこうなっているのか、どのようにプログラム変更することでそれがクリアできるのかをモブプロ形式でドライバー・ナビゲーターを交代しながら実施し、結果数点の改善を達成させることができました。この最中にはコードを書いていくためのポイント、動作確認とレビューの進め方なども含まれており、チームでWebサービス開発を行っていく流れが体験できたはずです。
また課題を実施する中で、「テストコードを書く」ことの重要さや、プログラミングにおける設計の話、またちょっと毛色を変えてfreeeが組織的に取り組んでいる「アクセシビリティ」についてなど、アプリケーション開発を取り巻く様々なトピックにも触れ、その世界の広さ・面白さを体験していただけたのではないかなと思います。
チーム2: APIを知る
我々が普段使うWebサービスが、他のサービスとは相互に連携し合っていることも珍しくありません。それはfreeeのプロダクトにおいても例外でありません。 freeeではPublicに公開しているAPIがあり、APIを活用した外部サービス連携を強化し、APIエコノミー形成を目指しています。 また一方で、我々もまた他サービスの公開されてるAPIを利用してより便利にプロダクトを使っていただけるような機能も作っています。(Googleカレンダー連携など)。 このチームではそのような内外のAPIに焦点をあて、そもそも連携がどのように実現されているのかも含めて体験していただき、その改善を行ってもらいました。
「APIって何?」という状態からのスタートでしたが、実例として「郵便番号を渡すとJSON形式で住所を返すAPI」を題材に、APIがあるとどんなメリットが有るのかを理解し、その重要性を理解できるように進めていきました
ゴールは既に公開されているPublic APIの改良でしたが、手を加えることをで何が良くなるのかインターン生に考えてもらい実装しました。PostmanというAPIを叩くツールを使って動きを確認しながらAPIに手を加えました。 また実装の変更だけではなく、その定義を示すドキュメントであるOpen APIのファイルの変更も行ってもらいました。
修正したのは小さな改善ではありますが、開発する上で必要な基礎知識や、問題解消までのアプローチ、コードの意図や背景を読み解く方法を伝え、この改善がどんな価値を提供するのか考えてもらうことで、チュートリアルでは味わえない開発の現場の空気感を味わってもらえたのではと思います。
チーム3: ユーザーを知る
このチームでは、実際にプロダクトを使っているユーザーさんから寄せられた要望である「エクスポート機能」の改善に取り組みました。 この開発はボリュームそのものは大きくありませんがプロダクト開発の楽しさをいろんな角度から感じることができる内容だったと思います。
一口に要望といっても、単に要望をそのまま実現することが要望実現ではありません。
ユーザーさんはその機能を使って業務を回しています。 その業務を正しく理解した上で要望の本質を捉え、解決方針が真にユーザーの業務を改善しているかどうかを見極める必要があります。個人的にはこういうところがBtoBのプロダクト開発の醍醐味だと思っています。
このチームでは、その「要望」に対して「解決方針」を議論することから始めました。 実際に想定されるユーザーの業務やユースケースを考え、実際に自分の手で同じことを試行し、どのように改善すべきかを考えました。 その上でPM(仕様とかを決めている人)への提案、さらなるディスカッションを経て実際に開発をします。
実際にはサマーインターンが終了した後になってしまいましたが、この際の改善はきちんとユーザーに届けられました。
他のチームとは少し毛色こそ違いますが、これもまたプロダクト開発の重要な側面をしっかり感じていただけたのではないかなと思います。補足
技術的にはどのようなことをやったの?
内容の説明が結構コンテンツによっていて、技術的にどんなことをやったの?という疑問を持たれる方がいらっしゃるかもしれませんね。 技術的には、まさに動いている我々のプロダクトのコードベースに対して作業してもらったので、freeeの典型的な技術スタックを触ってもらったという状況です。 freeeプロジェクト管理では、バックエンドにruby on rails, フロントエンドにはReact/Typescriptを採用しています。
実際リモートでのインターンってどんな感じ?
今回はリモートでの実施となったサマーインターンですが、会議等はGoogle Meetで行いつつ、日常の作業はSlackで、通話が必要な際はSlack huddleを利用してコミュニケーションをとりつつ実施していきました。
特にモブプロをするようなシチュエーションでは、VSCode LiveShareを利用していました。これは、我々としても日常的にモブプロなどで利用していることもあり、ほとんど問題なく開発を進めていけました。
まとめ
いずれのサマーインターンも一貫して、「現場だからこそできる」「freeeだからこそできる」学びを提供できたらいいなという思いでそれぞれの課題設定をしました。 実際、プログラミング学習とその実務との間には、特にプログラミング以外の部分に関して(例えば仕様を決めていくプロセスなど)、ギャップがありどんなものかの想像もつきづらく、エンジニアになることへの不安になったりすることもあるかと思います。 このインターンの取り組みで、実際の現場を体感したことにより、一層「エンジニアになる」ということの具体的なイメージを持ってもらえたならいいなと思っております。
23新卒採用のエントリーも開始しています!
サマーインターンは終わってしまいましたが、23新卒採用のエントリーが早速開始されています。 以下のような項目にピンとくる仲間を探しています。
- 価値あるプロダクトをつくり、顧客に最速で届けたい方
- 動作の遅いアプリケーションや使いにくいアプリケーションに憤りを感じる方
- ベンチマーキングやパフォーマンスのデバッグが好きな方
- 面倒なことは全部自動的にやってもらいたいと思う方
- 世の中の既存の仕組みに疑問を持つことが多い方
- 常に新しいことに挑戦していたい方
もし興味があれば、是非応募してみてください! jobs.freee.co.jp