2022-03-15 雑談 要件定義はやっぱりむずかしい

ほえほえ＠スプシマン @hoehoe1234

要件定義ね・・・・（一般論として）ノンプロにはできないですかね。IPAの「エンドユーザのための要件定義」は求める水準が高くて本職でもできる人は少ないでしょう。要件定義を書くためのカテゴリは３つ～４つぐらいにわかれていて ①業務に詳しいこと ②要件定義の進捗を管理すること ③文章能力自体

ほえほえ＠スプシマン @hoehoe1234

④要件定義とはなにか？の理解 ⑤システムへの理解（要件なので不用といわれますが、そんなわけありません。ベンダー丸投げならともかく、現代では要件定義と基本設計の境界はあいまいです） ぐらいで、これはIPAの資料をみてもわかります。

ほえほえ＠スプシマン @hoehoe1234

要件定義は「やりたいことを書けば良い」とうのは事実ですが、これは基本設計が「どやるかを書けばよい」、実装が「どう動くのか書けば良い」といっているのと同じで実質なにも言っていないんですね。結局、肯定全体に対する理解がないと要件定義なんてかけないんです。

ほえほえ＠スプシマン @hoehoe1234

要件～総合・受け入れテストのなかの一つの工程の文書なので全体を抑えてないとかけるわけがないのです。密接にからまっていますから。なので「お客さん側につくプロ」としてコンサルなどを雇うんですね。実際、「要件定義がかけます」って人は少ないのかな。なんておもます。

ほえほえ＠スプシマン @hoehoe1234

理由はIPAの資料みてくださいね。要件定義に求められる要素技術が体系的に記述されています。なので現実は要件定義グループの一員となって、やりたいこと、ふべんなこと、業務の実態を説明するという立場になるんですね。これが否定されるのはおかしいと思います。それ以外にできることがないからです

ほえほえ＠スプシマン @hoehoe1234

最上位文書なので直しがあると手戻りは大きくなります。そしてトップダウンとは３回やって始めて「やりたかったことがわかる」というものなので手直しはあるんですね。なのでシステム側の「やったことのある人」はとても貴重なのです。業務の人がシステムを理解するのは原則無理ですので。

ほえほえ＠スプシマン @hoehoe1234

なので、これまでも、これからも要件定義は「システム側の人が業務を理解して書く」ことになるでしょう。逆は出来ないからです。そして手戻りはどうしても多くなります。システムの人は業務を知らないからです。でもそれ以外に解決方法がありませんね。これを打破する方法はいろいろ提示されて

ほえほえ＠スプシマン @hoehoe1234

ていますが、端的には「自社内に開発のプロを雇用して業務を習得してもららう」ってことだと思います。で、これが日本ではむずかしいので解決策がないんですね。要件定義は専門技術なのでノンプロがちょっと勉強して書けるようなものではないのですね。これはどの領域でも同じことが言えると思います。

ほえほえ＠スプシマン @hoehoe1234

経理に素人が来て月次締めたり、決算書類作れるでしょうか？開発部門に素人が・・。全部同じなんです。要件定義もシステム開発全体を知り、経験を積んだ人間にか書けません。結局、専門家を雇用するというだけの当たり前の話で銀の弾はないってことですね。