皆さんこんにちは。Hazama チームの内田（@uchan_nos）です。
かなり前の話になってしまいますが、サイボウズでは 8/17 から 1 週間、開発系のインターンシッププログラムを実施しました。 アプリ開発や品質保証のコースに加えて インフラコース があったのが、サイボウズのインターンとして初の試みでした。
私が所属する Hazama チームは、サーバの運用管理用のツール（デプロイやモニタリングを行うツール）を作っています。 今年の初めにはデータセンターのフロントエンドを Apache から nginx に切り替えたりもしました（cybozu.com のリバースプロキシを nginx にリプレイス - Cybozu Inside Out | サイボウズエンジニアのブログ）。
インフラコースは Hazama が担当するということで、私が 3 人の学生さんたちのメンターとしてインフラに関する講義をしたり、課題達成に向けてサポートを行うことになりました。 上手くいった点や次回に改善したい点などをご紹介します。
目次
インフラコースでやったこと
インフラコースといっても、ネットワークを配線したり、サーバにログインしてバックアップなどのオペレーションをしてもらうの ではなく、 クラウド環境のソフトウェアを整備するような課題を設定することにしました。 何かと地味な印象のあるインフラですから、その中でも学生さんの興味を引けて、かつ実用になるような ワクワクする課題 を探しました。
最終的に用意した課題は「LXC コンテナを使ってローカル PC 上にミニクラウド環境を作ろう」です。
目指すのは nginx をフロントエンドにして 2 台の AP サーバがロードバランスされるシステムです。 nginx と AP サーバ用のホストマシンはそれぞれ LXC コンテナとして構築し、3 台のコンテナを Linux Bridge で繋ぎます。 インフラコースといってもサイボウズは Web 企業ですし、 AP サーバは学生自身で簡易な Web アプリを作ってもらうことにしました。
そして、このシステムを手動で構築して終わりではなく、 0 から自動的に構築するデプロイスクリプト の開発を最終成果物としました。 インフラプログラマは、こういった自動構築の仕組みを作るのが大きな役目です。
まずはインフラコースで起こった面白いエピソードを幾つかご紹介します。
LXC の IP アドレスをどうやって取るか
LXC コンテナの IP アドレスを取得する方法、みなさんご存知でしょうか。
LXC コンテナは初期設定でコンテナを作ると DHCP で動的に IP を取得する構成になります。 nginx からロードバランスするには AP サーバのホストの IP アドレスを nginx が知っている必要がありますから、 DHCP を有効にしたまま何とかするには DNS を使ったり、 あるいは nginx の設定ファイルを AP サーバのコンテナを再起動するたびに書き換える必要があります。 もちろん、各ホストに静的アドレスを割り振るのもアリです（そして、それが一番楽です）。
$ sudo lxc-ls --fancy NAME STATE IPV4 IPV6 AUTOSTART -------------------------------------------------- ubuntu-ap1 RUNNING 10.0.3.128 - NO ubuntu-ap2 RUNNING 10.0.3.106 - NO ubuntu-nginx RUNNING 10.0.3.252 - NO
学生さんたちがどんな方法を使うかなーと観察していたところ、3 人とも AP サーバの IP アドレスを動的に取得する方法を選択したようです。
文字列の split 関数などを使って lxc-ls --fancy の出力を 頑張ってパース するコードを書いていました。
パースしなくても lxc-info -iHn $NAME で IP アドレスだけを取得できるんですけどね。（私もそのときは知りませんでしたが！）
なぜかコンテナ内で apt-get が失敗する
ある学生さんは、まず LXC コンテナを生成し、その後 lxc-attach を経由して apt-get install を実行するデプロイスクリプトを書きました。
すると何故だか apt-get が失敗 してしまいました。
彼はその原因がネットワークの不安定さにあると突き止め、APT リポジトリに定期的に ping し、ネットワークの立ち上がりを認識するという修正を加えました。 その修正にはタイムアウト処理も含まれるという完璧さで、この問題は無事回避されたのでした。
インフラのソースコードには
# 削除すると動かない sleep(3)
みたいなコードが 必ずあるもの で、インフラのチームに配属された新人はなぜ 3秒 待てばよいのかまったく理解できないものです。 彼は学生にして、その深淵な世界を知ってしまいました。 この所為でインフラエンジニアになる夢を捨ててしまわないように祈るばかりです。 （そんなコードを書いたことがないなら、それは下層システムを作っている人が頑張っている証拠ですから労ってあげましょう！）
インターンをやってみて、上手くいったところ
今回のインターンでは、サイボウズは 技術力が高くて、エンジニアが働きやすい 会社だと分かってもらうことを目標にしました。 その会社で働くということの具体的なイメージを持ってもらい、入社したいと思ってもらえたら成功です。
そのために、まずは学生さんにインターンを 楽しんでもらう ことが大前提と考え、そのために課題の準備から当日の運営までいくつかの工夫をしました。 楽しめないインターンではマイナスイメージを与えてしまうでしょう。本当は技術力が高くて働きやすい会社であっても。
その上で、サイボウズの技術力をアピールするための工夫を入れることにしました。 インターンは楽しいし会社もすごい となれば、入社したいと思ってもらいやすくなるはずです。
その甲斐あってか、インフラとして初めてのインターンにもかかわらず、参加された学生さんから高い評価をいただきました。 功を奏したと思うポイントを挙げていきます。
面白い課題を見つける
面白さにはいくつかの観点があります。
まず、勉強のための課題ではなく、その会社の役に立つ課題であるかどうか。 会社に役立ちそうだ と感じれば、課題をこなすモチベーションが高まるでしょう。 さらに、それが 本当に役立つ ものなら、彼らの成果を実際の業務に組み入れることができます。
言語の入門書を与えてお勉強してもらうのを課題にするのではなく、業務に関連したコンテンツを盛り込む。 そういう考えのもと、今回のインターンではサイボウズのインフラで 近い将来使うであろう コンテナを用いたロードバランシング機構を作る課題を設定しました。
（その課題達成のために Python を勉強する必要があるなら、その時は堂々と「空飛ぶ Python」を読んでもらうことにします。）
次に、技術的にも面白い課題かどうかという観点があります。 その時々のトレンドになっている技術は、世間に知られ始めたばかりで挑戦したくなる技術が多いです。 今回のインターンを開催したときは、コンテナ技術が世間に浸透し始めていました。
最後に、ちょうど達成できるくらいのレベルになるように設計をしました。 課題が難しすぎても簡単すぎてもつまらなくなってしまいます。 挑戦しがいがありつつ、まったく歯が立たないことがないようにするため、チームメンバーと議論して課題を詰めました。
課題の難易度を調整する
といっても、課題を簡単にするのが難しい場合もあります。 そういうときは正解のひな形を用意しておくのが一つの解決策です。 今回は、LXC コンテナの細かい動作原理は省き、コンテナを作成するコマンド列を準備しておきました。 また、Web アプリの作成経験がない場合に備え、ロードバランス対象の Web アプリのひな形を配ったりしました。
課題のレベルを適切にするためには 学生さんの技術的な経験について事前に把握しておく 必要があります。 面談で技術的な質問をするとか、簡単な課題を解いてもらうなどの方法があるでしょう。 今回私は、学生さんたちが現在取り組んでいる研究に関することや Linux に関することを質問しました。 Python によるプログラミング経験、Linux コマンドラインの経験の有無などは、課題のレベル調節に欠かせない情報です。
講義の中でも手を動かす
インフラ系の知識は学生時代に知ることがあまりないため、今回のインターンでは講義の時間を多く取りました。
講義といっても 録音を聞いた教授本人さえ寝てしまうような講義 ではなく、 積極的に学生さんたちにクイズを出し、ときどきコマンドを打ってもらいつつ進めました。 クイズを解くというのは 能動的に 答えを探すということですから、脳が活性化して知識をよりよく身に付けられます。
このようなインタラクティブな講義は、事前に用意した資料をただ読んでもらうのでは実現できず、メンターの頑張りと、インターンに割ける時間が多いことが求められます。 学生さんたちに喜んでもらえるインターンとするために、私はその週、その他の業務を できるかぎり排除 して、講義に時間を使いました。 メンターが良い講義をすることで、会社の技術力のアピールにもなります。
煮詰まり状態を解消する
- RuntimeError が 38 行目で発生したことは分かったが、果たして本当の原因は何なのか。コードを眺めてもさっぱりだ。
- コンテナの IP アドレスを得る方法がそもそも分からないぞ…
というとき、人は煮詰まります。煮詰まったまま PC の前で数時間が経過する、なんてこともあるでしょう。 インフラコースの学生さんたちも、そういう経験は何度もあるとのこと。 私の経験的に、一度煮詰まると、知ってる人から見ると筋が悪い試行錯誤を繰り返して時間だけが過ぎてしまうのが常です。
ということで、私はメンターとして 30分ごとに休憩を促しに行く ことにしました。 30分というのは、時間管理テクニックで知られる「ポモドーロ法」で良く使う単位です。 私が自席で30分タイマーをかけ、それが鳴ると学生さんの席まで歩いていって、席を立って近くを散歩してくるように伝えます。 この人間タイマー法はとても好評でしたし、何しろ私自身が、彼らが何かに煮詰まっているかどうかを観察できる、優れた手法でした。
メンターから話しかける
学生さんたちは企業のオフィスに来るというだけで緊張しているはずですし、なかなか聞きたいことを質問できない雰囲気になっているかもしれません。 ことあるごとに「調子どう」と なるべく軽い雰囲気 で声をかけ、問題が小さいうちに解決できるようにしました。
「煮詰まり状態を解消する」は自分でタイマーを仕掛けてもできますが、 緊張をほぐしたり質問しやすい環境を作るには、やはりメンターから話しかけることが必要です。 スムーズに開発できる環境を用意することで、学生さんたちにとっても私にとっても、 インターン期間を充実した楽しい時間にすることができたのではないかと思います。
同僚の協力をあおぐ
学生さんたちはメンターである私 以外 の社員についても知りたいと思っているはずです。 近い将来、一緒に働く仲間になる可能性がありますから！ そこで、私のチームの他のメンバーに協力を頼み、インターンに関わってもらうことにしました。
ただ、「関わる」と言ってもおしゃべりをするだけでなく、 コードレビュー をしてもらうことにしました。 チームメンバーにレビューしてもらうことで、サイボウズという会社に、私以外にも技術力がある社員がいることを宣伝できます。 また、学生さんたちとのやりとりで忙しい私に代わって、じっくりレビューをしてもらえるという良い副作用もありました。
開発メンバーの一員として受け入れる
学生さんたちはその企業がどんな雰囲気なのかを知るためにインターンに来ています。 それなのに、周りの社員と異なる環境でインターンの期間を過ごすのでは、雰囲気を良く知ることはできません。
サイボウズはエンジニアに 素晴らしい椅子と机 を支給している会社ですから、学生さんたちにも同等のものを使ってもらいました。 また、サイボウズの社員はお互いに仲が良いですから、その様子が見えるように壁で仕切られていない場所に席を確保しました。 さらに、昼食を食べながら自主的に勉強会をする文化がありますので、「Rと統計の勉強会」に学生さんたちを誘いました。
インターンの途中の日には、気軽に質問し会社のことを知ってもらうためにインフラチームの社員も誘って外食に行きました。 社員同士で外食に行くのは、もちろん普段から良くあることです。
改善点
上手くいったことだけではなく、改善すべき点もいくつかありました。 とくに、事前準備を入念に行うことが大切だと感じました。
課題の選定、資料の準備などはパッと思いつくところで、今回のインターンでも忘れずに行えました。 反省は、それ以外の 準備を見逃しやすい事柄 をまんまと見逃してしまったことです。
開発マシンの手配と設定
開発マシンとモニタが学生の人数分だけ確保できているかを、追加の発注が間に合うくらい余裕をもって 確認すべきでした。 今回は、モニタの手配が直前になってしまって、社内からかき集めてきて間に合わせましたが、 当日になってもモニタが足りなかった可能性がありました。
インフラコースでは、普段私たちがやっているように開発マシンの Windows 上で Hyper-V を設定し、Linux を入れて開発に使ってもらうことにしていました。 本当は、事前に設定を済ませておくつもりでしたが、開発マシンの座席への設置が直前になってしまったことから、 仕方なく学生さんたちに設定作業をお願いすることにしました。
しかし、手配したマシンの BIOS で仮想化技術が無効になっており、Hyper-V で仮想マシンを作ることができず、苦労しました。 まず、BIOS に問題があることを突き止めるところから始まり、貴重なインターン期間を余計な作業に費やすことになってしまいました。 （なんと BIOS の「セキュリティ」という項目の中に仮想化技術の設定があり、探し出すのにとても時間がかかりました。）
アカウントの手配
サイボウズの開発で使っている GitHub Enterprise を学生さんたちにも使ってもらおうと思っていました。 ただ、それは 開発側が思っていただけ で、インターンを統括する人事部はそんなことは感知していませんでした（いやまあ、当たり前なのですが）。 かなり直前になってアカウントの追加申請をしていないことが発覚し、情報システム部に急いで頼みましたが、 たまたま GitHub Enterprise の 人数制限に達しており アカウントを追加できませんでした。
今回は社外秘なコードを書くわけでもありませんでしたので、github.com 上で開発を行うことにしました。 インターン終了後にも学生さんが自分のコードを見られるようになり、逆に良かったかもしれません。 ただ、もし社外秘なコードを書くことになっていたら、課題設定を見直す必要があったでしょう。
Office 365 などを社内で使っており、それらをインターンの発表資料作成などで使ってもらおうと考えているのなら、そのアカウントも要チェックです。
おわりに
サーバ仮想化って何のためにやってるか、という質問を最初にしたとき、学生さんたちは「リソースの有効活用のため！」と答えてくれました。 そういう目的もなくはないのですが、サイボウズで最も大事なのは 物理機材が壊れたとき のための仮想化だということです。 サービスを仮想マシンやコンテナの上で動かしておけば、故障時に素早く他の機材上で起動しなおすことができます。 その視点はかなり新鮮なものだったようです。
インターンを通して、クラウドインフラが動く仕組みやインフラ向けプログラムを作る際の気構え、 ネットワークのデバッグ技術、コンテナ技術など、多くの学びがあったのではないかと思います。 個人的にも、初めてインターンシッププログラムで学生さんをサポートする立場で、 一緒に技術のお勉強をしたり実りの多い 5 日間でした。
インフラコースではありませんが、kintone 開発チームでは通年でインターンシップを募集しています。 サイボウズのインターンシップ全般を詳しく知りたい方は インターンシップ | サイボウズ 採用情報（新卒・キャリア） をご覧ください。情報は随時更新されます。
