新製品ができあがるまで

みなさん、こんにちは。
とどろきでございます。

今回は新製品ができあがるまでについて説明しようと思います。

私が就活生の時、「開発に興味があるんだけど、実際どんな業務しているか分からないから、働く自分をイメージできない」ということがありました( ；∀；)
働く自分をイメージできないと、自分が御社でやりたいことなんて、見つからないよ。。。

というわけで

自分が開発で働く姿を想像しながら、就職活動したい
これから開発者として就職するんだけど、働く姿が見えない
開発以外の職種に興味があるんだけど、開発者以外は開発にどう関わるの？

という疑問をお持ちの方向けにこの記事を書いています。少しでも、開発に興味を持ち、自分が働くイメージを付けていただけたらと思います。

本題に入る前に私の自己紹介を載せておきます。

名前：とどろき
職業：BtoB装置メーカーソフトウェア開発者
経験：製品開発部隊にて、社会人1年目～3年目まで経験を積む。ソフトウェア開発者として配属されるも、日々問い合わせ対応に追われ、コーディングは3年間で3日間くらいしかやらなかった（笑）。4年目から技術設計部隊に異動し、現在に至る。そこそこコーディングをする毎日を送る。

それでは、本題に入ります。

1. 開発の全体像の把握

まずは開発の全体像について説明したいと思います。

みなさん、開発ってどんなものをイメージしますか？

私が学生の時は、

「なんかテーマがあってそれをみんなで作っていく」

くらいの漠然としたイメージしかありませんでした。

大きく見たときは、そうなんですが、実は製品ができあがるまでには、みなさんが想像できないほどの人間がかかわり、想像できないほどのステップを踏みます。

1.1 開発の流れ

製品ができあがるまでの大まかな流れを示した図が以下です。

大きな流れとして、

プロジェクト起案準備
↓
プロジェクト起案
↓
いわゆる、私が想像していたザ・開発
↓
開発品の評価
↓
販売準備
↓
リリースというようになります。

私が就活生の時は、ザ・開発というところあたりしかイメージしていませんでした。

もう少し細かく流れに沿って説明していきたいと思います。
私が開発部隊にいるので、ザ・開発に関する説明のボリュームが重めですが、是非読んでいただければ幸いです。

2. 各段階でやること

商品企画してからリリースされるまで、各段階でどのような部署がどのようなことをやるのかということを詳しく説明していきます。

2.1 起案準備

起案準備として、商品企画と実現性検討をする必要があります。

2.1.1 商品企画

それではまずは商品企画から見ていきます。

商品企画とはその名の通り、商品を企画します。

企画というと、具体的にはお客様の要望や市場の動向から次に何を作るか決めます。

大まかな観点としては、(What, Why)という観点です。
・何を作ったら売れるか？(What)
・なぜこの製品を作ったら売れると想定できるか？(Why)

この段階では製品開発部隊(製品企画部※1)、技術営業、アプリ開発、営業が関わります。

営業部隊だけでは本当に製品が作れるか分からない、また開発部隊だけでは本当に製品が売れるか分からないので、このように営業寄りの部署と技術よりの部署が組んで、商品を企画します。

※1　会社によっては製品開発部隊が企画するのではなく、製品企画部という部署がある会社もあります。OB訪問で聞いてみましょう。

商品企画が終わったら、次は実現性検討に入ります。

それでは今回は商品企画にて

「例：ワンタッチで精細な写真が撮れるカメラをつくる。」

ことが決まったという想定で以降書きます。
このほうが、みなさんも開発のイメージがつきやすいと思います。

私はカメラを作ったことはありませんので、そんなんじゃ作れないよというコメントは受け付けません。（笑）

2.1.2 実現性検討

次は、実現性検討です。

実現性検討での大まかな観点は以下です。

・必要なリソース、お金は？(Who)
・どうやって作ろう？(How)
・いつまでに作ろう？(When)

この時にかかわる人間は、製品開発部隊、研究開発部隊、技術設計部隊です。

製品開発部隊は必要なリソース、予算の確保、各種スケジュールの調整を行い、プロジェクト計画を立てます。

例えば

AさんとBさんが余裕があるから、この2人を割り当てる。
年間何台売れる見込みが立つから、研究開発費は何年で回収できる。
いついつの展示会に出すことで販売促進ができるけど、本当にその時期にリリースすることができるか。できないならリソースを増やさないと。

と言ったように、この実現性検討フェーズでは、リソース、期間、予算などの観点からプロジェクト計画を立てます。

技術設計部隊は、研究開発部隊よりは上流の課題の調査を行います。ソフトウェア担当であれば、どこは既存技術が流用出来て、どこは新規設計しないといけないかなどの調査を行い、どのくらいで開発が完了するか期間の見積もりを行います。またその見積もりの過程で見つかった課題があれば、プロジェクト起案準備と並行して、課題解決の目処を立てます。

研究開発部隊は、技術的に課題となるコアな部分の解決策の調査を行います。

今回例に挙げたカメラで説明すると、例えば、以下のような機能を実装するとします。

研究開発では、上図で示したような黄緑色部分の
「精細な写真を取得する必要があるため、製品のコアとなる画像の補正部分という新たなアルゴリズムを作成する」
という課題解決の目処をたてます。

技術設計では、
「シャッターを押してから、画像取得、補正、保存の一連の流れを作る中で、どこを流用するか新規設計するか」
など全体的な技術の課題調査を行います。

2.1.1 商品企画と2.1.2 実現性検討が終わってはじめてプロジェクトを起案することができます。起案が完了したら、ようやく開発に入ります。

2.2 ザ・開発

開発は設計して、作って、問題ないか自部門でチェックするという流れでものを作ります。

この段階では、実現性検討と同じように、製品開発部隊、研究開発部隊、技術設計部隊が関わります。

基本的に
製品開発部隊は全体のスケジュール調整、関係部署との開発に関する会議などのプロジェクト全体に対しての進捗を管理します。またおかしな製品にならないように軌道修正するのもこの部隊の役割です。
技術設計部隊はプロジェクト全体の技術設計を行います。
研究開発部隊はコアな部分の課題解決を行います。
会社の規模が大きいほど、仕事の役割がきっちりしており、小さくなるほど仕事の境界が曖昧になります。

余談ですが、

開発には大きく分けてアジャイル開発とウォーターフォール型開発の2種類あります。簡単に説明すると以下のような違いがあります。
①アジャイル開発：ソフトウェア開発で取り入れられている。柔軟に仕様変更に対応できるというメリットあり。
②ウォーターフォール型開発：本書のように緻密に計画を立て、仕様変更はしないという前提のもと開発を進める手法。
ハードウェアの開発は、アジャイル開発はあまり聞きません。一方でWebアプリなどのソフトウェア開発はアジャイル開発が普及しています。それぞれの詳細な開発の違いは本書の範疇を超えるので、他の人の記事を読んでほしいです。

今回は、ウォーターフォール型開発で説明を行います。
ウォーターフォール型開発は以下のような手順で開発を進めます。

要件定義→構想設計→詳細設計→作る！→設計検証
作る！というのはソフトウェア開発であれば、プログラミングですね。
プログラミングに関してはこのnoteの範疇を超えるので、また別の機会に。。。

今回は「ワンタッチで精細な写真が撮れるカメラをつくる。」というテーマで模擬的にザ・開発をしてみようと思います。

私はソフトウェア開発者であるため、ソフトウェアに重きを置いて説明していきます。メカ、電気の設計も大まかな思想は同じです。

2.2.1 要件定義

お客様や市場の「～したい」という要望から何をするかまとめたものを要件定義と呼びます。この要件定義がしっかりしていないと一生開発は終わりませんし、良いものもできません。開発の肝とも言えます。

今回のカメラで言うと、以下のように要件定義ができます。

■要件定義：ワンタッチで精細な写真が撮りたい
↓もう少しばらすと
①ワンタッチで写真が撮れること
②撮れた写真が精細であること

が要件定義となります。

2.2.2 構想設計

次に構想設計に入ります。

構想設計では、要件定義を実現するために、「製品を外から見たときのふるまい」を言語化します。そのためにまずは製品の全体像を把握します。

今回のカメラを対象にすると、シャッターがあって、撮像素子があって、記憶領域があって、補正を担う画像処理エンジンがあってというように全体像を把握することから始めます(下図参照)。その後、要件定義を満たすように開発項目を洗い出します。

今回ソフトウェア開発に限定しますが、以下のように外から見たふるまいを言語化します。

要件定義①ワンタッチで写真が撮れること
→構想設計①-1　シャッターを押すと画像を取得すること

要件定義②撮れた写真が精細であること
→構想設計②-1　撮像素子を用いて画像を取得すること
→構想設計②-2　画像を補正して、精細な画像が取得できること
→構想設計②-3　補正した画像を保存できること

ここまでできたら構想設計は終わりです。

2.2.3 詳細設計

次は詳細設計に入ります。詳細設計では、構想設計を実現するための内部処理のふるまいを言語化します。

例えば、以下のように詳細設計ができます。

要件定義①ワンタッチで写真が撮れること
→構想設計①-1　シャッターを押すと画像を取得すること
→→詳細設計①-1-1　シャッターを押すと撮像素子に電気的な信号を入れること

要件定義②撮れた写真が精細であること
→構想設計②-1　撮像素子を用いて画像を取得すること
→→詳細設計②-1-1　電気的な信号が入った瞬間から1秒間露光して撮像素子から画像を取得すること
→構想設計②-2　画像を補正して、精細な画像が取得できること
→→詳細設計②-2-1　取得した画像から画像の補正用パラメータを計算すること
→→詳細設計②-2-2　補正用パラメータを使用して取得した画像を補正すること
→構想設計②-3　補正した画像を保存できること
→→詳細設計②-3-1　補正した画像を新たなファイル名にして保存すること
→→詳細設計②-3-1　ファイル保存形式はjpegにすること

詳細設計にてここまで言語化できたら後は楽勝です。ソフトウェアであれば、プログラミングします。ハードウェアであれば、図面に起こし、手配をかけ、工場の人に組み立てるよう指示します。ここは自分でやったり、外注したりします。大まかな目安として、コアな部分は自分でやりますが、画面の作りこみなど開発の本質ではない部分は外注に投げたりします。そのあたりは別の機会に。。。

2.2.4　設計検証

これでようやくものができました。できたものに問題がないかチェックします。

製品が仕様通りにできているかという観点から製品開発部隊、技術設計部隊がテスト計画をたて、テストを行い、不具合修正を行います。テストには多くの種類があり、ソフトウェアに関して言えば、ユーザーに近いテストから、開発者しか分からないホワイトボックステストなど、多々あります。ハードウェアのテストだと、耐久試験、連続試験、運搬試験などがあります。テストする人間は外注したり、内部の人間がテストを行います。

カメラで言うと、テスト項目は山ほどあるので、こんな感じというのだけ以下に示します。
ソフトウェアテスト項目①　正常に補正できた画像が出力できること。
ハードウェアテスト項目①　カメラを運搬しても壊れないこと。
などなど・・・・

製品開発部隊、技術設計部隊、(研究開発部隊)が一通りチェックし、見つかった問題を解決できれば、ようやく別の部署に手放すことができます。

2.3 評価

いよいよ製品リリースまで近づいてきました。
設計検証までが終わったら、次は品質管理部隊に渡し、妥当性確認と生産性検証を行います。品質管理部隊は2つに分かれていることが多いです。一つは製品の質を管理する部隊、もう一つは生産の質を管理する部隊です。
妥当性確認は製品の質を管理する部隊、
生産性検証は生産の質を管理する部隊
が担当します。

まずは妥当性確認から説明します。

2.3.1　妥当性確認

製品の質を管理する部隊が、
製品をリリースして良いものか最後の砦となり、
チェックします。
チェックする項目は大きく分けて2つ。
①不具合、不備がもうないか。
ソフトウェアの不具合がないかのチェックは当然のこと、製品に関わる全てのドキュメントのチェックを行います。開発文書であったり、お客様に提出する文書であったり、ありとあらゆる文書のチェックを行います。
②危険なところがないか(メカ、電気回路など。)、怪しいところがないか
危険なところはないか、クレームに繋がるようなキナ臭いところはないかを確認します。
特に②については、ここまで開発が進んでいるのに大きな問題が発覚してしまうと全てが詰んでしまうので、こまめにこのあたりは評価し、技術と品質管理の間で擦り合わせます。

カメラでいうと、異常な熱を持っているところがないかなどをチェックします。こちらも確認項目は山ほどあるので、割愛します。

2.3.2　生産性検証

製品の質を保って生産することができるかチェックします。
・購入品の質を担保するために、購入品の入荷基準は決まっているか
・組み立ては誰がやるか、その教育はだれがやるのか
・原価達成できるのか
・組立工数はどれくらいかかるのか
などなど
こちらも開発の後半で発覚するとまずいことばかりなので、評価が始まる前までにやばそうなところはすり合わせておきます。

カメラで言うと、例えば、他社製品の撮像素子を使用することになっているが、その素子の入荷基準は決まっているか、その基準は要件定義を満たすために妥当かということをチェックします。
こちらも山ほど確認事項はあるので割愛します。

2.4 販売促進

いよいよもうすぐリリースとなります。

製品開発と一緒にアプリ開発、技術営業、営業が販売促進します。
販売するためにどれだけ新製品が優れているかを宣伝できるものを作ります。

アプリ開発であれば、カタログに載せる用に、新製品を使って、きれいに撮影する方法、きれいに撮影できる対象を考えます。
技術営業であれば、従来自社製品および他社製品との比較表の作成や、営業のためにFAQみたいなものも作ります。また社内に知らせる文章、お客様に見せる用のカタログも作ります。

こうやって多くの人が関わってようやく製品がリリースされるわけです。

リリースされたら、営業はお客様にお知らせします。

ここでようやくみんなで飲みにいけるわけです。。。

リリースされてからも大変なのですが、それはまた別の機会に。。。

3.　さいごに

最後まで読んでいただきありがとうございます。

最後にまとめますと、新製品開発には多くの人が絡み、おおよそは以下のような流れで進みます。

製品開発部隊だけでは新製品の開発は不可能です。なので、就職活動では人との関わりをもった経験が理系であっても重要視されます。

全ての新製品開発がこの流れに添うわけではありませんが、大きくはこのような流れになっているはずです。会社による開発の違いはOB訪問で確かめてみてください。このnoteをOBの方に見せて「ここはどうなのか教えてください！」と言っていただいて構いません。そうすることで自分がその会社で働くイメージをつけることができ、さらにはその会社でやりたいことが明確になると思います。

今回の記事は以上となります。もしご不明点、コメントがあれば、本記事へのコメントかtwitterもやっておりますので、是非ご連絡ください。