00:04
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが赤坂より、開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の辰巳と、賑やかし役の辰巳です。よろしくお願いします。
さて、今回はちょっと多そうなので、早速いってしまいます。今回のタイトル、この要件定義書に突っ込みを入れろパート2というところで、前回、架空の会社さん、架空の開発会社さんが作ってきた要件定義書、GPT作成なんですが、
それで、ここはどうなんだろうというところを、島田さん、辰巳さん含め、突っ込んでいくという会になっておりまして、概要欄にリンクもしくは文書が載っていると思いますので、ぜひそれを見ながら一緒に突っ込んでいっていただければというところで、早速、内容を続きにいきたいと思います。
ユーザー管理に関する議論
4番目の機能要件、概要ですね。実際の機能というところになると思うんですが、突っ込みどころがなかなかありそうです。4.1、ユーザー管理の1、ユーザー登録。パスワードは英数字8文字以上とする。パスワードポリシーの詳細は別途セキュリティポリシーに従う。というところで、ここを突っ込みどころというところですが。
どっちですかっていう。英数字8文字以上とするのに、セキュリティポリシーに従う。セキュリティポリシーがそもそも何?
これ別途書いてないですもんね。
とは、セキュリティポリシーって何やねんっていうところですかね。
とは。
英数字8文字以上にするだけだったら全然問題ないと思うんですよね。
もっと言ったら一番重要なのは、お客さんとここを握り必要があるっていうところ。
あと、この時点でそこまでガチガチに決めなくていいんじゃないかとは逆に思いますね。
そうですね。
使ってみてお客さんはちょっと8文字以上で英数字絡めるのめんどくさいわって言われる可能性が高い気がしますね。
ここら辺島田さんどうですか?
そうっすね。別に8文字でも10文字でもあんまりやることに変わらないので、それによって見積みが変わったりすることもないし。
ただ、英数字8文字ってのはちょっと弱いかなと。記号も含めないし、ちょっと弱いかなって気がしますけどね。
やるならちゃんとやりたいんですよ。中途半端ですよね。
あれですよね。あと大文字小文字とかありますしね。
そうそうそう。
記号は何を許容するかとか。
そこら辺がセキュリティポリシーで後ほど決めるってことなんですかね。
後ほど決めるんでも別にいいと思うんだよね。
今ここで明確に書かなくていいんじゃない。
なるほど。では、これは次にいっちゃっていいかなと思います。
ログイン状態の設定
2のログイン。ログイン状態は原則として無期限で保持する。
一方でセキュリティ上30分以上操作がない場合は自動ログアウトすると。
順案件ですね。
なるほど。
多分思うところとしては操作をしている限りではログイン状態を保持したい。
要はスマホアプリみたいな感じにしたいんじゃないか。
これ操作がない場合自動ログアウトする。操作していても30分以上でログアウトしちゃうようなことがあるんだろうか。
30分間操作しないんだったらそれは結構何も操作していない実感が長い気がしますね。
5分とかあったらまだわかるんですけど。
ここもパスワードと同じ話で今これを決めきる必要も特にないんじゃないか。
そうですよね。私なんだろうな。PCとかデフォルトだと大体15分いじってないとそもそもスリープになったりとか。
そうですね。スクリーンセーバーだったりとかね。
ここら辺も今はいいんじゃないかの案件とかどっちなの案件って感じですかね。
ログアウトするっていう意味がちょっとよくわからないところもあるんだけど。
ログアウトしたらまたアカウントとパスワードを入れないと入れないのか。
そこをちょっと明確にしておくべきかなと思いますよね。
明示的にログアウトしたらまたアカウントとパスワードを入れなきゃいけないっていうのが普通なのかな。
それをやらない限りはずっとログインできると。
ブラウザを閉じてもまた開けばまた入った状態で復活できるようにするっていうのがこの上の方。
ログイン状態は原則として無期限で保持というのはそういうことなのかな。
ログアウトしない限りはずっと入れると。
下の方はここに隠れた一行が本当はあってログアウトするとセッション切れてもう一回ログイン画面に飛ばされるっていう要件が本当は隠れていて、
それと同じ状態が一方での文章で実現されると。
すごく業間を読むとそういうことなのかなって思うけど。
そういうことならしっかりそこまで書く必要がある。
あと30分は長い。
やっぱり5分とか10分とか放置されている状態を防ぐのであればそうしないといけないかなっていう気もしないでもないけど。
どうなんだろうね、放置。わからないね。スマホとかに放置っていう話になるからね。
では次行っちゃいますか。
3番目簡易登録。メールアドレス認証を行わない簡易登録モードも用意すると。
こんなことできるんですかね。
登録本は絶対分けないほうがいいですね。
あとここビックリマークついてないですけどログインのところで登録済みメールアドレスとパスワードでログインできるって書いてあるんで。
じゃあメールアドレスの認証を使わない簡易登録モードなんで存在しちゃったらどうやってその人ログインするんですかって話になるんですね。
メールアドレスを入力しなきゃいけないってなるんだったらそこメールアドレスがないとログインできない。
要は弾いてるのにメールアドレスがない状態で入れちゃってるってちょっと矛盾しちゃうなっていう。
目的が知りたいですね。デモ的に使うのであれば簡易なデフォルトのメールアドレスとか入れたら入れますよみたいなのを用意すればいいのかなと思いつつ。
最初のときに簡易登録モードみたいなのは分けなくて、フローとして最初はメールアドレスを使わないで簡易登録、要は仮登録ができるっていう話だったら全然いいと思うんですよ。
多分そういうことだと思うけどね。
それが分かりにくすぎるっていう話だと思いますよ。
メールアドレスに対してよくあるよね、リンク送られてきてそれを踏まないといけないとか。
それをやらなくてもとりあえずは入れるというふうにしておいて、でも何か重大なことをやろうとするとそれ踏んでないんでできませんみたいなね。
ああ、はいはいはい。
いうことはあり得るけども、結局メールアドレス認証やってないと適当なアドレスでも進められちゃうんで、それはどうなのかなって気がするけどね。
なるほど、ありがとうございます。
次行っちゃってよいですかね。
4.2のプログラム・セッション。
プログラム一覧では以下を表示するプログラム名、所要時間、レベル、料金。
詳細画面では概要と各セッション対象を表示するというところで、そのセッションの具体的な内容や時間配分はリリース直前にコーチ側で調整する。
一見悪くなさそうにも聞こえるんですけどね。
あり得るっちゃあり得る気が。
これはいいんじゃないの?
なんかあり得そう。
あり得そう。
強いて言えば、必ずセッションを開始する前にはコーチが見ないといけないっていうのであれば、未確認状態なのか確認したのか、そのフラグを立てておいて、立ってないと始められないみたいなね。
こういう風にしといた方がいいのかもしれないけど。
そうですね、ワークフロー的に順番になってて、これができたらプログラムとして機能するみたいな風にしておけば。
あり得るかなと思いますね。
では、次行っちゃいますか。
初めて突っ込まないやつが。
これはいいんじゃない?
これはいいんじゃない?
こういうのあっていいんじゃないですか。
予約フローと決済について
では次、4.3予約決済。
予約フローが書いてありますね。
ユーザーがコーチを選択。
カレンダーからアキュアクを選択。
決済画面へ遷移。
予約完了メール送信。
予約時間にビデオ通話画面から参加。
ビデオ通話基盤。
Zoom独自。
その他はコストと品質を見て後日決定する。
これは全部見積もり出してこいって言われそうですね。
それもそうですし、今決めろやっていうところですね。
限定義のタイミングで決まってないのはかなりリスキーですね。
コストと品質を見て。
品質はまた何を持ってって感じですかね。
HPKのメニューが豊富なのかそういう話なのかわからないですけど。
これはでもこういうふうに言われたらどうするものですか。
ポックとか作るみたいな感じになっちゃうんですかね。
なかなか厳しいですね。
でもサンプル作るしかないですかね。
その時のポックを独自とかで作ってみるっていうのは
それこそ今だったらAIに関連的なものを作らせてみるみたいなのがあるかもしれないですね。
結局これは要件固まりきってないってことですね。
そうですね。これ決めてもらわないとスタートできない。
後から覆されることがあるんで。
予約がすごく簡単に書いてあるんだけど
コマを予約したいって言ってから
実際に決済が完了するまでに他の人もやってるかもしれないんでね。
決済プロセスの課題
だからダブルブッキングならないような仕組みっていうのは結構必要で。
結構大変そうですよね。
あるいは決済画面まで行ったんだけど
そこで放置しちゃうユーザーもいるんで
いつまでその人がその枠を抑えてられるのかっていうタイムアウトの問題とか
それも考えないといけないので非常に難しいんでね。
確かにユーザーから考えれば別になんてことなく
例えばECサイトとかですけどやってますけど
とりあえず突っ込んでおくとか
システム上やっぱり細かく決まってないと
そもそもできないってところですもんね。
映画館の予約なんかもそうだけど
ちゃんと席を押さえて決済に行って
いざ正式に登録しようとすると
もう取られてますみたいなことがあったりすると思うんだよね。
そのために確かレースを20分とか15分とかの
有用期間とか設けてその期間はもう仮で抑えて予約できる。
そうそうそうね。
なるほど。では次行っちゃいますか。
これあれですね。
2番の対象範囲の決済でクレジットカード銀行振り込みを画面のみとありましたが
ここの詳細っぽいことが書いてある決済というところです。
クレジットカードに対応銀行振り込みは本フェーズでは
管理画面上で入金済みフラグを手動更新する想定
決済代行サービスA社を利用予定ながら正式選定はリリース直前に行う
PCI DSS準拠が望ましいが必須ではないということらしいですね。
一部良さそうに見えるけれども大枠フワフワだなという感じですかね。
管理画面上で入金済みフラグを手動更新する想定
これ前回話したこととそのまま問題が解決できてないんだけど
結局誰がこのお金を振り込んできたのか何のお金なのかがわからないんだよね。
ということが起きるので消し込みにも難しかったです。
お客さんによっては勝手に振り込み手数をマイナスして振り込んできたりするので
そういうことされるとどうしていいかわからないことになるので。
では次行っちゃいますか。
データ保管とレポート機能
4.4 チェックイン機能 ユーザー1日1回コンディションを入力できるほう
眠気・集中度
入力内容は最低3年間保管
保管データの削除・ポリシーや利用目的の詳細を今後整理する
とりあえずデータを集めておきたい。3年間保管したい。
いいんじゃないですか。
これも3年間分保持して。
サービスが停止しない限りはね。
むしろ消さない限り永遠に残ると思うんだけど。
ローテーション的な感じで消していく。
ここは良いでしょうというところで
4.5 レポート 人事向け
企業単位で社員の受講状況を一覧表示
詳細な回答内容やコメントを閲覧できるようにすることで
きめ細やかなフォローを可能にする
きめ細やかなフォローが何なのか分からないですけど
そんなにおかしなことは言ってない気がするような気がしますけど
レポートのイメージは欲しいところですよね。初めの前にね。
なるほど。ここも良いかなというところですかね。
そんなにヤバくないですね。後半調子を取り戻していきます。
非機能要件の重要性
では5. 非機能要件 概要というところで
これは前回ちょっと話ありましたが
辰巳さん 非機能要件について教えていただいてもよろしいでしょうか。
要はですけど データを登録するときに何秒かかるとか
ページを表示するために何秒かかるとか
どれくらいのユーザー数に耐えられるサーバーの構築をしているかとか
というようなものをシステムだけでは分からない裏側の話
側だけではない裏側の話が大体非機能要件というふうに考えていただいて
差し支えないと思いますね。
なるほど。ありがとうございます。ここら辺が
5.1性能を5.2回応
そのようなことを書いている気がしますね。
5.3セキュリティと
ここら辺ヤバいですね。
ヤバいこと書いてますね。
画面起動を減速0.1秒以内
無理でしょ。まばたきするより早いですよ。
0.1秒以内
安倍博士のプロフィールサイト並みの速さ
これは極力早くしてほしいってことなんでしょうかね。
普通は2秒とか4秒とか
複雑な表示要件のページは覗くとか
そういうのが一般的だよね。
正確に言ってしまえば画面ごとによって違うと思いますし
それこそレポートとかどうしても時間かかると思いますし
それはそうだよね。
さっきの話で言うと
シンプルに画面を表示するだけなのか
リクエストを送って
それが何かデータを作成とか削除するときの
秒数って絶対変わると思うんですよ。
そこら辺の話。
なるほど。
では次、ピーク時同時アクセス100ユーザー程度を想定
逆にこれは楽勝すぎますね。
たぶん次につながっている
将来的にユーザー数が増加してもできるだけインフラ除去を行わず対応したいと
それはできるんですか?
やろうと思えばできますね。
オートスケーリングってやつ
AWSとかそういうクラウドはあるんで
ただ最初のときは100人ぐらいだったら
結構そんなデカいサーバー使わなくていいですけれども
将来的に増えてもそれを考慮したくないのであれば
オートスケーリングを入れておく必要があるみたいな感じだと思います。
結構難しい話ですけどね。
なるほど。
このピーク時同時アクセス
自分もこんなところに突っ込みはしないけども
実際は難しいところもあって
100人同時に使うのはいいとして
例えばレポートの機能を表示するのに10秒かかると
あちこちからデータを集めてきて表示するので10秒かかるというときに
その10秒の集計処理を100人同時にやられると
結構落ちるんじゃないかって思うんだよね。
ものによります。
ものによるんだよね。
なんかにみんなで一斉にログインするぐらいだったら全然
ログインして使う分はいいんだけど
実践のせいで
F5行為じゃないけどそういうことを減られると落ちるかもしれない。
重い処理をやられると困る。
重い処理を同時にやられると
そこは一時突っ込まないけどね。
この段階で。
なるほど。では次いきます。
5.2
これを可用性でいいんですかね。
年間稼働率99.9%を目標
ただし障害時の復旧時間運用体制の詳細は
ホームフェーズに対象外とする
対象外としていいんですかね。
いやダメだと思います。
ちゃんと障害時の運用体制
あらかじめ考えておく必要があります。
ある程度社内で決まってるっていうのはあると思うんですけど
あとは99.9%
よく年間稼働率SLAとかSLOとか言うんですけど
ちなみにAWSとかのSLA、SLOが
大体この99.9%ぐらいなんで
相当やばい数字だと思います。
365日でほぼ1日も
障害が起きないぐらいのレベルなんです。
もうちょいか。365日中363日ぐらいか。
障害が起きない。
こんなに優秀な運用ができるんだったらすごいですけど
大分大見栄を切ってるかなっていう印象です。
これは圧をかけてきたいだけなのかな
みたいな気もしてますけど
しかも目標を言ってますからね。
大丈夫かなっていう。
まあ保証じゃないので
ここはどうなのかな。
そうですね。目的と保証は全然違うシーンです。
ただそこを自分の墓穴を掘るように
法で記載する意味は特にない気がします。
次行っちゃいますか。
5.3セキュリティ
一般的なウェブシステムとして
必要十分なセキュリティを確保すること
多様性認証は本フェーズ対障害とし
社会情勢を見て柔軟に検討すると。
ふわふわですね。
さっきの厳密性と比較したら一気に落ちましたね。
非機能要件ってこんな感じになりやすいんですか。
平均的に合格点を出したいんですよ。
現実的なところとしては。
ただすごく数学100点取ってるけど
国語と英語が30点みたいなことを書いてる気がするんですよね。
みんな80点ぐらい取ればいいんですけど。
そこがちょっとずれてる感じがしますね。
島田さんいかがでしょう。
こんな早けたになるのは普通かなと思うんだよね。
細かく書いてもお客さんにも理解できないし。
わかんないですね。
これやめましょうかって言ったって
お役さんもまた理解できないので
必要十分なセキュリティとしか言いようがないと思うんだよね。
多様性認証は対障害なんだ。
それも一つの判断だよね。
めんどくさいからね。うざいからね。ユーザーにとってはね。
人によってはそんなことよりも素早く
要件定義の重要性
ジムとか行って使いたいんですぐ開けるのが大事だったりするのに
要素認証とかやってればいいんだよっていうことがあったりするので
それは社会情勢っていうかどうかわかんないけど
ユーザーの反応を見ながら決めていけばいいと思うんだよね。
企業とかこのシステム自体のどのくらい使われてるかとか
そこら辺も関わってきそうですもんね。
少なくとも立ち上げのときはそんなにガチガチに考えなくていいと思いますね。
ではちょっと長くなってしまっていますが
最後6運用その他まで行っちゃいましょうか。
6.1運用時間システム報酬対応時間は平日9時18時
深夜帯に発生した障害は翌営業日に対応する
お客さんとこれが握れてるんだったら特に問題ない
では6.2データ移行既存システムは存在しない想定のため
基本的にデータ移行は不要とする
ただし現状Excelで管理しているユーザーデータがあるため
可能であれば一括取り込み機能を実装する
フォーマットを基本設計で決定
こういうやり方でやっても低コストなんでいいと思いますけど
旧システムから一括そのまま新しいのに移管さえしてしまったら
一括取り込み機能は別になくてもいいかなと思いますね
あっても損はしないと思いますけど
いらないよね。一回だけでいいんだよね。
いらないと思います。一括取り込み機能がいらない
最初の一回だけやれるんで一括取り込み機能なんていらないですよ
一回目だけ立ち上げのときだけうちのほうで裏から入れるんで
あとはメンテ画面でメンテしていくと
いうことでいいんじゃないですかね
あとはこれで終わりですね
いろいろ突っ込んでみましたがどうでした辰巳さん
改善余地はあるもののこれAIが作ってきたって
マジでびっくりすると思いますね
しかもこれ収録用にかなり削りに削ってるんで
そういった意味でも整合性が出なかったりした部分があったと思うんですけど
じゃあフルでもちゃんと本番のガチガチのものを作ってこいって言ったら
突っ込みどころも残さず本当に精緻なものを作ってくるんで
あくまでも今日はエンタメだったっていうことは皆さんご認識いただければなって
曖昧さへの注意
実はAI会だったって話ですかね
島田さんどうでした
そうですねAIはすごいなっていうのは確かにそういうことですね
基本的にそもそも要件定義って何のために作るかっていうと
見積もりとセットで使うもので
基本的には初めにお客さんが要求を出して要求しようみたいなのを出して
開発会社の方がこの要件定義書と見積もり書をセットで出すと
最終的に納品した時にちゃんと要件定義の内容が実現できてるのかっていうのを
納品の受入れテストのチェックリストにして使うみたいな
そんな使い方になるんで
だから曖昧なところってのは開発会社としてはすごい嫌なんでね
どうぞでも取れるみたいなね
そういうところは突っ込まざるを得ないというか
これやばいなっていう嗅覚が働いてしまうところありますね
この注釈自体もAIが出してきてるわけで
やっぱりこの曖昧なところ結局どっちなのっていうところが多く
要件定義の突っ込みどころって基本的にこういうところになるのかなというところで
やっぱりそういうところを逃さず
これってどうなんですかっていうところを突っ込んでいく
かつ切っこすぎないと言いますか
ここら辺はあんまり言っても伝わらないだろうなっていうところの影も見つつ
お客さんと一緒に進めていくみたいなのが大事なのかなということと
あとAIはすごいなという結論かなというところでしょうか
そんな感じで今回はもう閉めちゃってよいですかね
長くなってしまいましたが
本日はいかがでしたでしょうか
楽しんでいただけましたらフォローや評価をお願いします
またXでも最新情報を随時発信していますのでよろしくお願いします
システム開発に関するご相談がございましたら
公式ホームページからお気軽にお問い合わせください
それではまた次回お会いしましょう
ありがとうございました
