こちらは バイセルテクノロジーズ Advent Calendar 2021 の 15日目の記事です。
前日の記事は 浅野さん の「部署異動して感じたディレクターの魅力」でした。
こんにちは。開発1部の瀬尾です。
私が所属している開発1部はバイセルの販売領域に関わるプロダクトを担当しています。いくつかあるプロダクトの中で、私はグループ会社の株式会社タイムレスが運営するタイムレスオークションを担当し、そのディレクターを務めています。
今回はディレクターの職務の一つ、要件定義、仕様決めをする上で私が気を付けていることを書きたいと思います。
私は「要件定義」「仕様決め」「設計」と区別して考えるようにしています。
それぞれ例え話を交えながら説明します。
要件定義
要件定義という言葉はよく使われますが、要件を定義するってどういう事でしょうか？
新人の頃は曖昧なままこの言葉を使っていました。
要件定義はよく、ドリルと穴の話で例えられます。
「ドリルを買いに来た客が欲しいものはドリルではなく穴だ」という例え話です。
つまり要件は「穴」だ、という事です。
しかし、本当に要件は「穴」でいいのでしょうか？
なぜ「穴」が要件だと言えるのか。。
それはお客様に「なぜドリルが欲しいんですか？」と聞くと「穴を空けたいからだ」と答えたからでしょう。
そこで「なぜ穴を空けたいんですか？」とさらに聞いたとしましょう。すると「椅子の足を取り付けるためにネジ穴を空けたい」と答えました。
さらに「なぜ椅子の足を取り付けようとしているんですか？」と聞くと「椅子が壊れてしまったから」と答えました。
「新しい椅子を買うのではダメなんですか？」と聞くと「思い入れのある椅子だから修理して使いたい」と答えました。
この辺りでようやく要件がぼんやり見えてきました。
このお客様の要件は「壊れてしまった思い入れのある椅子を使える状態にすること」と定義できます。（まだまだ粗いですが例え話なのでこの辺にしておきます）
このように、要件定義をするためには目的や背景などを深堀りして理解する必要があります。
実際、現場から「システムにこんな機能を追加して欲しい！」つまり「ドリルが欲しい！」みたいな話が舞い込みます。
そんな時は「なぜ？」を繰り返し、その要望の本質を探ります。
また、目的や背景以外にも、利用者は誰か、時間的な制約があるか、ビジネス上の影響（業務工数や売上や利益への影響）があるか、など様々な事をヒアリングしていきます。
そうやっていろいろ聞いていくと、時には「新しい機能は必要なく、システムの使い方を変えるだけで済む」なんて結論になることもあります。人間、課題があると何かが足りないと思いがちです。要望を鵜呑みにせず、無駄な開発を未然に防ぐのもディレクターの大事な仕事だなと思っています。
仕様決め
要件定義ができたら仕様を決めていきます。
要件を満たす仕様はいくつも考えられます。どういうことかと言うと「要件＝壊れてしまった思い入れのある椅子を使える状態にする」だとして、ネジ穴を開けるドリルは電動か、手動か。ドリルを買うのか、レンタルか、それとも業者に頼むか。はたまた、既に穴が空いている棒を用意すればドリルは要らない、強力な接着剤でくっつければ穴すら要らない、という様にいくつも方法があり得ます。
実際に仕様を決めるためには、ユーザーのリテラシーレベルや、どういう状況下で使う事になるのか、などを調べておかないと決めることができません。
また、広い視野で考える事も大事です。
ある部署が要望する機能を実装したら、別の部署の業務工数が増えてしまったという失敗をしたことがありました。
だいたいの業務は繋がりがあるので、関連しそうな業務は考慮する必要があります。
一部がメリットを享受したとしても、他方でデメリットが出てトータルでビジネス的にマイナスだったら意味がありません。
関連部署との調整を疎かにしないこと、そもそもどこが関連しそうかを気付けるように業務を理解しておくことが大事だと思います。
そして、特に忘れないように気を付けているのは、システムのユーザーである社員の先には弊社のサービスを受けるお客様がいる、という事です。
システムを利用する社員の声は届きますが、お客様の声はなかなか届きません。業務を効率化することだけに気をとられると、お客様が不利益を被っていたという事も発生し得るので、そこはとても気を付けています。
設計
仕様決めができたら、設計をエンジニアに依頼します。
この時「定義した要件は必ず満たさなければならないが、決めた仕様は絶対ではない」というスタンスで設計してもらっています。
新しい技術を取り入れたり、保守性の観点だったり、機能と工数のバランスだったり、エンジニアの視点で忌憚なく仕様変更の提案を貰います。
その提案の可否をディレクターが判断し、取り入れていった方が良い結果になりやすいです。
例えば、ドリルの仕様としてバッテリー内蔵型にすると決めたけど、電源コード式にした方が既に開発した物を流用でき工数が少なく済む、という提案をもらい、必ず持ち運べるようにしなければならない要件はなく、工数短縮のメリットが大きいと判断して電源コード式へ仕様変更する、といった具合です。
目的や背景を深堀りした要件定義が出来ていれば判断もしやすいです。
このように、要件定義→仕様決め→設計と抽象度の高い状態から解像度を上げていき、何のために何を作るのかを考え決めていきます。時には立ち返って、様々な視点を取り入れ、明確な正解がない中で最適解を目指すのはディレクターの仕事の醍醐味だと思います。
最後にバイセルではエンジニアを募集しています。
少しでも興味のある方はぜひご連絡ください！
明日のバイセルテクノロジーズ Advent Calendar 2021 は赤川さんから「Smart Proxy Managerを用いたクローラー実行時のアクセス遮断への対策」について紹介されるのでそちらもぜひ併せて読んでみてください！
