2013年から2014年にかけてもプロジェクトマネージャの仕事も終わり、次の仕事に引っ越しをしようとしています。次は、どこへ行くのか。それは、まだ決まっていません。現在も模索中です。基本は、Rails だけど、Android なんかもやりたいな。
2014年6月4日水曜日
プロジェクトマネージャの次。仕様とは何か?
2013 年 3 月 に始まったプロジェクトもなんとか収束しつつあり、残務対応中です。
まだ、Ajax を使って、初期設定家賃を表示したりとかの実装は、残っていますが、次の仕事へと引っ越しをしようとしています。
今回のプロジェクトを振り返って、これは、ひどいなと思ったのが、初期のころに仕様を出してきた人が顧客企業にいまはいないと言うこと。
普通、仕様を出すとそれに基づいて、ベンダーは、開発を進め、一年後とかに納品となるわけですが、仕様を出してきた人が、いなくなって、そんな仕様知らん!みたいなことになるとベンダーからすれば非常に困ったことになるわけです。
そもそも仕様とは何なのか?
そう思うわけです。
仕様とは何か?
顧客企業の資産であり、ビジネスのルールであり、ノウハウであり、常に変わってゆくものだと言うことです。
その代わってゆく仕様を一時的に切り取って、システムに実装するのがソフトウェアエンジニアの仕事になると思います。
もちろん、その企業の業務が軌道に乗り、そんなに変更は、起きないかもしれません。
以前、変化に対応するソフトウェアを作る。というテーマの議論もあった気がします。
それが動的振る舞いのモデル化だったかな?この辺、かなり怪しい知識です。悪しからず。
ビジネスルール管理システムなどの雑誌記事も読んだことがあります。
話は戻って。
仕様は、みんなで決めるもの。
その定義書(宣言書)として、仕様書と言うものの存在意義があると思うのです。
いわば、仕様書は、法律見たいなものです。
これからの業務アプリケーションは、そういう方向に進むのか進まないのか?
私も生きている間、仕事をしているあと何年かは、その現場に立ち会うことになるのかなと思っています。
ここで問題になるのが、仕様書の詳細化。これは、一度、動くソフトウェアを作らないと見えてこない。
どのレベルの仕様書をビジネスルールとするのか?
それは、難しい、私もまだ見えていない問題。
ここは、こうの方が使いやすいから、こうしてよ!という仕様とうちの会社はこうだからこうしてよ!という仕様とで分類とかも必要だな。
登録:
コメントの投稿 (Atom)
0 件のコメント:
コメントを投稿