「ロールモデルが身近にいないからこそ、私自身が今後入ってくる女性エンジニアのロールモデルになれたらいいなと思います」 今回お話を伺ったのは、SaaS事業部でクロジカスケジュール管理の開発をしている（写真左から）西村さんと、レイモンさんです。お二人がエンジニアとして働くなかで感じていることを話していただきました。 インタビューを通して、エンジニアは性別を問わず挑戦でき、スキルを磨いていける仕事だということが分かりました。エンジニアに挑戦したい全ての人の背中を押してくれる対談となっています。 挫折をきっかけに、エンジニアの道に ── これまでのご経歴とエンジニアになろうと思ったきっかけについて教えてください。レイモンさんからお願いします。 レイモンさん（以下、敬称略）：ミャンマーの大学を卒業後、ミャンマーにある日本のIT企業でオフショア開発を始めました。その後は日本に移り、受託開発の企業や派遣企業でエンジニア経験を積みました。現在はTOWNのSaas事業部で開発エンジニアをしています。 エンジニアになろうと思ったのは、大学に入学した時からです。もともと経営学にも興味があり悩んだのですが、プログラミングを専門的に学べる大学に入学しました。ミャンマーでは大学で学んだ分野に就職することが一般的なので、自然と私もプログラミングの道に進みました。 ── レイモンさんはプログラミング専門の大学に通われていたんですね。続いて西村さんもお願いします。 西村さん（以下、敬称略）：大学在学中にプログラミングスクールに通い、スクールが斡旋してくれた企業に入りました。前職では会計系システムの開発に従事し、詳細設計・実装・テスト・運用保守など幅広く、上流工程から下流工程まで様々な経験をしました。その後TOWNに転職しました。 ── レイモンさんと同じく大学時代にプログラミングを学ばれたんですね。昔からエンジニアになりたかったんですか？ 西村：それが実は違うんです！私は大学では法学部に所属していて、4年生の9月まで公務員志望だったんです。 しかし希望していた所に就職できず、その時にこれからどうしようかと考えた時に、手に職を付けられる職業がいいと思ったんです。 公務員を目指してる時に色々な市役所や県庁の説明会に参加したのですが、今後はますますITが重要な分野になってくると伺いました。そしてIT系で手

未経験からエンジニアになるには？ エンジニアへのキャリアチェンジを考える方は多くいらっしゃいますが、その一方で成功への道筋は人それぞれ異なります。 この度インタビューを行ったのは、当社 クラウド事業部のエンジニアでクロジカサーバー管理の運用保守を行う粂井さんです。 もともと不動産会社で営業として働かれていた粂井さんは、エンジニアの勉強を始めて約半年で当社に入社し、現在はインフラエンジニアとして活躍されています。粂井さんに未経験の方がスキルをつけてエンジニアとして活躍するまでの過程をお伺いしました。 不動産営業からのキャリアチェンジ ── 今までどのような仕事をされていましたか？ 前職は新卒で入った不動産の会社で営業を約1年半、その後、事務の仕事を2年間ほどやっていました。 ── もともと営業をされていたんですね！エンジニアになろうと思ったきっかけは何ですか？ 前の職場はほとんどの社員が営業だったのですがエンジニアも数名いて、PCのエラーなどがあるとよく助けていただいていました。その中でエンジニアという職業に興味を持つようになりました。 前職で営業出身のメンバーは部署異動もありましたが、エンジニアだけはエンジニア専門でした。専門職というか、技術職にちょっと憧れてたっていうのはあったかもしれないです。 ── エンジニアの中でもインフラエンジニアが良かったのはどうしてですか？ どうやったらエンジニアになれるのだろうと調べて、エンジニアスクールの無料カウンセリングを受けました。その時インフラエンジニアのことやAWSのことを教えてもらって、面白そうだなと思いました。 前職の時にエンジニアに働く環境を支えてもらっていたので、自分も「技術で支えたい」という思いが強かったのかなと思います。 そして一大決心で前の会社を辞めて、そのスクールに入ってエンジニアを目指しはじめました。 ── そこから勉強されて、就職活動してTOWNに入社していただいたと思うんですけど、勉強はどのくらいしましたか？ 前の会社を辞めたのが2022年8月末で、9月から入社の2023年3月までの約半年間はずっと勉強ですね。 プログラミングスクールが6ヶ月コースだったので、最初の4ヶ月で資格勉強や就職活動・転職活動の準備をして、その後1月から2ヶ月で残ったスクールレッスンの消化と転職活動を同時にやっていました。 ──

イントロダクション TOWNでは大学生のインターン・アルバイトを募集しています。当社は創業間もないころから学生インターンを行っており、独自のカリキュラムをご用意しています。これまで100名以上の学生の方を受け入れてきました。 この記事では、現在アルバイトをしてくれている大学３年生のアキノさんと、人事部インターン担当の倉上さんへインタビューをしました。インターン・アルバイトの仕組みと、実際に経験してみた感想についてお伝えします。 ＜語り手＞トークゲスト：（左から順に）アキノさん（2022年入社） アルバイト倉上さん（2022年入社） 人事部 インターン担当インタビュアー：島津（2022年入社） 採用広報 インターンとアルバイトの仕組み ── まず初めに、インターンとアルバイトの仕組みについて教えてください。 倉上：実務経験がない方も安心してアルバイトをスタートしていただけるように、まずインターンで合計６回（１回６時間程度）のカリキュラムを通して、実践的なエンジニアの基礎を学んでいただきます。そしてインターン終了後に、アルバイトとして本格的なエンジニアの仕事に加わっていただきます。 インターン・アルバイトには３つのコースがあり、こちらからお好きなコースを選んでいただきます。①大規模アプリ開発コース：３万人が使う大規模システムに携わりたい人向け②新規アプリ開発体験コース：０→１フェーズのシステムに携わりたい人向け③サーバーコース：AWSでのサーバー構築を学びたい人向け 詳細についてはアルバイト説明資料をご覧ください。 「将来の選択肢を広げたい！」とインターンへ応募 ── ではここから、実際にインターンを経て昨年の10月からアルバイトをしてくださっているアキノさんに体験談をお伺いします。そもそもアキノさんはどうしてTOWNのインターンに応募してくださったのですか？ アキノ：アルバイトの時間は学生生活の多くの時間を占めると思います。私は大学卒業後はエンジニアとして働きたいので「せっかくなら将来のためになるアルバイトがしたい」という気持ちで、エンジニアのアルバイトを色々探している時にTOWNを見つけて応募しました。 ── アキノさんは「②新規アプリ開発体験コース」を選ばれていますが、このコースにした理由を教えてほしいです。 アキノ：このコースは「フルスタックエンジニアになれる」

イントロダクション ── こんにちは。採用広報の島津です。今回はメグリ株式会社さんとの合同記事です。メグリさんもTOWNも、どちらも受託開発から自社開発へ転換したという共通点があります。本企画では「受託開発から自社開発へ」をテーマに、前編後編にわたってお伝えしたいと思います。 前編では「なぜ受託開発から自社開発に転換したのか」や「転換期の失敗談」などを詳しく聞いていきたいと思います。 ＜語り手＞トークゲスト篠田さん：メグリ株式会社 Product Division Planner岩崎さん：TOWN株式会社 プロダクトマネージャーインタビュアー松岡さん：メグリ株式会社 HR島津 ：TOWN株式会社 採用広報 プロダクトについて 島津：まずは、簡単にプロダクトの紹介をお願いできますでしょうか。 篠田：社名の通り「MGRe（メグリ）」というサービスです。モバイルアプリの開発から運用マーケティング活動までサポートするモバイルアプリプラットフォームです。 メグリの特長として、アプリをつくることがゴールではなく、そこからがスタートだと考えています。顧客とアプリを通じてどんなコミュニケーションを実現したいのか、その理想の実現のためクライアントと共にアプリを育てていくことを大切にしています。 島津：なるほど！ありがとうございます。岩崎さんもお願いします。 岩崎：「クロジカ スケジュール管理」（2023年3月28日に「Aipo」から名称変更）はビジネス向けのスケジュール共有アプリです。 建築系の業界とか介護系の業界とか、そういう １つの箇所に人が集まらないで、複数拠点を持つ方たち、バラバラの場所にいる人たちが、予定の共有とかをしやすくするためのツールです。 今は1,800社で導入していただいていて、約３万人のユーザーに使ってもらっています。 メグリ株式会社 篠田さんのこれまでのキャリア 島津：続いて、お二人のご経歴をお話しいただけますでしょうか。 篠田：2014年に株式会社ランチェスター（現、メグリ株式会社）に入社しました。それまでは、様々な会社で新規事業を担当していました。前職では会社の方針転換があり、この先新規事業に携わることが難しそうだったので、他の会社を探してる時にたまたまメグリに出会いました。 今まで受託開発の会社が新規事業をやるという新しい挑戦だったので、立ち上げ自体もな

── こんにちは。採用広報の島津です。社内メンバーへのインタビュー、今回はAipoのエンジニアのレイモンさんにお話を伺いました。 ＜語り手＞トークゲスト：レイモンさん（2022年入社） Aipo事業部エンジニアインタビュアー：島津（2022年入社） 採用広報 イントロダクション ── 本日はお時間をいただきありがとうございます。よろしくお願いします。 今回はAipoのエンジニアとしてご活躍されているレイモンさんへのインタビューです。レイモンさんがどうしてTOWNを選んでくれたのか、実際に入社してみてどうか等、お伺いしたいと思っています。 レイモン：はい。よろしくお願いします。 ── まずは、レイモンさんのプロフィールをお伺いしてもよろしいでしょうか。 レイモン：2022年の10月にTOWNに入社して、現在はAipo事業部でエンジニアをしています。 TOWNに入社するまでは、１社目がミャンマーにある日本企業、そのあと日本に来て、２社目が受託開発の企業、３社目が派遣企業でエンジニアをしていました。そして４社目にTOWNに入社しました。 なぜ日本で働こうと思いましたか？ ── そもそもなぜエンジニアになろうと思ったのですか？ レイモン：大学でもエンジニアリングの勉強をしていて、プログラミングにも興味があったからです。それで大学を卒業して、ミャンマーにある日本企業にエンジニアとして入社しました。 ── 最初にミャンマーにある日本企業に入社したのですね。その後どうして日本で働こうと思ったのですか？ レイモン：日本企業で働いていて、日本の仕事のやり方にも慣れて、考え方も自分に合っていると思ったからです。それと、日本にいた方がエンジニアの勉強になると思ったからです。 最初の会社は入社後すぐに３ヶ月間、日本に滞在する研修がありました。その時に色々な技術を体験することができて、日本にいた方が技術の勉強になると感じていました。 当時のミャンマーでは担当できる仕事の幅が狭く、もっと成長したいと思いました。ですので「日本企業で仕事がしたい」という気持ちと、「もっと色々なことに挑戦したい」という気持ちがあって、日本に行ってみようと考えました。 日本に来て、TOWNに入社するまで ── そうなんですね！それでは日本に来て、どのような会社で働かれていたのですか？ レイモン：TOWNに入社するまで

イントロダクション ── こんにちは。採用広報の島津です。TOWNでは定期的にミートアップを開催しています。今回は、スケジュール管理SaaS『Aipo』のプロダクトマネージャーである岩崎さんが登壇するミートアップの内容を簡単にレポートします。 ＜語り手＞トークゲスト：岩崎さん（2005年入社）Aipo事業部 プロダクトマネージャーインタビュアー：長澤さん（2018年入社）人事 残業時間の変化 ── 「残業がなくなった話」がテーマとしてありますが、岩崎さんの肌感覚として、アジャイル開発の導入前と現在までで、残業時間はどのくらい変わりましたか？ 岩崎：現状は本当にほぼ残業がないです。大体18時半くらいにはメンバーがみんな帰るんですけど、19時以降は誰もいない状況です。 受託開発を始めた当時は、そもそもその週にどこまでやればいいのか分かっていませんでした。21時過ぎまで働いて、なんとなく「今日はここまで進んだからいいかな」と一日を終えていました。その頃は一日数時間の残業が普通でした。 ── じゃあ劇的に変わったんですね。 岩崎：そうですね。家に帰って夕食を食べるか、コンビニで買って会社で食べるかくらいの違いですね。「限られた時間でいかに成果を出すか」という考えに、みんなシフトできたかなと思います。 受託開発から自社開発へ ── 「アジャイル開発をしたら残業がなくなった話」の前段として、まずは当社のビジネスモデルの転換についてお話いただけますか。 岩崎：2013年に受託開発から自社開発に完全に切り替えました。その転換で働き方も大きく変わりました。 完全に自社サービスに転換した時に、代表から「もう受託はやりません。それに伴い、ビジネスモデルを労働時間を増やさなくても会社が成長できる『知識集約型』に変えます。」という話がありました。そこで「残業をしないようにしましょう」となり、働き方を変えていきました。 ── まず会社自体の変化が大きくあったのですね。 岩崎：そうですね。受託開発時代は残業が当たり前で、終電まで働くこともよくありました。しかし、自社サービスになってからは、「最初のうちは売り上げが回復するまで時間がかかるかもしれないけど、みんなで頑張って働き方を変えていきましょう。」と切り替えていきました。 ウォーターフォールからアジャイルへ ── それでは今回のテーマの「アジャ

わたしたちはアジャイル開発の手法のひとつであるスクラムを取り入れて、1週間のスプリントで開発をしています。1週間というサイクルの中でスピード感のある開発をするためには、作ると捨てるが簡単にできる開発環境の構築がかかせません。 アジャイルを始めて10年たちましたが、この10年で学んだことの一つとして「複雑なしくみはスケールをしない」というのがあります。 開発チームにはいろいろなスキルやバックグラウンドを持ったメンバーが集まります。開発ツールをそろえておく、Homebrewを活用する、Gitの操作をGUIだけでできる運用にしておく、MavenやDockerのよく使うコマンド群はシェルスクリプト化して1クリックで実行できるようにするなどシンプルなしくみにするための取り組みをしています。 開発ツールをはじめとした開発環境の構築だけでなくローカルでの実行環境もシンプルになるように改善を進めてきました。以前は各自のマシンに直接実行環境を構築していました。しかしさまざまな問題があったため、現在はDockerを導入して同じ環境を作れるようになっています。 初期の開発スタイル 最初の頃は各自の開発マシンに直接TomcatやMySQLをインストールしてもらっていました。 しかしこの方法では次のような課題を抱えていました。 新しいメンバーが入った際に開発環境構築に時間がかかる。エンジニアごとに開発環境が微妙に異なり、問題が起きたときの切り分けがしづらい。ミドルウェアのバージョン切り替えがしづらい。 新しいメンバーが入った際に開発環境構築に時間がかかる インフラ構成が管理されていないため、新しいメンバーが入ったときにはTomcatやMySQLのインストールをおこなった後、設定ファイルを手作業で書き換えてもらう必要がありました。設定の写し間違えがあると起動しなくなるため、どこが間違っているかエラーログなどを調べながら調整する必要がありました。 エンジニアごとに開発環境が微妙に異なり、問題が起きたときの切り分けがしづらい 入社時期によってミドルウェアのマイナーバージョンが少しずつ違っていて、特定のバージョン以降でエラーが起きたり、設定ファイルの書き方をバージョンにあわせて変えないといけなかったりしました。 設定ファイルに変更が入ったときもメンバー間で適用状態に差が出て、少しずつ異なる設定ファイ

わたしたちのチームでは顧客からの声を集めた「ニーズカウンター」をベースに開発の優先順位を決めてアジャイル開発をしています。 「こういう機能がほしい！」といった要望はニーズカウンターにあがってきますが、「表示に時間がかかる」や「この操作を行うとたびたびエラーになる」などの非機能要件は要望としてほとんどあがってこないため、どうしても開発の優先度が低く、後回しになってしまいがちです。 ユーザーから「表示が遅い」などの報告を直接いただくこともありますが、そういった報告をうける前に手を打っておくことで、ユーザーが当たり前にもとめる品質を提供し続けられると考えています。 そもそも非機能要件とは？ そもそも非機能要件はどんなものでしょうか。非機能要件はIPAによる「非機能要求グレード2018」に「非機能要求グレードの6大項目」として定義されています。この非機能要求グレードはよくまとまっており、自分たちが提供しているサービスがどの程度のレベルを満たしているかを確認するのにも役立ちます。SaaSサービスを提供していると顧客からセキュリティチェックシートへの回答を求められることもありますが、そのときの判断基準としても使えます。 サービスやチームの状況、コスト的な面からすべてを最初から網羅するのは現実的ではありません。しかし現状を把握しておくことで、ビジネス上の目標と照らし合わせながら「来年はここをこのレベルにまで持っていきたい」や「来月はここを強化する」と開発スケジュールに組み込んでいきやすくなります。 それでは非機能要求グレードの6大項目とともにわたしたちがおこなっている具体的なとりくみをご紹介します。 可用性 システムサービスを継続的に利用可能とするための要求。 稼働時間・停止時間などの運用スケジュール、障害、災害時における稼働目標としての要求があげられます。具体的には冗長化対応やバックアップを取ることで実現します。また障害時の復旧・回復方法および体制を確立することで対応します。 わたしたちのとりくみ EC2とRDSによる冗長化構成にすることで可用性を高めています。詳しい構成についてはこちらのブログで紹介しています。 またメンテナンス時間を設けずにアップーデートができるよう、Beanstalkを使ったBlue/Green デプロイをしています。 バックアップも1日1回フルバックアッ

Aipoはおかげさまで3万人にご利用いただいています。ユーザーが増えても最小最速のリリースを実現できるよう、リリース内容にあわせてリリース方法を選んでいます。 リリース戦略を立てることになったきっかけ もともとユーザー全員に同じタイミングでリリースする方法をとっていました。一度に全員にリリースするためリリースノートは書きやすいものの、一発勝負というところもあり、リリース後にパフォーマンスのボトルネックが発覚する、アップデートで逆にユーザーの使い勝手が悪くなるなどリスクもあるリリース方法でした。 課題を感じながらも具体的な改善策がないままリリースフローを変えることができていませんでした。 そんな中、戦略的なリリースに取り組むきっかけとなった出来事が起こります。 UIリニューアル 2018年、新たにサイドメニューを配置するUIリニューアルをしました。 当時のリリースノートを見ると大きな変更が3つも同時にリリースされており、ユーザーに負担をかけるリリースだったと反省しています。 UIリニューアルでは画面の構成が変わるため、ある程度のフィードバックがあることは予想していましたが、フィードバックをいただく中で顧客の解像度がまだまだ低かったことを実感しました。 サイドメニューを追加するということは、メインコンテンツの幅がそのぶん狭くなります。50ピクセルのサイドバーが増えたことで「今まで10文字表示されていたところが2文字表示が少なくなってしまった」「1行で表示されていたものが改行されるようになってしまった」といった声を多くいただきました。 この経験を通して、ビジネス向けカレンダーとして1画面の情報量を重要視されているユーザーが多くいらっしゃることを理解することができました。 それと同時に今のリリース方法だと多くのユーザーに影響を与えることになり、細かな調整に柔軟に対応しづらいという問題点があることがわかりました。またリリースの影響を受けるユーザーの数だけ反響があるため、ユーザーサポートが対応しきれなくなる問題も浮かび上がってきました。 これらの反省をもとに3つのリリースフローをつくりました。 １．ユーザーごとリリース ユーザーをグルーピングして段階的にリリース内容を適用していきます。 このフローをつかうケース ほとんどのユーザーに影響するUI変更、仕様変更新しい画面の追加を含

1台構成からスタートしたサービス。Jenkinsの導入によるビルド環境の統一化、オートスケーリングによるリリース作業の負担軽減をへて、Elastic Beanstalkを使ったBlue/Green デプロイにたどりつくまでの継続的デリバリーの歴史についてご紹介します。The post Beanstalkを使ったBlue/Green デプロイにいたるまでの継続的デリバリーの歴史 first appeared on TOWN株式会社.