海外と日本でのソフトウェア開発職の文化を振り返ってみた

こんにちは。阿部と申します。とある渋谷のIT企業でエンジニアのお仕事をしています。普段はブログを書いていないのですが、お勤め先の社内ブログ用に以前執筆した記事をlean-agile podcastで紹介していただく事になり、当時の記事を今回こちらのプラットフォームでも公開する事にしました。長文になりますが、ご興味を持たれた方は是非ご覧ください。

「海外と日本でのソフトウェア開発職の文化を振り返ってみた」という記事のタイトルにしているのですが、この話のモチベーション・裏付けとしてまず自分のバックグラウンドを簡単に説明しておきます。私は名前によらず外国籍・海外育ちで、今までヨーロッパと日本それぞれでベンチャー・中小企業・大手の仕事環境を6社ほど転々とし、色々な国のエンジニアと仕事をしてきました。

(*ちなみに、日本語で記事を書くのはあまり得意でないので、言葉遣いがおかしいところは大目に見ていただけれると嬉しいです。)

日本でこのような経験を持つ方はあまり多くないであろうと、今回何かそこから得ることがあれば共有できればと思いました。とはいえ、振り返ってみてそれほど驚くような話や知恵になるポイントが出てきたわけではありませんので、あくまで一つの個人的な体験談、「food for thought」として読んでいただければ幸いです。また、それぞれの国の人や文化が良いとか悪いとかジャッジして書いているつもりではない事だけご了承願います。

ということで、ディスクレーマーはこれぐらいにしておいて、本題に入りたいと思います。

エンジニアの「ものづくり」に対するスタンス

日本に来てこちらのエンジニアリングの職場についてまず感じたのは、みなさんがある課題に対する技術的ソリューションを考える時のアプローチの違いです。ヨーロッパのエンジニアはものをプラグマティックに考える傾向があり、問題を解決するために一番手取り早い・必要最低限のものを作ろうと、むしろ出来れば何も作らず既存のものをうまく使い回すだけで済ませようとします。仕事自体に関する考え方の違いかもしれませんが、どれくらい楽をして時間を使わず仕事を片付けられたかに意義を感じる人が多いと思います。一方、日本ではエンジニアリングを単なる仕事をこなすための手段としてだけ捉えるのではなく、より自分の作るものに対するオーナーシップやプライドの意識が高いエンジニアが多い印象を受けました。ある問題に取り組むにあたって、自分がどのような素晴らしいものを作れるのか、それが既存のものよりどう優れているのか、新しいものを作ってどうアピールできるのか、という観点から考える人が多いと思いました。

なぜこのように違うのか考えてみたのですが、ヨーロッパに比べて日本の技術職においては「名を上げる」事が成功するためのより大きな要素となっているからだと思います。会社に(エンジニア職に限りませんが)表彰の制度があったり、ある既存の技術を使うか判断する時はどこの誰が開発したものなのかも判断の基準に入っていたり、あるリリースのクレジットにおいて誰の名前がどの順序で記載されるか細かく議論されたり、何かを作る前からそれをどのカンファレンスの場で発表できるのかを考えたり、色々な面で自己アピールの重要性があらわになっています。それは、より多くのエンジニアがブログを公開していたり、勉強会・セミナーを開催したり、前に出て目だとうという動きをしている事にもつながっていると思います。また、例えばあるプロジェクトをオープンソース化する際のモチベーションも、日本ではより多くの人に使ってもらって名を上げるというところが中心になっている一方、ヨーロッパだと他の人に貢献してもらう事によって得をしたいという趣旨が強いと思います。

こういったスタンスは例えばエンジニアの面接の内容にも影響している気がします。ヨーロッパの面接では結構ドライにその場でスキルや問題解決力がテストされるところに重点があります。日本では、逆に全く何もテストされないケースもあり、その変わり過去にどの会社で誰とどのプロジェクトに関わって何を作ったのかをより細かく聞かれます。自分が日本で転職活動している時に経験した出来事ですが、過去にオープンソースで公開した成果物が無いことを理由に一度面接すら断られた事もあります。無名のエンジニアには、スキルがどうであろうと興味はないという事だったのでしょう。こういう事もあり、日本ではやる気の無いエンジニアに見られないために自己アピールを意識しなければいけないのも大切だという事を学びました。

このような文化の違いは自分の日々の仕事にも影響しているのか考えてみたのですが、確かに他のエンジニアにタスクを依頼する時の頼み方に影響しています。ヨーロッパの人に何か依頼する場合は要件を細かく伝えないと、伝えた事を文字通りに実装する人が多く、マイクロマネージしないと自分が想像していたものより色々足りないものが戻ってきます。この点は以前勤めていた日本企業で海外の外注先に開発を依頼している方々も苦労していると聞きました。逆に日本では、頼んだタスクに対して想定していた以上に時間がかかり、注文以上のものが戻ってきたりする事もあり、どこまで作るのかをよりはっきりさせておく事が大事だと思います。

極端な例を一件語りますと、これも以前勤めていた日本企業での出来事ですが、あるチームが全員でオーバーエンジニアリングに励んでしまった場合がありました。あるサービス間の連携を実現するために共通のデータフォーマットを決めるタスクが、いつの間にかデータの交換プロトコル、シリアライズ用の機能、ネットワークライブラリ、pub/subサービスとどんどん話が膨らみ、他のチームにも使ってもらおうとより汎用性が高いものを数ヶ月かけて設計・実装していました。皮肉なことに、そのような汎用的なサービスは既存のものがたくさん存在していて、結局他のチームでは使ってもらえず無駄な努力になってしまっていました。ここまでひどいケースは流石にあまりないと思いますが、何をどこまで作る必要があるのか冷静に考える役割を持つ人がいるのは特に日本の開発現場ではより大事だと感じました。

エンジニアのチーム構成・組織構成

上記にあった開発者のネームバリューの話とも関連していると思いますが、日本の開発チームはより参加しているメンバーによってアイデンティティを持つ団体になっている印象を受けました。何をするために集まっているのかより誰が集まっているのかの意識の方が高い気がします。チームの人と飲みに行ったり、チームビルディングのアクティビティーがあったり、社員旅行で基本チームメンバーとしか行動しなかったり、よりチームというユニットが中心になっている事が色々なところから伝わってきます。日本は元から上下関係を大切にする文化もあり、チームに関してもメンバーを育てる・メンバーの面倒を見る・チームの先輩から学ぶという意識が強いと感じました。また自分が遭遇した日本の職場の例になりますが、あるスキルを持つエンジニアが他のチームで必要とされたら、そのエンジニアを「貸し出す」という考え方があり、チームリーダー間では「これぐらいの期間だったらエンジニアAを貸してあげる。でもちゃんと返してね。」みたいな遣り取りがされているぐらいエンジニアの所属が意識されていました。

それに対し、ヨーロッパの開発チームはよりプロジェクト・プロダクトを実現するための一時的なタスクフォースという意識の方が強いと思います。あるプロジェクトが完了して次に進む際にメンバーがシャッフルするのも普通で、場合によってはプロジェクトではなくタスク単位で、あるタスクをこなすスキルを持つエンジニアが必要であればその人が一時的にチームに加わるという移動の仕方もあります。社員の評価も、チーム内の上の人に評価されるより、最近は仕事で関わりがある人はチーム所属と関係なくお互いの評価をする事が増えてきています。なので、ある固定のメンバーのグループに所属している感覚もそこまでなく、どちらかというとチームより会社自体への所属意識の方が高いと思います。ちなみに、飲みに行くのも特にチームとは関係なく普通に仲が良い社員と行きます。

ヨーロッパでいう「フラット」な組織というのは、上下関係を減らすだけでなく、このようなチーム間をより自由に横ばいするところもその概念に含まれていると思います。このような動きをしていると、社内での繋がりも増えるのである意味ネットワーキングになります。それにより、誰がどういう分野のエキスパートであり、ある分野に詳しいエンジニアの意見が聞きたい時には誰に聞けばいいのか分かるうえ聞きに行きやすいというメリットもあります。

日本ではそれがよりチーム内の範囲にとどまっている事が多いと思います。以前勤めていた日本の職場ではその問題が意識され、それを解決するためにわざわざアンバサダー的な役割を持つ人が設けられていました。ある知識やスキルを持つエンジニアの意見を聞いたりアドバイスをもらいたい場合に、その人に相談すれば、社内でその分野に詳しいエンジニアを紹介してくれるという仕組みになっていました。ここまで対策をとるのは珍しいと思いますが、他のチームとの交流を広めるためにシャッフルランチみたいな企画があったり、日本ではより組織的な壁が多く、それを超える努力がそれなりに必要だという事が自分にとって印相的でした。

エンジニアのミーティング文化

最後の議題になりますが、日本の職場ではミーティング、特に定例ミーティングが多いです。情報の共有や仕事の議論は前もって決めた時間と場所とメンバーでするのが普通で、またそのような場に参加するメンバー設定は組織構成に強く紐づいており、チームリーダーとチームメンバーのミーティング、リーダー層のミーティング等のような形に別けられているのが多いと思います。また、それが情報の伝達経路をコントロールする手段になっている場合もあります。

以前一緒に仕事をしていたある日本人のエンジニアの話ですが、誰かがその方の席まで話しかけに来ると「直接こちらまで話をしに来ないでください。ミーティングをスケジュールしてください。」と会話を断る事もありました。その場で話すと周りの人に話しが聞こえるのも気にしている印象を受けました。また、自分のチームメンバーに直接話しかけてほしくないというリーダー役のエンジニアも遭遇した事があり、その人はチームメンバーに話があればリーダーを通して問い合わせる・ミーティングを設定するようにと周りに依頼していました。

それに対してヨーロッパではコミュニケーションがよりルーズ・アドホックであり、例えば誰かに相談したい技術的な課題や疑問があった場合にまずは直接その人と話をしに行くのが普通です。ミーティングというのは複数メンバーが集まる時間調整や議論をする物理的なスペースが確保したい場合にもちいる最終手段で、できれば話はその辺でしてすぐ済ませたい気持ちの方が強いと思います。

ヨーロッパのオフィスでは大体コーヒーメーカーとそれに伴うキッチンスペース・ソーシャルスペースが存在し、そこがそのようなコミュニケーションをする場にもなっています。日本のオフィスにもウォータタンク等が存在しますが、そこで誰かと会話をするのはあまりなく、あったとしたらちょっとした雑談にすぎなく、そもそもそこで長時間会話をしていると周りに仕事をサボっているように見られる気がします。ヨーロッパではそういう場で雑談ももちろんありますが、何か議論したい仕事の課題があれば相手を「コーヒーを一杯飲みませんか?」と誘って、そこで議論をする風習もあります。周辺にいる他の社員に話が聞こえてしまう事を気にするよりかは、むしろ何か盗み聞きしてもらってコメントがあれば会話に入ってきてほしいぐらいのオープンなスタンスな人も結構います。

個人的に思ったのは、日本の方がミーティング時間と作業時間がきっちり区別されているので、プライベートミーティングをスケジュールに入れておくなどして集中して作業する時間が作りやすいことです。その反面、ちょっとした会話で済ませる事が出来たはずの話にミーティングを設定するオーバーヘッドなどで無駄になっている時間も結構あるのと、誰かと情報交換が必要なタスクがあった場合にレスポンスタイムも悪いことです。日本はスループット重視、ヨーロッパはレイテンシー重視という事なのでしょうかね。

最後に

あまり纏まりのない話になりましたが、何か共感できる点や反論したい点がありましたら、気楽にコメントして頂ければと思います。また、今回の内容は論理的に因果関係を調査した課題ではないので、「日本だからこう」、「開発の職場だからこう」、という事を言おうとしている訳ではありません。むしろそれぞれの企業の文化や個人の働き方も大きく影響しているので、このような話から何か一般化するのは難しいと思います。例えば、私が現在お勤めしている職場は今まで働いてきた職場の中で一番日本人の割合が多い一方、自分が勤めてきた日本企業の中で一番仕事の進め方がヨーロッパに近いとも思いました。

という事で結論に繋がっていないままの長文になってしまいましたが、最後まで読んで頂きありがとうございました。

enneatype-5 engineer

enneatype-5 engineer