こんにちは、デジナーレ福岡オフィスの徳安です。
フロントエンドでエクスポート機能を実装する際、
CSVファイルのエクスポート に関する記事はよく見かけますが、
Zipファイルのエクスポート に関する内容はあまり見かけませんでした。
実際にZipファイルをエクスポートする機会があったため、
今回は 「Zipファイルをエクスポートする方法」 と 、
「ファイルの中身が壊れている際に考えられる原因」 についてまとめました。
最初に試したコード
以下は、最初に実装したコード
const { data , headers } = await axios . get ( "~api url~" )
const blob = new Blob ( [ data ] , { type : "application/zip" } )
const fileUrl = window . URL . createObjectURL ( blob )
const a = document . createElement ( "a" )
a . href = fileUrl
a . download = "example.zip"
a . click ( )
上記のコードでは、Zipファイルのエクスポートはできるが、
解凍すると、ファイルの中身が壊れてしまう 。
原因 Zipファイルをエクスポートする際に、ファイルが正しくエクスポートできない主な原因
原因1: Axiosのレスポンスデータ形式が適切でない デフォルトでは、axios のレスポンスデータは文字列（string）として処理される。
バイナリデータ（Zipファイルなど）を扱う場合、
responseTypeを適切に指定しないとデータが壊れてしまう 。
原因2: Blob作成時のデータ形式エラー 取得したデータが文字列や不適切な形式だと、Blobに変換する際に問題が発生 する。
これが原因で、解凍時に壊れたファイルとして認識されることがある。
原因3: サーバーのレスポンスヘッダーが不正確 サーバーが返すレスポンスの Content-Type ヘッダーが正しく設定されていないと、
ブラウザがデータを正しく処理できないことがある。
その場合はサーバー側で Content-Type: application/zip が返されているか確認する。
今回は原因1の、 Axiosのレスポンスデータ形式が適切でない ことが原因だったため、
下記のように修正。
const { data } = await axios . get ( "~api url~" , {
responseType : "arraybuffer" ,
} )
const blob = new Blob ( [ data ] , { type : "application/zip" } )
const fileUrl = window . URL . createObjectURL ( blob )
const a = document . createElement ( "a" )
a . href = fileUrl
a . download = "example.zip"
a . click ( )
また、responseType: 'blob'を指定すると、レスポンスを直接Blob形式で取得できる。
下記のコードのように、responseType: 'blob' を指定する ことで、
取得したデータがすでにBlob形式になっているため、new Blob()の記述が不要 になる。
const { data } = await axios . get ( "~api url~" , {
responseType : "blob" ,
} )
const fileUrl = window . URL . createObjectURL ( data )
const a = document . createElement ( "a" )
a . href = fileUrl
a . download = "example.zip"
a . click ( )
まとめ 原因1: AxiosのresponseTypeを適切に設定する。
原因2: Blob作成時のデータ形式に注意する。
原因3: サーバーのレスポンスヘッダーContent-Typeを確認する。
以上の点を考慮して実装することで、
Zipファイルを正しくエクスポートすることが可能になります。
ここまで読み進めていただきありがとうございます。
新年、明けましておめでとうございます。
旧年中は格別のお引き立てを賜り、サービス開発・Web制作ならびにCS事業として現場業務に入り込んだ運営改善やプロモーションご支援など皆様の事業フェーズに合わせて幅広く関わる機会をいただき感謝申し上げます。
自社としてもAI活用したツール等の企画・開発を進めており、より皆様の事業立ち上げ・成長に寄与できますよう社員一同邁進してまいります。
令和7年 元旦
こんにちは、デジナーレ福岡オフィスの大坪です。
エンジニアの皆さん、デザイナーから受け取ったモックを見て「早く実装したい」とうずうずしたり、はたまた「これって技術的に実装できるのか？」と不安になることはありませんか？
実装の前にまずは「考える」
フロントエンド開発において UIの実装は、見た目の再現だけでなく、使いやすさ、保守性、パフォーマンスなど、多くの要素を考慮する必要があります。「まずはコードを書いてみよう」というアプローチは、一見スピーディに見えるかもしれませんが、後々の修正や調整のコストが大きく増やしてしまう可能性があります。計画的に「考える」ことで、効率的かつ高品質なUIを実現することが可能になるのです。
モックを読み解く
モックと仕様書を確認する上では視覚的な要素だけでなく、インタラクションの流れや状態の変化なども含めて確認します。例えば、ボタンをクリックした後の画面遷移や、フォーム入力時のバリデーション、エラー表示の仕様などが明確に定義されているかを見ていきます。
さらに重要なのは、実装の観点から機能の必要性を検討することです。デザイン的に使いやすように見えても、実装が複雑になりすぎたり、パフォーマンスに影響を与えたりする可能性がある場合は、代替案を提案することも検討します。また、アクセシビリティの観点からも、すべてのユーザーが問題なく利用できるかを考慮する必要があります。
他にも、レスポンシブデザインの対応があります。異なる画面サイズでのレイアウトの変化や、モバイルでの操作性なども含めて確認します。これらの要素は仕様書に明確に記載されていない場合もあるため、デザイナーと早めに相談することが望ましいでしょう。また、実装時の技術的な制約についても考慮が必要です。使用するフレームワークやライブラリの制限、ブラウザの互換性など、技術的な実現可能性も含めて検討します。これにより、開発段階での手戻りを最小限に抑えることができます。
デザインの一貫性をチェックする
各UI要素がデザインガイドラインに沿っているかを確認することはマストです。デザインシステムが存在する場合は、そこで定義されているカラー、フォントサイズ、スペースなどとモックを比較し、統一されたデザインが保たれているかをチェックしましょう。また、ボタンやカードなどのコンポーネントに複数のバリエーションが存在する場合、それぞれのバリエーションがどのようなシチュエーションで使用されるのかを明確に理解する必要があります。ブログ から「UI Stack」の考え方を身につける事をお勧めします。
UI Stackとは レスポンシブデザインについても確認を怠らないようにしましょう。モックに明示的に記載がなくても、ユーザーが様々なデバイスで閲覧することを考慮し、タブレットやスマートフォン向けのレイアウト調整が必要になる場合があります。これにより、各コンポーネントのサイズや配置も適切に調整されるべきです。
コンポーネントの命名規則を確認する
ここでは各コンポーネントの名前が意味を持ち、実装に適しているかを確認します。適切な命名規則を採用することで、コードの可読性が向上し、チーム内でのコミュニケーションがスムーズになります。
具体的なポイントとして、命名規則を統一し、同じ種類のコンポーネントには同じ接頭辞や接尾辞を使用されているか確認します。例えば、すべてのボタンコンポーネントに「Button」を含めるなどがされているか見てみるといいでしょう。
コンポーネントの役割や機能が一目で分かる命名になっているか確認します。この時点で分かりにくいと感じたのであれば直ちに変更するべきでしょう。この時点で分からないという事は、既にデザイナーとエンジニア間で解釈が異なっているという事になります。ぜひ変更を検討してみてください。
再利用可能な要素を探す
Figmaでモックを作成されていれば、要素がコンポーネント化されていることが多いです。再利用されているUI要素を見つけることで、実装前にどの程度の共通コンポーネントが必要かを洗い出すことができます。共通コンポーネントは汎用性が高く、異なる場面で再利用できるように設計することが求められます。そのため、各コンポーネントがどのようなデータや状態を受け取る必要があるかを検討することが重要です。
汎用的なコンポーネントの作成方法については ここでは説明しません。以前すでに紹介しておりますので、もし興味があれば、以下のブログをご覧ください。
Reactで実践する汎用コンポーネント設計の考え方 また、再利用可能なコンポーネントでなくても、もし似たような機能を持つコンポーネントが存在するなら、何故分けて作成されているのかそれは統一できないのか、ユーザーにどういう影響を与えるのかを考えることも大事です。もし統一することが出来ればその分工数も減り、別の実装を行うことが出来ます。仕様書やモックを確認しながら「これは何のために作られている？本当に必要？」というのを常に考える必要があります。
コンポーネントを階層に分割する モックを観察して必要な情報を整理した後は、コンポーネントの階層設計に取り掛かります。これは、拡張性や保守性を高めるために非常に重要なステップです。コンポーネントを親子関係で考えると整理しやすくなります。このようなLPがあったとしましょう。
これを階層に分割するとこのように分けられると考えられます。
まず、ページ全体や大きなセクションが親に該当します。(LandingPage）このコンポーネントはページ全体のレイアウトを管理し、ヘッダーやフッター、主要なセクションを包含します。
子コンポーネントは、親コンポーネント内のサブセクションや特定の機能ブロックを担当します。例えば、Header、 HeroSection、ServicesSectionなどが該当します。これらはさらに細かい要素を含むことが多く、複数の小さな孫コンポーネントを組み合わせて構成されます。
孫コンポーネントは、ボタンや入力フィールド、アイコンなどの細かいUI要素です。これらは再利用性が高く、複数の場所で使われることが多いです。例えば、Button、Icon、Cardなどが該当します。
このように各コンポーネントがどのように組み合わさっているかを明確にすることで、コード全体の構造が見えやすくなり、後からの修正や機能追加がスムーズに行えるようになります。また、依存関係を整理することで、特定のコンポーネントがどこでどのように使用されているかを一目で把握でき、不要な依存関係を避けることができます。
コンポーネントの設計
コンポーネントの設計では、各コンポーネントの責務と範囲を定義し、必要なpropsを設計します。この際、状態管理の方針やコンポーネント間の依存関係も整理します。特に重要なのはコンポーネントの粒度です。細かすぎると管理が煩雑になってしまい、大きすぎると再利用性が低下してしまいます。適切なバランスを見つけることが、保守性の高いコードベースを作る鍵となります。どのような粒度で分けるのかを考えるためにも、一つ前でお伝えしたコンポーネントを階層で分割する作業は大事になってきますし、それを元にチームでどういう風にコンポーネントを分けるのか話し合いをするべきでしょう。まずはチーム内で共通認識を持つことが何よりも重要です。とはいえコンポーネントの設計で判断に悩むこともあるでしょう。そういった時はMaterial UI やReact BootStrap といったUIコンポーネントライブラリ参考にすると解決の糸口が見つかるかもしれません。また、Reactの公式ドキュメント を読むのも参考になるはずです。
技術的な実装方針を固める
実装に入る前の技術的な検討は、プロジェクトの成功を左右する重要な要素です。まず、スタイリング手法の選択から始めます。Tailwind CSS やStyled Components など、複数の選択肢の中からプロジェクトに最適なものを選定する必要があります。
状態管理についても慎重な検討が必要です。例えばReactを使用する場合、Redux などのグローバルな状態管理ライブラリーとuseStateによるローカルな状態管理の使い分けを、チームやプロジェクトのルールに基づいて決定します。
また、アニメーションの実装方法やレンダリングの最適化、アクセシビリティ対応など、パフォーマンスと使いやすさに関わる技術的な判断も重要です。これらの決定はプロジェクト全体の品質に直接影響を与えます。
さらに、ディレクトリ構成の設計も重要な検討事項です。プロジェクトの規模やチームの開発スタイルに合わせて、コードの可読性と保守性を高める最適な構造を選択します。これは将来的なメンテナンスの容易さにも大きく関わってきます。
まとめ
フロントエンド開発におけるUI実装は、単なるデザインの再現に留まらず、ユーザーエクスペリエンス、アクセシビリティ、パフォーマンス、そして保守性といった多岐にわたる要素を総合的に考慮する必要があります。
また、コンポーネントの粒度や命名規則、依存関係の整理といった細部にまで注意を払いながら設計を進めることで、コードベース全体の可読性と保守性を高めることができます。これにより、チーム全体での開発効率も向上し、ユーザーにとって魅力的で使いやすいアプリケーションを提供することができるでしょう。
弊社では、最新ツールの利点を最大限に活用しつつ、UI/UXデザインから開発、ビジネスサポートに至るまで、プロフェッショナルな視点でプロセス全体をトータルにサポートしています。特に、人間ならではのクリエイティビティや細部への徹底したこだわりを大切にすることで、クライアントに寄り添った本当に価値あるITストレスフリーなサービスを提供しています。
今後も最新のデザインツールや開発手法について、引き続き情報を発信してまいりますので、ぜひお楽しみに！
こんにちは、デジナーレ福岡オフィスの大坪です。
まだ読んでいない方はこちらからぜひご覧ください！
デザイナーでなくてもUIデザインが作れる！? Uizardとは？
UizardのHandoff機能とは？ 今回ご紹介するのは、Uizardと似たような機能を持つ「Galileo AI」というツールをご紹介します。Galileo AIはテキストや画像から簡単にUIデザインを自動生成でき、デザインの経験がなくてもプロ並みの仕上がりが期待できるということで、とても注目されています。
Galileo AIってどんなツール？
Galileo AIは、テキストプロンプトや画像を基に、専門的なスキルがなくてもウェブやモバイル向けのUIデザインをAIによって簡単に自動生成できるツールです。
共同設立者であるヘレン・チョウは、デザイナーが業務の中で「本来注力すべき重要なスキル」を発揮する時間が不足しているという課題を感じていました。当時を振り返りGalileo AIを創設するきっかけについてこう話します。
2022年に大規模言語モデルの進化を見て、デザイナーが繰り返し行っている作業の一部を自動化できる可能性があると感じました。それにより、デザイナーがビジネスや戦略的スキルにもっと時間を割けるようになれば、彼らは本当に輝ける場所で力を発揮できると思いました。 Diveによるインタビューより抜粋
2024年2月に公式リリースされたGalileo AIは公開後、わずか3日で100,000以上のデザインが生成され、750,000インプレッションを記録するなど大きな注目を集めました。このツールはデザイナーだけでなく、エンジニアやデザインに詳しくないユーザーにも広く利用されており、その使いやすさと高品質な成果物が評価されています。
Galileo AIの主要機能
Explore
Exploreは、ユーザーが他のユーザーによって生成された実際のUIデザインを閲覧・使用できる機能です。単なるテンプレート選びではなく、実際に使用されているデザインを参考にすることで、より実践的なインスピレーションを得るだけでなく、どんなプロンプトを入れてUIを生成したのかも閲覧することができます。また、必要に応じて閲覧したUIをFigmaにエクスポートしたり、HTMLでコードの書き出しすることも可能です。これにより、デザインのカスタマイズや実装がスムーズに行えます。
Text to UI
Text to UIは、ユーザーがデザイン要件を入力すると、AIがUIデザインを自動的に生成します。これにより、ユーザーはアイデアを迅速に視覚化できます。これまでデザイナーが時間をかけて検討し、ツールを使いこなして実現していたプロセスの多くを、Galileo AIがサポートしてくれます。
使い方
ログイン後、画面中央のテキストフィールドで生成したいデザインの指示 を入力するか、左端のメニューから「Text to UI」をクリックします。今回は「Text to UI」からデザインを作成したいと思います。
すると下のような画面に遷移します。前回にUizardでUIを生成した時と同じプロンプトを入れてみたいと思います。こちら からご覧ください。
前回同様まずはdesktopのUIを作っていきますので、まずは「Web」を選択します。
従業員を管理できるアプリケーション。勤怠管理、休憩時間管理、従業員のスケジュール確認などの機能があります。
するとGalileo Botがレスポンスが返ってきました。
了解しました！
Uizardの時はこのような最初の生成の段階で会話ではなく、決められたフォームに入力をしていく形式でした。驚いたのがシンプルな指示に対して、内容を理解し誤解がないように仕様を確認してきたことです。
はい、その通りです！それに加えて、以下の点も考慮したいです！
数分ほど待つと、Galileo Bot がUIデザインを６画面生成してくれました。
こちらがリクエストいただいたデザインです。
生成されたUIをFimgaにエクスポートしていきます。
Fimga(デスクトップ)
よく見るとカレンダーの日付であったり、ヘッダーがサイドメニューに途中変わっていたりとありますが、全体的なトーンは全体を通して統一感があるように見られます。
Galileo AIに戻り、「Code」モードに切り替え、書き出しも同時に行ってみます。
コードをコピーし、codesandboxで描画してみます。
余談ですが、同じチャット内でモバイル用のUIの生成もお願いしましたが、Uizard同様、違うデバイスを生成するためには新しいスレッドでなければいけないようです。
ご迷惑をおかけして申し訳ありませんが、このスレッドではデスクトップ用のデザインしかお手伝いできません。
気を取り直して、新しいスレッド内で同じプロンプトでモバイルも生成してみました。こちらは３画面生成してくれました。
Fimga(モバイル)
Image to UI 続いてImage to UIについて見ていきましょう。こちらはユーザーがアップロードした画像を参照し、AIがそれに基づいたUIデザインを作成します。この機能により、既存のビジュアルを活用してデザインを進めることができます。
使い方
「Text to UI」の時と同じようにサイドメニューから「Image to UI」をクリックします。コンタクトページ の画面をスクリーンショットし、アップロードを行います。
生成したものがこちらです。
デスクトップ
モバイル
こちらの機能もFigmaにエクスポートができるので行います。出力したのがこちらです。
指定したカラーは踏襲してはいるのですが、デザイン自体は画像を元に新たに作成したといった印象が強いです。デスクトップ画面にいたってはフッターそのものが無いなど情報も欠如しています。
デスクトップ
モバイル
こちらはどちらも生成されたものと全く同じに描画できています。エクスポートしたコードを使うときの注意点として、コードをそのままコピーしても日本語が文字化けしてしまうので、<meta charset="UTF-8"> タグを <head> セクションに入れる必要がありますので気を付けましょう。
まとめ
いかがだったでしょうか。Galileo AIはテキストやイメージからUIデザインを自動生成し、仕事の効率化をサポートすることができるツールでしたね。
特筆すべき点として、Text to UIではChatGPTのようにチャット形式で対話しながらデザインの要件を詰められる事や、生成されたUIデザインの統一感の高さが挙げられます。また、現場で広く使用されているFigmaへのエクスポートに対応していることは、実務での活用可能性を高める重要な特徴といえます。生成されたデザインがオートレイアウトで作成される点も作業効率の面で魅力的です。
しかしながら、いくつかの制約や注意点も存在します。デバイスごとに別スレッドでの生成が必要な点や、Image to UIでの修正には、再度画像をアップロードする必要があるといった制約があります。また、有料版であってもクレジット制が採用されており、1画面の生成に10クレジットを消費する仕組みとなっています。デザインの修正を行う際にもクレジットが要るため、計画的に使用していく必要があるでしょう。クレジットを１か月以内にすべて使い切ってしまった場合、翌月まで待つか、追加でクレジットを購入しなければなりません。
Figmaへのエクスポート時には、すべてのレイヤー名が同一になってしまう点も、実務での使用時には注意が必要です。
このように、Galileo AIはデザインの専門知識がなくてもプロフェッショナルなUIデザインを生成できるツールとして非常に魅力的ですが、実務での活用においては、その特徴と制約を十分に理解した上で使用することが重要といえるでしょう。今後のUIデザイン制作の効率化に大きく貢献する可能性を秘めたツールとして、さらなる進化が期待されます。
弊社では、最新ツールの利点を最大限に活用しつつ、UI/UXデザインから開発、ビジネスサポートに至るまで、プロフェッショナルな視点でプロセス全体をトータルにサポートしています。特に、人間ならではのクリエイティビティや細部への徹底したこだわりを大切にすることで、クライアントに寄り添った本当に価値あるITストレスフリーなサービスを提供しています。
今後も最新のデザインツールや開発手法について、引き続き情報を発信してまいりますので、ぜひお楽しみに！
引用元：Galileo AI
こんにちは、デジナーレ福岡オフィスの大坪です。 前回、AIを活用したデザインツールであるUizardについて解説いたしました。
まだ読んでいない人はこちらから！
デザイナーでなくてもUIデザインが作れる！? Uizardとは？ さて今回は、Uizardの注目すべき機能の一つである「Handoff機能」についてご紹介します。この機能とは一体何なのか？さっそく詳しく見ていきましょう！
Handoff機能でできること
Handoff機能の概要
Handoff機能には、大きく分けて2つの主要な機能があります。それは、作成したUIのエクスポート と、コードの書き出し です。
UIのエクスポート機能 コードの書き出し機能
今回は、この中でも特にコードの書き出し 機能に焦点を当てて検証していきます。
「UIのコード書き出し」という機能自体は、FigmaやAdobe XDなどの既存ツールでもすでに提供されています。「それなら特に珍しい機能ではないのでは？」と思うかもしれません。しかし、私が注目したのは、UizardがCSSだけでなくReactコードも書き出せる という点です。
Reactコードをそのまま書き出せるツールがあれば、フロントエンド開発の作業効率は大幅に向上するのが期待されます。特に、Reactを主力とする開発者にとって、これは非常に実用的で魅力的な機能と言えるのではないでしょうか？
Handoff機能の実用性検証
それでは、実際にUizardのコード書き出し機能がどこまで使えるのか、今回はこちらのLogin画面を題材にして検証していきたいと思います。
検証1: スクリーン全体を選択してコードを書き出す
まずはスクリーン全体を選択して画面右側にある「Handoff」をクリックします。CodeのセクションでReact, CSSどちらのコードを書き出したいのか選択できるようになっています。
理想としてはこれで全てのコンポーネントのコードが書き出されることですが、結果は果たして・・・
React
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
import React from 'react' ;
const styles = {
Screen : {
backgroundColor : '#ffffff' ,
} ,
} ;
const Screen = ( props ) = > {
return (
< div style = { styles . Screen } >
{ props . children }
< / div >
) ;
} ;
export default Screen ;
CSS
.screen {
background-color : #ffffff ;
}
描画結果
実際にCodeSandboxで描画した結果はこちらです
白い背景が描画されましたが、それ以外の情報は何も表示されません。この結果から、選択した要素のみがコードとして書き出される ことが分かります。UI全体を構成する他のコンポーネントは含まれておらず、意図した通りの再現には至りませんでした。
検証１では選択したものしか書き出しが行われなかった為、今度はスクリーン内のすべてのコンポーネントを選択してコードを書き出してみることにします。
書き出し時に表示されたメッセージ
Select only one component at a time to inspect its React and CSS code
とメッセージが表示され、なんと複数選択された要素のコード書き出しはサポートされていない ことが判明しました。
以上の検証から、Uizardのコード書き出しは「個別コンポーネント単位」での利用を前提としていることが判明しました。UI全体を包括的に生成することは難しく、複数要素を一括でReactコードに落とし込む機能は現時点では備わっていないようです。また、UizardにはFigmaのようなコンポーネント階層機能が備わっていないため、複数コンポーネントをグループ化してそれをネストし、書き出しを行おうとしたところ、検証２と同じ結果になりました。
この結果をもとに、このHandoff機能が実践レベルの現場開発で即戦力となり得るかを今度は探っていきます。エンジニアにとって重要なのは、書き出されたコードがどれだけ実装作業が効率化できるか、そして実務に耐えうるクオリティを担保できるかです。
検証３実際のUIフローに近い構成要素の書き出し
下記はUizardで生成された、テキスト入力フィールドとボタンのReactコード例です。
InputField.jsx
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
import React from "react" ; & nbsp ;
const styles = {
& nbsp ; Input : {
& nbsp ; & nbsp ; top : "312px" ,
& nbsp ; & nbsp ; left : "486px" ,
& nbsp ; & nbsp ; width : "468px" ,
& nbsp ; & nbsp ; height : "48px" ,
& nbsp ; & nbsp ; padding : "0px 8px" ,
& nbsp ; & nbsp ; border : "1px solid #eeeeee" ,
& nbsp ; & nbsp ; boxSizing : "border-box" ,
& nbsp ; & nbsp ; borderRadius : "64px" ,
& nbsp ; & nbsp ; backgroundColor : "#ffffff" ,
& nbsp ; & nbsp ; color : "#030303" ,
& nbsp ; & nbsp ; fontSize : "14px" ,
& nbsp ; & nbsp ; fontFamily : "Inter" ,
& nbsp ; & nbsp ; fontWeight : 500 ,
& nbsp ; & nbsp ; lineHeight : "18px" ,
& nbsp ; & nbsp ; outline : "none" ,
& nbsp ; } ,
} ;
const defaultProps = { text : "" } ;
const InputField = ( props ) = > {
& nbsp ; return (
& nbsp ; & nbsp ; < input style = { styles . Input } placeholder = { props . text ? ? defaultProps . text } / >
& nbsp ; ) ;
} ;
export default InputField ;
Button.jsx
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
import React from 'react' ;
const styles = {
& nbsp ; Button : {
& nbsp ; & nbsp ; cursor : 'pointer' ,
& nbsp ; & nbsp ; top : '520px' ,
& nbsp ; & nbsp ; left : '486px' ,
& nbsp ; & nbsp ; width : '468px' ,
& nbsp ; & nbsp ; height : '48px' ,
& nbsp ; & nbsp ; padding : '0px 8px' ,
& nbsp ; & nbsp ; border : '0' ,
& nbsp ; & nbsp ; boxSizing : 'border-box' ,
& nbsp ; & nbsp ; borderRadius : '100px' ,
& nbsp ; & nbsp ; backgroundColor : '#7a52f4' ,
& nbsp ; & nbsp ; color : '#ffffff' ,
& nbsp ; & nbsp ; fontSize : '16px' ,
& nbsp ; & nbsp ; fontFamily : 'Inter' ,
& nbsp ; & nbsp ; fontWeight : 700 ,
& nbsp ; & nbsp ; lineHeight : '22px' ,
& nbsp ; & nbsp ; outline : 'none' ,
& nbsp ; } ,
} ;
const defaultProps = {
& nbsp ; label : 'Log in' ,
} ;
const Button = ( props ) = > {
& nbsp ; return (
& nbsp ; & nbsp ; < button style = { styles . Button } >
& nbsp ; & nbsp ; & nbsp ; { props . label ? ? defaultProps . label }
& nbsp ; & nbsp ; < / button >
& nbsp ; ) ;
} ;
export default Button ;
これらのコードは、テキスト入力フィールドやボタンなどのUIの見た目や基本的なレイアウト情報 をコンポーネントとして表現しています。しかし、イベントハンドラやバリデーション、状態管理（入力されたテキストの保持など）といった「動的な振る舞い」は一切ありません。生成されるのはあくまで「見た目」ベースのコードであり、実務的な機能を再現するには、開発者自身がロジックやイベント処理を追記する必要があります。
また、複数要素（例：この入力フィールドとボタンを含むログイン画面全体）を一挙にまとめて出力することは依然として困難なので、一要素ずつコードを取得し、開発者が自らコンポーネントや状態管理ロジックを組み立てる必要があります。
実務レベルでの即戦力性は？
UizardのHandoff機能は、デザインからReactコードを自動生成することで、コーディングの初期段階を短縮するポテンシャルがあります。特に小規模なコンポーネントや、初期プロトタイプを素早く立ち上げたい場面ではいいかもしれないです。
既存プロジェクトへの統合
生成されたコードは主に「見た目」ベースで、既存プロジェクトに導入する際、どう扱えるでしょうか。幸い、生成コードはシンプルなJSXとインラインスタイルベースで記述されているため、技術的な統合ハードルは低めです。適宜Tailwindなどのスタイルガイドラインに合わせて書き換えることも容易でしょう。
しかし、実際のプロジェクトでは、状態管理（ReduxやReact Hooksなど）、命名規約、レスポンシブ対応など、ルールがあります。生成されたコードはあくまで「スタート地点」に過ぎず、それらのプロジェクト固有要件に合わせたカスタマイズ作業は不可避です。
デザイン変更への対応
プロジェクト進行中には、デザインの微修正や仕様変更が頻繁に起こります。Uizard上でデザインを修正し、再度コードを書き出しても、既存の実装との整合はもちろん自動的に取られません。結果的に、開発者は再生成されたコードを参考にし、手動で差分を確認・反映させなければならず、作業はゼロにはなりません。
まとめ
UizardのHandoff機能について見ていきましたが、この機能は「実務でそのまま使える即戦力ツール」と評価するのは難しいのが正直なところです。完全な自動化や大規模開発へのスムーズな導入には課題が残ります。
弊社では、最新ツールの利点を最大限に活用しつつ、UI/UXデザインから開発、ビジネスサポートに至るまで、プロフェッショナルな視点でプロセス全体をトータルにサポートしています。特に、人間ならではのクリエイティビティや細部への徹底したこだわりを大切にすることで、クライアントに寄り添った本当に価値あるITストレスフリーなサービスを提供しています。
UizardのHandoff機能に関する今回の検証結果が、エンジニアの皆様にとって有益な参考となれば幸いです。今後も最新のデザインツールや開発手法について、引き続き情報を発信してまいりますので、ぜひお楽しみに！
日頃はご愛顧を賜り厚く御礼申し上げます。
誠に勝手ながら休業期間を下記の通りとさせて頂きます。
＜休業期間＞
※2025年1月6日（月）から通常営業致します。
こんにちは、デジナーレ福岡オフィスの大坪です。
そんな中、デザインの分野でもAIは活躍しています。今回は、AIの力でデザイナーでない人でも簡単にUIデザインが作れる画期的なツール「Uizard」について解説していきましょう。
Uizardとは？AIの魔法で誰でもデザインが可能に
Uizard(ウィザード)は、AIを活用してデスクトップ、タブレット、スマートフォン向けのUIを、専門知識がなくても自動生成できる画期的なデザインツールです。
CEOであるトニー・ベルトラメリは、Uizardについてこんな思いを語っています。
『今日、業界を問わず、すべての企業はソフトウェア企業であり、顧客、従業員、またはその両方に役立つユーザーフレンドリーな製品を構築する必要があります。それにもかかわらず、ほとんどの従業員はソフトウェア設計の専門家ではありません。 誰もが自分のアイデアを簡単かつ迅速に実現、伝達、テストできるようにすることです。』
このことから、Uizardはデザインの専門知識を持たない人でも、質の高いUIデザインを手軽に作れる環境を実現したいという思いで作られているように感じます。
例えば、プロダクトマネージャーが新サービスのプロトタイプを急いで作りたい時。クライアントへの企画書にイメージ図を添付したい時。デザイナーが不在の中、エンジニアが急遽UIを作らなければならない時。
Uizardでは、白紙のキャンバスからのデザイン作成も可能ですが、AI機能を活用すれば、数回の簡単な質問に答えるだけで、わずか1分程度で洗練されたUIデザインを生成できます。
Uizardが「Magic」という言葉をツール内で使っているのですが、あっという間に素敵なデザインができあがる様子は、まさに魔法そのものです。
Uizardの主要機能
Uizardが非デザイナーでも簡単に扱えるサービスというのは理解できましたが、既に世界的にシェアを誇っているデザインツールとUizardは何が違うのでしょうか？ここではUizardにどんなことが出来るのかAutodesigner , Wireframe scanner , Screenshot scanner この３つの機能を中心に見ていきます。
Autodesigner ：オートデザイナー オートデザイナーはChatGPTのような会話形式でデザインができる、AIアシスタント機能です。テキストで意図を伝えるだけで、リアルタイムでデザインを生成・修正できます。
最新のAIのバージョンである２.０版(有料版のみ)では、AIと会話しながらデザインできる機能が追加されました。例えば、「ここにボタンを追加して」「このセクションの色を変更して」といった具合に、普通の言葉で指示するだけで、すぐにプロトタイプが作れてしまいます。
使い方
自分のダッシュボードの「Start Creating」項目内の「Generate with Autodesignare」を選びます。
AIに対して指示を行う画面に遷移したら、生成するプロジェクトの指示を与えていきます。
プロンプトは日本語でも可能のようですが、今回は英語で入力してみました。
Q１．Which device are you designing for?(どのデバイス向けにデザインしますか？)
Q２．Describe your project in plain English (あなたのプロジェクトをわかりやすい英語で説明してください)。
生成スタイル選択画面に遷移します。ここでは何を使ってUIを生成したいのか選ぶことが出来ます。
最後に作成するプロジェクトのスタイルについて聞かれます。
Q３．Describe the preferred style for your project (あなたのプロジェクトに適したスタイルについて説明してください)
色味やテイストをタグで選ぶ項目では、Light、Modern、Corporateのタグを選択しました。
レスポンシブは同時に作成できなかったので、同様のステップでデスクトップの作成してみます。
こちらは９画面作成してくれました。
アイコンのサイズやボタンの余白などが画面ごとに違うといった気になるところはありますが、いずれも叩き台としては十分な精度ではないでしょうか？
Wireframe Scanner : ワイヤーフレームスキャナー
続いてワイヤーフレームスキャナーという機能です。こちらは手書きのワイヤーフレームを写真に撮ったものや、スクリーンショット等の画像をアップロードするだけで、 AI が画像を認識しデザインを書き起こしてくれるというものです。
使い方
まず新しいプロジェクトを開き、左側のサイドメニューの中にある「Magic」の中の「Wireframe Scanner」をクリックします。 するとAIのチャット画面が表示され、どのデバイス向けのプロジェクトを作成したいか聞かれます。今回はデスクトップを選択しました。その後パソコンから画像をアップロードするかQRコードを使ってスマホから画像をアップロードするか選択できます。 今回はQRコードを使ってスマホからデータを送ることにしました。
スマホでQRコードを読み込むとすぐにブラウザが開きました。(画面左)そこで「select from files」をクリックし、画像を選択します。
完成したのはこちらです。
じつはこの画面、弊社のコンタクト ページを手書きで書き起こしてみたのですが、大枠は捉えているといったところでしょうか・・・驚いたのは、このツール自体は日本語のサポートが一切ないのにもかかわらず、手書きの日本語をちゃんと読み取れている所です。手書きでもう少し丁寧にワイヤーフレームを作成すれば、もっと精度は上がるかもしれません。
Screenshot Scanner：スクリーンショットスキャナー
最後に紹介するのがショートカットスキャナーです。こちらは名前の通りスクリーンショットしたものをAIがUIに変換するというものです。公式ページによると生成されたUIは自由に編集ができるようです。ではさっそく使っていきましょう。
使い方
ワイヤーフレームスキャナーと同様の手順で進み、今度は「Screenshot Scanner」を選択します。するとAIのチャット画面が表示されるので、ワイヤーフレームスキャナーの手順で進みます。今回はパソコンからスクリーンショットをアップロードすることにします。
こちらでも引き続き弊社のコンタクトページを使おうと思います。スクリーンショット取ったものをアップロードしてました。こちらではデスクトップとモバイルの両方生成してもらいます。
生成されたものがこちら
こちらは30秒ほどでUIを出力してくれました。ざっと見た感じ大きなレイアウト崩れがあるわけでもなく、コンテンツの位置など正確に把握しているように見えます。ところどころ文字が切れているとこが散見しますが、テキストボックスの幅が狭いだけで、幅を広げたら文字もほとんど正確に読み取ることが出来ているようでした。
まとめ
いかがだったでしょうか？UizardはAIの力を活用することで、デザインの専門知識がなくても質の高いUIデザインを作成することが出来るまさに画期的なツールです。
テキストベースでのUIの自動生成
手書きワイヤーフレームのデジタル化
スクリーンショット等の既存デザインのスキャンからUIの再現
といった機能がありましたね。
しかし、便利さの裏にはいくつか注意点もあります。
引用元：Uizard
こんにちは、デジナーレ福岡オフィスの大坪です。
皆さんはReactで開発を進めていくときにコンポーネントの汎用性について考えたことはありませんか？
Reactの汎用的なコンポーネント設計は、実装する上での開発効率と保守性を大きく左右する大事な要素となっています。適切な設計なしでは、プロジェクトの規模が大きくなるにつれて保守が困難になり、開発速度の低下を招くことになります。
ではどのように設計されたコンポーネントが汎用性の高いものになっていくのでしょうか？実例を交えて解説していきます。
汎用とは
汎用（はんよう）：いろいろの方面に広く用いること。「同一規格の部品を—する」
『デジタル大辞泉』（小学館）より
つまり、汎用性の高いコンポーネントとは、様々なユースケースに対応できる柔軟性を持たせたコンポーネント を指します。
汎用性のあるコンポーネントのメリット
１．コードの再利用性が高まり、開発効率が向上
汎用的なコンポーネントの設計
ここでは、テーブルコンポーネントを例にコンポーネントの再利用性を取り上げていきます。
汎用的ではないテーブルコンポーネントの例
では、実際にあなたがプロジェクトで、テーブルコンポーネントを用いて実装を行うことになったとします。
このようなテーブルコンポーネントが既に用意されていました。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
const Table = ( { headerData , bodyData } : TableProps ) = > {
return (
< table >
< thead >
< tr >
{ headerData . map ( header = > < th key = { header . id } > { header . label } < / th > ) }
< / tr >
< / thead >
< tbody >
< tr >
{ bodyData . map ( { body = > (
< td key = { body . id } > { body . item } < / td > ) }
< / tr >
) ) }
< / tbody >
< / table >
) ;
} ;
これを見てどう思いますか？
しかし、例えば別のページでテーブルコンポーネントを再利用したい、そこではソート機能も付けたい、もしくはテーブルも横から縦位置にしたいとなった時、このコンポーネントはそのまま使えるでしょうか？
このような設計では、新しい要件が出るたびに新しくコンポーネントを実装するか、既存のコンポーネントを修正する必要が出てきます。特に前者のようにコンポーネントが必要になる度に新しく実装していたら、似たようなコードがどんどん増えていき、再利用性が高まるどころか、チーム開発だった場合混乱が生じてしまうでしょう。限定的な使い方でしか再利用できない状態 になっています。
コンポーネントの適切な分割
コンポーネントは、小さな粒度で設計する 必要があります。例えば子供のころに一度は目にしたであろう「レゴブロック」は、小さな部品がたくさんあります。この小さな部品を組み合わせて、家を作ったり、恐竜や城を作ったりするのですが、全てはいくつかのパターンに分類された同じ小さな部品の塊 でできています。
先ほどのテーブルコンポーネントはレゴブロックで組み立てたものを接着剤で固めたようなものでした。これでは柔軟な組み替えができません。
画像のようにコンポーネントの分割を意識して設計してみました。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
// HeaderCell.tsx
const HeaderCell = ( { label } : HeaderCellProps ) = > (
< th
style = { {
padding : '8px' , . . .
} }
>
{ label }
< / th >
)
// HeaderRow.tsx
const HeaderRow = ( { children } : HeaderRowProps ) = > (
< tr
style = { {
height : '40px' , . . .
} }
>
{ children }
< / tr >
)
// TableCell.tsx
const TableCell = ( { value } : TableCellProps ) = > (
< td
style = { {
padding : '8px'
} }
>
{ value }
< / td >
)
// TableRow.tsx
const TableRow = ( { children } : TableRowProps ) = > (
< tr
style = { {
height : '40px'
} }
>
{ children }
< / tr >
)
このように各コンポーネントでは最低限のデザインのみを担保している状態です。この小さなコンポーネントを組み合わせることで、さらに大きなコンポーネントを柔軟に実装できます。
コンポーネントの設計では、以下の点に注意を払う必要があります
１．レイアウトに関する最小限のデザインのみを指定する
特にpropsの設計は重要です。既に仕様や実装段階で必要な機能が決まっているものは積極的に組み込んでよいですが、必須でない機能はオプショナルにすることで柔軟性が増します。ただし、「将来的にこの機能が必要かもしれない」という予測に基づいてpropsを追加することは避けましょう。
propsを過剰に渡してしまうと、以下のような問題が発生します
１．コンポーネントの複雑性が増す使用されていないpropsの影響 を考慮する必要がある
このように設計されたコンポーネントを組み合わせることで、様々なユースケースに柔軟に対応できる実装が可能になります。
では、実際にこれらの設計原則に従って作られたコンポーネントを使用してみましょう。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
const UserTable = ( ) = > (
< TableBase >
< HeaderRow >
< HeaderCell label = "Name" / >
< HeaderCell label = "Age" / >
< / HeaderRow >
{ users . map ( user = > (
< TableRow key = { user . id } >
< TableCell value = { user . name } / >
< TableCell value = { user . age } / >
< / TableRow >
) ) }
< / TableBase >
) ;
この例では、基本コンポーネントを組み合わせることで、シンプルながら拡張性の高いテーブルを実現しています。ソート機能やフィルター機能が必要な場合も、これらのコンポーネントをベースに実装できます。
おわりに
汎用的なコンポーネント設計は、開発効率と保守性の向上に大きく貢献します。小さなコンポーネントを組み合わせる設計アプローチを採用することで、プロジェクトの成長に合わせて柔軟に対応できる基盤の実装が可能です。
本記事で紹介した設計の考え方を、是非実際のプロジェクトや個人開発の場で活用してみてください！
こんにちは、デジナーレ福岡オフィスの徳安です。
カスタムフックとは、React の組み込みフック（useState や useEffect など）を活用して、
特定の機能やロジックを再利用可能な形でまとめた関数のことです。
（例 データの取得やユーザのオンライン状態の監視、チャットルームへの接続など）
カスタムフックを使用することで、ロジックの再利用性が向上し、開発効率が改善されるだけでなく、保守性も高まります。
そこで、カスタムフックを活用する際の利点 や注意点 、そしてロジックを切り分けるタイミング について整理してみました。
カスタムフックとは？ カスタムフックとは、React の組み込みフック（useState や useEffect など）を使って、
特定の機能やロジックを再利用可能な関数としてまとめたもの。
カスタムフックを使うことで、コンポーネントからロジックを分離し、
再利用できる形で関数を作成することができる。
これにより、Reactのコンポーネント内で
「UIロジック」と、「ビジネスロジック」や「状態管理」などを分離 することができる。
カスタムフックを使用する利点
1. ロジックの再利用性 カスタムフックを作成すると簡単に再利用が可能になるため、
誰でも同じロジックを利用することができ、コードの記述時間を短縮することができる。
2. コンポーネントの可読性 カスタムフックを使用しロジック部分を切り出すことで、
コンポーネント内のコードがシンプルになり可読性も上がる。
カスタムフックを使用するタイミング 必ずしも重複したコードをカスタムフックに切り分ける必要はない。
★カスタムフックの使用タイミングは、主に次の2つの状況
1. 重複があまりない場合でも、ロジックを明確に切り分ける必要がある場合 カスタムフックは、単にコードの重複を解消するためだけでなく、
コンポーネント内のロジックを明確に分離し、可読性や保守性を向上させるためにも有用。
■ 状態管理が複雑な場合
コンポーネント内で行うロジックが複雑になり、状態や副作用が絡む場合 、
カスタムフックに切り分けることで、コンポーネントがシンプルになり、ロジックが分かりやすくなる。
■ 外部システムとの同期が必要な場合
Reactの状態管理やライフサイクルから離れて、 外部システムとやり取りする必要がある場合に、
カスタムフックにそのロジックをまとめると、コンポーネントの責務を分けるこ とができる。
2. 重複するロジックを再利用する必要がある場合 カスタムフックに切り分けることで、複数のコンポーネントで同じようなロジックを繰り返し書かなくて済むというメリットもある。
特に、同じパターンのロジックを複数回使用する場合 は、カスタムフックに切り分けておくと、コードがクリーンで保守しやすくなる。
カスタムフックの構築 下記コンポーネント内に記載されているfetchData関数で行っている処理は、
多くのコンポーネントで共通するロジックであるため、
カスタムフックに切り分けることで、コードの重複を避け、保守性を高めることができる。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
const Component = ( ) = > {
const [ data , setData ] = useState ( ) ;
const [ isLoading , setIsLoading ] = useState ( true ) ;
const [ error , setError ] = useState ( ) ;
const fetchData = async ( ) = > {
setIsLoading ( true )
try {
const response = await fetch ( 'https://example.com' ) ;
const json = await response . json ( ) ;
setData ( json ) ;
} catch ( error ) {
setError ( error ) ;
} finally {
setLoading ( false ) ;
}
} ;
useEffect ( ( ) = > {
fetchData ( ) ;
} , [ ] ) ;
if ( error ) {
return < div > Error : { error . message } < / div > ;
}
return (
<>
{ loading && (
< div > Loading . . . < / div >
) }
{ data && (
< div > data : { data } < / div > // 取得したデータを展開する
) }
< / >
) ;
}
export default Component
関数内の処理 ★ コンポーネント内に記載されているfetchData関数内で行っている処理は、次の4つのステップ
ローディング状態の管理（setIsLoading(true)） APIリクエスト（try ブロック内で行う） エラーハンドリング（catch ブロック内で行う） 処理完了後にローディング状態を false に設定
この処理をカスタムフックにまとめることで、再利用可能でシンプルなコードになる。
カスタムフックの作成
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
import { useState , useEffect } from "react" ;
const useFetch = ( url ) = > {
const [ data , setData ] = useState ( ) ;
const [ isLoading , setIsLoading ] = useState ( true ) ;
const [ error , setError ] = useState ( ) ;
useEffect ( ( ) = > {
const fetchData = async ( ) = > {
setIsLoading ( true ) ; // ローディング状態の管理
try {
const response = await fetch ( url ) ; //APIリクエスト
if ( ! response . ok ) {
throw new Error ( "Failed to fetch data" ) ;
}
const json = await response . json ( ) ;
setData ( json ) ;
} catch ( error ) {
setError ( error ) ; // エラーハンドリング
} finally {
setLoading ( false ) ; // 処理完了後にローディング状態を false に設定
}
} ;
fetchData ( ) ;
} , [ url ] ) ; // URLが変わるたびに再実行される
return { data , loading , error } ;
} ;
export default useFetch ;
上記のカスタムフックでは、URLを引数として受け取り 、
・取得したデータ(data) ・読み込み状況(isLoading) ・エラーの状態(error)
を含むオブジェクトを返却する。
カスタムフックを使用する 先ほど作成したカスタムフックをComponentコンポーネント内で使用する。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
import useFetch from './useFetch' ; // 定義したカスタムフックをインポートする
const Component = ( ) = > {
const { data , loading , error } = useFetch ( 'https://example.com' ) ;
if ( error ) {
return < div > Error : { error . message } < / div > ;
}
return (
<>
{ loading && (
< div > Loading . . . < / div >
) }
{ data && (
< div > data : { data } < / div > // 取得したデータを展開する
) }
< / >
) ;
}
export default Component
このように、FetchData関数をカスタムフックに切り分けることで、
コンポーネント内のロジックが整理され、より明確で再利用可能な形になる。
そして、カスタムフックにラップすることで、実装時の意図とデータの流れを正確に表現することができる。
コンポーネントの責務をデータの取得や副作用の管理から切り離し 、
ビューのレンダリングに専念させることができる ため、コードがシンプルで理解しやすくなる。
注意点 カスタムフックを使用する際には、以下の注意点を守ることが重要。
ルールに従うことで、コードの可読性、保守性、そして再利用性が高まる。
１．命名は必ず use で始まる カスタムフックを使用する際には、必ず「use」で始まる名前にし、
続く単語はキャメルケース（先頭大文字）で書く。【例】useCounterなど
２．単一責任の原則 カスタムフックを作成する際には、単一の責任を持たせるようにする。
これにより、コードの可読性、再利用性、保守性が向上する。
３．同じカスタムフックを使っても state は別々に管理される カスタムフックは、state 自体ではなく、state を扱う「ロジック」のみ共有できるようにするためのもの。
そのため、同じカスタムフックを異なるコンポーネントで使用しても、各コンポーネントの state は独立している。
４．カスタムフックは、純粋関数である必要がある カスタムフック内のコードは、コンポーネントのレンダリングのたびに実行されるため、
コンポーネントのレンダリングに影響を与えるような副作用を持つべきではない。
まとめ カスタムフックを使用することで、Reactアプリケーション内のロジックを整理し、
コードの再利用性、可読性、保守性を向上させることができます。
カスタムフックは、コードの重複を避けるだけでなく、
複雑な状態管理や副作用を分離するためにも有効です。
適切に使うことで、Reactアプリケーションをより効率的に開発し、保守しやすくすることができます。
ここまで読み進めていただきありがとうございます。
LinkedInは、企業のブランディングやリード獲得に欠かせないビジネスSNSとして広く活用されています。特にグローバルに展開する企業にとって、効果的な運用が重要です。今回は、LinkedInの運用に携わる楳原さんに、運用を始める際のポイントや投稿戦略について詳しくお話を伺いました。
Q. LinkedInを始めたきっかけや、当時解決したかった課題は何ですか？
A. 近年、LinkedInは世界中のビジネスシーンで「名刺代わり」とも言える存在になり、スタートアップ企業のプロモーションにも欠かせないツールとなっています。今回ご支援した企業はグローバル市場をターゲットとしており、SNS運用が整っていなかったため、サポートを提供しました。主な課題は、サービスの海外での認知度をもっと向上させる必要があったためです。
Q. 最初の投稿内容や、それを作る際に意識したことは何ですか？
A. 最初の投稿は企業の概要と今後の展望についてでした。まずは「どんな企業なのか」を広く知ってもらい、信頼できる情報源としてフォロワーとの関係を築くことを意識しました。
Q. LinkedIn運用で最初に設定すべき重要な項目は何なのでしょうか？
A. LinkedIn運用を始める際に、最初に設定すべき重要な項目は、私は5つだと考えています。
①方針
企業アカウントの目的や運用方針を明確にし、どういったゴールを目指すのかを決定する
② 目的
主に採用活動のためなのか、それとも営業ツールとして活用するのかをはっきりさせる。この目的に応じて投稿の内容やトーンが変わってくるため。
③ ターゲット層
業界別にフォロワー層を分析し、どのようなフォロワー層を獲得したいかを定める。定めたターゲットに合ったコンテンツを考える。
④ あるべき姿
企業のイメージをどう伝えるか、またどのようなポジションを築きたいかを定める。信頼性やプロフェッショナリズムが重要視されるLinkedInでは、この要素が特に大事。
⑤ フォロワー属性の優先度
どの属性のフォロワーを優先的に増やすかを決める。例えば、スタートアップ企業であれば、投資家やパートナー企業をターゲットにすることも考慮すべきです。
これらの設定を最初に行うことで、企業アカウントの方向性が明確になり、効果的な運用が可能となります。私たちはクライアントに合わせてこれらの要素を慎重に調整し、信頼性を重視したプロファイル作りをサポートしています。
なるほど！投稿だけじゃなくて、始める前にこんなにもポイントがあったのですね。
A. 投稿の頻度やタイミングは、フォロワーの増加傾向やエンゲージメント率を分析しながら決定しています。一般的な目安として、週に1～2回、1日1投稿を基本としていますが、頻度よりも投稿の質とタイミングが重要です。
タイミングに関する方針
投稿準備 ：
ターゲット層に合わせた投稿タイミング ：
ターゲット層が最もアクティブな時間帯を意識。
ビジネスパーソン向けには、平日の午前中や昼休みに投稿するのが効果的。
イベント・キャンペーン告知のタイミング ：
イベントやキャンペーン前後に複数回投稿を行い、フォロワーの関心を維持・喚起。
ペイド投稿の活用 ：
有料のペイド投稿を適切なタイミングで組み合わせ、最大の効果を目指す。
投稿内容に関する方針
オーガニック投稿とペイド投稿の組み合わせ ：
無料のオーガニック投稿と有料のペイド投稿を組み合わせることで、リーチと効果を最大化。
エンゲージメント重視の内容 ：
無理に投稿数を増やすのではなく、フォロワーにとって有益な情報を届け、エンゲージメントを高めることを優先。
分析結果を基にしたフォロワー増加予測 ：
過去のデータを元に、1回の投稿で増加するフォロワー数を予測し、投稿内容の精度を向上させることで、クライアントの目標達成をサポート。
Q. ターゲット層に効果的なアプローチをするため、どんなコンテンツを重視していますか？
A. ターゲット層に効果的なアプローチをするためには、フォロワーの属性に合わせた二段階のコンテンツ戦略を採用しています。
一段階目：企業をまだ詳しく知らない人向けの「認知・周知」を目的としたコンテンツ 例) 企業の歴史やビジョン、取り扱う製品やサービスの概要
POINT： 丁寧に説明することで、信頼感を醸成し、フォロワーに企業の存在を知ってもらいます。特にスタートアップ企業の場合、ブランド認知が低いことが多いため、この段階での情報提供が非常に重要です。
二段階目：ターゲット層に向けた有益な情報や営業接点となるコンテンツ
例) 業界の最新トレンド、製品に関する技術的な情報、またはクライアントが参加するイベントの告知・レポート
POINT： フォロワーの関心を引きつける工夫をしています。イベント参加に関連するコンテンツは特に効果的で、「事前告知→現地レポート→結果報告」という3段階の投稿が「いいね」や「シェア」につながりやすく、企業との接点を深めるきっかけになります。
Q. LinkedInの他のSNSにはないメリットは何ですか？
A. 前職ではtoC向けにInstagramを運用していましたが、LinkedInは実名での運用が主で、ビジネスに直結するチャンスが多いです。実際にLinkedIn経由で海外のイベントや展示会へのオファーが届くこともあります。また、名刺代わりにLinkedInでつながることが増えてきていて、クライアントからもLinkedInのQRコードを名刺に入れたいとの声が寄せられています。これはLinkedInの運用成功の証だと感じています。
楳原さん、ありがとうございました。
我々では、ＢtoB向けの新規サービスのプロモーション支援を行っています。
今後も新しいノウハウがたまってきたらshareしていきますので、よろしくお願いします。
こんにちは、デジナーレ福岡オフィスの大坪です。
みなさん、「デザインシステム」という言葉を聞いたことがありますか？
デザインシステムとは、製品やブランドのデザインを一貫して効率的に作り出すための、ルールやコンポーネント(部品)の集まりです。 言わば、デザインのためのレシピ本やレゴブロックのセットのようなもので、これによりデザイナーやエンジニアは毎回一から作り直すことなく、品質の高いデザインを素早く作ることができます。
本記事では、デザインシステムの基本概念、エンジニア目線でデザインシステムで気を付けておくことについて解説していきます。
デザインシステムの目的
デザインシステムの主な目的は、ウェブサイトやSNSといった全てのサービスと接する場面で、エンドユーザーに対し一貫した体験を効率的に提供することです。 FigmaやAdobe XDといったツールを使ってデザインを作成しますが、この時にコンポーネントと呼ばれる再利用可能な部品を設計していくことで、デザイン作業の効率性を向上させます。 このコンポーネントは効率だけではなく、統一されたデザインを可能にし品質を保ちつつ、デザイナー、エンジニア、プロダクトマネージャーといったプロジェクトに関わるすべてのチームにとって「信頼できる唯一の情報源」となります。
つまり、デザインシステムは共通認識を持つためのツールとして機能します。ただし、プロダクトの数、チームの規模、事業フェーズなどによって変化していくため完成形はなく、目的達成のためにトライ＆エラーを繰り返しながら継続的に改善していく過程こそがデザインシステムの本質と言えます。
デザインシステムの構成要素
典型的なデザインシステムは、以下の要素で構成されています：
デザイン原則 ：企業の理念や対象となるプロダクトに対しての思想を記述したもの。これが明確になれば、様々なチームやメンバーで共同作業をすることになったとしても、何を重視しなければならないかが判断できるようになります。スタイルガイド ：カラー、タイポグラフィ、アイコンやスペースなど、UIを構成する要素をまとめたもので、ここで定義されたスタイルやプロパティを使って、画面やコンポーネントを作成していきます。また、エンジニアもスタイルガイドの内容を元に実装していくので、数値や命名は注意して定義しておく必要があります。パターンライブラリ ：コンポーネント、レイアウト、テンプレート、デザインパターンといった再利用可能な要素をまとめたコレクション。UIを作成する時にはこのパターンライブラリから必要な部品を探し出し、レゴブロックのように組み立てていきます。
このほかにも、ライティングガイド、実装コード、イラストレーション・アニメーション、なども必要な場合があります。
これらの要素を組み合わせることで、一貫性のあるデザインを効率的に作成できるのです。
デザインシステムを始めるには？
デザインシステムの構築は、多くの企業にとって重要な課題です。しかし、どこから手をつければよいのでしょうか？ まずは、デザイン原則とブランディングを確立することから始めましょう。これが基盤となります
段階的に拡張していくこのアプローチにより、持続可能なデザインシステムの開発が可能になります。小さな成功を積み重ね、徐々に大きな成果へとつなげていきましょう！
ユーザーインタラクションって？ ユーザーインタラクションとは、ウェブサイトやアプリケーション上でユーザーが対話する方法のことです。 ユーザーとボタンの間でインタラクションはこのようなことが考えられます。
enabled : ボタンの初期の状態です。hovered ：マウスカーソルをボタン上に置くと、色が変わったり、サイズが少し大きくなったりします。click/tap ：ユーザーがボタンを押すと、アクションが実行されます。この時、ボタンの見た目が一瞬変化しします。focused ：キーボードでナビゲーションする際、ボタンにフォーカスが当たると視覚的に強調されます。disabled ：条件が満たされていない場合、ボタンがグレーアウトして押せなくなります。
実装を意識したデザインシステムの構築
デザインシステムが完成したら、次に重要なのはエンジニアとの連携です。以下の点に気を付けて、デザインシステム構築の段階でのミスコミュニケーションを防ぎましょう。
デザイン要素の具体的な定義
デザインを行う上で、コンポーネントのサイズ、色、動作などを明確かつ具体的に記述し、エンジニアが迷うことなく実装できるようにします。
● ボタンのホバー時の色の変化と遷移時間
● フォームのバリデーションエラーの表示のタイミング
● モーダルの表示/非表示時のアニメーション速度
● レスポンスデザインにおける各ブレイクポイントでの要素の振舞い
また、デザイン上の制約や「やってはいけないこと」
● ボタン内のテキストは一行に制限し、折り返さない
● アイコンは指定されたサイズ以外で使用してはいけない
● 指定したカラーパレット以外の色を使用してはいけない
これらのような曖昧な表現を全て明確にしていくことが出来れば、エンジニアの推測作業を最小限に抑えられ、デザインの意図をより正確に伝えられるでしょう。
命名規則の統一
Figmaのようなコラボレーションデザインツールでは、コンポーネントやプロパティ名は日本語でも命名可能です。しかし、実装のことを意識するのであれば日本語は避け、必ず英語で命名しましょう。
命名規則の記法
例えば、エンジニアがJavaScriptのライブラリであるReactを使用して実装を行うと仮定しましょう。
キャメルケースとパスカルケース キャメルケース(ローワーキャメルケース) ：接頭辞を小文字から始める書き方パスカルケース(アッパーキャメルケース) ：接頭辞を大文字から始める書き方(例：PascalCase, ButtonIcon)
この他にもスネークケースや、ケバブケースなどがあります。
英単語の選択
英単語についても工夫が必要です。例えばヘッダーのUIを作成しているとしましょう。
Header : 文書の冒頭部分を指す可能性があり、ページ上部の機能的な要素との混同が起きやすい。NavgationBar : テキストが長くなると実装時にスペルミスの可能性が高まる。TopBar : 位置を特定しすぎており、レスポンシブデザインでスマートフォンの時に位置が変わる場合、この名前は適していないかもしれない。
Headerを採用する場合は他のコンポーネントでHeaderといった命名を避ける、NavgationBarをNavBarに短縮して採用するといった検討が必要になってきます。
プロパティ名から意図を伝える
コンポーネントを作成した際、そのコンポーネントの状態や見た目が変わる可能性がある場合、適切なプロパティの設定する必要があります。ボタンのコンポーネントを例に考えてみましょう。
プロパティ名で意図を明確に伝える
状態の表現 前章のユーザーインタラクションの説明で考えられるボタンの状態（enabled, hovered, pressed, focused, disabled ）を表すプロパティには state が適切だと考えられます。サイズの変更 レスポンシブデザインに対応するため、ボタンのサイズを変更できるようにします。size というプロパティ名が明確です。アイコンの有無 ボタンにアイコンを付加するオプションには、ブール値を使用します。hasIcon という名前で、アイコンの存在を直感的に表現できます。その他の懸念事項
type: もし、ボタンの種類が複数あるのであれば、必要かもしれません(primary, secondaryなど)label: ボタン内のテキストが動的に変わる可能性があるなら、labelバリアントを追加しておけばデザインシステムを構築する時にラベルの修正がスムーズになりますし、エンジニアに対しても親切でしょう。
プロパティ名は、その役割や影響を明確に示すものを選びましょう。３単元動詞 + 名詞 、もしくはis + 形容詞 、has + 形容詞 といった機能に沿った命名を行うといいでしょう。この命名はエンジニアがメソッド名を定義するときの命名規則に合わせるので、バリアント名を見るだけで、エンジニアはメソッドを定義したらいいんだというのが瞬時に理解できます。
これにより、デザイナーとエンジニア間のコミュニケーションが円滑になり、エンジニアにとっても意図したデザインの実装が容易になります。
まとめ
デザインシステムは、一貫性のあるユーザー体験を効率的に提供するための強力なツールです。本記事では、デザインシステムの基本概念から実装を意識した構築方法まで解説しました。
コンポーネントを作成する際、そのUIだけでなく、バリアントや命名で苦戦することがあるかもしれません。バリアントを作成する上で「UI stack」という考え方を取り入れてみるのも良いでしょう。弊社ブログ で紹介しておりますので、ぜひそちらもご覧ください！↓↓
デザインシステムには完成形がなく、継続的な改善が必要です。チーム全体で協力し、ユーザーのニーズやプロダクトの変化に柔軟に対応しながら、より良いデザインシステムを構築していくことが重要です。デザインシステムを通じて、効率的な開発プロセスと魅力的なユーザー体験の両立を目指しましょう。
こんにちは、デジナーレ福岡オフィスの大坪です。
JavaScriptは様々な環境で利用することができますが、JavaScriptでウェブページを開発する上で、内容や見た目をプログラムで操作できることは非常に便利です。この操作を可能にするのが「DOM」です。ここでは、DOMが何か、どのように使われるのかについて説明します。
DOMとは何か？
DOMとはドキュメントオブジェクトモデル (Document Object Model)の略で、HTMLやXMLなどのマークアップ言語で作成されたドキュメントにアクセスするための仕組みになっています。 、DOMを使い、 スクリプト言語を用いてブラウザに描画された内容を抽出、追加や削除を行います。DOMはその手段を提供するAPIなのです。
また、DOMでは名前のとおり、ウェブサイトを作成するために必要なドキュメントに含まれる要素や属性、テキストをそれぞれオブジェクトにまとめられています。このドキュメントを構成する要素や属性らのオブジェクトのことをノードと呼んでいます。
ドキュメントを構成する要素をノードと呼び、オブジェクトの種類に応じて要素ノード、属性ノード、テキストノードと呼ばれています。
HTMLやXML文書をツリー状の構造で表現される
ウェブページを作るときに使うHTMLやXMLは、文字やタグで書かれています。このHTMLやXMLを、DOMでは木の枝が伸びるような形（ツリー構造）で表現されています。
たとえば以下のようなコードがあるとします。
<!DOCTYPE html>
<html>
<head>
<title> ページのタイトル </title>
</head>
<body>
<h1> 見出し </h1>
<p> これは段落です。 </p>
</body>
</html>
このコードをDOMのツリー構造で表すと、次のようになります
最上部に<html>タグがあり、その下に<head>タグと<body>タグがあります。
<head>タグの下には<title>タグがあり、タイトルのテキストが含まれます。<body>タグの下には<h1>タグ（見出し）と<p>タグ（段落）があります。
このように、DOMはウェブページ全体を一つの大きなツリーとして整理し、それぞれのノードを分かりやすく表現しています。また、このDOMツリー上の上下関係は以下のように呼ばれることもあります。
ルートノード : ツリーの最上部に位置するノード。(<html>タグ)親ノード ： 上下関係にあるノード。ルートノードに近いノードのことを親ノードと呼ぶ。(<head>タグ、<body>タグ)子ノード ： ルートノードから遠いノード、親ノードに直接つながっているノード(<head>タグの下の<title>タグ。<body>タグの下の<h1>タグ、<p>タグ)兄弟ノード ： 同じ親ノードを持つノード同士。(<body>タグの下の<h1>タグ、<p>タグ)
DOM のインターフェイス
DOMの基本概念を知ったところで、DOMの中でよく使用されるインターフェイスを見ていきましょう。
Document インターフェイス Document インターフェイスは、ウェブページ全体を表すオブジェクトであり、DOMツリーのルート（最上位）に位置します。Document インターフェイスを使うことで、ページ内の要素にアクセスしたり、新しい要素を作成したりすることができます。
主要なメソッドとプロパティ：
document.getElementById(id)：指定されたIDを持つ要素を取得します。
// IDが"myElement"の要素を取得
const elementById = document . getElementById ( "myElement" ) ;
// 取得した要素をコンソールに表示
console . log ( elementById ) ;
document.querySelector(selector)：指定されたCSSセレクタに一致する最初の要素を取得します。
// 最初の <p> 要素を取得
const firstParagraph = document . querySelector ( "p" ) ;
// 取得した要素をコンソールに表示
console . log ( firstParagraph ) ;
document.createElement(tagName)：指定されたタグ名の新しい要素を作成します。
// 新しい <div> 要素を作成
const newDiv = document . createElement ( "div" ) ;
// 作成した <div> 要素にテキストを追加
newDiv . textContent = "新しいDIVです" ;
// 作成した <div> 要素を <body> 要素の子要素として追加
document . body . appendChild ( newDiv ) ;
document.body：ページの <body> 要素にアクセスします。
// <body> 要素にアクセスして新しい内容を追加
document . body . innerHTML += "<p>新しい段落が追加されました。</p>" ;
Element インターフェイス Element インターフェイスは、HTMLやXML文書の個々の要素を表します。これにより、要素の属性や内容を操作することができます。
主要なメソッドとプロパティ：
element.innerHTML：要素のHTMLコンテンツを取得または設定します。
// 最初の <div> 要素を取得
const divElement = document . querySelector ( "div" ) ;
// <div> 要素のHTMLコンテンツを設定
divElement . innerHTML = "<p>新しい段落が追加されました。</p>" ;
element.setAttribute(name, value)：要素に新しい属性を追加または変更します。
// 最初の <h1> 要素を取得
const heading = document . querySelector ( "h1" ) ;
// <h1> 要素にクラス属性を追加
heading . setAttribute ( "class" , "main-heading" ) ;
element.getAttribute(name)：要素の属性の値を取得します。
// 最初の <h1> 要素を取得
const heading = document . querySelector ( "h1" ) ;
// <h1> 要素のクラス属性の値を取得
const className = heading . getAttribute ( "class" ) ;
console . log ( className ) ; // 取得したクラス属性の値をコンソールに表示
element.appendChild(child)：要素に新しい子要素を追加します。
// 新しい <span> 要素を作成
const newSpan = document . createElement ( "span" ) ;
// <span> 要素にテキストを追加
newSpan . textContent = "新しいスパン要素です" ;
// 最初の <div> 要素を取得
const divElement = document . querySelector ( "div" ) ;
// 作成した <span> 要素を <div> 要素の子要素として追加
divElement . appendChild ( newSpan ) ;
Nodeインターフェイス Node インターフェイスは、DOMツリー内のすべてのオブジェクトの基本となるインターフェイスです。Element インターフェイスも Node インターフェイスから継承しています。
主要なメソッドとプロパティ：
node.parentNode：現在のノードの親ノードを返します。
// 最初の <p> 要素を取得
const paragraph = document . querySelector ( "p" ) ;
// <p> 要素の親ノードを取得
const parentElement = paragraph . parentNode ;
console . log ( parentElement ) ; // 親ノードをコンソールに表示
node.childNodes：現在のノードのすべての子ノードのリストを返します。
// 最初の <div> 要素を取得
const divElement = document . querySelector ( "div" ) ;
// <div> 要素のすべての子ノードを取得
const childNodes = divElement . childNodes ;
console . log ( childNodes ) ; // 子ノードのリストをコンソールに表示
node.removeChild(child)：指定された子ノードを削除します。
// 親要素を取得
const parent = document . querySelector ( ".parent" ) ;
// 子要素を取得
const child = document . querySelector ( ".child" ) ;
// 親要素から子要素を削除
parent . removeChild ( child ) ;
node.textContent：ノードのテキストコンテンツを取得または設定します。
// 最初の <p> 要素を取得
const paragraph = document . querySelector ( "p" ) ;
// <p> 要素のテキストコンテンツを設定
paragraph . textContent = "新しいテキストコンテンツ" ;
// <p> 要素のテキストコンテンツを取得
const text = paragraph . textContent ;
console . log ( text ) ; // テキストコンテンツをコンソールに表示
EventTargetインターフェイス EventTarget インターフェイスは、DOM内でイベントを処理するための基本的なインターフェイスです。Element や Document も EventTarget インターフェイスを実装しています。
主要なメソッド：
addEventListener(type, listener)：指定されたタイプのイベントリスナーを登録します。
const button = document . querySelector ( "button" ) ;
button . addEventListener ( "click" , ( ) = > {
alert ( "ボタンがクリックされました！" ) ;
} ) ;
removeEventListener(type, listener)：指定されたタイプのイベントリスナーを削除します。
const handleClick = ( ) = > {
alert ( "ボタンがクリックされました！" ) ;
} ;
const button = document . querySelector ( "button" ) ;
button . addEventListener ( "click" , handleClick ) ;
// イベントリスナーを削除
button . removeEventListener ( "click" , handleClick ) ;
Windowインターフェイス window オブジェクトは、ブラウザのウィンドウ全体を表します。このオブジェクトには、ブラウザのウィンドウに関する情報や、表示されているドキュメントにアクセスするためのプロパティやメソッドが含まれています。
主要なプロパティとメソッド：
window.document: 現在表示されているウェブページ（DOMツリー全体）にアクセスする。
// ページのタイトルを取得
console . log ( window . document . title ) ;
window.alert(message): 指定したメッセージを表示するアラートダイアログを表示します。ユーザーが「OK」をクリックするまでページの操作を停止します。
// アラートダイアログを表示
window . alert ( "Hello!" ) ;
window.setTimeout(function, milliseconds): 指定した時間（ミリ秒）後に指定した関数を一度だけ実行します。
// 3秒後にメッセージを表示
window . setTimeout ( ( ) = > {
console . log ( "3秒が経過しました" ) ;
} , 3000 ) ;
window.setInterval(function, milliseconds): 指定した時間間隔（ミリ秒）ごとに指定した関数を繰り返し実行します。
// 1秒ごとにメッセージを表示
window . setInterval ( ( ) = > {
console . log ( "1秒が経過しました" ) ;
} , 1000 ) ;
window.innerWidth: ブラウザウィンドウの表示可能な領域の幅をピクセル単位で返す。
// ウィンドウの幅を表示
console . log ( `ウィンドウの幅: ${window.innerWidth}px` ) ;
window.innerHeight: ブラウザウィンドウの表示可能な領域の高さをピクセル単位で返す。
// ウィンドウの幅を表示
console . log ( `ウィンドウの幅: ${window.innerWidth}px` ) ;
window.scrollTo(x, y): ページを指定された位置（x, y）にスクロールします。
// ページを垂直方向に500ピクセルスクロール
window . scrollTo ( 0 , 500 ) ;
windowオブジェクトは省略可能
つまり私たちが開発をしていく上でプログラムの実行結果を表示させたり、デバッグ等でよく使う は、 console.log()は実はwindowオブジェクトのプロパティです。window.console.log()と書く事が出来ます。
まとめ
DOMは、ウェブページの構造をプログラムで操作するための強力なツールです。Document、Element、Node、EventTarget などの主要なインターフェイスを通じて、開発者はウェブページの内容や構造を柔軟に制御することができます。
今回ご紹介したDOMの操作のメソッドはその豊富な機能のほんの一部に過ぎません。これらは覚えるというよりも実装の際に調べたり、都度都度調べていきさらに詳しい情報を探求していくことをお勧めします。DOMの理解を深めることは、最新のフレームワークやライブラリを効果的に活用する上でもきっと大切なはずです。
ぜひこれを機に公式ドキュメント などもチェックしてみてください！
![株式会社デジナーレ[designare]](https://designare.jp/wp-content/themes/designare_new/img/logo.svg){kind=logo}
