
2025.02.18
「売上をスケールする」AIの使い道とは アルペンが挑む、kintone×生成AIの接客データ活用法
リンクをコピー
記事をブックマーク
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:ありがとうございます。実際どうやっているのか、詳しく説明いただいてよくわかりました。説明と言っちゃダメですね、雑談ですね(笑)。雑談していただいて参考になりました(笑)。イチ視聴者のようになってしまったんですけれども、ありがとうございます。
(次回に続く)
関連タグ:
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
第20回エクゼクティブメンターイベント「今、「ひと」と組織が共創する〜働き方の未来へ」
2024.12.07 - 2024.12.07