開発現場の真実
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、賑やかし役の辰巳です。よろしくお願いいたします。
この収録日はクリスマスということで、クリスマスではあるんですが、実家の水道が壊れまして、イランプレゼントをもらったわけなんですけど、水道業者さんと作業しながらちょっと話したりとかあると思うんですけど、
その時に水回りのことをいろいろ聞いていたら、風呂出るときに冷水かけて出るとカビ出ませんよ、みたいなことを言われたので、へーと思ったんですけど、これ皆さん知ってるもんですか?
知らない。
聞いたことあるような気がしますけども、どっか頭の奥底に言わせる。
なんかいいらしいです。ちゃんと調べてみないと本当のことはわかんないですけど。
要は湿気と温度がカビの応症なんで、温度をまず下げようって話なんじゃないですか。
なるほど。こういうチップスとかあるといいよなって雑談のネタにもなっていいよなとか思って、なんかこれをこうしたらいいよみたいなのとかってあったりします?水回りとか。
水回りで言うと僕一人暮らしオンリーな話かもしれないですけど、普通皆さん公衆浴場とか行くと体洗ってから温泉入るじゃないですか。
一人暮らしだったら別にそこ気にしなくていいんで、入浴剤とか浴槽を使ってやりたいけれども、体洗いながらお風呂沸かしたりするの面倒だなって思う場合は、
先にお湯を沸かしてお風呂入る準備とか他のことをしながら、お湯溜まったら入浴剤入れてお風呂入って体温まって体洗うっていう順番もあり。
確かに戦闘とか、戦闘というかサウナとか行った時には結局温まった後の方がよく落ちるんで、最初迷惑かけないように洗って、風呂入って出る時にまた洗って出たりとかしますからね結局。
なので一人で暮らす分にはもう全然そっちの方がコスパが良い。時短にもなるんで。
なるほど。
っていう話です。
とはいえ、先週かな、先々週だったか、辰巳さんたまに風呂入らないみたいな。
冬は2日に1回ぐらいしか入らないですね。これ何かこの工業電波で。
いらんこと言ってしまったかもしれませんというところを突っ込んでいただきましたが、というところで今回のタイトル。
この要件定義書に突っ込みを入れろ。おそらくパート1になるかなというところです。
架空の要件定義書を検討
これはですね、おそらく概要欄にリンクかもしくは直接入れてあると思うんですが、
とある開発会社さんが作ってきたであろうという架空の要件定義書を作成しまして、これについていろいろ突っ込みを入れていこうということで、
こういう要件定義書はこう見ようとか、こういうところ気をつけたらいいですよみたいなことをうっすら皆さんにご承知いただければみたいな感じですかね。
そうですね。作ってもらったのはチャッピーくんなんですけれども。
出た、チャッピーですね。チャッピーかGPT派かGPT派、いろんな派閥がありますがチャッピーくんが。
本当にプロが見てもパッと見遜色がない内容。
ただこの要件定義書に突っ込みを入れろというたてつけというかタイトルなので、
突っ込もうと思ってもどこを突っ込めばいいのかちょっとこの平文だけだとわからないんで、
突っ込みの頃を明示してもらうようにして、それでやっとわかるっていうレベルになります。
それでじゃあついて読んでみたら確かにそうだよねみたいなところがあるんで、ちょっとそれを今日読みながら。
承知しました。読み上げていくと時間かかりそうなので可能であれば皆さんもちょっと一緒に見ていただきながら、
主には島田さんの鋭い突っ込みを期待しつつ、上から読んでみますか。
読んでいきましょう。
最初オンラインメンタルトレーニングサービスの要件定義書ドラフトというところで、
お客様がおそらくいないである株式会社テックサンプルサマーDX推進室というところで、
これに依頼されて開発会社さん、これもかっこいいですがもちろんスマートDXプロ株式会社さんが作った
要件定義書というふうになっておりまして、まず1個目システム概要の突っ込みどころが書いてあるのが、
まず1.2システムの目的ですね。本システムはスポーツ選手及び一般利用者を対象に
オンライン上でメンタルトレーニングを提供し、ユーザーのモチベーションを最大化することを目的とすると。
ここの突っ込みはおそらくモチベーションというのは何というところですね。
そうですね。たぶんこれ次のやつとセットになってると思ってて、モチベーションの定義や測り方については別途検討する。
この時点で分かってない。
なるほど。
これが問題だと思う。ここら辺はたぶんシステムで計算してグラフとか数値化すると思うんですけど、
それがないのであればデザインの仕様もないし、要件の整理の仕様もないということだと思います。
これじゃあ後ほど出てくるってことですか。結局出てこないので、ここら辺はちゃんと決めていかないといけないよねってところは突っ込みどころってところですかね。
そうですね。ここはちゃんとクライアントさんにヒアリングをして、この段階で分かってないと後々突っ込みますよっていうことを知ってもらわないとダメだと思います。
確かにこういうのだとデータ化できないものをどう扱うかとか、これってどうするのかっていうのはなかなか最初にちゃんと決めていかないと絶対に詰まるというか、そもそも作れないというところですもんね。
クライアントさん側もこの業界に特化をもとからしてたところで、マニュアルでサービスをやってるんだったらいいんですけど、パッとこれを考え始めるとこういうこと起きがちだよねっていうのがそこまで読み取るんですね。
ちなみにですけど、ちょっとそこまで突っ込んでっていいのかわかんないですけど、モチベーションってどうやって測ります?
それがそもそもモチベーションって測れるんですかって話ですね。
そもそもモチベーションいりますかっていうところもあるんですけど。
なんでそこら辺を深掘りしだすとキリがないっていうところですね。
なるほど。こういうデータ化しづらいものに関しては、ちゃんとどうデータ化するかっていうのを詰める必要があるという突っ込みっていうことですね。
ここのところで、やっぱり要件提出って何のために作るのかっていうのがまずそもそもあって、これを満たしてないと検査不合格になるっていう話であれば、ここんとこは突っ込まざるを得ないよね。
要するにシステム一生懸命作ったけど、最後全然ユーザーのアンケート取ったらモチベーションアップできてないってなったら、ダメって受け入れられませんってなってしまったら、それは困ってしまうんで、開発会社としてはね。
そこはこういうことを目的にしたらいけないというか、これはあくまでも目的にするんだったら目的なんだけども、達成するかどうかは受け入れできるかどうかの判断に使わないみたいなふうなことを書いてくれないと、これは恐ろしい文章ですよ。
結構サラッと書いてますけどね。
なるほど。確かに要件というか、こちらでどうしようもない部分が含まれてますよね。
いろいろトレーナーの方の手腕とかも関係してくるので、価格設定もそうですしね。価格が高ければ全然やる気で起きないよって言うかもしれないし、この辺はシステム的にはどうしようもないところもあったりするんでね。
そう聞いていくとやっぱり曖昧なものが困るんだなというふうに思っていまして、今次の突っ込みどころが同じシステム概要の1.3背景の本サービスでは直感的でストレスのないUXを実現するっていうのもこれ同じようにかなり抽象的だなと。
全く同じような話ですよ。
直感的でストレスのないUXって何って話ですよね。どういったことをイメージしていってるのか。それは業界によっても違うかもしれないしっていうところですもんね。
本当そうだと思いますし、主観的すぎる。
データ化もできないし、要件と言えてないっていうところですかね。
そうですね。あとはここは要件だけじゃなくて非機能要件にも関わってくる部分なんで。これって要件なんで。機能要件がメインなんで。そこですよ。
システムの目的を探る
なるほど。わかりました。次行っても良いですかね。
はい。
では2、対象範囲っていうところで本システムで実現する機能対象外とありますが、ここの突っ込みどころが決済のところですかね。
クレジットカード、銀行振り込みは画面のみというところが突っ込みどころになってますが、これはどう見ます。
この日本語が意味わかんないですね。
わかんないねこれ。
これはどういうことなんだろう。
そこも含めて、意図的にチャッピー君が作ってるのはものすごいレベル高い話かなと思いますけど。
銀行振り込みは画面のみ。要はシステム内で完結させたいみたいな意味なのかなと思いました。
例えば証券会社とかで銀行振り込みというか口座に入金するときってAPIなんで銀行と別画面に飛ぶんですよね。銀行の制御。
そういうのを介さないで完結したいみたいな話だったら、それはとんでもなく難しいことなんで多分無理ですよって話ですね。
振り込み先が書いてあるだけっていう話じゃないのかな。
そういうことですか。
すごいですね。架空のものでも結構話せるっていう。こういうこと言ってんじゃないのっていう。
そういった意味でも僕と島田さんでこれだけ解釈が違うんでブレやすいですよねこの表現。
多分ね、銀行振り込みの振り込み先の口座が書いてあるんだけど、それが誰から振り込まれたかわかんないっていう問題がよくあるんだよね。
振り込みみんなやってくれるんだけど、振り込み元の口座の名前と申し込んだ人の名前が違うとか、付き合わせできないってあったりね。
クレジットカードの場合はその場で入れてもらえば必ずこの人ってわかるんだけど、銀行振り込みの場合はそれがわからないんだよね。
確かに。
なるほど。ちなみにこれちょっと次行っちゃうんですけど、2.2対象外で将来的にSSOやアプリに拡張できる設計とすることで、すいません、まずこれSSOって何ですかね。
シングルサインオンですか。
シングルサインオンですね。はいはい。なるほど。
何かというとめっちゃ簡単に言うと、一つのアカウントを使い回してログインができるよっていうような感じですね。
その中でLINEとかも一番含まれるみたいな感じです。
これは今のところ対象外になってるんだね。
対象外だけど将来的にはそうしたいよってことなのですかね。
なんで対象外に入れたのか。
基本的に要件提起書にやらないことは書かないっていう風にした方がいいんだよね。
そうしないとここに載ってないことはやるのかやらないのか分からなくなってしまうと。
やらないことの中に入ってないじゃんって言われるはずなんだよね。
やることしか書いてないと。そういう約束にしておいた方が要件提起書としてはいい。
そうですね。
ちゃんとやるんだったらフェーズ分けてとか書いてほしいところですね。
要件定義書の疑問
これはフェーズ2でやるみたいなね。それならいいんだけどね。
なるほど。ありがとうございます。
では、あと3番目の利用者までいったら今日はここまでというところにしますか。
将来的にSSOやアプリに拡張できる、卓上することっていうのもなかなか今何をやればいいのかってよく分かんないんだよね。
分かんないですね。もっと多分ブレークダウンして考えると、SSOって結構独立した機能なんで、別に今考えなくてもそんなに問題ないからとか思っちゃう。
そうなんだよ。やることになったときに何と連動するのかっていうのをちゃんと考えて、どうすべきかってその場で考えるべきなんだよね。
よくこういうことを拡張性を持たせておくことみたいなことを書いてあるんだけど、要件的にね。
拡張性とはない。
そう、今やることは何もないみたいなことがあるんだよね。
お客さんの心理としては分からなくはないですけどね。システムのことよく分かんないんで、とりあえず対応できるようにしといてってことで入れてるってことなんでしょうけど。
家作るときに庭に灯籠を作るみたいな話なんで、別にそれはそのときに考えればいいことだと思うんだよね。
分かりました。では3番目、利用者。
3.1、利用者種別。3.2、一般ユーザー。3.3、顧客企業の人事担当者。
ツッコミどころが3.2、一般ユーザーのPC、スマホ、タブレットからの利用を想定するが、画面設計はPC優先とする。
まわりくどい表現ですね、本当にね。
普通にレスポンシブだけじゃダメなんですか?
言いたいこととしては、レスポンシブしないよっていうことですね。別にスマホとかタブレットから入ってもいいけど、っていうことなのかなと思うんですけど。
レスポンシブするんじゃないの?
するんですか、これ。解釈が分かれますね。
するんだけど、よくあるパターンのほとんどみんなPCなんだよね、みたいなね。
利用者が多いってことなんですかね、画面設計はPC優先とする。
PCなんだけど中にはタブレットとかスマホでアクセスする人もいるんだよね、みたいな。
そっちでもアクセスできないと困るみたいな感じで言われたりすることがあって、結局やらされるんだよね。やらされるって言葉が悪いけど、やるんだよね。
意味のない書き方ではありますね、そう考えると。
表現の問題って感じですね。
これはね、PC、スマホ、タブレットからの利用を想定できてくれればいいのに、画面設計はPC優先とするっていう言葉が入ってるんで、どうすればいいんだっていう感じがするんだよね。
書き乱されますね。
書き乱される。やっぱりスマホとPC、全く画面の配置が違うので、という意味じゃないのかな、これ。
答えはどこにもないですね。
では、これでラストにしたいと思いますが、3.3顧客企業の人事担当者。
顧客企業の情報取り扱い
必要最低限の情報のみ閲覧可能とする一方で、詳細な回答内容も参照できるようにする。
これまたややこしい書き方。
社員の受講状況を確認する閲覧専用ユーザー。個人情報保護の観点から、先ほどの必要最低限の情報のみ閲覧可能とする一方で、詳細な回答内容も参照できるようにする。
本当に読むのにカロリーを費やす文章だなと、つくづく思いますけれども。
社員の受講状況を確認する閲覧専用ユーザー。これはどうですか?
まだちゃんと読めとれてないような気がします。
分かんない。日本のところは分かんない。
こういう時に後半の総括で話した方がいいかなと思ったんですけど、
やっぱり表現がブレる内容って結構、これだけ我々の中でも割れる中で、先方が思っていることも10中100違ってくると思うんですよね。
いかにこの認識の擦り合わせが難しいかっていうのと、そこに全力で費やさないと後々トラブル。
そうですね。こういう場合、聞くしかないですよね。
よくありますよ、全然。
エンドユーザーとしては、一言に社員の詳細画面とか会員の詳細画面といっても、
普通の一般権限のユーザーが見ていい内容と見ちゃよくないようなアレルギーの情報とかがあったりするので、そこを分けたいってことだと思うんだよね。
我々が作る時に、まずメニューで権限を分けようって話になるじゃない?
メニューが表示されるのかされないのかっていうのがあるんだけど、
多分この話はさらに上で、会員の詳細とか社員の詳細画面は見えるんだけど、その一部に見えちゃいけない部分があると言うんじゃないかね。
結構厄介なんだよね。
大変ですね。
見えちゃいけないものは一ブロックにまとまってくればいいんだけど、あちこちにバラバラとここは見えちゃいけないとかになっていると、それを制御するのは結構大変。
簡単に出すんだったら、詳細バージョンのメニューとか作っちゃいそうですね。
そうそう。それは一つの手だよね。
僕もその似たような経験があったので、もうちょっと具体化しようって話になって、
人材バンクみたいなところの履歴書を見れるようにするっていうところで、会員登録するまでは経歴までしか見れない。
会員登録したら、経歴以外の個人情報とかを見れる。連絡先も見れる。
そういう具体的なところまで落とし込めていれば非常にいいんですけど、ここは非常に曖昧な。
思わないのも、もう少しコースが掛かるとかって強いと思うよ、これ。
その割にはサラッと書いてあって怖いですね。
怖いですね、本当に。
さて、今回はこの辺にして引き続きパート2で456を見ていきたいと思います。
特にうまくまとめられないので、このまま締めちゃってよいですかね。
後半にうまくまとめられたらとか。
続きは後半へ。
続きは後半へというところで終わりたいと思います。
本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価をお願いします。
また、Xでも最新情報を随時発信していますので、よろしくお願いします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
