スポンサーサイト 

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

2年目SE、プロマネやります。(2話) 

前回のあらすじ:
クライアントから概要だけ聞きましたよ。

さて、と。
クライアントの友人が帰って行ったところで、私は一息ついた。

会社と同じような仕組みでやる以上、ここからは自分が今の話をまとめないといけない。

だが、どうやって?

今さらながら、私はまだ会社では上流にはほとんど触ったことがない。
自分が触ってきた範囲なんて、基本設計からテストくらいまでのもの。
この工程の前や後はほぼ未知の領域である。

とはいえ、そうした基本設計をするにあたって、概要設計や要件定義書といった上流の成果物をまったく見てこなかったわけではない。

まずは、それを中心にどうまとめたらいいか書き出してみることにした。
以下が、そのメモに当たる。


☆目下、まとめておかないといけないこと。
 ・全体的なサービスの概要
 ・ハードウェアのデータの流れや使うハードの要件
 ・どんなソフトウェア・言語・アーキテクチャをといったソフトの要件
 ・予算・納期
 ・開発体制
 ・個別の具体的なサービス
 ・データベースの設定
 ・UI・画面遷移の定義



とりあえずは、このくらいだろうか。
意外と多いことに思わず驚いてしまう。
全部個人でやろうとすると、こうした工程をすべて自分だけでやらないといけないことを改めて認識した。

とはいえ、大きく分ければ、
「概要設計」、「開発環境構築定義書」、「DB設計書」、「UI設計書」
の4つでよさそうに見える。

これらのたたき台を作って、それからまた友人とミーティングできれば理想だ。

続きます!

はい。
というわけでシリーズ第二話。

相手が何をやりたいか聞いた後。
いきなりドキュメント制作、と行ければすごかったのですが、現実はそんなに易くありませんでした。

現実には、何をやらなければいけないのか、を考えることから始めないといけなかったのです。

そして、実際思ったままに書き並べてみると、あるわあるわ……。

日ごろ、上流の人(たいがいは上司でしょうね)が設計をする様をあまり知らなかっただけに、個人的にはいい発見ができたように思います。

上流工程をする人に、作る俺らの気持ちも知らないで……、なんて思うこともなきにしもあらずでしたが、そう思われてる人たちからしてみたって、同じように思ってるのかもしれませんね。

さて。
次回は要件定義ドキュメント作成その1。
「開発環境構築定義書」から参りましょう。

スポンサーサイト

コメント

コメントの投稿















管理者にだけ表示を許可する

トラックバック

この記事のトラックバックURL
http://katawara.blog15.fc2.com/tb.php/50-ad425605

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。