要件定義工程に入門しました
梅雨も明け、本格的に夏らしくなってきましたね。今年の梅雨は局所的に大雨が降ったようでしたが、皆様どうでしたか？ わたしは残業明けて会社を出るとなぜか雨が上がっているので、ほとんど雨に降られませんでした。残業すると、何かいいことがあるらしいのでしょうか（降られた1回は、飲み会で定時退社した日。本当に何かあると思ってしまう）。
前回のコラムは、多くの方にご覧いただきありがとうございました。まさか月間1位をいただくとは……。コラム開始以降、そんなことは一度も考えていなかっただけに、結果を見たときは驚きました。「タイトル見てクリックしたけど残念なコラムだった」とか言われないよう、頑張っていきたいと思います。
●要件定義始めました
急ぎの案件が発生したとき、案件の基礎知識があるということで、開発要員であるわたしが要件から参加することになりました。要件定義は、開発と違って目的を果たすための選択肢が多いですね。今回は案件が少々特殊ということもあって、なおさら多かったようです。
予算に合う答えを導き出すために、システム上必要でも優先度を加味して削ったり、同じ機能でも作り方を変えることで工数を削ったりと、いろいろ頭を悩ませておりました。その中で1つ驚いたことがありましたので、この場で紹介したいと思います。
●予算を変えずに機能を複雑にする
それは、「仕様が固まれば簡単にできる機能を、あえて難しいままにしてしまう」ということでした。仕様を決定することで必要なQ＆Aの往復時間と、その後ひっくり返されるリスクを考慮して、仕様を選択して使えるようにしてしまうという判断でした。確かにおっしゃる通りなのですが、そのためには開発に負荷かかるんですが……と思いつつ、Q＆Aのレスが遅くて1週間このために時間を無駄にするならば、その方がよほど良い結果なんですよね。
「要件定義工程は開発工程とはまったく違うセンスが要る」
そう考えた瞬間でした。
●まだこの工程は早い気がした
この工程を終えて、いくらか思うところがありました。うまくまとまらなかったので、1つずつ書いていきたいと思います。
◎仕様が比較的簡単にガラっと変わり、変化への耐性が低い自分には少々つらかった
「出した案がダメになったと思ったら巡り巡って採用されていた」「方向性が決まったと思ったら、そこから少しずつ変わり、結局大きく変わっている」など、個人的に精神衛生上あまりよろしくないなと感じました。
◎8割方できると思ったら「できる」と言えないといけない
100％にしてから回答する時間がない。開発者はじっくり考え、抜けがないようにするが、要件では細かい事は後回しが基本のようで、なかなか細かい部分に気を回す時間がありませんでした。こういうのが後の工程で悪さをするのですがね……。
◎自分たちに一番良い結果は、「自分が妥協すること」が多い
上述の例にもありますが、「さっさと折れるのが一番の良策」ということが多かったです。個人的にはこの決断は非常に苦手（嫌い）です。折れるところは折れ、本当に相手に妥協して欲しいところを交渉しやすくするなど、「コミュニケーションスキル」とかいう次元ではなく、「戦略スキル」のようなものが必要ですね。時にはハイリスクな選択肢を選ぶなどということは、わたしにはどうも苦手です。
◎1つの問いに対して多くの答えを持ち、すばやく出せなければならない
「こういうことをシステム化するにはどうするか？」という答えに5～6つの選択肢を持ち、それを反射的に選別して出せるようにならないといけない。この点、わたしは比較的得意としていますが、まだ選択肢が少ないと感じました。
●終わりに
開発工程は比較的余裕を感じていましたが、この工程では結構課題が浮き彫りになった感がありました。この点だけでも参加した意義があると感じています。
今後、当分この工程に顔を出すことはないと思いますので、気長に地力を付けていこうと思います。いつかはこの工程をやらないといけないので……。