見出し画像

新しい価値を実装する時は、仕様に対してHowの前にWhyを大切にする

Showcase Gig Product Team Blog

こんにちは。Showcase Gigのプラットフォーム開発2チームでエンジニアをしている田坂 @yuuuutsk です。 今回は私のチームで、実装や設計をする前段階で大切にしていることをアウトプットします。 特段目新しいことは書いてないですが、少しでもチームの文化の理解につなげれば幸いです。

プログラムなどの実現手法に関してWhyを明確にすることは、t-wadaさんも提案しているように分解していくことはコードの可読性や適切な抽象化によい教訓となっています。

少しレイヤの違う話ですが、機能や仕様のWhyを明確にすることも良いエンジニアリングにつながります。 特に新しい価値を実装するときには重要なマインドだと考えています。

新しい価値を実装するとは？

前提としてエンジニアリングは課題解決することであり、その手段や武器としてテクノロジがあります。

課題解決は基本的に事業に紐づいているわけですが、事業のフェーズもいくつかあります。

すでに価値が社会に対して浸透途上、当たり前のものになっていないような新しい価値を実装するときには比較してそうでないフェーズの時と課題解決の仕方を工夫する必要があります。

新しいサービスやアプリケーションは機能やUIがドラスティックに変わっていくことは多いです。 これは、ユーザーに対してどんな価値提供をすれば熱狂的に使ってくれるかのプロダクトのHowがまだ確率していないからです。正確にいうと伸び代があり、価値を高める余地が多いフェーズということです。

このような状況下では開発途中にプロダクト要件や仕様に変更されたり 開発完了後の動作レビューの際、仕様考慮漏れに気付くことも珍しくありません。

このような漏れはすべてをなくすことはできませんが、事前に気付くこともできます。

Whyを大切にする

漏れをなくすには、誰が何のために何をするかをクリアにします。

機能（仕様）は解決したい目的があって生まれます。 この時機能はHowであり、目的はWhyとなります。

あくまでも目的を達成すればよいので、Howは選択の余地があります。 語弊のないように「このHowでやりたい」などは世界観や哲学にあたるので 多少例外と考えましょう。たとえばUIのテーマなどが当てはまります。

エンジニアが要件や機能のHowだけを考えると、「やはり、こんな機能の方がXXXするためにはよい価値を提供できそうだね」という話になり一部実装やり直しとなるわけです。 また、スタートアップでは要件と大部分の仕様は決まっているが細部で使用が決まっていないことは、組織のリソース状況やチームの体制などから往々にしてあります。これは裁量であり、想像できやりがいのあるポイントでもあります。

これらを踏まえて、要件や機能設計を担っていないエンジニアであってもWhyの理解を深めることはフェーズによって、大切にするべき視点の比重を変える重要性がわかります。

事業やプロダクトのロードマップを意識する

今までは目の前の機能開発に関して大切だと感じていることについて触れせさせていただきました。 それらは点のWhyやHowであり、線としての視点もあります。

事業（もしくはプロダクト）でトライしたいことはたくさんあります。 その順序やタイミングはロードマップとして落とし込まれていて、会社や事業の規模によりますが組織が数十人など程度の規模を超えてかつ事業の柱だった場合は1-2年単位や4-5年単位で大まかなロードマップが設定されていることが多いです。 その中で、システムで見たときには線の最適解を出すにはエンジニアの視点も大切になってきます。

弊社のモバイルオーダープラットフォーム（O:der Platform）とプロダクト開発の事例を元に解説します。

弊社ではO:der Platformを軸に複数のプロダクトが提供されています。

画像1

プラットフォームとプロダクトの間の責務の分離で考えたときに、機能的には異なるがデータもしくはロジックとしては同じものがそれぞれのプロダクトにあると共通資産としてプラットフォーム側でデータやロジックを持つメリットがあります。 O:der PlatformだとID（会員）・店舗情報やメニュー情報・売り上げ情報などが該当します。

こういったプロダクトの背景があった時にビジネス要件として「店舗情報をプロダクト間で連携する」があった場合 新規プロダクトを作るとき、プラットフォーム側に共通資産を配置しプロダクト側はその資産を活用する形で実装します。

一方で既存プロダクトは、この新規プロダクトリリースのタイミングでは同一の要求はないが、来期に連携する構想があったとします。 既存プロダクトも機能開発が継続して行われているので、時間がたてば経つほどデータ移管は難しくなります。

システムのことを開発サイドは事業サイドと比較すると、より理解しているので システム移管に関してどのタイミングで行うとちょうど良さそうというのが判断しやすいです。

この判断は事業やプロダクトのロードマップを意識していないと難しい良い例です。 この例は複数のプロダクトが使うプラットフォームとプロダクトを開発するロードマップの例で、プラットフォームは大前提各プロダクトの共通資産であるので事業や各プロダクトの中長期的なロードマップの関連度が高かったです。 一方単一プロダクトを開発するときも、規模は違えどロードマップを意識すると点の最適解だけではなく線の最適解も検討できるので、常に注視するエンジニア文化を目指したいと個人的には感じています。

最後に

規模やフェーズ、事業の特性によってケースバイケースではありますが、私たちのチームで大事にしている Whyを明確にすることや事業のロードマップを常に意識していることに関して解説していきました。

Showcase Gigではエンジニアドリブンで裁量を持って働ける会社です！ 私たちと一緒にプラットフォームやプロダクトを一緒に作りませんか？


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