要件定義書 続き
1日家から出ない日が自分の中で結構あるのですが、自分が人生最後の日を迎えたとき、こんな日を多く過ごしたことを後悔するのでしょうか。もっと多くの場所へ行き、多くの人と出会うべきだったと思うのでしょうか。無理してそういう生き方をする方が後悔する気がしますが。
ということで。
まとめ切れていない要件定義書及びRFPについてまた書いていきたいと思います。しつこくいきます。
まずRFPです。
RFPは、具体的なシステム提案を行うよう要求する書類になりますね。
で、今回は中身について書いていきたいと思います。
まず一つ目。そのプロジェクトに至った背景です。なぜこのプロジェクトを行うことになったかですね。
このシステムは現在こういう状況で、この辺に支障が出ていて、こういう風に伸ばしていきたくて、これを解決するためにはこういうシステムを導入した方がいいと思っています、というのを明示する、といった感じです。かみ砕くと素直に理解することができますね。
で二つ目が、現在抱えている主な課題です。この業務ではこんなことがあって負担がかかっている、遅いし使いづらいしこれからこういうことがしたいのに全然いうこと聞きません、みたいなことを書く。
三つ目は目的です。
このシステムとこのシステムを連動して、こんな風に稼働させるようにする。個々のシステムは入れ替えなきゃいけませんね、みたいな。
次はプロジェクトのゴールですね。
何秒以内で処理が終わり、使用者が稼働と同時にスムーズに使えるようにという品質の部分。
見積金額以内でプロジェクトを終わりにしてね、という費用の部分。
いつまでに設計し、リリースしてかどうさせるかという納期の部分。
次にプロジェクトの範囲です。（スコープっていうみたいです）
システム開発のどの部分か、（プロジェクトの）
サーバの購入もお願いするのか
運用ルールはだれが決めるのか
人材教育はだれがするのか
この辺を明示すると。
次にプロジェクトの方針です。ここ大事っぽい感じがしますね。
オンプレなのかSaaSなのか。
コストによって判断しますよーみたいに書いてもいいみたいです。
ハードウェア構成はどうしましょうとか。
アドオン（機能拡張用のソフトウェアを合体させ本体のソフトウェアのできることを増やす）やカスタマイズ（ソフトウェアのデフォルトの機能に変更や追加を加えて使いやすくする）はどうしようかとか
インターフェース連携はどうするかとか
メリットデメリット色々考えて判断します、って感じで書くと。
後は会社情報。
うちは現在こんな人数でシステム利用者はこれくらいで年商こんなもんでどこにあります、みたいな。あとこんなもの売っててこういう仕事してます、っていう
で、システムはこういう構成で、なまえはどこどこのこのシステムっす、って感じ。
あとＰＣやサーバはこんなん使っててこういう状況です、っていう感じですね。台数やスペックが重要みたいです。ちゃんと伝えないと後で入れ替えたりするのが面倒
RFPも要件定義書もそうですが、システムなのかWebサイトなのかとかでだいぶ変わってくるみたいなので、まだ触れてない現段階ではこんなかんじでいいかなと。
次回は要件定義書についてこんな感じで書いていきます。
以上です。
