Webディレクターが初めてスマホアプリのディレクションをするときに意識すること

Webディレクターが初めてスマホアプリのディレクションをするときに意識すること こんにちは!ディレクターの菅原です。
私はエクストーンにデザイナーとして入社して、約4年前にディレクターにジョブチェンジをしています。
(余談ですが、今のところエクストーンでのジョブチェンジ制度の利用は先にも後にも私だけですが、ジョブチェンジ歓迎だと思います!)
デザイナー時代はほとんどがWebプロジェクトに携わっており、ディレクターに転身してからもWeb関連のサービスが中心でした。
しかし、最近ではスマホアプリ(以降、アプリ)が急増し、アプリのディレクションに慣れるまでに時間がかかりました。
今日は、Webディレクターがアプリのディレクションに挑む際に注意すべきポイントや意識すべきことについて紹介したいと思います。

Webとアプリの違い

Webとアプリは異なる特性を持ち、デザインや開発において異なるアプローチが必要です。
適切な判断を行うために、それぞれのプラットフォームの違いを理解することが大切です。

Web

  • プラットフォームの制約が少なく、自由度の高いデザインが可能です。
  • PCからスマホまで、様々な画角表示への配慮が必要です。
  • 逆に自由度が高いからこそ、ユーザーエクスペリエンスの一貫性に注意が必要です。

アプリ

  • iOSとAndroidそれぞれのガイドラインに沿ったUIが理想的です。
  • スマートフォンの小さな画面での利用を想定したシンプルなデザインが求められます。
  • プラットフォームごとにベースとなる思想や技術的な違いがあるため、それぞれのOSの理解が必要です。

要するに、Webは柔軟性が高く、自由なデザインが可能ですが、様々なデバイスに合わせる必要があります。
一方、アプリはプラットフォームのガイドラインに従い、シンプルで一貫性のあるデザインを提供することで、各OSのユーザーが慣れ親しんでいるインターフェースを提供することができるので、使いやすく感じてもらうことができます。

iOSとAndroidの違い

次にiOSとAndoroidの違いについても簡単に紹介します。
各OSの特性を理解しておくことで、それぞれのOSに対して最適な設計ができるだけでなく、保守性や拡張性へも影響するので、それぞれの特性を認識し、プラットフォームに適したUI/UXを検討することが大事です。

iOS

  • Human Interface Guidelinesに基づくデザイン指針を重視
  • ユーザーエクスペリエンスを中心に据え、直感的な操作性と使いやすさを追求
  • シンプルで奥行きのあるデザインを採用
  • 画面遷移は横にスライドし、滑らかなアニメーションを強調
  • Appleが提供するフォントを使用し、品質に重点を置く
  • アプリストア審査が厳格

Android

  • Google MATERIAL DESIGNを基に、ミニマルなデザイン指針を採用
  • オープンソースで、カスタマイズオプションが豊富
  • 画面遷移は画面を重ねていくイメージで、物理法則に基づいたアニメーションを使用
  • フォントの選択やカスタマイズが多様で、端末ごとに要注意
  • 異なるメーカーがカスタマイズするため、機種依存問題が発生しやすい
  • 端末数が多く、解像度のパターンも多様

iOSとAndroidは、このように異なるデザイン哲学を持つものの、最近ではそれらの違いが平準化されています。
制作側としては、両OSのデザインをできるだけ共通化することがコストやメンテナンス面で利益をもたらす場合もあるため、最低限のOSのガイドラインを遵守しつつ、できる限り共通のデザイン要素を活用することがディレクターの腕の見せ所かもしれないですね。

設計上の違い

ワイヤーフレームを書く上で抑えておきたいのが、設計上の違いです。
ここでは簡単に紹介しますが、端末でそれぞれ確認すると分かりやすいと思います。

OS標準の戻るボタン(ナビゲーションバー)の有無

ナビゲーションバー
Androidにはナビゲーションバーが存在します。
この戻るボタンを押した時の挙動まで整理できていると良いです。

タイトルの配置方法の違い

タイトルの配置方法の違い
iOSではタイトルは画面上部に中央寄せされ、タイトルバー左側には「戻る」ボタンが表示されます。これに対して、Androidではタイトルは画面上部に左寄せされることが多いです。

同一機能・意味を持つアイコンや配置の違い

たとえば、「前画面に戻る」ボタンや他のアクションのためのアイコンやボタンは、iOSでは「<」を使用し、Androidでは「←」を使用することが一般的です。
同様に、ブックマーク、共有、ダウンロードなどの機能についても、iOSとAndroidではアイコンやUIの配置が異なることがあります。

ユーザーが異なるプラットフォームのアプリを使っても違和感なく操作できるよう、各プラットフォームの特性を考慮してデザインすることが大切です。実際に端末で見比べてみると良いですよ。

アプリの開発

そして、開発についても、それぞれの開発手法についても理解が必要です。
プロジェクトによって、安定性を求める場合や、コストとメンテナンスに重点を置く必要がある場合など、様々だと思います。その時に開発手法を理解していることで、プロジェクトの要求事項に合致した提案が可能になり、リソースの最適な活用とユーザーエクスペリエンスの最適化ができるようになります。

Native(Swift/Kotlin)

アプリをiOS(SwiftまたはObjective-C)およびAndroid(KotlinまたはJava)のプラットフォーム固有の言語で個別に開発する方法。

  • メリットとして、アプリの動作速度やユーザーエクスペリエンスを最大限に高められます
  • デメリットとして、iOSとAndroidの2つのプラットフォーム用に個別に開発する必要があり、デザインを2つ用意する必要があります

Webviewアプリ

ネイティブアプリの中でWebコンポーネント(Webページ)を表示する方法

  • パフォーマンスやコストを重視する場合、WebviewとNativeを組み合わせることも可能です
  • メリットとしては、運用が楽で、Webview内の更新時にはアプリのアップデートが不要です。ただし、デメリットとして、圏外の状況での表示には制限があるので注意が必要です
  • デザインは1つだけ用意すれば良いです

クロスプラットフォーム(Flutterなど)

1つのコードベースでiOSとAndroidの両方のプラットフォームに対応する方法

  • 1つの開発言語でiOSとAndroidの両方に対応できます
  • メリットとして、デザインは1つのデザインで両プラットフォームに適用できます
  • デメリットとして、パフォーマンスは若干低下し、アプリのサイズ(容量)が大きくなることがあります

Nativeでの開発はパフォーマンスとユーザーエクスペリエンスを重視する場合に採用しますが、プラットフォームごとに開発が必要です。Webviewは運用が楽でコスト効率が良いですが、一部制限がある場合があります。クロスプラットフォームは1つの開発言語で両プラットフォームに対応できますが、パフォーマンスやアプリサイズに注意が必要です。
それぞれにメリットデメリットがあるので、この3つの中から最適な開発手法を選択することが大事です。

アプリの構成と設計

アプリの構成と設計において、画面の分割やメニュー形式、画面遷移などの要点を適切に選択・設計することが大切です。

1. 画面の目的と細分化
  • 1つの画面に1つの明確な目的を持たせる(1つの画面のなかで複数の操作をさせず、必要な場合は画面を分けるのが好ましいです)
2. 基本的なメニュースタイル
  • 下部タブ(2以上から6まで、主に4〜5個)
  • ドロワー型メニュー
3. レイアウトスタイル
  • リスト型(縦方向の一覧表示)
  • タイル型(2〜3列の表示)
  • カード型(Instagramのようなデザイン)
  • カルーセル型(横方向の一覧表示)
4. 動きのパターン
  • 通常の画面遷移はOSに任せる(Androidは機種に依存)
  • モーダル画面(元の画面の上に別のウィンドウを表示する方法)を使い、一時的な画面切り替えに活用
  • ポップアップを使用して、お知らせや情報を強制的に表示
  • ダイアログでは、OS標準のUIを活用し、文字色や表示内容に注意(AndroidとiOSではダイアログのデザインやタイトルの扱いに違いがあるため、注意が必要)

まとめ

アプリのディレクションにおいては、Webとは異なるルールや要点を把握し、ユーザーにとって魅力的で使いやすいアプリを開発するためにこれらのポイントを意識してアプリのディレクションをしていきましょう。
Webディレクターからスマホアプリのディレクションは最初は難しく感じるかもしれませんが、ルールさえ覚えれば何とかできます!分からなくなったり、困った時は手元の端末でアプリを片っ端から見て学ぶのが近道です。定番のアプリ、競合アプリ、類似のアプリなどたくさんインストールして、とにかく触ってください。慣れてきたらアプリのディレクションって楽しい!って思えるかもしれないですよ。

UI/UXを向上させるガイドライン作り

エクストーン ディレクターチームの柳澤です。

最近、私たちの日常生活において、コミュニケーション、ショッピング、行政手続き、医療、教育などの多くの活動がデジタルサービス上で行われており、ウェブサイトやスマートフォンアプリはもはや日常において不可欠なツールとなっています。

日常的に使うアプリやウェブサイトはさまざまですが、使いやすいものもあれば、逆に使いにくいものもあります。
良いUI/UXデザインが提供されると、タスクの達成がスムーズになり、サービス提供者とユーザーの両方にとって理想的な状態が生まれます。
逆に不十分なUI/UXデザインは、ユーザーの離脱、サポートコストの増加、そして目標の未達成を引き起こす可能性があり、好ましくない状況を招くことがあります。

この記事では、UI/UXを向上させる方法の中で、「ガイドラインの作成」に焦点を当てて説明したいと思います。

良いUI/UXとは?

一体「良いUI/UX」とはどのようなものを指すのでしょうか?

簡潔に言うと、初めて使う人にとっても「簡単に理解し、直感的に操作ができる」ことや、さまざまな状況下でも「迷わずに目的を達成できる」ことを指し、総じて高い満足度が得られることを言います。

UXについては範囲が広いですが、良いUIの良い例としては、以下などがあります:

  • フォントの大きさや色が読みやすい
  • 背景やボタンの色、大きさ、配置が適切
  • 見出しやボタンの名称が次のアクションを誘導する言葉を使用
  • 情報を探す際に迷わないような言葉の選定
  • ページや画面ごとの情報量の調整
  • 同じ意味やレベルの内容が階層的に整理されていること

ウェブサイトやアプリの開発プロジェクトにおいて、良いUI/UXを提供するためには、全体方針(コンセプトなど)と具体的なガイドラインの確立は有効です。これにより、プロジェクトが一貫性を持って進行し、最終的な成果物の品質が確保されやすくなります。

特に、プロジェクトの規模が大きい場合や、異なるチームが画面や機能を担当している場合、UI/UXガイドラインは非常に有効で、統一的なルールや品質基準を維持するのに役立ちます。

デジタル庁「ウェブアクセシビリティ導入ガイドブック」

様々な企業や官公庁が公開しているガイドラインの中でも、デジタル庁が『誰一人取り残されない、人に優しいデジタル化』を実現するために発行した「ウェブアクセシビリティ導入ガイドブック」は、シンプルでわかりやすく、良い参考例になるのではないかと思います。

専門知識がない人でも理解しやすく、多くの実例や解説が提供されています。PDFファイルの作成から最新のスマートフォンに対応する方法まで、さまざまな内容が包括的に取り上げられています。

www.digital.go.jp

また、デジタル庁のウェブサイト自体が、このガイドブックのアクセシビリティに従ったデザインになっているため、ガイドラインを読みながら実際の適用例を確認することもできます。

日本工業規格「JIS X 8341-3」

『JIS X 8341-3:2016』は、高齢者や障害のある人を含むすべてのユーザーが、使用している端末、ウェブブラウザ、支援技術などに依存せずにウェブコンテンツを利用できるようにすることを目的とした規格です。

waic.jp

この規格は、適合レベル(A〜AAA)ごとの実装チェックリストを提供しており、どのレベルに準拠しているかによってアクセシビリティの品質を判定することができるようになっています。

官公庁のサイトではウェブアクセシビリティ方針の中で適合レベルや検証結果を公開していたりします。

www.cao.go.jp

www.soumu.go.jp

達成レベルが上がるにつれて、規格はより厳格になり、目標達成には高いハードルが設けられ、最高ランクであるAAAを達成するには、相当な労力と費用が必要です。 実際、多くの官公庁でも、適合レベルA〜AAとしているところが多い印象を受けます。

Xtoneでも以前のプロジェクトで「JIS X 8341-3」に対応する実務経験があり、達成基準のチェックリストを順に詳細に検証した経験があります。

独自のUI/UXガイドラインを作ってみる

UI/UXを向上させるためのガイドラインの有効性については前述した通りですが、ここではガイドラインの作成手順を簡単に説明します。

1. ターゲットユーザーの理解

はじめに、サービスのターゲットユーザーが誰なのかを明確に定義します。そのターゲットユーザーがこのサービスを使ってどのような目的を達成する(したい)のかを明確に表現します。

2. 設計方針(UI/UXのコンセプト)の確立

ターゲットユーザーが目標を達成するために必要なUI/UXを明確に定義し、その方針を明示します。これらの方針は、UI/UXのコンセプトとして捉えることができます。

3. 個別のガイドラインの策定

ターゲットユーザーと設計方針を元に、具体的な施策としてのガイドラインを定めていきます。 以下は項目の一例です。

  • トンマナ・カラー
  • ナビゲーション
  • レイアウト
  • ボタンとリンク
  • 画像
  • フォント
  • 手続きや設定における画面遷移
  • フォーム
  • 注釈や注意事項の表現
  • ワーディング

4. プロジェクト全体でガイドラインを遵守する

ガイドラインを策定するだけでは、絵に描いた餅になってしまいます。プロジェクトの関係者に適切に伝え、内容を理解し、実行してもらうことが重要です。これによって、ガイドラインが本来の目的を果たすことができます。

5. 見直しと改善

優れたガイドラインであっても、時代やトレンドに適応しなければ陳腐化してしまいます。ガイドラインの定期的な見直しや改訂により、変化し続ける環境の中でも、フレッシュな状態を保つことができます。

まとめ

UI/UXガイドラインの策定には一定の労力がかかりますが、それに見合ったリターン(サービスの品質向上・それに伴うユーザーの満足度の向上)が得られるのではないかと思います。

ガイドラインは、1つのプロダクトを対象とする場合もあれば、組織が提供するサービス全体を対象とする場合もあります。より対象が多い場合に、ガイドラインは本領を発揮します。

サービスのトンマナがバラバラで統一感がない、、、
使い勝手に一貫性がない、、、
ユーザー体験が今ひとつよくない、、、

そうした課題をお持ちの場合は、ガイドラインを作成してみると良いかもしれません。

Xtoneの福利厚生の取り組みが日経MJで紹介されました

2023/10/16の日経MJで、Xtoneが今年から導入した「婚活サポート」の取り組みが紹介されました。

日経MJ(2023/10/16版)

Xtoneでは社員に「長く働いてもらうこと」を目指して福利厚生を設計しています。

実際、従業員の平均勤続年数は7年前後と、業界の中では長い方です。

福利厚生の内容は時代の変化や会社のステージに合わせてアップデートされていますが、大きく以下の3つに分類されます。

①勉強意欲をサポート
②日々の環境をサポート
③ライフイベントをサポート

それぞれの具体的な内容は以下のようになっています。

①勉強意欲をサポート
  • 端末購入補助制度(年1回最大6万円)
  • 書籍代(全額)
  • イベント・セミナー参加費(全額)
②日々の環境をサポート
  • 住宅手当(会社から1.5km以内の場合、3万円)
  • 引越し手当(地方から東京に引っ越す場合、最大40万円)
  • 健康診断オプション代(最大11,000円)
  • インフルエンザ予防接種(本人もお子様も全額支給)
  • 子ども手当(子供1人につき1万円)
③ライフイベントをサポート
  • 婚活サポート(最大1万円/月)
  • 結婚祝い(5万円)
  • 妊活サポート(最大50万円/年)
  • 出産祝い(5万円)
  • 住宅購入祝金(最大20万円)
  • お子様の入学祝金(小学校:5万円、中学:5万円、高校:10万円、大学:20万円)

 
 

Xtoneでは、一緒に働くメンバーを募集しています!
ご興味のある方は、ぜひご連絡ください!
Xtone 採用ページ

ダークモード対応デザインの効率の良いデータの作り方と注意点

エクストーンデザイナーチームのジョです。
UIデザインをする時に、案件によってはダークモードの対応が必要になることがあります。
しかし、全てのページに対してダークモードの色を指定または修正しようとすると、とても大変な作業になってしまいます。

何度かダークモード対応をするなかで、気にした方が良いポイントがわかってきたので紹介します。

実装しやすいダークモードのデザインデータを作るためには

ダークモード対応で一番重要なポイントは、ライトモードとダークモードの色を指定する時に、色の数と名前を完全に一致させることです。
開発者が実装する時に、同じ名前でライトモードとダークモードの色を紐つけておくと、簡単に画面の切り替えができます。
Figma上でもプラグインを使うと、ライトモードとダークモードを簡単に切り替えられます。 開発者とデザイナーで共通認識を持つことで、効率よく作業ができてミスも少なくなります。

ライトモードとダークモードの色の名前と数を一致させよう

ダークモードの作成に役立つプラグイン

Figmaプラグインの「Dark Mode Switcher」を使えば、簡単にダークモードの画面が作れます。
ライブラリでライトモードとダークモードの色の名前や数を一致しておくと、ボタン1つで簡単に切り替えることができて便利です。

Figmaのプラグインで簡単にダークモードに変換

www.figma.com

色を定義する際に注意すべきポイントは?

ライトモードでは問題なく視認できる配色のバランスでも、ダークモードでは視認性が低下する場合があります。
例えば、ライトモードではテキストの色とボーダーの色が同じでも問題なかったのに、ダークモードでも同じにした場合に視認性が悪く感じられるといった場合があります。
この場合は、ダークモードにおけるテキストカラーかボーダーカラーを別の色に変更する必要があるでしょう。
テキストカラーとボーダーカラーが同一色だからといって、ライブラリの定義をひとつにまとめず、機能別に定義することで、変更がしやすく柔軟性の高いデータをつくることができます。

同じ色でも要素ごとに細かく分けて定義しよう

devモードとローカルバリアブルでさらに便利に

2023年6月にFigmaの大型アップデートがあり、devモードやローカルバリアブルといった強力な機能が追加されました。 特にローカルバリアブルはダークモード対応にも便利です。先述の「Dark Mode Switcher」のような色の切り替えもでき、開発者も確認しやすい色定義を作ることが可能です。 細かな条件付きの色指定も可能なので、これからはプラグインよりもローカルバリアブルを使う機会が増えそうです。 ローカルバリアブルの活用については別の記事で取り上げる予定です。

出典:Figma Learn

おわりに

以上、ダークモード画面の作成方法についての紹介でした。
デザインデータの作り方は、人それぞれ方法があると思います。大切なのは、より効率的で実装しやすい、管理しやすいデータを作ることだと考えています。
今後もデザイン作業についてより良い方法があったら引き続き紹介していきたいと思います。

Droidkaigi 2023-これが本物のAndroid開発の祭典!現地からの生の声と感想

エクストーン Androidエンジニアの市橋です。今回は先日9/14〜16に開催された「Droidkaigi 2023」に参加した際の体験レポートをお届けします。個人的に関心を持ったセッションや会場の雰囲気に焦点を当てて簡単に紹介できればと思います。

会場入り口

「Droidkaigi」とは

Droidkaigi」とは、Android開発の技術共有や交流を目的とする国内技術イベントです。オフライン・オンラインにて国内外問わず沢山のエンジニアが一堂に会します。技術セッションや交流イベントが主な内容です。

個人的に興味を持ったセッション

1. 「Modifier.Node を使いましょう」(sujiさん)

このセッションでは、Jetpack Compose v1.3.0で追加されたModifier.Nodeについて紹介されていました。

去年発表された新しい概念ではありますが、UIレンダリングのパフォーマンスが重視される中でModifier.Nodeの概念は今後より一層に注目されるテーマだなと感じました。

基本実装はModifier.NodeModifierNodeElementクラスをそれぞれ作って、thenで割り当てることで実現できるので、自社のCompose案件でも段階的に導入できたらなと思います。

speakerdeck.com

2. 「Androidアプリの良いユニットテストを考える」(Nozomi Takumaさん)

このセッションでは、Android開発における良いユニットテストについて紹介されていました。

まずは「アプリの変更を容易に保つ」というテスト自動化の目的をしっかり再確認できました。また、自分自身はテストダブル(スタブ、スパイ、フェイク)でのユニットテストの価値を高く評価していましたが、今回そのデメリットも学びました。これからはもっと慎重に使っていくべきだと気づきました。

自社のモバイルチームはテスト文化を作り始めている段階です。今回学んだ良いユニットテストのポイントを考慮に入れて、チーム全員で意味のあるテストを進めていこうと思います。

speakerdeck.com

3. Compose で Android/iOSアプリを作る(m.coderさん)

このセッションでは、KotlinだけでAndroidとiOS両方のアプリを同時に作る方法が紹介されていました。

具体的にはUIをComposeで、ロジックをKMPで実装します。今回のセッションではAPIから取得した猫の画像を表示するというシンプルなアプリを見せてくれました。

Kotlinだけで両方のOSに対応できるのは感動的でしたが、まだ外部ライブラリに頼らざるを得なかったり、制限もある印象を受けました。

しかし数年後、これがマルチプラットフォーム開発の一つの選択になるかもしれないので、情報をしっかりキャッチして、自社の案件で使えるかも検討したいです。

speakerdeck.com

会場の雰囲気

人の多さ

純粋に人の数が多く、セッション部屋を移動するのが若干大変なほとでした。今回のイベントには1000人以上の参加者が来場したので、規模感がイベントの盛り上がりを象徴しているなと改めて感じました。

Welcomeトーク

参加者の反応

参加者たちの中にはノートパソコンを片手に、熱心にメモを取っている方も多かったです。特に印象的だったのは、X(旧Twitter)でハッシュタグ「#Droidkaigi 」を付けて、セッションの内容をまとめたり、議論してたりする方も多くいらしたことです。

Android開発への熱をより感じたい方はぜひハッシュタグで検索してみてください。

技術セッション

交流イベントの盛り上がり

技術セッション以外にも、様々な交流イベントが用意されていました。

  • 協賛ブース
  • ネイル体験
  • スタンプラリー
  • 各種ミートアップ
  • アフターパーティー(一日目)
  • キャリア相談会(三日目)

など、来場者が自由に参加できるスペースが広がっていました。

協賛ブース

普段他社さんのお話を聞く機会はほとんどないので、様々な方とコミュニケーションをとることは本当に貴重な体験でした。因みに、採用やマルチプラットフォーム開発の問題は多くの会社で共通の悩みだなと感じました。

実際に色々と参加してみた中で、来年のDroidkaigiをより有意義に楽しみたい方はこれらのイベントに積極的に参加することをぜひオススメしたいです!

ドロイド君ネイル

おわりに

実際に参加してみて、「Droidkaigi」はAndroid開発に真剣に取り組むすべての人にとって、非常に有益なイベントでした。交流の場でもあるので、運営の方々はじめ、協賛企業、来場者など、「Droidkaigi」に関わる皆で一緒に創る興行だなと非常に感じました。

来年はComposeやマルチプラットフォームの最近Tips、生成AIなどの興味深いテーマが取り上げられることを個人的には期待したいです。そしてまた今日から、自社のプロジェクトに粛々と励みたいと思います。

皆さん本当にお疲れ様でした!

Googleスプレッドシートの変更をSlackへ通知する方法

GoogleスプレッドシートをSlackに通知

こんにちは、Xtoneの松本です。
Google Sheets(スプレッドシート)でタスク管理や試験管理をする際、シートが更新されたらSlackへ通知したいと考える方は少なくないと思います。本記事では、非エンジニアでも簡単にGoogleスプレッドシートの変更内容をSlackへ通知できる方法を紹介します。
※所用時間:約10分〜15分

Googleスプレッドシートの特定の列の表記の変更をSlackへ通知する

今回は以下のようなタスク表を想定し、特定の列が変更された場合にSlackへ通知を送るような仕組みを作ります。今回はステータスを管理する「H列」が任意のステータスに変更された場合に通知が飛ぶようにします。

Slackチャンネルへ通知されるイメージは以下の通りです。

事前に準備しておくもの

事前に準備をしておくものは以下の3つだけです。

それでは、具体的な設定方法の説明に入ります。

1. SlackにWebhookをインストールする

はじめに、SlackにWebhookをインストールします。
手順は下記の通りです。

  • SlackのWEBサイトから「Incoming Webhook」をみつけます
  • 「Slackに追加」します(※Slackにログインしている必要があります)

  • 更新の通知を受け取りたいSlackチャンネルを選び、「Incoming Webhook インテグレーションの追加」を押します

  • Webhook URLが表示されるので、コピーして手元に控えておきます(※後で使います)

  • 画面の下の方にスクロールし、設定を保存します

以上でWebhookの設定は完了です。

2. Googleスプレッドシートを用意する

通知を受け取りたいGoogleスプレッドシートを用意します。

はじめに、列を作る

どのようなフォーマットでも問題ありませんが、以下の3種類の列を作成し、それぞれの列番号を控えておいてください。列番号は「アルファベット」ではなく「番号」で控えてください。
(A列=1、B列=2、C列=3…といった具合です)

記載内容
ID タスクのID
内容 タスクの内容
ステータス タスクのステータス

通知を受け取りたいステータスを決める

ステータスの列がどのステータスになったら通知を送りたいか、を決めておきます。
例えば今回の例では「対応中」「対応済み」「完了」のステータスに変わった際に通知を受け取りたい想定としてあります。

Google Apps Script(GAS)に記述する

さぁ、いよいよスクリプトを書きます。

  • まず、Googleスプレッドシートのメニュー「拡張機能」から「Apps Script」を選びます

  • コードエディタが開いたら、予め記載されている内容(function myFunction〜)をすべて削除します

  • 以下のコードを丸ごとコピーし、貼り付けます
  • プログラムの上部に記載されている以下の内容を、あらかじめ控えておいた内容に書き換えます

※以下は記載例です

上記の記載が終わったら、スクリプトの準備は完了です。

トリガーを追加する

トリガーを追加します。

  • 左のメニューから「トリガー」を選択します

  • 右下の「トリガーを追加」をクリックします

  • 各項目を以下のように設定し、「保存」します

  • Googleの認証画面が表示されるので、認証するアカウントを選択します

  • アカウントへのアクセスを「許可」します

以上で全ての設定は完了です。

試しにステータスを変更してみる

試しに、一つのタスクのステータスを「完了」に変更してみます。

きちんとSlackの指定したチャンネルに通知が飛んでいました。

まとめ

最近では、さまざまなツールをSlackに統合して、通知を中心にした効率的な作業とコミュニケーションが一般的になっています。そのような中で、GoogleスプレッドシートがSlackへの通知を行えないことは唯一のストレス要因でした。逆に、これが実現できるようになることで、Googleスプレッドシートの活用範囲の拡大が期待できます。この記事では、基本的な内容の通知方法を紹介しましたが、さらに発展的なカスタマイズを探求してみても面白いと思います。

たとえば、

  • 「特定の担当者」に向けて、「特定のステータス」になったら通知する
  • タスクが特定の人に割り当てられた場合、通知メッセージにその人へのメンションを追加する

など、より便利で効率的な通知システムはいくらでも考えられます。

また機会があれば、そうしたカスタマイズ版を別の記事で紹介できればと思います。

FigmaのAuto Layout機能でデザイナー・エンジニア間のコミュニケーションをよりスムーズに!

エクストーン デザイナーチームのジョです。

エンジニアさんとデザイン実装についてすり合わせをするときにいつも「可変領域を定義してほしい」と依頼されます。
デザイナーとしても、どのような端末であっても意図通りのデザインを表示したいので、可変領域と固定領域の定義はとても大事なポイントだと考えています。
以前、SketchでUIデザインをしていた時は、都度定義資料などを作成していました。
現在Figmaを使うようになってからは、Auto Layout機能を設定することで定義資料作成の手間もなくなり、エンジニアにも理解しやすいデザインファイルを作ることが可能になりました!

Figmaで一番の便利機能はやはりAuto Layout !

「Auto Layout」とは、コンテンツやオブジェクトの中身に応じて、余白や配置を自動調整できる機能です。
この機能を使うことで、端末画面の大きさに応じた可変レイアウト対応や、コンテンツ量に応じたレイアウト調整をとても楽に行えます。

最近のアップデートでさらに便利に!

2023年6月のアップデートでは、可変幅のmin/max値の設定ができるようになり、回り込み対応も可能になりました。

Figma公式チュートリアルからのスクリーンショット

設定した内容はdevモードで簡単に確認可能!

設定した内容は、エンジニア側でもすぐに確認できます。 2023年6月に登場したdevモードを使うことで、例えば可変(Fill/Hug)と固定(Fixed)など、UI要素のどこが伸びてどこが固定なのか、設定した内容が簡単に確認ができます。

デザイン上で設定した内容がdevモードで確認可能

確認したいオブジェクトを選択するとFillに設定しているところは「100%」、Hugに設定しているところは「Auto」と表示されることがわかります。 (Fixedに設定した場合には「Fixed」と表示されます。)
また、右側のinspect表示パネルには設定したmax-widthの表示も確認できます。

おわりに

デザインの意図通りに実装していただくためには、エンジニアさんとのコミュニケーションはとても重要です。
Auto Layoutを意識してデザインを行うと効率よく作業ができますし、エンジニアさんにも的確な情報を伝えられて一石二鳥です。

今後も作業効率向上やコミュニケーション強化のためのテクニックなど、デザインチームからも紹介していきたいと思います。