今回は、中国の大学を卒業後、エンジニアとして来日したOuさんのインタビューです。進捗を何度も聞かれることに戸惑いを覚えたというOuさんですが、日本の開発現場で直面したのは、“相談のタイミング”という意外な文化の違いでした。異なる価値観のなかで模索しながら、“チームで働く”ことをどう学んでいったのか。その姿から、チーム開発に大切なヒントが見えてきます。
「作ってから相談」では遅い。プロジェクト成功の鍵は“作る前に話す”
日本の職場で働きはじめて、まず戸惑ったのが“報告・相談のタイミング”でした。
中国にいた頃、少なくとも自分が経験したスタートアップでは、技術系の出身者が多く、自分のタスクは自分で完結させるのが基本でした。そんな環境に慣れていたので、日本で頻繁に進捗を聞かれることには、正直「自分で完結できたのに、なんで？」と、少し効率が悪いと感じてしまって。もしかして、自分のこと信用されてないのかな……と、つい考えてしまうこともありました。そんな戸惑いの中で起きた、ひとつの失敗体験があります。
以前、録音アプリの開発に関わったときのこと。担当のメンバーはとても丁寧で、録音の音質（サンプルレート）やファイル形式など、細かな設定を選べるように作り込んでくれていました。でも、開発が進む中で「そこまで機能が必要なんだっけ？」とふと立ち止まる場面がありました。改めてチームでプロジェクトのゴールを話し合ってみると、このアプリのターゲットはITに詳しくない高齢のユーザー。求められていたのは、「AI分析に使える程度の音質で録音できれば十分」という、シンプルな要件だったんです。つまり本来は、録音ボタンひとつで完結するくらい、誰にでも使いやすい設計にするべきだった。
この経験を通して感じたのは、「何を大事にするか」という共通認識を最初に持つことの大切さです。それが共有できていれば、細かい相談がなくても、メンバーが自然と正しい方向に進めていたはず。報告や相談の頻度を増やすことも大切ですが、それ以上に、判断の基準となる共通認識を整えておくことが、自走できるチームをつくる鍵になると実感しました。そして、チームで開発を進めるには、単にすり合わせるだけでなく、“どう伝えるか”も大きな鍵になります。
技術とチームをつなぐ“伝える力”が強い武器に
技術的なやりとりの中で感じるのは、「伝えること」と「伝わること」はまったく別だということです。以前、クライアントに挙動の説明をしたら沈黙の時間が長く続いてしまったこともあったんですよね。自分の中では当たり前になっている言葉も、相手がそれを知らなければただの専門用語。だからこそ、話す前にまず「この人はどんな立場で、どれくらいの知識を持っている人だろう？」と想像するようになりました。
たとえば、iOSチームとして働いているときに、バックエンドのエンジニアと話すとき。同じエンジニアでもベースの知識やいつも触れている技術が異なるためいきなりコードの話をするのではなく、iOSの基本的な仕様や動きから説明して、どうしてこの実装にしたのかを順序立てて伝えるようにします。ビジネスサイドの人と話すときは、仕様の背景やユーザー体験をベースに話を組み立てていきます。「なぜこの技術を選んだのか」「そのメリットとデメリットは何か」を、なるべく噛み砕いて伝えることを心がけています。相手に合わせて伝え方を変える。それだけで、チーム全体の理解や判断スピードはぐっと上がると実感しています。
そうして個々の対話を丁寧に重ねるうちに、チーム全体としてどんな方向を目指すべきかという視点のもと、“チーム全体の認識を揃える”役割を担うようになっていきました。
意見が分かれたとき、決断の軸は“対話”にある
チームでの共通認識を持つことは決して簡単ではありません。特に、リーダーになってからは、「どこまで話し合い、どこで決めるか」という見極めに悩むことも増えました。
たとえば、私が3人のチームのリーダーをしていたときのことです。パフォーマンスを重視するAさんはある技術を推し、スピード重視のBさんは別の技術を勧め、そして私も第三の案を考えていました。誰かの提案を採用すれば、他の誰かを否定するようで、最終的にどの意見を選ぶべきかを判断するのに非常に悩みました。
この時、まず最初に話し合ったのは、プロジェクトのゴールを明確にすること。何を最優先するのかを共通認識として持つことで、チームに共通の土台ができあがります。そして、各メンバーがなぜその技術を選んだのか、その背後にある価値観（重視しているポイント）を丁寧に共有しました。
最終的には、「限られた期間内で、どの選択肢が最も現実的にゴールに近づけるか」という観点から、チーム全員で意思決定を行いました。重要だったのは、メンバー全員の共通認識を定義するための対話。こうした“対話のプロセス”を積み重ねることで、チームの判断力も育ちます。リーダーとしては、答えを出すことだけが役割ではなく、皆が納得して進める状況をどう整えるかも大切な責任だと実感した経験でした。
信頼され、“任せたくなる”人を目指す
ここまでにコミュニケーションや対話の話をしてきましたが、一貫して大切にしているのは「また一緒に仕事がしたい」と思ってもらえる存在でいることです。
アプリやプロダクトの開発は、私にとって「ものづくり」そのもの。うまくいかないことも、悩んでしまうこともありますが、それでも手を動かして、少しでもよいものを目指し続ける。それこそが私が夢中になれる瞬間です。だからこそ、“つくること”に情熱を持つ人と、共に成長していけたらと思っています。その理由は、自然と前向きな議論が生まれるし、ただ形にするだけじゃなく、使いやすさや美しさ、そして長く愛されるプロダクトを一緒に作り上げることができるから。
もちろん、チームに貢献するためには、技術力や実装力を磨くことも欠かせません。レビュー対応などで技術的な信頼を積み重ね、みんなで同じゴールを目指して進んでいけるように、日々の学びや努力を大切にしています。
“対等に話せる力”は、技術の裏打ちから生まれる
技術力がすべてではないものの、まずはチームメンバーと対等に意見を交わせるレベルの技術力を身につけることも大切です。技術を理解することは、対話に説得力を生み、プロジェクトの推進力にもつながります。
TechTrainでメンターをやっていて感じるのは、課題のコードが書けても、その理由が説明できない人が多いということ。でもそれこそが、成長のチャンス！常に探求心を持ち、実際に技術がどう動いているのか、背後にある仕組みにも目を向けてみてください。たとえば初心者の方には、「私はSwiftを勉強したい」と言語ありきで学ぼうとする人が多いのですが、それは少しもったいないと感じます。大事なのは、言語の文法そのものではなく、その言語を通してソースコードの裏で何が起きているのかを観察すること。たとえば、値を代入するとき、裏ではどういう処理が走っているのか？メモリはどう管理されているのか？設計思想はどこに現れているのか？そうした“書き方以外の部分”にも意識を向けてほしいんです。そうすれば、新しい言語を学ぶ必要が出てきても、過去に学んだ知識と照らし合わせながら「なんとなく分かる」「なんとか書ける」と感じられるようになります。
そして、課題を解決したあとは、その背景や解決策を他の人が見ても理解できるようにドキュメントとして残すことをおすすめします。解決までの流れや、コードの根底にある仕組みを言語化することで、技術の理解がぐっと深まります。これは、プロダクト開発で求められる対応力を養うための効果的な勉強法です。
そして、この「技術を理解する力」は、自分の成長だけでなく、チームにとって大きな武器になります。技術に裏打ちされた対話は説得力が増し、プロジェクトを前進させる起爆剤になります。だから私はこれからも、技術への探究を続けていきます。
ひとりじゃない。学びも楽しさも、“つながり”から深まる
プログラミングやプロダクト開発って、「ひとりで黙々と進めるもの」というイメージを持たれがちかもしれません。でも実際は、チームで開発を進めていくことがほとんど。なので、TechTrainのような場を活用して、メンターや仲間の力を借りて成長していくのが一番だと思います。「これをつくりたい」という思いがあれば、学ぶことも苦じゃなくなりますし、完成までのプロセスもきっと楽しめるはずです。
私は誰かの成長をサポートすることにやりがいを感じています。もし学習で行き詰まったり、チーム開発で悩んだりしたときは、ぜひ気軽に相談にきてください。一緒にものづくりの楽しさや技術の奥深さを、思いっきり楽しみながら学びましょう！
Ouさん、インタビューありがとうございました。
「チームの一員としてどう振る舞うか」を、時間をかけて丁寧に言語化してきた姿勢が印象的でした。文化の違いに戸惑いながらも、報連相のタイミングや伝え方に悩み、実践を重ねてきたからこそ、「また一緒に仕事がしたいと思ってもらえるように」という言葉には重みがありますね。
TechTrainでは今回インタビューに答えて頂いたOuさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！
