for Startups Tech blog

このブログのデザインを刷新しました。（2023/12/26）

Slackワークフローを使って、開発のオンボーディングプロセスを効率化してみた

はじめに

こんにちは、エンジニアリングマネージャーの八巻（@hachimaki37）です。

今回の記事では、Slackワークフロー（以下、ワークフローと呼ぶ）を活用して開発チームにおけるオンボーディングプロセスを効率化した取り組みを紹介します。前回の記事「開発者体験サーベイで始める可視化とカイゼン（続編）」では、開発者体験の可視化について触れました。本記事では、その続編として、可視化を通じて明らかになったチームの課題を解決するための具体的な改善策に焦点を当てます。

前半では、オンボーディングプロセスに感じていた課題感と具体的な取り組み内容を紹介し、後半ではその経緯やチーム全体で得られた成果について振り返ります。

注記：

前回までの記事の内容についてはあまり触れておりません。そのため、以下をお読みいただけると内容の解像度が高くなるかと思います。

目次

前提

当社では、新卒・中途を問わず、入社初日から研修を提供しています。この研修では、フォースタートアップスで働く上で基本的な知識を身につける内容が中心です。一方、業務に直結するオンボーディングは、各配属先で行われます。本記事では、私が所属するグループ（以下、チームと呼ぶ）におけるチームのオンボーディングに焦点を当てています。

オンボーディングにおける課題

オンボーディングのプロセスには、既存メンバーと新人メンバー双方に課題が存在すると考えています。

既存メンバーの視点

例えば、

  • 教育とサポートの負担：新人メンバーのサポートに時間を割くことで、自身の業務が圧迫される。
  • 情報伝達のズレ： 社内プロセスや技術的仕様の伝達が非効率。
  • 進捗の不透明さ：新人メンバーの困りごとや詰まりどころがわかりづらい。

新人メンバーの視点

例えば、

  • 環境やツールへの習熟：新しい開発環境やツールの理解に時間がかかる。
  • コードベースの理解：複雑なコードやアーキテクチャへの適応に時間がかかる。
  • サポート不足：フィードバック機会の少なさによる不安や不透明さ。
  • 心理的安全性：既存メンバーへの聞きづらさ、焦りや不安。

共通の課題

例えば、

  • チーム文化への適応：新人メンバーがチーム文化に馴染むプロセスのサポート不足。
  • コミュニケーションの質と頻度：効率的な情報共有と疑問解消の促進。

解決策と期待できる効果

これら課題を解決するために、ワークフローを導入してオンボーディングプロセスを自動化しました。すべての課題を完全に解決できるわけではありませんが、この仕組みにより、以下のような効果が期待できます。

  1. 汎用性を高め、属人化を解消

    1. チームの資産となる仕組みを構築
    2. レバレッジを効かせた効率的なオンボーディングを実現

  2. 適切なタイミングでの情報提供

    1. 新人メンバーの早期戦力化を促進
    2. オンボーディングプロセスのリードタイムを効率化
    3. プロダクトや業務フローの理解を、新人メンバーのペースで進められる環境を提供
    4. ファーストリリースの早期実現

  3. 既存メンバーの負担軽減

    1. 教育やサポート業務の効率化

具体的な取り組み

ワークフローを使ったオンボーディングの仕組みは至ってシンプルです。下記はイメージ図です。新人メンバーと既存メンバーとの間にワークフローが入り、橋渡しの役目を担っています。 簡単に紹介いたします。

期待すること

ワークフローが完了する時点で、チームでは下記のことを期待しています。

  • 開発環境構築が完了していること
  • チームの開発プロセスを理解していること
  • 各種ルールのインプットを終えていること

上記が達成できていれば、チームでの開発を円滑に進めるための基本的なスキルを習得していると考えられるからです。

概要

ワークフローを活用し、主要なプロセスを自動化しました。これまで、オンボーディングの各工程が完了するごとに既存メンバーがサポートを行い、次の作業を指示していました。そのため、新人メンバーが学ぶべき情報やドキュメントを適切なタイミングでワークフローが提供できるようにしました。

仕組み

  • 誰かが特定のチャンネルに参加した時にワークフローを開始する
  • ボタン操作を活用して、次のステップへ進行する
  • よって、各ステップは新人メンバーおよび既存メンバーのボタン操作により自動通知され、進行していく

構成

ワークフローは全13ステップで構成しており、オンボーディングの目的や期待値、開発環境の構築サポートなど、インプットが必要なドキュメントに加え、3つの演習が含まれています。ステップの一部を紹介します。

  • チャンネルの新メンバーの自己紹介
  • オンボーディングの目的や期待値について
  • おおよそのタイムラインについて
  • アカウントの作成依頼
  • 開発環境の構築サポートについて
  • プロダクト情報について
  • チームの文化について
  • コーディングルールについて
  • 演習
    • ブランチ戦略：GitHub Flow
    • Commitルール：Emoji Prefix
    • デプロイ手順：検証環境へのデプロイ方法

実施例

ワークフローの流れ

  1. 誰かがチャンネルに参加した時に開始する

    • 新人メンバーがチームの開発チャンネルに追加されることで、ワークフローが開始。

  2. 新人メンバーのアクション

    • 指示されたタスクを完了すると次のステップが進行。

  3. 既存メンバーのアクション

    • レビューや指示されたタスクを完了し、ボタンをクリックすると次のステップが進行。

  4. 基本この繰り返し

    • 新人メンバーのアクションに対して、必要に応じて既存メンバーがアクションすることで、段階的にオンボーディングが進行する。

詳細に説明いたします。

1. 誰かがチャンネルに参加した時に開始する

チームの開発チャンネルに追加された時に「チャンネルに参加したユーザー」にメッセージが送信されます。そこからオンボーディングのワークフローが始まります。

実際にチームの開発チャンネルに追加された時に、参加したユーザーにメッセージが送信されます。

2. 新人メンバーのアクション

次のステップでは、ステップのフォームを使い「情報をフォームで収集する」から「チャンネルに参加した新メンバーの自己紹介」を行っていただき、既存メンバーに対して周知するようにしています。

3. 既存メンバーのアクション

上記キャプチャーのように既存メンバーに対してボタンクリックを促し、「確認しました！ありがとうございます🎊」ボタンをクリックしてもらうことで、次のステップが進行します。

4. ワークフロー完了後

新人メンバーが全てのステップを完了すると、ワークフローから既存メンバーに対してその旨がお知らせされます。

このように、新人メンバーと既存メンバー間のコミュニケーションフローにワークフローを組み込むことで、適切なタイミングで情報を提供し、スムーズなオンボーディングを実現しています。

経緯

後半は、開発者体験サーベイで始める可視化とカイゼン（続編）で可視化された課題について少し振り返ります。

開発者体験におけるチームで浮き彫りになった課題は、「フロー状態」と「認知負荷」の2つでした。特に、チーム全体の最適化を図るには「認知負荷」の改善が鍵であると判断しました。

これらの中でも特に 「プロジェクトのソースコードを理解するためのドキュメントは十分である」 を最優先で改善することを決めました。その理由は、新人メンバーが複数名チームに参画する予定があったため、チーム全体の開発生産性を高めるためには、新人メンバーの早期立ち上がりが不可欠と判断したためです。

ドキュメントを充実させることは重要なのですが、ドキュメントだけがあっても上記の目的の達成には課題が残ります。 そこで、ドキュメントの充実に加えて、既存メンバー、新人メンバーにとって、より良い開発者体験を構築できるようオンボーディングプロセスの効率化に取り組むことを決めました。

導入後のフィードバック

実際に5名の新人メンバーに今回紹介したワークフローを使ってオンボーディングを進めていただきました。その結果、以下のようなフィードバックが寄せられました。一部を紹介いたします。

  • 新人メンバーの声

    • ワークフローがあることで、次にやることが明確になった。
    • 演習を通じて開発の進め方を学ぶことができてよかった。
    • ドキュメントに不十分な部分があり、既存メンバーに質問する場面もあった。
    • ワークフローの前段でシステム全体の概要が説明されていると、より理解しやすくなりそう。

  • 既存メンバーの声

    • オンボーディングの負担が軽減された。
    • 自分の業務に集中できる時間が増えた。
    • 新人メンバーのサポートが体系化され、効率的に進められるようになった。

貴重なご意見をいただき、よかった点や改善点をしっかりと把握することができました。これを踏まえ、さらなる改善を進め、チームが継続的に成長できる仕組みを構築していきたいと思います。

その第一歩として、実際に活用いただいた方々と改善ミーティングを行い、ワークフローの構成や内容の見直し、補完作業、ドキュメントの充実化に取り組んでおります。

具体的な変化

昨年10月頃から、ワークフローを活用したオンボーディングを導入しています。従来は、入社後に最初のプルリクエストを作成するまでに約2週間かかっていましたが、Findy Team+のデータを見ると、現在では約1週間ほどに短縮されています。

チームで日々改善を重ねているため、ワークフロー導入だけがこの変化の要因とは言い切れませんが、少なからず効果はあったと考えています。

あとがき

本記事では、ワークフローを活用したオンボーディングの効率化に関する取り組みを紹介しました。この仕組みを導入することで、チーム全体の生産性向上や開発者体験、新人メンバーの早期戦力化に向けた確かな一歩を踏み出せたと感じています。

次回の記事では、開発者体験のこれまでの改善活動を振り返り、開発者体験サーベイの結果を第1回と第2回とで比較します。その数値の変化を分析し、そこから得られた学びや気づきを共有したいと思います。

便利な言葉『多分』 曖昧さが生む可能性とリスク

目次

はじめに

こんにちは！フォースタートアップス株式会社のエンジニアの山崎です。 私たちの日常会話や仕事の場面で、無意識に使っている「多分」という言葉。この言葉には曖昧さや柔軟性を含む一方で、意外なリスクも含んでいます。

記事の目的と背景

この記事では、「多分」という言葉の心理的背景、使いすぎることで生じるリスク、そして改善方法について考察します。この記事のテーマを取り上げたきっかけは、周囲の人から「多分」が口癖になっていると指摘を受けたことでした。その際、「多分」を多用することで相手を不快にさせたり、ネガティブな影響を与えていないかと気になり、自分自身の言葉遣いを振り返るきっかけになりました。そして、このプロセスの中で「多分」という言葉の利便性とリスクについて深く考える機会を得ました。「多分」を適切に使いこなすことで、コミュニケーションをより信頼性の高いものにするヒントをお届けします。

対象の読者
  • コミュニケーションの改善に関心がある方
  • 職場での信頼性を高めたいと考えている方
  • 曖昧な表現を減らしたいと感じている方

「多分」を使う心理的理由

「多分」を使う理由には、いくつかの心理的要因が関わっています。

自信の欠如

十分な情報が揃っていない状況では、「多分」を使って正確性を保とうとする心理が働きます。また、自分の意見に自信がないため曖昧な表現を選び、批判を回避する傾向があります。

相手への配慮

会話の調和を重視し、「多分」を使うことで柔らかい印象を与えます。相手の意見を尊重し、断定を避けることで対立を防ぐ目的があります。

柔軟性と曖昧さの許容

曖昧な表現を使うことで、変化に対応しやすくなり、心理的余裕を感じることができます。グレーゾーンを維持することで、過度に限定された発言を避ける効果もあります。

「多分」が生むリスク

便利に思える「多分」ですが、使いすぎると次のようなリスクが生じます。

信頼性への影響

明確な意見や事実が求められる場面で「多分」を多用すると、発言の信頼性が低下する可能性があります。結果として、聞き手からの信頼を失うリスクがあります。

曖昧なコミュニケーション

「多分」が含む曖昧さは、聞き手に具体的なアクションを取りにくくさせ、誤解を招く恐れがあります。

意思決定の遅延

曖昧な情報が判断を先延ばしにし、チームやプロジェクトの進行に悪影響を及ぼすことがあります。

「多分」に頼らないための方法

「多分」に頼りすぎないための具体的なアプローチを以下に挙げます。

事前準備を徹底する

問題やテーマについて十分に調査し、具体的なデータや根拠を用意することで、曖昧な表現を避けられます。また、質問や議論の展開を予測してシナリオを想定することも効果的です。

言葉の置き換え

「可能性としては高いです」や「現時点では問題ありません」といった具体的な表現を使うことで、曖昧な「印象」を抑えることができます。また、「おそらく」や「推測ですが」などの丁寧な表現で誠実な印象を与える工夫も有効です。

回答を保留して精査する

即時回答を避け、正確性を重視する姿勢が重要です。「現時点では明確な情報がないため、確認してから回答します」といった言い方で、慎重な対応を選択できます。

フィードバックを活用

発言後に周囲からのフィードバックを積極的にもらい、曖昧な表現を特定します。改善のヒントを得ることで、「多分」の使い方を意識的にコントロール可能です。

自分に自信を持つ

不安な気持ちが曖昧な表現を生む原因になることがあります。そのため、自分の意見や判断を信じ、明確に表現する意識を持つことが大切です。

「多分」の使いどころ

「多分」はすべての場面で避けるべきではなく、適切に活用することが求められます。

活用すべき場面
  • 初期段階のアイデア出し：不確実な状況で自由な発想を促すため
  • チーム間の意見交換：対立を避けつつ柔軟なアイデアを共有したいとき

避けるべき場面
  • 重要な意思決定が要求される場面：プレゼンや交渉など信頼性と具体性が必要な状況

まとめ

「多分」という言葉は、日常生活や仕事の場面で多くの人が使う便利な表現です。しかし、その利便性の裏にはリスクも存在します。「多分」の特性を理解し、適切に活用するためのポイントを振り返ります。

「多分」の利便性とリスクを理解する

心理的安全性を提供する一方で、使いすぎると信頼を損なう可能性があります。 曖昧さを許容することでその場の雰囲気を和らげることもできますが、使いすぎると発言の信頼性が低下する可能性があります。「多分」は便利な表現ですが、場面に応じた適切な使い分けが重要です。

適切な場面での使用を心がける

重要な意思決定の場面では明確さを優先し、曖昧さが効果的な場面では柔軟性を活かしましょう。

改善に向けた行動を実践する

具体的な方法を取り入れ、「多分」の使用を意識的にコントロールすることで、信頼性の高いコミュニケーションを目指せます。

おわりに

「多分」という言葉の利便性とリスクを深く理解することで、コミュニケーションの質を向上させることができます。この記事を参考に、日常や仕事の場面で「多分」と上手に向き合い、信頼性と柔軟性のバランスを取った表現を心がけてみてください。

この記事の内容をスライド資料版としてもまとめています。 気になる方はご覧ください。

参考資料

開発者体験サーベイで始める可視化とカイゼン（続編）

はじめに

こんにちは、エンジニアリングマネージャーの八巻（@hachimaki37）です。2024年10月に昇進し、試行錯誤の日々を過ごしております。

今回の記事は、メンバーレイヤーが考えてみた『開発生産性』と『開発者体験』（正編）の続編です。DevEx: What Actually Drives Productivity という論文を基に、開発者体験に関するサーベイを独自に設計し、フォースタートアップスの開発組織で「開発者体験に関するアンケート調査」を実施しました。

サーベイの目的をはじめ、サーベイの設計や設問構成、調査結果からどんなことが可視化されたのかなどについて書いていきたいと思います。

注記：

正編の内容についてはあまり触れておりません。そのため、正編からお読みいただけると内容の解像度が高くなるかと思います。また、個人的見解や解釈が含まれる点にご了承いただけますと幸いです。

目次

本題に入る前に、フォースタートアップスの開発組織と開発生産性のレベルについて少し触れたいと思います。

フォースタートアップスの開発組織

当社では、テクノロジーグループとSTARTUP DBグループという2つのプロダクトチームが存在し、全体でおおよそ20名ほどの開発組織です。私は、テクノロジーグループ（以下、チームと呼ぶ）に所属しております。

開発生産性のレベル

開発生産性のレベルとして3つの階層が定義されています。

※以下、開発生産性の教科書から引用。より詳しい内容を知りたい方は、開発生産性の教科書や開発生産性について議論する前に知っておきたいことをご覧いただければと思います。

レベル1：仕事量の生産性

このレベルでは、特定の作業量をどれだけ効率的にこなせたかに焦点を当てています。価値や売上への貢献は考慮せず、純粋に作業量の観点から生産性を評価します。

今回行った「開発者体験に関するアンケート調査」は、このレベル1に該当します。開発者の体験を可視化し、プロダクトチーム毎に純粋な作業量の観点で改善に生かせるようにしています。

また当社では、Findy Team+を活用しながらプロダクトチーム毎の開発生産性向上にも取り組んでおります。参考値ですが、直近6ヶ月（2024年7月1日〜2024年12月31日）のチームの推移です。チームでは、「オープンからレビューまでの平均時間」と「レビューからアプルーブまでの平均時間」の2つのスタッツを「市場全体（Findy Team+導入企業）の上位10%」に目標を置き、昨年9月ごろから改善に取り組んでおります。

レベル2：期待付加価値の生産性

このレベルでは、仕事量だけでなく、各施策がプロダクトにどれだけの価値をもたらすかを考慮します。ただし、実際の価値を評価するには時間がかかるため、「期待される価値がどの程度リリースできたか」に焦点を当てます。 この観点では、プロダクト開発組織全体のアウトプットが重視されます。

現在、チームではレベル2の「各施策がプロダクトにどれだけの価値をもたらすか」を課題と捉え、各施策の効果測定方法について、リリースに合わせた最適なアプローチを模索しています。

レベル3：実現付加価値の生産性

このレベルでは、売上やKPIなど、実際のサービスに対する具体的な貢献を評価する段階です。このレベルの生産性は、開発チームだけではなく、カスタマーサクセス、セールス、マーケティングなど、組織全体で評価に取り組んでいく必要があります。 このレベルでは、「そのタスクが実際にビジネスの目標に貢献できているか」という観点で評価することになります。

開発生産性の教科書によれば、規定の職務以上の役割を担うこと、越境してお互いに深く入り込んでいくことが求められるなど、職務を超えて開発生産性レベル3の向上に取り組んでいく必要があることから達成が難しいとされています。その理由については私も深く共感しています。ただし、この難しさこそが、私が今取り組んでいる課題でもあります。現在、チームとしてのアウトカムを定義し、サービスに対する具体的な貢献や価値が何であるかを試行錯誤しながら進めています。

開発者体験サーベイ

目的と背景

開発生産性レベル1の向上です。その課題発見を目的としています。実施背景は、開発者にとってより良い作業環境を整備することを目指し、開発組織およびプロダクトチーム毎の開発者体験を可視化するために実施しました。

サーベイ設計

サーベイは、DevExの3つの側面（「フロー状態」「フィードバックループ」「認知負荷」）に焦点を当てた設問を中心に構成しています。また、「雇用形態」「所属」「役職」「勤続年数」などの属性情報を加えることで、サーベイ結果を詳細に分析できる設計としました。

設問構成

サーベイは、5段階評価による26問と、自由回答形式の5問で構成し、段階評価は以下のように定義しています。

  • 1ポイント: 全くあてはまらない
  • 2ポイント: あまりあてはまらない
  • 3ポイント: どちらともいえない
  • 4ポイント: ややあてはまる
  • 5ポイント: とてもあてはまる

設問設計

設問は、意図した回答が得られるように慎重に議論し設計しました。

フロー状態に関する設問

  1. 途切れることなく日々継続的に開発に集中できる。
  2. 会議や中断がなく、まとまった時間を開発に充てることができる。
  3. 予期していないタスクや要求がほとんどない。
  4. チームで協力して対処する必要があるインシデントの頻度は低い。
  5. 私の仕事は魅力的である。
  6. 私が行うコーディングタスクは退屈なものよりも魅力的である。
  7. 自由回答
    • 「フロー状態（集中、没頭、楽しさを感じている精神状態）について、一つだけ改善できるとしたら何でしょうか？」

設問の意図

  • 深い作業に費やした時間の満足度
  • 中断の頻度
  • 開発者の興味を引くタスクか

フィードバックループに関する設問

  1. チーム内での心理的安全性は高い。
  2. 技術的な質問に対し、10分以内に回答を得ることができる。
  3. 開発者は、必要な情報に簡単かつ迅速にアクセスできる。
  4. 開発者が繰り返し質問する内容は、十分にドキュメント化されている。
  5. リクエストしたコードレビューは速やかに（数時間以内）実施される。
  6. リクエストしたコードレビューは迅速に（24時間以内）完了する。
  7. 開発環境にはよく整備された自動テストがあり、結果を迅速に確認できる。
  8. テスト環境（CI）は十分に整備されており、テスト結果を迅速に確認できる。
  9. 自由回答
    • 「質問に対する回答がすぐに得られる（頻度や速度、品質）ことについて、一つだけ改善できるとしたら何でしょうか？」

設問の意図

  • 質問に対する回答が得られる頻度
  • コードの変更が承認されるまでの時間

認知負荷に関する設問

  1. デプロイの手順は最小限で、比較的容易である。
  2. 変更したソースコードは短いリードタイムで本番環境にリリースされる。
  3. プロジェクトやタスクの目標は明確で理解しやすい。
  4. プロジェクトのソースコードは明確でシンプルで、理解しやすい。
  5. ソースコードを理解するためのドキュメントは十分である。
  6. ソースコードの品質は優れており、よくメンテナンスされている。
  7. チーム内およびチーム間でコードや作業の理解を促進する取り組みが行われている。
  8. 会社から提供される機材は充実しており、十分な性能を備えている。
  9. 開発に必要なツールは、会社から適切に提供される。
  10. 作業プロセスや開発者ツールの操作は直感的で使いやすい。
  11. 開発環境の設定手順は整備されており、すぐに開発を開始できる。
  12. 自由回答
    • 「認知負荷（開発者がタスクを完了するために必要な、ワーキングメモリにかかる負荷）について、一つだけ改善できるとしたら何でしょうか？」

設問の意図

  • 変更のデプロイのしやすさ
  • 理解のしやすさ
  • プロセスや開発者ツールの操作の直感性

その他

  1. チームや会社の文化は主体性を持った挑戦を支援していますか？
  2. プロダクトにおいてオーナーシップや使命感を感じていますか？
  3. 自由回答
    • 私たちの開発で気に入っている点は何ですか？
    • 私たちの開発で課題感を感じる点は何ですか？

設問の意図

  • 改善が進みやすい環境かどうか

サーベイの実施概要

調査方法

回答形式：Googleフォームを使用

回答数

回答者数: 13名 ※フォースタートアップスに所属する開発者を対象

調査結果

実際に調査結果をまとめた報告書の一例を紹介いたします。

開発者体験に関するアンケート調査では、「フロー状態」「フィードバックループ」「認知負荷」の3つの側面に関する設問に対して、平均スコアを算出しました。その結果、以下の3つの側面において、3.5ポイント以上の評価が得られました。

これらにより、フォースタートアップスで働く開発者の開発者体験は「やや良い」状態であることがわかりました。

また、全体の大部分を占める「中途（正社員）」のフロー状態を中心に改善を行うことで、フォースタートアップスで働く開発者のパフォーマンス改善が見込めると考えます。

各スコア

フロー状態：3.5 / 5 ポイント

フィードバックループ：3.6 / 5 ポイント

認知負荷：3.6 / 5 ポイント

所属グループ別

テクノロジーグループとSTARTUP DBグループを比較した結果、大きな差異は見られませんでした。

雇用形態別

一方で、雇用形態別に見ると、「中途（正社員）」のフロー状態（3.0 ポイント）とフィードバックループ（3.3 ポイント）に改善の余地があることがわかりました。

要因分析の結果、以下のような傾向が確認されました。

テクノロジーグループ

  • フロー状態において、以下の2つの設問が特に低いスコアを示しました。
    • 「途切れることなく日々継続的に開発に集中できる」: 2.6ポイント
    • 「当初予期していなかった予定外のタスクや要求はほとんど受けない」: 2.8ポイント
  • 弊社では、一部のポジション（主に「中途（正社員）」が担当）で突発的な業務が発生しやすく、これが外れ値としてスコアに影響を与えている可能性があります。

STARTUP DBグループ

  • フィードバックループにおいて、以下の設問が特に低いスコアを示しました。
    • 「リクエストしたコードレビューは、迅速（24時間以内）に完了（Approve）する」: 2.8ポイント
  • Findy Team+で直近6ヶ月（2024年7月1日〜2024年12月31日）の推移を確認した結果、プルリクエストのコメント数が多い傾向であることが判明しました。このことから、コードレビューでの修正作業がスコアに影響を与えている可能性が考えられます。

このように要因分析をFindy Team+と組み合わせることで、課題の仮説も立てやすくなります。

その他

さらに、「チームや会社の文化は主体性を持った挑戦を支援していますか？」という質問に対する回答は4.4 ポイントと高評価であり、フォースタートアップスで働く開発者は新しい取り組みや主体性を持った挑戦を実行しやすい環境であることが示されました。

あとがき

いかがでしたでしょうか。定性的な評価とは別に定量的なデータがあることで、開発組織やプロダクトチームの開発者体験の側面をより明確に可視化することができます。本記事では、2024年6月に実施した第1回開発者体験に関するアンケート調査の結果を中心に紹介しました。あれから半年以上が経ち、プロダクトチーム毎にこのデータも活用しながら改善に取り組んでいます。

次回の記事では、ネクストアクションや改善施策、また2回目アンケート調査の結果を基に数値の変化について執筆を予定しています。

現場での開発生産性レベル1の重要性を感じる一方で、今後はレベル2〜3の達成に向けても挑戦していきたいと思います。

属人的なデザイントークン管理からの脱却

目次

はじめに

こんにちは、STARTUP DB(SDB)の開発をしている杉谷です。

私含めSDBチームでは、デザイナーとエンジニアが密に連携しながらプロダクト開発を進めています。
その中で、「デザイントークンの管理」という課題に直面し、改善に取り組んできました。

フロントエンド開発において「デザインの意図を正確にコードに反映する」ことの重要性を日々の開発で実感しています。特に、デザイントークンの管理は、品質の維持と開発効率の両面で大きな影響を与える要素だと考えています。

今回は、FigmaのLocal Variablesを効率的にSCSSに変換する仕組みを構築した経験についてお話ししたいと思います。

完全な自動化には至っていませんが、従来の手作業と比べて大きな改善を実現することができました。この記事が、同じような課題を抱えているチームの皆さんの参考になれば幸いです。

属人的なデザイントークン管理の問題点

実際にチームで開発を進める中で、以下のような課題を感じていました。

手動管理の限界

// 手動で更新していた従来のSCSS
$color-primary: #1a2b3c;     // Figmaでは 'Primary/Base'
$color-secondary: #2d3e4f;   // Figmaでは 'Secondary/Base'
$spacing-large: 24px;        // Figmaでは 'spacing.large'

この方法には、次のような問題点がありました：

  • デザイントークンの更新が発生するたびに手動でコードを書き換える必要がある
  • 特にcolor・spacingやtypographyの設定は数が多く、更新に時間がかかってしまう
  • 更新漏れや入力ミスのリスクが常にあり、ミスした状態で使用される可能性がある

命名規則の不一致

私たちのチームでは、デザイナーとエンジニアで異なる命名規則を採用していました：

// エンジニア側の命名
$font-size-large: 18px;
$font-weight-bold: 700;
$spacing-x-small: 4px;

// Figma側の命名
// typography.headline.large
// typography.weight.bold
// space.xs

この不一致によって、以下のような問題が発生していました：

  • コードレビュー時に、これがFigmaのどの値なのか確認が必要になる
  • 新しいメンバーが参画した際の学習コストが高くなる
  • 変更が必要な箇所の特定に時間がかかってしまう

解決方法の検討

最初はFigmaのAPIを活用する方法を検討しました。APIを使用することで、Variablesの値を直接参照し、StyleDictionaryで変換するというシンプルな流れを実現できると考えていました。

Figmaのドキュメント（Variables API）を確認すると、変数を参照するためのエンドポイントが用意されていることが分かりました。

しかし、この機能はENTERPRISEプラン以上でないと利用できないという制約があることが判明。私たちのチームのプランでは利用できず、別のアプローチを考える必要がありました（無念、、、）

そこで代替案として、Figmaのプラグインを自作する方法を検討することにしました。

実装

以下の2つのステップで実装を行いました：

  1. Figmaプラグインの作成
  2. StyleDictionaryの設定

Figmaプラグインの作成

実際に作成したPluginはこちらになります：

Export local variables to Json

Plugin URL： Export local variables to Json

下記で実際に書いたコードについて一部解説します。

ソースコード：figma_export_variables_plugin

Pluginの主な機能

デザイントークンをJSON形式に変換し、StyleDictionaryで扱いやすい形式に整形します。

Pluginを使用してJSONに変換

処理の流れ

1.変数コレクションの取得と処理

async function exportToJSON() {
  // ローカルの変数コレクションを取得
  const collections = await figma.variables.getLocalVariableCollectionsAsync();
  // 各コレクションを処理して結果をマージ
  const files = [];
  for (const collection of collections) {
    files.push(...(await processCollection(collection)));
  }
  // 結果をUIに送信
  const mergedBody = Object.assign({}, ...files.map((file) => file.body));
  figma.ui.postMessage({ mergedBody });
}

2.変数の階層構造の作成と値の変換

// 例：'colors/primary/base' → { colors: { primary: { base: { $value: '#1234567' } } } }
name.split("/").forEach((groupName) => {
  obj[groupName] = obj[groupName] || {};
  obj = obj[groupName];
});

3.値の型に応じた変換処理

  • カラー値の変換：RGBAからHEX形式へ

  • 数値の整形：小数点以下の処理

  • エイリアス（参照）の解決：他の変数を参照している場合の処理

StyleDictionaryの設定

StyleDictionaryは、デザイントークンを一元管理し、複数のプラットフォームやフォーマットに変換できるツールです。

以下が実際に、自作Pluginで出力したJSONをSCSSに変換する際に書いたコードになります。

import StyleDictionary from 'style-dictionary'

// プレフィックスの追加 
// 例：typography.headline.large → $typography-headline-large
StyleDictionary.registerTransform({
  name: 'AddPrefixToTheName',
  type: 'name',
  transform: (token) => {
    return `${token.name}`
  },
})

// pxを付与しない項目を定義 
// opacity: 透明度は0-1の小数値 
// font-weight: フォントの太さは100-900の数値 
// line-height: 行の高さは倍率で指定
const EXCLUDED_CATEGORIES = /opacity|font-weight|line-height/


// 数値型のトークンにpxを付与
// 例：spacing.large: 24 → $spacing-large: 24px
StyleDictionary.registerTransform({
  name: 'AddPixelToTheValue',
  type: 'value',
  filter: (token) => {
　　// 数値型で、かつ除外カテゴリーに含まれないものだけを変換
    return token.$type === 'number' && !EXCLUDED_CATEGORIES.test(token.name)
  },
  transform: (token) => {
    return `${token.$value}px`
  },
})

// StyleDictionaryの出力設定
export default {
  source: ['.style-dictionary/tokens/*.json'],
  platforms: {
    scss: {
      transformGroup: 'scss',
      buildPath: 'src/styles/',
      files: [
        {
          destination: '_variables.scss',
          format: 'scss/variables',
        },
      ],
      transforms: ['AddPrefixToTheName', 'AddPixelToTheValue'],
    },
  },
}

主なカスタマイズ内容

  1. 変数名へのプレフィックス追加(AddPrefixToTheName)
    • 例：color-primary → $color-primary
    • バージョン管理や名前空間の分離に役立ちます
      • 今のチームではデザイントークンがV1・V2と混在しているので、ここでそれぞれ判別出来るようにprefixをつけて管理しています
        • 例：color-primary → $v2-color-primary
  2. 単位（px）の自動付与(AddPixelToTheValue)
    • 例：spacing-large: 24 → $spacing-large: 24px
    • 数値型のトークンに自動で「px」を付与します
    • ただし、以下は除外：
      • opacity（不透明度）
      • font-weight（フォントの太さ）
      • line-height（行の高さ）

改善後の状況

自動化による効率化

# コマンド一つで同期が完了
yarn build-style-dictionary

この改善により：

  • デザイントークンの更新が数秒で完了するようになりました
  • 人的ミスのリスクが大幅に低減されました

命名規則の統一

// 自動生成されるSCSS
$typography-headline-large: 24px;
$typography-weight-bold: 700;
$space-xs: 4px;

この改善により：

  • デザイナー・エンジニア間のコミュニケーションがよりスムーズになりました
    • デザイナーとエンジニアで異なる命名規則を使用していたため変数の使い分けに時間を取られていましたが、Figmaの命名規則をベースとした統一により、デザイントークンの運用がスムーズになりました。デザイナーが定義した名前がそのままSCSS変数として使えるため、本来の実装作業に集中できるようになりました
  • コードレビューの効率が向上しました
  • メンバーの学習コストが低下しました

学んだこと

共通言語の重要性

共通言語の重要性について、実際の経験から多くの気づきがありました。

当初、デザイナーとエンジニアで異なる命名を使うことは柔軟性があると考えていました。 しかし、プロジェクトが進むにつれて、それがコミュニケーションコストの増加につながることを実感しました。

特に印象的だったのは、チームメンバーの入れ替わりが発生した際のことです。『なぜこの命名規則を採用したのか』という背景が失われ、コードの意図が理解しづらくなってしまいました。そこで、Figmaの命名規則に合わせることで、プロジェクト全体で一貫性のある共通言語を持つことができ、新メンバーにとっても理解しやすい環境を作ることができました。

この取り組みを通じて、共通言語を設計する際は職種による区分けを避けることの大切さにも気づかされました。エンジニアやデザイナーといった役割で言語を分けるのではなく、プロダクトに関わる全員が自然に受け入れられる/受け入れやすい共通の言語を築くことが、結果としてプロダクトの品質向上につながるのだと実感しています。他所では当たり前のことかもしれませんが、実際に経験することで、その重要性を自分は今回深く理解することができました。

自動化の価値

単純作業の自動化は、工数削減以上の価値があると実感しました。

特にヒューマンエラーのリスクが低減されたことで、品質の維持も容易になりました。
それだけではなく、チームメンバーが本質的な作業に集中できる環境づくりの重要性を学びました。

効率化を超えた学びの機会

この取り組みを通じて、開発における効率化作業の面白さを改めて実感することができました。 また他にも当初は単純な作業の自動化という認識でしたが、実際に取り組んでみると予想以上の発見がありました。

特に印象的だったのは、Figmaのプラグイン開発です。 APIが利用できないという制約は、一見するとマイナスに思えましたが、その制約がむしろより柔軟なアプローチを生み出すきっかけとなりました。 また、当初はチーム内での利用のみを想定していたプラグインが、現在では社外の方々にも活用していただけるようになりました。この予想外の広がりは、効率化への取り組みが単なる業務改善を超えて、より大きな価値を生み出せる可能性を教えてくれました。

振り返ってみると、今回の取り組みは効率化を超えて、技術的な制約との向き合い方や、想定外の価値の見出し方など、エンジニアとしての視座を広げる貴重な機会となったかなと思います。

今後の展望

現在の仕組みをベースに、さらなる自動化と品質向上を目指して、以下のような改善を検討中です

プルリクエスト時にデザイントークンの整合性を自動でチェックし、不整合がある場合は即座に開発者へ通知する仕組みの実装を考えています。これにより、デザインとコードの一貫性をより確実に担保できると良いなと考えています：

  • CIへの組み込み
    • プルリクエスト時に自動でデザイントークンの同期チェック
    • 不整合があった場合の自動通知

デザイントークンの品質管理向上を目的に、以下の機能追加出来ると良いなと考えています：

  • バリデーション機能の強化

現在50名以上の方々に利用していただいているFigmaの自作Pluginですが、より使いやすいものにするため、以下の改善が出来たら良いなと考えています：

  • Pluginの改善
    • UI・UXの改善
    • Userからのコメントを基に機能追加・修正

おわりに

今回は、FigmaのLocal Variablesを効率的にSCSSに変換する仕組みについて共有させていただきました。当初検討していたFigma APIの利用は叶いませんでしたが、プラグインを自作することで課題を解決することができました。

この仕組みにより、デザイントークンの更新作業が効率化されただけでなく、デザイナーとエンジニア間の共通言語が確立され、コミュニケーションの質も向上しました。

みなさんのプロジェクトでも、似たような課題を抱えているかもしれません。本記事が、その解決のヒントになれば幸いです。