シリコンバレーではエンジニアとして生涯やっていても活躍できます。
優秀であれば高額な収入を維持できるでしょう。
業績の良い大手企業であれば年収も2500-3500万。
パフォーマンスが次第では4000-5000万、もしくはそれ以上も夢ではないと思います。

そんな中、シリコンバレーではかなり安い給料で自分はエンジニアとしてスタートしました。
自分の能力がシリコンバレーで通じるのか試したかったので給料という面ではネガティブ。
評価されれば上げてもらえるだろうと、オファーに対して特に交渉せずサイン。
       
入社してからはとにかく英語に慣れるのが大変。
意外にも技術的には割りと通じるものでしたが、今思うと最初の2年間くらいは普通のエンジニア。
ただ単にアサインされた業務をこなしながら周りのエンジニアの働き方や考え方を観察している日々。


3年後くらいには若手をメンターする立場。
驚くことにシリコンバレーのエンジニアを指導する立場にあったのです！
アメリカの有名大学を卒業するようなエンジニアは流石に基礎がちゃんとしており、自分も復習するいい機会でした。

そして多くのエンジニアに出会い何とかやっていけるもんだなと思った頃にはリードエンジニア。
エンジニアチームの計画を練って、プレゼン、プロジェクトマネージャーやプロダクトマネージャーと協力してプロジェクトを進行。
数人のエンジニアで一緒に立ち上げたプロジェクトが製品化が進むにつれ数10人、数100人規模のプロジェクトになったりもしました。
他グループにヘルプにいったり、逆にヘルプがきたりとグループをまたいでのプロジェクトも多く経験しました。

そんなエンジニアとしては順風満帆の毎日でしたが、感じていることがありました。
それは・・・

1. 自分よりできるエンジニアはいくらでもでてくる
2. 作業スピード・集中力が落ちてくる
3. 求められるエンジニアタイプが異なってくる
4. ハードスキル以上にソフトスキルが難しい

ということ。
これに対して自分のエンジニアとしての商品価値を10年後、20年後に維持できるかという自問をしてみた。


その１：できるエンジニアはいくらでもでてくる
優秀でかつモチベーションの高いエンジニアがたくさんいます。
自分のキャリアを高めるため自己評価がちゃんとできており、何よりもやりたい事や学びたいことがはっきりしています。
自分でなくてもできることがたくさんありますし、自分以上に良い働きをする人もいるでしょう。
そういう人をどうやってリードしていくかが大切になってくると思います。

その２：作業スピード・集中力が落ちてくる
プロジェクトではアジャイルやリーンスタートアップなど迅速に動く事が求められます。
新しいツールや技術に関して専門的知識を学び続けなければなりません。
ソフトウェアにしてもハードウェアにしても作業スピードや思考スピード、そして集中力は落ちてくると思う。
例えば Business Insider Japanの記事
「集中力は43歳！ 人間の脳のピーク年齢は、能力ごとに違っていた」
マサチューセッツ工科大学（MIT）の認知科学研究者による加齢に伴う知能の変化に関する研究を紹介している。
人それぞれかとは思うが自分は割と納得されられた。
自分もこの先エンジニアとしてチームに遅れをとり迷惑をかけることもあると思います。

その３：求められるエンジニアタイプが異なってくる
技術の進化は本当に早いと思います。
Gartnerの記事では技術のハイプサイクルが紹介されています。ハイプサイクルについてはこちら。
「5 Trends Emerge in the Gartner Hype Cycle for Emerging Technologies, 2018」
これをみても技術の動向は激しい状況、そして求められるエンジニアは変化していきます。
ある特定の技術だけでやキャリアの幅も狭まってしまい、その価値を持ったエンジニアが必要とされるでしょう。

その４：ハードスキル以上にソフトスキルが難しい
ハードスキルは割と皆そういう専門的教育を受けて身に着けてきているので、学びやすく利用しやすいと思います。
ソフトスキルはコミュニケーションやリーダーシップなど人というインプットに対してどうアウトプットするかが重要になります。
人それぞれだとは思いますが、比較的エンジニアがこの能力を身に着けるのは簡単ではないと思います。
しかしこの能力はとても重要でどんな職に就いたとしても重要視される能力でしょう。

技術の変動とは違い常に一定のものとして存在するもの、普段の生活や職場など様々な場面で活用できます。

以上4点を挙げましたが、こういったことを考えるようになって

• ハードスキルを向上させる以上にソフトスキルは早めに学ぶべき
• できればソフトスキルを身につけたエンジニアを育てたい

と思うようになりました。
そしてマネージャという職には今後の自分に必要な能力を身につけるための環境があります。
チームを管理し自分の思うように事を動かすのではなく、チームが事を動かし自分がソフトスキルを使って貢献する。

そんな理由でエンジニアを捨てマネージャーになることを決意しました。
書くと単純に思えてきましたが、これでも結構悩んだことを今でも覚えています・・・

では、また。アスタ　ルエゴ。

シリコンバレーでは製品としての技術だけでなく、プロジェクトとしての生産性を上げるための技術も進んでいます。
様々な方法が試されながら改善されていってるのです。
日本でも製造過程で手段が確立、活用されていますがシリコンバレーではどのようにプロジェクトを達成していくか興味ありませんか？

「こういった技術はシリコンバレーだから通じるんだ！」

「日本の会社、それも自分の今いる会社で通じるわけがない！」

と思われるかもしれませんよね？

でも、そんなことないと思います！
確かに会社や組織の方針により新しいプロセスを提案しても簡単に通らないことがあります。
それはそれで放っておきましょう。
そんなことに時間を費やしても労力の無駄だと思いますし、気力もなくなり精神的に参ってしまいます。

先ずは自分自身が意識改革し個人レベルでこういった技術を身に着けるのをおススメします。
多くの本は組織としてのプロジェクトを効果的に達成することを目的として書かれています。
ですが、それを組織として実践する必要はないのです。
僕がここでお伝えしたいのは自分自身に対して実践するということです！

今回はロッシェル・カップさんの書籍を主に参考にさせていただきました。
理由は

• 日本の会社の状況をとても良く観察されている
• データを元にポイントを明確に分析されている
• シリコンバレーでの具体的な実例がある
• 僕がシリコンバレーで経験している内容そのまま

日本、シリコンバレー両面の情報を非常に詳しく分析されており、非常に経験豊富な方だと思います。
    * Japan Intercultural Consultingはロッシェル・カップさんの経営されるコンサルタント会社

参考にした本は以下2冊。

前者は日本の状況とシリコンバレーの状況が非常にうまくまとめられていて導入としておススメです。
これを読んで自分の置かれた状況と照らし合わせてみてください。

「そんなことはない！自分も組織もモチベーションは高い！」
という方は良い組織でお勤めなのだと思います。
自分自身にではなく組織に対して実践できる環境なのだと思います。

後者は先ず最初に全体的なイメージを掴めればいいかなと。
その後気になったところをじーーーくりと読むのがいいかなと思います。

個人レベルで使えて私がおススメするのは3章にある以下のテクニック。

1. アジャイル
2. リーンスタートアップ

ここで学んだものを個人の業務レベルにどう適用できるか考えてみてください。
そして実践してみてください。
シリコンバレーでも組織レベルで達成するのは決して楽ではないものです。

ですが、個人レベルならよりフットワークも軽く実践し易いと思います。

例えばアジャイルであれば以下のようなことが考えられるかな。

• 自分自身でバックログを作成
• 顧客（ここでは上司、プロジェクトメンバー）のニーズにより優先付
• タスク内容を可視化、ツール化
• 自分自身のタスクでスプリント
• 打ち合わせで報告が必要であれば自分専用のタスク管理ツールを使用
• スプリント後は自己評価
• 結果やプロセスを含め改善点を次につなげる

リーンスタートアップであれば

• 最初からじっくり要求に対する検討をするのでなく先ず作る
• 顧客（上司やプロジェクトメンバー）の反応・フィードバックをもらう
  • 発表用資料などであれば先ずはコンテンツ・ストーリ作成時点で反応確認
• フィードバックから早く学び次につなげる
• フィードバックもらうときは自分の考えを先ず伝えて意見を聞く

基本的には顧客を会社にとっての顧客でなく、自分にとっての顧客に置き換えることでやり方が少し見えてくるのではないかな。
そして、実践するに際して別途専門書などで理解を深めると良いと思います。

時間はかかると思いますが、少しずつ試してダメなら何が違うのか考え自分なりにアレンジすれば良いと思います。
きっと数か月もすればどこかで変化を感じてもらえるのではないかな。


少しずつ個人レベルで身に着けられてそれが上司やチームメンバーに感じ取られるようであれば、その時がチャンス！

自分の考えを提案し、グループ・組織にインパクトのある一流社員になる一歩を！

それでは、また。アスタ　ルエゴ！
​​

最近は履歴書 (Resume) を見ることが多いので、履歴書について。
履歴書は就職、転職時に必ず必要な書類。自分を売り込むための重要なマーケティングツールですよね。
先ずは履歴書で自分に価値を見つけてもらい、その後電話やオンサイトの面接へと繋がっていきます。
とーーっても重要なものですね。
自分も履歴書を書く時にいつも悩み、時には書いていてブルーになります・・・
そんな追い込まれて書く必要がない様に、普段から見直しておきたいもの。

因みに職種によって書き方が色々違うと思いますが、ここではエンジニアを対象としています。
    っていうか自分がエンジニアなのでエンジニアしかしらん・・・というのが本音。

エンジニアといっても幅が広くソフトエンジニアであったり、ハードエンジニア、メカニカルエンジニア、テストエンジニアなどいろんなものがあります。
自分の場合は まあほぼ審査したことがありますが、メカニカル系はちょっと少な目・・・
　しかし、インダストリアルデザイナーの履歴書はきれいですごいと思った。
　因みに学生さんの履歴書を見てあげたりするけど、ビジュアル的に工夫する人も多いなぁと感じた。


履歴書のパターン
先ほど述べたとおり仕事の関係で割と多くの履歴書を見ることがありますが、まぁ大体の場合二つのパターンがみられます。
一つ目は全ての経歴を詳しく書くことで、３ー５枚くらいの構成となっているパターン。
二つ目は限りなく端折って必要な部分だけをまとめ１ー２枚くらいの構成となっているパターン。

まぁ、どちらが良いとか悪いとかいっていうのはないとは思いますが、その会社の規模や競争率の状況で変えるのが良いかと思います。
大企業などではおそらく募集をかけてから ２週間くらいの間に１００件以上の履歴書を受け取るだろうと考えられます。
　ニーズの高い技術市場では1週間のうちに１００ー２００件以上はありそうかな・・・最近で言えばAI系だとか

そのような状況が想定される場合、審査する側からすると後者の方がウケが良いだろうと思います。
伝えたい事がうまくまとめられていて、かつ自分の売り込みたいところが自分ではっきりわかっていると捉えることができます。

これに対して前者の場合は 今までやってきたこと、関わったことを列挙して書かれていて一見良いようにも思えます。
しかしながら、審査側は多くのものに目を通さないといけないため必要ないところと一緒に読み飛ばされる可能性もあるでしょう。
比較的小さな企業なら応募も少なくじっくりと読んでくれると思いますので、こういった状況では前者も良いかと。


相手を知る
ではどうしたら良いか・・・
自分なりに考えてみると、やはり「履歴書を書く前にじっくりと応募する会社について調査する」というのが基本かなと思います。
普段使っている履歴書を転用して汎用的に書くのではなく、自分が受けたい会社の”必要案件にあった”内容に沿って書き直すべきだと思います。

この必要条件とはなにか？
これは募集内容に記載されている ”Requirements" や "Qualifications" に相当します。
その会社が必要としている人材がどんなものであるのか、それに対して自分がどう売り込むことができるのか。
先ずはその辺りに関してじっくりと考えて履歴書をアップデートするべきだと考えています。

募集内容には経験年数や必要な技術などが細かく記載されています。
記載された技術内容から大体扱う製品やプロジェクトもおよそ検討がつくかもしれません。
そういった情報からプロジェクトの規模や競争率の高さなどを推測し、プランを練るのが重要だと思います。
全てが当てはまればそれに越したことはないですが、必ずしもそういうケースはないでしょう。
その場合でもあきらめる必要はなく、足りていないところをどう補うかを考えれば良いかと思います。


自分を売り込む
ある程度相手が見えてきたら、次はどう自分という”商品”を売り込むか。
言ってみれば製品紹介のビラ作りですね。
書き方は人それぞれで、何が良いというのもなく非常に難しいです。
自分の場合は次の３点に注目して書くことにしています。

その１：キーワードを加える
ほとんどの企業の場合、Hiring Manager が募集を HR に依頼すると思います。
そして募集を Website などに載せてから誰が最初に応募者に目を通すか。
私の経験上はほぼ HR の担当者が最初にスクリーニングをかけるでしょう。
この時重要となるのは技術面をあまり良く知らない HR 担当者はキーワードを重視します。
募集内容にあるキーワード（技術内容、製品アプリケーション、経験年数、業務内容など）が履歴書の中に見られるか。
全く同じでなくても似ているか。

ここで HR からみてキーワードが乏しい場合は Reject されてしまいます。
ここでパスした応募者は確実に Hiring Manager の元へいくでしょう。
ですので、募集内容を今一度確認し、同じもしくは似たキーワードが履歴書の中で見られるかを確認するの重要と思います。
　自分もたまに HR のスクリーニングで消されてしまったもったいない人材がいないか確認しにいくことも・・・

その２：今まで何を達成して何に貢献したのか
おそらくほとんどの Hiring Manager が期待するのは自律できて自発的に、積極的に行動してくれる人を期待すると思います。
単に「こういったプロジェクトでこれやりました」という内容の列挙では、言われた仕事をやってきただけに見え雇う側もあまり期待しないでしょう。

そこで重要なのは自分が今までの会社でどのようにモチベーションを維持し、貢献をしてきたかということかなと。

この時考えたいのは、プロジェクトの目的に対して達成した内容（タスク）だけでなく、それ以上の何かを伝えること。
達成したものが実際どういう貢献度として現れたのかを数字で示したりするのも良いですし、小さくても自分が立ち上げたプロジェクトやプロセスも良さそう。
特に車内の貢献度として具体的に説明できれば組織としての自分の立ち居地をしっかり理解している自律した人材だと思われるかもしれません。
　言いすぎかな・・・でも少なくとも自分はそう思う・・・

例えば、自分が所属していたグループにおいて何が足りなかったのか、何が必要だったのか。
その課題に対してどういうアプローチをしたのか。
それによって グループがどう改善されたのか、という点が重要だと思います
この時、利益として大きな効果が表れていれば プラスですが、そうでなくても データとして何か値が得られていれば大きなプラスとなると思います。
　社外秘などの情報には注意しないといけません・・・公表されている情報から自分の貢献度をどう記載するか・・・

その３：何が募集内容にマッチングするのか
次は何と言っても募集内容にどうマッチするかですかね。
自分はここが一番難しい・・・
最初にどーんと書くのも良いですし、カバーレターにするのか。
　そう言えば最近カバーレターってあんまり見ないなぁ・・・１－２割くらいかな付けてくるの。

おそらくは電話、オンサイトの面接で確認されるところだとは思いますが、履歴書にも付け加えておきたいところ。
はっきりとではなく何となーく匂わせておくくらいにとどめていくのがベストかなぁと思っています。
とはいっても ”その１” と "その２" で上手く文面を作りこんでいけば自然とここはカバーされるとは思います。
　自分は文章下手なので・・・少し肉付けしたりも・・・

また仮に自分の経歴が募集内容に合わないところがある場合は、何かしらアピールも必要かと。
全ての内容に対して100％マッチしていなくても、その他の内容で１２０％ならそこをアピールすることもできますし。

とまぁこんな３点です。
今後いろいろと経験するうちに自分ルールを加えるかもしれませんが、今の自分ルールはこんなとこ。

以上、今回はシリコンバレーでの履歴書について。

それでは、また。 アスタ　ルエゴ！

「言われた事をひたすらやっていき、その都度課題を解決していく」
重要なことですね。

　アサインされた課題

• 期限に間に合っているか
• 課題をどうクリアしているか
• レポートがどのようにまとまっているか
• などなど

まさに私がそれまで日本でエンジニアとして経験していたサイクルでした。
仕事をアサインされ、その成果物の質次第で査定が決まる。
ちゃんとしたエンジニアリングの作業プロセスもあるので成果物の質が良ければ認められました。
ただ、これは評価されるうえで最低限必要なこと・・・

さてシリコンバレーではどうか？
実は・・・

日本人エンジニアとしてやってきた過去のスタンスが通じたのは初期の頃だけでした。

日本人としての持ち味は作業の細かさやコツコツとデータを纏めたり資料作りをしたりというところ。
また実験室での泥臭い作業をこなしてきた自分にはどうって事無い！
逆に優秀な人材が多いシリコンバレーではあまり泥臭い作業は好まれない。
自分の持ち味をいかせるぞぉー！
と頑張ったものの、いざ仕事をアサインされて成果物を出しても反応が、い・ま・い・ち・・・
年度末の評価も 中の中 程度・・・

あれっ？？
あれれ？？

ちょっとまずいなぁーーーと思い再び初心に戻って "観察" してみることにっ。
　　"観察" に関しては本ブログ 「シリコンバレー流　エンジニアの仕事術　周りを観察する事で見えてくる自分の価値」にご紹介していますので是非一度読んでみてください。

そこで気付きました。
評価されている、信頼されているエンジニアは自ら提案して仕事をしているではないですかっ。
自分みたいに仕事を待っている人はほとんどいなーい・・・

どんな感じで提案しているかというと、例えばこんな感じ。

• 今後こういった課題がありそうなので、ここは自分がカバーします。
• これは誰かがやらないといけないので自分がやっておきます。
• 自分だけでは対応できないタスクがありそうなので、誰々と話して一緒に進めておきます。
• この技術はこういったことに使えそうなので、少し調査しておきます。
• ここは少し効率が悪いので改善しておきます。
• などなど

あんまり疑問系「やってもいいですか？、どうしますか？」でもなく、「やります、やっておきます」って感じなんですよね・・・流石優秀・・・あっぱれでした。
もちろん自分の意見を述べた上で、上司の意見を求めるケースもたくさんありますが。
自分のタスクでないから、アサインされていないから、といって提案しないのはチャンスを自ら逃しているに等しい。

基本的には仕事内容を待ってその都度言われたタスクをやるだけでは評価されません。
​自ら気付き、気付いたら自分がやる！

というコツを学んだのでした。​
ただ、これを実践するには時間がかかりました。
与えられる仕事内容は当たり前にこなしつつ、周りをもっと観察して何か必要なのかというのをいち早く察知しないといけません。
この与えられる仕事内容のスピードを上げつつ質を維持し、少しでも効率を高めないといけません。

学んだからには実践。
いろいろとやり方を試しながら進めていった結果、年度末の評価も徐々に上がっていきました！
ありがたや、ありがたや。

それともう一つ学んだコツ。
普段からマネージャーの言葉には耳を傾けて「近いうちにプロジェクト、タスクとして何がありそうか」というのを探っておくことです。
そこでピンときた内容には予めちょっとした資料を用意しておくとグッド。
感が当たってマネージャーから話があれば資料をちょいと加工して直ぐ対応できます。
「その件なら前に気になって調べてたのでメールしますね。」
てな感じに。
例え感が外れても調べたことは知識に繋がります。
何事にも Initiative に、そして Assertive にですね。

それでは、また。アスタ　ルエゴ！

こんにちは。
​今回は観察すると言うことについて。

エンジニアとして科学的な現象を観察するのはとても楽しく興味を持ちますよね！
データを観察したり、プロセスを観察したりするのは、どこで何が起きているのか理解するのにとても助かります。
エンジニアとしてとても重要な能力です。

しかしながら、ここでご紹介したいのはちょっと違います。
上のようにエンジニアという観点で観察というと、ついつい研究的な事や技術的な事などといった感じで考えられがちですが、これはいわゆるハードスキル、ご紹介したいのはどちらかというとソフトスキル的な観察です。

エンジニアとして価値を高めるためにはチームを観察するという事も重要！
「それはマネージャーの役目だと思うけど、どういうこと？」ってなりますよね。
いえいえ、マネージャーはもちろんそうですが、エンジニアとしてもかなりプラスになります。

チームをよーく観察することで自分のエンジニアとしての経験を活かせそうな場が見えてくることがあります。
そして技術的にチームのプラスとなると思えるところは、改善するためのアクションをどんどんしていくべきです。

例えばですが、

• チームメンバーの個性：効率良く連携するにはどうするか？
• プロジェクトの納期：遅れがちだが、何が足りないのか？
• プロジェクトの成果物：質にいまいち納得いかないが、何が足りないのか？
• チームに無い新しい機能：ある分野の技能を持った人がいないが、自分がやったらどうか？

こういったチーム内の観察はとても重要で、採用されたばかりの新しい職場であったり、しばらく勤めて変化が欲しい時であったり、いろんな場面で有用なソフトスキルです。
観察により何かを発見し、それを改善するためのアクションができるエンジニアはとても価値の高い人だと思います。

私の知っているエンジニアにも観察能力に長けた人たちがいて、そういう人はやっぱり周りからとても尊敬されていました。
こういう人を周りに尊敬されている人を観察しスキルを吸収していくのもまた重要ですね！

それでは、また今度。　アスタ ルエゴ！
​

今回はアメリカのシリコンバレーでエンジニアとして再スタートした時の事を少しご紹介したいと思います。
シリコンバレーはご存知の方もいると思いますが、アメリカ カリフォルニア州のサンフランシスコ近辺などベイエリアと呼ばれる地域になります。
その昔、多くの半導体（原料：シリコン）を扱ったメーカーが集まっていた事とその地形（盆地：バレー）からシリコンバレーという名前の由来になっています。
シリコンバレーにはアップル（クーパチーノ）、グーグル（マウンテンビュー）、フェイスブック（メンローパーク）、アドビ（サンノゼ）、インテル（サンタクララ）、シスコ（サンノゼ）、ヤフー（サニーベール）、オラクル（レッドウッドシティー）、エヌビディア（サンタクララ）などなど多くの著名な企業が集まっています。
その昔と言ったのは、今では半導体メーカーというよりは、IT関連の企業などが増えてきてシリコン製品だけで競争している会社は少ないからです。
　シリコンマップスという会社では企業一覧をグラフィカルにマップにしたポスターなどをデザインしています。
　仕事上、いろんな会社を訪問するのですが、割とよく見かけます。
　シリコンバレーだけでなく他の地域もサポートしていてビジュアル化して企業を見たい場合にはとてもお勧めです。

さてアメリカで転職した当時の話に戻りますが、今振り返ってみると当時は自信と不安の塊で、モチベーションというエネルギーはとても高い値を維持しながらもそのエネルギーの塊はバタバタとノイズのように乱れていたという印象です。
精神的には乱れまくり・・・
日本にいた時の私は欧米人に対する憧れと一緒に仕事をしてみたいという強い気持ちがあった一方で、「自分なんかが優秀な人たちに囲まれてエンジニアとしてやっていけるのか、ついていけるのか」といった劣等感を既に感じていました。
「何か始めないと」と思いながら、お昼休みは自己啓発本などを読み、仕事が終わればインターネットで毎日現地の情報などを調査、時間があれば英語の勉強などをしていました。
　当時読んでいた自己啓発本などは精神面を整える上でとても役に立ち、今でもお気に入りは保管しています。
　ここで当時読んでいた本の１つを書籍紹介ブログ記事 「転職時に読んでいたおススメ本のご紹介」 に紹介していますのでご興味ある方は是非。
　英語の勉強は苦痛だったなぁ・・・というか苦手・・・今思うと日本で勉強していた内容がどれだけ身についていたのか。
　当たり前なのかもしれませんが、「習うより慣れろ」が一番だということをこっちに来て再認識しました。

そんな毎日を過ごしているうちにアメリカで挑戦してみるという感情は日に日に高まり、しばらく経つと割と引っ込み思案な自分が転職会社のリクルータなどにコンタクトしながらいろいろとアドバイスをいただいていました。
海外の会社へ直接転職するというケースはほとんどなかったので、外資企業や海外に子会社などがある日系企業をターゲットとしていました。
　ターゲット

• その１：外資系企業での現地就職を直接アタック！
• その２：外資系企業で国内就職し、短期 (1-3年)での現地トランジション！
• その３：日系企業で国内就職し、現地駐在員を目指す！

　２と３はエージェントにその意志をしっかり伝えた上で「考えてもいいよ」という企業だけ面接しました。
　人を巻き込んで動き出したら流石に引けないですねぇ・・・
　やっぱり動き出さないと何も始まらないというのを痛感。

そういった中でいくつかの企業と面接の機会をいただきながら自分の技術能力が海外で通じるレベルなのかを試していましたが、流石に外資系企業の面接は難易度も高かったです。
技術能力を試す問題や思考能力を試す問題などをホワイトボードを使って説明しながら回答するといった形式が多々ありました。
　日本の典型的な面接である人柄や経歴などを確認するのとは大分違うので慣れるまでは大変。
　しかも英語で・・・というのが英語の成績の悪かった自分には苦痛・・・

自分も割りとまじめ？？に働いていた方なので自分の分野である技術的問題にはある程度解答できていたと思いますが、全く知らない分野で思考を試されたりするような問題にはとっても苦労しました。
そんなことを繰り返しながら数は少ないものの内々定、内定などをもらいつつアメリカでもやっていけそうかなぁという感触を掴んでいた日々でした。
　今思うと退職する時が一番大変だったかなぁと。
　それまで色々と面倒をみていただいた上司や先輩方などに「申し訳ありません！」という気持ちで一杯でした。

さて、話は飛んでシリコンバレーでのエンジニアライフをスタートしたわけですが、先ほど書いた通り精神的にはかなり乱れていたと思います。
私の場合は製品の技術サポートをしたりするようなお仕事でしたので、社内だけでなく上で挙げたような社外の大手企業のエンジニアと打ち合わせする機会が沢山ありました。
説明しないといけない内容などは理解できているけど上手く伝えられなかったり、文化の違い、仕事の進め方の違いなどで本来一人で片付く仕事も周りのエンジニアに少しフォローをしてもらいながら数ヶ月を過ごしていました。
　今思うとただ黙々と自社製品の開発に取り組むような職種であれば、成果物を出しやすかったのかなぁと思ったりもします。
　が、シリコンバレーを含め大手企業のエンジニアとのやり取りもできるというのはとてもプラスでした。

あまりにも周りを巻き込んでいたので、「これはいかん！」と思い出したのがおそらく3ヶ月くらい経った頃でしょうか。もっと自律しなくてはと思い、落ち着いて先の事を考えてみることにしました。
その時に考えたことなどは今でも自分の中で基本として残っているのですが、その中でもやはり基本中の基本としているのは ”観察” です。
人と同じ事をやっていても自分の価値はなかなか生まれないので、先ずは周りを観察することにしました。
チーム、グループに足りないものを見つけそこを自分の価値となるよう伸ばしていこうと思ったのです。
　この考えは新しい職場、会社に移った時などの基本として今でも参考にしています。
　本ブログサイトの「シリコンバレー流　エンジニアの仕事術　周りを観察する事で見えてくる自分の価値」でご紹介しているのでお時間ある時に是非一度呼んでみてくださいね。

難しそうに思えるのですがグループによっては簡単に見つけられることもあり、コツさえつかんでしまえば割と簡単に適用できたりします。
私のシリコンバレーでのスタートがこの考え方に救われたと言っても過言ではありません。
スタートから6ヶ月くらい経った頃には自分だけにできることを見つけることができ、1年後くらいにはグループ内に今までなかった仕組みを作ることができました。
　このやり方はおそらく日本でも可能かとは思いますが、業務プロセスが日本の方ががっつりと決められているので個人的にはUSよりも少し難しいのかなとも感じています。

「グループ、チーム内に足りないことを観察する。」という単純なところに気づくまで3ヶ月ほどかかってしまいましたが、これにより無事にスタートできたと今でも思います。
逆に言うと「人と同じ技術能力でやっていても生き残るのは大変だ。」というのを感じた時期でもありました。
​
それではまた。アスタ ルエゴ！