GMOペパボのデザイン部という会社横断組織で（自称）デザインエンジニアをやっているgyugyuです。好きな鮨ネタはスズキです。
この記事は GMOペパボデザイナー Advent Calendar 2022 の13日目の記事です。昨日は たるたるさん の 【2022】minneのアクセシビリティを振り返る でした。
この記事では「短期的には効率が下がるものの、中長期的にはより大きい効用をもたらす社内ツールのデザインをしたこと」と、そこから導き出される「社内ツールでもデザインをすることの重要性」について説明します。
前提
この記事におけるデザインとは
この記事において、デザインという言葉で意味しているものは情報設計のことです。リッチなビジュアルの作り方や美しいUIパーツの作り方についてはこの記事では説明していません。それらについてはペパボの他のデザイナーが素晴らしい記事を書いているので、そちらをご覧ください。
効用による社内ツールの分類：短期か中長期か
社内ツールを導入する最大の理由は、業務における生産性を改善するためです。特に、改善を実現できるツールでも、市場に存在する代替物が存在しないものや、代替物が希望する実現方法と大きく乖離している場合には、それを自分たちで開発するインセンティブが大きくなります。
これらの社内ツールには、どれくらいの期間とコストでどの程度の効用を得たいかによっても分類ができます。例えばRPA(Robotics Process Automation)に代表される自動化は、短期・低コストで限られた範囲の生産性改善を実現できます。一方で、もっと抽象的で大きな課題を解決する場合には、より大規模な社内ツールを開発する必要があるでしょう。それを使ってもらうためには中長期的なメリットを説明して納得してもらう必要もありますし、導入後に一時的に生産性が低下することも考えられます。
新規ツールの導入と普及という問題
抽象的な課題を解決する大規模な社内ツールを開発したときには、前述したとおり長期的メリットを説明して使うことを納得してもらう必要がありました。しかし、実際に利用するにあたって初期に求められるコストを支払えず、導入が停滞するという問題が発生します。短期的に成果が求められる環境で起こりがちで、長期的メリットに納得しつつも導入できないという状況になります。
導入を進めるために以前のワークフローを変更し、ツールの使用を必須にするという解決方法もあります。導入を進めるということが目的であればこの方法でも解決はできますが、ワークフローの変更というトップダウンでの導入ではどこかにぎこちなさが生じてしまいます。
言い換えれば、納得できる長期的メリットを提示し、自主的に触って試したくなるツールを作れば、自然と抽象的課題を解決できるツールが導入されるということになります。
複数のサービスブランドごとに異なるルールを適用したい
ここ数年、ペパボでは Inhouseというデザインシステム の設計が行われてきました。デザインシステムというと具体的なコンポーネントライブラリを想像しがちですが、ペパボで設計されたデザインシステムはもう少し大枠なもので、コンテンツのガイドラインなども含まれています。そのサブセットとしてKindaichiという名前のライティングスタイルガイドラインが存在しており、このガイドラインに準拠することで、より明快なコミュニケーションを行えます。
以前は、社内に点在する文章が得意なパートナーが自主的にクオリティアップに励んでいましたが、それは属人的なものなので仕組み化されていませんでした。また、それぞれのパートナーがどこに着目するかでぶれが生じており、校正時に相反するスタイルが修正候補として提示されることもありました。
ペパボのサービスが単一のブランドではなく、複数のブランドで構成されていることも複雑さの要因となっています。各サービスでライティングスタイルガイドラインをまとめるという取り組みも自主的に行われてきましたが、内部の項目や完成度、浸透度がサービスごとにまちまちになってしまったり、パートナーの配属が変更になったときに覚え直しになるという問題が発生していました。
複数のブランドで使用できるようにするため、Inhouseではプロトタイプを提示するのみにとどまり、社内の各ブランドで上書きするという 2階建ての仕組み を採用しています。これはKindaichiについても同じで、アディショナルなガイドラインのみがブランドごとに存在しているということになります。
この2階建ての仕組みを実現可能で、外部へ機密データを送信せずスタンドアロンで稼働する、職種を問わず利用可能な校正ツールとしてKindaichi Check Toolを開発しました。
実際の利用ニーズに即した「コンテキスト」と「トーン」の設計
ライティングスタイルガイドラインや、ガイドラインに準拠していることを確認できる校正ツールが組織のアウトプットに寄与することについては、あまり議論の余地はないでしょう。しかし、前述のとおりガイドライン策定の進捗がまちまちであった場合、校正ツールの利用開始時期もまちまちになるということになります。このような場合、一斉に利用方法をレクチャーするのは非効率なので、自発的に試して利用法を身につけてもらう仕掛けが必要です。
Kindaichi Check Toolは内部で textlint を使用しており、これは本来の使い方だと校正のルールをYAML形式で記述するものでした。技術検証の際はこれをフロントエンドのみで動かせる薄いツールとして開発し、各ルールの有効・無効を設定するとYAMLを生成するジェネレータを作り、生成したYAMLで校正を行うものとして見せていました。
一斉に利用方法をレクチャーする方針、かつ継続的なアップデートがないのであれば、このプロトタイプをリリースしても問題はあまり発生しなかったでしょう。しかし、ライティングスタイルガイドラインに自主的に参加でき、ライティングを大事にする文化が育つようにするためには、ルールの有効・無効が設定できるだけではデザインとして不十分であると考えました。
Kindaichiには主要な構成要素として、Inhouseとも共通するブランドごとに上書きできる仕組みと、ライティングスタイルガイドライン独自の「どういうことに対して何を言うか」から感情を抽出したTone of voiceがあります。ブランドとTone of voiceの二つの要素を候補の中から選択することで検証すべきルール群が適用されるようになると、文章としてのライティングスタイルガイドラインを読むだけでシームレスにツールを触ることができると考えました。
ブランド単位だと「管理ページのみこのルールを使いたい」などの要望があったので少々拡張して「コンテクスト」、Tone of voiceを「トーン」とそれぞれ名づけてトップレベルのオブジェクトにし、ツールで使用される用語の辞書を整備した上で、オブジェクト間の関係性を作図していきました。
この作図が完了してからワイヤーフレームへと落とし込み、UIデザインと実装が行われました。
実際に使われるまでとその後の運用活性化
Kindaichi Check Toolがリリースされた当初は物珍しさで利用するパートナーもいましたが、その後しばらく利用者が増えることはありませんでした。ツール含むKindaichiへの要望を受け付けるSlackチャンネルも、ほとんど稼働していない状況になっていました。
しかし先日、ある事業部で事業部全体のライティングスタイルガイドラインを議論する際、メンバーがKindaichi Check Toolの有用性に気づき、それ以降、積極的に要望を投稿してくれるようになったのです。そこからさまざまな機能がKindaichi Check Toolに追加されてきましたが、デザインは初期のものからほとんど変わらず、利用開始に負担がかからない仕組みは今も変わらず続いています。
例えばこのグラフはGoogle Analyticsで取得したコンテクストの選択状況ですが、2階建ての仕組みで作られた他ブランドがチェックでは積極的に使われており、デザインがよい効果をもたらしたと言うことができます。
ライティングスタイルガイドラインについての議論も以前より活発になりました。これまではライティングが得意な個人がその能力を活かすという点での活躍でしたが、事業部を横断して有志が集まった編集プロダクション方式実現の足がかりとなりました。今後は、全社でライティングスタイルガイドラインを育てていく流れも盛り上がることが期待できます。
社内ツールでも真剣にデザインに取り組んだ結果、ライティングの未来が開けたと言えるでしょう。
まとめ
使いたくなる社内ツールをデザインすることは、中長期的なメリットをもたらすツールを開発し、抽象的な課題を解決する際に有効です。社内横断部門はそのような抽象的な課題に取り組むことが多く、私が所属するデザイン部も社内横断部門の一つです。このような部門は少人数ゆえ、他の部門にも増してユーティリティプレイヤー的な働き方が求められます。そのような場所でこそ、デザインエンジニアが本領発揮できる機会があるのではないでしょうか。
明日の記事のご案内
明日 GMOペパボデザイナー Advent Calendar 2022 の14日目の記事は keita_kawamotoさん です！お楽しみに！