こんにちは、 介護のほんね の開発担当エンジニア 兼 プロダーツプレイヤー の徐 聖博です。 メドレーでは定期的に技術勉強会を行っているのですが、この勉強会に参加するのはエンジニアばかりとは限りません。先日は 非エンジニア向けに Git の勉強会を開催 しました。エンジニアではないメンバーも Git を使えるようにすることは、プロダクトの高速開発に大きな効果があると僕たちは考えています。今回は、その思想の背景と、実際に行った勉強会の内容についてご紹介します。 一般的な開発フロー 実際にサービスをコードレベルで把握・修正する人は大抵の場合エンジニア（一部デザイナー）と呼ばれる人種です。 しかし、一般的に、「サービスの運営」と一言で言っても、そこに携わる人の役割は様々です。 サービスの規模にもよりますが、ディレクターやエンジニア・デザイナーはもとより法務や広報など様々な方のサポートによって一つのサービスが成り立ちます。 こうした人が「使いにくい」「ここ、なんか文章間違ってる」と思った場合どうなるでしょうか。 通常は、ディレクターが意見をまとめて方針を決め、一度エンジニアと相談した上で、実装・確認の後リリースというような開発フローを経ます。（下図） これでは改善をしようと思っていても、実際に実装が終わり改善されるまでに時間がかかりすぎてしまいます。 メドレーが目指す開発の形 メドレーでは、こうした通常の開発における課題解決や、エンジニアリング技術を使った業務改善を目指し、定期的に非エンジニア・デザイナー向けの勉強会を開いています。 今回、 初回として行ったのは非エンジニア向けの Git 講座 です。 メドレーでは、先ほど述べたような問題を解決しリリースまでの時間を短縮できる開発フローを目指しており、その一環としてこのような勉強会を開きました。 下図のように、誤りを発見した人が直接自分で編集し、エンジニアがプルリクをレビューしてマージ・リリースすることで開発速度の向上・品質の担保を目指しています。 ※勉強会で実際に使った資料はこちら speakerdeck.com メドレーの Github には、エンジニア・ディレクターに加えて医師や営業といった様々な職種の方が開発者登録されており、全員で直接コードを編集し、日々プロダクト改善に努めています。 まとめ メドレーでは、課題解決・効率化を目指して、さまざまな勉強会を開催しています。非エンジニア・デザイナーに向けても、Git 講座を皮切りに今後月 1 で勉強会を開催予定です。 こうした勉強会の様子を定期的に記事にしていくので、ご興味ある方はメドレーブログをフォローいただけたらなと思っております。 ※ メドレー公式 Facebook ページ に「いいね！」していただけると、ブログの最新情報をフォローできます 今後とも、よろしくお願いします！

こんにちは、 介護のほんね の開発担当エンジニア 兼 プロダーツプレイヤー の徐 聖博です。 メドレーでは定期的に技術勉強会を行っているのですが、この勉強会に参加するのはエンジニアばかりとは限りません。先日は 非エンジニア向けに Git の勉強会を開催 しました。エンジニアではないメンバーも Git を使えるようにすることは、プロダクトの高速開発に大きな効果があると僕たちは考えています。今回は、その思想の背景と、実際に行った勉強会の内容についてご紹介します。 一般的な開発フロー 実際にサービスをコードレベルで把握・修正する人は大抵の場合エンジニア（一部デザイナー）と呼ばれる人種です。 しかし、一般的に、「サービスの運営」と一言で言っても、そこに携わる人の役割は様々です。 サービスの規模にもよりますが、ディレクターやエンジニア・デザイナーはもとより法務や広報など様々な方のサポートによって一つのサービスが成り立ちます。 こうした人が「使いにくい」「ここ、なんか文章間違ってる」と思った場合どうなるでしょうか。 通常は、ディレクターが意見をまとめて方針を決め、一度エンジニアと相談した上で、実装・確認の後リリースというような開発フローを経ます。（下図） これでは改善をしようと思っていても、実際に実装が終わり改善されるまでに時間がかかりすぎてしまいます。 メドレーが目指す開発の形 メドレーでは、こうした通常の開発における課題解決や、エンジニアリング技術を使った業務改善を目指し、定期的に非エンジニア・デザイナー向けの勉強会を開いています。 今回、 初回として行ったのは非エンジニア向けの Git 講座 です。 メドレーでは、先ほど述べたような問題を解決しリリースまでの時間を短縮できる開発フローを目指しており、その一環としてこのような勉強会を開きました。 下図のように、誤りを発見した人が直接自分で編集し、エンジニアがプルリクをレビューしてマージ・リリースすることで開発速度の向上・品質の担保を目指しています。 ※勉強会で実際に使った資料はこちら speakerdeck.com メドレーの Github には、エンジニア・ディレクターに加えて医師や営業といった様々な職種の方が開発者登録されており、全員で直接コードを編集し、日々プロダクト改善に努めています。 まとめ メドレーでは、課題解決・効率化を目指して、さまざまな勉強会を開催しています。非エンジニア・デザイナーに向けても、Git 講座を皮切りに今後月 1 で勉強会を開催予定です。 こうした勉強会の様子を定期的に記事にしていくので、ご興味ある方はメドレーブログをフォローいただけたらなと思っております。 ※ メドレー公式 Facebook ページ に「いいね！」していただけると、ブログの最新情報をフォローできます 今後とも、よろしくお願いします！

こんにちは、 介護のほんね の開発担当エンジニア 兼 プロダーツプレイヤー の徐 聖博です。 メドレーでは定期的に技術勉強会を行っているのですが、この勉強会に参加するのはエンジニアばかりとは限りません。先日は 非エンジニア向けに Git の勉強会を開催 しました。エンジニアではないメンバーも Git を使えるようにすることは、プロダクトの高速開発に大きな効果があると僕たちは考えています。今回は、その思想の背景と、実際に行った勉強会の内容についてご紹介します。 一般的な開発フロー 実際にサービスをコードレベルで把握・修正する人は大抵の場合エンジニア（一部デザイナー）と呼ばれる人種です。 しかし、一般的に、「サービスの運営」と一言で言っても、そこに携わる人の役割は様々です。 サービスの規模にもよりますが、ディレクターやエンジニア・デザイナーはもとより法務や広報など様々な方のサポートによって一つのサービスが成り立ちます。 こうした人が「使いにくい」「ここ、なんか文章間違ってる」と思った場合どうなるでしょうか。 通常は、ディレクターが意見をまとめて方針を決め、一度エンジニアと相談した上で、実装・確認の後リリースというような開発フローを経ます。（下図） これでは改善をしようと思っていても、実際に実装が終わり改善されるまでに時間がかかりすぎてしまいます。 メドレーが目指す開発の形 メドレーでは、こうした通常の開発における課題解決や、エンジニアリング技術を使った業務改善を目指し、定期的に非エンジニア・デザイナー向けの勉強会を開いています。 今回、 初回として行ったのは非エンジニア向けの Git 講座 です。 メドレーでは、先ほど述べたような問題を解決しリリースまでの時間を短縮できる開発フローを目指しており、その一環としてこのような勉強会を開きました。 下図のように、誤りを発見した人が直接自分で編集し、エンジニアがプルリクをレビューしてマージ・リリースすることで開発速度の向上・品質の担保を目指しています。 ※勉強会で実際に使った資料はこちら speakerdeck.com メドレーの Github には、エンジニア・ディレクターに加えて医師や営業といった様々な職種の方が開発者登録されており、全員で直接コードを編集し、日々プロダクト改善に努めています。 まとめ メドレーでは、課題解決・効率化を目指して、さまざまな勉強会を開催しています。非エンジニア・デザイナーに向けても、Git 講座を皮切りに今後月 1 で勉強会を開催予定です。 こうした勉強会の様子を定期的に記事にしていくので、ご興味ある方はメドレーブログをフォローいただけたらなと思っております。 ※ メドレー公式 Facebook ページ に「いいね！」していただけると、ブログの最新情報をフォローできます 今後とも、よろしくお願いします！

こんにちは、 介護のほんね の開発担当エンジニア 兼 プロダーツプレイヤー の徐 聖博です。 メドレーでは定期的に技術勉強会を行っているのですが、この勉強会に参加するのはエンジニアばかりとは限りません。先日は 非エンジニア向けに Git の勉強会を開催 しました。エンジニアではないメンバーも Git を使えるようにすることは、プロダクトの高速開発に大きな効果があると僕たちは考えています。今回は、その思想の背景と、実際に行った勉強会の内容についてご紹介します。 一般的な開発フロー 実際にサービスをコードレベルで把握・修正する人は大抵の場合エンジニア（一部デザイナー）と呼ばれる人種です。 しかし、一般的に、「サービスの運営」と一言で言っても、そこに携わる人の役割は様々です。 サービスの規模にもよりますが、ディレクターやエンジニア・デザイナーはもとより法務や広報など様々な方のサポートによって一つのサービスが成り立ちます。 こうした人が「使いにくい」「ここ、なんか文章間違ってる」と思った場合どうなるでしょうか。 通常は、ディレクターが意見をまとめて方針を決め、一度エンジニアと相談した上で、実装・確認の後リリースというような開発フローを経ます。（下図） これでは改善をしようと思っていても、実際に実装が終わり改善されるまでに時間がかかりすぎてしまいます。 メドレーが目指す開発の形 メドレーでは、こうした通常の開発における課題解決や、エンジニアリング技術を使った業務改善を目指し、定期的に非エンジニア・デザイナー向けの勉強会を開いています。 今回、 初回として行ったのは非エンジニア向けの Git 講座 です。 メドレーでは、先ほど述べたような問題を解決しリリースまでの時間を短縮できる開発フローを目指しており、その一環としてこのような勉強会を開きました。 下図のように、誤りを発見した人が直接自分で編集し、エンジニアがプルリクをレビューしてマージ・リリースすることで開発速度の向上・品質の担保を目指しています。 ※勉強会で実際に使った資料はこちら speakerdeck.com メドレーの Github には、エンジニア・ディレクターに加えて医師や営業といった様々な職種の方が開発者登録されており、全員で直接コードを編集し、日々プロダクト改善に努めています。 まとめ メドレーでは、課題解決・効率化を目指して、さまざまな勉強会を開催しています。非エンジニア・デザイナーに向けても、Git 講座を皮切りに今後月 1 で勉強会を開催予定です。 こうした勉強会の様子を定期的に記事にしていくので、ご興味ある方はメドレーブログをフォローいただけたらなと思っております。 ※ メドレー公式 Facebook ページ に「いいね！」していただけると、ブログの最新情報をフォローできます 今後とも、よろしくお願いします！

こんにちは、 介護のほんね の開発担当エンジニア 兼 プロダーツプレイヤー の徐 聖博です。 メドレーでは定期的に技術勉強会を行っているのですが、この勉強会に参加するのはエンジニアばかりとは限りません。先日は 非エンジニア向けに Git の勉強会を開催 しました。エンジニアではないメンバーも Git を使えるようにすることは、プロダクトの高速開発に大きな効果があると僕たちは考えています。今回は、その思想の背景と、実際に行った勉強会の内容についてご紹介します。 一般的な開発フロー 実際にサービスをコードレベルで把握・修正する人は大抵の場合エンジニア（一部デザイナー）と呼ばれる人種です。 しかし、一般的に、「サービスの運営」と一言で言っても、そこに携わる人の役割は様々です。 サービスの規模にもよりますが、ディレクターやエンジニア・デザイナーはもとより法務や広報など様々な方のサポートによって一つのサービスが成り立ちます。 こうした人が「使いにくい」「ここ、なんか文章間違ってる」と思った場合どうなるでしょうか。 通常は、ディレクターが意見をまとめて方針を決め、一度エンジニアと相談した上で、実装・確認の後リリースというような開発フローを経ます。（下図） これでは改善をしようと思っていても、実際に実装が終わり改善されるまでに時間がかかりすぎてしまいます。 メドレーが目指す開発の形 メドレーでは、こうした通常の開発における課題解決や、エンジニアリング技術を使った業務改善を目指し、定期的に非エンジニア・デザイナー向けの勉強会を開いています。 今回、 初回として行ったのは非エンジニア向けの Git 講座 です。 メドレーでは、先ほど述べたような問題を解決しリリースまでの時間を短縮できる開発フローを目指しており、その一環としてこのような勉強会を開きました。 下図のように、誤りを発見した人が直接自分で編集し、エンジニアがプルリクをレビューしてマージ・リリースすることで開発速度の向上・品質の担保を目指しています。 ※勉強会で実際に使った資料はこちら speakerdeck.com メドレーの Github には、エンジニア・ディレクターに加えて医師や営業といった様々な職種の方が開発者登録されており、全員で直接コードを編集し、日々プロダクト改善に努めています。 まとめ メドレーでは、課題解決・効率化を目指して、さまざまな勉強会を開催しています。非エンジニア・デザイナーに向けても、Git 講座を皮切りに今後月 1 で勉強会を開催予定です。 こうした勉強会の様子を定期的に記事にしていくので、ご興味ある方はメドレーブログをフォローいただけたらなと思っております。 ※ メドレー公式 Facebook ページ に「いいね！」していただけると、ブログの最新情報をフォローできます 今後とも、よろしくお願いします！

こんにちは、 介護のほんね の開発担当エンジニア 兼 プロダーツプレイヤー の徐 聖博です。 メドレーでは定期的に技術勉強会を行っているのですが、この勉強会に参加するのはエンジニアばかりとは限りません。先日は 非エンジニア向けに Git の勉強会を開催 しました。エンジニアではないメンバーも Git を使えるようにすることは、プロダクトの高速開発に大きな効果があると僕たちは考えています。今回は、その思想の背景と、実際に行った勉強会の内容についてご紹介します。 一般的な開発フロー 実際にサービスをコードレベルで把握・修正する人は大抵の場合エンジニア（一部デザイナー）と呼ばれる人種です。 しかし、一般的に、「サービスの運営」と一言で言っても、そこに携わる人の役割は様々です。 サービスの規模にもよりますが、ディレクターやエンジニア・デザイナーはもとより法務や広報など様々な方のサポートによって一つのサービスが成り立ちます。 こうした人が「使いにくい」「ここ、なんか文章間違ってる」と思った場合どうなるでしょうか。 通常は、ディレクターが意見をまとめて方針を決め、一度エンジニアと相談した上で、実装・確認の後リリースというような開発フローを経ます。（下図） これでは改善をしようと思っていても、実際に実装が終わり改善されるまでに時間がかかりすぎてしまいます。 メドレーが目指す開発の形 メドレーでは、こうした通常の開発における課題解決や、エンジニアリング技術を使った業務改善を目指し、定期的に非エンジニア・デザイナー向けの勉強会を開いています。 今回、 初回として行ったのは非エンジニア向けの Git 講座 です。 メドレーでは、先ほど述べたような問題を解決しリリースまでの時間を短縮できる開発フローを目指しており、その一環としてこのような勉強会を開きました。 下図のように、誤りを発見した人が直接自分で編集し、エンジニアがプルリクをレビューしてマージ・リリースすることで開発速度の向上・品質の担保を目指しています。 ※勉強会で実際に使った資料はこちら speakerdeck.com メドレーの Github には、エンジニア・ディレクターに加えて医師や営業といった様々な職種の方が開発者登録されており、全員で直接コードを編集し、日々プロダクト改善に努めています。 まとめ メドレーでは、課題解決・効率化を目指して、さまざまな勉強会を開催しています。非エンジニア・デザイナーに向けても、Git 講座を皮切りに今後月 1 で勉強会を開催予定です。 こうした勉強会の様子を定期的に記事にしていくので、ご興味ある方はメドレーブログをフォローいただけたらなと思っております。 ※ メドレー公式 Facebook ページ に「いいね！」していただけると、ブログの最新情報をフォローできます 今後とも、よろしくお願いします！

医療介護の求人サイト「 ジョブメドレー 」の開発を担当している新居です。 10 月になり肌寒い季節になってきましたが、メドレーでは今年の夏の 8 月から 9 月の間で技術職 インターンシップ （以下、技術 インターン ）を実施しました。 最初に少しメドレーのエンジニアについて紹介すると、メドレーにはエンジニアが所属する開発本部があり、昨年 2015 年 7 月に CTO の平山が参画してから整備されてきました。弊社自体は 2009 年創業ではあるものの、正式に開発本部が立ち上がってからは 1 年弱です。開発本部には 10 月現在 14 名が所属しており、 こちらの記事 でも紹介しましたが医療 xIT という領域でプロダクトの開発をゴリゴリ進めています。 このようにまだまだスタートアップフェーズを走っている段階であり、教育や技術 インターン 開催に使える時間も限られている中ではありましたが、その中で最大限の成果を出せるよう、実施に向けて取り組むことになりました。自分自身としても インターン 生のメンターをするのは初でしたが、 インターン 生とメンターである自分、そしてプロダクトを通じて社会のため（それが会社のためでもある）にしっかり価値を残せるようチャレンジしました。 ということで少し前置きが長くなりましたが、今回はメドレーで行った技術 インターン の取り組みをひとつの事例として紹介してみようと思います。 【企画 1】まずはインタビュー 今回の インターン 生は某大学の 3 年生 1 名で、まずはどういう流れで進めていくかを決めるために簡単にインタビューを行いました。 インタビューの内容は 「なぜ技術 インターン をやりたいのか？」 「大学ではどういう勉強をしてるのか？」 「技術スキルはどれくらいか？（どの言語を書いたことがあるかとか）」 といった内容で、今回は受け入れ前提だったので技術試験などは行っていません。 インタビューの結果、細かい内容は伏せますが今回の インターン 生は大学の授業でプログラミングや簡単な UNIX コマンドに触れたことがあるというレベル感で、「将来エンジニアの道に進むかどうか悩んでいる」「開発の流れをひと通り経験してみたい」という要望を持っていました。 【企画 2】ゴールと内容の大枠を決める インタビューの結果を踏まえて、技術 インターン で行う内容を決めていきます。インタビューによって インターン 生が求めていることがわかったので、それを満たせるようにゴール設定をします。今回だと「開発の一通りの流れを経験し、 インターン 生本人の今後の進路決定のための判断材料やヒントを得てもらうこと」というゴールを設定しました。 また、冒頭でも述べましたが、スタートアップフェーズで少人数でプロダクト開発を進めている最中なので、メンターである自分の開発業務も疎かにできません。実際に開発・運用しているプロダクトでしっかりアウトプットを出し続けることが大切なので、 インターン 生のレベル云々に関係なく、技術 インターン でもどうにか実際に稼働しているプロダクトでアウトプットを出せるような企画を考えました。 そこで以下のような企画の大枠イメージを定義しました。 インターン 生、自分、社会（会社）に価値を残すために、実プロダクト上でアウトプットをしっかり出す 実プロダクト上でアウトプットを出すことで得られる達成感や喜びを感じてもらう ひと通りの開発フローを経験してもらう メンターである自分にも開発業務があるので OJT 形式で行う 【企画 3】詳細な内容を決める ゴールと大枠を決めた後は、企画の詳細な内容を決めていきます。 以下のようなフェーズ 1〜4 を定義してみました。 フェーズ 1「基本的なウェブアプリケーション開発のフローを経験する」 今回の インターン 生のレベル感を踏まえて、まずは Ruby と Rails を使った基本的なウェブアプリケーション開発のフローを経験してもらうことにしました（ Ruby と Rails は今回関わる実プロダクトで使っているため）。そこで教材として Ruby on Rails チュートリアル：実例を使って Rails を学ぼう を使用しました。ご存知の方も多いと思いますが、 Ruby と Rails を使いながらウェブアプリケーション開発を体系的に学べるとても良い教材です。 Ruby と Rails はもちろんのこと、Git の使い方、デプロイ、テストといった実プロダクトの開発で必要不可欠な要素も含まれており、手厚いフォローがなくとも手を動かしながら進められるということで今回採用することになりました。 フェーズ 2「実プロダクトでウェブアプリケーション開発のフローを経験する（小〜中規模）」 フェーズ 1 で流れを掴んだら、ここから実プロダクトの開発に関わってもらうことにしました。まずは文言の修正や追加などを通じて実プロダクト上での開発フローを経験してもらいます。 フェーズ 3「実プロダクトでウェブアプリケーション開発のフローを経験する（中〜大規模）」 フェーズ 2 で慣れてきたらできる範囲で徐々に規模を大きくしていきます。 （小〜中、中〜大など抽象的なところはありますが、細かい定義は省略します） フェーズ 4「難しい課題解決にチャレンジしてアウトプットを出す」 フェーズ 3 の上位として実プロダクト上での難しい課題解決にチャレンジしてもらいます。ここは必須ではないですが、一応設定しておきました。 このような感じでフェーズに区切って定義してみました。 【企画 4】ゴールと内容を共有し認識を合わせる ゴールと内容が決まったら、それらを インターン 生に共有し、 インターン 生のやりたいこととズレがないようしっかり認識を合わせました。問題がなければ開始日からどういう流れで進めていくかのスケジュールもすり合わせし、開始日を待つことになります。 【実施】実際に実施した流れを紹介 いよいよ当日です。当初の計画通りにフェーズ 1 から実施しました。 実際にどういう流れで進んでいったか紹介してみます。 初日から 4 日目 フェーズ 1 の「 Ruby on Rails チュートリアル 」を進めた 「 Ruby on Rails チュートリアル 」の第 9 章のはじめくらいまで進めることができた 時間の都合もありここで「 Ruby on Rails チュートリアル 」は終了した 5 日目 ここから実プロダクトの開発環境構築を行った 早速実プロダクトの文言調整などを行った（ここでブランチ操作や PR の出し方なども経験） 6 日目から 9 日目 実プロダクトで小さい開発業務を数件こなした 表示まわりの調整が中心だが、データベースから必要なデータを取得したり、条件による出し分けをしたり、プロダクト開発で考えないといけないことを経験した ここまでで実プロダクト上でのひと通りの開発フローを経験した 10 日目から 13 日目 実プロダクトの中規模な開発業務を経験した（内容はメディア系のプロダクトの新規ページの追加） ルーティング、コントローラ、ビューなどのページ遷移に必要な処理を実装した 新規ページに表示する情報の取得、情報の整形や表示まわりの処理を実装した データーベースへのデータのインサート、アップデートなども経験した 14 日目から 17 日目 テストコードを追加した 普段手動で行っていたことの自動化をする スクリプト の開発をした（後回しにしていた課題などの解決） 日程の都合もありここで技術 インターン は一区切り こんな感じで一気に紹介してみましたが、随所で適宜フォローを入れつつ短期間で実プロダクト上でアウトプットをしっかり出すことができました。もちろん インターン 生の成果物はしっかりコードレビューと品質レビューをした後、本番にリリースされました。 【実施】感想 今回の技術 インターン 終了後、企画していたフェーズ 3 くらいまでは到達でき、 インターン 生からも当初の目的を満たせたという感想を頂くことができました。ひと通りの開発フローを経験できたこと、実プロダクト上で作ったものが本番環境にリリースされるドキドキや達成感を感じてもらえて、良い経験になったのではないかと思います。 スタートアップということで普段の開発業務と並行し、数日ガッツリ時間をとってフォローするなどはできませんでしたが、 インターン 生の目的を満たせたこと、そして実プロダクト上で新しい機能を追加してリリースできたり、普段の自分の業務で手が回らず後回しになっていた課題なども解決することができ、 インターン 生と自分、社会（会社）のために価値を残すことができたのではないかと思います。 さいごに ということで、今回はメドレーで実施した技術 インターン の事例を紹介してみました。スタートアップというフェーズらしく、意思決定も柔軟で、今回のような技術 インターン の企画・実施という突発的な業務であったり、会社の成長と共に生まれる様々な問題や課題の解決に奔走することも多々ありますが、それもまた醍醐味でしょう。働く環境の整備やエンジニアの文化形成も徐々に進められており、大変なこともありますがスタートアップフェーズでしか経験できないような濃い仕事がたくさんあります。集まっているメンバーは豊富な経験を持った 30 代が中心ですが、もちろん 20 代でも、医療 xIT で挑戦したいやる気ある方を募集中ですので、興味のある方はぜひご連絡ください！ www.wantedly.com

医療介護の求人サイト「 ジョブメドレー 」の開発を担当している新居です。 10 月になり肌寒い季節になってきましたが、メドレーでは今年の夏の 8 月から 9 月の間で技術職 インターンシップ （以下、技術 インターン ）を実施しました。 最初に少しメドレーのエンジニアについて紹介すると、メドレーにはエンジニアが所属する開発本部があり、昨年 2015 年 7 月に CTO の平山が参画してから整備されてきました。弊社自体は 2009 年創業ではあるものの、正式に開発本部が立ち上がってからは 1 年弱です。開発本部には 10 月現在 14 名が所属しており、 こちらの記事 でも紹介しましたが医療 xIT という領域でプロダクトの開発をゴリゴリ進めています。 このようにまだまだスタートアップフェーズを走っている段階であり、教育や技術 インターン 開催に使える時間も限られている中ではありましたが、その中で最大限の成果を出せるよう、実施に向けて取り組むことになりました。自分自身としても インターン 生のメンターをするのは初でしたが、 インターン 生とメンターである自分、そしてプロダクトを通じて社会のため（それが会社のためでもある）にしっかり価値を残せるようチャレンジしました。 ということで少し前置きが長くなりましたが、今回はメドレーで行った技術 インターン の取り組みをひとつの事例として紹介してみようと思います。 【企画 1】まずはインタビュー 今回の インターン 生は某大学の 3 年生 1 名で、まずはどういう流れで進めていくかを決めるために簡単にインタビューを行いました。 インタビューの内容は 「なぜ技術 インターン をやりたいのか？」 「大学ではどういう勉強をしてるのか？」 「技術スキルはどれくらいか？（どの言語を書いたことがあるかとか）」 といった内容で、今回は受け入れ前提だったので技術試験などは行っていません。 インタビューの結果、細かい内容は伏せますが今回の インターン 生は大学の授業でプログラミングや簡単な UNIX コマンドに触れたことがあるというレベル感で、「将来エンジニアの道に進むかどうか悩んでいる」「開発の流れをひと通り経験してみたい」という要望を持っていました。 【企画 2】ゴールと内容の大枠を決める インタビューの結果を踏まえて、技術 インターン で行う内容を決めていきます。インタビューによって インターン 生が求めていることがわかったので、それを満たせるようにゴール設定をします。今回だと「開発の一通りの流れを経験し、 インターン 生本人の今後の進路決定のための判断材料やヒントを得てもらうこと」というゴールを設定しました。 また、冒頭でも述べましたが、スタートアップフェーズで少人数でプロダクト開発を進めている最中なので、メンターである自分の開発業務も疎かにできません。実際に開発・運用しているプロダクトでしっかりアウトプットを出し続けることが大切なので、 インターン 生のレベル云々に関係なく、技術 インターン でもどうにか実際に稼働しているプロダクトでアウトプットを出せるような企画を考えました。 そこで以下のような企画の大枠イメージを定義しました。 インターン 生、自分、社会（会社）に価値を残すために、実プロダクト上でアウトプットをしっかり出す 実プロダクト上でアウトプットを出すことで得られる達成感や喜びを感じてもらう ひと通りの開発フローを経験してもらう メンターである自分にも開発業務があるので OJT 形式で行う 【企画 3】詳細な内容を決める ゴールと大枠を決めた後は、企画の詳細な内容を決めていきます。 以下のようなフェーズ 1〜4 を定義してみました。 フェーズ 1「基本的なウェブアプリケーション開発のフローを経験する」 今回の インターン 生のレベル感を踏まえて、まずは Ruby と Rails を使った基本的なウェブアプリケーション開発のフローを経験してもらうことにしました（ Ruby と Rails は今回関わる実プロダクトで使っているため）。そこで教材として Ruby on Rails チュートリアル：実例を使って Rails を学ぼう を使用しました。ご存知の方も多いと思いますが、 Ruby と Rails を使いながらウェブアプリケーション開発を体系的に学べるとても良い教材です。 Ruby と Rails はもちろんのこと、Git の使い方、デプロイ、テストといった実プロダクトの開発で必要不可欠な要素も含まれており、手厚いフォローがなくとも手を動かしながら進められるということで今回採用することになりました。 フェーズ 2「実プロダクトでウェブアプリケーション開発のフローを経験する（小〜中規模）」 フェーズ 1 で流れを掴んだら、ここから実プロダクトの開発に関わってもらうことにしました。まずは文言の修正や追加などを通じて実プロダクト上での開発フローを経験してもらいます。 フェーズ 3「実プロダクトでウェブアプリケーション開発のフローを経験する（中〜大規模）」 フェーズ 2 で慣れてきたらできる範囲で徐々に規模を大きくしていきます。 （小〜中、中〜大など抽象的なところはありますが、細かい定義は省略します） フェーズ 4「難しい課題解決にチャレンジしてアウトプットを出す」 フェーズ 3 の上位として実プロダクト上での難しい課題解決にチャレンジしてもらいます。ここは必須ではないですが、一応設定しておきました。 このような感じでフェーズに区切って定義してみました。 【企画 4】ゴールと内容を共有し認識を合わせる ゴールと内容が決まったら、それらを インターン 生に共有し、 インターン 生のやりたいこととズレがないようしっかり認識を合わせました。問題がなければ開始日からどういう流れで進めていくかのスケジュールもすり合わせし、開始日を待つことになります。 【実施】実際に実施した流れを紹介 いよいよ当日です。当初の計画通りにフェーズ 1 から実施しました。 実際にどういう流れで進んでいったか紹介してみます。 初日から 4 日目 フェーズ 1 の「 Ruby on Rails チュートリアル 」を進めた 「 Ruby on Rails チュートリアル 」の第 9 章のはじめくらいまで進めることができた 時間の都合もありここで「 Ruby on Rails チュートリアル 」は終了した 5 日目 ここから実プロダクトの開発環境構築を行った 早速実プロダクトの文言調整などを行った（ここでブランチ操作や PR の出し方なども経験） 6 日目から 9 日目 実プロダクトで小さい開発業務を数件こなした 表示まわりの調整が中心だが、データベースから必要なデータを取得したり、条件による出し分けをしたり、プロダクト開発で考えないといけないことを経験した ここまでで実プロダクト上でのひと通りの開発フローを経験した 10 日目から 13 日目 実プロダクトの中規模な開発業務を経験した（内容はメディア系のプロダクトの新規ページの追加） ルーティング、コントローラ、ビューなどのページ遷移に必要な処理を実装した 新規ページに表示する情報の取得、情報の整形や表示まわりの処理を実装した データーベースへのデータのインサート、アップデートなども経験した 14 日目から 17 日目 テストコードを追加した 普段手動で行っていたことの自動化をする スクリプト の開発をした（後回しにしていた課題などの解決） 日程の都合もありここで技術 インターン は一区切り こんな感じで一気に紹介してみましたが、随所で適宜フォローを入れつつ短期間で実プロダクト上でアウトプットをしっかり出すことができました。もちろん インターン 生の成果物はしっかりコードレビューと品質レビューをした後、本番にリリースされました。 【実施】感想 今回の技術 インターン 終了後、企画していたフェーズ 3 くらいまでは到達でき、 インターン 生からも当初の目的を満たせたという感想を頂くことができました。ひと通りの開発フローを経験できたこと、実プロダクト上で作ったものが本番環境にリリースされるドキドキや達成感を感じてもらえて、良い経験になったのではないかと思います。 スタートアップということで普段の開発業務と並行し、数日ガッツリ時間をとってフォローするなどはできませんでしたが、 インターン 生の目的を満たせたこと、そして実プロダクト上で新しい機能を追加してリリースできたり、普段の自分の業務で手が回らず後回しになっていた課題なども解決することができ、 インターン 生と自分、社会（会社）のために価値を残すことができたのではないかと思います。 さいごに ということで、今回はメドレーで実施した技術 インターン の事例を紹介してみました。スタートアップというフェーズらしく、意思決定も柔軟で、今回のような技術 インターン の企画・実施という突発的な業務であったり、会社の成長と共に生まれる様々な問題や課題の解決に奔走することも多々ありますが、それもまた醍醐味でしょう。働く環境の整備やエンジニアの文化形成も徐々に進められており、大変なこともありますがスタートアップフェーズでしか経験できないような濃い仕事がたくさんあります。集まっているメンバーは豊富な経験を持った 30 代が中心ですが、もちろん 20 代でも、医療 xIT で挑戦したいやる気ある方を募集中ですので、興味のある方はぜひご連絡ください！ www.wantedly.com

医療介護の求人サイト「 ジョブメドレー 」の開発を担当している新居です。 10 月になり肌寒い季節になってきましたが、メドレーでは今年の夏の 8 月から 9 月の間で技術職 インターンシップ （以下、技術 インターン ）を実施しました。 最初に少しメドレーのエンジニアについて紹介すると、メドレーにはエンジニアが所属する開発本部があり、昨年 2015 年 7 月に CTO の平山が参画してから整備されてきました。弊社自体は 2009 年創業ではあるものの、正式に開発本部が立ち上がってからは 1 年弱です。開発本部には 10 月現在 14 名が所属しており、 こちらの記事 でも紹介しましたが医療 xIT という領域でプロダクトの開発をゴリゴリ進めています。 このようにまだまだスタートアップフェーズを走っている段階であり、教育や技術 インターン 開催に使える時間も限られている中ではありましたが、その中で最大限の成果を出せるよう、実施に向けて取り組むことになりました。自分自身としても インターン 生のメンターをするのは初でしたが、 インターン 生とメンターである自分、そしてプロダクトを通じて社会のため（それが会社のためでもある）にしっかり価値を残せるようチャレンジしました。 ということで少し前置きが長くなりましたが、今回はメドレーで行った技術 インターン の取り組みをひとつの事例として紹介してみようと思います。 【企画 1】まずはインタビュー 今回の インターン 生は某大学の 3 年生 1 名で、まずはどういう流れで進めていくかを決めるために簡単にインタビューを行いました。 インタビューの内容は 「なぜ技術 インターン をやりたいのか？」 「大学ではどういう勉強をしてるのか？」 「技術スキルはどれくらいか？（どの言語を書いたことがあるかとか）」 といった内容で、今回は受け入れ前提だったので技術試験などは行っていません。 インタビューの結果、細かい内容は伏せますが今回の インターン 生は大学の授業でプログラミングや簡単な UNIX コマンドに触れたことがあるというレベル感で、「将来エンジニアの道に進むかどうか悩んでいる」「開発の流れをひと通り経験してみたい」という要望を持っていました。 【企画 2】ゴールと内容の大枠を決める インタビューの結果を踏まえて、技術 インターン で行う内容を決めていきます。インタビューによって インターン 生が求めていることがわかったので、それを満たせるようにゴール設定をします。今回だと「開発の一通りの流れを経験し、 インターン 生本人の今後の進路決定のための判断材料やヒントを得てもらうこと」というゴールを設定しました。 また、冒頭でも述べましたが、スタートアップフェーズで少人数でプロダクト開発を進めている最中なので、メンターである自分の開発業務も疎かにできません。実際に開発・運用しているプロダクトでしっかりアウトプットを出し続けることが大切なので、 インターン 生のレベル云々に関係なく、技術 インターン でもどうにか実際に稼働しているプロダクトでアウトプットを出せるような企画を考えました。 そこで以下のような企画の大枠イメージを定義しました。 インターン 生、自分、社会（会社）に価値を残すために、実プロダクト上でアウトプットをしっかり出す 実プロダクト上でアウトプットを出すことで得られる達成感や喜びを感じてもらう ひと通りの開発フローを経験してもらう メンターである自分にも開発業務があるので OJT 形式で行う 【企画 3】詳細な内容を決める ゴールと大枠を決めた後は、企画の詳細な内容を決めていきます。 以下のようなフェーズ 1〜4 を定義してみました。 フェーズ 1「基本的なウェブアプリケーション開発のフローを経験する」 今回の インターン 生のレベル感を踏まえて、まずは Ruby と Rails を使った基本的なウェブアプリケーション開発のフローを経験してもらうことにしました（ Ruby と Rails は今回関わる実プロダクトで使っているため）。そこで教材として Ruby on Rails チュートリアル：実例を使って Rails を学ぼう を使用しました。ご存知の方も多いと思いますが、 Ruby と Rails を使いながらウェブアプリケーション開発を体系的に学べるとても良い教材です。 Ruby と Rails はもちろんのこと、Git の使い方、デプロイ、テストといった実プロダクトの開発で必要不可欠な要素も含まれており、手厚いフォローがなくとも手を動かしながら進められるということで今回採用することになりました。 フェーズ 2「実プロダクトでウェブアプリケーション開発のフローを経験する（小〜中規模）」 フェーズ 1 で流れを掴んだら、ここから実プロダクトの開発に関わってもらうことにしました。まずは文言の修正や追加などを通じて実プロダクト上での開発フローを経験してもらいます。 フェーズ 3「実プロダクトでウェブアプリケーション開発のフローを経験する（中〜大規模）」 フェーズ 2 で慣れてきたらできる範囲で徐々に規模を大きくしていきます。 （小〜中、中〜大など抽象的なところはありますが、細かい定義は省略します） フェーズ 4「難しい課題解決にチャレンジしてアウトプットを出す」 フェーズ 3 の上位として実プロダクト上での難しい課題解決にチャレンジしてもらいます。ここは必須ではないですが、一応設定しておきました。 このような感じでフェーズに区切って定義してみました。 【企画 4】ゴールと内容を共有し認識を合わせる ゴールと内容が決まったら、それらを インターン 生に共有し、 インターン 生のやりたいこととズレがないようしっかり認識を合わせました。問題がなければ開始日からどういう流れで進めていくかのスケジュールもすり合わせし、開始日を待つことになります。 【実施】実際に実施した流れを紹介 いよいよ当日です。当初の計画通りにフェーズ 1 から実施しました。 実際にどういう流れで進んでいったか紹介してみます。 初日から 4 日目 フェーズ 1 の「 Ruby on Rails チュートリアル 」を進めた 「 Ruby on Rails チュートリアル 」の第 9 章のはじめくらいまで進めることができた 時間の都合もありここで「 Ruby on Rails チュートリアル 」は終了した 5 日目 ここから実プロダクトの開発環境構築を行った 早速実プロダクトの文言調整などを行った（ここでブランチ操作や PR の出し方なども経験） 6 日目から 9 日目 実プロダクトで小さい開発業務を数件こなした 表示まわりの調整が中心だが、データベースから必要なデータを取得したり、条件による出し分けをしたり、プロダクト開発で考えないといけないことを経験した ここまでで実プロダクト上でのひと通りの開発フローを経験した 10 日目から 13 日目 実プロダクトの中規模な開発業務を経験した（内容はメディア系のプロダクトの新規ページの追加） ルーティング、コントローラ、ビューなどのページ遷移に必要な処理を実装した 新規ページに表示する情報の取得、情報の整形や表示まわりの処理を実装した データーベースへのデータのインサート、アップデートなども経験した 14 日目から 17 日目 テストコードを追加した 普段手動で行っていたことの自動化をする スクリプト の開発をした（後回しにしていた課題などの解決） 日程の都合もありここで技術 インターン は一区切り こんな感じで一気に紹介してみましたが、随所で適宜フォローを入れつつ短期間で実プロダクト上でアウトプットをしっかり出すことができました。もちろん インターン 生の成果物はしっかりコードレビューと品質レビューをした後、本番にリリースされました。 【実施】感想 今回の技術 インターン 終了後、企画していたフェーズ 3 くらいまでは到達でき、 インターン 生からも当初の目的を満たせたという感想を頂くことができました。ひと通りの開発フローを経験できたこと、実プロダクト上で作ったものが本番環境にリリースされるドキドキや達成感を感じてもらえて、良い経験になったのではないかと思います。 スタートアップということで普段の開発業務と並行し、数日ガッツリ時間をとってフォローするなどはできませんでしたが、 インターン 生の目的を満たせたこと、そして実プロダクト上で新しい機能を追加してリリースできたり、普段の自分の業務で手が回らず後回しになっていた課題なども解決することができ、 インターン 生と自分、社会（会社）のために価値を残すことができたのではないかと思います。 さいごに ということで、今回はメドレーで実施した技術 インターン の事例を紹介してみました。スタートアップというフェーズらしく、意思決定も柔軟で、今回のような技術 インターン の企画・実施という突発的な業務であったり、会社の成長と共に生まれる様々な問題や課題の解決に奔走することも多々ありますが、それもまた醍醐味でしょう。働く環境の整備やエンジニアの文化形成も徐々に進められており、大変なこともありますがスタートアップフェーズでしか経験できないような濃い仕事がたくさんあります。集まっているメンバーは豊富な経験を持った 30 代が中心ですが、もちろん 20 代でも、医療 xIT で挑戦したいやる気ある方を募集中ですので、興味のある方はぜひご連絡ください！ www.wantedly.com

医療介護の求人サイト「 ジョブメドレー 」の開発を担当している新居です。 10 月になり肌寒い季節になってきましたが、メドレーでは今年の夏の 8 月から 9 月の間で技術職 インターンシップ （以下、技術 インターン ）を実施しました。 最初に少しメドレーのエンジニアについて紹介すると、メドレーにはエンジニアが所属する開発本部があり、昨年 2015 年 7 月に CTO の平山が参画してから整備されてきました。弊社自体は 2009 年創業ではあるものの、正式に開発本部が立ち上がってからは 1 年弱です。開発本部には 10 月現在 14 名が所属しており、 こちらの記事 でも紹介しましたが医療 xIT という領域でプロダクトの開発をゴリゴリ進めています。 このようにまだまだスタートアップフェーズを走っている段階であり、教育や技術 インターン 開催に使える時間も限られている中ではありましたが、その中で最大限の成果を出せるよう、実施に向けて取り組むことになりました。自分自身としても インターン 生のメンターをするのは初でしたが、 インターン 生とメンターである自分、そしてプロダクトを通じて社会のため（それが会社のためでもある）にしっかり価値を残せるようチャレンジしました。 ということで少し前置きが長くなりましたが、今回はメドレーで行った技術 インターン の取り組みをひとつの事例として紹介してみようと思います。 【企画 1】まずはインタビュー 今回の インターン 生は某大学の 3 年生 1 名で、まずはどういう流れで進めていくかを決めるために簡単にインタビューを行いました。 インタビューの内容は 「なぜ技術 インターン をやりたいのか？」 「大学ではどういう勉強をしてるのか？」 「技術スキルはどれくらいか？（どの言語を書いたことがあるかとか）」 といった内容で、今回は受け入れ前提だったので技術試験などは行っていません。 インタビューの結果、細かい内容は伏せますが今回の インターン 生は大学の授業でプログラミングや簡単な UNIX コマンドに触れたことがあるというレベル感で、「将来エンジニアの道に進むかどうか悩んでいる」「開発の流れをひと通り経験してみたい」という要望を持っていました。 【企画 2】ゴールと内容の大枠を決める インタビューの結果を踏まえて、技術 インターン で行う内容を決めていきます。インタビューによって インターン 生が求めていることがわかったので、それを満たせるようにゴール設定をします。今回だと「開発の一通りの流れを経験し、 インターン 生本人の今後の進路決定のための判断材料やヒントを得てもらうこと」というゴールを設定しました。 また、冒頭でも述べましたが、スタートアップフェーズで少人数でプロダクト開発を進めている最中なので、メンターである自分の開発業務も疎かにできません。実際に開発・運用しているプロダクトでしっかりアウトプットを出し続けることが大切なので、 インターン 生のレベル云々に関係なく、技術 インターン でもどうにか実際に稼働しているプロダクトでアウトプットを出せるような企画を考えました。 そこで以下のような企画の大枠イメージを定義しました。 インターン 生、自分、社会（会社）に価値を残すために、実プロダクト上でアウトプットをしっかり出す 実プロダクト上でアウトプットを出すことで得られる達成感や喜びを感じてもらう ひと通りの開発フローを経験してもらう メンターである自分にも開発業務があるので OJT 形式で行う 【企画 3】詳細な内容を決める ゴールと大枠を決めた後は、企画の詳細な内容を決めていきます。 以下のようなフェーズ 1〜4 を定義してみました。 フェーズ 1「基本的なウェブアプリケーション開発のフローを経験する」 今回の インターン 生のレベル感を踏まえて、まずは Ruby と Rails を使った基本的なウェブアプリケーション開発のフローを経験してもらうことにしました（ Ruby と Rails は今回関わる実プロダクトで使っているため）。そこで教材として Ruby on Rails チュートリアル：実例を使って Rails を学ぼう を使用しました。ご存知の方も多いと思いますが、 Ruby と Rails を使いながらウェブアプリケーション開発を体系的に学べるとても良い教材です。 Ruby と Rails はもちろんのこと、Git の使い方、デプロイ、テストといった実プロダクトの開発で必要不可欠な要素も含まれており、手厚いフォローがなくとも手を動かしながら進められるということで今回採用することになりました。 フェーズ 2「実プロダクトでウェブアプリケーション開発のフローを経験する（小〜中規模）」 フェーズ 1 で流れを掴んだら、ここから実プロダクトの開発に関わってもらうことにしました。まずは文言の修正や追加などを通じて実プロダクト上での開発フローを経験してもらいます。 フェーズ 3「実プロダクトでウェブアプリケーション開発のフローを経験する（中〜大規模）」 フェーズ 2 で慣れてきたらできる範囲で徐々に規模を大きくしていきます。 （小〜中、中〜大など抽象的なところはありますが、細かい定義は省略します） フェーズ 4「難しい課題解決にチャレンジしてアウトプットを出す」 フェーズ 3 の上位として実プロダクト上での難しい課題解決にチャレンジしてもらいます。ここは必須ではないですが、一応設定しておきました。 このような感じでフェーズに区切って定義してみました。 【企画 4】ゴールと内容を共有し認識を合わせる ゴールと内容が決まったら、それらを インターン 生に共有し、 インターン 生のやりたいこととズレがないようしっかり認識を合わせました。問題がなければ開始日からどういう流れで進めていくかのスケジュールもすり合わせし、開始日を待つことになります。 【実施】実際に実施した流れを紹介 いよいよ当日です。当初の計画通りにフェーズ 1 から実施しました。 実際にどういう流れで進んでいったか紹介してみます。 初日から 4 日目 フェーズ 1 の「 Ruby on Rails チュートリアル 」を進めた 「 Ruby on Rails チュートリアル 」の第 9 章のはじめくらいまで進めることができた 時間の都合もありここで「 Ruby on Rails チュートリアル 」は終了した 5 日目 ここから実プロダクトの開発環境構築を行った 早速実プロダクトの文言調整などを行った（ここでブランチ操作や PR の出し方なども経験） 6 日目から 9 日目 実プロダクトで小さい開発業務を数件こなした 表示まわりの調整が中心だが、データベースから必要なデータを取得したり、条件による出し分けをしたり、プロダクト開発で考えないといけないことを経験した ここまでで実プロダクト上でのひと通りの開発フローを経験した 10 日目から 13 日目 実プロダクトの中規模な開発業務を経験した（内容はメディア系のプロダクトの新規ページの追加） ルーティング、コントローラ、ビューなどのページ遷移に必要な処理を実装した 新規ページに表示する情報の取得、情報の整形や表示まわりの処理を実装した データーベースへのデータのインサート、アップデートなども経験した 14 日目から 17 日目 テストコードを追加した 普段手動で行っていたことの自動化をする スクリプト の開発をした（後回しにしていた課題などの解決） 日程の都合もありここで技術 インターン は一区切り こんな感じで一気に紹介してみましたが、随所で適宜フォローを入れつつ短期間で実プロダクト上でアウトプットをしっかり出すことができました。もちろん インターン 生の成果物はしっかりコードレビューと品質レビューをした後、本番にリリースされました。 【実施】感想 今回の技術 インターン 終了後、企画していたフェーズ 3 くらいまでは到達でき、 インターン 生からも当初の目的を満たせたという感想を頂くことができました。ひと通りの開発フローを経験できたこと、実プロダクト上で作ったものが本番環境にリリースされるドキドキや達成感を感じてもらえて、良い経験になったのではないかと思います。 スタートアップということで普段の開発業務と並行し、数日ガッツリ時間をとってフォローするなどはできませんでしたが、 インターン 生の目的を満たせたこと、そして実プロダクト上で新しい機能を追加してリリースできたり、普段の自分の業務で手が回らず後回しになっていた課題なども解決することができ、 インターン 生と自分、社会（会社）のために価値を残すことができたのではないかと思います。 さいごに ということで、今回はメドレーで実施した技術 インターン の事例を紹介してみました。スタートアップというフェーズらしく、意思決定も柔軟で、今回のような技術 インターン の企画・実施という突発的な業務であったり、会社の成長と共に生まれる様々な問題や課題の解決に奔走することも多々ありますが、それもまた醍醐味でしょう。働く環境の整備やエンジニアの文化形成も徐々に進められており、大変なこともありますがスタートアップフェーズでしか経験できないような濃い仕事がたくさんあります。集まっているメンバーは豊富な経験を持った 30 代が中心ですが、もちろん 20 代でも、医療 xIT で挑戦したいやる気ある方を募集中ですので、興味のある方はぜひご連絡ください！ www.wantedly.com

医療介護の求人サイト「 ジョブメドレー 」の開発を担当している新居です。 10 月になり肌寒い季節になってきましたが、メドレーでは今年の夏の 8 月から 9 月の間で技術職 インターンシップ （以下、技術 インターン ）を実施しました。 最初に少しメドレーのエンジニアについて紹介すると、メドレーにはエンジニアが所属する開発本部があり、昨年 2015 年 7 月に CTO の平山が参画してから整備されてきました。弊社自体は 2009 年創業ではあるものの、正式に開発本部が立ち上がってからは 1 年弱です。開発本部には 10 月現在 14 名が所属しており、 こちらの記事 でも紹介しましたが医療 xIT という領域でプロダクトの開発をゴリゴリ進めています。 このようにまだまだスタートアップフェーズを走っている段階であり、教育や技術 インターン 開催に使える時間も限られている中ではありましたが、その中で最大限の成果を出せるよう、実施に向けて取り組むことになりました。自分自身としても インターン 生のメンターをするのは初でしたが、 インターン 生とメンターである自分、そしてプロダクトを通じて社会のため（それが会社のためでもある）にしっかり価値を残せるようチャレンジしました。 ということで少し前置きが長くなりましたが、今回はメドレーで行った技術 インターン の取り組みをひとつの事例として紹介してみようと思います。 【企画 1】まずはインタビュー 今回の インターン 生は某大学の 3 年生 1 名で、まずはどういう流れで進めていくかを決めるために簡単にインタビューを行いました。 インタビューの内容は 「なぜ技術 インターン をやりたいのか？」 「大学ではどういう勉強をしてるのか？」 「技術スキルはどれくらいか？（どの言語を書いたことがあるかとか）」 といった内容で、今回は受け入れ前提だったので技術試験などは行っていません。 インタビューの結果、細かい内容は伏せますが今回の インターン 生は大学の授業でプログラミングや簡単な UNIX コマンドに触れたことがあるというレベル感で、「将来エンジニアの道に進むかどうか悩んでいる」「開発の流れをひと通り経験してみたい」という要望を持っていました。 【企画 2】ゴールと内容の大枠を決める インタビューの結果を踏まえて、技術 インターン で行う内容を決めていきます。インタビューによって インターン 生が求めていることがわかったので、それを満たせるようにゴール設定をします。今回だと「開発の一通りの流れを経験し、 インターン 生本人の今後の進路決定のための判断材料やヒントを得てもらうこと」というゴールを設定しました。 また、冒頭でも述べましたが、スタートアップフェーズで少人数でプロダクト開発を進めている最中なので、メンターである自分の開発業務も疎かにできません。実際に開発・運用しているプロダクトでしっかりアウトプットを出し続けることが大切なので、 インターン 生のレベル云々に関係なく、技術 インターン でもどうにか実際に稼働しているプロダクトでアウトプットを出せるような企画を考えました。 そこで以下のような企画の大枠イメージを定義しました。 インターン 生、自分、社会（会社）に価値を残すために、実プロダクト上でアウトプットをしっかり出す 実プロダクト上でアウトプットを出すことで得られる達成感や喜びを感じてもらう ひと通りの開発フローを経験してもらう メンターである自分にも開発業務があるので OJT 形式で行う 【企画 3】詳細な内容を決める ゴールと大枠を決めた後は、企画の詳細な内容を決めていきます。 以下のようなフェーズ 1〜4 を定義してみました。 フェーズ 1「基本的なウェブアプリケーション開発のフローを経験する」 今回の インターン 生のレベル感を踏まえて、まずは Ruby と Rails を使った基本的なウェブアプリケーション開発のフローを経験してもらうことにしました（ Ruby と Rails は今回関わる実プロダクトで使っているため）。そこで教材として Ruby on Rails チュートリアル：実例を使って Rails を学ぼう を使用しました。ご存知の方も多いと思いますが、 Ruby と Rails を使いながらウェブアプリケーション開発を体系的に学べるとても良い教材です。 Ruby と Rails はもちろんのこと、Git の使い方、デプロイ、テストといった実プロダクトの開発で必要不可欠な要素も含まれており、手厚いフォローがなくとも手を動かしながら進められるということで今回採用することになりました。 フェーズ 2「実プロダクトでウェブアプリケーション開発のフローを経験する（小〜中規模）」 フェーズ 1 で流れを掴んだら、ここから実プロダクトの開発に関わってもらうことにしました。まずは文言の修正や追加などを通じて実プロダクト上での開発フローを経験してもらいます。 フェーズ 3「実プロダクトでウェブアプリケーション開発のフローを経験する（中〜大規模）」 フェーズ 2 で慣れてきたらできる範囲で徐々に規模を大きくしていきます。 （小〜中、中〜大など抽象的なところはありますが、細かい定義は省略します） フェーズ 4「難しい課題解決にチャレンジしてアウトプットを出す」 フェーズ 3 の上位として実プロダクト上での難しい課題解決にチャレンジしてもらいます。ここは必須ではないですが、一応設定しておきました。 このような感じでフェーズに区切って定義してみました。 【企画 4】ゴールと内容を共有し認識を合わせる ゴールと内容が決まったら、それらを インターン 生に共有し、 インターン 生のやりたいこととズレがないようしっかり認識を合わせました。問題がなければ開始日からどういう流れで進めていくかのスケジュールもすり合わせし、開始日を待つことになります。 【実施】実際に実施した流れを紹介 いよいよ当日です。当初の計画通りにフェーズ 1 から実施しました。 実際にどういう流れで進んでいったか紹介してみます。 初日から 4 日目 フェーズ 1 の「 Ruby on Rails チュートリアル 」を進めた 「 Ruby on Rails チュートリアル 」の第 9 章のはじめくらいまで進めることができた 時間の都合もありここで「 Ruby on Rails チュートリアル 」は終了した 5 日目 ここから実プロダクトの開発環境構築を行った 早速実プロダクトの文言調整などを行った（ここでブランチ操作や PR の出し方なども経験） 6 日目から 9 日目 実プロダクトで小さい開発業務を数件こなした 表示まわりの調整が中心だが、データベースから必要なデータを取得したり、条件による出し分けをしたり、プロダクト開発で考えないといけないことを経験した ここまでで実プロダクト上でのひと通りの開発フローを経験した 10 日目から 13 日目 実プロダクトの中規模な開発業務を経験した（内容はメディア系のプロダクトの新規ページの追加） ルーティング、コントローラ、ビューなどのページ遷移に必要な処理を実装した 新規ページに表示する情報の取得、情報の整形や表示まわりの処理を実装した データーベースへのデータのインサート、アップデートなども経験した 14 日目から 17 日目 テストコードを追加した 普段手動で行っていたことの自動化をする スクリプト の開発をした（後回しにしていた課題などの解決） 日程の都合もありここで技術 インターン は一区切り こんな感じで一気に紹介してみましたが、随所で適宜フォローを入れつつ短期間で実プロダクト上でアウトプットをしっかり出すことができました。もちろん インターン 生の成果物はしっかりコードレビューと品質レビューをした後、本番にリリースされました。 【実施】感想 今回の技術 インターン 終了後、企画していたフェーズ 3 くらいまでは到達でき、 インターン 生からも当初の目的を満たせたという感想を頂くことができました。ひと通りの開発フローを経験できたこと、実プロダクト上で作ったものが本番環境にリリースされるドキドキや達成感を感じてもらえて、良い経験になったのではないかと思います。 スタートアップということで普段の開発業務と並行し、数日ガッツリ時間をとってフォローするなどはできませんでしたが、 インターン 生の目的を満たせたこと、そして実プロダクト上で新しい機能を追加してリリースできたり、普段の自分の業務で手が回らず後回しになっていた課題なども解決することができ、 インターン 生と自分、社会（会社）のために価値を残すことができたのではないかと思います。 さいごに ということで、今回はメドレーで実施した技術 インターン の事例を紹介してみました。スタートアップというフェーズらしく、意思決定も柔軟で、今回のような技術 インターン の企画・実施という突発的な業務であったり、会社の成長と共に生まれる様々な問題や課題の解決に奔走することも多々ありますが、それもまた醍醐味でしょう。働く環境の整備やエンジニアの文化形成も徐々に進められており、大変なこともありますがスタートアップフェーズでしか経験できないような濃い仕事がたくさんあります。集まっているメンバーは豊富な経験を持った 30 代が中心ですが、もちろん 20 代でも、医療 xIT で挑戦したいやる気ある方を募集中ですので、興味のある方はぜひご連絡ください！ www.wantedly.com

医療介護の求人サイト「 ジョブメドレー 」の開発を担当している新居です。 10 月になり肌寒い季節になってきましたが、メドレーでは今年の夏の 8 月から 9 月の間で技術職 インターンシップ （以下、技術 インターン ）を実施しました。 最初に少しメドレーのエンジニアについて紹介すると、メドレーにはエンジニアが所属する開発本部があり、昨年 2015 年 7 月に CTO の平山が参画してから整備されてきました。弊社自体は 2009 年創業ではあるものの、正式に開発本部が立ち上がってからは 1 年弱です。開発本部には 10 月現在 14 名が所属しており、 こちらの記事 でも紹介しましたが医療 xIT という領域でプロダクトの開発をゴリゴリ進めています。 このようにまだまだスタートアップフェーズを走っている段階であり、教育や技術 インターン 開催に使える時間も限られている中ではありましたが、その中で最大限の成果を出せるよう、実施に向けて取り組むことになりました。自分自身としても インターン 生のメンターをするのは初でしたが、 インターン 生とメンターである自分、そしてプロダクトを通じて社会のため（それが会社のためでもある）にしっかり価値を残せるようチャレンジしました。 ということで少し前置きが長くなりましたが、今回はメドレーで行った技術 インターン の取り組みをひとつの事例として紹介してみようと思います。 【企画 1】まずはインタビュー 今回の インターン 生は某大学の 3 年生 1 名で、まずはどういう流れで進めていくかを決めるために簡単にインタビューを行いました。 インタビューの内容は 「なぜ技術 インターン をやりたいのか？」 「大学ではどういう勉強をしてるのか？」 「技術スキルはどれくらいか？（どの言語を書いたことがあるかとか）」 といった内容で、今回は受け入れ前提だったので技術試験などは行っていません。 インタビューの結果、細かい内容は伏せますが今回の インターン 生は大学の授業でプログラミングや簡単な UNIX コマンドに触れたことがあるというレベル感で、「将来エンジニアの道に進むかどうか悩んでいる」「開発の流れをひと通り経験してみたい」という要望を持っていました。 【企画 2】ゴールと内容の大枠を決める インタビューの結果を踏まえて、技術 インターン で行う内容を決めていきます。インタビューによって インターン 生が求めていることがわかったので、それを満たせるようにゴール設定をします。今回だと「開発の一通りの流れを経験し、 インターン 生本人の今後の進路決定のための判断材料やヒントを得てもらうこと」というゴールを設定しました。 また、冒頭でも述べましたが、スタートアップフェーズで少人数でプロダクト開発を進めている最中なので、メンターである自分の開発業務も疎かにできません。実際に開発・運用しているプロダクトでしっかりアウトプットを出し続けることが大切なので、 インターン 生のレベル云々に関係なく、技術 インターン でもどうにか実際に稼働しているプロダクトでアウトプットを出せるような企画を考えました。 そこで以下のような企画の大枠イメージを定義しました。 インターン 生、自分、社会（会社）に価値を残すために、実プロダクト上でアウトプットをしっかり出す 実プロダクト上でアウトプットを出すことで得られる達成感や喜びを感じてもらう ひと通りの開発フローを経験してもらう メンターである自分にも開発業務があるので OJT 形式で行う 【企画 3】詳細な内容を決める ゴールと大枠を決めた後は、企画の詳細な内容を決めていきます。 以下のようなフェーズ 1〜4 を定義してみました。 フェーズ 1「基本的なウェブアプリケーション開発のフローを経験する」 今回の インターン 生のレベル感を踏まえて、まずは Ruby と Rails を使った基本的なウェブアプリケーション開発のフローを経験してもらうことにしました（ Ruby と Rails は今回関わる実プロダクトで使っているため）。そこで教材として Ruby on Rails チュートリアル：実例を使って Rails を学ぼう を使用しました。ご存知の方も多いと思いますが、 Ruby と Rails を使いながらウェブアプリケーション開発を体系的に学べるとても良い教材です。 Ruby と Rails はもちろんのこと、Git の使い方、デプロイ、テストといった実プロダクトの開発で必要不可欠な要素も含まれており、手厚いフォローがなくとも手を動かしながら進められるということで今回採用することになりました。 フェーズ 2「実プロダクトでウェブアプリケーション開発のフローを経験する（小〜中規模）」 フェーズ 1 で流れを掴んだら、ここから実プロダクトの開発に関わってもらうことにしました。まずは文言の修正や追加などを通じて実プロダクト上での開発フローを経験してもらいます。 フェーズ 3「実プロダクトでウェブアプリケーション開発のフローを経験する（中〜大規模）」 フェーズ 2 で慣れてきたらできる範囲で徐々に規模を大きくしていきます。 （小〜中、中〜大など抽象的なところはありますが、細かい定義は省略します） フェーズ 4「難しい課題解決にチャレンジしてアウトプットを出す」 フェーズ 3 の上位として実プロダクト上での難しい課題解決にチャレンジしてもらいます。ここは必須ではないですが、一応設定しておきました。 このような感じでフェーズに区切って定義してみました。 【企画 4】ゴールと内容を共有し認識を合わせる ゴールと内容が決まったら、それらを インターン 生に共有し、 インターン 生のやりたいこととズレがないようしっかり認識を合わせました。問題がなければ開始日からどういう流れで進めていくかのスケジュールもすり合わせし、開始日を待つことになります。 【実施】実際に実施した流れを紹介 いよいよ当日です。当初の計画通りにフェーズ 1 から実施しました。 実際にどういう流れで進んでいったか紹介してみます。 初日から 4 日目 フェーズ 1 の「 Ruby on Rails チュートリアル 」を進めた 「 Ruby on Rails チュートリアル 」の第 9 章のはじめくらいまで進めることができた 時間の都合もありここで「 Ruby on Rails チュートリアル 」は終了した 5 日目 ここから実プロダクトの開発環境構築を行った 早速実プロダクトの文言調整などを行った（ここでブランチ操作や PR の出し方なども経験） 6 日目から 9 日目 実プロダクトで小さい開発業務を数件こなした 表示まわりの調整が中心だが、データベースから必要なデータを取得したり、条件による出し分けをしたり、プロダクト開発で考えないといけないことを経験した ここまでで実プロダクト上でのひと通りの開発フローを経験した 10 日目から 13 日目 実プロダクトの中規模な開発業務を経験した（内容はメディア系のプロダクトの新規ページの追加） ルーティング、コントローラ、ビューなどのページ遷移に必要な処理を実装した 新規ページに表示する情報の取得、情報の整形や表示まわりの処理を実装した データーベースへのデータのインサート、アップデートなども経験した 14 日目から 17 日目 テストコードを追加した 普段手動で行っていたことの自動化をする スクリプト の開発をした（後回しにしていた課題などの解決） 日程の都合もありここで技術 インターン は一区切り こんな感じで一気に紹介してみましたが、随所で適宜フォローを入れつつ短期間で実プロダクト上でアウトプットをしっかり出すことができました。もちろん インターン 生の成果物はしっかりコードレビューと品質レビューをした後、本番にリリースされました。 【実施】感想 今回の技術 インターン 終了後、企画していたフェーズ 3 くらいまでは到達でき、 インターン 生からも当初の目的を満たせたという感想を頂くことができました。ひと通りの開発フローを経験できたこと、実プロダクト上で作ったものが本番環境にリリースされるドキドキや達成感を感じてもらえて、良い経験になったのではないかと思います。 スタートアップということで普段の開発業務と並行し、数日ガッツリ時間をとってフォローするなどはできませんでしたが、 インターン 生の目的を満たせたこと、そして実プロダクト上で新しい機能を追加してリリースできたり、普段の自分の業務で手が回らず後回しになっていた課題なども解決することができ、 インターン 生と自分、社会（会社）のために価値を残すことができたのではないかと思います。 さいごに ということで、今回はメドレーで実施した技術 インターン の事例を紹介してみました。スタートアップというフェーズらしく、意思決定も柔軟で、今回のような技術 インターン の企画・実施という突発的な業務であったり、会社の成長と共に生まれる様々な問題や課題の解決に奔走することも多々ありますが、それもまた醍醐味でしょう。働く環境の整備やエンジニアの文化形成も徐々に進められており、大変なこともありますがスタートアップフェーズでしか経験できないような濃い仕事がたくさんあります。集まっているメンバーは豊富な経験を持った 30 代が中心ですが、もちろん 20 代でも、医療 xIT で挑戦したいやる気ある方を募集中ですので、興味のある方はぜひご連絡ください！ www.wantedly.com

医療介護の求人サイト「 ジョブメドレー 」の開発を担当している新居です。 10 月になり肌寒い季節になってきましたが、メドレーでは今年の夏の 8 月から 9 月の間で技術職 インターンシップ （以下、技術 インターン ）を実施しました。 最初に少しメドレーのエンジニアについて紹介すると、メドレーにはエンジニアが所属する開発本部があり、昨年 2015 年 7 月に CTO の平山が参画してから整備されてきました。弊社自体は 2009 年創業ではあるものの、正式に開発本部が立ち上がってからは 1 年弱です。開発本部には 10 月現在 14 名が所属しており、 こちらの記事 でも紹介しましたが医療 xIT という領域でプロダクトの開発をゴリゴリ進めています。 このようにまだまだスタートアップフェーズを走っている段階であり、教育や技術 インターン 開催に使える時間も限られている中ではありましたが、その中で最大限の成果を出せるよう、実施に向けて取り組むことになりました。自分自身としても インターン 生のメンターをするのは初でしたが、 インターン 生とメンターである自分、そしてプロダクトを通じて社会のため（それが会社のためでもある）にしっかり価値を残せるようチャレンジしました。 ということで少し前置きが長くなりましたが、今回はメドレーで行った技術 インターン の取り組みをひとつの事例として紹介してみようと思います。 【企画 1】まずはインタビュー 今回の インターン 生は某大学の 3 年生 1 名で、まずはどういう流れで進めていくかを決めるために簡単にインタビューを行いました。 インタビューの内容は 「なぜ技術 インターン をやりたいのか？」 「大学ではどういう勉強をしてるのか？」 「技術スキルはどれくらいか？（どの言語を書いたことがあるかとか）」 といった内容で、今回は受け入れ前提だったので技術試験などは行っていません。 インタビューの結果、細かい内容は伏せますが今回の インターン 生は大学の授業でプログラミングや簡単な UNIX コマンドに触れたことがあるというレベル感で、「将来エンジニアの道に進むかどうか悩んでいる」「開発の流れをひと通り経験してみたい」という要望を持っていました。 【企画 2】ゴールと内容の大枠を決める インタビューの結果を踏まえて、技術 インターン で行う内容を決めていきます。インタビューによって インターン 生が求めていることがわかったので、それを満たせるようにゴール設定をします。今回だと「開発の一通りの流れを経験し、 インターン 生本人の今後の進路決定のための判断材料やヒントを得てもらうこと」というゴールを設定しました。 また、冒頭でも述べましたが、スタートアップフェーズで少人数でプロダクト開発を進めている最中なので、メンターである自分の開発業務も疎かにできません。実際に開発・運用しているプロダクトでしっかりアウトプットを出し続けることが大切なので、 インターン 生のレベル云々に関係なく、技術 インターン でもどうにか実際に稼働しているプロダクトでアウトプットを出せるような企画を考えました。 そこで以下のような企画の大枠イメージを定義しました。 インターン 生、自分、社会（会社）に価値を残すために、実プロダクト上でアウトプットをしっかり出す 実プロダクト上でアウトプットを出すことで得られる達成感や喜びを感じてもらう ひと通りの開発フローを経験してもらう メンターである自分にも開発業務があるので OJT 形式で行う 【企画 3】詳細な内容を決める ゴールと大枠を決めた後は、企画の詳細な内容を決めていきます。 以下のようなフェーズ 1〜4 を定義してみました。 フェーズ 1「基本的なウェブアプリケーション開発のフローを経験する」 今回の インターン 生のレベル感を踏まえて、まずは Ruby と Rails を使った基本的なウェブアプリケーション開発のフローを経験してもらうことにしました（ Ruby と Rails は今回関わる実プロダクトで使っているため）。そこで教材として Ruby on Rails チュートリアル：実例を使って Rails を学ぼう を使用しました。ご存知の方も多いと思いますが、 Ruby と Rails を使いながらウェブアプリケーション開発を体系的に学べるとても良い教材です。 Ruby と Rails はもちろんのこと、Git の使い方、デプロイ、テストといった実プロダクトの開発で必要不可欠な要素も含まれており、手厚いフォローがなくとも手を動かしながら進められるということで今回採用することになりました。 フェーズ 2「実プロダクトでウェブアプリケーション開発のフローを経験する（小〜中規模）」 フェーズ 1 で流れを掴んだら、ここから実プロダクトの開発に関わってもらうことにしました。まずは文言の修正や追加などを通じて実プロダクト上での開発フローを経験してもらいます。 フェーズ 3「実プロダクトでウェブアプリケーション開発のフローを経験する（中〜大規模）」 フェーズ 2 で慣れてきたらできる範囲で徐々に規模を大きくしていきます。 （小〜中、中〜大など抽象的なところはありますが、細かい定義は省略します） フェーズ 4「難しい課題解決にチャレンジしてアウトプットを出す」 フェーズ 3 の上位として実プロダクト上での難しい課題解決にチャレンジしてもらいます。ここは必須ではないですが、一応設定しておきました。 このような感じでフェーズに区切って定義してみました。 【企画 4】ゴールと内容を共有し認識を合わせる ゴールと内容が決まったら、それらを インターン 生に共有し、 インターン 生のやりたいこととズレがないようしっかり認識を合わせました。問題がなければ開始日からどういう流れで進めていくかのスケジュールもすり合わせし、開始日を待つことになります。 【実施】実際に実施した流れを紹介 いよいよ当日です。当初の計画通りにフェーズ 1 から実施しました。 実際にどういう流れで進んでいったか紹介してみます。 初日から 4 日目 フェーズ 1 の「 Ruby on Rails チュートリアル 」を進めた 「 Ruby on Rails チュートリアル 」の第 9 章のはじめくらいまで進めることができた 時間の都合もありここで「 Ruby on Rails チュートリアル 」は終了した 5 日目 ここから実プロダクトの開発環境構築を行った 早速実プロダクトの文言調整などを行った（ここでブランチ操作や PR の出し方なども経験） 6 日目から 9 日目 実プロダクトで小さい開発業務を数件こなした 表示まわりの調整が中心だが、データベースから必要なデータを取得したり、条件による出し分けをしたり、プロダクト開発で考えないといけないことを経験した ここまでで実プロダクト上でのひと通りの開発フローを経験した 10 日目から 13 日目 実プロダクトの中規模な開発業務を経験した（内容はメディア系のプロダクトの新規ページの追加） ルーティング、コントローラ、ビューなどのページ遷移に必要な処理を実装した 新規ページに表示する情報の取得、情報の整形や表示まわりの処理を実装した データーベースへのデータのインサート、アップデートなども経験した 14 日目から 17 日目 テストコードを追加した 普段手動で行っていたことの自動化をする スクリプト の開発をした（後回しにしていた課題などの解決） 日程の都合もありここで技術 インターン は一区切り こんな感じで一気に紹介してみましたが、随所で適宜フォローを入れつつ短期間で実プロダクト上でアウトプットをしっかり出すことができました。もちろん インターン 生の成果物はしっかりコードレビューと品質レビューをした後、本番にリリースされました。 【実施】感想 今回の技術 インターン 終了後、企画していたフェーズ 3 くらいまでは到達でき、 インターン 生からも当初の目的を満たせたという感想を頂くことができました。ひと通りの開発フローを経験できたこと、実プロダクト上で作ったものが本番環境にリリースされるドキドキや達成感を感じてもらえて、良い経験になったのではないかと思います。 スタートアップということで普段の開発業務と並行し、数日ガッツリ時間をとってフォローするなどはできませんでしたが、 インターン 生の目的を満たせたこと、そして実プロダクト上で新しい機能を追加してリリースできたり、普段の自分の業務で手が回らず後回しになっていた課題なども解決することができ、 インターン 生と自分、社会（会社）のために価値を残すことができたのではないかと思います。 さいごに ということで、今回はメドレーで実施した技術 インターン の事例を紹介してみました。スタートアップというフェーズらしく、意思決定も柔軟で、今回のような技術 インターン の企画・実施という突発的な業務であったり、会社の成長と共に生まれる様々な問題や課題の解決に奔走することも多々ありますが、それもまた醍醐味でしょう。働く環境の整備やエンジニアの文化形成も徐々に進められており、大変なこともありますがスタートアップフェーズでしか経験できないような濃い仕事がたくさんあります。集まっているメンバーは豊富な経験を持った 30 代が中心ですが、もちろん 20 代でも、医療 xIT で挑戦したいやる気ある方を募集中ですので、興味のある方はぜひご連絡ください！ www.wantedly.com

医療介護の求人サイト「 ジョブメドレー 」の開発を担当している新居です。 10 月になり肌寒い季節になってきましたが、メドレーでは今年の夏の 8 月から 9 月の間で技術職 インターンシップ （以下、技術 インターン ）を実施しました。 最初に少しメドレーのエンジニアについて紹介すると、メドレーにはエンジニアが所属する開発本部があり、昨年 2015 年 7 月に CTO の平山が参画してから整備されてきました。弊社自体は 2009 年創業ではあるものの、正式に開発本部が立ち上がってからは 1 年弱です。開発本部には 10 月現在 14 名が所属しており、 こちらの記事 でも紹介しましたが医療 xIT という領域でプロダクトの開発をゴリゴリ進めています。 このようにまだまだスタートアップフェーズを走っている段階であり、教育や技術 インターン 開催に使える時間も限られている中ではありましたが、その中で最大限の成果を出せるよう、実施に向けて取り組むことになりました。自分自身としても インターン 生のメンターをするのは初でしたが、 インターン 生とメンターである自分、そしてプロダクトを通じて社会のため（それが会社のためでもある）にしっかり価値を残せるようチャレンジしました。 ということで少し前置きが長くなりましたが、今回はメドレーで行った技術 インターン の取り組みをひとつの事例として紹介してみようと思います。 【企画 1】まずはインタビュー 今回の インターン 生は某大学の 3 年生 1 名で、まずはどういう流れで進めていくかを決めるために簡単にインタビューを行いました。 インタビューの内容は 「なぜ技術 インターン をやりたいのか？」 「大学ではどういう勉強をしてるのか？」 「技術スキルはどれくらいか？（どの言語を書いたことがあるかとか）」 といった内容で、今回は受け入れ前提だったので技術試験などは行っていません。 インタビューの結果、細かい内容は伏せますが今回の インターン 生は大学の授業でプログラミングや簡単な UNIX コマンドに触れたことがあるというレベル感で、「将来エンジニアの道に進むかどうか悩んでいる」「開発の流れをひと通り経験してみたい」という要望を持っていました。 【企画 2】ゴールと内容の大枠を決める インタビューの結果を踏まえて、技術 インターン で行う内容を決めていきます。インタビューによって インターン 生が求めていることがわかったので、それを満たせるようにゴール設定をします。今回だと「開発の一通りの流れを経験し、 インターン 生本人の今後の進路決定のための判断材料やヒントを得てもらうこと」というゴールを設定しました。 また、冒頭でも述べましたが、スタートアップフェーズで少人数でプロダクト開発を進めている最中なので、メンターである自分の開発業務も疎かにできません。実際に開発・運用しているプロダクトでしっかりアウトプットを出し続けることが大切なので、 インターン 生のレベル云々に関係なく、技術 インターン でもどうにか実際に稼働しているプロダクトでアウトプットを出せるような企画を考えました。 そこで以下のような企画の大枠イメージを定義しました。 インターン 生、自分、社会（会社）に価値を残すために、実プロダクト上でアウトプットをしっかり出す 実プロダクト上でアウトプットを出すことで得られる達成感や喜びを感じてもらう ひと通りの開発フローを経験してもらう メンターである自分にも開発業務があるので OJT 形式で行う 【企画 3】詳細な内容を決める ゴールと大枠を決めた後は、企画の詳細な内容を決めていきます。 以下のようなフェーズ 1〜4 を定義してみました。 フェーズ 1「基本的なウェブアプリケーション開発のフローを経験する」 今回の インターン 生のレベル感を踏まえて、まずは Ruby と Rails を使った基本的なウェブアプリケーション開発のフローを経験してもらうことにしました（ Ruby と Rails は今回関わる実プロダクトで使っているため）。そこで教材として Ruby on Rails チュートリアル：実例を使って Rails を学ぼう を使用しました。ご存知の方も多いと思いますが、 Ruby と Rails を使いながらウェブアプリケーション開発を体系的に学べるとても良い教材です。 Ruby と Rails はもちろんのこと、Git の使い方、デプロイ、テストといった実プロダクトの開発で必要不可欠な要素も含まれており、手厚いフォローがなくとも手を動かしながら進められるということで今回採用することになりました。 フェーズ 2「実プロダクトでウェブアプリケーション開発のフローを経験する（小〜中規模）」 フェーズ 1 で流れを掴んだら、ここから実プロダクトの開発に関わってもらうことにしました。まずは文言の修正や追加などを通じて実プロダクト上での開発フローを経験してもらいます。 フェーズ 3「実プロダクトでウェブアプリケーション開発のフローを経験する（中〜大規模）」 フェーズ 2 で慣れてきたらできる範囲で徐々に規模を大きくしていきます。 （小〜中、中〜大など抽象的なところはありますが、細かい定義は省略します） フェーズ 4「難しい課題解決にチャレンジしてアウトプットを出す」 フェーズ 3 の上位として実プロダクト上での難しい課題解決にチャレンジしてもらいます。ここは必須ではないですが、一応設定しておきました。 このような感じでフェーズに区切って定義してみました。 【企画 4】ゴールと内容を共有し認識を合わせる ゴールと内容が決まったら、それらを インターン 生に共有し、 インターン 生のやりたいこととズレがないようしっかり認識を合わせました。問題がなければ開始日からどういう流れで進めていくかのスケジュールもすり合わせし、開始日を待つことになります。 【実施】実際に実施した流れを紹介 いよいよ当日です。当初の計画通りにフェーズ 1 から実施しました。 実際にどういう流れで進んでいったか紹介してみます。 初日から 4 日目 フェーズ 1 の「 Ruby on Rails チュートリアル 」を進めた 「 Ruby on Rails チュートリアル 」の第 9 章のはじめくらいまで進めることができた 時間の都合もありここで「 Ruby on Rails チュートリアル 」は終了した 5 日目 ここから実プロダクトの開発環境構築を行った 早速実プロダクトの文言調整などを行った（ここでブランチ操作や PR の出し方なども経験） 6 日目から 9 日目 実プロダクトで小さい開発業務を数件こなした 表示まわりの調整が中心だが、データベースから必要なデータを取得したり、条件による出し分けをしたり、プロダクト開発で考えないといけないことを経験した ここまでで実プロダクト上でのひと通りの開発フローを経験した 10 日目から 13 日目 実プロダクトの中規模な開発業務を経験した（内容はメディア系のプロダクトの新規ページの追加） ルーティング、コントローラ、ビューなどのページ遷移に必要な処理を実装した 新規ページに表示する情報の取得、情報の整形や表示まわりの処理を実装した データーベースへのデータのインサート、アップデートなども経験した 14 日目から 17 日目 テストコードを追加した 普段手動で行っていたことの自動化をする スクリプト の開発をした（後回しにしていた課題などの解決） 日程の都合もありここで技術 インターン は一区切り こんな感じで一気に紹介してみましたが、随所で適宜フォローを入れつつ短期間で実プロダクト上でアウトプットをしっかり出すことができました。もちろん インターン 生の成果物はしっかりコードレビューと品質レビューをした後、本番にリリースされました。 【実施】感想 今回の技術 インターン 終了後、企画していたフェーズ 3 くらいまでは到達でき、 インターン 生からも当初の目的を満たせたという感想を頂くことができました。ひと通りの開発フローを経験できたこと、実プロダクト上で作ったものが本番環境にリリースされるドキドキや達成感を感じてもらえて、良い経験になったのではないかと思います。 スタートアップということで普段の開発業務と並行し、数日ガッツリ時間をとってフォローするなどはできませんでしたが、 インターン 生の目的を満たせたこと、そして実プロダクト上で新しい機能を追加してリリースできたり、普段の自分の業務で手が回らず後回しになっていた課題なども解決することができ、 インターン 生と自分、社会（会社）のために価値を残すことができたのではないかと思います。 さいごに ということで、今回はメドレーで実施した技術 インターン の事例を紹介してみました。スタートアップというフェーズらしく、意思決定も柔軟で、今回のような技術 インターン の企画・実施という突発的な業務であったり、会社の成長と共に生まれる様々な問題や課題の解決に奔走することも多々ありますが、それもまた醍醐味でしょう。働く環境の整備やエンジニアの文化形成も徐々に進められており、大変なこともありますがスタートアップフェーズでしか経験できないような濃い仕事がたくさんあります。集まっているメンバーは豊富な経験を持った 30 代が中心ですが、もちろん 20 代でも、医療 xIT で挑戦したいやる気ある方を募集中ですので、興味のある方はぜひご連絡ください！ www.wantedly.com

文責：徐　聖博（ ダーツプロ ） こんにちは！メドレーのダーツプロこと徐です。  社会人歴・エンジニア歴 3 年目ながら、メドレーでは 口コミで探せる介護施設の検索サイト「 介護のほんね 」の開発・運用を 1 人で担当 しています。（インフラ整備からフロントエンド開発まで行っています）  現在筆者が一人で担当している介護施設の口コミサイトである「 介護のほんね 」 前職では Web ゲームのバックエンド開発（ PHP ）を担当していて、メドレーに入った時点では 「インフラ？経験無いです…」 「フロントエンド？ Javascript で書くんですよね…？」 「 Ruby on Rails ？ Ruby なら書くだけかけますけど…」 という状態でした。今回はそんな自分が、入社後半年で フルスタ ックエンジニアとして 介護のほんね を 1 人で担当できるまでに至った、メドレーの開発体制について紹介します。 メドレーのプロダクト メドレーには Web アプリケーションから iOS のアプリケーションまで様々なプロダクトがあります。 サーバーサイドに Ruby on Rails を用いるプロダクトを初め、 PHP を使ったプロダクトもあり、構成はプロダクトにより様々です。フロントエンドでは、AngularJS や Mithril の MVC の フレームワーク を使用したり、 CoffeeScript や Babel なる AltJS を用いて開発しており、幅広い技術を採用しています。 サーバーサイドを Ruby on Rails で書き、Mithril を使い SPA で作られている「 CLINICS 」。インフラは、Heroku を採用。 CLINICS では、メドレーで初となる iOS アプリをリリース。 PHP の爆速 Phalcon フレームワーク を使用したオンライン病気事典「 MEDLEY 」 このように多種多様な技術を用いながら、どのプロダクトにおいてもメンバーはそれぞれインフラからフロントエンドまで幅広い開発をしています。しかし、もともと フルスタ ックエンジニアだったという人は少なく、尖った強みを持ちながら、メドレーに入社後、徐々に対応範囲を広げてきたというケースが多いです。  これは、メドレーにおける”機能ベース開発”という進め方が大きく関係しています。 機能ベース開発が、エンジニアを フルスタ ックにする メドレーでは、基本的に機能ベースで ISSUE ・タスクを切り分け、それぞれの ISSUE ・タスクを週のはじめのミーティングにおいて担当者を決めていきます。  それぞれ業務の幅が広いタスクがたくさんあり、週のはじめに担当を決めていく インフラやフロントエンドの得手不得手は各々ありますが、基本的には関係なくタスクが割り振られ（もしくは挙手制で）作業を進めていきます。 「知識が足りない・全く経験がないタスクが回ってきた！(> <)」などという場合も、お互い協力・教えあいながらタスクをこなしていくので、経験のないチャレンジングなタスクに挙手できたりします。  システム全体を把握して開発することで、プロダクト全体の品質向上 このタスクベース開発体制を続けていると、システム全体の開発に携わることが多くなります。入社当時はバックエンドしか知識がなかったエンジニアも、開発する機能が増え、プロダクト全体の構成を把握する機会が増えるため、入社から半年〜1 年経つ頃には、1 つのサービスを一通りインフラからバックエンド、フロントエンドまで触ることになります。  Elasticsearch の基盤整備から、DB の スキーマ 設計、バックエンド・フロントエンドの作りこみまで 全て一人で開発したジョブメドレーのトップ画面 こうしてシステム全体を把握することで、エンジニアたちがそれぞれ他の分野を考慮したプログラムを書けるようになり、 API の設計・ユーザインタラクション開発や、インフラ構成を配慮したキャッシュ機能開発など、一貫性をもった開発が可能となります。 もちろんもともと、特定分野に強みを持つエンジニアが集まっていますので、それぞれ得意分野を活かしつつも、お互いの領域が理解できることで、社内のプロダクトの全体的な最終的な品質向上を実現できていると感じています。 まとめ 今回はメドレーにおける機能ベースの開発体制を紹介しました。 メドレーでは、このようにどのプロダクトでも個人が機能ベースで開発をしていきます。そのため、入社時点で経験がない分野でも一年ほど開発に携わることで、一通りのインフラからフロントエンドまでの開発をこなせる知識がつき、僕も一人で 1 つのプロダクトを担当できるまでになりました。 しかし、これは機能ベース開発だけのおかげではなく、様々な分野のとても気さくなシニアエンジニアが集まり、気軽に質問できる開発部の雰囲気も大いに関係していると思っています。僕自身この 1 年で、さまざまな分野に挑戦しましたが、各領域のプロがレクチャーしてくれることで、その分野に自信をもって取り組めるようになったと感じています。 また、メドレーに集まるエンジニアは皆開発が大好きです。各々が日々技術に対して貪欲で、勉強が好き・開発が好きという個人の努力により、知らない困難なタスクも進んで開発した結果 フルスタ ックエンジニアになります。これが最終的なプロダクト品質へのこだわりになり、品質の高いプロダクトができているのだと思っています。 フルスタ ックな開発がしたい、システム全体考えた品質の高い開発をしたいような方は是非メドレーで一緒に働いてみませんか？ 勉強大好き、開発するのが大好き！ダーツが大好き！(？)というようなエンジニアをメドレーでは募集しています。  ぜひ、よろしくお願いします！ www.wantedly.com

文責：徐　聖博（ ダーツプロ ） こんにちは！メドレーのダーツプロこと徐です。  社会人歴・エンジニア歴 3 年目ながら、メドレーでは 口コミで探せる介護施設の検索サイト「 介護のほんね 」の開発・運用を 1 人で担当 しています。（インフラ整備からフロントエンド開発まで行っています）  現在筆者が一人で担当している介護施設の口コミサイトである「 介護のほんね 」 前職では Web ゲームのバックエンド開発（ PHP ）を担当していて、メドレーに入った時点では 「インフラ？経験無いです…」 「フロントエンド？ Javascript で書くんですよね…？」 「 Ruby on Rails ？ Ruby なら書くだけかけますけど…」 という状態でした。今回はそんな自分が、入社後半年で フルスタ ックエンジニアとして 介護のほんね を 1 人で担当できるまでに至った、メドレーの開発体制について紹介します。 メドレーのプロダクト メドレーには Web アプリケーションから iOS のアプリケーションまで様々なプロダクトがあります。 サーバーサイドに Ruby on Rails を用いるプロダクトを初め、 PHP を使ったプロダクトもあり、構成はプロダクトにより様々です。フロントエンドでは、AngularJS や Mithril の MVC の フレームワーク を使用したり、 CoffeeScript や Babel なる AltJS を用いて開発しており、幅広い技術を採用しています。 サーバーサイドを Ruby on Rails で書き、Mithril を使い SPA で作られている「 CLINICS 」。インフラは、Heroku を採用。 CLINICS では、メドレーで初となる iOS アプリをリリース。 PHP の爆速 Phalcon フレームワーク を使用したオンライン病気事典「 MEDLEY 」 このように多種多様な技術を用いながら、どのプロダクトにおいてもメンバーはそれぞれインフラからフロントエンドまで幅広い開発をしています。しかし、もともと フルスタ ックエンジニアだったという人は少なく、尖った強みを持ちながら、メドレーに入社後、徐々に対応範囲を広げてきたというケースが多いです。  これは、メドレーにおける”機能ベース開発”という進め方が大きく関係しています。 機能ベース開発が、エンジニアを フルスタ ックにする メドレーでは、基本的に機能ベースで ISSUE ・タスクを切り分け、それぞれの ISSUE ・タスクを週のはじめのミーティングにおいて担当者を決めていきます。  それぞれ業務の幅が広いタスクがたくさんあり、週のはじめに担当を決めていく インフラやフロントエンドの得手不得手は各々ありますが、基本的には関係なくタスクが割り振られ（もしくは挙手制で）作業を進めていきます。 「知識が足りない・全く経験がないタスクが回ってきた！(> <)」などという場合も、お互い協力・教えあいながらタスクをこなしていくので、経験のないチャレンジングなタスクに挙手できたりします。  システム全体を把握して開発することで、プロダクト全体の品質向上 このタスクベース開発体制を続けていると、システム全体の開発に携わることが多くなります。入社当時はバックエンドしか知識がなかったエンジニアも、開発する機能が増え、プロダクト全体の構成を把握する機会が増えるため、入社から半年〜1 年経つ頃には、1 つのサービスを一通りインフラからバックエンド、フロントエンドまで触ることになります。  Elasticsearch の基盤整備から、DB の スキーマ 設計、バックエンド・フロントエンドの作りこみまで 全て一人で開発したジョブメドレーのトップ画面 こうしてシステム全体を把握することで、エンジニアたちがそれぞれ他の分野を考慮したプログラムを書けるようになり、 API の設計・ユーザインタラクション開発や、インフラ構成を配慮したキャッシュ機能開発など、一貫性をもった開発が可能となります。 もちろんもともと、特定分野に強みを持つエンジニアが集まっていますので、それぞれ得意分野を活かしつつも、お互いの領域が理解できることで、社内のプロダクトの全体的な最終的な品質向上を実現できていると感じています。 まとめ 今回はメドレーにおける機能ベースの開発体制を紹介しました。 メドレーでは、このようにどのプロダクトでも個人が機能ベースで開発をしていきます。そのため、入社時点で経験がない分野でも一年ほど開発に携わることで、一通りのインフラからフロントエンドまでの開発をこなせる知識がつき、僕も一人で 1 つのプロダクトを担当できるまでになりました。 しかし、これは機能ベース開発だけのおかげではなく、様々な分野のとても気さくなシニアエンジニアが集まり、気軽に質問できる開発部の雰囲気も大いに関係していると思っています。僕自身この 1 年で、さまざまな分野に挑戦しましたが、各領域のプロがレクチャーしてくれることで、その分野に自信をもって取り組めるようになったと感じています。 また、メドレーに集まるエンジニアは皆開発が大好きです。各々が日々技術に対して貪欲で、勉強が好き・開発が好きという個人の努力により、知らない困難なタスクも進んで開発した結果 フルスタ ックエンジニアになります。これが最終的なプロダクト品質へのこだわりになり、品質の高いプロダクトができているのだと思っています。 フルスタ ックな開発がしたい、システム全体考えた品質の高い開発をしたいような方は是非メドレーで一緒に働いてみませんか？ 勉強大好き、開発するのが大好き！ダーツが大好き！(？)というようなエンジニアをメドレーでは募集しています。  ぜひ、よろしくお願いします！ www.wantedly.com

文責：徐　聖博（ ダーツプロ ） こんにちは！メドレーのダーツプロこと徐です。  社会人歴・エンジニア歴 3 年目ながら、メドレーでは 口コミで探せる介護施設の検索サイト「 介護のほんね 」の開発・運用を 1 人で担当 しています。（インフラ整備からフロントエンド開発まで行っています）  現在筆者が一人で担当している介護施設の口コミサイトである「 介護のほんね 」 前職では Web ゲームのバックエンド開発（ PHP ）を担当していて、メドレーに入った時点では 「インフラ？経験無いです…」 「フロントエンド？ Javascript で書くんですよね…？」 「 Ruby on Rails ？ Ruby なら書くだけかけますけど…」 という状態でした。今回はそんな自分が、入社後半年で フルスタ ックエンジニアとして 介護のほんね を 1 人で担当できるまでに至った、メドレーの開発体制について紹介します。 メドレーのプロダクト メドレーには Web アプリケーションから iOS のアプリケーションまで様々なプロダクトがあります。 サーバーサイドに Ruby on Rails を用いるプロダクトを初め、 PHP を使ったプロダクトもあり、構成はプロダクトにより様々です。フロントエンドでは、AngularJS や Mithril の MVC の フレームワーク を使用したり、 CoffeeScript や Babel なる AltJS を用いて開発しており、幅広い技術を採用しています。 サーバーサイドを Ruby on Rails で書き、Mithril を使い SPA で作られている「 CLINICS 」。インフラは、Heroku を採用。 CLINICS では、メドレーで初となる iOS アプリをリリース。 PHP の爆速 Phalcon フレームワーク を使用したオンライン病気事典「 MEDLEY 」 このように多種多様な技術を用いながら、どのプロダクトにおいてもメンバーはそれぞれインフラからフロントエンドまで幅広い開発をしています。しかし、もともと フルスタ ックエンジニアだったという人は少なく、尖った強みを持ちながら、メドレーに入社後、徐々に対応範囲を広げてきたというケースが多いです。  これは、メドレーにおける”機能ベース開発”という進め方が大きく関係しています。 機能ベース開発が、エンジニアを フルスタ ックにする メドレーでは、基本的に機能ベースで ISSUE ・タスクを切り分け、それぞれの ISSUE ・タスクを週のはじめのミーティングにおいて担当者を決めていきます。  それぞれ業務の幅が広いタスクがたくさんあり、週のはじめに担当を決めていく インフラやフロントエンドの得手不得手は各々ありますが、基本的には関係なくタスクが割り振られ（もしくは挙手制で）作業を進めていきます。 「知識が足りない・全く経験がないタスクが回ってきた！(> <)」などという場合も、お互い協力・教えあいながらタスクをこなしていくので、経験のないチャレンジングなタスクに挙手できたりします。  システム全体を把握して開発することで、プロダクト全体の品質向上 このタスクベース開発体制を続けていると、システム全体の開発に携わることが多くなります。入社当時はバックエンドしか知識がなかったエンジニアも、開発する機能が増え、プロダクト全体の構成を把握する機会が増えるため、入社から半年〜1 年経つ頃には、1 つのサービスを一通りインフラからバックエンド、フロントエンドまで触ることになります。  Elasticsearch の基盤整備から、DB の スキーマ 設計、バックエンド・フロントエンドの作りこみまで 全て一人で開発したジョブメドレーのトップ画面 こうしてシステム全体を把握することで、エンジニアたちがそれぞれ他の分野を考慮したプログラムを書けるようになり、 API の設計・ユーザインタラクション開発や、インフラ構成を配慮したキャッシュ機能開発など、一貫性をもった開発が可能となります。 もちろんもともと、特定分野に強みを持つエンジニアが集まっていますので、それぞれ得意分野を活かしつつも、お互いの領域が理解できることで、社内のプロダクトの全体的な最終的な品質向上を実現できていると感じています。 まとめ 今回はメドレーにおける機能ベースの開発体制を紹介しました。 メドレーでは、このようにどのプロダクトでも個人が機能ベースで開発をしていきます。そのため、入社時点で経験がない分野でも一年ほど開発に携わることで、一通りのインフラからフロントエンドまでの開発をこなせる知識がつき、僕も一人で 1 つのプロダクトを担当できるまでになりました。 しかし、これは機能ベース開発だけのおかげではなく、様々な分野のとても気さくなシニアエンジニアが集まり、気軽に質問できる開発部の雰囲気も大いに関係していると思っています。僕自身この 1 年で、さまざまな分野に挑戦しましたが、各領域のプロがレクチャーしてくれることで、その分野に自信をもって取り組めるようになったと感じています。 また、メドレーに集まるエンジニアは皆開発が大好きです。各々が日々技術に対して貪欲で、勉強が好き・開発が好きという個人の努力により、知らない困難なタスクも進んで開発した結果 フルスタ ックエンジニアになります。これが最終的なプロダクト品質へのこだわりになり、品質の高いプロダクトができているのだと思っています。 フルスタ ックな開発がしたい、システム全体考えた品質の高い開発をしたいような方は是非メドレーで一緒に働いてみませんか？ 勉強大好き、開発するのが大好き！ダーツが大好き！(？)というようなエンジニアをメドレーでは募集しています。  ぜひ、よろしくお願いします！ www.wantedly.com

文責：徐　聖博（ ダーツプロ ） こんにちは！メドレーのダーツプロこと徐です。  社会人歴・エンジニア歴 3 年目ながら、メドレーでは 口コミで探せる介護施設の検索サイト「 介護のほんね 」の開発・運用を 1 人で担当 しています。（インフラ整備からフロントエンド開発まで行っています）  現在筆者が一人で担当している介護施設の口コミサイトである「 介護のほんね 」 前職では Web ゲームのバックエンド開発（ PHP ）を担当していて、メドレーに入った時点では 「インフラ？経験無いです…」 「フロントエンド？ Javascript で書くんですよね…？」 「 Ruby on Rails ？ Ruby なら書くだけかけますけど…」 という状態でした。今回はそんな自分が、入社後半年で フルスタ ックエンジニアとして 介護のほんね を 1 人で担当できるまでに至った、メドレーの開発体制について紹介します。 メドレーのプロダクト メドレーには Web アプリケーションから iOS のアプリケーションまで様々なプロダクトがあります。 サーバーサイドに Ruby on Rails を用いるプロダクトを初め、 PHP を使ったプロダクトもあり、構成はプロダクトにより様々です。フロントエンドでは、AngularJS や Mithril の MVC の フレームワーク を使用したり、 CoffeeScript や Babel なる AltJS を用いて開発しており、幅広い技術を採用しています。 サーバーサイドを Ruby on Rails で書き、Mithril を使い SPA で作られている「 CLINICS 」。インフラは、Heroku を採用。 CLINICS では、メドレーで初となる iOS アプリをリリース。 PHP の爆速 Phalcon フレームワーク を使用したオンライン病気事典「 MEDLEY 」 このように多種多様な技術を用いながら、どのプロダクトにおいてもメンバーはそれぞれインフラからフロントエンドまで幅広い開発をしています。しかし、もともと フルスタ ックエンジニアだったという人は少なく、尖った強みを持ちながら、メドレーに入社後、徐々に対応範囲を広げてきたというケースが多いです。  これは、メドレーにおける”機能ベース開発”という進め方が大きく関係しています。 機能ベース開発が、エンジニアを フルスタ ックにする メドレーでは、基本的に機能ベースで ISSUE ・タスクを切り分け、それぞれの ISSUE ・タスクを週のはじめのミーティングにおいて担当者を決めていきます。  それぞれ業務の幅が広いタスクがたくさんあり、週のはじめに担当を決めていく インフラやフロントエンドの得手不得手は各々ありますが、基本的には関係なくタスクが割り振られ（もしくは挙手制で）作業を進めていきます。 「知識が足りない・全く経験がないタスクが回ってきた！(> <)」などという場合も、お互い協力・教えあいながらタスクをこなしていくので、経験のないチャレンジングなタスクに挙手できたりします。  システム全体を把握して開発することで、プロダクト全体の品質向上 このタスクベース開発体制を続けていると、システム全体の開発に携わることが多くなります。入社当時はバックエンドしか知識がなかったエンジニアも、開発する機能が増え、プロダクト全体の構成を把握する機会が増えるため、入社から半年〜1 年経つ頃には、1 つのサービスを一通りインフラからバックエンド、フロントエンドまで触ることになります。  Elasticsearch の基盤整備から、DB の スキーマ 設計、バックエンド・フロントエンドの作りこみまで 全て一人で開発したジョブメドレーのトップ画面 こうしてシステム全体を把握することで、エンジニアたちがそれぞれ他の分野を考慮したプログラムを書けるようになり、 API の設計・ユーザインタラクション開発や、インフラ構成を配慮したキャッシュ機能開発など、一貫性をもった開発が可能となります。 もちろんもともと、特定分野に強みを持つエンジニアが集まっていますので、それぞれ得意分野を活かしつつも、お互いの領域が理解できることで、社内のプロダクトの全体的な最終的な品質向上を実現できていると感じています。 まとめ 今回はメドレーにおける機能ベースの開発体制を紹介しました。 メドレーでは、このようにどのプロダクトでも個人が機能ベースで開発をしていきます。そのため、入社時点で経験がない分野でも一年ほど開発に携わることで、一通りのインフラからフロントエンドまでの開発をこなせる知識がつき、僕も一人で 1 つのプロダクトを担当できるまでになりました。 しかし、これは機能ベース開発だけのおかげではなく、様々な分野のとても気さくなシニアエンジニアが集まり、気軽に質問できる開発部の雰囲気も大いに関係していると思っています。僕自身この 1 年で、さまざまな分野に挑戦しましたが、各領域のプロがレクチャーしてくれることで、その分野に自信をもって取り組めるようになったと感じています。 また、メドレーに集まるエンジニアは皆開発が大好きです。各々が日々技術に対して貪欲で、勉強が好き・開発が好きという個人の努力により、知らない困難なタスクも進んで開発した結果 フルスタ ックエンジニアになります。これが最終的なプロダクト品質へのこだわりになり、品質の高いプロダクトができているのだと思っています。 フルスタ ックな開発がしたい、システム全体考えた品質の高い開発をしたいような方は是非メドレーで一緒に働いてみませんか？ 勉強大好き、開発するのが大好き！ダーツが大好き！(？)というようなエンジニアをメドレーでは募集しています。  ぜひ、よろしくお願いします！ www.wantedly.com

文責：徐　聖博（ ダーツプロ ） こんにちは！メドレーのダーツプロこと徐です。  社会人歴・エンジニア歴 3 年目ながら、メドレーでは 口コミで探せる介護施設の検索サイト「 介護のほんね 」の開発・運用を 1 人で担当 しています。（インフラ整備からフロントエンド開発まで行っています）  現在筆者が一人で担当している介護施設の口コミサイトである「 介護のほんね 」 前職では Web ゲームのバックエンド開発（ PHP ）を担当していて、メドレーに入った時点では 「インフラ？経験無いです…」 「フロントエンド？ Javascript で書くんですよね…？」 「 Ruby on Rails ？ Ruby なら書くだけかけますけど…」 という状態でした。今回はそんな自分が、入社後半年で フルスタ ックエンジニアとして 介護のほんね を 1 人で担当できるまでに至った、メドレーの開発体制について紹介します。 メドレーのプロダクト メドレーには Web アプリケーションから iOS のアプリケーションまで様々なプロダクトがあります。 サーバーサイドに Ruby on Rails を用いるプロダクトを初め、 PHP を使ったプロダクトもあり、構成はプロダクトにより様々です。フロントエンドでは、AngularJS や Mithril の MVC の フレームワーク を使用したり、 CoffeeScript や Babel なる AltJS を用いて開発しており、幅広い技術を採用しています。 サーバーサイドを Ruby on Rails で書き、Mithril を使い SPA で作られている「 CLINICS 」。インフラは、Heroku を採用。 CLINICS では、メドレーで初となる iOS アプリをリリース。 PHP の爆速 Phalcon フレームワーク を使用したオンライン病気事典「 MEDLEY 」 このように多種多様な技術を用いながら、どのプロダクトにおいてもメンバーはそれぞれインフラからフロントエンドまで幅広い開発をしています。しかし、もともと フルスタ ックエンジニアだったという人は少なく、尖った強みを持ちながら、メドレーに入社後、徐々に対応範囲を広げてきたというケースが多いです。  これは、メドレーにおける”機能ベース開発”という進め方が大きく関係しています。 機能ベース開発が、エンジニアを フルスタ ックにする メドレーでは、基本的に機能ベースで ISSUE ・タスクを切り分け、それぞれの ISSUE ・タスクを週のはじめのミーティングにおいて担当者を決めていきます。  それぞれ業務の幅が広いタスクがたくさんあり、週のはじめに担当を決めていく インフラやフロントエンドの得手不得手は各々ありますが、基本的には関係なくタスクが割り振られ（もしくは挙手制で）作業を進めていきます。 「知識が足りない・全く経験がないタスクが回ってきた！(> <)」などという場合も、お互い協力・教えあいながらタスクをこなしていくので、経験のないチャレンジングなタスクに挙手できたりします。  システム全体を把握して開発することで、プロダクト全体の品質向上 このタスクベース開発体制を続けていると、システム全体の開発に携わることが多くなります。入社当時はバックエンドしか知識がなかったエンジニアも、開発する機能が増え、プロダクト全体の構成を把握する機会が増えるため、入社から半年〜1 年経つ頃には、1 つのサービスを一通りインフラからバックエンド、フロントエンドまで触ることになります。  Elasticsearch の基盤整備から、DB の スキーマ 設計、バックエンド・フロントエンドの作りこみまで 全て一人で開発したジョブメドレーのトップ画面 こうしてシステム全体を把握することで、エンジニアたちがそれぞれ他の分野を考慮したプログラムを書けるようになり、 API の設計・ユーザインタラクション開発や、インフラ構成を配慮したキャッシュ機能開発など、一貫性をもった開発が可能となります。 もちろんもともと、特定分野に強みを持つエンジニアが集まっていますので、それぞれ得意分野を活かしつつも、お互いの領域が理解できることで、社内のプロダクトの全体的な最終的な品質向上を実現できていると感じています。 まとめ 今回はメドレーにおける機能ベースの開発体制を紹介しました。 メドレーでは、このようにどのプロダクトでも個人が機能ベースで開発をしていきます。そのため、入社時点で経験がない分野でも一年ほど開発に携わることで、一通りのインフラからフロントエンドまでの開発をこなせる知識がつき、僕も一人で 1 つのプロダクトを担当できるまでになりました。 しかし、これは機能ベース開発だけのおかげではなく、様々な分野のとても気さくなシニアエンジニアが集まり、気軽に質問できる開発部の雰囲気も大いに関係していると思っています。僕自身この 1 年で、さまざまな分野に挑戦しましたが、各領域のプロがレクチャーしてくれることで、その分野に自信をもって取り組めるようになったと感じています。 また、メドレーに集まるエンジニアは皆開発が大好きです。各々が日々技術に対して貪欲で、勉強が好き・開発が好きという個人の努力により、知らない困難なタスクも進んで開発した結果 フルスタ ックエンジニアになります。これが最終的なプロダクト品質へのこだわりになり、品質の高いプロダクトができているのだと思っています。 フルスタ ックな開発がしたい、システム全体考えた品質の高い開発をしたいような方は是非メドレーで一緒に働いてみませんか？ 勉強大好き、開発するのが大好き！ダーツが大好き！(？)というようなエンジニアをメドレーでは募集しています。  ぜひ、よろしくお願いします！ www.wantedly.com

文責：徐　聖博（ ダーツプロ ） こんにちは！メドレーのダーツプロこと徐です。  社会人歴・エンジニア歴 3 年目ながら、メドレーでは 口コミで探せる介護施設の検索サイト「 介護のほんね 」の開発・運用を 1 人で担当 しています。（インフラ整備からフロントエンド開発まで行っています）  現在筆者が一人で担当している介護施設の口コミサイトである「 介護のほんね 」 前職では Web ゲームのバックエンド開発（ PHP ）を担当していて、メドレーに入った時点では 「インフラ？経験無いです…」 「フロントエンド？ Javascript で書くんですよね…？」 「 Ruby on Rails ？ Ruby なら書くだけかけますけど…」 という状態でした。今回はそんな自分が、入社後半年で フルスタ ックエンジニアとして 介護のほんね を 1 人で担当できるまでに至った、メドレーの開発体制について紹介します。 メドレーのプロダクト メドレーには Web アプリケーションから iOS のアプリケーションまで様々なプロダクトがあります。 サーバーサイドに Ruby on Rails を用いるプロダクトを初め、 PHP を使ったプロダクトもあり、構成はプロダクトにより様々です。フロントエンドでは、AngularJS や Mithril の MVC の フレームワーク を使用したり、 CoffeeScript や Babel なる AltJS を用いて開発しており、幅広い技術を採用しています。 サーバーサイドを Ruby on Rails で書き、Mithril を使い SPA で作られている「 CLINICS 」。インフラは、Heroku を採用。 CLINICS では、メドレーで初となる iOS アプリをリリース。 PHP の爆速 Phalcon フレームワーク を使用したオンライン病気事典「 MEDLEY 」 このように多種多様な技術を用いながら、どのプロダクトにおいてもメンバーはそれぞれインフラからフロントエンドまで幅広い開発をしています。しかし、もともと フルスタ ックエンジニアだったという人は少なく、尖った強みを持ちながら、メドレーに入社後、徐々に対応範囲を広げてきたというケースが多いです。  これは、メドレーにおける”機能ベース開発”という進め方が大きく関係しています。 機能ベース開発が、エンジニアを フルスタ ックにする メドレーでは、基本的に機能ベースで ISSUE ・タスクを切り分け、それぞれの ISSUE ・タスクを週のはじめのミーティングにおいて担当者を決めていきます。  それぞれ業務の幅が広いタスクがたくさんあり、週のはじめに担当を決めていく インフラやフロントエンドの得手不得手は各々ありますが、基本的には関係なくタスクが割り振られ（もしくは挙手制で）作業を進めていきます。 「知識が足りない・全く経験がないタスクが回ってきた！(> <)」などという場合も、お互い協力・教えあいながらタスクをこなしていくので、経験のないチャレンジングなタスクに挙手できたりします。  システム全体を把握して開発することで、プロダクト全体の品質向上 このタスクベース開発体制を続けていると、システム全体の開発に携わることが多くなります。入社当時はバックエンドしか知識がなかったエンジニアも、開発する機能が増え、プロダクト全体の構成を把握する機会が増えるため、入社から半年〜1 年経つ頃には、1 つのサービスを一通りインフラからバックエンド、フロントエンドまで触ることになります。  Elasticsearch の基盤整備から、DB の スキーマ 設計、バックエンド・フロントエンドの作りこみまで 全て一人で開発したジョブメドレーのトップ画面 こうしてシステム全体を把握することで、エンジニアたちがそれぞれ他の分野を考慮したプログラムを書けるようになり、 API の設計・ユーザインタラクション開発や、インフラ構成を配慮したキャッシュ機能開発など、一貫性をもった開発が可能となります。 もちろんもともと、特定分野に強みを持つエンジニアが集まっていますので、それぞれ得意分野を活かしつつも、お互いの領域が理解できることで、社内のプロダクトの全体的な最終的な品質向上を実現できていると感じています。 まとめ 今回はメドレーにおける機能ベースの開発体制を紹介しました。 メドレーでは、このようにどのプロダクトでも個人が機能ベースで開発をしていきます。そのため、入社時点で経験がない分野でも一年ほど開発に携わることで、一通りのインフラからフロントエンドまでの開発をこなせる知識がつき、僕も一人で 1 つのプロダクトを担当できるまでになりました。 しかし、これは機能ベース開発だけのおかげではなく、様々な分野のとても気さくなシニアエンジニアが集まり、気軽に質問できる開発部の雰囲気も大いに関係していると思っています。僕自身この 1 年で、さまざまな分野に挑戦しましたが、各領域のプロがレクチャーしてくれることで、その分野に自信をもって取り組めるようになったと感じています。 また、メドレーに集まるエンジニアは皆開発が大好きです。各々が日々技術に対して貪欲で、勉強が好き・開発が好きという個人の努力により、知らない困難なタスクも進んで開発した結果 フルスタ ックエンジニアになります。これが最終的なプロダクト品質へのこだわりになり、品質の高いプロダクトができているのだと思っています。 フルスタ ックな開発がしたい、システム全体考えた品質の高い開発をしたいような方は是非メドレーで一緒に働いてみませんか？ 勉強大好き、開発するのが大好き！ダーツが大好き！(？)というようなエンジニアをメドレーでは募集しています。  ぜひ、よろしくお願いします！ www.wantedly.com