開発できない元SIerエンジニアがなぜ海外カナダで働けているのか

開発できない元SIerエンジニアがなぜ海外カナダで働けているのかカナダ生活
海外エンジニアTOSHI

カナダでエンジニアやってます、TOSHIです。

「SIerはプログラミングの開発経験が少ないから海外就職はできない」という意見をよく聞きます。

元SIerの私自身そう思っていましたが、今私はカナダのシステム開発会社で働いています。

Webシステムの開発、AIやロボットを用いたサービス開発(カナダはAIが強いと言われてる)などを行う企業で開発チームのマネージャーをやっています。この企業と出会ったきっかけは昔お世話になった方からの紹介ですが、もちろん面接はありましたし長期的に雇用される保証はない状態でした。ただ、ありがたいことにクビにならずに今2年目を迎えています。

私は日本にいた頃、SIerで6年間エンジニアとして業務システムの開発(と言ってもスクラッチではなく追加機能開発やバグ修正くらい)、製品保守、カスタマーサポートをしていました。マネジメントがやはりメインで、ガッツリ開発するタイプではありませんでした

「スキルがない」と海外就職は後ろ向きでしたが、むしろそのマネジメント経験が活きていると感じます。個人の所感ですが、カナダはマネジメントができるエンジニアが圧倒的に少ないと思います。みんな好きな開発作業をやりたがりますし。私は開発作業とマネジメント半々でやっている感じです。

なぜ開発ができるわけでもなかった私が海外でエンジニアとして働けているのか、カナダ人同僚に聞いてみた内容をお伝えします。自分で仮説を立ててもしょうがないなと思ったので。

「開発できないから」と海外就職をあきらめている方の参考になればうれしいです。

なぜ私が現地でエンジニアとしてやっていけるのかカナダ人同僚に聞いてみた

働ける理由①|日本企業とコミュニケーションが取れるから

私の会社は日本にグループ企業があり、そちらから発注してもらっている売上が大半を占めています。そのため当然日本企業との打ち合わせやメールでのやり取りが発生します。

私は元々SIerの頃に自分も同じように関係会社に発注していたので、相手がどういった粒度の見積が欲しいのか、また細かい部分の作業調整等、相手が期待する内容もある程度わかりますし対応できます。

そういったコミュニケーションの部分は単純に「日本語がわかる。」だけでは対応する部分が難しいため重宝されているポイントになっているようです。

これは私のスキルというか、日本での経験が活きている感じですね。

働ける理由②|プロダクト全体の品質を上げられるから

SIerならお馴染み、工数見積・設計・レビューがあります。SIerがコーディングをしない代わりに多くの時間を費やしているのがこの3つの作業ではないかと思います。
ではこれらのどういったポイントが具体的に評価されているか見てみます。

見積

作業工数を見積もる時、経験則で「こういった機能実装だったらX時間くらいかな?」というのがあると思います。そしてその数値はお客さんに対しても説明、納得してもらえるような値にある程度なっているかと思います。
ここがポイントです。


「お互いに納得する見積を出す」というのがなかなか難しく、現地のエンジニアでよく見かけるパターンは以下の2つです。

①担当者自身が実施する想定の見積で納得感のある一般的な数値になっていない。
②具体的な作業イメージができておらず、過度に多い見積になっている。

①については担当者自身が見積もった箇所全体を実施する場合は問題ありませんが、基本的には少なからず複数人で開発するかと思います。その場合に見積もった担当者自身が開発しない箇所の工数差異が大きくなってしまいます。

②は具体的な事例で言うとユーザ認証機能の実装で1人月、という提示が過去にありました。
要件としてはログイン、ログアウト、パスワードリカバリ機能も含めますが、システムの規模は小規模、またサーバサイドのみの実装、かつ単純なパスワード認証です。

ただここで問題なのは「Authorization & Authentication」という括りで「1人月」としており、具体的な数値の根拠や機能実装の内訳の説明はありませんでした。

そこで活きるのがSIerとして他の人に開発してもらう想定で見積もってきた経験です。具体的にどういった機能実装の想定か列挙できると思います。これがあるだけで対顧客への見積の信頼が上がり、双方に納得のできる(開発会社は赤字にならず、顧客もお金を出して良いと思える)見積になります。

この「妥当な見積の提示が出来る」点は評価されているようで、他メンバーが見積もった際は必ず私を交えてレビューするようになっています。

設計

設計とは具体的に概要設計、画面設計、詳細設計になります。

同僚のやり方を見ているとシステム全体のフローの作成、もしくは画面イメージ(ラフイメージ)の作成はできるものの、概要設計時のシステム利用の事前の想定、また画面項目や動作部分(チェック仕様等)までは落とし込めていないケースが散見されます。

これは日本ではドキュメントの納品が当たり前ですがカナダでは圧倒的に少ないことが挙げられます。打ち合わせの議事録さえないので詳細設計書が作れないのも当然かもしれません。

そのためSIer時代の設計スキルが特に活きてくるのが日本から発注してもらう時になります。

私の会社は日系企業なので日本からも発注を貰って開発していますが、その際は日本流のやり方で基本的にはウォーターフォールの開発となります。そのため身内のグループ企業からの発注であっても設計書は必須です。
私は元々ウォーターフォールでずっと開発してきたのでその点はかなり経験が活かせており、評価されているポイントとなっているようです。

レビュー

日本企業とビジネスをしていると重要になってくるのが日本のビジネスカルチャーへの理解です。

日本はドキュメントベースの企業が多いため設計書以外にも課題管理、詳細スケジュールの管理等は基本的にドキュメントにて行い、これらをその時点のエビデンス、成果物として提出します。

ビジネスカルチャーを理解しているとどういった成果物を日本企業が求めているかわかり、相手が求める成果物と自身の認識にズレが発生しにくくなります。そのため現地メンバーが仕上げた成果物が要求を満たすものになっているかレビューすることができます。

どういった点をレビューしているかというと

・当初から一貫性の取れた記載になっているか。(途中で記載内容、粒度が変更されていないか。)
・当初合意した最終成果物を満たすための機能が漏れなく実装されるスケジュールになっているか。
・記載すべきことがドキュメント内に漏れなく記載されており、不要な記載等ないか。(例:作業開始日、終了日の記載の確認、顧客提示資料に開発元の会社名を記載していないか等)

メンバーからは「細かい設計書を作成するのはPoC(Proof of Concept.できるかどうかの技術検証)なのに効率が悪い。」、「直接Redmineを見てもらって詳細スケジュールのドキュメントを廃止にすべき。」といった声も挙がり、メンバーから出てくる成果物の内容が変わることもありましたが、その度に企業文化を説明し、成果物の調整をしていました。
私以外は日本のシステム開発の実務経験がないため、日本のシステム会社が求める成果物を理解し、レビューできる点は評価されているようです。

働ける理由③|マネジメント経験があるから

SIerで働いていると大小関係なくチームのマネジメント経験があるのではないでしょうか?
私は以前、製品保守、カスタマーサポートでマネジメントの経験がありました。

マネジメントでやっていたのは主に

・QCDの管理
・他部門との成果物の合意
・関係者との作業調整

日本でSIerに勤めているとこういった小さいチームながらマネジメントを経験している人は数多くいると思います。

カナダのエンジニアは日本より圧倒的にマネジメントが出来る人が少ないです。それは日本と違ってエンジニアとマネージャーをそれぞれ別のポジションと認識しており、マネジメントを好んでやる人が少ないからです。別のポジションとは日本のように給料や社内の地位が、マネージャー>エンジニアという訳ではなく、あくまで職種が違う、という認識です。
そのため、エンジニアとしてモノ作りをしたい人はエンジニアのプロフェッショナルを目指してキャリアを積みますし、無理にマネジメントをやりたいと思う人はあまりいません。
そういった背景からマネジメントができる人は少なく、マネジメント経験者の需要は高いです。

日本企業とカナダ現地のメンバーの橋渡しをしつつ、経験者としてチームのマネジメントができるため、日本からのプロジェクトの管理は私に任せてもらっている部分が大きく、その点は大いに評価してもらっています。

働ける理由④|最低限の会話は英語でできるから

カナダ現地に来る前、勉強しても最終的にTOEICは500点台でしたがワーキングホリデービザ取得後、1年間ほぼ毎日Bizmates(ビズメイツ)で英語のレッスンを受けていました。

毎日25分と短いながらもIT関連の実務経験がある先生を指名し、自己PRの作成や面接練習、開発プロジェクトの状況報告の練習等をしていたため、ある程度仕事の中で使われる表現や単語を理解していました。

そのため現地で就職し、ミーティングに参加しても「全くわからない。」といったことはあまりなく、「なんとなくわかるけど部分的にわからない。」状態だったため、都度わからなかった表現をメモして後から調べて理解する、といったことをしているとだんだんと会話についていけるようになりました。

今では基本的な会話はなんとかできるようになってきたため問題点や解決方法等の説明も理解し、詳細の確認もある程度できますが、英語・日本語ができる第三者を介することなく英語で直接担当者と会話できている点も評価されているようです。

よく使うフレーズ

仕事でよく使われるフレーズを紹介しておきたいと思います。

①「Do you understand?」 ではなくて「 Does it make sense?」

「Do you understand?」は「理解できる?」という意味なので失礼になる場合があります。なので「Does it make sense?」で「わかりますか?」という表現にした方が良いです。打ち合わせの中でもほぼ毎回出てくるぐらい頻度が高い表現です。
返事の仕方はわかる場合は「make sense.」、わからない場合は「No, it doesn’t make sense.」で回答すると良いです。

②具体的な細かい実装は「implement」、大きい規模や抽象的な実装の場合は「develop」を使う

例えば、Emailアドレスが有効かチェックする機能を実装して欲しい場合は「Can you implement an  email checking feature?」(Emailのチェック機能を実装してもらっていいかな?)、ざっくりログイン機能を開発して欲しい時は「Can you develop a login feature?」(ログイン機能開発してもらってもいいかな?)となります。

③何かタスクを依頼したりレビューコメントを修正して欲しいときは「Can you~~? Because~~.」、ちょっとしたお願いを聞いて欲しい時は「Can you do me a favor?」

手の込んだ作業や少し時間がかかるような場合は例えば「Can you fix my comments? Because I think you misunderstood the specification.」(私のコメント(したところ)、直してもらっても良いかな?何故ならあなたは仕様を勘違いしてると思うから。)

もしちょっとしたお願いだったら「Can you do me a favor? I want to confirm your marketing docs. So can you share me?」(ちょっとお願いしてもいい?あなたのマーケティングの資料を確認したいんだ。だからシェアしてもらってもいい?)

④じっくり確認するなら「confirm」、ちょっと確認するなら「check」、さらっと見るなら「look through」

例えばプログラムのロジックをじっくり確認して欲しいなら「Can you confirm behavior of the login feature?」(ログイン機能の動作確認してもらっていい?)、Emailをチェックして欲しいなら「Please check my email.」(私のEmailチェックしといてね。)、ドキュメントを作成してさらっと見てほしいなら「Please look through my design document.」(私の設計書に目を通しておいてね。)となります。

働ける理由⑤|フレンドリーな人柄だから

私は元々あまり物怖じしないタイプなので英語に自信がなくても自分から同僚に話しかけたり一緒にスターバックスにコーヒーを買いに行ったりしていました。ほとんどのメンバーが自分より年下ですが彼らは私より先に入社していた「先輩」としてリスペクトしていましたし、彼らがどのように仕事を進めているか興味があったため対等に接し、時には友人としてゲームを一緒に楽しんだりしていました。どうしても日本の麻雀牌で麻雀がしたかったのでわざわざ$400かけて日本の麻雀セットを購入し、彼らに日本式の麻雀のルールを説明してチームのメンバーやその友達とプレイしたこともありました。

そういった日々を過ごしていたのでチームに溶け込むのも早かったですし、彼らが「同僚」として認めてくれるのにあまり時間はかかりませんでした。

今になって思うと、私は日本から来て開発のマネージャーとして採用されましたが、突然やってきた見知らぬ人で英語も話せず、しかも開発ができる訳でもなかったらそりゃー信頼もされないし癪に障りますよね。

なので同僚とすぐ仲良くなれてチームに溶け込めるフレンドリーさがあったからこそ、皆とプロジェクトを進められているようになっているように思います。

逆に伸ばしておいた方が良かった点

やはり英語です。「最低限の会話」レベルでは仕事をするには全然足りません。なぜ英語が必要かと言うと

①ネイティブ達の会話についていけないことがある
②永住権のビザ申請に英語のスキルが必要になる

①はネイティブの人達の会話がビズメイツで相手をしてもらっていた人以上に速度がかなり早く、聞き取れないことがどうしてもあります。
そうなると当然顧客との折衝や仕様の詳細を詰めたり代替案を検討することも難しくなり、現地顧客のプロジェクトマネジメントは難しくなります。
まだまだ日本の売上に依存している今は良いですが、今後北米メインになった時に私の存在意義がなくなってしまう可能性があるため、どうしても現地の人とコミュニケーションを取れるスキルが必要です。

②は短期滞在を考えている人は無視してもらってよいです。私は3年は北米での就労経験が欲しいと思っているのですが、そうなってくると必要になるのがビザです。
同じ会社に働き続けられるなら今の会社限定で発給される就労ビザがあるためそれでも良いのですが、やはりキャリアアップや倒産、といったリスクを考えると永住権の申請をした方がよいです。
そうなるとIELTS (International English Language Testing Service)のスコアが7は欲しい(1年在住でようやく5…)ので英語は必須と言えます。

日本企業に勤めているとTOEICのスコアが重視されますが北米で求められるのは本当にコミュニケーションが取れる(聞き取れる・話せる・書ける・読める)能力です。
このIELTSのスコアがないと北米でエンジニアの養成学校に入ろうと思っても入れないところが多く、ワーホリで北米に来ても語学学校だけで終わってしまう可能性があります。
「北米で働きたい!」と思っているひとはまずIELTSを日本で受けて自分の英語レベルを把握しておくことを強くオススメします!

さいごに

いかがだったでしょうか。SIerでもこんな風にカナダ現地で就職、働き続けることができた事例の一つとして紹介させて頂きました。

結論ですが、私は日本のSIer出身であれば日本企業と取引のある企業に入った方が良いと思います。正直、北米のCS系出身のエンジニアと勝負できるなら良いですが、わざわざそこで勝負しなくても彼らが戦えない日本のビジネス、カルチャーで勝負した方が既に持っている強みを十分に発揮でき、存在意義を主張できるからです。

私のように海外での転職を目指している方、働き続けたい方に少しでも希望を持ってもらい、参考にしてもらえればと思います。

コメント