「プロダクトを作るということ」を徒然なるままに考える
はじめに
徒然なるままにこれまでの化学メーカーでの製品開発経験やITエンジニアとしてのプログラム開発経験から「プロダクトを作る」ということについて、一般化（抽象化）してみました。この内容が誰かの参考になれば幸いです。
プロダクトのキーは「ニーズ」ですが、ニーズに応えるといった方向性のプロダクト開発とニーズを作り出すというプロダクト開発があると思います。
ニーズを作り出すということはスティーブ・ジョブズが生み出したiPhoneのように、これまで欲しいと考えたこともなかったものが新たに表れて、欲しいと思わせるタイプのプロダクト開発のことを意味します。
この手の仕事の話の方が面白いかもしれませんが、業務として経験がないため、ニーズに応える方向性のプロダクト開発に限定して書いていきたいと思います。
ニーズに応えるときには「自然との対話」が必要なものと、「人との対話」が必要なものがあります。
それぞれについてどのように考え、取り組んでいったか書いていきたいと思います。
自然との対話によるプロダクト開発
化学メーカー時代（半導体の加工用の溶液を作成していました。）の経験を元に書きますが、主に自然科学を利用したプロダクトの開発に関するものになります。
何か指標となる性能があり、それを満たすようなものの開発という観点です。
私は開発フェーズを大きく２つに分けており、「拡散のフェーズ」と「収斂のフェーズ」と認識していました。
１．拡散のフェーズ
ここが一番難しいフェーズで上手くいきそうな方向性を探すというフェーズになります。
もし十分な時間や予算があるのであれば考えうる全てを試すこともできるかもしれませんが、大まかな方向性がなければほとんど不可能なことだと思います。
そこで私が意識していたことを以下に記載します。
・良さげな過去データがないか集める
当然自社のデータが最も近いことをやっているので、自社データに財宝が隠れている可能性があります。
良い過去データが見つかれば一気に答えに近づきます。
特に見落としがちなのは、ある実験においてネガティブだったデータです。Aという性能を達成しようとしていたが、Bについてなぜか良い性能が出たが、Aについては未達だったといった具合になり埋もれます。
今回着目している性能がBだった場合には、これは答えになりえるわけです。
大切なことは自分の実験や他者の実験について、いま求めているものと違ったとしても、予想に反した結果が出た場合、心に留める、又は何かに記載してストックしていくことだと思います。
また合っていても間違っていても良いので、その結果が出たモデルを適当に考えておくと心に留めて起きやすくなります。
・異分野との組み合わせ
その課題のことを考えて寝て待っていると、稀に異分野とのつながりがみえることがあります。
例えば「半導体の洗浄」と「食器洗浄」も異分野との組み合わせとも言えますし、「化学」と「生物学」が結びついたプロダクトもあります。
異分野との誘発を狙って起こすことは難しいのですが、モデルを図に示したり、キーワードから類似するものを探す連想ゲームをすることも有効に働くことがあります。
・関連しそうなパラメータをなるべく大きく振る
何かを探すときはパラメータを大きく振ることをお勧めします。
良い発見は思い込みの範囲外にあることが多いからです。
例えばAという添加剤の影響を知りたければ、「Aが入ってないとき」、「Aが微量」、「Aについてその業界の常識の範囲内の量」、「Aについてその業界の常識の範囲を超えた量」といった感じです。
ただ気をつけたいのは、その他のパラメータも動いてそちらが影響している可能性もあるということです。
Aを増やしたら実は「粘度」というパラメータが効いていて、そちらが効果があったといった具合です。
そのため場合によっては切り分け試験も必要となります。
２．収斂のフェーズ
上手くいきそうな方向性を見つけたら、それがなぜうまくいったかについて仮説（モデル）を考えます。
そしてその仮説通りであれば、他のこれでも上手くいくか等を試し、
「何を入れるかの最適化」を行います。
（例えばアミノ酸が上手くいきそうであれば、どのアミノ酸が一番うまくいきそうかといった具合です。）
勿論この仮説検証中にも予想外のことが起きます。
これがまた「良さげな過去データ」になりえるわけです。
最後は「どれだけ入れるかの最適化」の微調整になります。
ある要素を固定して他の要素を振ったり、実験計画法等を使用して最適解を探すことになります。
３．商品戦略
ここまでで開発したものはまだ世に出ていないわけですが、世に出るためには知的財産のフィルターを通る必要性があります。
まずは権利侵害していないか調査することになりますが、侵害していない場合には逆に権利化できないかということを考えます。
まねできそうにないものであれば出願しない方法もありますが、他社に権利化された場合、先使用権で戦う必要性があります。
先使用権の主張もハードルがありますので、他社の出願を防ぐ意図で出願だけしておくという戦略もあります。
仮に出願する場合は、明細書の記載や実施例は充実させておきたいものです。
権利の範囲は請求項に記載された内容になりますが、権利範囲が広いものは特許になりにくいという性質があります。
そのため補正されることが実務上は多いです。
その際に明細書や実施例が充実していると、権利範囲の補正に使うことができ権利化にも近づきます。
人との対話によるプロダクト開発
プログラマーの経験を元に書きますが、顧客の要求仕様を元に開発されるプロダクトに関するものになります。
私自身はスクラッチ開発が多いので、その経験に引っ張られたものになると思います。
また正しい回答は様々な書籍を参考にされた方が良いと思いますので、私の経験上感じたことを記載します。
１．要求仕様
顧客によって異なりますが、顧客が当該製品やサービスに詳しい場合（組み込みにて経験したパターン）は、相談しながら進めると指摘が鋭いものの出戻りが少なくてすむことが多いです。
顧客が当該製品やサービスに詳しい場合、このフェーズは進みやすいですが、後で想定と異なるといったことで出戻りが発生しやすくなります。
きちんと仕様を握っておきましょうという風に言われますが、難しいのが現状なので、ダメージコントロールや交渉することが実務上は必要かと思います。
また相談しやすい空気を作り出すため雑談等も有効だと考えています。
２．設計
最近は様々なサービスをつなぐことが多いので、本格的に実装する前に簡単で構わないので早めに疎通確認はした方がよいです。
またドキュメントも良く読んだ方がよく、API使用時には使用回数の制限などの落とし穴も存在します。
簡易的にでも良いので、早めにそもそも実現可能なのかといった基本的な調査は済ませておいたほうがよいでしょう。
また再起動は想定しておいた方がいいと思います。
クラウドサービスを利用することも多いと思いますが、その場合は冗長化してリスクを減らす必要があるか検討が必要です。
また上手く稼働しないときは安全な方向に倒れるように設計しましょう。
最悪のケースを避け、顧客には不便かもしれませんがまだいい方向に倒れるように設計することをお勧めします。
３．実装とテスト
テストについてはExcelにペタペタレベルの業務が多かったので、ここで言及することは避けます。
実装については、私にとって一番大変だったのが実装の最初の一歩でした。
書籍を読んでプログラミングの基本は分かっていたのですが、実際にフローから実装に起こすところで苦戦しました。
以下の感覚を得てから、実装ができるようになったのでその感覚を記載します。
・C++について
C++の実装については、プログラミングの基本部分で躓いていました。疑問は以下の２つです。
疑問1) * の使い方
疑問2) ポインターやアドレスを関数の引数に使う意味
疑問１については * が３つの意味を持つ演算子であるために躓きました。
「かけ算」、「ポインタ変数を宣言する時に使用する記号」、及び「間接参照演算子」といった３つの意味がありました。
特に間接参照演算子を見落としていて分からなくなっていたので、同じとこで躓いた人は確認してみてください。
疑問2については、引数に使われたデータを書き替えることができると気づいて解決しました。
引数を使って何らかの処理をするという頭になっていたので、引数自体を書き換えるのかと思い、はっとしたのを覚えています。
・C#について
クラスの感覚がイマイチまだ掴めていませんでした。
これは個人的な感覚なのですが、データを「色のある水」、クラスを生成することを「容器を作ること」とイメージし、クラスにデータを入れ変数に代入するときには、容器からある色が分離されて注がれるイメージができたときに解決しました。
//Aコントロール(a1)に画像ファイル(test.png)を表示
A pg = new A(“test.png");
this.a1.Image = pg;上の例では test.gif がデータ(水)であり、new することでAという容器を作成し、Aという容器にデータを流しこんでいるイメージになるわけです。
さらにそこである色に分離された水が pg という変数に注がれているイメージです。
誰にとっても有効なイメージではないと思いますが、データを水のように考えることが参考になる方がいれば幸いです。
４．運用
ある日急に止まったと言われることがありますが、こういったときのためにもログ設計は大切です。
最近はマイクロサービス化が進んでおり、連携先や連携元の仕様がいつの間にか変わっていることがあります。
こちらに落ち度が無くても止まることはあることを想定して、心を落ち着けて、自分のプロダクトのログ、他社サービスの情報収集を行うことをお勧めします。
この記事が気に入ったらサポートをしてみませんか？