手法が古い

別プロジェクトで状況調査。

現段階では大まかな仕様が決まっており、詳細につめている段階。一刻も早く全体を押さえて、詳細な部分のレビューに参加すると共に、グループの進捗管理をして欲しいとのこと。

グループの担当分はシステム制御系。クラスタ構成によるフェールオーバの実現と、プロセスの生存監視。

こんなもん、サードパーティで優れた製品がいくらでもあるのにもかかわらず、自前でやるのでそうだ。まぁいろいろと政治的な事もからんでるらしい。

まぁそんなことは、どうでもよくて、どうしても工数をかけて自前でやりたいというなら止めはしない。

仕様書にはフェールオーバとプロセス監視を実現するための構成と通信フローがごちゃごちゃ書いてあったが、例によってよくわからん。

フェールオーバもプロセス監視も一般的な話。24時間稼働のシステムならどこでも問題となる話。もうこのキーワードだけで発生しそうな問題点と解決方法は大体予想がつくのだが...

相変わらず、要求分析に関する資料はなく、いきなり機能仕様書。しかもかなり詳細より。何を目的として、こういう機能にしたのかわからなきゃ、この機能が要求をみたしているかどうか、判断できないんだけど、それは気にするなってことか？

さらにわかりにくい原因として、どうも、機能中心にアプローチしているらしい。構造化設計をレベルの低いところでしかできない人達が設計するとこうなるんだろうなぁ。

ソフトウェアってのは、情報を変換するものなのだから、情報を変換する方法と共に、元となる情報に何があるのかってことが重要なのに。

構造化設計だって、データを中心に扱うDFDってのがあるから、構造化だからって、扱うデータをまとめなくていいってもんでもなかろうに。

オブジェクト指向なら、必ずデータをグルーピングして、そのデータに対してどんな操作が発生するかというアプローチをするので、必ず核となるデータが出てくるのに。

確かに経験の浅い人達が機能ばかりに目を奪われるのはわかる。僕も昔はそうだったから。　何故って、そっちの方がわかりやすいから。でも、機能とか操作を中心に分析したものは、抜けが発生しやすい。

自分では意識していないんだろうが、機能や操作は必ずそれに基づくデータがあって、そこから発生しているものなのに、根っこを無視して枝葉ばかりを作ろうとしても、木は倒れちゃうんだよね。

5年目程度の若いのがやっているならいざ知らず、外注から他社から多くの雁首並べておいて、これかい。誰一人、根っこをただそうとする人間がいなかったのかい。

まぁ、頭数がそろっている分、根っこをないがしろにしていても、相当時間をかけてレビューを実施して抜けを洗い出しては、いるらしい。

データ中心に解析ができない以上、そういう手間のかかる手法を採用するしかないのかな？

もっと初期の段階で呼んでくれれば、もっと効率よくスマートにやってやったのに。他社との打ち合わせでも、他社から突っ込みようのない仕様を考えてやったのに。
ある意味、もうほとんど決まっていて、手の出しようがないんだけど。

今の仕様書から、断片的な情報をまとめ上げて、自分が見やすいように再構成するしかないな。

手法が古いのが悪い訳じゃないが、手間がかかりすぎる。

ちょっと気に入らないので、毒を吐きたいところなのだが、また、このプロジェクトに関わっている人達が、みんな人のいい人ばっかりなので、毒もはけない。

まぁ、気に入らないが、ここのやり方に合わせていくしないな。やれるところから、徐々に僕のスタイルにねじ曲げていこう。
今までも、どこに行ってもそうだったから、今回も同じ事をするだけ。

居心地が悪かったら、居心地がよくなるよう、周りを変えてやる。