giftee Tech Blog

ギフティの開発を支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信しています。

エンジニアでも要件定義に関わることもあります、というお話

ギフティに転職してきて早くも半年以上経ちました。
以前の記事では、入社1ヶ月の立場で、ギフティの社風や働き方について書いています。
会社の雰囲気が知りたい方は、ぜひ読んでみてください。

今回は、ギフティに入って新たに経験するようになったことの一つ「要件定義」について書いていきます。

前職では要件定義に関わることがなかった

前職はシステムの受託開発をしていましたが、要件はすでに決まっている状態で、設計や開発からプロジェクトに携わるという形でした。

設計の段階でインターフェース定義を決めることはありましたが、クライアント企業とのやりとりは基本的に親会社や上司が行っていたため、私が直接クライアント企業と連絡を取ることはほとんどありませんでした。

ギフティでは、エンジニアもクライアント企業と直に関わることもある

ギフティはSaaSでサービスを提供していますが、サービスによっては特定のクライアント企業向けに開発やカスタマイズを行うケースもあります。
私の所属するチームは、大手飲食チェーンであるクライアント企業向けに開発やカスタマイズを行なっており、エンジニアもクライアント企業と直に関わります。
エンジニアもディレクターも、クライアント企業とのミーティングに一緒に参加して、今後の方針などを決めていったりします。

この点が、前職から大きく変わったことの一つです。

業務において、明確に要件定義フェーズ・設計フェーズ、などと分かれているわけではないのですが、クライアント企業から「こういうことがやりたい」という要望が来て、それをいかにして実現するかを考えることもあるので、ギフティに入ってから、いわゆる要件定義にも少し関わるようになりました。

ただ言われたことを実現すれば良いというわけではない

要件定義で難しいなと感じたのが、「言われたことを実現すれば良いというわけではない」という点です。
前職では与えられた仕様通りに設計するところからのスタートだったので、「この機能を実現するにはどうすれば良いか?」から始まります。

しかし、要件定義では、「そもそも、この機能は本当に必要なのか?」というところから始まります。

クライアント企業が「○○したい」と要望を出してきたときに、私はそれを実現する前提で話を受け止めていました。
ですが、チームメンバーから「なぜその機能が必要なのか、ちゃんと聞いた方が良い」というフィードバックをもらい、驚くと同時に納得しました。

必要なのは、現状とゴールを把握すること

要件定義については素人なので、IPAのユーザのための要件定義ガイド 要件定義を成功に導く128の勘どころという資料に目を通してみました。
といっても、とても量の多い資料なので、ざっと眺める程度ですが。。。

眺めてみて感じたことは、「現状の把握」と「ゴールの設定」が必要だということです。

  • 今のシステムの問題点は何なのか(現状の把握)
  • どういう状態になりたいのか(ゴールの設定)

この溝を埋めるのが、要件を明確化していくことに繋がります。

クライアント企業が本来何をしたいのか、そのためには何が必要なのかを把握して、必要に応じて適切な提案をすることが大切であることを学びました。

要件定義に関わることで、今後のキャリアの幅が広がる

これまでは関わることのなかった要件定義に関わることで、より広い視点でサービスについて考えるようになりました。
そして、先々はプロダクトオーナーの立場で開発に関わることも面白そうだな、と感じています。
技術を極めるエンジニアもいれば、プロダクト全体の完成度を高めるエンジニアもいます。
経験が増えることで、今後のキャリアの幅が広がっていくように感じました。