要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経

タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す

[NOV1975]

要件定義だけをやった会社から引き継いだ案件、だいたい炎上しているんだよなあ。要件定義の品質を顧客が正確に評価できない以上、ワンストップな対応ができる会社に準委任すべきだよ。

[paradisemaker]

大企業にはITコンサルがこの領域に入り込んでると思うけど、コンサルしか経験がなくてシステム開発のこと分かってない人がいて、開発への繋ぎができてないケースを割とよく見かけますね

[turanukimaru]

要件定義専門家が欲しいとかコンサルがと言うのは、結局ユーザが「良く分からないから詳しい人に全部やって欲しい」「失敗したら専門家のせいだってことで良いよね」と投げ出してるだけなので関わるだけ無駄。

[tk_musik]

コンサルの本来の領域な気がする。しかし要件定義専門家を置いても銀の弾丸にはならないか。。面倒臭いスクラムやらなあかんか。あー週休4日で言われたものだけもくもく作ってお金もらいたい

[dkfj]

これ、面白い視点だな。SIオワコン説が流布しているけど、逆にシステムの複雑さが増すに連れて、出番が増えているような気もする。この辺り、どういった企業形態が生き残るのか考えてみたい

[morimarii]

要件定義って結局システム化要求のどれを実現してどれを実現しないかが肝で、そのためにはユーザ側に業務に詳しい人間と社内政治をうまく捌ける人間が必須なのよね。このキーパーソンがいるかいないかで決まると思う

[nishi1231chang]

開発分かるエンジニアがやるのが一番いいけど、やりたがらないというジレンマ。革新的なサービスならいいけど、要件定義で困ってるのってレガシー業界のしがらみの多いシステムだったりで、誰もやりたくないという。

[kamayan1980]

開発営業の「要件定義も専門家の我々がお手伝いしますよ！」を信用してもうた発注企業がゴミより酷いシステム使ってるのは多々見かけますね。御社のビジネスの専門家は御社だけなのよ。

[eriotto]

客先常駐しつつ、数年に一度アップグレードの時に基盤部分を開発してる。歴でいうと最古参、業務についてはたぶんトップクラスに詳しい身からすると、用件定義から検収まで客先の立場で支援するのが一番うまくいく

[emt0]

要件定義に乗り気じゃない顧客に限ってアジャイルをいくらでも仕様変更可能な魔法の杖みたいに思ってたりするしほんと大変。アジャイルでちゃっちゃって出来んでしょ？2週間で。なんで出来ないの？アジャイルだよ？

[tksmrkm]

“IPA 要求工学知識体系(REBOK)概説”

[rryu]

結局、細かいことを詰める前に要件を漏れなく詳細に洗い出すというのが無理すぎるのだと思う。求められるスキルが高すぎる割に何らか失敗する可能性が高いのでやろうと思う人はいなくなるよなという感じ。

[honma200]

作ってみないとわかんないことが多々あるし、かといって当の担当者はいつも関われるわけでもない。忘れることも多々あるし

[kanu-orz]

“開発技術におけるアーリーアダプター的人材はほとんどがアジャイル開発方面に移行していったような印象がある” が結局の答えと方向性なのではないだろうか。

[mricopp]

具体的な絵(デザイン)が見えて急に別の要望を言ってくるから、当初の要件がひっくりかえされて要件定義の意味がなくなるという状況を何度か見ている。それをやっていいのがアジャイル、と勘違いしてる発注元。

[Chisei]

“「要求の発掘」により大量の要求っぽいものが発見されたとして、これを全て精査・厳選しして最終的な要件に変換することは、要求エンジニアには出来ない。これはシステムの使用者（ユーザー）がやらざるをえない”

[Silfith]

要求すらマトモに定義できてるか怪しい状態で突然要件定義する人はたくさん見てきた。　要求定義の上流が整備済みなのか、一緒に整備するのか評価出来ない人が携わると不幸は約束される

[KAZ99K]

えっ僕開発側の人間だけど要件起こすし設計に落とすしテーブルも作るよ。だって(システム会社じゃない)普通の会社が仕様書すら書けないの普通じゃない？僕ひょっとしてレア人材？(な訳ないか)

[inductor]

Requirement Engineer、その専門性からしてtake overをできる開発ベンダーとの埋め合わせが一番大変なはずで、そんな能力を持つ人間は世の中にいないし絵に描いた餅なのでは？？？の気持ちが強い。

[d6rkaiz]

10年くらい昔に要件定義専門という人とやったことあるけど、抜けが多すぎて手戻りばっかりだった記憶。抜けを指摘しても直してくれなかったことがあって、後日手戻りが発生したときには俺のせいにされたよ。

[junjuns7]

業務寄りの夢とシステム寄りの形の間には割と深い谷があり、そこを渡す専門性に名前は欲しい。でも要件ばかりやる人という人間像である必要もない。結局後工程まで付き合うことになる役割だとするのもひとつの見方。

[vanish_l2]

要件定義って四文字なのにいかつい日本語

[complete_dark]

この辺りをうまく要件定義から実装保守までやってるのがア◯センチュアという印象。筆者の言う通り流行ってないので一人勝ち(社員数、業績ともに増え続けてる )

[moromoro]

業務知識が浅くて開発運用経験ないコンサルさんは本当に入ってこないでほしい分野。見積が矮小化されて大炎上が起きる。

[coper]

REBOKやBABOK（とそれを生業とすること）は確かに流行らなかった。パッケージとアジャイルによってOne Shotの要件定義スコープが小さくなったからかかも。ユーザに決めさせて納得させる難しさは相変わらずだが。

[hiby]

要件定義を専門でやる技術者はもはや別の職業だよなあ。コンサルは手を出さないと言うかそういう経験がないのでありとあらゆるババを引くし水が流れて行かない。

[ultrabox]

短期間でころころ要件が変わるような業務はそもそもシステム化に馴染まないので対象にすべきではない。例外業務とかも全て範囲外だ範囲外。Excelとかで何とかしろ遠野！

[oakbow]

この手のことをやるコンサルを何度か見かけたが、プログラマほど技術的知識がなく、最終成果物の責任を負わないので浅い分析でやっつけてた。必要なものが足りず無駄が多いシステム設計ひっくり返すの大変だった

[ledsun]

「要件定義」は技術なのだろうか？発注側の人々の隙間にある金脈みたいなのを発掘する作業は技術なのだろう。しかし発注側に依存する要素が大きすぎて再現性は低そう。スクラムマスターより低そう。職人芸だよなあ…

[acealpha]

要件定義の価値が認められて開発の重要ファクタであることが周知されれば開発ベンダの立ち位置はよくなると思う それを今までなあなあにしてコンサルも実はやってなかったのが実態だと思うので

[w1234567]

提案と要件定義だけやって外注に基本設計フェーズ以降をポイ投げする奴はよくいるよな、要件定義をやり直す必要はあるがスケジュールは変わらない模様

[odakaho]

“要求エンジニアはユーザーが要求しているのだから、効率などは無視して要求を定義するし、構築者は効率が悪いと思っても、すでに定義された要求は充足せざるをえない”

[orangeno8]

大きい開発は外部に委託するにしても、自社開発を経営の方針にしないと解決しないでしょうね。

[Baybridge]

「ダメな奴は何をやってもダメ」みたな悲しい結論にしかならないのよねこれ。

[xlc]

その難しい要件定義を何とか乗り切ってきたのがSIer。それを切り捨ててデジタル庁で「モダンなWebエンジニア」が要件を決められるのかお手並み拝見。おそらくは「永遠にリリースしないアジャイル」をやると思うよ。

[n_231]

要件定義が得意な人はSIerに存在するけど、専業ではないしスキル継承も限定的。

[nakag0711]

やりたいことそのまま書くだけじゃダメだよなあ

[daishi_n]

要件定義って所属する会社や案件によってレベル感が違いすぎるからね。これに非機能要件も加わるから地獄だ

[ghostbass]

「要件定義はユーザーに理解できない」などと言う理解不能な意見を聞いたことがあるがそんなのは地獄でしかないって何故わからんのだ