ランサーズ(Lancers)エンジニアブログ > もくもく会 > 2023/8/25週 もくもく会 UXデザインの教科書, Next.jsのParallel routes, オープンソースLLM, INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
2023/8/25週 もくもく会 UXデザインの教科書, Next.jsのParallel routes, オープンソースLLM, INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

2023/8/25週 もくもく会 UXデザインの教科書, Next.jsのParallel routes, オープンソースLLM, INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

tanifumiya|2023年08月25日
もくもく会

ランサーズでは自己学習の場として毎朝1時間程のもくもく会を開催しています。
もくもく会を開催しようと思ったきっかけは、こちらで紹介しています。
以下は今週の取り組みになります。

今週のもくもく会

  • フロントエンドテスト入門第4章を読んだ
    • Web APIのモック作成
    • モックには以下がある
      • スタブ(代用目的、一般的なモックのイメージ)
      • スパイ(記録目的、APIが実行された回数、引数などを記録する)
    • スタブは、jest.mockで作る
    • スパイは、jest.fn() + toHaveBeenCalledなどのメソッドを利用
  • VRTの対応を確認した
    • Visual Regulation Test
    • github actions → frontend_check → Summary → Artifacts → vrt-report → ダウンロード → vrt_report.html
  • UXデザインの教科書を読んだ
    • https://zenn.dev/link/comments/71025848f085d3
    • 一般に、新しい製品やサービスを作ろうとする時、「◯◯できる製品」とか「◯◯を実現するサービス」というように、最初に製品・サービスのコンセプトを決めることがある。
      • 製品・サービスが出来ることを先に考えてしまうと、それによって実現するUXはその機能を使うことが目的になってしまう。
      • 実際の利用文脈では、ユーザーは機能を使いたくて製品・サービスを使うわけではない。 ユーザーの目的を果たすための手段として製品・サービスがあるはずだ。
      • 最初に機能を中心としたコンセプトからデザインをはじめてしまうのは、製造業の製品開発などでよく見られる誤ったアプローチである。
    • UXデザインでは、ユーザーが求めている体験価値の中からデザインで実現する体験価値を設定し、それを目標としてデザインを詳細化していくことが特徴である。
      • 体験価値とはユーザーが行動によって得られる嬉しいことである。
      • 体験価値はUXの中心的な概念であり、最初にユーザーの嬉しいと感じる原理を設定してしまうところに、UXデザインの最大のポイントがある。
      • 機能に合わせてユーザーの行動を都合よく合わせて考えるのではなく、デザインのアウトプットの一番最初にユーザー側の要件を決めること。
    • UXデザインは、どのようなものを作るかを検討する企画の段階がとても大切
    • 大切なのは、最初に検討した体験価値や理想のUXを目標として設定し、この目標からブレないように常に確認しながら具体的な制作を進めること
    • せっかくUXを重視しながらコンセプトを作っても、製品を作る際にそれを無視した制作が行われてしまうのであれば全く意味がない。
    • UXデザインは、製品・サービスを提供する際の仕組みを作ることまでがデザインの範囲
      • Webサービスの場合は、情報の更新体制などを含む運用体制やその運用計画がそれに当たる
      • 接客を含むような場合は、接客する従業員のマニュアルや制服など、検討するべき仕組みの範囲が大幅に拡大する
    • ユーザーとはだれか
      • 一般に、ユーザーと言うと、製品・サービスを直接使用する個人をイメージする
      • しかし、操作する個人のユーザー以外にも多様な役割のユーザーがいる
      • トラブル時のメンテする人、サポートする人、危機が出力する結果を受け取る人
      • 直接システムを操作する人を直接ユーザー、出力結果を利用する人を間接ユーザーと呼ぶ
    • ハッセンツァールモデルのUXモデル
      • 大きく3つ
        • 『実用的属性』と『快楽的属性』の2つの視点
        • 作成者は実用的属性を注目しがちで、そこにしかアプローチできない
        • ユーザーは快楽的属性しか見ていない
      •  ハッセンツァール曰く『快楽的属性』には以下のような3つの要素がある。
        •  刺激(刺激を受ける)
        • 同定(自分らしさを示せる)
        • 喚起(気持ちが喚起される)
      • 優れた品質は『実用的属性』だけでは築けない。
    • UXの定義
      • 定義元がいくつか存在
        • ISO9241-210:2010
        • UXPA(User Experience Professionals Association)
        • ニールセンーノーマングループ
        • ハッセンツァールとトランクティンスキーによる定義
      • 共通する点
        • 主観的評価
          • 体験の感情的評価(UXの本質的特徴)
        • 消費者とユーザーの連続性・一体性
          • ユーザーであるまえに製品を購入する消費者
          • 製品を利用する前のフェーズも利用の段階と同様に扱う
        • 時間的・長期的視点
          • ユーザーとサービスの関わりは、一時的なものに限定されない
          • 長く使う間の経験全てがUXの範囲

磯野

  • 今週やったこと
    • Reactでモーダル作る
      • モーダルは最初useStateで開閉状態を管理していたが、Next.js13の場合URLパラメータを用いて管理するのが良いらしい
      • URLパラメータで管理する方がモーダル表示・非表示時のTransitionも効くようになったのでこちらを採用
      • ‘use client’の乱用を防ぐこともできたので一石二鳥How to deal with basic Modal in Next.js 13 App dir
    • Next.jsのParallel routesについてお勉強
      • Intercepting RouteとParallel Routeの違い by ChatGPT4

      もちろんです、それではある世界を考えてみて下さい。この世界はまるで大きな街のようなものです。そして、君がこの街で遊びたいと思っているゲームの世界に行くには、特定の道路を通る必要があるとします。この道路、これがまさにNext.jsの「ルーティング」に相当します。


      では、「Intercepting Route」が何かを考えてみましょう。これはまるで街のゲートキーパーのようなものです。「Intercepting Route」は君が特定の道路を通る前に立ち止め、君が正しい許可や資格を持っているかをチェックします。もし資格がなければ、「Intercepting Route」はその道を通らせてくれません。この機能は、認証や特定のデータが必要なページへの進入を制御するのに役立ちます。


      それでは、「Parallel Routes」について話してみましょう。これはまるで同じ道を走る2台の車のようなものです。君が1つの道路を通りながら、同時に別の道路も進むことができます。これらは互いに競争せず、同時に独立して動作します。これにより、あるルートの進行状況が他のルートに影響を及ぼすことはありません。これがNext.js 13で導入された新機能で、複数のルートフェッチを同時に行うことが可能になりました。 この説明で、「Intercepting Route」と「Parallel Route」の違いが理解できたでしょうか? どちらも道路(ルーティング)をどのように利用するかという、基本的な考え方は同じですが、その使い方や扱い方が違うんだよ。

    • 新サイトにも導入できそう
      • 一覧ページで動画教材クリックしたらモーダルを表示させる(動画のプレビューを再生する?)
      • リロードしたら動画再生ページに遷移する

    https://nextjs.org/docs/app/building-your-application/routing/parallel-routes

    • デジタル庁のウェブアクセシビリティ導入ガイドブック読む
        1. ウェブアクセシビリティの基礎までしか読めてない
      • 来週も引き続き読んでいく
      • 今週の気づき
        • ウェブアクセシビリティは基本的に「人がチェックする必要がある」と考えましょう。
          • 本格的なwebアクセシビリティ適用に時間がかかるわけだ。。
          • 機械的なチェックでは、2〜3割くらいしか達成できないらしい
        • 一時的に障害がある人もウェブアクセシビリティの対象
          • 例えば、「メガネ忘れた」「腕を骨折して使えない」「電車内で動画見たいのにイヤホンがない」
          • 今まで上記の人は対象者に含まれないと思ってたので目から鱗だった

砂田

  • 最近、調べたことをNotionにメモを残すようにし始めた
    • Twitterで誰かがこのやり方をオススメしているのを見かけた
  • これまで
    • 検索した内容をブラウザのタブで残しっぱなし
    • タブが無限に増えていく
  • やり方
    • ある程度調べたらNotionにその内容をまとめて、タブはリンクを貼っておく
  • メモに残してみて
    • ブラウザがスッキリした
    • メモが増えていくと嬉しい
    • そのうち記事にしたい

岡田

  • 最近のオープンソースLLMを調べる (参考)
    • Google Colab 無料枠でどこまで使えるのか (メモリ: 12.7GB)
      • rinna 3.6B はGPUで利用可能 (参考)
      • Cyber Agent OpenCALM-7B はクラッシュ

      → 3.6Bくらいが無料枠の限界っぽい

      4bit量子化すれば動くかも

    • パラメータ数 (参考)
      • rinna 36億 (英語を含めたバイリンガルは40億)
      • サイバーエージェント 70億
      • NEC 36億/70億/130億(非公開)
      • GPT-3.5(OpenAI, Microsoft) 1,750億
      • GPT-4 5,000億(1,000B/1,000億とも言われている)
      • Japanese StableLM Base Alpha 7B(Stability AI) 70億
      • Llama2(Meta) 70億/130億/700億
      • 国立研究開発法人情報通信研究機構(NICT) 400億(非公開)
      • Weblab-10B(東大松尾研究室, バイリンガル) 100億(商用不可)
      • PaLM(Google) 5400億
      • PaLM2 3400億(噂)
      • QwenLM-7B(Alibaba) 70億

      ※ 非公開=API提供なし、オープンソースでの提供なし

      中国企業AmazonAppleが今後どうするか

    • 性能比較
    • Rinna × LangChain, Rinnaのファインチューニング を試したい
    • text-generation-webui は使えると多くの人に使ってもらいやすそう
    • 余談:Koeiromap 楽しい (参考)
  • 「文章生成AI利活用ガイドライン」の策定についてhttps://www.digitalservice.metro.tokyo.lg.jp/ict/pdf/ai_guideline.pdf
    文章生成AIは外部サービスに該当し、セキュリティ対策はサービス提供者に依存することから、機密情報や未公開情報を入力すると、万が一の場合、情報漏えいにつながるリスクが残ります。セキュリティを信じつつも、万が一を考えて、機密情報は使わないA:秘密文書に相当する、高い機密性を要する情報資産 B:秘密文書に相当しないが、直ちに一般に公表する ことを前提としていない情報資産 C:機密性A又は機密性B以外の情報資産B,Cまでなら良いが、Aはダメ既存の著作物に類似する文章の生成(※2)につながるようなプロンプトを入力しないこと(※2)「作家○○の作品△△に似せて文章を生成してください」とプロンプトに入力する 場合や、著作物をそのままプロンプトに入力し、当該著作物に類似した文章を生成 させる場合 等 ただ、「単に他人の既存著作物、作家名、作品の名称を入力するだけの行為は、必ずしも直ちに著作権侵害に該当するとは限りません。」とも書いてある

    「誰々みたいに書いて」はダメらしい

    文章生成AIの回答を対外的にそのまま使用する場合は、その旨明記

    原文は生成AI,編集は人間の場合、記載義務はあるのか?

    生成AI画像は「二次的著作物」と日本写真家協会「出典の明記を

    利用者アンケート

    1日当たり短縮時間は40%が「ほとんど短縮されていない」と答えた

    対して、文章生成AIを今後利用したいか?という質問に80%が「利用したい」と答えた

    → 需要はあるが、実益を得られていない状況

  • Next: AIエージェント沼にハマるためにこの辺を見ておけば良いと思われるリソースまとめ

西村

  • INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント 読んだ
    • アイデアを市場投入するまで遅い(リスクが最後にくる)
      • ビジネスケース・ロードマップ作成は意味ない
    • エンジニアが開発部隊になってる
      • 全体で見るとウォーターフォール
      • 開発だけアジャイルとかスクラムで効率化製品開発が失敗する根本的原因
    • 継続的な製品発見と市場投入こそ正義
      • リスクは最初に取り組む
        • 顧客が購入するか?(使ってくれるか?)
        • エンジニアが必要なものを作れるか?
        • 事業実現可能か?(コンプラとかマーケ的に)
        • ステークホルダーの合意とれるか?
      • 製品の定義づけとデザインは順を追ってではなく、協調させながら同時に実行する
        • デザイン決め→実装では遅い(当たるかどうかもわからない)
        • やりながら決めてけ

今週の報告は以上です。
週毎に取り組みを掲載していきますので、ご期待下さいませ。