開発の企画からリリースまでの流れ
futaba：現在みなさんがどんな体制でプロダクト開発をやっているか、今に至るまでどの様に体制が変遷してきたかというところはわかりましたが、実際にどうやって活動をしているのか、どうやって開発を一緒にやっているのかのがまだイメージが湧かないんですけれど、具体例を含めて教えてもらえたりしますか？
keroyama：ここからは私中心に話そうと思っています。
futaba：ありがとうございます！
keroyama：（スライドの）下に、開発の企画からリリースまでを具体的にどうやってやっているのかみたいなキャプチャをワーっと貼っています。今回は源泉徴収票機能の開発に沿いながらお話できればと思っています。
まず一言で言っちゃうと、設計からリリースまで本当に開発チームの中でみんなで協力して進めているよね……みんな？ って思っているんですけど（笑）。
futaba：そうですよね（笑）。
miyashita：確認（笑）。
keroyama：本当にチーム一丸となってやっている感じです。
源泉徴収機能の改善の例
keroyama：今回は源泉徴収機能の改善を取り上げてお話したいと思っているんですけど。kissyさん、これはどんな開発だったかを簡単に紹介してもらってもいいですか？
kissy：これは2021年の11月ぐらいにcokeチームでやったプロダクトの開発です。源泉徴収票機能がどういう機能かを簡単に話すと、SmartHRに源泉徴収票のデータを取り込んで、それを従業員に配布する機能です。
昔に作られて以降、大きな改善はされておらず、エンタープライズのような従業員の多い企業だと、ちょっと使いづらいところがあったんです。源泉徴収票データを取り込んであとから修正しようと思うと、全従業員分のデータを直さないといけなく、個別に修正ができないであったり。
そこで「源泉徴収票がよく使われる時期に合わせてプロダクトを改善して、お客さまに価値を提供しよう」と。
keroyama：2021年11月ですね。まだ半年も経っていない。すごく昔のことのように感じますね。
kissy：そうなんですよ。意外と最近の話です。
keroyama：最近ですね。（スライドの）その下に、みんなでどういうことをやっていったかを貼っています。企画の段階で、ドメインエキスパートとか、社内の実ユーザーに近い人たちに「こういう設計で今ある課題って本当に解決できそう？」みたいなのをヒアリングしました。これはkissyさんが中心にやってくださった感じですよね。
kissy：そうですね。「だいたいこういう点を解決したい」みたいなものはもうすでに見えていたので、ざっくり「こうあるとよさそう」みたいなところは、僕とその時にcokeチームにいたエンジニアとの数人でざっくり考えました。ドメインエキスパートや実際に社内労務に関わっているメンバーに「こんな感じはどうでしょう？」みたいなところをヒアリングしに行った感じでしたね。
keroyama：ここで「概ね方針はよさそう」みたいなことを実ユーザーに近い人たちに確認できたのはけっこう安心感があったなと私は記憶しています。
デザインツールとしてはfigmaを使っているんですが、「こういう仕様、こういう方向でよさそうだね」となったら、wentzさんを中心に、今ある画面をペタペタペタっと貼り付けていって、「ここをもっとこうしたほうがいいよね」「この画面はいらなくない？」とか、そういう話をメモして議論していくことをやりました。
実装の話も、このデザイン段階でエンジニアを絡めてやりましたよね。
wentz：もともとなかった機能ですが、「ここにこのコンポーネントを入れよう」と思った時に、どういう挙動がいいのか、ほかのプロダクトのページだとどのように実装しているのかとか。そのあたりを、具体的な実装やコードを見ながら振る舞いを確認したり。
文言ひとつ取っても、「どういう文言が一番伝わりやすいんだろう」というところはUXライターが考えるのではなくて、チームメンバー全員で知恵を絞って考えるっていう動きがあってすごくよかったなと思ったことを覚えています。
keroyama：そうですよね。文言だけを考えても、結局どう表示されるのかとか、どういう時に表示されるのかを見ながらじゃないとわからないですよね。文言だけで考えちゃうと周りのコンテキストとかを踏まえられないので、やはりデザインツール上でみんなでワイワイやるのはめっちゃいいですよね。
miyashita：この時はデザイン的な選択肢を何パターンか案を出してもらって、エンジニアの方がコードを見て「これだと意外と実装コストがかかるかもしれないから、ちょっと厳しいかも」みたいな話をしながら。最短でいい感じの道筋を決められた気がして、やり取りとしてはすごくよかったなという記憶があります。
kissy：昔の開発のやり方だと、細かいところまでPdMが考えていた時期もあって。そうじゃなくて、ざっくりやりたいところからチームでfigmaを使いつつワイワイできたことによって、手戻りだったりがすごく少なくなっている印象はあります。
keroyama：こういう進め方がもう定着している感がありますよね。デザインモックを作ってもらってみたいな。
リリースする前のユーザビリティテスト
keroyama：じゃあ次にいってみますか。デザインを固めて、実際に実装をやって、リリースする前にユーザビリティテストをやりましたという紹介です。
このあたりはwentzさんが中心になっています。ユーザビリティ推進室というものがあって、社内のいろいろな機能のユーザビリティテストをデザイナーの方が中心となってセッティングをして、「実際に社内のユーザーに近い人に触ってもらってフィードバックをもらおう」みたいな取り組みが、最近けっこう盛んに行われていますね。
（スライドを示して）この社内の実ユーザーに近い人をまとめたドキュメントって、もともとはkissyさんが作ってくれたんでしたっけ？
kissy：そうですね。人事・社内労務の人たちと一緒に作りました。SmartHRは社内に実ユーザーがいるのがとてもありがたくて。実際にプロダクトを作ってリリースする前に実ユーザーの人たちに使ってもらえたり、声を聞けるというのはすごくありがたい環境です。
ただ、いろいろな機能が増えて「実際に使っている人が誰だかよくわからん」となるくらいの組織規模になってきているので、「社内のSmartHRユーザーを探せ‼」みたいなドキュメントを作って、どんな人が実際に使っているのかを一覧化したものです。
keroyama：これ、けっこうみんな見ていますよね。スターの付き方を見るとわかりますが、みんなこれを見て実ユーザーを探している感がするなあと思っています。
wentz：めっちゃお世話になっています。
keroyama：（ユーザビリティテストの結果に戻って）ぴえんの顔が付いているところもあるんですけど（笑）。細かいところではやはり「ここはちょっとこうだったね」とかはありましたが、概ねシナリオはみんな最後までいけたという結果が得られた感じでした。
リリースチケット消費時の取り組み
keroyama：（スライドを示して）最後に貼ったものがややわかりにくいんですが、リリースのチケットです。これは出していいのかみたいなものを出してしまったんですが、大丈夫です（笑）。リリースする時に何をやるのかの最終確認のチケットを貼ってみました。
一番下のほうに、このチケットでやるサブタスクを切っています。「この時はヘルプにどういう修正がいるか」を、私を中心に「このページで修正が必要だよね」みたいなタスクを詳細化して貼っています。
私がやや多忙になっていた時期というのもあり、私が全部修正するわけではなく、シュッと修正できそうなやつはほかのPdMだったりエンジニアのみなさんに分担してレクチャーしながら修正してもらうみたいなこともできて。クロスファンクショナル感があって個人的にはすごくよかったと思っています。
お知らせの作成とかヘルプの作成みたいな、リリースの本当に最後にあることも、開発チームのみんなでできている感があるなと思いますね。
kissy：前まではUXライターチームに「ヘルプの修正をお願いします」と言うチャネルがありましたよね。
keroyama：ありました！
kissy：Slackのワークフロー機能でUXライターチームに「ヘルプの修正をお願いします」と依頼をして直してもらうみたいな。関わりがやや遠いような関係性でしたよね。
keroyama：そうだった。あれは今は動くことはほぼ（ない）……。開発チームからの依頼は、UXライターが入っているチームの場合はなくて。やり方はこの1年でぜんぜん変わった感じがありますね。
という感じで、けっこうワーっと話してしまいましたが、本当に企画の段階からリリースまでをみんなでやっている感じです。gennyさん、どうですか？ 何かありますか？（笑）。
genny：もうお話されたとおりで。SmartHRは労務系の難しい機能とかも扱っていて、ヘルプをどこに置くかもやはり機能の一部なので。そのあたりを最初の頃から一緒にみんなで考えてできているのはいいかなあと思います。
keroyama：ありがとうございます。「どうやって開発をしているの？」というトークテーマはこんな感じでした！
futaba：ありがとうございます。実際どうやっているのか、詳しく説明いただいてよくわかりました。説明と言っちゃダメですね、雑談ですね（笑）。雑談していただいて参考になりました（笑）。イチ視聴者のようになってしまったんですけれども、ありがとうございます。
（次回に続く）
