見出し画像

要件定義しんどいし、正直な気持ちを書く

私は新卒からWeb開発でエンジニアをしており、昨年勤めていた自社開発の企業を退職し、フリーランスとなりました。

フリーランスといえば聞こえは良いですが、契約した企業先で業務委託として働いているので、タイムスケジュールは会社員時代とほとんど変わりません。

結局正社員ではないので、給与がちょっと多い契約社員みたいなものです。

そんな私ですが、現在はスクラム開発をしているSlerの一チームに業務委託としてお仕事をいただいております。

Slerでスクラム開発ってどういうこと?と思われるかもしれませんが、基本的なスケジュールの立て方がスクラムなだけで、実際の業務の流れはウォーターフォールです。
なので、明確にはスクラムの皮を被ったウォーターフォールです。

スクラムチームは私が契約している企業の社員が数名、その企業の契約先である元会社の社員が数名、私のような業務委託のフリーランスが数名といったメンバーです。

大きなバグでなければ次のスプリントで修正版をリリースするので、一応アジャイルとしては成立しているはずですが、いかんせん「なんでこんな色んな組織の人間をごっちゃにするのか」に限ります。(口にはしませんが)

私は他の請負開発を知らないのでこれが最近のメジャーなのかもわかりません。
一概に悪だとも思いませんが、そもそも請負でスクラムって相性悪いよなとスクラム素人ながら常々感じています。
(相手が顧客の時点で上下関係ができているのだから平等じゃない)

私は今の現場に来て時々「あれ、私ってエンジニアだったっけ?」と思う時期があります。

それが開発(Slerでいうところの製造、ちなみに製造という言葉、私は好きではありません)以外の要件定義、試験計画、試験項目書の作成といった業務をしている期間です。

要件定義も試験計画もシステム開発に必要な工程であることは間違いありませんし、先方との認識齟齬も早期に解決できるので良いところもたくさんあります。

いかにエンジニアが専門職といえど、いえ専門職だからこそ自分がこれから作ろうとしているシステムをユーザーレベルから噛み砕き、リリース(納品)まで責任を持つことは大切なことです。

この現場で仕事をして改めて思うのが、この要件定義の難しさなのです。
次々と追加の要望が出た時なんかは、次工程に移るまで途方のなさを感じます。

要件定義フェーズあるあるですが、要求元が作る資料がかなりふわっとしていて何を作ってほしいのかわからない、また要求元自身も実際に何がほしいか明確でないことがあります。

「いや、何言ってるかわからんから要求元と直接話させてくれ!」と思いますが、基本的に要求元と直接やりとりすることは不可能なので、スクラムでいうところのプロダクトオーナー(PO)を介してQAシートなるものを作成し、確認してもらいます。

要求元もPOも他にたくさんの業務があるので、QAもすぐに回答いただけることはなく、最短で3日はかかります。

回答をもらえるまで要件整理を進めることはできないので、謎の空白時間が生まれてしまったりもします。

また、そもそも「〇〇さんにXXXのこと聞こうと思うんですが問題ないですかね?」といった確認をとって良いかの確認が必要な場面も多くあります。

これは私が経験不足だったり、案件への理解度が足りていないことも祟っているかもしれませんが、要件整理をした資料がうまく作れたとしても、それを口頭で説明する自分の能力の乏しさに愕然とします。

ふわっとした要件をつめてる時って自分自身もこれから何を作るのか明確ではないので、地に足つかない状態で説明してる頭の中は常にパニック状態です。

「チャット上だけでやりとりしていると効率悪いし、認識齟齬も生まれるので、口頭で説明する時間をとりましょうか」

いやいや私の場合は口頭の方が何言ってるかわからなくなるんだって。
テンパって早口で滑舌も終わってる一昔前のキモヲタみたいになるんだって。

要件定義って何をどう作るか決めるだけのフェーズでしょ?
何がそんなに難しくて時間かかるの?
社内システムやし、認識齟齬あったら後で修正すればええやん。

自社開発の温室で育てられた当初の私はそんな軽い気持ちでいましたが、そこから私は請負開発の荒波に揉まれ、今に至ります。(今も揉まれています)

幸いバッファはきっちり設けられているので大抵ギリギリになることはありませんし、多少の手戻りやバグは発生しつつも毎回リリースまで無事に完了します。

ただ、要件定義がたいして進まず1日が終わった日なんかには、実質の成果はエクセルでちょっとお絵描きしたくらいなので「私何やってんだろ」「明日の進捗報告で何言えばええんや」という気持ちに苛まれます。

なかなか質問の回答がもらえず作業が前に進まなかったり、やっと回答がもらえたと思ったら自分が思っていたイメージと全然違ったり、後追いで「やっぱりこうしてほしい」という要望が出てきたり、日々葛藤と自己嫌悪が止まないのが要件定義フェーズです。

もう少し詳しく話せば結合試験フェーズのエビデンス取りなんかも私にとって地獄期間ですが、あっちは頭を空っぽにすればなんとかなるのでまだマシです。

これだけ嫌々と要件定義のしんどいところを話してきましたが、開発工程の良し悪しは別として実際嫌なこと、楽しくないことほど大切で、自分にとっての成長につながるんじゃないかなと思います。

今までユーザー観点でシステム開発をすることって、思えばやってそうであんまりやってこなかった気がします。

頭の中でシステムの構造や制約が先行してしまうことでジレンマに陥ることも多いですが、結局はシステム観点は後からついてくるもので、まずユーザーファーストであることには変わりありません。

エンジニア、というよりものづくりという観点で見れば今やっていることをもう少し誇っても良いのかななんて、最近は少しプラスに考えることができるようになりました。

と、綺麗事を吐きましたが正直エンジニアなんだから開発だけさせてくれよ、エクセル開きたくないよ、ほぼ誰も見ないし試験通ってるならエビデンス取らんでええやろ。というのが一番の本音ですね。

自分がやりたいことは正直あんまりできていないですし、毎日内心半ギレ状態で仕事してますが、世の中そういうもんですよね??ね??

日本のITベンダーはどこもこんなもんだろうと勝手に思っていますが、海外ってどうなんでしょうね。

今いる場所でもう少し頑張ってみるもよし、視野を広げてもっと毛色の違う環境で働くもよし。

今のところ私のエンジニアとしてのキャリアは続きそう(というかエンジニア以外したことない)なので、今日みたいにまた作業が止まった時間なんかは、そういうことを考える時間に当てようと思います。

というか、大抵請負開発に疲れたSEたちが自社開発に行き着くのに、なんか順番逆ですよね。
そもそもウォーターフォールやりたくないから新卒の就活も自社開発に絞って受けていたのになんで自ら荒波に揉まれにいってるんですかね。
人生どうなるかわかんないですね。

フリーランス続けるとしても次に参画するプロジェクトは自社開発がいいなぁ、なんて…。









この記事が気に入ったらサポートをしてみませんか?