<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2021/12/shinsyakaijin_couple2-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h1>はじめに</h1>こんにちは、株式会社レコチョク新卒1年目の本多啓路と申します。現在はプロダクト開発第1グループに所属しており、Androidアプリの開発に携わっています。本記事は、我那覇さんの<a href="https://techblog.recochoku.jp/11774">OJTを通じたアプリ開発の取り組み</a>の続きの記事になります。アプリ開発中に工夫してうまくいったことと、失敗したことについて紹介していきます。<h2>工夫してうまくいったこと</h2>まずは開発中に工夫したことについて紹介していきます。<h3>・GitHub Projectsの使用</h3>アプリ開発についての進捗や自分の担当しているタスクを管理するために、今回はGitHub Projectsを使用しました。GitHub Projectsは、GitHub上でプロジェクト管理を行うための機能になります。ソフトウェア開発のプロジェクト管理やタスク管理を支援するために提供されており、以下のような特徴を持っています。<ol><li>カンバンスタイルのボードを利用して、タスクを視覚的に管理できます。</li><li>GitHubのIssueとPull Requestを直接プロジェクトにリンクでき、それらをタスクとして扱うことができます。</li></ol>この特徴を利用しつつ、毎週ミーティングを行うことで効率的に進捗確認や1週間ごとに行うタスクの割り振りを行うことができたと考えています。<img src="/wp-content/uploads/2025/04/GitHub-Project.png" width="100%"><h3>・mermaid.jsを使用したダイアグラムの作成</h3>アプリ作成には要件(詳しくは我那覇さんの記事を参照)があり、その中の一つにシーケンス図とクラス図の

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2021/12/shinsyakaijin_couple2-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>はじめに</h2>こんにちは、株式会社レコチョク新卒1年目の我那覇です。プロダクト開発第1グループに所属し、Androidアプリエンジニアとして業務に携わっています。配属から約半年間、個別課題を進めた後、業務と並行して同期の本多と２人でのアプリ作成課題に取り組みました。本記事では、アプリ作成課題の詳細と全体の流れを振り返りながらご紹介します。<h2>目的</h2>アプリ作成課題の目的は大きく次の2つです。<ul><li>これまでの研修で習得した知識をアウトプットする</li><li>２人で協力し、チーム開発を経験する</li></ul><h2>アプリ開発の要件</h2>今回の課題を進めるにあたり、以下の要件が提示されました。<ul><li>UI：Jetpack Composeを利用して2画面以上のUIを作成し、画面間の遷移を実装する</li><li>通信：無料APIを用いて通信を行い、OkHttp + Retrofitのライブラリを活用する</li><li>設計：MVVMアーキテクチャを採用し、シーケンス図、クラス図を作成する</li><li>機能：ライトモードとダークモードを選択可能にし、アプリ再起動後も設定を保持する Coilライブラリを使用してWebから取得した画像を表示する</li></ul>これらの要件を満たすため、GitHubのIssuesやProjectsを使ってタスクを細分化し、進捗を管理しました。<h2>開発の進め方</h2>一週間単位に区切り、以下の方法で情報を共有しながら開発を進めました。<ul><li>週2回のMTGを設定<ul><li>水曜：私と本多の2人で進捗確認</li><li>実装について困っていることがあれば相談し、機能のアイデアや改善点について話し合う</li><li>金曜：OJTの先輩も交えた進捗確認</li><li>一週間の

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2017/11/OpenAPISpec-200x200.jpg" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h1>はじめに</h1>こんにちは🌞システム開発推進部システム開発第3グループの小河です。普段はレコチョクの各サービスが共通で利用するバックエンドシステムの開発や運用を担当しています。本記事では、<strong>Swagger Editor</strong>と<strong>Redoc</strong>と<strong>GitHub Pages</strong>を組み合わせ、<strong>OpenAPIベースの仕様書を管理・社内公開する方法</strong>について、事例を通してご紹介します。<h1>APIドキュメントツールを用いる背景</h1>弊社では様々なサービスを展開していますが、共通で必要となる機能も多くあります。(例: 課金・音源の配信など)そのため、それぞれの共通機能を主にREST APIとして提供し、他組織が開発するサービスがそのAPIを利用して機能を実現しています。我々システム開発第3グループにてそれらAPIの開発を行っている都合上、<strong>API仕様書の管理と社内の他組織への公開</strong>を行う必要があります。<h1>Postmanを利用する上での課題</h1>我々システム開発第3グループでは、APIドキュメントツールとして<a href="https://www.postman.com/">Postman</a>を利用していました。しかし、ユーザーごとに課金がなされる料金体系(2025/03現在)のため、コスト上の課題がありました。社内の運用方法として<strong>利用ユーザー数に上限を設けたため、新たに案件に参画したメンバーはPostmanをすぐに利用を開始できない状態が発生していました。</strong><h1>なぜSwagger Editor + Redoc + GitHub Pagesか</h1>そこで、<a href="https://s...

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2025/03/compute-amazon-ecs-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p>NX開発推進部の齋藤です。今回は Amazon Elastic Container Service (ECS) で発生した接続不安定障害とその対応策（アベイラビリティゾーンの再調整）について紹介します。この記事は ECS をある程度運用したことがある方を対象にしています。<h2>【背景】</h2>現在運用中の Web サイトは、次の構成で稼働しています。<img src="/wp-content/uploads/2025/03/archtecture_1.drawio.png" alt="archtecture_1.drawio.png" />図1: NLB を使用した Web サイトの構成（簡略図）(図は簡略化していますが、) ECSのコンテナをアベイラビリティゾーン別で2台起動しています。この構成の特徴は、固定 IP が必要なため、別アカウントの Application Load Balancer (ALB) からの通信を受ける目的で Network Load Balancer (NLB) を採用している点です。アベイラビリティゾーンごとに固定IPを設定し、ALBからそのIPに転送しています。ある日、Web サイトへの接続が不安定になる障害が発生しました。調査の結果、ECSのタスクがパッチリタイアメントにより自動再起動され、その際にアベイラビリティゾーンへの配置が偏っていたことが原因であると判明しました。<img src="/wp-content/uploads/2025/03/az_rebalancing_1.png" alt="az_rebalancing_1.png" />図2: アベイラビリティゾーンの偏りが発生した状態この偏りにより、NLB の振り分けが正しく行われず、一部のゾーンでは 504 エラーが発生し、接続が困難な状況となりました。<img src="/w

<p><img width="180" height="180" src="https://techblog.recochoku.jp/wp-content/uploads/2016/09/Python-180x180.jpg" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>はじめに</h2>こんにちは、株式会社レコチョクの小林です。日頃は、主にPythonを用いたバックエンドの開発に携わっています。最近参画した業務で、バックエンドをPythonのFastAPIで、フロントエンドをNext.jsとTypeScriptで実装する機会があり、それぞれ異なるチームが開発を担当する中で、バックエンドとフロントエンド間での型情報の共有が課題となりました。そこで本記事では、異なる言語間でどのように型定義を同期させるか、その解決方法を検討します。<h2>開発環境</h2><ul><li>バックエンド：Python 3.12.0、FastAPI 0.110.3</li><li>フロントエンド：Next.js 15.2.2、TypeScript 5.8.2</li><li>コード管理：GitHubで別々のリポジトリで管理</li><li>コンテナ管理：Dockerを使用</li></ul><h2>現状の型定義方法とその課題</h2>前述のプロジェクトでは、バックエンドとフロントエンド間の型共有に関して、主に以下のような方法を採用していました。<ul><li><strong>手動での型定義</strong>：フロントエンド開発者がバックエンドのAPIドキュメントを参照し、TypeScriptの型定義を手動で作成</li><li><strong>ドキュメントベースの開発</strong>：Swagger UIなどのAPIドキュメントを参照しながら開発を進める</li><li><strong>コミュニケーションベース</strong>：バックエンドの変更があった場合、口頭やチャットでフロントエンド開発者に伝達</li></ul>これらの方法には以下のような課題がありました：<ul><li><strong>手動更新の手間</strong>: APIの変更ごとに型定義を手動で更新する必要があ

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2024/03/Kotlin_logo-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>はじめに</h2>こんにちは、株式会社レコチョク新卒1年目の我那覇です。昨年10月よりプロダクト開発第1グループに配属され、Androidアプリ開発エンジニアとして業務に携わっています。Serializationは、KotlinでJSONレスポンスを扱う際に便利なライブラリです。本記事では私自身の経験を交えながら、使用する際に初心者が気をつけたいポイントを紹介していきます。これからSerializationを導入しようと考えている方の参考になれば幸いです。<h2>実行環境</h2>macOS 14.4.1 SonomaAndroid Studio Koala | 2024.1.1 Patch 1Kotlin 1.9.0<h2>導入</h2>Serializationを利用するには、[crayon-67ef35cd68201395808165-i/]に以下のプラグインの設定を追加します。[crayon-67ef35cd68208371365035/]この設定により、データクラスに[crayon-67ef35cd6820a403806903-i/]アノテーションを付与することで、データクラスのシリアライズ/デシリアライズが可能になります。本記事では詳しい説明は割愛するため、詳細な導入方法や基本的な使い方については公式ドキュメントをご参照ください。<blockquote> <a href="https://kotlinlang.org/docs/serialization.html#formats">公式ドキュメント</a> <a href="https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/json.md#ignoring-unknown-keys">GitHub</a></blockquote><h2>使用

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2024/03/Kotlin_logo-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h1>はじめに</h1>こんにちは、株式会社レコチョク新卒1年目の本多啓路と申します。現在はプロダクト開発第1グループに所属しており、Androidアプリの開発に携わっています。今回はテキストの高さが日本語の有無によって上下する原因について調査する機会がありましたので、紹介していきたいと思います。<h2>発端となった事象</h2>アプリ開発のテスト中にテキストの大きさ(フォントサイズ)を同じにしているにもかかわらず、日本語がテキスト内に含まれるかどうかによってテキストの高さが微妙に違っているという事象が見つかりました。<ul><li>事象を再現した画像</li></ul><img src="/wp-content/uploads/2025/03/sample-1.jpg" width="70%">[crayon-67ef35cd69414322059462/]この事象を修正するにあたり、フォントサイズについての調査を行う運びとなりました。<h2>調査結果</h2>調査結果としては、以下の2点が原因で今回の事象が起こっているということがわかりました。<h3>1. アルファベットと日本語は違うフォントサイズでレンダリングされている</h3>同じフォントサイズで設定を行った際でも、日本語のフォントサイズはアルファベットのそれと比べて少し大きい数値となります。( px数値の場合だと平均1.25倍ほど )<ul><li>実際にテキストの大きさを16.sp(文字サイズを指定する単位)にしたときの比較<ul><li>今回の例だと日本語はアルファベットの約1.38倍大きい</li></ul></li></ul><img src="/wp-content/uploads/2025/03/sampleText-1.png" width="70%"><h3>2. デフォルトでテキストの最初と最後の行がトリミング

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2025/02/6a8dbf92219e7742e8b930fd822876ab-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p>こんにちは！NX開発推進部ビジネス推進グループの児玉です。1/23(木)に渋谷区立広尾中学校で新しい音楽体験研究所の特別体験会を実施しましたので、当日の様子をお伝えします！<h1>体験会実施の背景</h1><div style="margin: 10px 0;"></div>渋谷区では、「渋谷共創プロジェクト」の一環として、グローバル社会で活躍する自律した学習者を育むシブヤモデル「未来の学校」や、探究学習を推進する、探究「シブヤ未来科」といった取り組みが進められています。詳しくは、以下のサイトに紹介されています。<a href="https://steam-japan.com/news/9308/">全国初！ 渋谷区の探究「シブヤ未来科」の挑戦 | STEAM JAPAN</a>この取り組みでは、従来の先生が教える受け身の授業から、生徒自身が主体的に学びを創る授業へと変化させ、「探究」の時間を充実させることを目的としています。渋谷区に本社を置くレコチョクは、今回、区内の広尾中学と連携する機会があり、「ICT × 探究 ＋ 地域 × 企業」というコンセプトのもと、同校の「マイプロジェクト」の授業内で「音楽」の視点から体験会を実施させていただきました。その体験会では、レコチョクが近年取り組んでいる「新しい音楽体験研究所」の作品 、「レコチョクマミン」 と 「カメレオンノーツ」 を通じて、生徒さんたちに新しい音楽に触れて探究を深めてもらいました。<h2>「Maker Faire Tokyo」について</h2>2023年よりこれまでとは異なる分野への挑戦を通じ、レコチョクに対する新しいイメージを持ってもらうことを目的とした「新しい音楽体験研究所」プロジェクトが立ち上がりました。私が所属しているNX開発推進部では、「新しい音楽体験」を提供する取り組みの一環とし

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2024/11/6fba2531831f3bc4b2a93b7b5dfb424e-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>はじめに</h2>こんにちは、レコチョクの海津です。<br /><a href="https://techblog.recochoku.jp/11044">Maker Faire Tokyo2024</a>に出展した<a href="https://techblog.recochoku.jp/11229">カメレオンノーツ</a>という作品の開発に携わりました。<br />この作品で使われている作曲AIを動かすための環境構築について記載します。<h2>前提</h2><ul><li>作曲AI：Meta社のMusicGen（AudioCraft） </li><li>サーバー：AWSのEC2（GPUインスタンス） </li></ul>を利用します。<h2>自分で環境構築</h2>会社の基本ルールとして、EC2のAMIは会社の基盤チームで作られているAMIを使用します。<br />なのでまずはルールに則り、会社で共有されているAMIを使い一から環境構築をはじめてみました。<br />またGPUインスタンスはインスタンスサイズの最小がxlargeでコストが高いため、少しでもコスト削減しようとARMインスタンスを検討しました。<br />なので以下環境で構築をはじめました。<ul><li>AMI：会社のAMI（OSはAmazon Linux 2） </li><li>インスタンスタイプ：g5g.xlarge </li></ul>audiocraftはPython3.8以上が必要になったため、まずはpyenvのインストールを行いました。<br />ここでgccが必要になりインストールしてみると、kernel-headersがないというエラーが出てしまいました。[crayon-67ef35cd697ec043769421/]なのでkernel-headersを

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2023/06/ux-200x200.jpg" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p>こんにちは！株式会社レコチョクのUXデザイナーの川津です。今回は昨年12/12(木)に社内で行われた、UXリサーチャー瀧本はろか様を講師に招いてのUXリサーチ勉強会についてご紹介いたします。<h2>勉強会の目的</h2>レコチョクでは、「顧客視点を取り入れたサービス意思決定に寄与できる人材」の育成を目的として、UXディレクター/デザイナー向けの社内勉強会を開催してきました。現在、社内にはUXの専門家が多くないため、実践の場で活躍されている瀧本はろか様をお招きし、その実践的な知識と経験から学び、社員にその空気感を肌で感じてもらうことを目的として開催いたしました。<h2>UXリサーチ社内事例</h2><img src="/wp-content/uploads/2025/02/kiyosaki.jpg" alt="kiyosaki.png" /><strong>登壇者：レコチョク IT基盤部QA推進グループ 清崎康史</strong>まずはレコチョクから、社内のUXリサーチ事例について紹介をしました。清崎さんは社内QAチームのスペシャリストです。自社サービスにおけるユーザビリティテストの具体例を出しながら、テストの設計や結果、改善施策についてお話ししていただきました。テスト対象となったサービスには私も以前関わっていたため、「あそこの動線設計は難しいよねぇ」と思いながら興味深く拝聴しました。最初のテスト結果の数字はなかなか衝撃でしたし、その後の大幅改善にも驚きました。<h2>ユーザー視点を意思決定につなげるヒント</h2><img src="/wp-content/uploads/2025/02/takimoto.jpg" alt="takimoto.png" /><strong>登壇者：株式会社スマートバンク UXリサーチ部部⻑ UXリサーチャー 瀧本はろか様</strong>続いては講師の瀧本はろか様から「ユ