こんにちは、プロダクトデザイナーの @uknmr です。昨日に続き SmartHR UI に関する話を書きます。ええ、そう。今日はやや社内に向けて書きます。アドベントカレンダー14日目? 知らない子ですね。我が家にクリスマスの概念はないので、そんなものはありません。
SmartHR UI の目的とは?
ブランド観点から UI を揃えたい、一貫したユーザー体験*1を提供したい、という気持ちから生まれた SmartHR UI ですが、本当ですか? 我々は本当に UI を揃えるためだけにコンポーネント集を手入れしていますか? 共通コンポーネント集があれば、それを使い続けさえすれば UI が揃っていくのは必然です。「揃えたい」という気持ちは「誕生した瞬間に達成された」とも言えます*2。
では、何のために自前でコンポーネント集を手入れし続けているのでしょうか? 私はそれを「SmartHR というプロダクトの開発を最速で進めるため」だと考えています。
SmartHR UI は OSS として公開されている社内プロダクトです。開発が始まって4年以上が経ちましたが、依然として有志による兼任での開発を続けています。プロダクトエンジニアやプロダクトデザイナーの多くは「社会の非合理をハックする*3」というミッションのもとに集い、「SmartHR というサービスを大きくしていくことが日本の社会を豊かにしていく」と信じているはずです。その大志に向かい、早くリリースし早く検証し、また早くリリースし、と利用者に価値を届けるまでの時間と距離を短くすることが我々開発者の使命ではないでしょうか。目の前の仕事に集中していると見失いがちですが、決してスクラムや一緒に働く人のため、評価や目標のために働いているわけではないですよね。
SmartHR UI は SmartHR というプロダクトを最速で作る*4ために特化されたコンポーネント集です。そして SmartHR の成長・拡大と共に、グループ会社*5やサードパーティ*6のプロダクト開発をより加速させ、SmartHR グループ全体の価値をより高める可能性を持つ、夢のあるコンポーネント集であるとも言えます。
有志による兼任での開発を続ける理由
エコシステムの話に行く前に、SmartHR UI の大事な開発姿勢を紹介します。それを端的に言えば「必要なものを必要なだけ作る」です。SmartHR を最速で作るためのプロダクトである SmartHR UI ですが、作るコンポーネントが元々決まっていたわけではありません。複数プロダクトの共通項を実装するところから始まりましたが*7、その後は各プロダクトで生まれた課題を元に手を入れ続けています。コンポーネント集に大層な思想や綺麗な設計は必要ではないのかもしれません。隅々まで思想が行き届いた設計は美しく見栄えもいいでしょう。でもそれが実際に開発で使われるかどうかはまた別の問題です。使われるものを作るためにも、SmartHR UI は必要なものを必要なだけ作り、素早くリリースしている、と言えます。
SmartHR UIの開発に参加している有志は各々担当プロダクトを持ち、普段はそのプロダクト開発に従事しています。定例は週に1時間という限られた時間の中で、共有や相談・振り返りやリファインメントを行っています。これは各々が異なるプロダクトで SmartHR UI を使った開発を行っているからこそできる方法です。短い時間で責任をもって意思決定するには、合議ではなく建設的な対話をする必要があります。SmartHR というプロダクトをつくるためのプロダクトであるため、何をどんな場面でどう使い、何が課題なのか、またどうあるべきなのか話せる必要があります。実際に現場で使うための話ができなければ、いくら綺麗な設計をしようと意味がありません。
また、現場で生まれた課題に取り組んでいるからこそ、その課題感を感じている張本人が速度を保ったまま開発できます。もし SmartHR UI 開発チームが実プロダクトを担送しない専任であったなら、課題感を伝えるだけで労力と時間を失うでしょう。
もちろん兼任のデメリットも多くあります。しかし兼任だからこそ生まれる速さと強さが SmartHR UI の開発にはあります。記事の後半では、その理想像に頭を巡らせようと思います。
何がエコシステムなのか?
SmartHR の開発（デザインを含む）には「SmartHR UI を中心としたエコシステム」が存在すると私は考えています。それは SmartHR UI と SmartHR Design System、そして各プロダクト*8が相互に関係し合い構成されるエコシステムです。
まず開発者は SmartHR というプロダクトを通して利用者に価値を届けます。そのプロダクトは必ず SmartHR UI を使用して構築されています。また、デザインシステムやスマパタ*9などプロダクトを横断してより生産性や質を高めていく環境が整っています。
すべてのプロダクトで同じコンポーネントが使われているため、プロダクトで発生したコンポーネントに対する課題は良い点も悪い点も含め、他プロダクトでも発生する可能性があります。その課題を1つのプロダクトに閉じて解決することは容易いでしょう。しかし、SmartHR UI を用いて解決することによって、自プロダクトはもちろん数十の他プロダクト、さらにはグループ会社やサードパーティのプロダクトに伝搬していく可能性があります。
使用されるのはプロダクトだけではなく、デザインシステムやスマパタでも同じです。デザインシステムにドキュメントを書く中で問題が見つかることもあれば、スマパタを書く中で見つかるコンポーネントもあります。
こうして使用されればされるほど、SmartHR UI がフィードバックを受ける機会はより増え、そのフィードバックを活かし続けることによって、より質の高いコンポーネントライブラリとして進化していきます。
これが私が考える SmartHR UI を中心としたエコシステムです。コンポーネントライブラリに対するたった1行の変更が、巡り巡って日本の社会を支えるかもしれないなんて、わくわくしませんか。
これが実現できるのも、SmartHR のエンジニアやデザイナーといった開発者が SmartHR UI を使い続けてくれるからに他なりません。このエコシステムは「開発者」が「使うこと」から回り始めます。つまり、このエコシステムへの「貢献」の第一歩は「使うこと」なのです。
バグも多く、とても堅牢とは言えない開発体制ですが、SmartHR というプロダクトをよりよいものにしたい一心で、また少しでも開発者が楽をしてプロダクト開発に取り組めるよう、我々は SmartHR UI の開発を続けています。引き続き使い続けて、たくさんの反応をください!
SmartHR UI との理想の関わり方
使ってるだけで貢献できている、とはいえ、もう少し開発が活発になるといいな、という欲はあるので、いくつかの貢献パターンを書き連ねてお終いにしようと思います。
パターン1： 腕力任せ
SmartHR UI は OSS です。内部的な意思決定以外の情報は基本的に開示されています。プロダクトで使う特定のライブラリを使う際に、その実装まで見に行き、ある程度理解した上で採用するかどうか判断しますよね。
社内で運用されている OSS だからといって実装を見ないことはあるのかもしれません。ただ、社内にあるのでそのコミットハードルは一般的な OSS に比べたら低いのは間違いないでしょう。各プロダクトと技術スタックは変わっていません。コミット先が自プロダクトか、そうではないか程度の違いです。SmartHR UI にコミットすることは、自プロダクトだけでなく他プロダクトも良くする可能性があります。コミットしない理由はありません。
パターン2： 新しく機能を作るときにフィードバック
コンポーネントライブラリが一番活きるのは、新しい機能や新しい UI を生み出す時だと考えます。既存の UI やパターンでまかなえるかどうか? を考える時、コンポーネントライブラリに対する多くのフィードバックがあるはずです。
その宝の山を自プロダクト内の課題に閉じてしまうかどうかは作業者にかかっています。「新規プロダクト開発は誰にでもできる」とよく言われますが、それは「誰にでもできる新規プロダクト開発をしている」からなのではと思います。自プロダクトの開発速度を落とさず、他プロダクトにも影響を与える開発は誰にでもできるわけではありません。コードにコミットできるエンジニアだからこそ為せる技なのかもしれません。
フィードバックをしやすいような工夫はいくらでも出来ます。例えば、SmartHR の各プロダクトには SmartHR UI の使用を管理するために ui/index.ts ファイルを設けていることがよくあります。
export { ActionDialog, AppNavi, Balloon, Base, .. 省略 .. } from ‘smarthr-ui’
ここに SmartHR UI に反映した修正を差し込むことで、プロダクト開発上は SmartHR UI を使ってる状態を保ちつつ、いつでも SmartHR UI への出荷を狙えるようになります。
import { Base as shrBase } from ‘smarthr-ui’ // 軽微な形であれば、同ファイル内でやってもよさそう export const Base = styled(shrBase)`` export { ActionDialog, .. 省略 .. } from ‘smarthr-ui’ // TODO: SmartHR UI に反映する export { HogeButton as Button } from ‘./HogeButton’
また、新しい機能開発がなかったとしても、既存 UI を Storybook に抽象化する作業であったり、スマパタのためにパターンを抽出する作業であったり、そういった何らかの形で UI と改めて向き合う時にもフィードバックの種は転がっているように思います。それを踏み潰しなかったことにするか、送り届けて日本の未来に届けるか（極端）は一人ひとりの意識にかかっています。
パターン3： すべてはスクラム
パターン1も2も結局は個人の裁量に依ってしまいます。幸いなことに SmartHR ではほぼ全プロダクトチームにスクラムが敷かれていますし、全チームにフロントエンドエンジニアが居ます。この仕組みを使わない手はないように思います。
SmartHR UI はプロダクトで使うものだから、その課題を SmartHR UI のものとするのではなく、課題が発生したプロダクトのもの、と考える方法です。
あぁ、特定のプロダクトで発生した課題をスクラムで解決したら他プロダクトも良くなっちゃうなんて、なんて素敵なんだ!
パターン4： 専任
兼任による開発の良さを間違いなく感じてはいますが、決してそれに固執しているわけではありません。専任を立てた方が SmartHR 全体の価値が上がるのであればそうすべきです。
どうしてもプロダクトと兼任ができない、私一人に集中してやらせてくれたらもっとよくなるのに! もしそんな人が居るなら手を挙げてやっていってほしいな、と思います。まだまだ SmartHR は実力主義が活きる組織だと信じています。
おわりに
改めて SmartHR における SmartHR UI の存在に頭を巡らせてみました。歴史に残るプロダクトをつくりたい? 歴史に残るプロダクトを支えるプロダクトとしての SmartHR UI も引き続きやっていきましょう!
GitHub でも Jira でも Slack でも、どんなチャネルでも開発者であるみなさんの声をチーム一同お待ちしております。
*1:一貫した UI はありえますが、環境も利用者も違う “体験” が一貫するはずはありません
*2:使い続けているからこそ、ですね
*3:旧ミッション。今年から「well-working 労働にまつわる社会課題をなくし、誰もがその人らしく働ける社会をつくる。」という新しいミッションを追いかけています
*4:ただ作って機能表を埋めることに価値はないので、質が高いことは大前提です
*5:Nstock や AIRVISA は SmartHR UI を使用しています
*6:SmartHR Plus β 版という SmartHR と連携するアプリケーションを紹介するアプリストアがあります
*7:初めから居たわけではないので憶測半分です
*8:SmartHR は内部的に複数のプロダクトで構成されています
*9:スマパタとは SmartHR Patterns の略で、プロダクトに頻出する UI の実装パターンを実コードと共に集めて展開し、プロダクトに再反映することで UI の質を高めていく取り組みです。コードと Storybook が公開されています。
