# 議事録(team sumoto)

## 第7回

### 1.タイムボックス
19:40まで

### 2.本日のゴール
- 中間発表までの計画を立てる
- ニーズの確認までの計画

### 3. 計画
- 05/31
- 顧客インタビュー持ち寄り検討
- ユーザーストーリー・解決したい問題の決定
- 06/07
- 実現する機能の具体化
- 実現可能性の検討
- 解決したい問題への策の検討
- 06/14
- 発表内容の確認・検討
- 06/21
- 中間発表

#### 課題の検討（360°Lightning Talk）
- ビジネス：
- アプリケーションとして作成
- 基本使用料は取らず、広告収入で利益を得る
- 無料だとユーザーからの信頼が薄いのでは？
- オープンソースにする
- ユーザー：
- 若者をメイン顧客に据える
- 全年齢対象でもいいのでは？
- 端末は？（スマホ/PC/タブレット）
- テクノロジー：
- セキュリティ問題
- Webサービスorアプリケーションorブラウザの拡張
- パスワードデータをどこで管理するか（クライアントorクラウド）

#### ニーズはあるか
- IDとパスワードで登録・ログインするサービスが非常に増えている
- 全てのパスワードを覚えるのは困難
- 同じパスワードの設定の温床になる
- セキュリティリスクが高い
- 競合サービスは？
- [1PassWord](https://1password.com/jp/)
- Google Chrome, Edge, Safariなどのブラウザ
- iOSのキーチェーン

#### 顧客インタビュー
- Google Chrome
- 何でもかんでもGoogleに頼りすぎるのは怖い
- 一度設定してしまうと他人でもパスワードを使えてしまうのが怖い

## 第8回

### 今日やること
- ニーズを何をもって確認できたとするか
- ユーザーの対象を絞り込む
- (例)：複数人でパスワードを共有するモードと個人のパスワードを管理するモードがある。組織内での用途
- https://www.itmedia.co.jp/news/articles/1807/12/news116.html

- 使う人は何に不満があるのか
- マスターパスワードの存在
- 特定のネットワークに接続したら、マスターパスワード無しで使える機能
- 対象：組織、企業
- マジックリンク
- 使わない人はなぜ使わないのか

- アンケートをslackで取る
- 使っているかどうか
- 使っている人は不満があるか？
- 不満がある人はどんな不満があるか（任意でリプライしてもらう）
- 使ってない人はパスワードが管理出来たら便利だと思うか？
- 便利だと思うのに使わないのはなぜか(任意でリプライしてもらう)

## 第9回
- 先生方へのインタビュー
- パスワード管理アプリ使っているか？
- IBMでは1Passwordが"使える"(任意)
- 皆さん↑あまり使ってない
- ブラウザのパスワード管理機能は使っている
- 使うならどのような場面(where, what, when)で使うか？
- 重要度で管理する場所を分けている
- 改善してほしい点はあるか？
- 新たに欲しい機能はあるか？
- ブラウザと変わらないUI
- 重要度によってマスターキーをセットする
- マスターキーなしで使えるパスワード管理アプリが有ったら使うか？
- ブラウザの機能を使っている理由は？
- 1Passwordの使い方が分からない
- ユーザーインターフェースがブラウザと変わらなければ…(これだけなら変わらない)
- ブラウザで困ってない人もいれば、パスワードを入れるのがめんどうな人も
- 使い始めの抵抗が小さい
- 2段階認証はめんどくさいけど使ってる

- まとめ
- まとまった機能案
- ブラウザの拡張機能のようなイメージで登録しやすいツール
- 用途や重要度ごとにカテゴライズできるツール
- カテゴリごとにマスターキーを掛ける掛けないの選択ができるツール

- **次回議論すること(TODO)**
- 実現するために問題となる点を洗い出す
- 技術的に可能か？など
- 実現可能性の検討
- 中間発表に向けての準備
- スライドや何を話すかなど、決める

#### 議論
吹っ飛んでもいいやつ、盗まれてもいいやつしかパスワード管理ツールに入れない
更新頻度が高いor低い
リセットがすぐできた方がいいor悪い
登録が簡単or難しい
重要度で分ける(nPassward？)3、4段階とか
仕事(めっちゃ重要)orプライベート(ある程度漏れてもいい)
どうでもいいパスワードは忘れて登録しなおしたり、再登録強制なら数字増やすだけとかしてしまう
循環キー

- 4Password構想

||仕事|プライベート|
|--|--|--|
|重要なもの|||
|重要でないもの|||

# 第10回
### 何のプラットフォームで作るか
- ブラウザの拡張

- 機能
- アカウント作成時とログイン時に発動する
- パスワードとユーザID、URLを登録する、フォルダでカテゴリ分け
- フォルダに保存する
- フォルダを新規作成する
- フォルダの階層化（余力有れば）
- 登録したパスワードを使う
- URLに合ったデータを自動入力する（ON/OFF切り替え）
- パスワードがかかっているフォルダならマスターキーを要求

- 見た目・UI
- Figmaで作る
- https://www.figma.com/files/recent?fuid=986208545286285298

### 中間発表スライド(ニーズの確認)
- スライドの構成
- 既存のパスワード管理ツールについて
- 既存ツールの欠点
- 使ってる人がどんな欠点を感じているか聞く？
- 多くの人はパスワード管理をどうしているか
- ニーズ：「アカウントのカテゴリ分け」
- 具体的な機能について

教授にアンケートを取ってニーズを見つけた的なことをどこかに書く

- 使用するツール
- googleスライド
- 共同作業できるので

# 第11回
### 中間発表
#### 頂いた意見
- マスターキーや登録の手間などの煩雑さをなくすというニーズのはずが、カテゴリ分けという新たな煩雑さが加わっていないか
- 【カテゴリ分けの心理的コストについて】
確かにカテゴリ分けは心理的コストを増やしてしまう面があると感じました。
元々新たなニーズとして「カテゴリ分け」と「マスターキーの入力の省略等による心理的コストの引き下げ」を考えていましたが、カテゴリ分けは逆に心理的コストを増やしてしまうかもしれません。これらをどう両立すべきかは今後の課題です。(sumoto)

- パスワードは家だと物理的な手帳とかに記載してるが、使う側としては記録の手間が非常に気になりますよね！
- 心理的コストを減らす拡張機能の開発って面白いですね
- パスワードの保存場所はPC内部ですか？Google Chromeや1passwordはそのアカウントに保存されたパスワードが紐付いてると思うのですが、新規のパスワード保存拡張機能はどのようになってますか？
- 技術的に実現可能な範囲で検討するつもりだが、アカウントに紐付いたパスワードに関してカテゴリ分けをするつもり(shirotake)
- カテゴリ管理が面倒になって結局同じやつにたくさん入ってるとか、全部マスターキーの必要な方に入れちゃいそうです。
- インタビューの時は言わなかったけど、パスワード入力はやめたい。生体認証とか、スマホ認証の連携とか、マイナンバーカードで認証できるとか。
- 【生体認証について】
生体認証については何度か議題に上がりましたが、誤判定が少なくない(多いのが、本来通すべき人を誤って通さない)のと、怪我等で使えなくなる恐れがある(指の怪我で指紋認証が使えない等)ので、それだけに頼ることはできないと結論付けていました。
しかし、生体認証を組み込んで、失敗したらマスターキー入力という形にするのは、マスターキー入力の解消と安全性という観点からありだと感じました。(sumoto)

- 【その他スマホ認証・マイナンバーカードによる認証について】
マイナンバーカードによる認証は、スマートウォッチと同様のことが言えると思います。スマホはある程度普及しているので、スマホ認証に関しては検討すべき事柄だと思いました。(sumoto)

- 生体認証は想定しているんでしょうか。また、appleWatchを持っていたら、それでパスワード入力いらなくなるとかあると思うのですが、そういうのまで検討ってしたのでしょうか？
- 想定したが、精度の問題やプライバシー的な観点から導入を断念した。(shirotake)
- 【スマートウォッチによる認証について】
AppleWatch等のスマートウォッチによる認証は確かに検討していませんでした。しかし、スマートウォッチはあまり一般的に普及しておらず、持っていない人も多いという問題があります。PCやスマホだけで完結するという点である程度ニーズは満たせていると考えています。
ただ、生体認証のように、使える人は使えるようにするのはありなのかなとも思いました。(sumoto)

# 第12回
### カテゴリ分けについて
- 心理的コストなるのでは？
- マスターキーを掛けるor掛けないの2択
- 掛けるならどのマスターキーにするか選択？（セキュリティ面の考慮）

- 初期状態では二つのカテゴリ（掛ける, 掛けない）を用意
- ユーザーの任意でカテゴリを増やせる機能

- 機能について
- パスワード閲覧
- 拡張機能のアイコンをクリックするとカテゴリが見れる
- カテゴリをクリックすると、そのカテゴリのパスワードの一覧が見れる
- マスターキーが設定されている場合はそれを要求してから閲覧可能
- 閲覧できるデータ（url, ユーザー名, パスワード）
- データを選択し、カテゴリの移動処理が可能
- パスワード登録
1. ログイン時にポップアップを表示させる
- inputタグのtypeがpasswordの物がある場合表示する
- inputのtype=passwordの物をパスワード欄に,type!=passwordの物をユーザー名に
- ページのurlも拾う必要あり
- プルダウンからカテゴリの選択（デフォルトではマスターキー無しのカテゴリが選択）
- はい、いいえを選択させる（いいえの場合はポップアップを閉じるだけで終了）
2. はいを選択したとき
- ローカルストレージ
- keyとvalueを保存するJSONに保存
- keyがカテゴリ, valueがカテゴリ内のデータ配列{url, userName, password}
- JSONの形式（仮）
[
{"カテゴリ名":マスターキー,[(カテゴリ内のデータ一覧)]},
{"デフォルトカテゴリ":null,[{"url1","name1","pass1"},{"url2","name2",pass2},]},
]
- カテゴリの選択・生成
- プルダウンからカテゴリの選択（デフォルトではマスターキー無しのカテゴリが選択）
- プルダウンをクリックすると現状のカテゴリの一覧が表示
- プルダウン横のボタン(+)で新規作成
- パスワード使用
1. urlが変わるたびにストレージのデータと一致するか判定
2. データの入力等
2.1 一致した物がマスターキー無しのカテゴリのデータの場合
- そのデータを直接入力
2.2 一致したものがマスターキー有りのカテゴリのデータの場合
- ポップアップを表示し、マスターキーを要求
- 合致すればデータを入力
2.3 複数個ヒットした場合
2.3.1 マスターキーの無い物が含まれている場合
- そのデータを直接入力
- アカウントを切り替えるボタンで、他のデータと切り替える
2.3.2 マスターキーのある物のみの場合
- ポップアップを表示し、マスターキーを要求
- 合致すればデータを入力

# 第13回
## そもそもの最終発表の目的
- 最終発表では、ソリューションのアイディアがすべて完成している必要はありませんが、ソリューションの主要なシナリオの実現可能性を講師や他チームに納得させることを目指して下さい。

## やること
- 7/5(今日)
- 7/12(来週)
- 7/19(最終発表本番)

## 実現可能性とは？
- 作れるかどうか
- 有用性な物を技術面、体制面、資金面などの点を考えて、どうなのか

## 実現可能性を示すためには
- 実物を作る
- イメージを作る
- 設計書を作る（画面遷移図・）
- 保護方法（セキュリティのガード範囲・安全な理由や仕組み）
- 現状作成しているのは要件や要求
- これを詰めていくのも一つ
- 作ろうとしたものの認識がメンバー間でズレてないか

## セキュリティについて
- ローカルで保存
- データ保護方法
- データを暗号化してから保存

- マスターキーが必要な場合
- ユーザーにマスターキーを入力してもらう
- マスターキーを暗号化(ハッシュ化)して、ローカルにある暗号化(ハッシュ化)された正解のマスターキーと一致しているかどうかをチェック
- 一致してたら、マスターキー(平文)を鍵として、ローカルに保存されている暗号化された状態のパスワードを復号化してユーザーに渡す

- マスターキーを使わない場合
- 内部で適当なデフォルトのマスターキーを決めて置き、それを鍵とする
- マスターキーを定めていないのだからこれくらいの強度でええやろ！
- 実際の使用画面からdevTool使って覗いたほうが早い

## 利益の出し方（ビジネスとしての有用性）について
- 無料or有料
- 1PassWordとの違いとして無料でできることを挙げていた
- 無料とすると他の何かしらの方法でお金を取る必要あり
- 広告収入
- クラファン
- ~~闇商売~~
- そもそもChromeの拡張は全て無料
- https://kzstock.blogspot.com/2020/09/chromeextexpire20210201.html

## 発表に向けて
- 改めて有用かどうかリマインドする
- 中間発表の意見の取入れ
- 生体認証の使用可否
- カテゴリ管理の心理的コスト
- 画面遷移図を細かく作る
- セキュリティについてまとめる
- 利益の出し方とそれの根拠

## 来週（7/12）までに行う作業
- 画面遷移図
(例)↓
- パスワード登録時 (oki)
- パスワード使用時（usui）
- パスワードの保存・保護について
- マスターキーあり(sumoto)
- マスターキーなし(shirotake)
- [figma](https://www.figma.com/)で作る

## TODO
- 利益の出し方について議論する
- 発表の方針の検討
- 発表資料の作成分担の検討

# 第14回
## そもそもの最終発表の目的
- 最終発表では、ソリューションのアイディアがすべて完成している必要はありませんが、ソリューションの主要なシナリオの実現可能性を講師や他チームに納得させることを目指して下さい。

## 最終発表
スライド作成・発表担当：大木,臼井
- 改めて有用かどうかリマインドする("課題"欄をまとめる)　　// およそ3ページ　
- 下の "課題" 欄参照

- カテゴリ管理の心理的コスト　：有用化どうかリマインドのページで伝えたい
- カテゴリを選択しなければ自動的にデフォルトカテゴリに入れられる
- カテゴリ分けを必ずしもする必要はない
- カテゴリ分け（セキュリティの向上）と1カテゴリにまとめる（わずらわしさの解消）は両立しない、トレードオフ
- これをユーザーが自分なりにカスタマイズできるのが強み
- 生体認証の使用可否　：使わない！
- 「カテゴリ分け」「導入の心理的コスト」をニーズのメインに据えたときに実現可能性が低くなる
- セキュリティ上問題が発生する

---
スライド作成・発表担当：城武
- システム全体として必要な機能を説明⇒遷移図　　// 1～2ページ

#### 台本を作る(スライド作成者と発表者が違うため)
- 遷移図(or言葉)で具体的に説明　　// 各1～2ページ
- UI図（パスワード登録）
- UI図（パスワード処理）
- セキュリティについて
- データ復号の遷移図（マスターキーあり）
- データ復号の遷移図（マスターキーなし）
---
スライド・発表担当：須本
- まとめ　　// 1～2ページ

---
担当：臼井
- 付録　　// 任意ページ数
- 利益の出し方とそれの根拠（付録行き）
- 広告収入
- ユーザーに無駄な手間を取らせないような表示方法

## 課題
- 従来のとどう違うのか、優位性は何か
- 安全さと使いやすさの両立
- パスワードのカテゴリ分け
- カテゴリ分けによって1Passwordよりもセキュリティ面に優位性がある
- カテゴリによってマスターキー不要
- 煩わしさの解消、使用コストの低下
- 拡張機能として実装することで、導入の心理的コストを減らす
- アプリという形だと、便利だと分かっていても導入しようと思ってもらうのが難しい(なくても困らないから)
- すでにユーザーが利用しているパスワードはデフォルトのカテゴリに入れられる
- 最初にいちいちパスワードを登録する手間が省ける