要件定義

酪農の利益率を教えて貰った。
これはアレだ、大変だ。経費が和牛の比ではない。売上は上がるが利益が薄いのでちょっとの油断が直ぐに危険な領域に入ってしまうんだろうなという印象を受ける。

生産性も大事だけどトータルどこで利益を確保していくのかという考え方を持っておいた方が良いのかも知れない。利益率が少ないほど計画は大事でそれをしっかり達成する事が求められる。売上は上げやすいのでその辺りがしっかり出来るなら儲かるなとなる。

システム側としては各種計画の進捗状況や総合的な推移を常に見れるようにしておく事が大事なのかなとボクは思った。これは和牛でも同じで計画を立てる癖と進捗状況を見ていく作業はこれから益々必要かも知れない。

システム開発が本業になりつつあって色んな会社の見積りの話しなんかを聞くのだがどう考えてもうちが日本一安いのは間違いないなと確信する位に鬼のような金額を聞かされる。安ければ良いなんてもんじゃ無いが費用対効果が出てるんだろうか。
数十億するようなシステムの場合ボクの感覚だと何かあった場合の責任は開発元にありそうだが現実はそうではなく発注元に責任があってワイらは悪くないってのを良く見かけてワロてる。

多分開発元は複雑な要件定義やそもそもちゃんとした要件定義を伝えない発注元が悪いんであってうちは悪くないって感覚なのかも知れない。
分からなくはない。発注元に要件定義の概念はあまり無い。なんとなくこんな感じで作ってと言われたら95%は失敗する。
くろくまくんが成功したのは我々自体が要件定義が出来たからだ。

システム開発に於いて要件定義はとても重要で成否は全てこれにかかっている。そしてそれは複雑なようでシンプルでシンプルなようでとても複雑だ。
何を言ってるのか分からないがそれがシステム開発でその周りにこれまた様々な事象やしがらみが纏わりついてくるので大変だ。

この要件定義は発注元にお願いしたいのだがそう簡単なものではないので一緒に考える事になる。相手の協力を得られない＝失敗となるのでそこでコミュニケーションも求められる。

これをいくつも抱えていると発狂しそうになるがそんな暇はないので可愛い牛の顔を眺めながら考え事をしている毎日だ。

しかし毎日生きてる実感ってヤツがある。