BLOG

2021-08-02 テクニカル

要件定義への取り組み方

どうも、畜産ペンギンです。

 

ドラゴンボールの映画が来年やるみたいですね、楽しみです。

 

今回は要件定義について語って行こうと思います。

毎度毎度何らかの面倒事が起きるのでどうにかならんかと思い調べたり考えたりしてみました。

 

目次は以下の通り。

 

目次

・心構え

・何を聞くか書くか問題

・要件変更&追加問題

・まとめ

 

心構え

まず、結論として。

 

面倒事が起きる中での着地点を見つけるのが要件定義のお仕事だよ。

 

はい、終了。

めんどくさいのが嫌だからどうにかならんかと思ったのに。。。

 

そもそも顧客と開発側はある意味利害が衝突してるんですよね。

顧客は少ないコストでより多くの課題を解決したいし、開発側は少ない労力でより多くの売上が欲しい。

利害が衝突しているので当然ぶつかり合いが起き、面倒事が起きる。

この中でお互い納得できるWin-Winの道を探す物と覚悟を決めておけば多少気は楽になるんじゃないでしょうか。

 

何を聞くか書くか問題

これはシステム概要と、IFの定義と・・・という話ではありません。

そこに正解は無いからです。

 

勿論、基本的には既存のフォーマットに沿って書くでしょう。

そのアプローチは間違いでは無いと思います。

ですが、本質はあくまで顧客の課題を解決する事というのは理解出来ると思います。

顧客の課題は都度異なるので、具体的にコレを書くべきというのは答えは無いという事ですね。(ある程度の共通解はあると思いますが、完全では無い)

 

唐突ですが、開発者なら一度は皆「こんな要件で作れるかよ」と思った事はあるんじゃないでしょうか。

開発者側は基本的に、より具体的で詳細な要件定義を求める人が殆どだと思います。

 

ですが顧客のステークホルダーとなる方は基本的に大変忙しい人が多く、こちらの聞きたい事に常に付き合ってくれるような状況にありません。

じゃあこっちで勝手に詳細まで決めて要件定義書には書いておくから読んでおけよ、レビュー通ったら後から文句言うなよといっても無駄です。

忙しいので当然分量が多すぎると読み切れないし、そもそもシステム開発に詳しく無いのでこちらの聞きたい事の意図が伝わらない事も多々あります。

その結果、後々認識齟齬が発覚した段階で要件変更や追加として降ってきます。

 

ここで一つ気を付けておきたいのは、顧客はシステム開発に対して詳しく無いからと言って天狗になってはいけません。

そもそもお金を頂いている関係なのだから、という事もありますがここで言いたいのは顧客の課題自体には顧客の方が詳しいという事です。

 

顧客はシステム開発に詳しく無いが故に、解決方法として開発者側からすれば「こういうシステムにした方が良いのでは?」と思う事は多々ありますが、課題の背景を理解しようとせず安直に開発者側の思った通りにすると顧客の課題解決に役立たない物が出来上がります。

 

話が少しわちゃわちゃして来ましたが強引に方向転換します。

結局何を聞けば何を書けば良いかというと、顧客にとって大事な事と仕様変更のリスクが大きい部分を抑える必要があるという事です。

そして、それが何なのかを理解する為の能力が求められると言った所でしょうか。

 

要件変更&追加問題

これに対して怒りを感じた事が無い開発者も中々居ないんじゃないでしょうか。

これらを減らす為の事は上で記載してますので(他にも政治的な方法等あると思いますが)ここでは起きた際の取り組み方について書いていきます。

 

まず、要件変更or追加を言い渡された際の、開発者目線の単純な行動と結果としては以下の2つがあると思います。

・受ける=商品価値が上がる、コストが上がる。

・断る=商品価値が下がる、コストが下がる。(変わらない)

 

気をつけなければならないのは、ここでいう商品価値で言いたいのは顧客に作成を依頼された成果物という意味ではなく開発者自身の事を指しています。

顧客は当然柔軟に対応しない開発者より対応する開発者を求めます。

 

リーダーレベルでもたまに二つ返事で無理です。と答える人を見ますが本当にこの前提を理解した上での発言なのかと疑う事があります。

また、免罪符として「チームメンバーを守る為」という言い訳も出来るので本人としてはチームを守るリーダーしてるという気になっているんじゃないかと邪推したりしてしまいます。

 

少し口が悪くなりましたが、当然これは逆も当てはまります。

会社の売上の為や、顧客との関係悪化を恐れるばかりに二つ返事で受け入れてしまう人。

何でも受け入れて、自分だけならまだしもチームメンバーも一緒に無茶な働き方をさせるというのは当然最悪な事です。

 

必要な事はちょうどいい着地点を考え、見つける事です。

これも結局の所、顧客にっての重要度とコストあるいはリスクが一つの指標になると思います。

そして、それが何なのかを理解する為の能力がry

 

まとめ

結局の所、大事なのは相手の事を考えるという事だと思いました。

それはどの仕事でも同じ事かもしれません。

 

特に顧客とのやりとりは気を遣い精神的に疲れる事も多いですが、たった一言、たった一行で売上や稼働時間等のコストが大きく変わるのでよく考える、また勇気を出して伝える必要があると思いました。

 

今回はここまでです。

 

さようなら。

The following two tabs change content below.

畜産ペンギン

主にネットワーク系、開発系を経験しているエンジニアです。 技術系を気まぐれに書いて来たけどそれ以外も気まぐれに書いていこうかなぁと。