開発本部のメンバーと開催した「すしバッシュ」についてレポートします。 すしバッシュって？ 「すしバッシュ」とは、美味しいお寿司を食べながら、 登壇者のLT（ライトニングトーク）という自由なテーマの小話を聞きつつ、 ワイワイ楽しく交流するイベントです。要するにやっていることはビアバッシュなのですが、「すし」という言葉にワクワクしてもらえるかなと思って「すしバッシュ」と命名しました（笑）。 今回のすしバッシュは、開発本部が新設されたので、開発本部メンバーの交流を目的としています。 発表テーマ LT発表テーマをご紹介します。学生メンバー含め、5名によるLTが行われ、技術的な話題から個人の趣味まで、バラエティ豊かな発表で盛り上がりました。 ＜LTテーマ＞ ・僕たちはもう業種分類しなくていい ・映画「La La Land」聖地巡礼 ・オートスケールするSaaSに対する負荷テストの実施 ・アルバイト、今に至るまで／130万が消えてった ・スト6でマスターに到達した人間が実際コーチングしたらどうなるか実験してみた LTの様子 実際のLTの様子を写真でお届けします。 すしバッシュをやってみて TOWNには「おかげで助かった！を増やそう」というバリューがあります。 「いつでも顧客の期待や想像を超えるものを提供しよう。顧客からもらえる『おかげで助かった！』はそれができた証。たくさん集めて、自分たちも成長を積み重ねていこう」というものです。本来は顧客に対してのバリューですが、今回のすしバッシュを通して、私自身がメンバーに対して「おかげで助かった！」を強く感じました。 LTでは自分が取り組んでいる業務や、その中で発見したことを共有してくれるメンバーもいました。例えば、負荷テストでの発見を紹介してくれる人や、業種を調べて分類しなくてもAIを用いて自動化する可能性を紹介してくれる人。私が特に驚いたのは、広報として記事を載せているウェブサイトを、実はAI Labの学生メンバーが作ってくれていたことです。他のメンバーが作ってくれた土台があるからこそ、自分も発信活動ができているんだな、と「おかげで助かった！」を実感しました。 月１くらいで開催したい すしバッシュはメンバー皆さんのLTが面白いし、交流できて楽しいので、月に１回くらいの頻度で恒例イベントにしていきたいです！ 「（筋肉のために）お寿司より

「実際にサービス化に向けて、AIを用いてチームで開発ができるのは、学生の方にとって大きなメリットだと思います。」 そう話すのは、取締役 兼 AI Lab責任者の古森さん。AI Labは、社内の業務効率化の支援、そしていずれはそのノウハウを活かしてサービス化することを目的に、学生エンジニアを中心にして開発を行っています。 また、当社は日本マイクロソフト株式会社から、生成AIを活用するパートナー企業向けの事業支援プログラムとして約2,200万円分の利用枠の支援を受けています。 AI Labは具体的にどのような開発をしているのか、そしてAI Labの今後の展望について、古森さんにお話を伺いました。 「AI Lab」って？ ── AI Labとはどのような組織なのでしょうか？AI Labは、エンジニアやバックオフィスなど、社内業務プロセスの効率化を支援するAIを開発する組織です。学生アルバイトの方を中心にして、2023年10月に設立されたばかりの新しいチームです。 ── 具体的にどのようなことをしていますか？ 現在はクラウド事業部とSaaS事業部、それぞれの事業部のエンジニア支援を進めています。 クラウド事業部側については、構築したサーバーのテストの自動化を今までメインに行っていましたが、最近は新サービスのプロトタイプ作りとして、質問応答型のAIの開発もしています。 SaaS事業部側については、開発環境自体の改善をしています。具体的にはビルド時間を短くして、開発が早くなるように改善をしています。 ── AI Labでは全てのプロジェクトでAIを使っているのですか？ いえ、全てのプロジェクトでAIを使っている訳ではありません。AI Labの目的は、単にAIを使用することではなく、業務プロセスを効率的に改善することです。そのため、プロセス改善を行う際には、AIの活用が最適か、それとも他の方法が効果的かを慎重に評価します。AIが適している分野ではAIを用いて改善し、手作業の方が効果的であれば手作業を選択します。AIは単なるツールの一つです。例えば料理においては、作る料理に応じて適切な道具を選ぶように、AIも状況に応じて選ぶべきツールだと考えています。AIが適切ならばAIを使い、そうでない場合は他の方法を採用します。 ただ、効率化のためにAIが最も適している場合は、もちろん積極的に

未経験からエンジニアになるには？ エンジニアへのキャリアチェンジを考える方は多くいらっしゃいますが、その一方で成功への道筋は人それぞれ異なります。 この度インタビューを行ったのは、当社 クラウド事業部のエンジニアでクロジカサーバー管理の運用保守を行う粂井さんです。 もともと不動産会社で営業として働かれていた粂井さんは、エンジニアの勉強を始めて約半年で当社に入社し、現在はインフラエンジニアとして活躍されています。粂井さんに未経験の方がスキルをつけてエンジニアとして活躍するまでの過程をお伺いしました。 不動産営業からのキャリアチェンジ ── 今までどのような仕事をされていましたか？ 前職は新卒で入った不動産の会社で営業を約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変更、仕様変更新しい画面の追加を含