前エントリで論じられた、正しいランキング設計の考察の続き。第2回は、ランキングの収奪性、格差の固定性を軽減する手段を、具体的に論じてみる。 前回の記事へのTwitter上のフィードバックは、Togetterにまとめてある。こちらもご興味があれば、一読の価値がある。いくつか被ってしまったものもあるけれど、諸々の後半記事。 「ランキング」以外の名称を用いるこれはほぼ確定。ランキングという名前は、「noteとして競争原理を推奨する」という強いメッセージを発する。noteの全てのユーザーが、競争原理で動いているわけではないので、これは望ましくない。 おそらく最終的には「注目」「人気」などの名称を使うことになるかと思われる（「オススメ」はパーソナライズ用にとっておく）。また、「ランキング」という名称やスタンスをやめることで、後述するようないくつかの公平性のための施策を行う余地が生まれる。 時間による

検索 UI を作る機会があったので、リファンレンスを集めた。あたまの整理をかねてパターン分け。 パターン一覧 1. フリーワード型 2. サジェスト型 3. グループ型 4. あとからフィルター型 5. 条件指定型 6. レコメンド型フリーワード型キーワードで検索。入力中に検索結果がリアルタイムに変わるものが多い。 良いところ シンプル。入力と同時に検索結果を表示できるので、最短で検索対象へたどり着ける。 イマイチ キーワードが間違っていると、対象へたどり着けないことがある。 感想 タスク管理やシンプルなファイル管理に多く採用されていた。 複雑な検索条件が不要。ユーザーが検索対象のキーワードを把握している場合に有効そう。見つける、というよりも、ショートカット的な役割に近い。サジェスト型キーワードを入力すると、検索候補が表示。 良いところ キーワードを正確に把握していなくても対象へたどり着け

2012年1月、Twitter の iOS チームに7人目のエンジニアとして入った。 たまたま最初の週が Hackweek だったので、通常の仕事は一旦停止。なんでもやりたいことをやっていいらしい。入ったばかりで何もわからない状態だったので、ぼくのメンターのテックリードがやっていた Twitter for Mac の多言語化を手伝うことにした。水曜にパッチをマージしてもらって、ぼくの担当部分は完了。その後は次週から始まる通常営業に備えてコードを読み始めた。 次の週からは通常のサイクルが始まった。毎朝スタンドアップミーティングがあり、各自の仕事の進み具合を他のメンバーと共有する。前職までは同僚がほぼ日本人ばかりだったので英語で仕事をしたことがなく、聞き取りがうまくできなかったのを覚えている。 この日からさっそく Twitter for iOS のユーザーとして気になっていた問題を直し始めた。

(Twitter での6年間 6 からの続き) Apple のイベントからしばらくすると、テックリードから提案があった。ぼくがデモ用に作ったライブラリの設計もコードもきれいで見通しがいいので、そのライブラリをアプリ本体に組み込んで、既存のコードを置き換えてはどうかということだった。ぼくはその提案には反対だった。既存のコードによほど大きな設計ミスがない限り、同じ要求を与えれば同じコードができあがる。ぼくの知る限り、既存のコードに大きな設計ミスはなかった。ぼくは、まずゴールとなる新アーキテクチャーを設計し、既存のコードを徐々に置き換えていくことでゴールに近づけていくインクリメンタルアプローチを提案した。既存のプロモートツイート関連のロジックを新しいコードベースに意味もなく移植したりすることで問題を起こしたくなかったのだ。マネージャーや他のエンジニアたちも同意見で、新アーキテクチャプロジェクトを

こんにちは、HR TechスタートアップでHRをしています。なんだかんだで、採用という領域に14年くらい関わっています。 ここ最近、IT/Webエンジニア採用において大きな変化を実感していて、それに対して経営者や人事の変化が少ないな、と感じていたので記事にします。 願わくば、エンジニア採用をやっている企業の経営者や人事の役に立てば幸いです。 変化さて、その大きな変化というのは、採用企業と求職者間における情報量の逆転です。変化の傾向自体はずっとあったのですが、ここのところ閾値を超えた感じがあります。 数年前のソシャゲブームのときも、求人倍率としては求職者が優位ではありました。それでもまだ当時は採用企業のほうが情報強者で、待遇につられてブラック企業に入ってしまうエンジニアが多かったのを記憶しています。 それまでは求人情報といえば、求人広告やエージェントから伝えられる情報をもとに求職者が判断し、

どうも、さっそ (@satorusasozaki) です。 ぼくは「シリコンバレーで世界を変えるプロダクト作る！」という目標を掲げ、3年前に渡米しました。最初の2年間はエンジニアとして活動し、3年目に現地で出会った4人の仲間とスタートアップを始めました。1年少し続けたのですが解散することになったので、今日は以下の3点を中心に、振り返りを書いてみたいと思います。 ・シリコンバレーで現地の人とスタートアップを創業するまで ・スタートアップな生活 ・スタートアップが解散する理由 シリコンバレーで現地の人とスタートアップをするのはどんな感じなのか、できるだけ具体的に想像していただけるように、私生活など、仕事以外のことも織り交ぜながら書いていきたいと思います。これからサンフランシスコ・シリコンバレーに来て何かやってみたいという人のお役に立てれば嬉しいです。 ・・・ スタートアップを始めるまで最初に、

チャーリーです。 先日6/5(火)にDMMさんに講演に呼んでいただき、1時間半でこれまでの #ビジネスモデル図解シリーズ の総集編みたいな話をしたので、この記事にまとめるよ。 当日は #DMMビジモ というハッシュタグを使ってたくさんの方がつぶやいてくれました。なんと東京のトレンド8位に。 ここから講演のスライド。ぜ、ぜんぶで91枚...？ 講演ではスライドを映しながら話したので、スライドだけではわかりづらいかもしれないけど、ぜひご覧ください（途中にyoutubeライブの動画を貼ってるのでそれもよければぜひ）。 ※ 最後にPDFファイルもあります 実は当日Youtubeライブ配信があったのですが、途中まで切れていたようで、ちょうど上のスライドから動画が残っています。以下の動画をみながらスライドをみると、スライドで言い切れていないニュアンスも含めてお話しているので、動画といっしょに見るのがお

ANDPADでデザインを担当している後藤です。 エンジニア 「このボタン、分かりにくいですね」 開発を進めてて、エンジニアにこう言われたことはありませんか？ 「このボタンって、どう動くんですか？」 「このボタン、気がつきにくいですね。」 そういったときに、どのようにUIの意思決定をしたか、説明して納得してもらう必要があります。 今回は「並び替えボタン」で起きたケースを紹介します。 あまり目立たない機能ですが、データを整理することが多いBtoB向けサービスでは、要望が多い機能じゃないでしょうか。 【目次】 ・どこが分かりにくかったか？ ・エンジニアとデザイナーの通る思考回路は違う ・エンジニアの考えた解決策 ・画面上における機能の優先順位 ・機能単体のゴール ・まとめ どこが分かりにくかったか？実際の画面がこちらです。（※こちらは現在開発中の機能になります） さて、どこが分かりにくかったでし

2020年4月26日UPDATE 記事公開から早いもので2年が経ち、こちらの記事は有料とさせて頂きました。 Here’s my «me too» story about Araki . Sorry that is only in Japanese. I hope some of your friends can help you read it or maybe you don’t need to read it you already understand something... In the end, finally i got his answer. I do now realize what he was thinking regarding us and his “art" 📸 All i can do now is to accept the situation as it

ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。

完璧なゆで卵をつくるにはまず、卵黄と卵白の凝固温度を復習する必要があります。白身は63度から固化しはじめ、70度で黄身が固化します。つまり、63度以上70度以下の温度につけておけば温泉卵ができるというわけで、とろとろの半熟が好みなら70度以下の加熱にとどめ、やや固いのが好みなら中心部の温度を80度に近づけるようにすればいい、というわけ。 しかし、ゆで卵が難しいのは白身と黄身という二つの異なる凝固温度の物質を一度に求める温度まで加熱しなければいけないからです。正直、料理のなかで最もレシピが書きづらいのがゆで卵ではないでしょうか。 例えばレシピに「冷蔵庫から出したての卵を使いましょう」と書いたとします。しかし、冷蔵庫の庫内温度の設定はぞれぞれ。業務用の4℃かもしれませんし、家庭用の10℃かもしれません。卵の初期温度が違えば調理時間も当然変わってきます。さらに卵は一つ一つ形やサイズが異なるのです

エンジニアのnoteクリエイターさん達に、素敵なお知らせが。 pcのnoteエディターに、コード埋め込み機能（β）がつきました。エディタでテキストを選択し、ポップアップのコードボタンを押すと、コードブロックを埋め込めます。 こんな感じですね。 for(int i=0; i<100; i++){ println("hello world"); }あわせて、コードブロックの中では、TABボタンが使えるようになります。まだ実験中なので、使いにくいところはあるかと思います。 アプリでの対応はリニューアル後になってしまいますが、年内には搭載されるはずです。マークダウン…もなんとかしたいところですが、これは年内目標ということで。 まずは需要があるかどうかのテストとなります。 今回、実装をメインで頑張られたのは、エンジニアのtanazawaさんです。お疲れ様でした！今後も、noteのチーム一同、引き続き

暗号通貨のおもしろいところの一つとして合意形成アルゴリズムにあると思っているのですが、PoWやらPoSやら横文字が多くてとっつきづらいので自分なりに図解してみました。 PoWとは ビットコインなどで採用されているPoW。 「強きものが利益を得る」という人の欲望をうまく刺激してるが、設備投資費や電気代がかかりすぎるので、相場が急落したり、マイニング量の半減などで成り立たなくなる恐れがあり、個人的には持続可能で健康的な仕組みではない気がしています。 PoSとは イーサリアムは今はPoWですが、将来的にはPoSに移行するといわれています。こちらも人の欲をうまく利用していますが、富がある箇所に、より富が集中していく仕組みなので、後参入にはうまみがなく、若干ねずみ講的な印象があるので個人的には好きではありません。 PoIとは 個人的に今の暗号通貨の中で最も平等で将来性を感じる仕組みはPoIです。暗号

先日、ふとしたきっかけで乃木坂46の公式サイトをリデザインを思い立ち、スキルアップの一環も兼ねてトップページをリデザインをしていました。 そのリデザインから学んだことなどをブログに書きたいと思っていたのですが、公式サイトに掲載されているコンテンツの著作権上、なかなか難しいかなと思い、念のため乃木坂46の運営委員会に問い合わせてみたところ、営利目的でなければ使用しても大丈夫（ブログの掲載も可）との許可をいただいたため、こちらに書くことにしました（2/9 16:43：問い合わせの内容は、公式サイトのお問い合わせフォームから送信したため、画像の添付などはしていません。コンテンツの掲載許可は頂きましたが、運営委員会に直接デザインデータを送ったわけではありません）。 なぜリデザインをしたいと思ったのかもともとアイドルが好きで、アイドルグループの公式サイトをチェックする機会が多いのですが、乃木坂46の

マネジメントを行われている管理職の方で、実際にマネジメントにおける最適なプロセスについて深く洞察さている方はいらっしゃいますか？ そんな皆様にはぜひ「デザイン思考」の考え方を取りいれていただけると、今よりきっとうまくいくはず！という事を紹介したいと思っています。 リーダーとマネージャーは別物まず前提として、組織のリーダーシップと、メンバーをマネジメントすることは全く別のことだと言われています。 スティーブン・コヴィーの『７つの習慣』ではこう定義させていました。 ・リーダーシップ：正しい道を指し示し、先頭に立って進むこと ・マネジメント；示された道筋に対して最適化を効率よく行うこと 以下に７つの習慣で語られていた、リーダー、マネジャー、メンバーについての記述を引用します メンバーとは？ 道を切り開いている作業チームのメンバーは生産者であり、 直接に問題を解決しようとする人たちである。 マネー

Herokuはwebアプリをインターネット上にデプロイする場所として広く使われている。web業界の人は誰もが一度は触った事があると思う。 何が便利なのかというと、デプロイ作業が極めて簡単なことだ。コマンド一発でサーバーが用意され、これまたコマンド一発でデプロイが出来る。一般に、webアプリは依存するライブラリが多種多様あり、それらを漏れなくインストールしないとデプロイ出来ないのだが、代表的なwebアプリケーションの作り方に添って作っている限り、後は構成を検知してよしなにやってくれるのだ。noteのリリース時の検証にも大活躍してくれた。 別にHerokuの回し者ではないのだが、一旦これを経験すると、VPSを借りてLinuxのセットアップをしてミドルウェアいれて....といった一般的な構築作業が気の遠くなる工程に思えてくる。 しかし、HerokuはUSとヨーロッパにサーバーがあり、日本からの通

軍事ドクトリン（原則）や戦略書、兵器の変遷史などを読むのが好きです。 戦争が好きなわけではなく、とても勉強になるからです。戦争というのは、有史以来、全文明がもっとも真面目に研究し、アップデートを繰り返してきた分野です。なので、最も合理的かつ実践的なノウハウが詰まっています（軍事が合理的でない国は、だいたい滅びました）。 これらの知識を、応用ができることはいっぱいあります。限られた時間やリソースでの意思決定や、ライバルとの競争、団体競技などなど… 以下は、ジョン・フレデリック・チャールズ・フラーという、英国陸軍の人が提唱する陸戦原則。この原則は、世界中の陸軍教練に広く取り入れられています。デザインやビジネスなどでも、非常に使い勝手良いかなと感じています。 （上のリストは、厳密にはフラーのオリジナルでなく、彼のセオリーから米軍が作った改訂版「1986年版の米陸軍の野戦教範100-5」ベースの、

引継ぎ資料を作るときには、ボードゲームの説明書の作り方を真似しましょう。すると誰でも分かりやすい資料ができて、後任の人がハッピーになって、感謝されて、あなたもハッピー。 本noteでは、そんなハッピーを生み出すために、ボードゲームの説明書の構造 & 引き継ぎ資料への作り方を解説していきます。ゲームを作る方なら、説明書をデザインするときも参考になるかもしれません。 まずは実際の説明書を見てみましょう。 下記の画像は、僕が以前つくった「切り裂きジャックは誰？」というゲームの説明書です。「B5１枚に収める ＆ フォントは最低でも7pt」という制約のため詰め込み気味ですが、内容は結構わかりやすくなっているかと思います。 これを踏まえて、各項目について解説していきます。 １．ゲームの名前おそらくどんな説明書でも、最初に書かれているのはそのゲームの名前ではないでしょうか。 引き継ぎ資料も同様に、最初は

はじめましてnoteの皆さん、名人を倒した将棋プログラムPonanzaというものを作っていた山本一成と言います。この度ははてなから引っ越してきました。2018年になったので新しくブログ書いてみようかなぁ〜ってはじめました。 私がプログラミングをはじめたのは大学生だった時ちょうど10年前でした。そして今2018年になって、同じプログラミングにしても色々変わったなぁという印象です。今日はそのへんを皆さんと共有できたらなぁ〜と書きました。 あくまで私の観測範囲内での話をすればですけど、10年前のプログラミングの世界は速く動くことがかっこよかったです。実際にかっこいいだけでなく、必要とされる場面も多かったような気がします。私が愛用しているプログラミング言語はC++(シープラスプラス)と言って、まあそれは高速に動作することだけを意識して作られた言語でした。 加えて、今から考えれば一体なんでそんなトリ

Sketchの命名ルールなどをまとめたGuidelineをつくりました - itachoco Sketch Guideline v0.1 note初投稿です！株式会社ソウゾウでメルカリ カウルというプロダクトのデザイナーをしている @wataame といいます。 突然ですが、Sketchを使ってアプリのUIなどを作る時に、「このレイヤーの名前どうしよう。。Table View？」と悩んだり、レイヤーの重ね順を「Artboardに配置している順番に上から並べる？」など、悩んだ経験があるデザイナーは多いのではないでしょうか。 どれが正解ということはなく、業界全体として特定のルールがあるわけでもないので、人によって・チームによってマチマチになっているのが現状で、チームに複数デザイナーが居る場合は、お互い空気を読みつつなんとなく合わせようとするけど細かいところはぐちゃぐちゃ。という状況で他の人が作