こんにちは、エンジニア兼 ダーツプロ の徐です。 2016 年 11 月 14 日（水）に株式会社 ドリコム さんのイベントスペースをお借りして、 エムスリー株式会社 さんとの合同勉強会を開催しました。 「医療系サービスにおけるエンジニア運用裏話」というテーマで、泥臭い・苦労した話やそれをどう工夫したかについて発表しました。 発表の様子 “開発”と言えば、「新規機能追加」を想像される方が多いのではないでしょうか。 しかし、実際現場で働くエンジニアは、新規開発をするのと並行して、安定したサービスを提供し続けるために日々努力しています。 大勢の人々が”当たり前に動くサービス”を実現するために、一生懸命になっているのです。 今回の勉強会はこうした各社の苦い話や知見を持ち寄った会となりました。 当日は各社 2 名ずつ、15 分弱の LT を行いました。 メドレーの発表内容を少しだけご紹介します。 1 人開発体制における運用と工夫 介護のほんね奮闘記 まずは私、徐より介護施設の口コミサイト「 介護のほんね 」 を、エンジニア 1 人でどう運用しているかについてご紹介しました。 １人で運用する際の苦労は何か、そして１人で運用する過程で大事なこととは何かについて紹介していきました。 必ずしもシステム的な工夫だけではなく、周りのメンバーにうまく協力をしてもらう姿勢について、日々の心がけなどを話しました。 人前での発表が不慣れで緊張している私… 発表資料は こちら オンライン病気事典 MEDLEY の 地味だけど重要な 運用の話 そして、オンライン病気事典「 MEDLEY 」を担当する 竹内 からは、運用の裏側として 小規模チームに起きる問題 とそれを解決する方法についての紹介がありました。 今回は、開発ばかりしているとつい疎かになりがちな**「運用手順書」**にスポットを当て、手順書を作成している際に気をつけているポイントについて解説しました。 発表資料は こちら まとめ 今回の勉強会では、普段なかなか取り扱われない”運用”をテーマにし、苦労した点やそれを工夫した点など”地味だけど大事な”ことについて、各社のノウハウを話し合うことができました。 エンジニアの仕事は、新規機能開発より運用のほうが割合が高いことから、日々の業務のなかで共感できる・役に立つ話をできるのでは、と考え勉強会を企画しました。 発表中に「そうだよね」と頷く参加者の方もいらっしゃり、さらに終了後の懇親会では「すごい共感しました…」といった感想をいただくなど、参加者の方にも楽しんでいただけた企画となったのではと感じています。 運用は、システム的な自動化の工夫ももちろんですが、人が人力作業でやるものもあります。 エムスリーさんからも実状やノウハウを（ぶっちゃけ話も織り交ぜながら）伺えましたが、いずれも運用においてオンライン・オフラインを問わず**「コミュニケーション」（人間関係）**が大事なんだなと感じました。 勉強会後の懇親会の様子。共感した・参考になったという話が多く飛び交いました。 今後もこうした実際の現場で役に立つ勉強会を定期的に開催していく予定です。 MedNightTokyo の Connpass グループで最新情報を発信してまいりますので、今回は残念ながら参加できなかった方も是非フォローをお願いします。 mednight.connpass.com メドレーブログでも、勉強会情報を掲載していくので、ブログも引き続きチェックしてくださいね。 ※ メドレー公式 Facebook ページ に「いいね！」していただけると、ブログの最新情報をフォローできます

こんにちは、エンジニア兼 ダーツプロ の徐です。 2016 年 11 月 14 日（水）に株式会社 ドリコム さんのイベントスペースをお借りして、 エムスリー株式会社 さんとの合同勉強会を開催しました。 「医療系サービスにおけるエンジニア運用裏話」というテーマで、泥臭い・苦労した話やそれをどう工夫したかについて発表しました。 発表の様子 “開発”と言えば、「新規機能追加」を想像される方が多いのではないでしょうか。 しかし、実際現場で働くエンジニアは、新規開発をするのと並行して、安定したサービスを提供し続けるために日々努力しています。 大勢の人々が”当たり前に動くサービス”を実現するために、一生懸命になっているのです。 今回の勉強会はこうした各社の苦い話や知見を持ち寄った会となりました。 当日は各社 2 名ずつ、15 分弱の LT を行いました。 メドレーの発表内容を少しだけご紹介します。 1 人開発体制における運用と工夫 介護のほんね奮闘記 まずは私、徐より介護施設の口コミサイト「 介護のほんね 」 を、エンジニア 1 人でどう運用しているかについてご紹介しました。 １人で運用する際の苦労は何か、そして１人で運用する過程で大事なこととは何かについて紹介していきました。 必ずしもシステム的な工夫だけではなく、周りのメンバーにうまく協力をしてもらう姿勢について、日々の心がけなどを話しました。 人前での発表が不慣れで緊張している私… 発表資料は こちら オンライン病気事典 MEDLEY の 地味だけど重要な 運用の話 そして、オンライン病気事典「 MEDLEY 」を担当する 竹内 からは、運用の裏側として 小規模チームに起きる問題 とそれを解決する方法についての紹介がありました。 今回は、開発ばかりしているとつい疎かになりがちな**「運用手順書」**にスポットを当て、手順書を作成している際に気をつけているポイントについて解説しました。 発表資料は こちら まとめ 今回の勉強会では、普段なかなか取り扱われない”運用”をテーマにし、苦労した点やそれを工夫した点など”地味だけど大事な”ことについて、各社のノウハウを話し合うことができました。 エンジニアの仕事は、新規機能開発より運用のほうが割合が高いことから、日々の業務のなかで共感できる・役に立つ話をできるのでは、と考え勉強会を企画しました。 発表中に「そうだよね」と頷く参加者の方もいらっしゃり、さらに終了後の懇親会では「すごい共感しました…」といった感想をいただくなど、参加者の方にも楽しんでいただけた企画となったのではと感じています。 運用は、システム的な自動化の工夫ももちろんですが、人が人力作業でやるものもあります。 エムスリーさんからも実状やノウハウを（ぶっちゃけ話も織り交ぜながら）伺えましたが、いずれも運用においてオンライン・オフラインを問わず**「コミュニケーション」（人間関係）**が大事なんだなと感じました。 勉強会後の懇親会の様子。共感した・参考になったという話が多く飛び交いました。 今後もこうした実際の現場で役に立つ勉強会を定期的に開催していく予定です。 MedNightTokyo の Connpass グループで最新情報を発信してまいりますので、今回は残念ながら参加できなかった方も是非フォローをお願いします。 mednight.connpass.com メドレーブログでも、勉強会情報を掲載していくので、ブログも引き続きチェックしてくださいね。 ※ メドレー公式 Facebook ページ に「いいね！」していただけると、ブログの最新情報をフォローできます

こんにちは、エンジニア兼 ダーツプロ の徐です。 2016 年 11 月 14 日（水）に株式会社 ドリコム さんのイベントスペースをお借りして、 エムスリー株式会社 さんとの合同勉強会を開催しました。 「医療系サービスにおけるエンジニア運用裏話」というテーマで、泥臭い・苦労した話やそれをどう工夫したかについて発表しました。 発表の様子 “開発”と言えば、「新規機能追加」を想像される方が多いのではないでしょうか。 しかし、実際現場で働くエンジニアは、新規開発をするのと並行して、安定したサービスを提供し続けるために日々努力しています。 大勢の人々が”当たり前に動くサービス”を実現するために、一生懸命になっているのです。 今回の勉強会はこうした各社の苦い話や知見を持ち寄った会となりました。 当日は各社 2 名ずつ、15 分弱の LT を行いました。 メドレーの発表内容を少しだけご紹介します。 1 人開発体制における運用と工夫 介護のほんね奮闘記 まずは私、徐より介護施設の口コミサイト「 介護のほんね 」 を、エンジニア 1 人でどう運用しているかについてご紹介しました。 １人で運用する際の苦労は何か、そして１人で運用する過程で大事なこととは何かについて紹介していきました。 必ずしもシステム的な工夫だけではなく、周りのメンバーにうまく協力をしてもらう姿勢について、日々の心がけなどを話しました。 人前での発表が不慣れで緊張している私… 発表資料は こちら オンライン病気事典 MEDLEY の 地味だけど重要な 運用の話 そして、オンライン病気事典「 MEDLEY 」を担当する 竹内 からは、運用の裏側として 小規模チームに起きる問題 とそれを解決する方法についての紹介がありました。 今回は、開発ばかりしているとつい疎かになりがちな**「運用手順書」**にスポットを当て、手順書を作成している際に気をつけているポイントについて解説しました。 発表資料は こちら まとめ 今回の勉強会では、普段なかなか取り扱われない”運用”をテーマにし、苦労した点やそれを工夫した点など”地味だけど大事な”ことについて、各社のノウハウを話し合うことができました。 エンジニアの仕事は、新規機能開発より運用のほうが割合が高いことから、日々の業務のなかで共感できる・役に立つ話をできるのでは、と考え勉強会を企画しました。 発表中に「そうだよね」と頷く参加者の方もいらっしゃり、さらに終了後の懇親会では「すごい共感しました…」といった感想をいただくなど、参加者の方にも楽しんでいただけた企画となったのではと感じています。 運用は、システム的な自動化の工夫ももちろんですが、人が人力作業でやるものもあります。 エムスリーさんからも実状やノウハウを（ぶっちゃけ話も織り交ぜながら）伺えましたが、いずれも運用においてオンライン・オフラインを問わず**「コミュニケーション」（人間関係）**が大事なんだなと感じました。 勉強会後の懇親会の様子。共感した・参考になったという話が多く飛び交いました。 今後もこうした実際の現場で役に立つ勉強会を定期的に開催していく予定です。 MedNightTokyo の Connpass グループで最新情報を発信してまいりますので、今回は残念ながら参加できなかった方も是非フォローをお願いします。 mednight.connpass.com メドレーブログでも、勉強会情報を掲載していくので、ブログも引き続きチェックしてくださいね。 ※ メドレー公式 Facebook ページ に「いいね！」していただけると、ブログの最新情報をフォローできます

こんにちは、エンジニア兼 ダーツプロ の徐です。 2016 年 11 月 14 日（水）に株式会社 ドリコム さんのイベントスペースをお借りして、 エムスリー株式会社 さんとの合同勉強会を開催しました。 「医療系サービスにおけるエンジニア運用裏話」というテーマで、泥臭い・苦労した話やそれをどう工夫したかについて発表しました。 発表の様子 “開発”と言えば、「新規機能追加」を想像される方が多いのではないでしょうか。 しかし、実際現場で働くエンジニアは、新規開発をするのと並行して、安定したサービスを提供し続けるために日々努力しています。 大勢の人々が”当たり前に動くサービス”を実現するために、一生懸命になっているのです。 今回の勉強会はこうした各社の苦い話や知見を持ち寄った会となりました。 当日は各社 2 名ずつ、15 分弱の LT を行いました。 メドレーの発表内容を少しだけご紹介します。 1 人開発体制における運用と工夫 介護のほんね奮闘記 まずは私、徐より介護施設の口コミサイト「 介護のほんね 」 を、エンジニア 1 人でどう運用しているかについてご紹介しました。 １人で運用する際の苦労は何か、そして１人で運用する過程で大事なこととは何かについて紹介していきました。 必ずしもシステム的な工夫だけではなく、周りのメンバーにうまく協力をしてもらう姿勢について、日々の心がけなどを話しました。 人前での発表が不慣れで緊張している私… 発表資料は こちら オンライン病気事典 MEDLEY の 地味だけど重要な 運用の話 そして、オンライン病気事典「 MEDLEY 」を担当する 竹内 からは、運用の裏側として 小規模チームに起きる問題 とそれを解決する方法についての紹介がありました。 今回は、開発ばかりしているとつい疎かになりがちな**「運用手順書」**にスポットを当て、手順書を作成している際に気をつけているポイントについて解説しました。 発表資料は こちら まとめ 今回の勉強会では、普段なかなか取り扱われない”運用”をテーマにし、苦労した点やそれを工夫した点など”地味だけど大事な”ことについて、各社のノウハウを話し合うことができました。 エンジニアの仕事は、新規機能開発より運用のほうが割合が高いことから、日々の業務のなかで共感できる・役に立つ話をできるのでは、と考え勉強会を企画しました。 発表中に「そうだよね」と頷く参加者の方もいらっしゃり、さらに終了後の懇親会では「すごい共感しました…」といった感想をいただくなど、参加者の方にも楽しんでいただけた企画となったのではと感じています。 運用は、システム的な自動化の工夫ももちろんですが、人が人力作業でやるものもあります。 エムスリーさんからも実状やノウハウを（ぶっちゃけ話も織り交ぜながら）伺えましたが、いずれも運用においてオンライン・オフラインを問わず**「コミュニケーション」（人間関係）**が大事なんだなと感じました。 勉強会後の懇親会の様子。共感した・参考になったという話が多く飛び交いました。 今後もこうした実際の現場で役に立つ勉強会を定期的に開催していく予定です。 MedNightTokyo の Connpass グループで最新情報を発信してまいりますので、今回は残念ながら参加できなかった方も是非フォローをお願いします。 mednight.connpass.com メドレーブログでも、勉強会情報を掲載していくので、ブログも引き続きチェックしてくださいね。 ※ メドレー公式 Facebook ページ に「いいね！」していただけると、ブログの最新情報をフォローできます

こんにちは、エンジニア兼 ダーツプロ の徐です。 2016 年 11 月 14 日（水）に株式会社 ドリコム さんのイベントスペースをお借りして、 エムスリー株式会社 さんとの合同勉強会を開催しました。 「医療系サービスにおけるエンジニア運用裏話」というテーマで、泥臭い・苦労した話やそれをどう工夫したかについて発表しました。 発表の様子 “開発”と言えば、「新規機能追加」を想像される方が多いのではないでしょうか。 しかし、実際現場で働くエンジニアは、新規開発をするのと並行して、安定したサービスを提供し続けるために日々努力しています。 大勢の人々が”当たり前に動くサービス”を実現するために、一生懸命になっているのです。 今回の勉強会はこうした各社の苦い話や知見を持ち寄った会となりました。 当日は各社 2 名ずつ、15 分弱の LT を行いました。 メドレーの発表内容を少しだけご紹介します。 1 人開発体制における運用と工夫 介護のほんね奮闘記 まずは私、徐より介護施設の口コミサイト「 介護のほんね 」 を、エンジニア 1 人でどう運用しているかについてご紹介しました。 １人で運用する際の苦労は何か、そして１人で運用する過程で大事なこととは何かについて紹介していきました。 必ずしもシステム的な工夫だけではなく、周りのメンバーにうまく協力をしてもらう姿勢について、日々の心がけなどを話しました。 人前での発表が不慣れで緊張している私… 発表資料は こちら オンライン病気事典 MEDLEY の 地味だけど重要な 運用の話 そして、オンライン病気事典「 MEDLEY 」を担当する 竹内 からは、運用の裏側として 小規模チームに起きる問題 とそれを解決する方法についての紹介がありました。 今回は、開発ばかりしているとつい疎かになりがちな**「運用手順書」**にスポットを当て、手順書を作成している際に気をつけているポイントについて解説しました。 発表資料は こちら まとめ 今回の勉強会では、普段なかなか取り扱われない”運用”をテーマにし、苦労した点やそれを工夫した点など”地味だけど大事な”ことについて、各社のノウハウを話し合うことができました。 エンジニアの仕事は、新規機能開発より運用のほうが割合が高いことから、日々の業務のなかで共感できる・役に立つ話をできるのでは、と考え勉強会を企画しました。 発表中に「そうだよね」と頷く参加者の方もいらっしゃり、さらに終了後の懇親会では「すごい共感しました…」といった感想をいただくなど、参加者の方にも楽しんでいただけた企画となったのではと感じています。 運用は、システム的な自動化の工夫ももちろんですが、人が人力作業でやるものもあります。 エムスリーさんからも実状やノウハウを（ぶっちゃけ話も織り交ぜながら）伺えましたが、いずれも運用においてオンライン・オフラインを問わず**「コミュニケーション」（人間関係）**が大事なんだなと感じました。 勉強会後の懇親会の様子。共感した・参考になったという話が多く飛び交いました。 今後もこうした実際の現場で役に立つ勉強会を定期的に開催していく予定です。 MedNightTokyo の Connpass グループで最新情報を発信してまいりますので、今回は残念ながら参加できなかった方も是非フォローをお願いします。 mednight.connpass.com メドレーブログでも、勉強会情報を掲載していくので、ブログも引き続きチェックしてくださいね。 ※ メドレー公式 Facebook ページ に「いいね！」していただけると、ブログの最新情報をフォローできます

こんにちは、エンジニア兼 ダーツプロ の徐です。 2016 年 11 月 14 日（水）に株式会社 ドリコム さんのイベントスペースをお借りして、 エムスリー株式会社 さんとの合同勉強会を開催しました。 「医療系サービスにおけるエンジニア運用裏話」というテーマで、泥臭い・苦労した話やそれをどう工夫したかについて発表しました。 発表の様子 “開発”と言えば、「新規機能追加」を想像される方が多いのではないでしょうか。 しかし、実際現場で働くエンジニアは、新規開発をするのと並行して、安定したサービスを提供し続けるために日々努力しています。 大勢の人々が”当たり前に動くサービス”を実現するために、一生懸命になっているのです。 今回の勉強会はこうした各社の苦い話や知見を持ち寄った会となりました。 当日は各社 2 名ずつ、15 分弱の LT を行いました。 メドレーの発表内容を少しだけご紹介します。 1 人開発体制における運用と工夫 介護のほんね奮闘記 まずは私、徐より介護施設の口コミサイト「 介護のほんね 」 を、エンジニア 1 人でどう運用しているかについてご紹介しました。 １人で運用する際の苦労は何か、そして１人で運用する過程で大事なこととは何かについて紹介していきました。 必ずしもシステム的な工夫だけではなく、周りのメンバーにうまく協力をしてもらう姿勢について、日々の心がけなどを話しました。 人前での発表が不慣れで緊張している私… 発表資料は こちら オンライン病気事典 MEDLEY の 地味だけど重要な 運用の話 そして、オンライン病気事典「 MEDLEY 」を担当する 竹内 からは、運用の裏側として 小規模チームに起きる問題 とそれを解決する方法についての紹介がありました。 今回は、開発ばかりしているとつい疎かになりがちな**「運用手順書」**にスポットを当て、手順書を作成している際に気をつけているポイントについて解説しました。 発表資料は こちら まとめ 今回の勉強会では、普段なかなか取り扱われない”運用”をテーマにし、苦労した点やそれを工夫した点など”地味だけど大事な”ことについて、各社のノウハウを話し合うことができました。 エンジニアの仕事は、新規機能開発より運用のほうが割合が高いことから、日々の業務のなかで共感できる・役に立つ話をできるのでは、と考え勉強会を企画しました。 発表中に「そうだよね」と頷く参加者の方もいらっしゃり、さらに終了後の懇親会では「すごい共感しました…」といった感想をいただくなど、参加者の方にも楽しんでいただけた企画となったのではと感じています。 運用は、システム的な自動化の工夫ももちろんですが、人が人力作業でやるものもあります。 エムスリーさんからも実状やノウハウを（ぶっちゃけ話も織り交ぜながら）伺えましたが、いずれも運用においてオンライン・オフラインを問わず**「コミュニケーション」（人間関係）**が大事なんだなと感じました。 勉強会後の懇親会の様子。共感した・参考になったという話が多く飛び交いました。 今後もこうした実際の現場で役に立つ勉強会を定期的に開催していく予定です。 MedNightTokyo の Connpass グループで最新情報を発信してまいりますので、今回は残念ながら参加できなかった方も是非フォローをお願いします。 mednight.connpass.com メドレーブログでも、勉強会情報を掲載していくので、ブログも引き続きチェックしてくださいね。 ※ メドレー公式 Facebook ページ に「いいね！」していただけると、ブログの最新情報をフォローできます

こんにちは、エンジニア兼 ダーツプロ の徐です。 2016 年 11 月 14 日（水）に株式会社 ドリコム さんのイベントスペースをお借りして、 エムスリー株式会社 さんとの合同勉強会を開催しました。 「医療系サービスにおけるエンジニア運用裏話」というテーマで、泥臭い・苦労した話やそれをどう工夫したかについて発表しました。 発表の様子 “開発”と言えば、「新規機能追加」を想像される方が多いのではないでしょうか。 しかし、実際現場で働くエンジニアは、新規開発をするのと並行して、安定したサービスを提供し続けるために日々努力しています。 大勢の人々が”当たり前に動くサービス”を実現するために、一生懸命になっているのです。 今回の勉強会はこうした各社の苦い話や知見を持ち寄った会となりました。 当日は各社 2 名ずつ、15 分弱の LT を行いました。 メドレーの発表内容を少しだけご紹介します。 1 人開発体制における運用と工夫 介護のほんね奮闘記 まずは私、徐より介護施設の口コミサイト「 介護のほんね 」 を、エンジニア 1 人でどう運用しているかについてご紹介しました。 １人で運用する際の苦労は何か、そして１人で運用する過程で大事なこととは何かについて紹介していきました。 必ずしもシステム的な工夫だけではなく、周りのメンバーにうまく協力をしてもらう姿勢について、日々の心がけなどを話しました。 人前での発表が不慣れで緊張している私… 発表資料は こちら オンライン病気事典 MEDLEY の 地味だけど重要な 運用の話 そして、オンライン病気事典「 MEDLEY 」を担当する 竹内 からは、運用の裏側として 小規模チームに起きる問題 とそれを解決する方法についての紹介がありました。 今回は、開発ばかりしているとつい疎かになりがちな**「運用手順書」**にスポットを当て、手順書を作成している際に気をつけているポイントについて解説しました。 発表資料は こちら まとめ 今回の勉強会では、普段なかなか取り扱われない”運用”をテーマにし、苦労した点やそれを工夫した点など”地味だけど大事な”ことについて、各社のノウハウを話し合うことができました。 エンジニアの仕事は、新規機能開発より運用のほうが割合が高いことから、日々の業務のなかで共感できる・役に立つ話をできるのでは、と考え勉強会を企画しました。 発表中に「そうだよね」と頷く参加者の方もいらっしゃり、さらに終了後の懇親会では「すごい共感しました…」といった感想をいただくなど、参加者の方にも楽しんでいただけた企画となったのではと感じています。 運用は、システム的な自動化の工夫ももちろんですが、人が人力作業でやるものもあります。 エムスリーさんからも実状やノウハウを（ぶっちゃけ話も織り交ぜながら）伺えましたが、いずれも運用においてオンライン・オフラインを問わず**「コミュニケーション」（人間関係）**が大事なんだなと感じました。 勉強会後の懇親会の様子。共感した・参考になったという話が多く飛び交いました。 今後もこうした実際の現場で役に立つ勉強会を定期的に開催していく予定です。 MedNightTokyo の Connpass グループで最新情報を発信してまいりますので、今回は残念ながら参加できなかった方も是非フォローをお願いします。 mednight.connpass.com メドレーブログでも、勉強会情報を掲載していくので、ブログも引き続きチェックしてくださいね。 ※ メドレー公式 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 ページ に「いいね！」していただけると、ブログの最新情報をフォローできます 今後とも、よろしくお願いします！

こんにちは、 介護のほんね の開発担当エンジニア 兼 プロダーツプレイヤー の徐 聖博です。 メドレーでは定期的に技術勉強会を行っているのですが、この勉強会に参加するのはエンジニアばかりとは限りません。先日は 非エンジニア向けに 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