決めないエンジニア

飲みながらアーキテクトの愚痴を聞いていたんだけれど、そのアーキテクトはこんなことを言っていたんですね。

「聞いてくださいよ、自分たちのプロダクトを作るのに要件が決まっていなければ手がつけられませんとか要件を出すのは私ではありませんとかいうんですよ」
「えっと、受託じゃなくて自社製品のプロダクトを開発しているんだよね」
「そうですよ、そうなのにおかしいじゃないですか。自分たちで仮説検証してものづくりしないと」
「プロダクト開発ならね」
「もう、要件をお伺いばかりしてきたから要件を自分で考えることができないんじゃないかって思っちゃいましたよ」

要件はお伺いするものだと考えているエンジニア。それはそれで問題なきがするけれど、要件を自分で考えることができないエンジニアの方が深刻な気がするんだけど。

お伺いは専門家としての職務放棄

確かに要件を提示することはSOWを書けば顧客に○がつくのは当然です。

要件は業務要件とシステム要件に分別しシステム化する際の費用と効果からシステム化をするかどうかを判断します。そのシステム化するシステム要件は確かに顧客側の要件定義の中での仕事だけれど、 ベンダ側の（システムの）要件定義の中で、システム化する要件はITの専門家としての知見を持って精査する必要があるしときにはシステム化要件から追い出したり、業務要件から巻き取ったりとバウンダリを変える必要もあるのですよね。

そうしたところで要件をお伺いばかりして顧客の提示を専門家としての識者の目線でレビューせずにこれで全部ですね、なんてやっているとしたら専門家としての責務を果たしていないことになりかねないです。

お伺いで失うもの

お伺いで要件を聞いてばかりいると用意された材料で料理を作るようなものでそこには新しい発想が生まればかりか要件が実現しようとしているシステムの知見からみて間違った解決策を選んているかどうかをろくに精査せずにパススルーすることになるんですね。

ここで知見を活かして間違いがないかを精査するということはシステム要件のテストにもなりますが知見自体を検証することにもなるんです。これをしていかないとシステム要件として出てきた要件が本来の事業上の要件の解決策としてのIT投資かどうかを見抜くスキルを鍛える場をみすみす手放してしまうことになるんです。

さらに言えば、要件はそうかもしれないけれど、物事の本質＝顧客のペインは実は別のもので、それを解決するなら解決する対応方法は違うという物事を判断するスキルも身につきません。

一番怖いのは自分で決められるスキルを持っていないことだと思うのです。ただ口を開けて待っているだけのエンジニアに高い費用を渡せるかって思いますよね。 

はじめよう! 要件定義 ~ビギナーからベテランまで

SECBOOKS ユーザのための要件定義ガイド (SEC books)

システムを「外注」するときに読む本