【よくわかる】ベンダー系エンジニアはどうやって勉強するのか（製品編）

こんにちは！Nozinekoです。

今日は僕がこなしている業務に必要な知識の学習をどうやって実行しているのかを紹介します。

ベンダー系エンジニアがこなす主な3つの業務については以下の概要編でも触れているので、「どんな事してるんだろう？」という方は見てみてください。

nozineko.hatenablog.com

Web系エンジニアでもなければプログラマーでもないベンダー系エンジニア。

自らの手で製品を作り上げるわけではありませんので、自分たちが扱う製品をどのように知り、学習するのか？

その一端を紹介したいと思います。

インターネットで情報を探す、社内にある製品資料を読む

まずは第一歩ですね。

独学チックな雰囲気が漂っていますが、これがメジャーであり鉄板です。

プログラム言語などのように製品ごとに教本やマニュアルが一般の書店においてあるわけではありません。

ですのでまずは勉強するための資料そのものを探すところから始める必要があります。

繰り返しにはなりますが、ベンダー系エンジニアは自分たちでプログラムを書いてシステムを作り上げることは（ほぼ）ありません。

シスコシステムズさんのような海外メーカさんが作っている製品を「組み合わせて」一つのシステムとして完成させることがほとんどです。

ですので、製品の事を知るにはやはりメーカさんのホームページやコミュニティ（掲示板など）で情報を探す事がほとんどです。

もちろん、必要な情報を毎回探していては時間がかかりすぎてしまうので、システム設計に必要な情報やガイドラインなどは勉強資料としてまとめておきます。

また、アップデートも頻繁に行われますのでその情報も逐一資料にまとめつつ知識・情報の共有をエンジニア同士で行っていくことが大事です。

例えば僕が担当しているIP電話であれば知っておくべき事は以下のようなものがあります。（一例です）

・IP電話機

　種類、型番、動作するプロトコル、使える機能...etc

・交換機（呼制御サーバ）

　サーバのキャパシティ、動作するプロトコル、設計思想...etc

・ビデオ会議端末

　種類、型番、画質、同時会議時のレイアウト表示、使える機能...etc

・Web会議システム

　キャパシティ、対応端末、設計思想、接続方法...etc

・付帯設備

　ルーター、スイッチ、DHCPサーバ、NTPサーバ、DNSサーバ...etc

・IP電話システムの設計思想

　番号計画、電話機能、コールルーティング思想、デバイス設計思想...etc

などなど。

これらはほんの一例ですが、各パーツをそれぞれ学び組み合わせて行く事が必要です。

メーカーが提供している講習会（製品トレーニング）に参加する

よくあるケースその2ですね。

シスコシステムズさんの場合、パートナー制度がありシスコさんのパートナーとして認定されると製品の講習会などを無償で受講する事が可能です。

もちろんいつでも参加できるわけではありませんが、自分が担当している製品のトレーニングなどが有る場合は積極的に参加して情報を集めることが必要です。

※パートナー制度についてはまた別の機会に。

製品の講習会では以下のような事が学習できます。

・製品のアップデートや最新情報の紹介

・将来的な製品の開発計画（ロードマップといわれています）

・導入実績や事例の共有

・最新製品のハンズオントレーニング（実際の製品を使った講習）

重要なのは将来的な製品の開発計画ですね。

メーカさんが作った製品にはやはりライフサイクルがあります。

MicrosoftさんのWindowsでもそうですし、AppleさんのiPhoneでもそうですがメーカサポートを受けれる期間ってだいたい4~6年くらいですよね。

僕が担当しているIP電話の製品もおおよそ5年くらいでサポートが切れてしまうことが多いです。

製品のライフサイクルを考慮し、自分が担当しているお客さんが「いつ」「何の製品を」導入しているかを把握する事で、導入した製品を新しくする時期をおおよそ予測する事が可能です。

その予測した時期に合わせて最新製品や将来のロードマップを加味し、新しい製品を組み合わせて提案して買ってもらう事がビジネスを考えていく上では必要なことになります。

もちろん、お客さんの中には「使えてるからサポート切れてもいいや」という方たちもいらっしゃいます。

こればっかりはお客さん次第ですね。

導入実績を元にテンプレートを覚える

最近の製品は多機能になっている事もあり、非常に覚えることが多くて煩雑になりがちです。

ただでさえ扱う製品が多い上に機能も多いとなれば、何をどう組み合わせるのがいいのかすら分からなくなることがあります。

そういった時は社内やトレーニングで知った導入事例を元に、製品の組み合わせ事例をテンプレート化することが必要になります。

製品の事を知っても不要な機能を実装してもお客さんが使う事はないでしょうし、機能を使えるようにするためにはお金も時間もかかります。

そういった手間を少なくするためには導入事例を元にテンプレート化してしまう事が一番効率がいいんですね。

（例えば、高価なPCを買っても用途がネットサーフィンしかしないのであればお金ももったいないですよね）

実際に触ってみる

いくら資料を読み、テンプレートを覚えても実際に扱えないのであれば意味がありませんね。

百聞は一見に如かず！あとは実際に触ってみるべし！

というのも自分たちで製品を作っているわけではないので、やはり細かい部分の仕様や動作確認はやってみないとわからない事も多いです。

動作確認の結果、明らかに自分が考えていた通りに動かなかった場合はメーカに都度問い合わせる必要があるため、調べるだけでは限界があります。

自分の手で動かし、見て、経験する事で動作や仕様を学んでいく時間も必要になるんです。

どうでしょうか？

Web系やプログラマの方たちとは違い、僕たちに必要な事は「製品そのものを知る」「製品の組み合わせを知る」事がほとんどです。

一つのシステムを作り上げるという観点では共通しているのかもしれませんが、アプローチする方法が異なるタイプのエンジニアだと思っていただければ幸いです。

社会人になっても勉強し続けるのはどこの世の中も変わらないのでしょうけれど、エンジニアは特にその傾向が強いのかもしれませんね…。

それではまた！