Agile Coach/Attractor Inc/翻訳者/Scrum Alliance Certified Scrum Trainer(CST)/Certified Team Coach(CTC)/チームトポロジー/プロダクトマネジメント/レガシーコードからの脱却/SCRUM BOOT CAMP他多数/将棋アマ四段

Joined July 2008
806 Photos and videos
Pinned Tweet
新刊のお知らせです。『Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方』という本が3/4に発売になります。 プロダクトマネジメントの重要な要素の1つであるステークホルダーとの関係性に焦点を当てた本です。生々しくて楽しいはず! ryuzee.com/contents/blog/146…
41
191
38,476
モラルが低い人がいるからダークパターンが発生するんじゃなくて、モラルに反する行為を合理化しやすい評価システムとか組織構造があるからダークパターンが発生するんや。ダークパターンがよくないなんてみんな知ってて、それでも自分たちは仕方ない(例外)ってダブスタ化しちゃうw
9
35
1,864
prawnとttfunk のバージョンのせいで1時間溶かした
831
UIに関して「気づかなかったほうが悪いのではなく、気づけないようなUIを作ったほうが100%悪い」と考えて大丈夫だよ。法令に違反していないなんて大前提で、それでもグレーゾーンを攻めるモラルのなさが糞ってことです
1
18
130
12,212
生成AIがあってもプロダクトオーナーのしごとは大変だし、片手間にできるようなもんじゃないと思いますだ
11
72
6,997
どれだけキラキラアピールしたり、登壇とかテックブログでイケてる感出したところで、ダークパターンが止められない時点でそういう価値観の組織なんだなーという感想になるね
1
34
181
23,074
「ロードマップは戦略、リリース計画は戦術」という表現はいいかもねー
6
32
3,264
- 生成AIでスクラムイベントを早く終わらせることに意味はない。目的は共通理解 - 生成AIでPBI等を大量生成すると偽の合意を誘発する - 生成AIは増幅器なので、良いコラボレーションができていれば役に立つが、対話不足や形式主義があるならそれを悪化させる - 生成AIで新しい価値を可能にするかを問う
1
19
89
8,366
スクラムイベントや活動は、人間同士の理解、判断、協働のためにある。生成AIは補助役にはなれるが、チームの対話そのものを置き換えてはいけない。 元記事はここ agilepainrelief.com/blog/gen…
1
12
1,712
AIで人減らしが進んでるけど、人減らしの意思決定をする人は、自分も削減の対象になる覚悟を持ってやれや
6
49
4,363
昨晩のWindows Updateで起動後すぐにDRIVER_POWER_STATE_FAILURE が毎回出て文鎮化してしまった。どうすんねん
2
1
1
4,619
直ったっぽいので様子見
1
2,123
だめぽ。chkdsk C: /R をしろと
1
1
1,666
残り2時間25分か。デフラグみたいに楽しい感じで表示してくれればずっと見てるけど、CUIなので放置
2
718
これは真理だ!
こんにちは。 デザイナーとして、大企業からスタートアップまで、かなり使われているプロダクトをデザインしていると自負しているのですが、多くの皆さんがAIでVibe Codingしただけで、使われるプロダクトを生み出せると思っていることに疲れたので、この投稿を書いてみます。 この投稿を読んですぐに取り入れられるくらい長く書くつもりです。長い文章が嫌いなら、とりあえずブックマークだけして後で読んでください。 1. 新しいプロダクトを考える時は、自分の好きなツールで考えるようにしてください。 AIは便利ですが、文章だけで考える必要はないです。考えが進むなら紙でも石でもレゴブロックでも良いです。 2. これから何のゲームをプレイしようとしているのかを理解してください。 どうすれば勝ちなのか、達成したいことを明確にします。プロダクトのデザインはアートではなくサイエンスです。 最高のユーザー体験は、勝つための体験設計の一部です。あらゆるものすべてに意思が必要です。デジタル領域のプロダクトはもはやeSportsです。 3. プロダクトの価値で課題を解決する場合、誰よりもその課題に乾きを持ってください。 解決していない現状に笑けるくらい怒ってください。できない場合、本当の問題に気づくのに多くの時間がかかり、大抵の場合は先に飽きがきます。 課題の実感がない人がデザインするプロダクトほど的外れで退屈なものはありません。自分がユーザーだとこの上ないですが、「この人の問題を解決したい」と思える実在の人の近くにいてください。会って話して存在する根源的な課題を認識してください。 4. 機能ではなく、もたらす結果から考えてください。 「あったら良いな」と思う機能は必要ないです。「必要な気がする」機能も必要ないです。わからないことばかりなのに、自分でゲームを複雑にする必要はないです。削って削って削り切ってなお削りすぎたと後で困るくらい削ってください。その上で命をかけたいと思えるコア体験に集中してください。 5. 退屈な解き方をしないでください。 ただでさえAIでクソみたいなツールが増えまくっているので、あなたが作るプロダクトくらいは面白くあってください。つまらないものに人生の時間を使わせないでください。 6. プロダクトを使う道のりを完全にコントールしてください。 あなたのプロダクトを認知してから、プロダクトの入り口にたどり着き、期待値を持って動き始め、最初の最高の体験をし、お金を払ってでも使い続けたいと思う、一連の流れを何度も何度も通しで確認してください。 すべての画面、パーツに意思と責任を持ってください。パーソナライズやカスタマイズといった言葉で濁して無駄に選択肢を増やさないでください。使う人が迷う要素を徹底的に排除し導きます。 素晴らしいプロダクトデザインは空気のようです。気づかないうちに流れていきます。普段使っているプロダクトがなぜそうなっているのか、なぜ使いやすいのか、なぜ使いにくいのかを観察して説明できるようにしてください。 7. 発明すべきか、ベストプラクティスに従うべきかで悩むと思いますが、UIにおいては一番使われているプロダクトを真似してください。 プロダクトは人に使われるための道具です。使われる感触もわからず、UIの作法もわからず、何も知らないのに「俺が考える最強のプロダクト」を作る??ただ「時間を無駄にしたい」と言ってるだけです。守破離が近道です。 すべてを模倣するのではなく、中途半端に見た目だけ真似するのではなく、設計意図を理解した上で、ありがたく先人の試行錯誤の結果を拝借してください。 8. 最初からドーパミンに依存する安易な手段に逃げないでください。 焦らせて判断を鈍らせたり、論点をずらすような短期的なハックを前提にすると価値を見誤ります。ハックしなければならいほど価値のないものを作ってるんですか?ゲームに大勝利するためにも体験価値の証明を優先してください。 9. プロダクトの設計に迷った時は、リリース投稿やリリース動画を考えてみてください。 あなたがわからないものはユーザーも理解できないです。リリース時の様子が想像できないのならコア体験がまだ存在していません。作ってる自分やチームですら使うのにつまずくものはプロダクトになってないです。すべてを捨てて最初からやり直しても良いです。 10. プロダクトのスタンスやポジションを持ってください。 似たようなものがたくさんある気がしますが、あなたのプロダクトを使う言い訳がほしいです。単に便利なだけでなく、会う人々に勧めたくて仕方がなくなるような強い思想です。 スタンスやポジションはすべてのデザインの意思決定に現れます。見た目やテキストのトーン、情報設計の運び、他にはない使いやすさにです。 そのために、考えのすべてをAIに任せないでください。自分の意思を持ってください。 11. 期限を必ず切ってください。頑張っても間に合うかわからない期日を設定してください。 失敗する前提で早く動いてください。振り返るタイミングがないまま続けると失敗を認識できないからです。失敗を認識できないと改善できません。 手作りでじっくり時間をかけると愛着が湧いて失敗だと認識したくなくなります。大成功に近づくためにさっさと作ってさっさと失敗してください。 12. 素早く失敗したら、成功できるサイズやステップまで小さく小さく刻んで問題を探ってください。 失敗したということは、理解できていないことや認知していない領域が存在しています。中途半端な成功には注意してください。緩やかな死です。自信を持って成功している状態を認識し続けてください。 13. 最初から分業で物事を始めないでください。 分業はチームで最適化を行うための手段です。最適化すべきものすらない状態で、意味のないタスクを生み出して無駄な仕事をしないでください。そして、最初から自動化しないでください。バカな要件を自動化してもゴミが生まれるだけです。 13. ユーザーが使っている様子を生で見てください。 できる限り自然な状態で、説明なしに使っている様子をただただ観察してください。妄想だけでは想像もしなかったハードルが驚くほど見つかります。 14. 楽しく生きてください。つまんないやつが作るプロダクトはたいてい面白くないです。 15. 使ってもらえるプロダクトを作れるようになったら、対価をもらえるように価値の付け替えをデザインしてください。 認知と利用を一体にしたプロダクトのデザインをしたり、ユーザーのモチベーションを課金に転換したり、自己増殖的に価値が作られる仕組みを組み込んだり。この先も楽しいゲームが待っています。 16. なんだか導入の思想ばかり書いてしまったので、より具体的なプロダクトのデザインについては、数日後にパート2をあげます。フォローといいねを押してください。ありがとうございます。
3
22
16,870
昔Windowsのパッケージソフトを作ってたとき、動作しないってお客さんの自宅まで行って、状況確認とデバッグしたことがある。結局百分は一見にしかずで、見た瞬間に理由はわかった。こういうのコスト高そうに見えるけど、メールや電話を延々するよりよっぽど安いんだよな
2
23
3,100
認定スクラムマスター研修はオンライン・宿泊の2形態でお届けしていましたが、オンサイトでの2日間のCSMを開催します! メイン講師は弊社の3人目のCST、永瀬です。 3日間ブロックするのが難しい方や、宿泊だと厳しいけど通いなら…というみなさま、お待ちしております! リンクはコメント欄に⬇️
1
5
4
2,133
Ryutaro YOSHIBA retweeted
内製化、最初のひとり問題というのがあって、最初に強い人を引っ張ってこれたら強い内製化チームを作れる可能性があるが、最初に弱い人で立ち上げるとどうにもこうにも強くならないという辛さがある
ITに強い人がいるユーザ企業は割と内製シフトはあるんだろうなと思っている ITエンジニアを雇ったりとかもね
1
11
97
26,470
Spotifyのブログから。 - エンジニアの99%以上が毎週AIコーディングツールを使用、94%が生産性向上を実感 - PR頻度は76%増加 - 技術スタックは元から標準化 - CEOもClaudeで数分でプロトタイプ作成 - ボトルネックは実装から意思決定へ移行し、計画や優先順位付けを再考中
5
40
309
58,098
記事はこれ。「世界をリードする技術分野が少なければ少ないほど、開発スピードは速くなる」と考えて元から技術スタックを標準化してたのが好感持てる engineering.atspotify.com/20…
7
50
4,887