$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

様々な価値観を持った人の生の声を聞ける「現役東大生が1日を50円で売ってみたら」読んだ

読んだ。非常に面白かった。自分はエッセイやノンフィクションの本は読んだことはあまりなかったのだけど、今後はいろいろ探してみようかなと思うくらいに面白かった。

著者が1日を50円で売ったことで出会った人たちと会話している内容や、それについて著者がどう思ったかなどが、この本に書かれている。発達障害の子供、ニューハーフ、キャバクラの人、地方議員など、本当にいろんな価値観を持った人たちと出会っていて、しかもそれぞれでネットやテレビの情報などではない生の声が聞けているのが良かった。これを読んでいると、自分もまだレッテルを貼っていることがあるなあと思う。

個人的に好きだったエピソードは、「ニューハーフと、デート」という話。LGBTの割合が13人に1人もいるとは思ってもいなくて、左利きと同じくらいの人数と同じだし、マイノリティとはなんなのかという気持ちになった。

とにかくおすすめ。興味があったら是非読んで欲しい。

登場人物を分類し、振る舞いを分解して、機能を考える(企画職の人に教えてもらったこと)

本職の企画の人が優れた機能案を出してくる理由がわからなくて、どうやってやってるんですかと雑談した。新たな発見があったので、雑なメモだけ残しておく。*1

その人の企画の流れ

企画の流れは、以下の3ステップで行っているらしい。

  • 1. 登場人物を分類する
  • 2. 登場人物ごとの振る舞いを分解する
  • 3. 様々な振る舞いを照らし合わせて、機能・UIを絞り込んでいく

「1. 登場人物を分類する」は、機能に関わる人物をツリー構造に分類していき、分類をした結果から、その機能を使うメインターゲットを決めるフェーズらしい。

例えば、ブログユーザーをブログの作者と読者に、さらに作者を毎日更新する人とそうでない人に、みたいにどんどん分解していく。すると、機能のメインターゲットが浮かんでくる。


「2. 登場人物ごとの振る舞いを分解する」では、メインターゲットを中心に、どのような振る舞いをするかを考えるフェーズらしい。

  • 振る舞いの種類を分解する
  • 振る舞いの流れを分解する
    • 流れのスタートから始めても、流れのハイライトから始めても良い

例えば、ブログ記事を読んでシェアするとかだと、ブログ記事を探す、ブログ記事を見つける、ブログ記事をシェアするみたいに、振る舞いをリストアップできる。さらにその流れを作っていくことで、徐々にどういう振る舞いがされるかが見えてくる。


「3. 様々な振る舞いを照らし合わせて、機能・UIを絞り込んでいく」では、登場人物と振る舞いがまとまったところで、それらを達成する機能やUIを考えるフェーズらしい。別の振る舞いを同じ機能・UIで達成できるなら、機能やUIをどんどん絞り込んでいき、シンプルにしていくみたい。

自分を振り返ってどうなのか

これと自分と比較してみると、自分のできていないところが見えそう。考えてみると、自分はサービスを使った経験から適当に機能やUIを考えるので、機能を考える上で登場人物や振る舞いのリストアップに漏れが発生していたということが分かった。

  • 自分は登場人物を根本から分類して決めるのではなく、自分のサービスを使った経験からしかしていなかったので、その機能を使う登場人物に漏れが発生していた
  • 振る舞いの種類をちゃんとリストアップしていないので、登場人物がやりたいことに漏れが発生していた
  • 振る舞いの流れをちゃんと分解していなかったので、機能を使う動機設定、適切な導線設計などができていなかった
  • 機能が狭い登場人物や振る舞いのために作られたものになり、他の登場人物のために別の機能を用意することになりがちだった

まとめ

企画よりはエンジニアを優先したいけど、こういう企画の流れを知れたのは非常に良かった。今後に活かせそう。

*1:一応企画の方に確認しました

「検索エンジン自作入門」を読んだ

Elasticsearchが裏でどのように動いているか理解できるようにするために、「検索エンジン自作入門」を読んだ。

この本を読んで、検索エンジンがやっていることを簡易的に知ることが出来た。少し理解するのは難しいが、具体的な例をコードレベルで見ることができる資料はなかなか無いので、非常に良い本であった。

2章以降からはコードを使って説明がされていくのだけど、そこからは理解が難しいかもしれない。しかし、それ以降を理解できなかったとしても、1章が端的に検索エンジンの仕組みについて書いてあるので、1章を読むだけでも価値があると思う。

自分の中では以下のものが参考になった。

  • 検索エンジンは4つのコンポーネントからなる
    • インデックス管理器
    • インデックス検索器
    • インデックス構築器
    • 文書管理器
  • 転置インデックスとは、{ 単語 -> [ docID & positions, docID & positions, ... ], ... } という集合で組み合わさっている
  • 転置インデックス構築処理の流れ
  • 転置インデックスからの検索処理の流れ
    • 検索クエリをトークンに分割する
    • 分割されたそれぞれのトークンを、そのトークンが出現する文書数が少ない順にソートする
      • ソートすることで比較回数を最小に出来る
    • それぞれのトークンのポスティングリストを取得し、文書IDとその出現位置のリストを取り出す
    • すべてのトークンで同一の文書IDが含まれ、かつ、各トークンの出現位置が連接していれば、検索結果に追加する
    • 検索結果に追加した各文書と検索クエリの適合度を計算する
    • 検索結果を、適合度の降順に並べ替える
    • 並び替えられた検索結果ののうち、上位のものを検索結果として返す
  • 文書は単語数次元あるベクトルとみなす事もできるので、ベクトルの近さを見れば類似度が分かる

また以前転置インデックスについても書いたのでこちらも参考に。

blog.shibayu36.org

読書メモ

  • 検索エンジンは4つのコンポーネントで(図もあり) 207
    • インデックス管理器
    • インデックス検索器
    • インデックス構築器
    • 文書管理器
  • 転置インデックスの仕組み 266, 341
    • 単語 -> [ docID & positions, docID & positions, ... ]
  • 転置インデックスからフレーズを探す 366
    • 単語を全て含むものを検索し、さらに同一ドキュメントでpositionが隣同士
  • 転置インデックスの辞書の実装 454
    • 二文探索木やB+木
  • 転置リスト(ポスティングリスト)の物理的レイアウト 506
  • 転置インデックスを用いた検索処理の流れ 542
    • 1. 検索クエリを構成する単語ごとに、ポスティングリストを取得
    • 2. ブーリアン検索により、検索条件に該当する文書IDを取得
    • 3-1. 検索条件に該当する文書とクエリの適合度を計算
    • 3-2. 検索結果を並び替えるための属性値を取得
    • 4. 適合度または並び替え用属性値の上位k件の文書を取得
    • 検索クエリを構成する単語をポスティングリストの長さの昇順にソートすることで、比較回数を少なく出来る
  • マージに基づくインデックス構築方法 655
  • トークン抽出の流れ 849
    • 対象となる文書から、トークンとその出現位置を抽出する
    • トークンごとに、文書への参照(文書ID)と出現位置を保存する
  • 転置インデックス構築処理の流れ 1124
  • 転置インデックスからの検索処理の流れ 1161
    • 検索クエリをトークンに分割する
    • 分割されたそれぞれのトークンを、そのトークンが出現する文書数が少ない順にソートする
    • それぞれのトークンのポスティングリストを取得し、文書IDとその出現位置のリストを取り出す
    • すべてのトークンで同一の文書IDが含まれ、かつ、各トークンの出現位置が連接していれば、検索結果に追加する
    • 検索結果に追加した各文書と検索クエリの適合度を計算する
    • 検索結果を、適合度の降順に並べ替える
    • 並び替えられた検索結果ののうち、上位のものを検索結果として返す
  • 検索クエリ「きょうは」というクエリで検索する例 1233
  • マッチしているかどうかを判定する流れ 1247
    • トークンAの文書IDを取得し、それ以外のトークンについて同じ文書IDを持つかどうかをチェックする
    • 同じ文書IDを持つトークンがないことがわかったら、トークンAのポスティングリストを可能な限り読み進める
  • 類似文書検索 2087
  • 動的なインデックス構築の基本的な戦略 2707
    • インデックスをメモリ上のインデックスとディスク上のインデックスに分割して管理する
    • 文書の追加による更新は、基本的にはメモリ上のインデックスに対して行う
    • ただし、メモリ上のインデックスのサイズが事前に設定したメモリ容量の上限に達した場合は、メモリ上のインデックスをディスク上のインデックスに統合する
  • インデックスのマージによる統合 2743
    • Remerge戦略 ディスク上のインデックスを常に1つに
    • No Merge戦略 マージを全く行わない
    • Geometric Partitioning戦略 ディスク上を複数の大きさの異なるインデックスに分割し、小さいものをマージしていく
  • XML Parserの種類 2864
    • DOM Parser: 一気に読み込んでパース処理。要素の順序を気にせず操作を行える反面、メモリ使用量が多い
    • SAX Parser: XMLを読み込みながら順次パース処理。メモリ使用量は少ないが、要素の順序を考慮する必要あり