標準化は“全部盛り”じゃない
〜本質を突き詰める開発プロセス〜
こんにちは、ニトエルの橋本です。
私はこれまでERPベンダーでのプロダクト開発、アドテック企業での海外事業の立ち上げ、AIスタートアップでの新規事業開発に従事する中で、いつも「標準化」と向き合ってきました。
（私のこれまでの取り組みは、社員インタビュー記事でも触れていますので、併せて読んで頂けると嬉しいです）
ニトエルでも、今まさにプロダクトの「標準化」を行っている真っ最中です。そこで、今回はプロダクト開発における標準化について、私なりのアプローチを言語化してみようと思います。
はじめに——「標準化」とは何か？
「ユーザーごとの要望を全部取り込んだら標準になるのでは？」
ユーザー企業が100社いるとして、その100社から吸い上げた要望を網羅できるように機能開発を行うとします。
すべてのユーザーの要望を聞いてプロダクトを作るため、一見すると、ユーザーからご満足頂けそうなアプローチに感じます。しかしながら、実際にやってみるとプロダクトは“ごった煮”状態の“複雑怪奇な機能”が生まれてしまい、結果としてユーザーが満足する機能を提供することもかなわなくなります。
これまで関わってきたプロダクトのなかで、「顧客ごとの要望を寄せ集めて“最大公約数”を作る」方法で機能開発をしてしまったことがありますが、結果は以下の通りでした。
保守コストがあがる
使いづらく複雑な機能ができあがる
機能が属人化し、特定の人以外には何の機能か分からなくなる
機能改修のコストが膨れ上がる
プロダクトが複雑化することで、保守・サポートも難しくなりますし、将来の成長を妨げる要因にもなります。また、要望をすべて吸い上げて機能開発をしたはずなのに、ユーザーに喜ばれる機能提供もできていませんでした。
この失敗から学んだのが「プロダクト開発とはただ顧客の要望に応えるのではなく標準化して機能化すること、そして標準化の肝は“何が本質か”を突き詰めること」というシンプルな事実でした。
1. 「本質を見極める」ための3つのステップ
(1) まずは自分が使うならどうするか？
ユーザーからのヒアリングだけを頼りにすると、どうしても要求は抽象的なレベルでとどまりがちです。そこで「自分が担当者なら、どのような情報を元に、どうやって意思決定をして、何を入力するのか？」 を、なるべく具体的に考えてみる事にしています。
たとえば「見積比較機能が欲しい」という要望について考える場合、見積書の実物や、自分で作ってみたサンプルを眺めながら
どんな情報を並べるのか
なにを軸に比較するのか
その情報を見て何をどう判断するのか
その結果どういった行動をとるのか
…といった風に具体的に操作イメージを自分で描いていきます。このプロセスを踏むことで、ユーザー側の漠然とした要望の中から「本当に求めているもの」を抽出します。
(2) 境界を鋭くする
標準化でありがちな罠が、どこまでが標準としてサポートするのか、逆に標準に含まれないものは何なのか、というスコープ定義の「境界が曖昧」 です。たとえばニトエルが日々向き合っている製造業のお客様の場合、取引形態や物流形態も多岐にわたります。
その中で、当たらずとも遠からず といったものが出てきて、それを適宜判断してスコープに含めてしまうと、機能の中身がちぐはぐになったり、肥大化したりして、最終的には本来の目的を追求できない機能になってしまう恐れがあります。
そこで、定義を眺めながら、どういったものはスコープで、どういったものはスコープ外なのか、ギリギリ含まれるもの、ギリギリ含まれないものは何なのか を、具体例を出して考えていきます。
こちらも結構泥臭い作業で、今のスコープだとこのケースは含まれないけど、本来サポートするべきなのでは？ といった事が見つかって、定義・スコープを微調整してまた考えてみて を何往復もすることがあります。
ただ、これをやっておくことが、「何を達成したいのか」が明瞭な、鋭く光る機能を作るための大事なプロセスだと考えています。
(3) コア要件から小さく実装し、フィードバックを回す
またそのほかに気をつけているのが「最初から大風呂敷を広げすぎない」 ことです。自分自身が必要だと思い込んでいる場合もあれば、「〇〇の機能がないと使えない」という要望を受けることもあります。それらを鵜呑みにして全部を盛り込んだ機能を作ると、
機能提供までの時間が長くなる
リリースしたものの意外と使われない
メンテナンス工数だけが積もっていく
という悲劇が起きがちです。そこで、ユーザーが本当に使うコア機能だけを先に作る → いち早く実用環境に載せる → ユーザーからの実際に使った声を集める → アップデートを繰り返す …というサイクルをまわすことで、不要な機能を開発するリスクを低減しています。
コア機能は何なのかの見極めは、言うのは簡単ですが難しい作業だと思います。私はここでも、具体例に立ち返って考える事が多いです。例えば、紙と鉛筆で全てやるならばどうなるのか、一番機能化になる箇所はどこか、その箇所だけだと本当に利用できないのか を自分がやるとしたらどうなるのかで考えていきます。
また、ここはユーザーのヒアリングの方法にもコツがあるかなと思います。例えば「どこまでを機能化できるといいですか？」「この機能も欲しいですか？」と聞くと、本音を言うと全部あったほうがいい になってしまいますが、もし「この機能だけなら早く作れそうですが、それでも使いたいですか？」と聞いたら、Yesなのか、Noなのか、その理由は何なのかという具体的なヒントを貰うことができたりします。
※抽象的な話でイメージし辛いかもしれないですが、もし良い具体例を思い出したら追記します。
2. 機能だけでなく「営業・導入プロセス」も含めて考える
標準化というと「汎用的な機能を作ること」に終始しがちですが、実は営業・価格設定・サポート体制まで含めたトータルの設計を行うこと が非常に重要です。
売りやすい・説明しやすい機能になっているか
価格や利用規約に影響はあるのか
サポート体制・窓口はどうなるのか
カスタマイズはどう考えるか
など機能開発以外の部分も事前に決めておかないと、うまくユーザーに使って頂く事までたどり着かなかったり、営業やサポート面で想定外の問題が発生し対応コストが増えてしまい、機能化メリットを十分に実現できない可能性もあります。
PRD（プロダクト要求仕様書）を作る段階で、エンジニアだけではなく営業やカスタマーサクセスも巻き込んで、「売るところからアフターサポートまで、どのような形で提供できるのか」 を一緒に検討していきます。
機能を作る段階でこうした販売・導入フローを意識しておくことが、プロダクトが長く使われる鍵になると感じています。
3. レビュー文化とチーム力
これは「標準化」に限った話ではないですが、チーム内のレビュー文化 を育てることを大事にしています。
エンジニア複数人でひとつのタスクを一緒に片づける
仕様の境界ケースやデータモデルの矛盾を早めに発見し、対応する
当たり前のことですが、忙しい現場だとひとりで抱え込んでそのままリリースしてしまう例が散見されます。そういった対応が続くと、最終的には誰も全体像を把握できなくなります。
特に「標準化」のプロセスは、曖昧な要件定義や散らかった仕様が一箇所に集約されやすい ので、早期にレビュー文化を構築することで、プロダクトの全体像をチーム全体で共有することができる様になります。
ニトエルでも、レビュー文化の定着を重要なものと捉えており、毎朝1時間、定例でPRDレビューをする時間を確保しています。
ひとりで作りこむことよりも、生煮えでも良いのでスピードを重視して持ってくることを推奨しており、相互にフィードバックを受けやすい形にしています。これによりバッチサイズが小さくなり、ムダな工数の削減が可能にもなります。
また、PRDレビューには営業や導入・保守担当にも参加してもらっており、「営業・導入プロセス」の観点でのフィードバックをもらえる状態にしています。
おわりに——「標準化は“引き算”の連続」
まとめると、私の考える標準化は「ユーザーの要望を全部足し算する」のではなく、「本質以外は思い切って引き算する」 作業です。
“全部盛り”に抵抗できるかどうかは、開発者だけで行えるものではなく、営業やCSの協力が必要不可欠です。
また、社内だけではなく顧客の理解を得ることも必要です。顧客の理解を醸成するためにも、まずは自社内で「要らないものを作らずに済む」文化と仕組みを築くことが重要です。
Key Takeaways
「自分だったらどうする？」の視点で本質を掘り下げる
例外ケースを徹底的に洗い出し、定義・境界を磨く
まずはコア機能だけ小さく実装、ユーザーフィードバックで育てる
販売・サポート体制も含めた“標準仕様”を設計する
チームでレビュー文化を育て、“曖昧さ”を早期に炙り出す
もし同じような課題に悩んでいる方がいれば、ぜひ参考にしていただけたら嬉しいです。それでは、次回のTech Blogもお楽しみに！
執筆者：橋本
製造業向けSaaS開発を担当するエンジニア。前職では海外拠点やスタートアップでPM/事業開発を経験。趣味はランニングと新しいビジネスモデルの妄想。最近、第二種電気工事士の資格を取得しました。