デザインシステムは最優先にはならないです
どちらかというと優先順位は低めですデザインシステムの必要性を説く時代は終わりましたが、その利用促進や運用継続は容易ではありません。デザインシステムの構築者とプロダクト設計者が同じ人物であるような小規模組織では、ガバナンスの課題は些細なものばかりです。また、コミュニケーションが活発な小さな開発チームなら、メンバーのモチベーションが続く限り、維持・管理は比較的容易です。 組織が大きくなり、様々な体制やプロセスを持つ複数のプロダクトが存在する場合、全員一丸となってデザインシステムを取り組むのは難しくなります。その結果、「作る側」と「使う側」に分かれがちです。この問題を解決するため、各プロダクトから代表者を集めて議論する連邦制のような体制が考えられます。しかし、デザインシステムへのコミットメントを本業と両立させるのは容易ではありません。 プロダクトの開発と改善に集中しているチームにとって、デザイン
Google のクチコミの仕組みについて
行ったことのない場所を検索するとき、地域の多くの情報が詰まった Google のクチコミを使えば、お店やレストランなど、あなたにぴったりの場所やビジネスの情報を見つけることができます。 日々、世界中のユーザーから数百万件にのぼるクチコミが投稿されており、Google は情報の有益性と正確性を保つため 24 時間体制でサポートしています。不適切なコンテンツを防ぐための作業の多くはあまり知られていませんが、今回はユーザーがクチコミを投稿した時の舞台裏を紹介します。 ポリシーの作成と実施 クチコミが実際の体験や来店に基づいていることを確認し、関係性のないコメントや不快なコメントを Google ビジネス プロフィールから除外するために、 厳格なコンテンツポリシー を作成しています。 世界が進歩するにつれて、Google のポリシーと保護も進化しています。これにより、不正行為の対象となる可能性があ
なぜスクラムチームをスケールしたくなるのか - だいくしー(@daiksy)のはてなブログ
Nexus, Scrum@Scale, LeSS, SAFeなど、スクラムチームをスケーリングする手法はたくさん存在する。 しかし、アジャイルコーチなどに、「スクラムをスケールするにはどうすればいいですか？」と聞くと「そもそもスケールをするな」と言われることもある。ぼくも基本的にはこれに同意する。 コンパクトな職能横断型のチームで、短いサイクルで高速に、安定したペースで開発をする。これをずっと続けることができるのならばそれが一番良い。 なのになぜ、人々はスクラムチームをスケールしたくなるのか。なぜこんなにたくさんのスケーリング手法が存在するのだろうか？ そういうことを考えてみた。 最初から人がたくさん必要な場合 そもそも最初からスケールされたチームでやりたいパターンがある。大規模な開発などはそうだろう。 小さくローンチして、インクリメンタルにユーザーフィードバックを受けながら開発できれば理
オープンソース：コミュニティからビジネス化への道 (a16z) - FoundX Review - 起業家とスタートアップのためのノウハウ情報
オープンソースのルネッサンスは進行中 フリーからSaaSまでのオープンソースの歴史 オープンソース0.0 – 「フリーソフトウェア時代」 オープンソース1.0 – サポートとサービスの時代 オープンソース2.0 – SaaSとオープンコアの時代 オープンソースの好循環 Business Success Centersを支える三本の柱 プロジェクトコミュニティフィット プロダクトマーケットフィット（PMF） バリューマーケットフィット 事業モデルの選択 クラウドと競争の壕 (moat) 市場開拓——オープンソースはファネルのトップ 第一段階：認知と感心 – 開発者コミュニティのマネジメント 第二段階：検討 – プロダクトマネジメント 第三段階：評価と意図 – 見込み客の獲得とビジネスデベロップメント 第四段階：購入と拡大 – インサイドセールスとフィールドセールス 成功と失敗はどのような姿を
OSSへのフィードバックはユーザーフォーラムとイシュートラッカーのどちらに書くべきか？ - 2019-06-18 - ククログ
※注：この記事の対象読者は、「OSSを使用していてトラブルに遭遇しているか、改善の提案があり、その情報を開発元に伝えたいが、どこで伝えればよいかわからない」という人です。「どういう体裁で報告すればよいか分からない」「何を報告すればよいか分からない」という人向けの話はまた日を改めて書くつもりです。 結城です。 OSS Gateワークショップで、初めてフィードバックをしようとしているビギナー参加者のサポートをしていると、ビギナー参加者から以下のような質問を受ける事があります。 こんな簡単な・くだらないレベルの事を報告してもいいんでしょうか？ ユーザーフォーラムとイシュートラッカー（バグトラッキングシステム）1のどちらに報告すればいいんでしょうか？ どのプロジェクト（開発元）に報告すればいいんでしょうか？ これらの点に対する筆者の回答は、端的には以下のようになります。 簡単でも些細でも何でも、あ
マーケティングを捨てよ、サポートへ出よう 事例から見るスタートアップ初期におけるユーザー獲得
2/23 に行った講演の資料です。スタートアップの初期ユーザー獲得の方法としてのセールスならびにサポートについて解説した内容になります。 マーケティングを捨てよ、とは言ってますが、もちろんマーケティングは大事です。ただ初期ユーザー獲得においてはマーケティングよりもセールスやサポートに力を入れたほうが、その活動を通してプロダクトも良くなるのでそっちのほうが良いのでは、というご提案になります。タイトルは寺山修司「書を捨てよ、町へ出よう」からです。Read less
Database smells
1. Database Smells データベースの不吉な臭い ＠データベース・リファクタリング読書会 奥野 幹也 @nippondanji mikiya (dot) okuno (at) gmail (dot) com 2. 免責事項 ● 本プレゼンテーションにおいて示されている見解は、私自身 の見解であって、オラクル・コーポレーションの見解を必ず しも反映したものではありません。ご了承ください。 3. 自己紹介 ● 今日は個人として来ています。 – http://nippondanji.blogspot.com/ – Twitter: @nippondanji ● MySQL サポートエンジニア – 2000 年にサン・マイクロシステムズ入社 – 2007 年に MySQL KK へ転職 – 気付くとまたサン・マイクロシステムズに・・・ – 現在は日本オラクルに在席。 – サポート一筋
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
