ワンキャリアクラウド

学生の本音をもとに、採用活動を。

Goodpatchは、ワンキャリアクラウドの全体を支えるデザインの基盤となる部分と、同シリーズ第一号「ワンキャリアクラウド採用計画」アプリケーションのユーザーインターフェイスのデザインを行いました。私たちは「UIデザイン」だとか「Webデザイン」という狭い視野でこれを捉えるのではなく、もっと広く「ソフトウェアデザイン」というものの見方で、ワンキャリアクラウドの構造から表層に至る部分のデザインを行いました。そこで私たちがもっとも強く意識した設計思想の一つが「拡張性」の考え方です。

「拡張性」という言葉は様々に捉えることができます。入れ物の中に何か物を追加して量を増やすこと、入れ物自体の容量を拡張し可載量を増やすこと、入れ物の数を増やし全体量も増やすこと、そもそも入れ物がなくても成り立つ仕組みを再設計すること—。

私たちは、ワンキャリアクラウドの情報構造の在り方やUIの表現、インタラクションの仕組みなど、様々なレイヤーにおいてこの「拡張性」を意識しながらデザインと向き合ってきました。特にUIのアーキテクチャとなる部分の設計（プロダクトの基盤となる部分）においては、そのときの構造設計が今後このSaaSプロダクトがどのように拡張し成長していけるのかを決める重要な基本構造にもなり得たため、先のロードマップを見据えながら整合性の取れる構造というものを考えてゆきました。

UIの表現においては、まずはどのような情報構造があるのかを前提としながら表現の最適なパターンを探ってゆきました。具体的なUIの設計の前に「概念モデル」と呼ばれる情報構造を表すモデルを作成し、UIに現れるであろう情報を一通り抽出しておき、そこで明らかになるオブジェクト同士の関連性から検討できるUIのパターンを当てはめてゆくアプローチを取りました。

例えば情報が一覧で並ぶような表現を検討する場合には、概念モデル上でそのオブジェクトが複数存在し得るのかを検討し、確実に複数個あり得ると判断した場合にはそれがリストなのか、アウトラインなのか、グリッドなのか、カルーセルなのか、メニューなのかといったUIパターンの検討を行いました。モデル上で0個があり得るならばUIとしても「空表示」が必要ですし、絶対に単数個と言い切れるならばいわゆる「詳細画面」として組み立てれば良いのです。

ここでUIの拡張性を検討してみると、現時点では存在し得るオブジェクトの数は1個で十分だったとしても、ロードマップを描いた際にオブジェクトが複数個存在していた方が拡張性を確保しやすいと考えられる場合には、概念モデル上では初めから複数個のオブジェクトを受け入れられる設計にしておき、表現においては一旦その数を絞るというアプローチが取れます。こうすることで、概念図やDBの設計では初めから複数個が受け入れられる、実際のバージョン1のUIでは1個のオブジェクトしか扱えないが、将来のバージョン2ではUIの改修のみで複数個のオブジェクトを扱えるようにする。そのような具合です。

ワンキャリアクラウドはプロジェクト発足当初からWebベースのSaaS、かつGUIアプリケーションの性質を持つであろうことが明確でした。GUIアプリケーションとは私たちが普段MacやWindows PCで使うようなアプリケーションのことを指しますが、ネイティブであるかをあえて考慮しなければ、例えブラウザを経由したインターフェイスを持っていたとしてもそれが「ツール」としてのUIを備えているならば、これはGUIアプリケーションであると言うことができます。すなわち、ワンキャリアクラウドとはWebサイトではなくWebアプリケーションなのです。

そこでワンキャリアクラウドのデザインにあたっては、私たちはWebサイトのセオリーよりもGUIアプリケーションのセオリーを適用してゆくことを強く意識しました。

例えば自社の採用計画の組み立てを行うUIでは、まず全体のレイアウトをヘッダーとコンテンツ領域に二分し、コンテンツ領域をさらに3ペイン構造のスプリットビュー形式として骨格を構築しました。この構造はMacアプリケーションでよく見かけるようなマルチペイン型のインターフェイスになります。まずサイドバーが左側のペインにあり、その詳細情報が右側のペインに展開されるMaster-Detailパターンを意識した表現です。

このようなUIでは、Webサイトの設計パターンとしてよく検討される「フッター」などの要素はあえて除外しています。実装上はHTMLページではありますが、概念的にはWebページではなくアプリケーションの「ビュー」であることを意識しているのです。

UIコントロールに着目してみると、これらにもデスクトップインターフェイスで見られるようなGUI表現や挙動が盛り込まれています。PCのユーザーが普段触れるであろうUIと違和感がないように、GUIの原理原則になるべく忠実になるようデザインしています。例えば「メニュー」のデザインは、クリックして展開する様子から、各項目をマウスカーソルでポインティングする際の挙動、そしてメニューの閉じ方まで、それぞれに細かな調整を加えています。アクセシビリティの考慮も行っており、Tabキーやカーソルキーでフォーカスが廻り、Return / Enterキーによって選択・実行できるよう実装しています。

このような細部のインタラクションにまでこだわり、｢GUIとして正しく振る舞うこと」を大前提としています。そして「ユーザーが普段どおりに、自然に、普通に扱えること」を目指しつつも、ワンキャリアクラウド独自のインタラクションもこだわり抜いています。

この設計思想は決して「ワンキャリアクラウドだからこそ」とは限りませんが、プロダクトの価値を高めるためには、まずアプリケーションとしての基本の部分は妥協せず当たり前品質というものを目指し、そしてユーザーが違和感なくそのプロダクトと向き合える環境をデザインすることが大切であろうと考えました。

私たちはこのような設計思想を「守破離」の精神に当てはめてデザインの基本方針としています。詳しくは次の記事もご覧ください。

UIデザインと守破離の精神

モードレスネスとは、UIデザインの文脈では「モードを生じさせないインターフェイス」に関する思想です。一般論として、UIにモードが生じるとそのユーザビリティが低下する傾向にあります。UIデザインではこの「モード」と呼ばれるものをうまく捉え、適切に機能させる設計が求められます。

ワンキャリアクラウドのインターフェイスデザインにおいても、基本的にはモードレスなインタラクションを指向しつつ、時にはモーダルなインターフェイスを取り入れ、うまく調和が取れるようなUIに仕立て上げています。

ユースケース中心設計とは、デザインプロセスにおいて今回特に重視した設計論を指しています。ユーザーの執り得る“可能性のある”行動をモデル化し、詳細機能やインタラクションと紐付けながらその全体像を「ユースケース」と呼ぶ単位で分類しました。ふつうユースケースと言うとUMLのユースケース図のようなイメージがもたれますが、今回用いた手法では少し違ったアプローチをとっています。

UMLのユースケース図では「アクター（ユーザーのような単位）」と呼ばれる者が「何をするのか」を記述してゆきます。このようなモデルを描くと自ずとデザイナーの思考も「〜すること＝機能」の発想に傾いてゆき、いつからかタスクや機能起点のモーダルなインターフェイスを作る頭に凝り固まってしまいがちです。私たちはこれを避けるべく、ユースケースの捉え方とそのモデリングの手法に独自のアレンジを加え、なるべくデザイナーがモードレスな発想でいられるようなアプローチを取りました。こうすることで私たちは最初に「機能一覧」と呼ばれるようなタスク起点の発想にいくのではなく、「ユーザー」が「何」を「どうする」のか、の形式で構造化したシナリオに具体的なインタラクションと機能を当てはめていって、適切なモードもデザインできる余地を残そうとしました。

モードレスネス＋ユースケース中心設計では、機能とインタラクションをユースケース単位で捉えられるので、ユーザーストーリーに基づいた機能開発がしやすいですし、要件定義としても実装のやる・やらを判断しやすいといった副次的なメリットもありました。

ビジュアルデザインにおいては、ソフトウェアの拡張性ももちろんですが、実際に利用するであろうユーザーの環境を考慮した工夫を入れています。

ワンキャリアクラウドを利用するターゲットは主に企業の人事の方々です。私たちのようなソフトウェアのデザイナーやエンジニアと比較すると、おそらくデジタルツールというものには馴染みがない場合もあり得ます。また、私たちはMacを使ってデザインや開発を行いますが、彼らはWindowsを使って仕事をしている可能性が考えられますから、ターゲットとなるユーザーが使いそうなPC環境で表示具合の確認をしながらデザインを行いました。特にディスプレイに関しては発色の良いRetina DisplayのMacに合わせるのではなく、考えられる一般的なWindows PCのサイズ、解像度、発色等を前提とし、ビジュアルの細部まで調整していきました。

表示に用いるタイプフェイスの選定では、macOS, Windowsどちらでも同じように描画できるNoto Sans JPならびにRobotoを採用しています。

また、私たちグッドパッチの手からプロダクトが離れていったとしても、そのデザインが適切に運用され拡張が行えるように、Sketchをベースとしたデザインシステムをご提案いたしました。アウトプットをプロダクトだけに留めず、クライアントがビジネスを成長させてゆくためには私たちは何ができるのかを考え、デザインパートナーとして取り組んだ事例です。

ワンキャリアクラウドは、新規事業としてスタートしたため、ユーザーの反応を見ながら今後の方向性を考えていく必要がありました。限られたリソースの中で「その機能はユーザーにとって価値があるのか？」や「技術的に実現できるのか？」といった不確実性に向き合うために、フェーズを切り取って進めていくアジャイル開発のプロセスを採用しています。

変化に対応するための開発プロセス

ワンキャリアクラウドを開発するにあたり、「スクラム」という手法をベースとしたアジャイル開発プロセスを取り入れ、2週間ごとに機能の優先順位の検討、実装、レビューを反復的に繰り返していきました。

ソフトウェア開発では、開発の過程で新たな問題が見つかったり、外部からのフィードバックによってタスクの優先順位が変わることがありますが、2週間のタイムボックスを区切ることで優先順位の変更に合わせて、柔軟に開発を進められるように開発プロセスを設計しました。

１つのチームになる

開発の過程では、グッドパッチのメンバーとワンキャリアのメンバーが毎日SlackやZoomを使ってコミュニケーションをとったり、2週間ごとに開発のプランニングや振り返りを行うことでプロジェクトの問題を素早く共有・対応できるようにしました。
受発注関係ではなくパートナーとして、開発に関わるメンバー全員が１つのチームになれるようにコミュニケーションフローを設計することで、スピーディにプロジェクトを進めていくことができました。

実装観点を取り入れる

将来的な拡張性を持たせるために、デザイナーとエンジニアがお互いの観点を取り入れながらUI設計を行っていきました。
たとえば、情報量が増えてもレイアウトが崩れないようなUIの設計・配置を行ったり、再利用性を高めるためにタイポグラフィや色について適切な名前を一緒に考え、デザインを実装に落とし込む際に同じ思想で作れるような工夫を行いました。また、短期と中期でUIのロードマップを提示してMVPを作成することで開発効率を高めるなどの工夫も行いました。

ライブデザイン

デザイナーがデザインファイルをエンジニアに渡したあとの手戻りは、認識のずれから起こるものです。そこで私たちは、同じ画面を見ながらその場で一緒にデザインする「ライブデザイン」という仕組みを作りました。１つの画面をデザイナーとエンジニアで共有することでデザイナーがアイデアを考えたらエンジニアにすぐに共有できたり、エンジニアが実装したらデザイナーにすぐに確認してもらうといったことができるようになりました。これにより、メンバー間で高い相互認識と即座な意思決定が同時にできるようになりました。

Goodpatchは常に、クライアントのデザインパートナーとして、私たちの手から離れてからもプロダクトを運用していくための思想や文化を残すことをひとつのゴールにしています。ワンキャリアクラウドにおいても、デザインシステムやアジャイル開発の提案など、プロジェクトの過程までをデザインしています。

ワンキャリア代表取締役 宮下さんは、プロジェクトをこのように振り返ってくださいました。

サービスを作ることに留まらず、概念モデル図や共通言語を作るワーク、スクラム開発の提案など、プロセスの選択肢をたくさん教えてもらいました。Goodpatchの皆さんとの取り組みが終わった後も、会社にポジティブに働くものばかりでした。一過性のパートナーシップというより、会社の資産、アセットになるものを残してもらえたことは大きな価値だったと思います。

Credit

ディレクター：関矢
UXデザイナー：神
ソフトウェアデザイナー／UIデザイナー：丸
UIデザイナー：榎本
Webフロントエンドエンジニア：大角
Webフロントエンドエンジニア：乗田