J.B.Goode Inc.

Photoshopで切り抜いた画像に白縁をつける方法

切り抜き画像は、背景に埋もれて見えることがありますよね。本記事では、Photoshopで切り抜いた画像に白縁をつける方法をわかりやすく解説します。 1.切り抜いた画像を用意する 2.対象のレイヤーを選択し、レイヤースタイルを開く 3.境界線を有効にする 「境界線」をチェックし、今回は以下のように設定します・サイズ:80px・位置 :外側・カラー:#fff 完成 設定を確定すると、切り抜き画像に白縁が付きます。

Webデザイナーが業務で使っているChrome拡張機能

Web制作の現場では、デザインツールの操作だけでなく、リサーチや検証も欠かせません。本記事では、こうした業務を効率化するChromeの拡張機能を3つ紹介します。 1.WhatFont Webページ上に表示されているテキストのフォント情報を即座に取得できるChrome拡張です。 参考サイトを閲覧していると、「このフォント何だろう」と気になる瞬間がありますよね。ただ、詳細を調べようとすると、検証モードを開いて該当箇所を探す必要があり、少し面倒です。 WhatFontは、有効にした状態でページ上のテキストをクリックするだけで、現在適用されているフォント、フォントファミリー、フォントサイズ、フォントウェイト、行間、文字色を確認できます。 https://chromewebstore.google.com/detail/whatfont/jabopobgcpjmedljpbcaablpmlmfcogm?hl=ja 2.Responsive Viewer Webページを複数のデバイスサイズで同時に表示できる拡張機能です。 画面サイズを一つずつ切り替えながら確認していくと、各サイズの違いや変化が把握しづらいですよね。 Responsive Viewerは、有効にした状態でページを開くだけで、PC、タブレット、スマートフォンなど、自由に指定した複数のサイズを横並びで同時に表示できます。画面幅ごとのレイアウトの違いや、レスポンシブの切り替わり方を一覧で確認できる点が特徴です。 https://chromewebstore.google.com/detail/responsive-viewer/inmopeiepgfljkpkidclfgbgbmfcennb 3.モバイル電話シミュレーター - レスポンシブサイトテスト スマホを操作している感覚で、Webページを閲覧できる拡張機能です。 PC上でスマートフォン表示を確認する場合、デベロッパーツールの切り替えだけでは、実際の閲覧時の印象がつかみにくいですよね。特に、画面サイズやスクロール時の見え方は、PC表示とは感覚が異なります。 モバイル電話シミュレーターは、有効にした状態でページを開くだけで、スマートフォンに近い表示環境を再現できます。画面サイズや縦横比を切り替えながら、スマホ表示時のレイアウトや情報量を確認できます。 前述の「Responsive Viewer」でも同様の確認は可能ですが、表示モードの切り替えが必要になるため、用途に応じて使い分けています。 https://chromewebstore.google.com/detail/mobile-simulator-responsi/ckejmhbmlajgoklhgbapkiccekfoccmk?hl=JA まとめ 普段の業務でよく使っている拡張機能の紹介でした。よかったら試してみてください。

縞模様(ストライプ)を作るrepeating-linear-gradient

まっすぐなシマシマ CSSでシマシマな縞模様(ストライプ)を作るためにパッと浮かぶのは本来グラデーションを作るために使われる background-image: inear-gradient() と background-size を使ったテクニックです。 .bg-stripe { background-image: linear-gradient(90deg, /* 90deg = to right */ black 0%, /* 黒 */ black 50%, /* 黒 */ white 50%, /* 白 */ white 100% /* 白 */ ); background-repeat: repeat; /* 縦横どちらも繰り返す */ background-size: 20px auto; /* 白・黒・縞どうしのサイズはどちらも10px(=20px÷2) */ } 範囲のうち半分(0〜50%)を黒、もう半分(50%〜100%)を白とすることで、グラデーションといいつつ境界のハッキリとしたボーダーを描画し、かつ background-size によって繰り返しグループ1回分のサイズ単位を制御することで以下のような縞模様ができます。「黒・白」で1グループなので、10pxごとの縞模様にしたければ倍の20pxが単位になります。 ※画像はイメージのため black は #999 に変更しています。 ただ、この方法では 0deg (to top )や 90deg(to right )のように、垂直・平行でないとうまくいきません。135deg のように傾けてしまうと、以下のようなバラン型になってしまいます。これはこれで使う場面もありそうですが……。 斜めのシマシマ 垂直・平行方向にまっすぐでないシマシマを作るには頭に「repeating-」(繰り返す)を付けた repeating-linear-gradient を使います。 こちらなんとCSSのグラデーション表現が誕生した頃には既に使えるプロパティだったようで、IE(Internet Explorer)10での表示も可能なようです。 .bg-repeating-stripe { background-image: repeating-linear-gradient(135deg, black 0px, /* 黒 */ black 10px, /* 黒 */ white 10px, /* 白 */ white 20px /* 白 */ ); /* background-sizeやbackground-repeatは指定しない(auto)でも繰り返される */ } これにより単位ごとに背景をリピートする方法では難しい斜めの縞模様ができます。 つまりグラデーションの内部で繰り返しを行った状態を背景画像として提供してくれるので、サイズ指定を background-image 内で行ってしまえば、 background-size や background-repeat はデフォルトのままシマシマで埋め尽くすことができます。 もちろん「まっすぐなシマシマ」にも repeating-linear-gradient を使うことができますが、 linear-gradient の感覚でサイズやリピートを指定してしまうと「外」と「内」の二重で繰り返しが発生してしまい、うまくいかないので注意してください。 失敗例 100%まで繰り返しているため、 linear-gradient と同じになってしまう例 .bg-repeating-repeating-stripe { background-image: repeating-linear-gradient(135deg, /* 90deg = to right */ black 0%, /* 黒 */ black 50%, /* 黒 */ white 50%, /* 白 */ white 100% /* 白 */ ); background-repeat: repeat; /* 内部でもう繰り返してるのに外からも繰り返す */ background-size: 20px auto; /* linear-gradientと同じ結果になる */ } サイズを制限してしまい二重に繰り返すことで表示が刻まれてしまう例 .bg-repeating-repeating-stripe { background-image: repeating-linear-gradient(135deg, /* 90deg = to right */ black 0px, /* 黒 */ black 10px, /* 黒 */ white 10px, /* 白 */ white 20px /* 白 */ ); background-repeat: repeat; /* もう繰り返してるのにもう一回繰り返す */ background-size: 20px auto; /* 斜めの時点で縞のサイズ≠背景の繰り返し幅のためズレる */ } また repeating- による繰り返しグラデーションは他のグラデーション形式にも対応しており、 repeating-radial-gradient repeating-conic-gradient も同様に利用できます。円形のストライプを使う機会なんてかなりサイケデリックな場面しかなさそうですが……🌀 使う頻度に対して対応環境が思った以上に広くてびっくりしたプロパティでした。(きちんとやるなら三角関数的な計算は必須です) せっかくの午年ですしシマシマを作りたいときは積極的に活用していきましょう!

ページトップを判定したいだけなのに

課題 よくある「トップページに戻る」ボタンが画面固定されている場合について、自分がページトップにいれば非表示(非活性)・いなければ表示(活性)するようにしたい。 問題 もっとも容易に考えられる条件はY方向のスクロール値 window.scrollY が「ゼロか」「ゼロでないか」の時である。 つまりスクロールイベントが発生するたびに window.scrollY === 0 かを判定すればよいのだが、 window.addEventListener(’scroll’, … ) はご存知の通り(?)悪名高く、DebounceやThrottleといったテクニックがないと不要なスクロール処理が過剰発生することで知られている。 ただ、これらの「処理を間引く」ためのテクニックを使った場合、間引いているために少し反応が遅れて見えてしまったり細かいUI上の違和感が現れることもあり、適切でない場面もある印象。 そのため具体的な要素(ヘッダーが隠れた時)などの条件であればIntersection Observerで監視してあげるのがスマートでよいのだが、「ページトップか」を判断するにはそのためだけに見えない1pxの要素をページの一番上に置いて〜などのハックを使うことになるため少し煩わしい。 タイトル通りやりたいのはただ自分がページトップにいるかどうかを判定したいだけなのに……。 解決 アクセスした時点では活性状態にしたくないため、あらかじめ「トップページに戻る」ボタンには inert 属性を付けておく。 <a href="#" id="pagetop" inert>トップページに戻る</a> ※ hidden (非表示)と違いinert (非活性)属性だけでは非表示にはならないため、別途CSSにて非表示するための記載が必要。 /* CSSアニメーションを付けたい場合は別途transitionなどを使ってください */ #pagetop[inert] { visibility: hidden; } この前提をもってJavascript上で #pagetop の表示・非表示= inert の真・偽を切り替える。 function pagetopToggle() { let ticking = false; const pagetop = document.querySelector('#pagetop'); window.addEventListener('scroll', function() { if (!ticking) { window.requestAnimationFrame(function() { // 画面のフレームレートに応じて処理を間引く const isTop = window.scrollY === 0; // scrollTop: 0ならtrue if ( pagetop.inert !== isTop ) { // isTopがinertの有無と一致しなくなった時 pagetop.inert = isTop; // ページトップ(true)かトップでないか(false)を一致させる } ticking = false; }); ticking = true; } }, { passive: true }); // 既存のスクロール処理を邪魔しない=preventDefaultを使用しないことを明示 } もちろん window.scrollY はスクロールのたびに取得されるが、 inert の付け外し=画面上の変更処理については「ページトップでなくなった」「ページトップに戻った」の2回のみ働くため、パフォーマンス上はIntersection Observerによる監視と同等の軽量さが得られる(はず)。 また、念のため requestAnimationFrame ないし ticking によって画面のフレームレートごとに最低限の「間引き」も行っている。おそらくこれが一番お手軽かも。 ※別解:animation-timeline 動くか試せていないのとパフォーマンス的な観点では未知数だが、CSSの animation-timeline が使えるようになればこれだけで済むらしい(すばらしすぎる……)。 ただ、現状ではFirefoxなどにpolyfillが必要なためいずれはJSでCSSをゴニョゴニョする時代も終わるのかもしれないという希望だけ……。 https://caniuse.com/mdn-css_properties_animation-timeline body { animation-timeline: scroll(); animation-range: 0 1px; } #pagetop { visibility: hidden; /* content-visibility: none; */ animation: toggle-pagetop linear both; } @keyframes toggle-pagetop { to { visibility: visible; /* content-visibility: visible; */ } }

Live Sass Compilerをやめてnpmスクリプトに移行する

概要 これまでVS Codeの拡張機能「Live Sass Compiler」を使用してSCSSをコンパイルしていましたが、環境(設定やバージョン)によって出力されるCSSに差分が生じる問題が発生しました。 この問題を解決し、チーム全員が同じ設定でコンパイルできるように、npm scriptsを利用した管理に移行した際の手順をまとめます。 起きていた問題 VS Codeの拡張機能設定を同じにしても、出力結果に微妙な差分が出る。 解決策:npmスクリプトへの移行 プロジェクト自体にコンパイル環境を持たせることで、OSやエディタ環境に左右されない「共通のコンパイル設定」を構築します。 1.Node.jsのバージョン設定 古いバージョン(v14など)を使用していると、最新のSass機能が使えない可能性があるため、安定したバージョンに変更します。今回は nodenv を使用してプロジェクトのローカルバージョンを指定しました。 # 現在のバージョン確認 node -v # v14.17.1 (古い) # 利用可能なバージョンを確認して切り替え nodenv versions nodenv local 20.18.2 # 切り替わったか確認 node -v # v20.18.2 # 切り替わったか確認 node -v # v20.18.2 2.Sassパッケージのインストール プロジェクトのルートディレクトリで公式の Sass(Dart Sass)をインストールします。 # package.jsonがない場合は初期化 npm init -y # Sassを開発用依存関係(devDependencies)としてインストール npm install -D sass 3.package.json にスクリプトを追加 package.json の scripts セクションにコンパイル用のコマンドを追記します。これにより、パスの設定やオプション(Source Mapの有無など)を共通化できます。 コード スニペット { "scripts": { "sass:watch": "sass --watch src/scss:dist/css --style expanded --no-source-map", "sass:build": "sass src/scss:dist/css --style compressed --no-source-map" } } --watch: ファイルの変更を監視して自動コンパイル --style expanded: 開発時に読みやすい形式で出力 --style compressed: 本番公開用に圧縮して出力 --no-source-map: 今回はソースマップを出力しない設定 4.実行方法 チームメンバーはリポジトリをクローンした後、以下のコマンドを叩くだけで全員同じ設定で監視が始まります。 # 初回のみ npm install # 監視開始 npm run sass:watch 5. .gitignore の確認 不要なファイルがリポジトリに混入しないよう、.gitignore ファイルに以下が記述されているか確認します。 node_modules .DS_Store

ejs-cliとnpm scriptsで静的サイト制作環境を構築する

概要 以前、Sassのコンパイル環境をnpm scriptsで構築しましたが、今回はさらにHTMLをEJSに置き換えて、ヘッダーやフッターなどの共通パーツを効率的に管理できる環境を作ります。 1. 必要なツールのインストール EJSをコマンドラインから変換(コンパイル)するために ejs-cli を導入します。また、複数コマンドを並列実行するために npm-run-all なども合わせてインストールします。 npm install -D ejs-cli onchange npm-run-all 2. package.json の設定 package.json の scripts 部分に、EJSを変換するためのコマンドを追加します。 "scripts": { "build:ejs": "ejs-cli --base-dir src/ejs \"**/*.ejs\" --out public", "scss": "..." (今のSCSSコマンド) } 3. 「共通パーツ」と「ページ本体」の分割 header部分を_header.ejsに移動、footer部分を_footer.ejsに移動した後ページで両方を読み込みます。 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <title>トップページ</title> <link rel="stylesheet" href="/css/style.css"> </head> <body> <%- include('_header') %> <main> <p>ここがメインコンテンツです。管理が楽!</p> </main> <%- include('_footer') %> </body> </html> 4. ページごとにタイトルやJSを動的に変える include する際にオブジェクトを渡すことで、ページごとにタイトルや読み込むJSファイルを制御できます。 _header.ejs(タイトル制御): <% let titleParts = []; if (typeof title !== 'undefined' && title !== '') { titleParts.push(title); } titleParts.push('サイト名'); %> <title><%= titleParts.join(' | ') %></title> 注意: 記述ミス(.の欠落やスペースの有無)で動かなくなることがあるため、EJS内のスクリプトタグは慎重に記述しましょう...。 _footer.ejs <script src="/js/common.js"></script> <% if (typeof pageJs !== 'undefined') { %> <% pageJs.forEach(function(url) { %> <script src="<%= url %>"></script> <% }); %> <% } %> 5.【重要】発生した問題と解決策 問題1:共通パーツ用のファイル(_footer.html等)が出力される_から始まるファイルは出力不要なので、package.json のコマンドで除外設定を行います。 "build:ejs": "ejs-cli --base-dir src/ejs \"**/!(_)*.ejs\" --out public", 問題2:でリンクが機能しないpublic フォルダをルートとして認識させる必要があります。 .vscode/settings.json に以下を追記します。 { "liveServer.settings.root": "/public" } 6. npm scripts の完成形 最終的な package.json の設定です。SassとEJSの「監視(watch)」を1つのコマンドで同時に実行できるようにします。 { "scripts": { "sass:watch": "sass --watch src/scss:public/css --style expanded --no-source-map", "sass:build": "sass src/scss:public/css --style compressed --no-source-map", "ejs:build": "ejs-cli --base-dir src/ejs \"**/!(_)*.ejs\" --out public", "ejs:watch": "onchange \"src/ejs/**/*.ejs\" -- npm run ejs:build", "build": "npm-run-all -p sass:build ejs:build", "start": "npm-run-all -p sass:watch ejs:watch" } } 7. チーム向けREADMEの更新 移行後は、以下のルールをチームに周知します。 開発開始: npm start を実行 ソース管理: src フォルダを編集する 画像・JS: これらは直接 public フォルダ内に配置する(※ビルドフローに入れない場合) 拡張機能: Live Sass CompilerなどのVS Code拡張機能は競合するためオフにする

私たちについて

ソフトウェアでできること、すべて。

「ソフトウェアでできること、すべて。」とは、機能や対応範囲の話ではありません。私たちはソフトウェアを、現実を構成する抽象レイヤーとして扱います。生成AIやLLM、分散システム、クラウドネイティブなインフラ、ストリーム処理。重要なのは技術選定ではなく、どの抽象度で世界を分解し、どの境界で責務を定義し、どのアーキテクチャで時間と状態を制御するかという設計そのものです。デザインも同様に、視覚の装飾ではありません。情報の位相を揃え、意味の流れを設計し、認知と行動の連鎖を組み替えること。コードとデザインを往復しながら、概念を運用可能な構造へ落とす。ミッションである、地球上のあらゆるコトやモノをより良くするために、私たちは表層ではなく系全体を扱う。それを引き受ける覚悟の表明が、「すべて」です。

【OSSでWiki構築】第2回(環境構築編)

Docker ComposeでOutlineとDBを連携させる Docker Composeによる構築手順 1. はじめに この記事は、オープンソースのWikiツール「Outline」を、Docker Composeを利用してローカルPC上に構築するまでの一連の手順をまとめたものです。 最終的に、自己署名証明書による安全なHTTPS環境でOutlineが動作する状態を目指します。 第1回はこちら。【OSSでWiki構築】第1回:OSSの選定 使用技術スタック アプリケーション: Outline 実行環境: Docker / Docker Compose データベース: PostgreSQL キャッシュ: Redis リバースプロキシ (HTTPS化): Caddy 2. 事前準備 構築を始める前に、以下のツールがPCにインストールされていることを確認します。 Docker Desktop: 公式サイトからダウンロード。 (macOSの場合) Homebrewを使ったインストールが便利です: brew install --cask docker テキストエディタ: Visual Studio Codeなど、コードを編集できるもの。 ターミナル (コマンドラインツール) 3. 構築手順 ステップ1: プロジェクトフォルダの作成 まず、作業用のフォルダを作成し、その中に移動します。 # 例としてデスクトップに作成 cd ~/Desktop # フォルダを作成 mkdir outline-project # 作成したフォルダに移動 cd outline-project ステップ2: hostsファイルにカスタムドメインを追加 localhostに紐づくブラウザの強力なキャッシュ(HSTS)を回避し、クリーンな状態でローカルHTTPS環境を構築するため、PCのhostsファイルにoutline.testというカスタムドメインを追加します。 ターミナルで以下のコマンドを実行し、hostsファイルを開きます。(パスワード入力が必要です) sudo nano /etc/hosts ファイルの末尾に、以下の一行を追記します。 127.0.0.1 outline.test Control + O → Enterで保存し、Control + Xでエディタを終了します。 ステップ3: Caddyの設定ファイルを作成 HTTPS通信を担当する「SSL執事」であるCaddyの設定ファイルを作成します。 outline-projectフォルダ内に、Caddyfileという名前のファイル(拡張子なし)を新規作成し、以下の内容を記述します。 outline.test { # これはインターネットに公開しない、内部用の証明書を使うという指示 tls internal # outline.testに来たアクセスを、outlineコンテナの3000番ポートに中継する reverse_proxy outline:3000 } ステップ4: シークレットキーの生成 Outlineのセキュリティ設定に必要な、2つのランダムな文字列(シークレットキー)を生成します。 ターミナルで以下のコマンドを2回実行し、表示された文字列をそれぞれメモしておきます。 openssl rand -hex 32 ステップ5: docker-compose.ymlの作成と編集 プロジェクトの心臓部である設計図docker-compose.ymlを作成します。 outline-projectフォルダ内にdocker-compose.ymlを新規作成し、以下の内容を貼り付けます。 その後、SECRET_KEYとUTILS_SECRETの値を、ステップ4で生成した2つのキーに置き換えます。 # 動かしたいコンテナ(サービス)を定義していく services: # 1番目のサービス:Caddy(リバースプロキシ兼SSL執事) # ブラウザからのアクセスを全て受け取り、安全なHTTPS通信を提供する caddy: image: caddy:2-alpine restart: unless-stopped # PCのポート80(HTTP)と443(HTTPS)をCaddyコンテナに接続する # CaddyがHTTPからHTTPSへのリダイレクトも自動で行う ports: - "80:80" - "443:443" # Caddyの設定ファイル(Caddyfile)をコンテナ内に読み込ませる volumes: - ./Caddyfile:/etc/caddy/Caddyfile # 2番目のサービス:PostgreSQLデータベース db: image: postgres:15-alpine restart: unless-stopped volumes: - postgres_data:/var/lib/postgresql/data environment: POSTGRES_USER: outline POSTGRES_PASSWORD: StrongPassword POSTGRES_DB: outline # 3番目のサービス:Redis(キャッシュなど一時データ用) redis: image: redis:7-alpine restart: unless-stopped # 4番目のサービス:Outline本体 outline: image: outlinewiki/outline:latest restart: unless-stopped # ポートはCaddyが全て管理するため、Outlineは外部にポートを公開しない depends_on: - db - redis environment: # ステップ4で生成した2つのキーに置き換える SECRET_KEY: 'ここに1つ目のキーを貼り付け' UTILS_SECRET: 'ここに2つ目のキーを貼り付け' # アプリケーションの公開URL(httpsとカスタムドメインに変更) URL: '<https://outline.test>' DATABASE_URL: 'postgres://outline:StrongPassword@db:5432/outline' REDIS_URL: 'redis://redis:6379' PGSSLMODE: 'disable' # データを保存しておくボリューム(保管庫)を定義 volumes: postgres_data: ステップ6: コンテナの起動 全ての準備が整いました。ターミナルで以下のコマンドを実行し、コンテナを起動します。 docker compose up -d 初回はイメージのダウンロードに数分かかる場合があります。 ステップ7: 動作確認とアクセス コンテナが正常に起動したか、以下のコマンドで確認します。 docker compose ps 4つのサービス(caddy, db, redis, outline)がすべてUpまたはrunningになっていればOKです。outlineのSTATUSが(healthy)に変わるまで1〜2分待ちます。 Webブラウザで以下のURLにアクセスします。https://outline.test ブラウザに「保護されていない通信」などの警告が表示されますが、これは正常な動作です。「詳細設定」などをクリックし、「outline.testにアクセスする(安全ではありません)」を選択して先に進みます。 Outlineの初期設定画面が表示されれば、環境構築は成功です! 4. まとめ 以上の手順で、4つのコンテナが連携して動作する、安全なローカルHTTPS環境のOutlineを構築することができました。 構築過程で発生した様々なエラーとその解決策については、別の記事でまとめます。

【OSSでWiki構築】第1回

OSSの選定 はじめに OSSを利用したWiki構築の取り組みです。 目的とゴール設定 業務で扱う機会が少ない「システム構築の技術」を習得し、アウトプットすることを主目的としています。 目的(メイン) システム構築の一連のプロセスを経験し、具体的な技術的知見(Docker、DB、設定など)を獲得する。 ゴール OSSを用いて、実用可能なWiki環境を構築し、完成させる。 共有事項 構築過程で遭遇した技術的な課題と解決策を参考情報として共有する。 候補OSSの初期比較検討と仮選定 OSS名特徴・OutlineモダンなUI/UX、Notionに近い使い勝手、チーム向けに特化。Reactベース。・wiki.js多機能で柔軟な構成、多数の認証方式に対応。Vue.jsベース。・GROWI日本発の多機能Wiki。Markdownに加え、Notionのような構造化も可能。・MediaWikiWikipediaで使われている技術。機能は豊富だが、デザインが古め。 Outlinewiki.jsGROWIMediaWikiUI/UXモダン。多機能。やや古さが残る。機能的。設定が複雑。古典的。技術スタックNode.js,React,PostgreSQLNode.js,Vue.js,複数DBNode.js,React,MongoDBPHP,MySQL構築難易度低(シンプル)中(多機能ゆえ)中(MongoDB導入が必要)高(PHP環境構築が必要) 【結論】 上記比較の結果、Outlineを検証のメインOSSとして仮選定し、構築を進めていきます。 技術スタックの決定 項目採用技術理由対象OSSOutline上記比較検討の結果より実行環境Docker / Docker Compose依存関係の分離と管理DBPostgreSQLOutlineの必須要件であるため。 Outlineについて 概要 チームのドキュメント、議事録、仕様書、日報などを整理し、簡単に検索・共有するためのプラットフォーム。自分のサーバーでデータを管理できるため、セキュリティやプライバシーを重視する組織に適している。 特徴 モダンで高速なエディタ: Markdown記法に対応しており、直感的で快適にドキュメントを作成できる。リアルタイムでの共同編集も可能。 階層的なドキュメント管理: ドキュメントを入れ子構造で整理できるため、情報が探しやすくなっている。 強力な検索機能: すべてのドキュメントを横断して高速に検索できる。 外部サービス連携: Slackと連携して通知を受け取ったり、FigmaやLoomなどのコンテンツを埋め込んだりすることができる。 セルフホストとオープンソース: 自分のインフラ上で運用するため、データを完全にコントロールできる。また、必要に応じてカスタマイズも可能。 公式サイト https://www.getoutline.com

Goのイテレーター・ジェネレータについて

はじめに Go 1.23でイテレータ機能が標準ライブラリに追加されました。本記事では、新しく導入されたiterパッケージの使い方と、従来のスライスベースの反復処理との違いについて、実行フローとパフォーマンスについてまとめていきます。 イテレータとは イテレータは、コレクションの要素を順次走査するための抽象化です。Goでは従来からrangeを用いたスライスの反復処理が可能でしたが、Go1.23からは関数ベースのカスタムイテレータが言語レベルでサポートされるようになりました。 // 従来のスライスベースの反復処理 for i, v := range []string{"a", "b", "c"} { fmt.Println(i, v) } ジェネレータの概要 ジェネレータは、値を遅延評価的に生成するイテレータの一種です。Pythonのyieldキーワードのような専用構文はありませんが、iterパッケージで定義された型を使って実現します。 iter パッケージの型定義 package iter type Seq[V any] func(yield func(V) bool) type Seq2[K, V any] func(yield func(K, V) bool) Seq[V] 単一の値を返すイテレータ Seq2[K, V] キーと値のペアを返すイテレータ(mapのrangeループに相当) yield関数の戻り値は継続フラグで、falseを返すとイテレーションが中断されます。 スライス vs ジェネレータ スライスとジェネレータの実装について比較していきます。 【パターン1】 スライスベースの実装 func Test_Slice(t *testing.T) { strings := createSlice(5) for _, s := range strings { fmt.Printf("Test_Slice: %s\\n", s) } } func createSlice(max int) []string { slice := make([]string, 0, max) for i := range max { fmt.Printf("createSlice: %d\\n", i) slice = append(slice, strconv.Itoa(i)) } return slice } 実行結果: createSlice: 0 createSlice: 1 createSlice: 2 createSlice: 3 createSlice: 4 Test_Slice: 0 Test_Slice: 1 Test_Slice: 2 Test_Slice: 3 Test_Slice: 4 スライス生成が完全に完了してから、rangeループによる反復処理が開始されます。 【パターン2】 ジェネレータベースの実装 func Test_Yield(t *testing.T) { stringGenerator := generateString(5) for s := range stringGenerator { fmt.Printf("Test_Yield: %s\\n", s) } } func generateString(max int) iter.Seq[string] { return func(yield func(string) bool) { for i := range max { fmt.Printf("generateString: %d\\n", i) if !yield(strconv.Itoa(i)) { return } } } } 実行結果: generateString: 0 Test_Yield: 0 generateString: 1 Test_Yield: 1 generateString: 2 Test_Yield: 2 generateString: 3 Test_Yield: 3 generateString: 4 Test_Yield: 4 生成と処理が交互に実行されています。これが遅延評価の特徴です。 実行フローの違い スライスの場合 createSliceが全要素を生成 スライスがメモリ上に確保される rangeが各要素を順次処理 ジェネレータの場合 rangeがiter.Seq型の関数を実行 yieldが呼ばれるたびにループ本体が実行される 次の要素が必要になるまで生成処理は進まない 注目すべきは、generateStringの戻り値である関数を明示的に呼び出していない点です。rangeキーワードがiter.Seq型を検出すると、自動的に関数を実行してイテレーションを開始します。 パフォーマンス特性の比較 項目スライスジェネレータメモリ使用量O(n) 全要素を保持O(1) 現在の状態のみ初期化コスト高い - 全要素を事前生成低い - 遅延生成反復処理速度高速 - メモリアクセスのみやや低速 - 毎回関数呼び出しCPU使用率低い(反復時)高い(関数呼び出しオーバーヘッド)早期終了時の効率無駄な生成が発生必要な分だけ生成 ベンチマーク例 func BenchmarkSlice(b *testing.B) { for i := 0; i < b.N; i++ { slice := createSlice(1000) for _, s := range slice { _ = s } } } func BenchmarkGenerator(b *testing.B) { for i := 0; i < b.N; i++ { gen := generateString(1000) for s := range gen { _ = s } } } 使い分けの指針 スライスを選ぶべきケース 全要素を複数回走査する必要がある データサイズが小さく、メモリに余裕がある 反復処理のパフォーマンスが重要 データを一度に取得するコストが低い ジェネレータを選ぶべきケース データサイズが大きく、メモリ効率が重要 要素生成のコストが高い(DB クエリ、API コールなど) 早期終了の可能性が高い(条件に合う最初の要素を探すなど) 無限シーケンスを扱う場合 実践例:無限シーケンス func infiniteCounter() iter.Seq[int] { return func(yield func(int) bool) { i := 0 for { if !yield(i) { return } i++ } } } // 最初の10個だけ取得 func Test_InfiniteCounter(t *testing.T) { count := 0 for n := range infiniteCounter() { fmt.Println(n) count++ if count >= 10 { break } } } このようなパターンはスライスでは実現できません。 まとめ Go1.23のイテレータ機能は、従来のスライスベースの反復処理に加えて、メモリ効率の良い遅延評価を実現できます。 スライスメモリと引き換えに高速な反復処理 ジェネレータCPU時間と引き換えにメモリ効率の良い遅延評価 適切なパターンを選択することで、パフォーマンスとリソース使用量のバランスを最適化してきましょう。 参考資料 Go 1.23 Release Notes - Iterators

GoでEnumを表現する2つのパターン

Goには、Pythonなどの言語にあるような厳密なEnum型が存在しません。そのため、独自の型定義と定数を組み合わせてEnumを表現するのが一般的です。 今回は、実務でよく使われる2つの表現パターンについて紹介します。 【パターン1】 iota を活用した連番定義 iotaは、定数ブロック内で連番を自動的に割り振るための仕組みです。(Goに備わっている標準機能です) type ErrorCode int const ( BadRequest ErrorCode = iota + 1 // 1 Required // 2 InvalidChars // 3 InternalError // 4 ) iotaの初期値について Goの整数型のゼロ値は0です。未初期化の変数と明示的な値を区別するため、iota + 1として1から開始するのが一般的なプラクティスです。 定義したEnum値に対して文字列を返したい場合は、以下のように String() メソッドを定義します。 func (e ErrorCode) String() string { switch e { case BadRequest: return "BadRequest" case Required: return "Required" case InvalidChars: return "InvalidChars" case InternalError: return "InternalError" default: return fmt.Sprintf("ErrorCode(%d)", e) } } これにより、fmt.Printlnなどで出力する際に、数値ではなく意味のある文字列として扱えるようになります。 【パターン2】 mapベースで管理していく 定数で定義した値をキーとして、対応するメッセージをmapに格納する方法です。フォーマット可能な文字列や複雑なメタデータを関連づけたい場合に有効なパターンになります。 基本的な実装例 type ErrorCode int const ( BadRequest ErrorCode = iota + 1 Required InvalidChars InternalError ) var messageMap = map[ErrorCode]string{ BadRequest: "Bad Request error", Required: "%sを入力してください", // ... 続く } func (e ErrorCode) Message() string { if msg, ok := messageMap[e]; ok { return msg } return "Unknown Error Msg" } パラメータをつけた実装例 func (e ErrorCode) FormatMessage(args ...interface{}) string { template := e.Message() return fmt.Sprintf(template, args...) } msg := Required.FormatMessage("ユーザー名") // 出力: ユーザー名を入力してください ▶︎ こちらで試せます まとめ GoでEnum的な構造を実現する際は、要件に応じて使い分けましょう。 パターン1 シンプルで高速な文字列変換が必要な場合 パターン2動的なメッセージ生成や複雑なメタデータ管理が必要な場合 基本的にはパターン1をベースにし、複雑な関連データが必要になった段階でパターン2を検討するのが、Goらしいのかなと思っています。

スムーススクロールはJSでやるべき

みなさん、スムーススクロール(慣性スクロール)してますか。 jQueryの世界ではいにしえより伝わる以下のコードがあり、 # で始まるIDへのアンカーリンクの「スクロールがヌルっと動くため」だけにコピペで動くコードとして重宝されてきました。 $(function(){ $('a[href^="#"]').click(function(){ var speed = 400; // ページ中のどこに行くにも4秒で着く var href= $(this).attr("href"); var target = $(href == "#" || href == "" ? 'html' : href); var position = target.offset().top; $('body,html').animate({scrollTop:position}, speed, 'swing'); return false; }); }); ただ近年、このようなスムーススクロールを実装したい「だけ」であれば、以下のCSS1行の記述だけで完結するようになりました。 html { scroll-behavior: smooth; /* これだけ……だが…… */ } イージング(アニメーションの緩急)やデュレーション(辿り着くまでの時間=スピード)は各種ブラウザの取り決めに従うため調整用のオプションはありませんが、先ほどのjQueryで行っていたスムーススクロール程度の動き・要望についてはこちらのCSSのみで事足りる便利な記述です。 https://caniuse.com/?search=scroll-behavior 日本ではモバイル天下一ブラウザであるSafariについても2022年から(遅くない……?)対応しているためほぼ問題なく活用でき、実際 scroll-behavior: smooth; について調べると、滑らかなスクロールはこれだけで解決!という記事ばかり引っかかるようになりました。めでたしめでたし ……はたして本当にそうでしょうか……? 全てのスクロールバグの生みの親 たとえばLPペライチ内でのアンカーリンクのためだけにスムーススクロールの処理を書くのは……といった程度の場合には先ほどのCSSによる置き換えが有効ではあります。 ただし、サイトの規模が大きくなるほど scroll-behavior: smooth; は実用に耐えない場面が多いです。 つまりWeb記事の通り「これだけで解決!」と単純に思って reset.css や style.css の頭なんかに書いてしまうと他プラグインとの兼ね合いが悪く、原因不明のスクロール関連バグにつまづくことが多くなり……結局便利なスムーススクロールを使えなくなってしまう場面が稀にあります。 悪さをしている事例 原因不明といいつつほとんどは先の scroll-behavior: smooth; の記述があるためなのですが、具体的には以下のような事例が挙げられます。 https://seeder.site/web/610.html Swiper.jsでいつものように無限ループさせていたら、1周目を終わろうとしていたときに高速移動している。 https://note.com/chino8234/n/n538c02cf5dd0 「アンカーリンクでTOPページの特定のセクションに飛ばそうとしたのに、なぜか毎回“次のセクション”に遷移してしまう…」 https://x.com/tak_dcxi/status/1781708160484692054?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1781708160484692054%7Ctwgr%5E6865e621c16247d4df7f699d0f88d3aa328110a0%7Ctwcon%5Es1_c10&ref_url=https%3A%2F%2Fwww.tak-dcxi.com%2Farticle%2Fsmooth-scroll-implementation-example%2F (https://www.tak-dcxi.com/article/smooth-scroll-implementation-example/ ) ページ遷移後にスクロールで待たせる挙動はCSSのスムーススクロールでも同じ。JSならこの挙動を無効にできるけどCSSではできない。 https://x.com/tami_design/status/1815737711099248742?s=20 GSAPのScrollTriggerとscroll-behavior: smooth;は同時に使用しない横スクロールを実装したのですがリロードや画面リサイズすると表示が崩れたりして安定しなかった… ※こちら、GSAPのアニメーションがやけに重いと思ったら原因これだったので実体験です。 主にスライダー(カルーセル)やスクロールアニメーション系のプラグイン、ページ遷移時のアニメーションによくない影響を及ぼしていることがわかります。近頃はこういったプラグインもアニメーションの軽量化のためCSS animationを活用していることが多いのですが、そちらとCSS側の「全てをスムーススクロール」させる命令が干渉・衝突しているためかと思われます。 しかも scroll-behavior: smooth; は html に当てないとその効力を発揮しないため、必ずグローバル(ページ内すべて)のスクロールに対して反映されることになり……、衝突は避けられません。これではいけませんね こういった問題が発生した時の対策も必ず「scroll-behavior: smooth;を外してCSSでスムーススクロールしない」になってしまうため、実装をラクしたサボったツケを喰らうことになります。 そこでサイトの規模が大きくなりそうだけどCSSではなく、かつjQueryにも依存しないJavaScriptでスムーススクロールするための代替コードを考えてみました。 scroll-behavior: smooth; の代替メソッド 具体的に辿り着きたい対象=ターゲットがはっきりしている場合、JSでは scrollIntoView() というメソッドを活用することができます。こちらに behavior: "smooth" という引数を与えると、CSSで行っていたスムーススクロールと同じ動きを行うことができます。 element.scrollIntoView({ behavior: "smooth", /* CSSで指定したものと同じ振る舞い */ block: 'start' /* 上揃えの位置にスクロールする */ }); ここでいう element (または window )がスムーススクロールで辿り着きたい対象となります。 また、この behavior: "smooth" は直接スクロール位置の座標を指定する scrollTo() メソッドでも利用することができます。 window.scrollTo({ behavior: "smooth", /* CSSで指定したものと同じ振る舞い */ top: 0 /* topからの位置が0 → ページトップへのスクロール */ }); /* 余談:scrollIntoView()で書きたい場合はelementを「document.body」とするとよいらしい document.body.scrollIntoView({ behavior: "smooth", block: 'start' }); */ どちらのメソッドであってもCSSで scroll-behavior: smooth; とした際と全く同じブラウザ側で定められた動きのスムーススクロールが行われます。 実用例 例えば冒頭のjQueryによる記載は以下のように置換できます。 const anchors = document.querySelectorAll('a[href^="#"]'); // 「#」で始まるアンカーリンクすべてを取得 anchors.forEach(anchor => { // アンカーリンクそれぞれにクリック時のイベントを設定 anchor.addEventListener('click', (e) => { e.preventDefault(); // 本来のアンカーリンク挙動によるスクロールをキャンセル const href = anchor.getAttribute('href'); if ( href === '#' || href == "" ) { // hrefが「#」のみまたは空=ページトップに戻る場合 window.scrollTo({ behavior: "smooth", // スムーススクロール top: 0 // ページトップ }); } else { // hrefが「#◯◯◯」の場合 const target = document.querySelector(href); if (target) { // 「#◯◯◯」のID=アンカーリンク先が見つかった場合、その位置にスクロール target.scrollIntoView({ behavior: 'smooth', // スムーススクロール block: 'start' // 上端合わせ }); } } }); }); また繰り返すようですが behavior: "smooth" によるスムーススクロールはCSSと同じくブラウザ側でスクロール挙動を行うため、 scroll-margin-top のようなCSSによるスクロール位置の調整も問題なく適用され(てしまい)ます。 シンプルな固定ヘッダー分だけずらすようであれば以下のようなクラスを用意しておけばわざわざJSでヘッダーの高さを取得してスクロール位置を計算する……などの処理は必要ありません。(固定ヘッダーの高さが幅によって可変する場合は、きちんとJSで計算する必要がありますが……) .anchor-target { scroll-margin-top: 100px; /* ヘッダーの高さ分スクロール位置をずらす */ } ※上記CSSの適用には :target 疑似要素を使う方法もありますが、今回は e.preventDefault(); によって本来のアンカーリンク挙動をキャンセルしているため、スクロールの際 # で始まるハッシュ(URLフラグメント)が付かない= :target 要素が機能しません。そのため仮に .anchor-target というクラスをアンカーリンクさせたいID位置に付ける想定をしています。 (他にルート相対 /#◯◯◯ で始まる場合などの考慮も場合によっては必要ですが)あくまでページ内アンカーリンクのスムーススクロール化であれば上記のJSで事足りるかと思います。 便利なプロパティほど思わぬところや実装が進んだところでのつまづきに繋がるので、スムーススクロール「だけ」の機能であっても正しく・意図した挙動になるよう心がけて実装しましょう。

DXをバズワードにしない。 情報管理の“現場目線”に寄り添う――株式会社日本パープル

すべては、2021年に遡ります。株式会社日本パープルの林社長が語ってくださった、「新しいサービスを世に送り出したい」という、静かな、しかし強い意志。それが、すべての始まりでした。こんにちは。J.B.Goode Inc.です。今回は、私たちがひとつのサービスの「誕生」から「成長」、そして大きな「お披露目の場」に至るまで、デザインという立場で伴走させていただいた物語について、お話しさせてください。そのサービスの名は、『ConPass』。 私たちJ.B.Goode Inc.は、この新しいサービスの思想をかたちにする「ロゴ」や、心臓部である「ダッシュボード」のデザインから関わらせていただきました。 思想を「しるし」に。――ブランドロゴデザイン 『ConPass』ロゴレギュレーション 2021年、私たちはまず、日本パープル社が『ConPass』という名前に込めた想いを、一つの「しるし」に定着させることから始めました。『ConPass』は、紙と電子の契約書が社内に混在する、複雑な課題を解決するための「ハイブリッド型」契約管理サービスです。私たちは、このサービスの核をロゴデザインに翻訳しました。 ベースとした「円」のかたちは、「コンパス」を象徴すると同時に、バラバラなものを繋ぐ「繋がり」やユーザーの「安心感」を表現。 そして、ブランドカラーの「グリーン」には、安心感や親近感、そして「使う人の未来を明るく照らしたい」というポジティブな意志を込めています。このロゴは、これから始まる長いプロジェクトの、確かな道しるべとなりました。 複雑さを「直感」に。――ダッシュボードのUI/UXデザイン 『ConPass』製品ダッシュボード ロゴで固まった思想を、今度はプロダクトの「体験」に落とし込んでいきます。ダッシュボードのUI/UXデザインは、このプロジェクトで最も難しく、そして最もこだわった部分です。『ConPass』が扱う契約管理は、機能がどうしても多く、複雑になりがちです。しかし、林社長のこだわりは「誰でも、直感的に使えるサービスでなければ意味がない」という点にありました。たくさんの機能と、シンプルな使い心地。この両立は、まさに挑戦でした。 私たちは、情報を何度も整理し、ボタン一つ、言葉一つに「迷わせないか?」と問い続けました。目指したのは、ユーザーが何も考えなくても、まるでコンパスが指し示すように、自然と目的の操作にたどり着けるインターフェースです。この試行錯誤のプロセスこそ、サービスの本当の「やさしさ」をデザインする時間だったと感じています。 主軸サービスへ。そして、大きな舞台へ 2021年に産声を上げた『ConPass』は、そこから着実に成長を遂げていきました。 紙と電子が混在する「現場のリアルな課題」に寄り添うその価値が、多くの企業に認められ、いつしか日本パープル社の主軸サービスの一つとして数えられるまでになったのです。そして2025年7月。 その成長を確かなものとし、さらに多くの企業へ価値を届けるため、ひとつの大きな舞台が用意されました。それが、幕張メッセで開催される「DX総合EXPO」への出展でした。 価値を「物語」に。――LP&展示会デザイン 『ConPass』LP サービスの次なるステージに向け、私たちはその価値を伝えるための「物語」をデザインする必要がありました。それが、LP(ランディングページ)と、DX総合EXPOの展示会ブースです。 当日の展示会場の様子 このフェーズで、プロダクトマネージャーである小松さんの「強いこだわり」に、私たちは心を動かされました。「よくあるテンプレートのデザインではなく、『ConPass』だけの物語が伝わる、オリジナルのLPをつくりたいんです」その想いは、私たちも全く同じでした。 ロゴで表現した「安心感」、UI/UXで追求した「直感的なわかりやすさ」。これらすべての思想を一貫して表現し、初めてこのサービスに出会う人が、その世界観に触れ、「これは私たちのためのサービスかもしれない」と感じてくれること。展示会ブースは、4年前から始まった私たちのすべての仕事の、集大成の場だったのです。 最後に 展示会ブースイメージ DX総合EXPOの会場で、たくさんの方がブースに足を止め、熱心に『ConPass』の話に耳を傾けていました。2021年に私たちがデザインに込めた想いが、サービスとして成長し、企業の主軸となり、こうして多くの人に届いている。その光景を目の当たりにし、深く感動しました。 ひとつの強い想いが、ロゴになり、プロダクトになり、そして人と出会う「場」になる。 そのすべてに寄り添い、デザインという仕事で伴走できたことを、私たちは心から誇りに思います。 J.B.Goode Inc.は、ただつくるだけのデザイン会社ではありません。事業の立ち上げから、その成功まで。クライアントの「伝えたい」という想いの、一番の味方でありたいと願っています。

「暗闇×音楽」新感覚フェス!FEELCYCLE「LUSTER 2025」イベントレポート

暗闇が支配する空間で、音楽の奔流に身を委ね、リズムに乗り、シンクロする。そこは、まるで最高峰のナイトクラブと狂熱の音楽フェスが融合したかのような異次元の領域。人々はただ、その圧倒的なグルーヴの中で、自らの存在を燃やすように汗を流していた。FEELCYCLEは、ニューヨーク発祥のバイクエクササイズを、アレンジした革新的なフィットネススタジオ。暗闇、音楽、そして全身運動。この3つを掛け合わせた体験は、都市部を中心に約40店舗を展開し、流行やライフスタイルに敏感で、常に時代の先端をいく人々から絶大な支持を集めています。その真価は、ただ体を動かすだけでは終わらない“エンターテインメント性”の高さ。暗闇を切り裂くレーザー、重低音が床を震わせる非日常の中、参加者はバイクと一体となり、インストラクターのリードに熱狂的に応える。歌い、踊り、まるでステージアーティストのように、空間を一つに染め上げていくのです。 2025年8月12日、FEELCYCLEの公式ウェブサイトがリニューアルオープンし、そのブランドデザインをJ.B.Goode Inc.が担当しました。 FEELCYCLEが掲げる「IT'S STYLE. NOT FITNESS.」というブランドステートメントを軸に、フィットネスの枠を超えたエンターテインメント性や、非日常的な没入感を視覚的にも表現できるよう、サイト全体のトーンやビジュアル構成を再設計。そんなFEELCYCLEが主催する最大規模のイベント「LUSTER(ラスター)」が、5月30日(金)〜6月1日(日)の3日間、横浜アリーナ(神奈川県横浜市)で開催されました。年に一度の特別なこの日、音楽と運動がどのように融合し、どんな熱狂が生まれていたのか。 今回、ブランドデザインを手がけたJ.B.Goode Inc.のクリエイターが、その現場に足を運び、肌で感じてきました。 音楽フェスと暗闇フィットネスが溶け合う、“LUSTER”という祝祭 「LUSTER」は、FEELCYCLEが贈る国内最大級の暗闇バイクフェス。2016年に始まり、今年で開催9年目。これまでに延べ3万人以上を動員し、参加者にとっては一種の“聖地巡礼”とも言えるイベントです。 会場に入ると、目の前に広がっていたのは、まさに壮観。整然と並べられた1000台以上のバイク。巨大なステージ。 フロアに並ぶ数千台のバイク そして、空間を彩る圧巻のライティング。ステージが始まる頃には、会場はすでに熱気に包まれ、まるでライブの開演を待つ観客のような高揚感が漂っていました。 インストラクターの掛け声が響き渡ると、参加者全員が一斉にペダルを踏み込み始める。リズムに乗って体を揺らしながら、コール&レスポンスが巻き起こる。「ワンツー!ワンツー!」という合図に、全身のスイッチが入っていく。これはもう、フィットネスの域を超えた、“音楽フェス”そのものでした。 光と音に導かれる80分間のライド体験 今回のLUSTERでは、「FREE YOURSELF(EDM/ハウス系)」「FEEL YOURSELF(オールジャンル系)」という2つのスペシャルプログラムが用意されていました。 私たちが参加したのは、5月31日13:10から始まった「FEEL YOURSELF」。FEELCYCLEの中でも特に人気の高いプログラムで、選曲はポップス、ロック、R&Bなど幅広いジャンルを網羅。曲が変わるたびにライティングの色が変化し、空間のムードも一変します。重低音が体を打ち、光が音に反応するたび、会場全体が一つの巨大な鼓動を刻んでいるような感覚に陥りました。印象的だったのは、全国のスタジオから選抜されたトップインストラクターたちの存在感。彼らは単なるフィットネスの指導者ではありません。時に歌い、時に踊り、時に叫びながら、観客を一つに束ねていく。インストラクターの動きに呼応して、観客のペダルも一層速く、力強くなっていきます。 そこに登場したダンサーたちも、会場の熱狂に拍車をかけ、レーザーと映像演出が楽曲の世界観をさらに深く掘り下げていく――。全身で音を感じ、光に包まれ、ただひたすらに前へ進む。そこには、もはや“運動”という言葉では言い表せない、芸術的な没入体験がありました。 徐々に高まる会場の熱気とボルテージ 心がふるえ、体が叫ぶ。これが“ライブ感覚”のFEEL体験 インストラクターの声が鋭く響き、客席からも地鳴りのような歓声が湧き起こる。「もっと行ける!」「Position Three!」――その一言に、参加者たちは渾身の力でペダルを踏み込む。 音楽に合わせて動く1000人の姿は、まるで巨大なひとつの生命体のよう。声が重なり、鼓動が連なり、会場全体が一体感の中に溶け込んでいく。暗闇の中で交わされるアイコンタクトや、顔に浮かぶ笑顔、時折漏れる叫び声。普段のスタジオレッスンでは味わえない、生々しい“ライブ感”がそこにありました。 そして迎えたクライマックスーー。 インストラクターたちのパフォーマンスは最高潮に達し、会場のボルテージも一気に跳ね上がる。誰もが汗だくで、でも不思議と疲れは見えない。ペダルを踏む足は止まらず、むしろ加速している。 80分という時間が終わった瞬間、会場を包んだのは、圧倒的な達成感と静かな余韻。 息を整えながら、しばらくその場を離れずにいる参加者たちの姿が印象的でした。暗闇の中で解放された心と体。それがこのイベント最大のギフトだったのかもしれません。 フィナーレを迎えたLUSTER 2025 フィットネスは“運動”から“体験”へ。LUSTERが示した未来のかたち FEELCYCLEが掲げるのは、「IT'S STYLE. NOT FITNESS.」というコンセプト。単なるカロリー消費でも、ルーティンでもなく、自分自身を解き放つ“スタイル”の提案。それを体現したのが、この「LUSTER」でした。音楽とフィットネスを掛け合わせた試みは、すでにFEELCYCLEファンの間ではおなじみですが、このイベントを通じて明らかだったのは、その輪が確実に広がっているということ。実際に会場には、年齢も性別もさまざまな人々が集まっており、フェス好きな層やフィットネス初心者らしき姿も多く見受けられました。LUSTERは、ただのフィットネスイベントではありません。それは、新しい文化を生み出す“場”であり、音楽と運動が交差することで生まれる、未来のフィットネスの可能性を感じさせる体験でした。この日、横浜アリーナで起きたこと。それは、心を解き放ち、体を突き動かす、新時代のムーブメントの始まりだったのかもしれません。 J.B.Goode Inc.が紡ぐ、FEELCYCLEのブランド世界、解き放たれた「スタイル」の領域 「IT'S STYLE. NOT FITNESS.」——この揺るぎないブランドステートメントこそが、FEELCYCLEの中核だと考えています。 私たちJ.B.Goode Inc.は、その核心を捉え、フィットネスの既成概念を打ち砕くエンターテインメント性と、一度足を踏み入れたら最後、抗えない非日常的な没入体験を、視覚の領域で具現化することに挑戦しました。 サイト全体のトーンからビジュアル構成に至るまで、徹底的に再設計し、そのブランド世界をデジタル空間に再構築したのです。 漆黒の熱狂をオンラインへ。LUSTERが示すデザインの真価 LUSTER。あの横浜アリーナを震わせた圧倒的な熱量、暗闇と音楽が織りなす唯一無二の世界観を、いかにしてオンライン上で再現するか。 それが私たちの課せられたミッションでした。デザインは単なる装飾ではありません。それは、五感を刺激し、感情を揺さぶる体験そのものです。 私たちは、光と影のコントラスト、躍動するイメージ、そして見る者の深層心理に響く色彩設計を通じて、あの漆黒の熱狂を画面の向こう側へと解き放つことを目指しました。 まるでアリーナの爆音が、デバイスのスピーカーから響き渡るかのように。まるで幻想的なライティングが、目の前で瞬くかのように。 オンラインという制約の中で、LUSTERの真髄をFEELできるデザインの実現に、私たちは全力を注ぎました。 文章だけでは伝わらない魅力を、サイトでぜひ体感してください。 https://www.feelcycle.com 「スタイル」へと昇華する挑戦、デザインが切り拓く未来 ワークアウトを単なる運動ではなく、「スタイル」へと昇華させる FEELCYCLEの挑戦は、まさに時代の最先端をいくものです。彼らの研ぎ澄まされた美意識、そして未来を見据える視線を、今後もデザインという言語を通じて表現し、共に次なる高みへと昇り詰めていくクリエイティブパートナーとして、私たちはFEELCYCLEの「スタイル」を世界に轟かせるための、新たな章をスタートさせました。

これからのフルスタックエンジニアへ ──「実装者」ではなく、未来をつくる「創造者」として

技術革新が進む現代において、「フルスタックエンジニア」は多岐にわたる技術を扱う存在として注目されています。 しかし、J.B.Goode Inc.では、彼らを単なる「実装者」ではなく、コンピュータサイエンスの深い理解に基づき新たな価値を創造する「コンピュータサイエンスの体現者」と位置づけています。 J.B.Goode Inc.が追求する「エンジニアリング」とは、デジタルサービスの価値を再定義し、市場に新たな価値を生み出すことを目指すことです。 この記事を通じて、J.B.Goode Inc.が「世界一」を目指すエンジニアリングについてお届けします。 西川 真司ReactやVue.jsを用いたSPA、そしてGoやRustで構築されたマイクロサービスAPIゲートウェイといったアーキテクチャ設計を通じて、大規模システムのレジリエンス向上に貢献してきました。IoTエッジデバイス向けのリアルタイム組み込みLinuxやKubernetesによるコンテナオーケストレーションの経験を活かし、産業DX構想における技術的インパクトの最大化を追求しています。 また、クラウドネイティブな大規模分散システムにおいては、イベント駆動やサーバーレスアーキテクチャを駆使し、価値創造と社会課題解決に取り組むフルスタックアーキテクトです。 こんにちは、J.B.Goode Inc.のフルスタックエンジニアの西川です。 今や「フルスタックエンジニア」という言葉は珍しいものではありません。フロントエンドからバックエンド、インフラやクラウドまで、幅広くカバーできる存在として、多くの企業が求めるようになりました。 ですが、私たちが考えるフルスタックエンジニアは、単にツールや技術を横断的に扱える「器用な人」ではありません。それは出発点にすぎません。 むしろ、その先にあるのは、テクノロジーの根本原理を理解し、サービスのあるべき姿をゼロから構想し、自ら手を動かして形にできる“創造者”。これが、私たちの定義する「本物のフルスタックエンジニア」です。 フレームワークの限界 たとえば、Next.jsでフロントエンドを構築し、GoやgRPCでバックエンドAPIを実装し、Kubernetes上でマイクロサービスをオーケストレーションする。そんな技術スタックを一通り触れるのは、もはや珍しくない時代です。 でも、それらを「どう組み合わせるか」だけでなく、「なぜそう組むのか」「もっと良い方法はないのか」まで踏み込めるか。これが、私たちが大切にしている視点です。 たとえば、設計パターンひとつ取っても、ただDDD(ドメイン駆動設計)やCQRS、Sagaパターンを「流行っているから」使うのではなく、その背景にある設計思想や計算論的なトレードオフにまで目を向ける。 こういった深掘りが、新しい価値を生み出すための足場になります。 技術の“奥”に広がる選択肢 フルスタックエンジニアに求められるのは、単なるコードの知識やスキルだけではありません。むしろ、その背後にあるコンピュータサイエンスの理論── 情報理論、形式手法、分散システム、数理最適化などへの理解と応用力こそが、武器になります。こうした知識は、すぐに役に立つものではないかもしれません。でも、システム設計で行き詰まったとき、スケーリングに悩んだとき、既存ライブラリではどうしても要件を満たせないとき、「そもそも論」で考えられる力が、未来を切り拓きます。 つまり、「どの技術を使うか」ではなく、「どのような発想で問題を捉え、解決するか」が問われているのです。 “本質的価値”を見極める力が、未来をつくる 今、世の中にはデジタルサービスがあふれています。どれも便利で、よくできている。でも、正直どこか似たり寄ったりな印象を受けることも少なくありません。 そんな中で、本当にユーザーの心を動かすサービスをつくるには、「何をどう作るか」以前に、「なぜ作るのか」「何が本質的価値なのか」を見極める力が欠かせません。 たとえば、ユーザーの行動データを分析する時、ただ既存のBIツールで数値を見るだけではなく、統計的な推論や機械学習の構造を自分で理解し、適切なモデルを自ら設計できるかどうか。 また、トラフィックが急増した時、ただオートスケールをかけるだけでなく、分散合意アルゴリズムやネットワーク設計の限界まで踏み込んだスケーラビリティ設計ができるかどうか。 こうした“踏み込み”があるかどうかで、エンジニアの仕事の質は大きく変わってきます。 エンジニアリングは「未来への投資」 私たちは、エンジニアリングを「作業」とは捉えていません。それは未来をつくるための戦略的な投資です。だからこそ、目の前の要件に追われるだけではありません。「そもそも何のためにこの機能を作るのか?」「ユーザーが本当に困っているのは何か?」「自分たちの技術で、社会にどんなインパクトを与えられるか?」 そんな問いを、常に持ち続けています。結果として、サービスの品質や使い勝手が向上するだけでなく、市場そのものを動かすような、新しい価値が生まれる。 それが、私たちが信じているエンジニアリングの力です。 「世界一」の体験は、文化から生まれる J.B.Goode Inc.のエンジニア文化の特徴は、一言でいえば「妥協しない」こと。 複雑な問題を徹底的にシンプルに削ぎ落とす ブラックボックスに頼らず、自分で理解しきる 目の前の制約に屈せず、「できる方法」を探し続ける 「良い」では満足せず、「最高」を目指す こうした文化は、個人の力だけでは生まれません。チーム全体で、同じ価値観と視点を共有し、実践していくことが重要です。一人では成し得ないことも、志を共にする仲間となら実現できる。 それが、J.B.Goode Inc.の強みであり、エンジニアとして働く最大の魅力です。 コーダーではなく、「未来を描く創造者」へ 私たちが目指すのは、単なる実装者ではありません。誰かの指示に従うコーダーでもありません。私たちは、「計算論的な視点から、世界をどう再構成できるか?」を考える創造者です。テクノロジーを、ただの道具としてではなく、価値創出のための言語として扱える人。 そんな仲間と一緒に、まだ誰も見たことのない未来を、形にしていきたいと思っています。

J.B.Goode Inc.が目指すブランドのカタチと、チームで生み出す体験の未来

現代のデジタル化された世界において、「デザイン」は単なる見た目や使いやすさを超え、ビジネス戦略や顧客体験を形作る重要な要素となっています。しかし、その本質や知的探求の重要性が見過ごされがちな現状もあります。 そこで今日は、私たちJ.B.Goode Inc.が追求する「デザイン思考」と、それがまた私たちのブランド哲学の中で如何に息づいているかという、本質的な内容に迫ります。 この記事を通して、私たちがどのように「未来のデザイン認識論」を牽引し、ブランドの役割を再定義しているかについてお届けします。 廣岡 彰文グラフィックデザイナー、ウェブデザイナー兼フロントエンドエンジニアを経て、UI/UXデザインとプロジェクトマネージメントを歴任。プロスポーツ、EC、プロモーション、教育機関など、多様な領域におけるWebサイトやアプリケーションの企画・立案、UI/UX設計、プロジェクトマネジメントを手がける。プロジェクトを通して、エンドユーザーに対するブランド価値の創出、向上を担う。 J.B.Goode Inc.が牽引する「未来のデザイン認識論」 こんにちは、J.B.Goode Inc.の最高ブランド責任者の廣岡です。 私たちが考えるデザインは、もはや単なる視覚的表現や機能性の最適化に留まるものではありません。ウェブやアプリといったデジタルインターフェースの次元を超え、ユーザーが経験する多感覚的な接点、すなわちさまざまな体験全域における価値の創出をその命題としています。 これは、表層的なニーズの充足に留まらず、ユーザーの潜在意識に分け入り、顕在化していない、しかし確実に必要とされる価値を創造する、まさに知的探求のプロセスです。 ユーザーの行動や感情を丁寧に観察し、まだ言語化されていない「本当に必要とされているもの」を見つけ出す、徹底したエスノグラフィ、膨大なデータに裏打ちされた定量的洞察、そして何よりも”なぜ?”という根源的な問いを追求する批判的思考の上にこそ、デザインは成立すると考えています。 ユーザーにとっての認知負荷を最小限に抑え、かつ最適な解決策を提供する、シンプリシティの具現化を常に目指して 私たちのデザイン思考では、一過性のトレンドに一喜一憂し、表層的な模倣を安易に採り入れることはしません。 人々の生活様式や社会構造に深く根ざし、複雑に絡み合った課題をよみとき再構成するとともに、アフォーダンスを喚起する新たな体験を創造するものです。 機能性、操作性、そしてユーザーの情動的充足を高いレベルで統合し、デジタルとリアルの境界を融解させることで、ユーザーにとっての「不可欠な存在」へと昇華させる。 常に未来の特異点を見据え、予測不能なユーザー行動の複雑性と適応性に対応可能な、包括的なシンプリシティを追求しています。「良い」や「十分」といった凡庸な基準に満足せず、常に卓越性を追求する姿勢こそが、私たちの目指すデザイン思考の源です。 「あなたも明日からWebデザイナー」なわけない 近年、「一週間であなたもウェブデザイナー!」や「あなたもすぐに独立できる!」といったキャッチーな謳い文句が、SNSやウェブサイト上で広く流れています。その影響もあって、短期間でスキルを身につけられる職種として認知されているかもしれません。しかし、この流れは、デザインの持つ本質的な深遠さを軽視し、表層的なスキルセットのみで通用するという誤った認識を助長しているだけで、本来無限であるデザイナーの職域を縛り、作業ベースでのデザインツールのオペレーションに従事することを良しとする風潮を産み出しているように感じています。 前述のとおり、デザインとは、単なる視覚的装飾や、特定のツールの熟練度だけを指すものではなく、深い洞察力に裏打ちされた概念的思考、厳密な論理的推論、複雑な問題に対する非線形的な解決策の創出能力、そして絶えざる自己学習と高いメタ認知能力が求められる、極めて専門性の高い知的プロフェッションであり、卓越性への揺るぎないコミットメントが厳しく求められる世界であると考えます。 「守破離」で例えれば、「離」を感覚的に掴めたら、デザインができると考えているようなもの。スキル習得は「守」の入り口に過ぎず、「破」の段階で既存のデザインの枠を乗り越え、「離」で初めて独自の思想と価値を創造することができるという、知的探求の道こそがデザインです。 ただ、時にデザイナーの脳裏にふと湧いたワンアイデアが、一瞬にしてその世界観を決定づけることもまた事実です。個々の主観性、トーン・マナーやスキルの偏りなどを削ぎ落としてもなお残るものが、デザイナーとしての真の個性。 その隠しきれない個性の根底にある経験則や技に則って、一筆目に配置したテキストや、カラーパレットで作った色、綿密なグリッドには沿っていない画像の配置が、パンク・ロックの初期衝動のように、最も輝きを持つことがあるのもデザイナーの醍醐味であり、ロジカルだけでは到達しない、この領域にこそデザインの深淵が存在するとも私は考えています。 1人では到達できないデザイン そして、この研ぎ澄まされた個の力が最大限に発揮され、かつその限界を超えていくためにこそ、私たちはチームで取り組む価値を大切にしています。個人のスキルセットや経験には、必然的にバイアスや専門性の偏りが生じます。 多様な経験を基にした個人的能力により、限りなく客観的な視点を持った人はもちろん存在します。ただ、それは極一部であり、自身のデザイン的思考に真摯に向き合ってきたからこそ得られるもので、皆が一朝一夕に体得できるものではありません。 そのため、サービスやプロダクトの全体像を深く洞察し、整合性のある一貫したユーザー体験を一人で創造することは極めて困難です。 また、市場の変化の加速に対応するための情報収集や知識の再構築も、一人ではインプットの限界に直面します。ビジネス戦略の立案者、エンジニアリングやマーケティングのスペシャリストなど、多様な専門家との共創的連携、多角的な視点からのフィードバックを得られる環境こそが、新たな次元のアウトプットに繋げるためには必要です。 つまり、独りよがりで表層的な美しさのみに拘ることがデザイナーではなく、集団的知性を礎にし、常に俯瞰で物事を捉え、常に自らの知識体系を更新し、自己を再構築していくことこそ、デザイナーのあるべき姿であると考えます。 進化するブランドと、ブランディングの役割 J.B.Goode Inc.におけるブランドとは、社会に対する「約束」であり、その約束が多次元的な「体験」として提供されることで構築される、共感とロイヤルティのすべてです。 リアルとアンリアルが共存し、プロダクトやサービスのタッチポイントも多様化する現代では、それぞれのタッチポイントにおけるユーザー体験の質自体が、ブランド価値を形成する上で決定的な要素になります。 従来のブランディングが主に「メッセージの伝達」という一方向型の線形的な情報流通に重点を置いていたとすれば、現代のブランディングは、双方向型の「体験設計」そのもの、すなわちユーザー・エクスペリエンスのデザインです。 ユーザーがプロダクトやサービスを認知し、触れる瞬間から、サポートを受けるまでのエンドツーエンドのジャーニーにおいて、オンライン・オフライン、フィジカル、ヴァーチャルを問わず、あらゆる接点において一貫したポジティブな体験を提供することを目指します。 これは、デザイナーが単にトーン・マナーを整えるだけでなく、ユーザーフローの認知最適化、インタラクションデザインにおける感情知能のコントロール、そしてプロセス全体の人間中心設計を徹底することで、初めて実現されます。 私たちのプロダクトやサービスにおけるデザインは、まさにブランドに生命を吹き込む設計思想です。 優れたデザインは、ブランドの持つ価値観やパーソナリティをユーザーに直感的に伝え、心理的なつながりを生み出します。ユーザーが私たちのプロダクトやサービスを使うたびに、ブランドの価値を再認識し、愛着を深めていく。これが、私たちのブランディングです。 J.B.Goode Inc.に息づく、最高のデザイン文化 J.B.Goode Inc.では、デザイナー個々のスキルを磨くだけでなく、特定のカルチャーコードを共有し実践することで、一人の孤立した天才では決して到達できない革新的なデザインや、卓越したユーザー体験を常に目指し、産み出します。 「ユーザー中心」の文化 常にユーザーの視点から出発します。ユーザーが抱える課題を構造的に洞察し、課題の解決だけに留まらず、ユーザーと社会を豊かにすることこそが、私たちの存在意義です。このユーザーへの深い共感と飽くなき探求心は、チーム全体で共有し、活発な議論を通じて深化させます。解決すべき課題をシンプルに且つ本質的に見極め、ユーザーへの貢献を行動の第一義とすることが、私たちのデザインにおける共通の行動原則です。 「検証と改善」の文化 直感や勘といった経験則だけに依拠せず、データを基にした客観的分析と、そこから導かれる仮説検証を重視します。A/Bテスト、ユーザーテストなどのデータを通じて、常にデザインの最適化と洗練を図っていく。このデザインアプローチは、チームメンバーそれぞれの専門性によって、より深く、より確実な洞察に繋がります。現状に満足せず、常に卓越した結果を追求することが私たちの考え方です。 「探求と学習」の文化 デジタル領域におけるデザインの進化は、まさに指数関数的であり、留まることを知りません。新しい技術パラダイムや革新的なアプローチ、未だ見ぬユーザー行動パターンに対し、常に飽くなき好奇心と探求心を持ち続けることが必要です。チームとして情報や知の共有化を積極的に行い、互いに知的刺激を与え合うことで、個々の学習スピードは何倍にも加速されます。これもまた、常に卓越なものを目指す文化の表れであり、私たちの競争優位性の源泉です。 「協働と共創」の文化 デザイナーの仕事は、決して孤独なものではありません。開発者、プロダクトマネージャー、マーケター、そして社内外の多様なステークホルダーと積極的にコミュニケーションを取り、アイデアを建設的にぶつけ合い、共に最高のプロダクトを創り上げる「協働と共創」が私たちのデザイン文化です。異なる視点を受け入れ、活発な議論を通じて異なる専門性の交差から生まれる知的シナジーを生み出すことで、一人の力では見つけられない最適解に到達し、ユーザーに価値あるデザインが生まれると確信しています。この協働の精神こそが、あらゆる制約の中でも多角的な選択肢を見出し、チームとして最高のデザインを共創する力です。 「ソフトウェアの力で地球上のあらゆるコトやモノをよりよくする」を標榜するJ.B.Goode Inc.のデザイナーとして、単なる「ウェブデザイナー」や「UIデザイナー」に留まりません。 私たちは「未来を創る設計士」であり、「ブランド体験をオーケストレートする指揮者」です。そして、最高のデザインは、個々の才能が孤立することなく、チームとして深く協働し、互いに学び合い、高め合う文化の中でこそ生まれると確信しています。 この考えの根底には、J.B.Goode Inc.が創業以来、そのDNAとして深く刻み込んできた「始末」「才覚」「算用」という三つの行動原理が社訓として脈々と流れています。 「始末」 ー複雑は無駄。すべてをシンプルに。 「才覚」ー卓越したものだけ認めよ。  「算用」ー損から始めよ。 これらの言葉は単なる標語ではなく、無駄を排し本質を追求する洗練の哲学、常に卓越したものを目指す革新の精神、そして損得を超えて先に貢献することで新たな市場価値を創造する貢献のロジックという、私たちの行動原則として日々の行動や意思決定の指針となっています。 すべてのクリエイターが、それぞれの専門性を深めつつ、J.B.Goode Inc.の精神を源泉として、個々に専門性を昇華し、集団的知性をもって行動することで、私たちは、人々の暮らしや社会、そして未来そのものを豊かなものへと戦略的にデザインしていくのです。

最軽量の速さ。最高峰の自由。 ― 超軽量ヘッドレスCMS「.CONTENT」正式リリースのお知らせ :最速のパフォーマンスと究極の自由度を実現

このたび私たちは、新たなコンテンツマネジメント体験を提供する超軽量ヘッドレスCMS「.CONTENT(ドットコンテント)」を正式にリリースしました。「あらゆるデバイスに動画やテキストなどのデジタルコンテンツを、もっと速く、もっと自由に、もっとシンプルに届けたい。」そんな想いから開発がスタートした本プロダクトは、CMSの常識を見直し、新たなパラダイムとして、あらゆる業種・業界の課題を解決するために誕生しました。 複雑化したCMSからの脱却 CMSの多機能化が進む一方で、「CMSを使いこなせない」「管理画面が煩雑」「操作ミスが起きやすい」といった声が多く聞かれるようになってきました。便利さの裏にある複雑さ。それがコンテンツ運用のストレスになっているのです。「.CONTENT」は、そうした課題を解決するために「コンテンツ管理」に機能を絞り、極限までシンプルな構成にしました。扱うのは「テキスト」「画像」「音声」「動画」の4種類。これだけです。 コンテンツの“出し入れ”だけに集中 「.CONTENT」は、WYSIWYGエディタやレイアウト調整といった機能を意図的に排除しています。プレゼンテーション層(フロントエンド)とアプリケーション層(バックエンド)の責務を明確に分離するためです。フロントエンドの技術スタックに依存せず、任意のフレームワーク(React, Vueなど)で柔軟なUI/UXを構築できます。これにより、コンテンツ管理者はコンテンツの管理に専念でき、フロントエンド開発者はデザインとインタラクションに注力できます。結果として、誰もが迷わず扱える「軽さ」と「自由さ」を実現しました。 操作も表示も、とにかく軽い 「.CONTENT」の特筆すべき特徴の一つは、その卓越したパフォーマンスです。APIレスポンスの軽量さはもちろんのこと、コンテンツ取得時のレイテンシーを最小限に抑え、様々なデバイスでの表示速度を向上させます。これにより、ネットワーク負荷を軽減し、ユーザーエクスペリエンスを大幅に向上させることが可能です。 欲しい時に、欲しいだけ 「.CONTENT」では、必要なコンテンツを「欲しい時に、欲しいだけ」API経由で取得することがでるオンデマンドな配信モデルを採用しています。例えばアプリでは記事だけを、Webでは画像付きで、サイネージでは動画のみを取得する、といった柔軟な使い分けが可能です。フロントの仕様に合わせて最適な形でコンテンツを呼び出すことができるため、システム全体の効率化と高速化に大きく寄与します。コンテンツの“持ちすぎ”や“出しすぎ”を防ぎ、本当に必要な情報だけを必要な場所へ、瞬時に届けられる設計です。 拡張性・柔軟性も抜群。APIで自由な設計を実現 「.CONTENT」は完全なRESTful APIを基盤とするCMSです。そのため、ReactやVueなどモダンなフレームワークとの相性も良く、システムやサービスとの連携もスムーズ。将来的な拡張や再設計にも強い柔軟性を持ち合わせています。「CMSに合わせる」のではなく、「開発者の思想にCMSが寄り添う」。それが「.CONTENT」のスタンスです。 AIが自動でタグを生成する「AIタグ生成」機能 「.CONTENT」には、AIによる「タグ自動生成機能」を標準搭載しています。動画や音声ファイルをドラック&ドロップするだけで、AIが内容を解析し、最適なタグを自動で生成。これにより、コンテンツの分類や検索性が飛躍的に向上します。具体的には、音声認識・自然言語処理・画像認識などの複数のAI技術を組み合わせ、動画内で何が起きているかを理解し、重要なキーワードやシーンを特定します。たとえば、スポーツの実況動画からは「得点シーン」「インタビュー」「ハイライト」などのタグを自動で付与。手動でのタグ付け作業を劇的に省力化しながら、ユーザーにとって価値の高いメタデータを生み出すことができます AIが自動で要約を生成する「AIサマリー」機能 「.CONTENT」には、動画や音声コンテンツをAIが自動で解析・要約する「AIサマリー」機能が搭載されています。動画をアップロードするだけで、音声認識や自然言語処理、画像解析などのアルゴリズムが連携し、映像の中で語られている内容や登場する人物・シーン・感情の動きまでを総合的に解析します。その上で、重要なトピックや盛り上がりポイントを抽出し、視聴者にとって価値の高い要約文を自動生成します。これにより、動画の視聴前に内容を把握できる導線を作ることができるほか、メディア運営や番組制作、SNSマーケティングにおいても非常に強力なツールとなります。「.CONTENT」は、コンテンツの“中身”まで活用するCMSです。 利用シーンは無限大 「.CONTENT」は以下のような幅広い活用が可能です。・オウンドメディアやニュースサイトの運用・マルチデバイス対応が求められるアプリ開発・サイネージやIoT向けのコンテンツ配信デバイス・動画や番組の自動要約によるマーケティング支援・会員向けの情報管理・通知・決済機能の統合 「.CONTENT」が選ばれる理由 ・とにかく軽く、速く、シンプル・学習コストがかからない直感的なUI・APIベースでフロントに制限を与えない・AIによる動画・音声の自動サマリー&タグ生成でメディア運用を強化・あらゆるデバイスに対応する柔軟な拡張性 これからCMSを導入・再検討される方にこそ、一度触れていただきたいプロダクトです。 最後に 「.CONTENT」は、CMSを「管理」ではなく「解放」するために設計されました。自由に、軽やかに、速く。そんなCMSが、あなたのコンテンツ運用をもう一歩先へと導きます。 【お問い合わせ・詳細はこちら】J.B.Goode Inc.https://www.jbgoode.jp/contact/

「つどエール」で紡ぐ、新たな地域コミュニティの息吹 – デジタルが拓く、心豊かな交流の未来

現代社会は、目覚ましいテクノロジーの進化とともに、かつてないほどの変革期を迎えています。私たちの生活様式、働き方、そしてコミュニケーションのあり方も、その波に乗り大きく変容を遂げてきました。とりわけ近年、世界を覆った新型コロナウイルス感染症の感染拡大は、人々の物理的な接触を厳しく制限し、これまで当たり前のように存在していた地域社会における集いの機会を否応なく奪い去りました。しかし、このような未曽有の事態においても、私たち人間にとって地域社会との繋がり、そして温かい人々との交流が、心身の健康を維持し、日々の生活に潤いと豊かさをもたらす上で、決して欠かすことのできない要素であることに変わりはありません。むしろ、物理的な距離が生まれたからこそ、心の距離を縮めたいというニーズは、より一層高まっていると言えるでしょう。このような社会情勢における喫緊の課題意識から、革新的なオンラインコミュニケーションアプリ「つどエール」は誕生しました。このプラットフォームは、地理的な制約、時間的な制約、そして身体的な制約といったあらゆる障壁を超え、デジタルな繋がりを通じて、地域に根ざした多様な活動と心温まる交流を力強く支援することを目的として開発されました。本稿では、「つどエール」が、現代社会におけるコミュニティの再構築という重要なテーマにどのように貢献し、私たちの生活にどのような新たな価値をもたらすのか、その多岐にわたる可能性について深く掘り下げていきます。その具体的な事例として、身体教育医学研究所・岡田真平所長、指導員の倉崎直子様、そして住民サポーターとして地域を支える小林和利様のモデルケースとなった、自然豊かな長野県東御(とうみ)市の皆様への貴重な取材内容を交えながら、その全貌を明らかにしていきます。 オンラインコミュニケーションアプリ「つどエール」 岡田 真平公益財団法人 身体教育医学研究所 所長身体活動と健康の関係性、特に予防、教育、政策の観点から研究。エビデンスに基づいた知見と実践の経験を融合して、自治体や企業等の支援に従事し、アプリ開発などの社会実装を推進する橋渡し役も担う。 地域に根差した研究と実践 - 身体教育医学研究所の理念 岡田所長 私たちは、「誰もが『からだを育み、こころを育み、きずなを育み』ながら、住み慣れた地域で健やかに、そして自分らしく暮らし続けることができる社会」の実現を心から願い、そのための研究と実践活動に日々邁進しています。長野県東御市は、私たちの研究活動における重要な拠点の一つです。 私たちの活動は多岐にわたります。未来を担う子どもたちのための創造的な運動遊びや、豊かな自然に触れる里山探検プログラム。健康寿命の延伸を目指した高齢者の介護予防教室や、生活習慣病予防のための運動指導。さらに、障がいの有無に関わらず、誰もが共に楽しめるユニバーサルスポーツの普及活動など、幅広い領域で活動を展開しています。 これらの活動を通して得られた貴重なデータや知見を基に、保健・医療・福祉・介護・教育・スポーツといった多様な分野からの視点を取り入れた調査研究を行い、その成果を教育や啓発活動、そして積極的な情報発信を通じて社会に還元しています。 そして、これらの活動から自然と生まれる、地域に根ざした広範なネットワークを最大限に活かし、誰もが安心して、そして健やかに暮らせるような地域社会づくり、ひいては公共政策の形成に貢献していくことを、私たちの重要な使命と捉えています。 高齢者の健康と交流を支える「集い」の場 取材当日、東御市にお住まいの65歳以上の皆様を対象とした、活気あふれる介護予防教室が開かれていました。ここでは、 指導経験豊富なインストラクターをお招きし、参加者の体力レベルやニーズに合わせて、運動強度別に計6つの教室が開講されています。教室の内容は、日常生活に必要な筋力向上トレーニング、認知機能の維持・向上に役立つ脳トレレクリエーション、そして、高齢者にとって特に重要な課題である転倒を予防するための体づくりを中心とした、多岐にわたる運動プログラムが提供されています。その中でも、今回見学させていただいた「貯筋教室」 は比較的運動強度の高い教室です。参加者の皆様は真剣な表情で、笑顔を交えながらインストラクターの指導のもと熱心にトレーニングに取り組んでいらっしゃいました。 貯筋教室の様子 倉崎指導員 もちろん、筋力向上や転倒予防といった身体的な効果は非常に重要です。しかし、この教室が持つ意義は、運動効果だけではありません。ここは、参加者の皆様にとって、地域社会との大切な交流の場となっているのです。教室に参加される皆様からは、「こういった場所に定期的に足を運ぶことが、日々の生活の活力になっている」「ここで顔を合わせる仲間がいることが、運動を続ける目標になっている」といった声をよく聞きます。運動を通じて体を動かすことの爽快感とともに、仲間との会話や笑顔が、心身の健康を支える大きな力になっているのだと感じています。 新型コロナウイルス流行が奪った「集い」の機会 しかし、2020年に世界的に大流行した新型コロナウイルス感染症は、これまで当たり前のように存在していた「集い」の場を一変させました。 倉崎指導員 緊急事態宣言の発出などにより、公共施設の使用が禁止され、楽しみにされていた介護予防教室も、やむを得ず休止せざるを得ない状況となりました。毎週のように顔を合わせて、共に運動し、語り合っていた参加者の皆様との交流が、突然途絶えてしまったことは、私たちにとっても大きな痛手でした。 その後、感染状況が落ち着き、久しぶりに参加者の皆様にお会いした際、以前とはまるで別人のように、心身ともに元気をなくされている方が少なくありませんでした。コロナ禍で自宅から外出する機会が極端に減り、活動量が大幅に低下してしまったことが、その大きな原因だと考えられます。 そのような状況を目の当たりにし、「何とかしなければならない」という強い思いと、この困難な状況下でも、地域の方々の繋がりを維持し、健康をサポートするための新たな手段として、「つどエール」を利用しました。 当時を振り返る倉崎指導員 オンラインでの「集い」の再現 - 「つどエール」の誕生 「つどエール」開発における最初の、そして最も重要な目標は、これまで対面で行われてきた地域の方々の「集い」を、オンライン上で可能な限り忠実に再現することでした。 倉崎指導員 地域社会との交流が、物理的な接触を伴う形では実現することが極めて困難な社会情勢において、オンラインでの繋がりは、まさに唯一の希望の光でした。これまで培ってきた地域の方々の繋がりを、何としても絶やしたくない。その強い思いがありました。 高齢者にとって使いやすいツールを目指して 市場には、Web会議システムやコミュニケーションツールなど、オンラインで繋がるための様々な製品が存在します。その中で、なぜあえて「つどエール」というオリジナルのアプリを開発する必要があったのでしょうか。 岡田所長 確かに、オンラインでコミュニケーションを取るためのツールは数多く存在します。しかし、それらの多くは、ビジネス用途や若年層の利用を主な対象としており、高齢者をメインユーザーに想定した製品やツールはほとんどありませんでした。 東御市を含め多くの地域には、スマートフォンの操作に慣れていない高齢者の方がたくさんいらっしゃいます。そのような方々にとって、複雑な操作や多くの機能を備えた既存のツールは、かえって利用のハードルを高めてしまう可能性があります。そこで、私たちがJ.B.Goode Inc.に依頼した内容は、スマートフォンに不慣れな高齢者の方でも、より直感的に操作できるインターフェースを持ちながら、リアルな活動の場と同水準のコミュニケーションを実現するシステムを開発することでした。また、ログイン認証やアカウント登録なども、高齢者にとっては大きな障壁になります。個人情報のセキュリティを確保しつつ、利用者の皆様に負担をかけない方法をプロジェクトチームで模索しました。 その結果、特定のひらがな4文字を合言葉とする認証方式を採用することで、煩雑なIDやパスワードの管理から解放され、スムーズに指導員と地域住民が繋がる仕組みを実現することができました。 現場での手応えと新たな課題 実際に「つどエール」を地域の活動に導入してみて、どのような手応えを感じているのでしょうか。 倉崎指導員 長い間、参加者の皆様の声を聞くことができず、顔を見ることもできない状況が続いていたので、まずはオンライン上で再会できたことに、大きな安堵感を覚えました。しかし、参加者の皆様はもちろん、私たち指導する側もオンラインでのやり取りには慣れていないため、最初は手探り状態でセッティングを行っていました。 小林様 アプリのインストールや基本的な操作方法のサポートなどで、参加者の皆様のお手伝いをさせていただく中で、徐々に皆様がスマートフォンの使い方に慣れてこられたのを感じています。私も含めてですが、「つどエール」が、思わぬ形でスマートフォンの使い方を学ぶ良い機会になったのかもしれません。 左:小林様、右:倉崎指導員 岡田所長 開発段階では想定していなかった課題も明らかになりました。倉崎さんが仰るように、アプリの利便性を高めるために、開発側のJ.B.Goode Inc.の皆様とは本当に密なコミュニケーションを取りましたが、実際に利用者の皆様が苦労される部分は、Wi-Fiへの接続設定であったり、アプリのインストールといった、導入の初期段階に集中していることが分かりました。 また長年住民サポーターとして、教室の運営をサポートされている小林様の奥様は「つどエール」をきっかけに教室に参加することになったとお伺いしました。小林様 オンラインだからこそ実現できた嬉しい出来事もありました。実際に私の妻は、以前から体調に不安を抱えていたので、体操教室への参加を勧めていたのですが、なかなか重い腰が上がらずでした。 ただ、つどエールが出来たのでオンラインで自宅にいながら参加ができるということでスタートすると、徐々に体調も優れてくるようになり、今では一緒に参加するようになりました。 もし対面式の教室のみであれば、いきなり知らない場所に飛び込むことへの抵抗感があったかもしれませんが、オンラインであれば、そうしたハードルが低く、まずは気軽に試してみることができたのだと思います。対面での教室にも積極的に参加するようになり、地域との繋がりを深めています。 「つどエール」のこれから - デジタルが拓く新たな可能性 新型コロナウイルスの感染状況も落ち着きを見せ、社会活動は徐々に正常化に向かっています。「つどエール」は、最初のコンセプトとして掲げた「オンライン上での『集い』の再現」という役割を、一定程度果たすことができたと言えるでしょう。しかし、「つどエール」の可能性は、それだけに留まりません。 岡田所長 パンデミックという特殊な状況下においては、物理的な制約を乗り越えてオンラインで繋がることに大きな意義がありました。しかし、現在のように対面での交流が比較的自由になった社会においては、「オンラインで集まる」ということ自体の重要性は、以前ほど高くないかもしれません。 しかし、「集い」というものは、本来、会場に物理的に集まることができる人たちだけのものではないはずです。健康上の不安、あるいは天候、移動手段の問題から、なかなか外出することが難しい方々もいらっしゃいます。そうした、これまで「集い」に参加したくてもできなかった方々に向けて、必要な情報を提供したり、オンラインならではの交流の機会を設けることが、「つどエール」の次なる重要な目的になると考えています。 デジタルをうまく活用することができれば、物理的な制約を受けません。例えば、オンラインであれば、自宅にいながら専門家の話を聞いたり、遠隔地に住む仲間と交流したりすることができます。また、過去の教室の動画をアーカイブとして残すことで、いつでも好きな時に学習したり、運動したりすることも可能です。 私たちは、「つどエール」が持つこれらのデジタルならではのメリットを最大限に活かし、誰もが取り残されることなく、より包容力のある地域社会の実現に貢献していきたいと考えています。 つどエールの未来について熱く語り合う3人 取材を終えて 新型コロナウイルスの感染拡大という、未曾有の危機の中で生まれたオンラインコミュニケーションアプリ「つどエール」が、物理的な距離を超え、人々の間に新たな交流の形を生み出していることを、今回の取材を通して強く感じました。特に印象的だったのは、高齢者の方々が、最初は戸惑いながらもオンラインでの交流に積極的に参加し、徐々に慣れていく様子や、自宅にいながらにして体操教室に参加できるようになったというエピソードです。これは、デジタル技術が、これまで社会との接点を持ちにくかった人々にも、新たな希望と可能性をもたらすことを示唆しています。これまで、健康上の不安や移動手段の問題など、様々な理由で地域社会との繋がりを持つことが難しかった人々も、「つどエール」という架け橋を通じて、再び温かい繋がりを取り戻し、社会の一員として活躍できるようになったことは、地域社会全体にとって大きな進歩と言えるでしょう。岡田所長がおっしゃるように、今後は、「つどエール」が持つデジタルならではのメリットをさらに活かし、情報格差の解消や、よりきめ細やかなサポートの提供を通じて、誰もが取り残されない、より包容力のある社会の実現に貢献していくことが期待されます。「つどエール」は、単なるオンラインツールではなく、人々の心と心を繋ぎ、地域社会に新たな活力を生み出す、希望の光となる可能性を秘めていると感じました。今後の発展と、それが地域社会にもたらすであろう豊かな未来が、今から楽しみでなりません。

いつの間にか運動不足が解消する魔法!? プロ野球×科学の力で「歩く」がエンタメに変わるまで – 鎌田准教授に聞く、パ・リーグウォーク開発秘話と驚きの効果

私たちJ.B.Goodeが企画・制作・運用を手がけるスマートフォンアプリ「パ・リーグウォーク」。 このパ・リーグ公式アプリは、ダウンロードするだけで日々の歩数を自動的に計測します。応援する球団ごとにファンの総歩数を集計しランキングすることで、球場に足を運べないファンも、アプリを通じて球団の一員として一体感を味わい、ゲームに参加するような感覚を得られる仕組みを実現しました。 これらの機能は、人々の行動や活動をデータ化する当社の独自技術「J.B.Goode Personal Log」によって支えられています。 今回は、パ・リーグウォーク開発にご支援頂いた東京大学の鎌田准教授にインタビューさせて頂きました。 鎌田 真光東京大学大学院 准教授運動疫学、行動科学、身体教育学を主に扱い、身体活動と健康の関係について、予防、教育、政策の観点から研究し、自治体、企業のアドバイザーとして、エビデンスを元にアプリなどの社会実装の橋渡しを行う。 「運動不足を世界から無くす」研究者の掲げるミッションと、プロスポーツに託した社会を変える一手とは ——鎌田先生の研究テーマについて、教えてください。 鎌田准教授 私自身の第一ミッションは、運動不足を世界から無くすことです。一人一人が激しい運動をするという意味ではなく、一人一人がそれぞれに合ったアクティブな生活を送れる社会を作っていくことをミッションに掲げています。 このミッションには研究という言葉は出てきません。私自身は研究や論文を書けばそれで終わりということを目指しているわけではありません。社会を変えていくためには、研究者だけでなく、様々な企業や自治体の方々と一緒に活動を進める必要があります。その中で学術的にも解明されていないことはたくさんあります。 例えば、どういうアプローチをしたら人々の行動を変えられるのか。しかもそれを地域全体など大規模にできるのか。分かっていることを活用しながらエビデンスとしても発信していく活動を行っています。 もっと基本的なところでは、そもそもどういった運動をすると健康にいいんだろうかといったことを研究しています。 ——パ・リーグウォーク開発のきっかけは何でしたか? 鎌田准教授 当時、PLM様ではプロ野球が持つ新たな社会的価値の創出の柱を模索していて、健康もその1つでした。 私自身は行政で働いた経験があり、島根県の雲南市で小さな研究所の立ち上げから関わっていく中で、行政からこういうやり方でできるということは分かっていました。しかし、企業の皆さんと一緒ならもっとたくさんのことができると思っていました。まずはプロスポーツの皆さんと、発信力や様々な観点から体を動かすことを扱っているという点では、必ず相性がいいだろうと考えていました。 背景の一つに、オリンピックを開催しても、その国の人々のスポーツをする割合は増えないという研究がありました。2013年9月に東京で2020年(当初予定)のオリンピック・パラリンピック開催が決まり、オリンピックを機に何か活用できないか、プロスポーツの皆さんと何か出来ないだろうかということを考えていました。そんな中、PLM様と打ち合わせができる機会があり、この機会を逃すまいとプレゼンに挑んだところ、話はトントン拍子に進みました。 パ・リーグとしては、プロ野球コンテンツが持つ社会の新たな価値貢献をJBG社と模索していた段階だったこと、教育と並んで健康はその柱の一つだと考えていたことを後から聞きました。 私たちも行動変容を大規模に社会実装していくには、どんなビジネスパートナーと組むのがいいのか模索していたところだったので、お互いの目指すところが一致し、実現に至ったというのが始まりです。歩数という発想が先にあったのではなく、運動不足対策をどう進めていくかということがメインのスタートポイントだった。体を動かすことなら何でもよかったのです(笑) 様々なアイデアを出し、球場で運動プログラムを行うことなども考えていました。ウォークという形や歩数の重要性についてはJ.B.Goodeの皆様と話していましたが、パ・リーグウォークの形はJBG開発チームからのアイデアです。議論の中で、このポイントは重要だとか、健康上意味があるといったことを共有しました。開発側の皆さんの貢献は非常に大きいです。 当時、JBGの皆様よりご提案いただいた案“ブーステップ”(歩数の合計による野球の対戦球団同士の応援合戦)は、コンシューマー(ユーザー)である野球ファンのことをしっかり理解されていると強く思いました。私自身はソーシャルマーケティングといって、企業が行っているマーケティングを運動や健康に関する行動変容に生かしていますが、対象者目線で考えることが一番大事なポイント。 そういった観点からも“ブーステップ”というコンセプトは本当に素晴らしいと思いました。 「健康」ワードはNG?行動変容を促すための意外な戦略 ——開発段階で苦労したことは何かございますか? 鎌田准教授 ユーザーに歩くことを促すような仕組みづくりや、目標となる数値をどこに設定するのかという点が難しかったと思います。 あとは、私たちからのリクエストで、健康という言葉を使わないでくださいとずっと言っていました。健康のために動きましょうとは言わないでくださいと。それはなぜかというと、健康のために運動しましょうと散々言われてきて、それはもう私たち専門家や健康づくりサイドが散々言ってきて、押し付けのようなメッセージになっていると思ったからです。野球というエンターテインメントコンテンツを持っている皆さんが健康のために歩きましょうと言ってしまうと、これまでと同じ取り組みになってしまうと思います。それで一切、健康のために運動しましょうとは言わないでくださいというのをずっと言っていました。これは何度もあったことです。このメッセージはどうですかねといろいろありましたが、それが入ってしまうとせっかくの良さが消えてしまうと思いました。 開発の皆さんは大変だったと思いますが、コミュニケーションには時間を割きました。これは絶対に大事だし、楽しかったというのもあります。一般的な研究者よりも、こうした対話にはかなり労力を割いてきたのではと思います。 ——ユーザーの行動への効果について、聞かせてください。 鎌田准教授 パ・リーグウォークはエビデンスという点では、検証する中で様々な良い成果が出ています。 ダウンロードした時点で運動している人かどうか、運動の意識はどんな感じかというのを調査するチャンスがありました。その時に調べたら1/4の方がそもそも運動していなくて、近い将来に運動を始めるつもりがないと答えたんですよ。こういった方々は普通に運動教室を開いただけでは来てもらえません。 そういった方々が野球が好きだし、パ・リーグウォークでもやってみようかと始めて、歩数が上がったというようなアプローチができたというのは、健康施策上意義があり、非常に強力なエビデンス・成果です。 ユーザーの方々では、パ・リーグウォークを使い始めて歩数が増えたということが確かめられたのですが、さらに、様々な個人特性で効果に違いが見られなかったこともわかりました。 過去の様々な研究で、一般的に、収入的にゆとりがあったり、学歴が高いような方々の方が健康状態が良く、よく運動をしているといったことが分かっているのですが、さらに、そうした方々ほど、健康づくりの取り組みに反応しやすく、健康格差がどんどん広がりやすい、というのが難しさとして知られています。しかし、パ・リーグウォークは、少なくともダウンロードしてもらえれば、そうしたことはないというのが確かめられたことは、非常に意義があったと思っています。 だからこそ、「第9回健康寿命をのばそう!アワード」厚生労働大臣優秀賞をいただけたのではないかと思っています。 目指すはもっと面白い!パ・リーグウォークの未来予想図 ——パ・リーグウォークの今後について、聞かせてください。 鎌田准教授 より野球らしさや使う人にとってのインセンティブを高められれば、といったところは改善の余地があると思っています。野球ファンの声からも、リアルなところと繋げられないかという点や、ゲームなどとの連携で歩いたら選手が強くなるような要素が入ってくると、相当伸びるのではないかと思います。 最後に 今回のインタビューを通して、「運動不足を世界からなくす」という壮大なミッション、そしてその実現に向けた情熱が、「パ・リーグウォーク」の開発にも深く息づいていることを改めて感じました。健康という言葉を敢えて避け、野球ファンならではの一体感や応援する楽しさをモチベーションに繋げるという斬新なアプローチは、まさにソーシャルマーケティングの真髄であり、多くの人々の行動変容を促す可能性を秘めていると確信しました。 「パ・リーグウォーク」が単なる歩数計測アプリではなく、ファンと球団、そしてファン同士を結びつける、新しい形のコミュニティツールとしての可能性を秘めていることを再認識すると同時に、熱意と革新的な発想が、今後「パ・リーグウォーク」をどのように進化させていくのか、考え続けたいと思います。

デジタル戦略で野球界を革新!パ・リーグ躍進の舞台裏と未来

園部 健二パシフィックリーグマーケティング株式会社大学卒業後、営業会社、出版社、ゲーム会社を経て2017年9月にPLMに入社。人材紹介事業「PLMキャリア」の立ち上げを担当した。現在は執行役員COO(最高執行責任者)として、会社全体の事業に携わっている。 2023年のWORLD BASEBALL CLASSIC™(WBC)における日本代表の劇的な優勝、そしてメジャーリーグベースボール(MLB)での日本人選手の目覚ましい活躍は、国内に再び野球熱を呼び起こし、長らく低迷していた野球人気に新たな息吹をもたらした。その熱狂は、プロ野球誕生90周年となる2024年に、年間総入場者数が過去最多となる26,586,977人を記録する形に結びついた。特に注目すべきは、パシフィック・リーグ(パ・リーグ)の躍進だ。2007年、6球団の出資により設立されたパシフィックリーグマーケティング株式会社(PLM社)は、他リーグに先駆けてデジタル戦略を積極的に展開し、これまで野球に興味を持たなかった層を含む、新たなファン層の開拓に成功した。試合のハイライトやスーパープレーはもちろんのこと、選手の試合中の何気ない仕草やユーモラスなリアクションなど、従来の野球中継では捉えられなかった魅力を独自の視点で切り取り、編集したコンテンツを配信する公式YouTubeチャンネル『パーソル パ・リーグTV』は、登録者数140万人を超える人気チャンネルへと成長した。 日本最大のファンベースを持つプロ野球界において、デジタル戦略をいち早く成功に導いたPLMは、どのようにして困難を乗り越え、新たな地平を切り開いてきたのか。 今回は、『パーソル パ・リーグTV』の責任者である園部氏へのインタビューに成功。戦略と苦労の軌跡を詳細に紐解いていく。 登録者数140万人超え!「パ・リーグTV」独自の視点がファンを惹きつける ——『パーソル パ・リーグTV』について、教えてください。 園部氏 パ・リーグ6球団の主催試合を配信するインターネット動画配信サービスになります。有料会員向けの動画配信サービスになり、公式YouTubeチャンネルでは配信していないパ・リーグ6球団主催試合のライブ配信等も見ることができます。 ——サービスが始まったきっかけは何でしたか? 園部氏 もともとの始まりは、「プロ野球24」というサービスになります。2005年の球界再編時に、パ・リーグは新たにスタートしていこうというタイミングがあり、携帯電話でパ・リーグの試合が観られるサービスの立ち上げが提案され、2006年から開始しました。2010年には、「パ・リーグ ライブTV」という『パーソル パ・リーグTV』の前身となるサービスを外部委託で始め、2012年に『パーソル パ・リーグTV』の自社運営を開始しました。競合サービスの中でも、パ・リーグに特化することで、オリジナルコンテンツを充実させることができ、他サービスとの差別化にも成功しました。 ローリスク・ローリターンからの脱却!自社運営への大胆シフトが飛躍の鍵 ——なぜ自社運用を開始することになったのでしょうか? 園部氏 それまでPLM社として運営した事業が、球団公式CMSのディレクション、リーグスポンサーの営業など、6球団の意向を取りまとめて外部と交渉する、所謂代理店的な動きが中心でした。「パ・リーグ ライブTV」も外部のベンダーに運営していただき、その取りまとめをしており、レベニューシェアで収益の一部を得る「ローリスク・ローリターンモデル」で運用していました。 しかし、PLM社として本事業の成長可能性は高いと判断し、基幹事業として内製化していったほうが将来的な金銭的なリターンやナレッジの蓄積も大きくなると考え、自社での運用を決断しました。 ——サービスが進んでいく中でどのような課題がありましたか? 園部氏 サービスを運用していくなか抱えていた課題は、サービスはあってもナレッジが溜まっていなかったことです。各コンテンツの管理方法がモノリス設計となっていたので、ほかのサービスへ転用する際、新たなシステム開発がなかなかスムーズにいきませんでした。 そこで、データという資産を自社に残すというところから、パ・リーグクラウド(以下、PLC)を作ることになりました。 ベンダー頼みの各パーツを突貫工事で組み合わせたサービスにするのではなく、PLCを一つ作ることによって、将来的なサービスの拡張性を見据えた、様々な開発ができるようになりました。 「PLC」で加速するリーグビジネスの未来 ——PLCとはどういうものか教えてください。 園部氏 いわゆる機能の集合体です。 『パーソル パ・リーグTV』のライブ配信を行う上で、コンテンツの管理、Webサービスの管理、動画情報の管理、ユーザー情報の管理、公式情報の管理など、様々なサービスに拡張できるように必要な機能を集合させたものです。将来的なサービスの拡張性に備えたマイクロ設計になっています。機能単位でサービスが作られているで、それぞれの改修やメンテナンスが容易になりました。 また以前は、外部ベンダーのエンジニアへ「今日の視聴者数は何人ですか?」といったことから細かく問い合わせ、一つ一つ確認しながら資料に落としていくといった作業が発生していました。しかし、PLCでは AWS( Amazon Web Services )をベースとして設計しているので、ナレッジがベンダーに依存することなく、自社内で意思決定ができ、また外部への依頼もしやすくなりました。 ——サービスを開発した効果は他の面にもプラスになったと伺いましたが、詳しく教えていただけますか? 園部氏 バックエンド側の大きな改修や、新たな開発を行うことなく、TVアプリやネイティブのスマホアプリ、アーカイビングサービス(アーカイブセンター)の開発や配信基盤のリプレースを実現することができました 。エンドユーザー向けのサービス開発だけではなく、データの活用も進み、自社内でBIツールを使ったダッシュボードの開発やデータの可視化が可能になりました。 サービスの拡張性というところはキーになっています。  ——開発段階で苦労したことは何かございますか? 園部氏 経営陣への説明には苦労しました。グランドデザインの策定からロードマップ設計の部分、そして、システム構築まで、JBG社とは一緒に取り組んでおり、社内承認のフローまで伴走していただきました。 その後の実績からも、一定の理解は得られたと思っています。 パ・リーグデジタル戦略の現在地と未来 ——今後の展望について教えてください。 園部氏 最初の構想に今のものは完全に近づけているわけではないと思っています。スモールスタートではないですが、今後のステップで成長していくものと捉えています。未だない価値を創出するために、こういうデータを使おうという意見が社内でも出ているので、ファンを広げられるようなデータ基盤になっていければと思います。 Webサービスやスマホアプリで、ユーザーの声を反映して機能面をブラッシュアップさせながら、ユーザーにプロ野球を見る、好きになるという体験を近づけられるようなクラウドになるように考えています。 具体的にやりたいことはいくつかあり、データの活用、個人にパーソナライズした機能の提供、運用の筋肉質化、映像資産の活用などを、パ・リーグ クラウドを使って拡張していく予定です。 また、このPLCがリーグビジネスをやっていく上で、デジタル領域に関していうと、特に、肝になっていくと考えています。球団単体でできないことを、リーグが構築して使いこなせるようになれば、リーグビジネスの力が発揮できる領域だと思うので、そこを目指していきたいですね。 最後に 「リーグとして、球団単体ではできないことに挑む」PLM社が取り組んできたのは、単なる動画配信やクラウド構築にとどまらず、ファンの体験そのものを変革する挑戦でした。 『パーソル パ・リーグTV』を支えるPLCの開発には、目の前の課題を解決するだけでなく、未来のプロ野球をどう描くかという長期的な視点と、強い意志が込められていたことが伝わってきます。 スポーツビジネスの現場で、デジタルを武器に新たな価値を創出し続けるその姿勢は、他業界にも通じる示唆に富んでいます。PLM社の挑戦が、これからどのような未来を切り拓いていくのか、今後も注目していきたいと思います。