読者です 読者をやめる 読者になる 読者になる

超初心者がウェブサービスを作ってみるぞ

何をどうやったらウェブサービスが作れるのかさっぱりぴーな僕がそれを作るまでの記録

要件定義書の書き方|その前に#6

どうも、超初心者です。

アプリケーション開発の要、要件定義書を書きます。

 

と言っても、この記事では何も進みませんので、ご了承くださいませ。

 

要件定義書の正しい書き方ってどうなんでしょ。

ウェブには色々参考になりそうな情報が溢れてますよね。

僕も読みましたよ。たくさん読みました。けど、よー分からんのですわ。僕の理解力不足なのは違いないんだけど、正解が無さそうと言うのが半年学習した成果です。

 

プロのソフトウェアベンダーさんなんかも要件定義書は必須のドキュメントだから作ると思うし、納品物として決まっていそうですし、作るんでしょう。要件定義書。しかも上流工程だから、そこそこ単価の高い人が書くんでしょ?その辺の事情は詳しくないけど、ものの本にそう書いてありましたよ。

 

私が思うに、要件って使う人が出すんでしょ?作る側が書いて意味があるんすかね?どーなんですかね?

 

それとも、要件定義書を見ながら使う人と作る人が認識を合わせるんですかね。あーだこーだ言って赤ペン、蛍光ペンまみれにして、履歴だからって消さずに二重線したりしてみて、で結局、最初の要件を忘れちゃったりなんかして。

 

成果物を見返しても、何が言いたいの?何処が重要なの?美味しいの?みたいな笑

 

若しくは、要件定義書の目的って、出来上がったものが使う人の思っているのと違った時に、言った言わない論になった時の武器にでもするんですかね?

 

あと思ったのは要件定義書って21世紀になってもエクセルで書くのがかっこいい感じなんでしょうか?何処のウェブページみてもエクセルらしいフォーマットしか出てこないんですわ。

もっとかっちょいい業界標準ツールってものがあると思ってたよ。

誰かエクセルを否定してほしい。

 

そもそも要件定義っていう言葉が間違っちゃってたりして。

要件にも粒度があるだろうし、細かくなり過ぎるとそれって要件じゃなくて仕様だよ!ってなったり、粒がでかいと、使いやすいシステム みたいな意味のないコンセプトになっちゃうし。

ばーんと画面が出てログインできるねん!みたいなのが丁度いいのか、ユーザーIDを入力できるようになってる!みたいな感じがいいのか、さっぱりピーです。

 

ところで、ユーザーIDを入力できる、パスワードを入力できる、ユーザーIDとパスワードが一致したらログインできる

っていう要件定義書に意味や目的があるんですかね?

言わんくても分かるねん!って。

ユーザーIDとパスワードが不一致でログインできちゃうシステムなんてバグ以外でないんだから、こんな要件定義書を書くだけ無駄なんじゃないでしょうか?

日本の生産性悪いねーってアメリカ人に言われちゃうぞ。

 

次回ももう少し、要件定義書のあるべきを考えたいと思います。

 

ではでは。