GMOペパボ株式会社・マネージャー研修(2022年9月27日)
今までちゃんと使ったことがなかったTikTokを最近がっつり触ったところ、UIやインタラクションの細かな作り込みに気づくことが多く、発見の連続でした。今後の機能開発やUIデザインの参考にもできそうなので記事にまとめます。 調査期間:2024/1/22 - 1/29 使用環境:iPhone 15、iOS17 1. アクションなしの没入体験TikTokで最も特徴的なのは動画フィードでのレコメンドの仕組みです。フルスクリーンで表示されるショート動画が上下のスワイプで切り替わり、視聴行動(視聴時間やスキップなど)に応じて次の動画がレコメンドされ続けます。そのため利用者はフォロー、いいね、コメントなどの主体的なアクションを一切しなくても、フィードをスクロールするだけで自分好みのコンテンツが表示され続けます。 動画フィードでは利用者の視聴行動に応じて動画が次々とおすすめされるTwitterやInsta
はじめに 本記事はNTTドコモ Advent Calendar 2023の7日目の記事です。 こんにちは。NTTドコモサービスイノベーション部2年目の杉山です。 業務ではAI技術等のビジネス適用をしております。 入社してから2年目になりますが、たった2年の間にも社内におけるデータ活用は広がりを見せております。 データにあまり詳しくない人でも簡単に使えるAutoMLツールの台頭もあり、モデリングやモデルから出力されるスコアの活用はより身近なものになってきていると感じています。 そうなってくると研究開発チームとしてはスコアの算出だけではなく、その先の意思決定部分も含めた技術開発をすることで更になる価値創出につながり、最近では数理最適化技術を勉強しております。 Pythonで数理最適化ができるライブラリはいくつかありますが、本記事ではその中でも3種類のライブラリを手元で動かしてみましたので、その
「めちゃくちゃ勉強してソフトウェア開発も、アジャイルな開発もできるようになってきた! ところがせっかくうまくできるようになったけど、顧客への貢献にはなかなか繋がらない…」こんな悩みををよく聞きます。 この10年間でスクラムなどのアジャイルに関する情報やノウハウは増え、社会的な理解も広がり、その結果アジャイルははじめやすく、習熟もしやすくなっています。開発チームは急速に学習し、能力が高められやすい状況にあります。 ところがプロダクト価値の観点から見ると、開発チームも社内の他部署も、そして顧客も不満を持っていることがあります。せっかくアジャイルな活動ができるようになっても、プロダクト価値に繋げるまでにいたっていないことが多々あります。 本セッションでは、プロダクトという観点からアジャイルを捉え直し、開発チームや社内の他部署、顧客も満足するためのお話をします。 プロダクトマネジメントなど過去の登
風音屋(@kazaneya_PR)の横山(@yuzutas0)です。先日「東京大学の特任研究員に就任した」というリリースを掲載したところ、各所からご連絡やご質問が寄せられました。データ分析を支援する風音屋にとって、今回の取り組みがどういう意味を持つのかご紹介できればと思います。 なお、この記事ではデータ分析を担う人材を総称してデータ分析者(データアナリスト)と呼ぶことにします。会社によってはデータサイエンティストやコンサルタントと呼ぶほうが適切な場合もあるでしょう。データを集計・加工・可視化するだけなら「分析」とは呼ばないといった意見もあるでしょう。各自で好きな名前に置き換えて読んでください。 データアナリストを取り巻く脅威便利なテクノロジーが日々台頭しており「他の人より少しだけBIツールに慣れている」「他部門のメンバーよりデータ集計に慣れている」というだけのジュニアなデータアナリストでは
意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す
Intro to making decisions On this page, we have outlined how we make decisions at GitLab. Making decisions GitLab’s values are the guiding principles for our business. They inform hiring, performance management, and promotion assessments. They also guide other decisions that we make. At times, values may be in conflict. To address this, GitLab has a values hierarchy. At the top of this hierarchy i
背景と目的 ビジネスにおいて機械学習による回帰モデルを構築する際に、単に「予測値(点予測)」が知りたいというよりも、「予測値が(どれくらいの確率で)どれくらいの範囲に収まりそうか(区間予測)」を知りたい場面があります。例えば天気予報を眺めてみると台風の進路予測には予報円が出ており、ある程度幅を持たせて進路を予測するといったことが行われています。あるいは需要予測を行う場合に「95%の確率で40個~60個の間に入りそうだ」という幅を持たせた予測をすることができれば、「売れ残りがでると損失が大きいので、明日の仕入れ量は40個にしよう」といった意思決定に繋げることができるかもしれません。 そこで、本記事ではテーブルデータの回帰タスクで広く利用されており皆様にとって馴染み深い勾配ブースティングアルゴリズムを用いて、「幅を持たせた予測」を実装する方法を紹介します。 各手法の概要 この区間予測を実装する
本連載では、プロダクト開発に携わるエンジニア読者向けに「成功につながるプロダクト開発」を実現するためのプロダクトマネジメントの基本の考え方や応用テクニックを、国内外の企業の優れたプロダクト開発の取組みを事例にとり、小城久美子さんがエンジニア向けに紹介・解説。明日からすぐに使える「いいプロダクト開発」をかなえるヒントを提供します。 小城久美子(@ozyozyo) ソフトウェアエンジニア出身のプロダクトマネジャー。ミクシィ、LINEでソフトウェアエンジニア、スクラムマスターとして従事したのち、『LINE CLOVA』や『LUUP』などにプロダクトマネージャーとして携わる。そこでの学びを活かし、Tably社にてプロダクトマネジメント研修の講師、登壇などを実施。書籍『プロダクトマネジメントのすべて』(翔泳社)共著者 「エンジニアのためのプロダクト開発」連載、前回はユーザーとの対話をするためにどのよ
「相談があるのだけど……」と知人友人から持ち掛けられて、親切心から「アドバイス」をしてあげた。 でも、全く相手に響かず、「なんで言うとおりにやらないの」と、逆に相手を責めてしまい、何の解決にもならなかった。 そんな経験のある人はいないでしょうか。 私は死ぬほどあります。 そんな失敗から、徐々に私は「人からの相談」について、考えを改めざるを得ませんでした。 実際、「アドバイスの欲しい人」は本当に少ないのです。 多くの人が求めているのは、「黙って話を聞いてくれる人」であって、あれこれと改善案を考えてくれる人ではありません。 しかも、もっと悪いことに親切心からの「改善策」「アドバイス」はむしろ、「なんでこんなこともやってないの?」という批判だと受け止める相談者も少なくありません。 「◯◯してください」や「◯◯すべきです」といった直接表現はまず、誤解されて伝わるのです。 そして、非難されている、と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く