見出し画像

もっともっと業務アプリのデザインをしたかったので、SmartHRに入社しました

drivesketch

こんにちは、drivesketchです。今年の2月に株式会社SmartHRに入社し、同社のプロダクトデザイナーになりました。

働きやすい環境と、挑みがいのある課題があり、毎日充実した日々を過ごしています。他にも私のような「情報設計が大好き」「業務用アプリケーションが大好き」という人がいたらぜひ来て欲しいので、入社の経緯と入社後の所感を書いていきます。

SmartHRに入る前

SmartHR入社前は、受託のデザイン会社に4年弱在籍し「インフォメーションアーキテクト」という情報設計だけを担当するポジションに就いていました。

ウェブサイトやアプリケーションを作る際に「全体としてどんなページがどんな階層構造で存在するか」「各ページにどんな要素があって、どんな操作をしたら何が起きるのか」を決める工程が主な担当領域です。

ロゴやバナーを作ったり、フォントや色の微細な調整をしたりすることはなかったので、IT業界で「デザイナー」と聞いて多くの方が想起する仕事とは割とずれがあるかもしれません。

仕事以外でも、ラグビーのうまいルール説明を考えたりオリンピック種目を分類したりと、遊びとしても情報設計をしていました。

基本的に、複雑に絡み合った情報の塊について「どう切り分け、どう名付け、どう並び替えたら分かりやすくなるか」を考えることに強い快感を覚える性質を持っているため、このインフォメーションアーキテクトという仕事を天職だと思って務めていました。

転職理由

業務用アプリケーションへの偏愛

SmartHRへ転職した最大の動機は、業務用アプリケーションのデザインに専念したいと思ったためです。

前職では大規模ウェブサイトと業務用アプリケーション(以下、業務アプリ)を多く担当していました。どちらもやりがいと面白みを感じていましたが、特に業務アプリの設計をする際の、複雑な業務フローを理解し、画面上のオブジェクトやアクション、ステータス、ユーザー権限などに整理していく…という過程が、情報設計ジャンキーである私としては楽しくて仕方なく、業務アプリを扱うプロジェクトを担当するたびに「面白い、もっとやりたい、これだけをやっていきたい」という思いが強くなっていったのでした。

どうすれば「業務アプリだけを担当するデザイナー」になれるのか。自然と「自社で業務アプリを開発・運用している会社に行く」という選択肢を意識するようになりました。

プロダクトデザインの専門部署

業務アプリの自社開発企業は他にもありますが、SmartHRに特に強く惹かれたのは、プロダクト(※1)をデザインする部署が、それ以外のサービスやコーポレート領域のデザインをする部署とは別に存在する点でした。

※1 アプリケーションソフトウェアとしてのSmartHRを指す

それまでの業務経験から、私は業務アプリのような「タスクを処理するツール」のデザインと、ウェブサイトやパンフレットのような「コンテンツを伝えるメディア」のデザインとでは、求められるスキルや頭の使い方がかなり異なるという感覚があったので、SmartHRの部署の分かれ方には深く首肯できましたし、自分の「業務アプリに専念したい」という動機とも一致していると感じました。

そこから興味を持って同社を調べていくうちに、プロダクトデザイナーの採用情報(※2) やメンバーの発信(※3)の内容から、「デザイナーがソフトウェアエンジニアリングの知見を持つこと」を重要視している様子が伺えたことも、私のデザインに対する思想との一致を強く感じ、ますます魅力的に映りました。

※2 応募資格の欄に「エンジニアリング領域への理解や関心」や「開発・実装経験」が記載されている
※3 「私はデザイナーでありエンジニアである」というnote記事上の記述「デザイナーは開発の一員」というTwitterでの発言があった

その後も、私はネットストーカーのように同社のプロダクトデザイナーの取材や連載を読み漁り、「思想が同じだ、この人たちは私の同志だ」「自分がこの人たちと一緒にいないのはおかしい、今すぐこの会社に行くべきだ」という思い込みを加速させます。最終的には、重いラブレターのような応募書類をしたためて、採用窓口に送りつけていました。

幸い、頭のおかしいストーカーと判定されることなく順調に選考が進みます。他社の選考も並行して受けていましたが、SmartHRから内定の連絡をもらった時点で(詳細な条件を聞く前に)他社の選考はすべて辞退していました。

実際に入社してみてどうか

さて、そんな経緯で入社してから、あっという間に半年が過ぎました。

先述のように、勝手に大きな期待を持って入社したわけですが、過大な期待にたがわず「そうそう、これがやりたかった! これが欲しかった!」と何度も感じています。

全部を挙げていくときりがないので、特にインパクトが大きかったものを2つ紹介します。

開発チームの一員としてのデザイナー

入社してすぐに開発チームのひとつに配属されました。PM、プロダクトエンジニア(複数人)、QAエンジニア、UXライター、プロダクトデザイナー(私)で構成されるチームで、プロダクトの開発をしています。この「開発チームの一員としてのデザイナー」という立場は、私にとって念願のものでした。

異なる職能を持つ全員が、仕様検討などの初期段階から開発に参画するため、認識のずれや考慮漏れによる手戻り、同じ議論の繰り返しなどが起きにくい環境になっています。

たとえば先日、ユーザーの操作とシステムの処理が複雑に絡み合う機能を開発した際は、操作と処理の流れのフローチャートのたたき台を私が作成し、チーム全員で様々な観点から議論しブラッシュアップしました。

実際に作成したフローチャート。ユーザーのどんな操作をトリガーに、クライアントサイドやサーバーサイドでどんな処理が行われ、ユーザーにどんなフィードバックが返ってくるのかが整理されている。
実際に作成したフローチャート。ユーザーのどんな操作をトリガーに、クライアントサイドやサーバーサイドでどんな処理が行われ、ユーザーにどんなフィードバックが返ってくるのかが整理されている。

このフローチャートが、画面構成、UI文言作成、フロントエンド/バックエンド実装、QA実施の共通の設計図となり、開発の途中で「あれ、こういうパターンのときはどうなるんだっけ?」と疑問が生じた際に立ち戻れるものとして役に立ちました。

ジェームズ・ダイソン氏が「デザインもエンジニアリングの一部であるべき」と発言していますが、今回のフローチャート作成からの一連の流れを通じて、私もこの言葉の意味を改めて実感しました。

改善を繰り返し進化するプロダクト

SmartHRには、ほぼ毎日 大小さまざまな機能改善や機能追加が行われています。私が開発に関わった機能も、入社から半年の間に複数回リリースされ、ユーザーの手元に届いています。

そのうち1回は、リリース後にユーザビリティテストを実施し、その結果をもとに別の追加機能を開発し、そちらも既にリリースされています。

ユーザビリティテストを通じて、自分たちが考えて作った機能が思っていたように使われないことを目の当たりにしたり、この機能では満たせないユーザーのニーズがあることを知ったときは少なからずショックを受けましたが、このショック自体が私にとっては新鮮な喜びでもありました。

というのは、前職時代は「納品」を最後にプロダクトとの関係が終了することが多く、自分たちの考えた画面構成や挙動が、実際にどれくらいユーザーの役に立っているのかを検証し、改善する機会をなかなか持てなかったからです。

「作って終わり」ではなく、継続的な改善に関わりたいというのも、私が自社開発の企業への転職を指向した理由の一つでした。この半年で「作って、使ってもらって、声を聞いて、改善する」という一連の流れを実際に体験したことで、「これを繰り返すことで、プロダクトをより良いものに近づけていける」と実感でき、この会社に来たのが正解だったと改めて確信できたのでした。

SmartHRのユーザビリティテストの取り組みについてはこちらの記事が詳しいです。

これからの目標

ということで、「業務アプリのデザインに専念したい」と思っていた私にとって、かなり理想的な環境を手に入れることができました。が、肝心の私自身はというと、スキルも知識も経験も理想には程遠く、業務ドメインやプロダクトの各機能、開発の基礎知識など、学びたいことが山積みになっています。

また、担当しているプロダクトの機能や体験を最高のものにしていくだけでなく、これまで培ってきた情報設計の経験や考え方を、プロダクト開発以外のシーンでも役立てて行きたいと考えています。

焦る気持ちを抑えて、一段ずつ階段を登っていくつもりで日々精進していく所存です。


あなたも仲間になりませんか?

SmartHRのプロダクトデザイングループでは、ともに完成のないプロダクトを作る仲間を募集しております。

応募の前にもっとプロダクトデザイナーについて知りたい場合は、カジュアル面談もぜひ。


この記事が参加している募集

入社エントリ

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
drivesketch
業務用アプリケーションのインターフェースデザイナー。好きなものは分類と説明と相撲とラグビー。