この記事は 富士通クラウドテクノロジーズ Advent Calendar 2017 の19日目です。
18日目は @cooさんの
ニフクラの物理ネットワークを支える人たちでした。
ホッテントリ入りしたらしく、プレッシャーがハンパない。
はじめに
自分は入社二年目から三年間に渡ってインターンの運営に携わっており、直近二年は企画から当日運営までをメインで担当しています。
今回は、主に直近二年間の内容を中心に、やったこと・工夫・感じたことなんかを書いていこうと思います。
タイトルは「FJCTの」となっていますが、昨年度以前は「ニフティの」と読み替えてください。
また、ここでいう「インターン」とは５日間でアイデアソンから開発までを実施するハッカソンに近い形式のもので、実業務を行う就業インターンではありません。
※それインターンじゃないじゃんというツッコミは本記事では受け付けません。
就業インターンは別途受け入れています。
2015年までのインターン
開発の5daysインターンは2012年から毎年開催されています。
毎年マイナーチェンジされてはいましたが、2012~2015インターン内容をざっくり説明すると以下の感じでした。
- 参加学生は40名程度、1チーム4名前後
- 5日間でアイデアソンから実装までやって発表する
- メンターは会場常駐1~2名＋定期的に見回り
- 昼休みなどには社員のLTをしたり、一緒にご飯を食べたりする
- 原則、弊社のクラウドサービスを活用する(2012、2013: ニフクラ C4SA、2014、2015: ニフクラ mobile backend )
当時の人事を含めた企画者の目的としては以下の観点が強かったように思います。
- 会社の雰囲気の良さ・社員の良さを知ってもらう
- 自社サービスの宣伝・UX調査
- 初心者にもものづくりの楽しさを知ってもらう
課題
2015年までの形式でも、発表までに各チーム動くものをちゃんと仕上げており、イベントとしては概ね上手くいっていました。
会社の良さを知ってもらうという点でも、社員の雰囲気を知ってもらうような役割も十分果たしていたように思います。
（自分も2012に学生としてインターンに参加しており、こういった部分が決め手の一つとなって入社しました。）
一方、以下のような課題・疑問もありました。
メンターの動員が大変
手続き系をやってくれる人事の方々の他に、メンターとしてチーム数＋αのエンジニアを動員する必要がありました。
(チーム：メンター一対一ではなく、2~3人で2~3チームを担当してまとめて見る感じでした。)
ただでさえ業務にアドオンで対応するのに、動員人数が多いと元々忙しい人にもお願いすることになります。
そうなると、全員一日一回以上は会場を見回るようなシフトを組んでいても、急用で見回りが全然できないというメンターが毎年出てしまいました。
メンターとの交流密度は満足度と相関が強く、忙しいメンターが当たったチームには満足してもらえないという状況でした。
業務についての理解が深まらない
これは実業務に触れてもらえていないので当然なんですが、事後アンケートでの「仕事のイメージができたか」という項目の評価が芳しくなく、フリーフォーマット欄でも「もっと仕事内容を体験したかった」といった意見が毎年ありました。
会場もセミナールームを使っており、執務エリアへの入室は社内見学の10分程度しかなかったので、働いている様子もあまり分からなかったと思います。
技術力の高い学生が楽しめていない場合がある
個人的にはここが一番課題だと思っていた部分です。
40名も参加してもらうと参加者の技術力にもかなりの幅が出るので、チーム分けの際に開発できない学生が偏らないようバランスを取ると、良くできる:少しできる:開発初心者、が大体 1:2:1 みたいな構成になります。
そうすると、できる学生が開発初心者のフォローに回ってしまったり、発表直前に分担以外の未完成部分まですべて背負うことになってしまったりと、できる学生が言い方悪いですが割りを食うようなことになることがたびたびありました。
この場合、開発初心者にとっては動くモノを作った成功体験になるんですが、できる学生にとっては思うように開発できなかったり、ただただ体力的に辛かった体験になってしまい、いざ就職活動シーズンに入ると、開発できていた学生はあまり受けてくれず、自信をつけた開発初心者がエンジニア志望で受けてくれるけどレベル不足でマネージャー面接で落とされるという、会社・学生両者にとって残念な状況になっていました。(優秀かつ入社してくれた後輩もたくさんいますが。)
2016年度インターン
この年から私が一から企画を立ててやっている内容になります。
私がインターンの企画を担当することになったきっかけは、人事から「今年はIoTテーマでインターンをしたい」という相談を受けたことでした。
私は IoTデザインセンター というサービスを展開している部署に所属しているので、前年度メンターだったこともあって一次相談がきたのでしょう。
聞いたときの最初の感想は「いや、無理」だったのを覚えています。
理由は無数にあるのですが、主なものを挙げると
- ハードの準備が大変
- 作られ得るものの幅が広すぎてフォローしきれない
- ハード面のメンターをできるメンバーが少ない
- IoTは必要な技術の幅が広い
- ハードウェアはデバッグが難しくハマる可能性が高い
- 発表できるレベルで動くものを作るハードルがアプリ単体よりも格段に高い
- 実施が8月末なのに相談時点で6月に入ろうとしていた
- しかも告知開始は6月中旬
そんなわけで最初はやらない方向に持っていこうと仕向けてたんですが、気づいたらなし崩し的にやることになっていて、既成事実的に自分がリーダーみたいになっていました。
この辺の経緯は良く覚えていないですが、人事の協力を取り付ける力は怖いですね。
どうしたらいいかということでエンジニアチームで相談した結論として、
- このテーマを中途半端に人事に任せると当日自分たちが死ぬ
- どうせやるなら現場エンジニアがやりたいようにやろう
ということで、形式を大きく変えることにしました。
やったこと
少人数制
思い切って募集を15名まで絞りました。
認知度向上という点では効果減の懸念はありましたが、それよりも
- レベルの高い学生に思いっきり開発してもらいたい
- ハード準備の費用面
- メンターの確保
- コミュニケーション密度の向上
といった点を考えて決断しました。
また、1チームの人数も4名から3名にしました。
執務エリア内での実施
5日間で実業務をやってもらうのは無理だと判断したので、せめて業務中の様子が見られる環境に出入りできるようにしようということで提案しました。
ここは人事の担当者にかなり頑張っていただいて実現しました。
学生向けのネットワーク敷設、社内用PCの払い出し、周辺座席の社員への周知など、各方面への調整大変だったと思います。
アイデアソンの方針変更
それまでは自由に作りたいものを作ってもらっていたんですが、プロダクトの価値について考えてもらうようなワークスタイルに変更しました。
これには主に二つの意図がありました。
一つは、少しでも業務に近い考え方を経験してもらおうということ。
二つ目は、最終発表時の評価軸を単純な派手さや面白さよりもちゃんとサービスについてアイデアを練っているか、それを技術で実現できているかという観点に寄せていきたいということでした。
スクラム講座の導入
チーム開発のやり方として、スクラムのプラクティスを取り入れた講座を行うようにしました。
それまでもカンバンの活用やユーザーストーリーの書き方なんかはやっていたんですが、デイリースクラム(朝会)や夕方のレビュー(夕会)も取り入れて、一日一スプリントなイメージで進めるように設計をしました。
また、それぞれのセレモニーについて、なぜそういう風にやるのか、背景にどういった考えや経験則があるのかを細かく説明するようにしました。
1チーム1メンター
各チームに1名、固定で担当のメンターを入れて5日間の朝会・夕会を中心に継続してフォローしてもらうようにしました。
その他
- Slackの導入
- 社内Slackにサポート用のチャネルを作成し、参加学生を招待しました。
- Gitの事前学習のお願い
- クラウド環境の事前払い出し
- 当日はとにかく時間がないので、サーバの立て方やコントロールパネルの使い方を事前に確認できるようにアカウントを事前に払い出しました。
- チーム担当以外のメンター
- デバイスの準備
当日の様子
IoTLT vol.19で発表してきた資料があるので、当日の写真なんかはこちらでご確認ください。
(分社前の社名やサービスロゴなんかが入っているのはご愛敬。)
良かったこと
少人数制
狙いが全体的に上手くいき、特に参加者のレベルの担保とコミュニケーション密度の2点は想像以上でした。
チーム人数を3名に減らしても例年と同等以上のアウトプットがありましたし、人数が少ないことで全員の顔が認識でき、社員対学生だけでなくチーム同士・学生同士の交流も活発に行われて一体感があったように思います。
1チーム1メンター
朝会・夕会に参加してもらうことで、それまでのコンテキストを理解したサポートが行えていたのが良かったです。
困ったらとりあえず相談する人が明確になったのも良かったように見えました。
良くなかったこと
事前課題
これはフォローが足りなかったのもありますが、オーバースペックなサーバーを立てたり、ファイアウォール全空きで放置したりとトラブル多発でした。
テキストでガイドラインを用意するだけではダメなんだなと痛感しました。
また、Gitの学習も習得度が悪かったです。
個人で少しコマンドを触った程度では、普段他人とコードを共有しない学生にはありがたさが分かりにくいらしく、当日リポジトリを有効活用できたチームは少なかったです。
デバイスの準備
想定はしていましたが、用意したデバイスではやりたいことができないチームが発生してしまいました。
Iotチームが保有していたもので代用してもらってなんとか開発はしてもらえましたが、本人たちがやりたいことを100%させてあげられなかったのはやはり無念でした。
また、目玉デバイスは思ったより使われず、IoTチームのおもちゃ箱に吸収されていきました。
執務エリアでの開発
執務エリアでは社内用のPCを使わなければならず、しかもそれがWindows機だったため、開発環境の立て直しのコストを嫌った学生が社外エリアで開発するようになり、結局最終日には全チームが執務エリアに入ってこなくなるという事態になりました。
また、働いている様子が見られたのはある程度参考にはなったようですが、やはりそこで何が行われてるかが分からないと根本的な満足度向上にはつながりませんでした。
社内Slackの利用
社内Slackを使ったために学生が使うチャネルを自由に作成できず、みんな投稿を遠慮してしまってあまり活用されませんでした。
また、人事からの重要連絡はメール、事前学習はfacebookグループ、当日の開発サポートはSlackと連絡手段が分散してしまい、情報を追うのが大変だと学生から苦情が多発しました。
スクラム講座
これはほぼ個人の反省なんですが、6月に認定スクラムマスターの資格を取ったばかりで、学んだことを活かしたくて色々詰め込みすぎました。
やはり1日で1スプリントは無理でした。
セレモニーでやることも多すぎて、メンターでさえ何をどこまでやればいいか把握しきれず、不完全燃焼なまま5日間がすぎました。
2016所感
色々と至らない点はありましたが、エンジニアが2週間でコンセプト固めたにしては上々の内容だったと思います。
また、参加学生も個性派揃いで、こちらにとっても大変刺激的な5日間でした。
そんな学生たちにも楽しんでいただけた＋会社に興味をもってもらえたようで、結果として参加者15名のうち3名が2018入社予定となっています。
進学した学生や、就職学年ではない学生もいた中でのこの数字は、会社の良さを存分に伝えられた結果なのかなと思います。
※ 念のため言っておきますが、インターンに参加すると優先的に推薦枠がもらえたりとかのおかしなバイアスはかかってません。
また、個人的には空回りした感しかないスクラム開発ですが、そもそもチーム開発経験のある学生が少なかったようで、アンケートで「チーム開発を経験できたのが良かった」「アジャイル開発のやり方が勉強になった」といった声が結構多かったのが救いです。
カンバンとか付箋使ってワイワイ開発するの楽しいよね。Doneにペタペタ移動させてくの気持ちいいよね。
2017年度インターン
正直に言ってしまうと、今年度の春先は分社のゴタゴタでインターンの企画どころじゃなかったんですが、またやるなら早々に告知を出さねばならないということで、ベースは2016年度のまま、微調整して今年も実施することにしました。
社員数が半分以下になった状態でよく開催に倒したなと思います。いい意味で。
主な修正点
事前課題
マニュアルを用意しました。
また、配布したアカウントに監視を入れ、おかしな使われ方をされればすぐに連絡ができるようにしました。
(優秀な後輩が全部やってくれた。)
お小遣い制の導入
前回のデバイス不足の反省から、各チームに予算を設定し、その中で自由に買い物ができるようにしました。
DMM.make AKIBAの利用
アイデアが決まる二日目の会場をDMM.make AKIBAにすることで、デバイス調達をしやすいようにしました。
DMM.make AKIBAはDMM Open Challenge のサポート企業としてよく出入りさせていただいていたので、その伝手でイベント利用担当の方にご相談させていただきました。
(もちろん正価でお借りしました。)
執務エリア利用の廃止
労力と効果が見合わなかったのでやめました。
社員LT枠の拡大
社内に入れなくなった代わりに、社員のLTの数を多くすることで仕事のイメージを深めてもらえるようにしました。
5日間全部で10枠+Iot部門の講演ぐらいやったと思います。
デザイン思考ワークショップの導入
当時IoTデザインセンターの支援内容としてデザイン思考ワークショップというものを積極的にやっていたので、担当メンバーにお願いしてアイデアソンにデザイン思考のエッセンスを取り入れてもらいました。
その流れで講師までお願いしました。
スクラム講座 → アジャイル講座
一年経って短期間の開発に適用できるプラクティスとそうでないものの整理がついたので、短期開発向けにちゃんとチューニングをしました。
もはやスクラムのフレームからは完全に外れていたので、名前もアジャイル講座に改めました。
社外Slackの利用
前年は社内Slackを使っていましたが、「そもそも社内でやる意味あるんだっけ？」ということでインターン用にSlackチームを作成しました。
これによってチームごとのチャネルや情報発信専用チャネルが作成でき、利便性が向上しました。
最終日の評価項目の事前公開
前年度のフィードバックで、評価基準が分かりにくいという意見があったので、事前学習の段階から基準を公開するようにしました。
詳細は割愛しますが、アイデア面が2項目、技術面が3項目、プレゼンテーションが1項目でそれぞれ5点満点としました。
当日の様子
キャンセルがあり、参加者は14名でした。
3の倍数にならなかったので、3:3:4:4で4チームに振り分けました。
今年は発表とかしてないので、残念ながらまとまった資料とかはありません。
良かった点
基本的に前年度上手くいって今回も継続した施策は同様に上手くいっていたように思います。
ここでは変更点のフォーカスしてピックアップします。
お小遣い制 + 買い出しタイム
作りたいものに合わせて調達ができたのはやはり良かったです。
加えて、買い物という行為自体が楽しかったり、地方からの参加者にとっては秋葉原探検ツアーの側面もあったようでした。
一点失敗点としては、DMM.make AKIBA利用は二日目だけだったため持ち込む機材を最低限に抑えたところ、持ち込んでいなかったArduinoを購入してしまうチームが続出し、そう多くない予算の中では大きな出費をさせてしまいました。
会社には在庫があったので、アナウンスと準備不足でした。
採点基準の事前公開
発表の形式やアピールの方向性がある程度統一されるようになり、比較をしやすくなりました。
特に全チームが簡単ではありましたがビジネスモデルの説明を入れてきたのは大きな変化でした。
そういう話が入ってくると社員としても実業務を絡めたフィードバックがしやすく、学生としても勉強になったのではないかと思います。
また、講評でも他のチームと比べてのGood/Badが説明しやすくなったため、結果にも納得感があったはずです。
アイデア・技術・プレゼンの配点比重も、程よいバランスだったように思います。
良くなかった点
Slackの積極活用
前年度に比べるとかなり改善はされたのですが、期待していたほどの書き込みはありませんでした。
もっと書きやすい雰囲気を作るような工夫が必要だと感じました。
所感
ベースはできるだけ変えずに前年度の課題を改善するようにしたので、全体的にいいところは残しつつ不満は解消した内容にできたと思います。
学生の雰囲気は前年度に比べると穏やかな人が多く、同じようなカリキュラムでも場の空気が前回とはまた違う感じだったのが面白かったです。
穏やかとは言ってもインターンに参加してくる学生の行動力は流石のもので、この5日間で作ったアイデアをブラッシュアップしてMashup AwardsやGUGENに出展するチームもありました。素晴らしい。
さいごに
こうやって振り返ってみると、我ながらよくやってるなーという気持ちもありつつ、なんだかんだで楽しくて好きでやってるんだなというのに改めて気づきました。毎年協力してくれるメンターの皆さんには感謝しかないですね。
興味持って参加してくれる学生の皆さんにも感謝です。このインターンでの経験を活かして、うちの会社に限らず世の中のどこかでエンジニアとして頑張っていってくれたら嬉しい限りです。
他にも「Git慣れしてない学生は大事なキーを世界中にコンニチハさせるから注意しておく」とか「いくら工夫してもそもそも5日じゃ短い」とか、運営する上で悩ましいことや知見なんかもまだまだあるんですが、すでに結構な長さになってしまったので今回は割愛します。
また何か機会があれば。
来年度のインターン
まだ何も考えていないですし、来年も私が担当するかどうかも未定です。
ただ、メイン事業のクラウドインフラの面白さももっとアピールしたいという声が社内から挙がっているので、5日間の来年度テーマとしてなのか別の形式なのかは分かりませんが、そういったインターンも実施されるんじゃないかなという雰囲気は感じています。
補足
本記事では割愛しましたが、5日間の開発インターンの他にも1~2日で行う企画系のインターンも毎年実施しています。
興味がある方はそちらも是非。
20日目は @blue271828さんの「MackerelでゆるいDocker監視」です。
興味のある方が多そうなテーマですね。期待。