ITにおける日本人との協力：10の違い

日本（日本人は自分たちの国と呼んでいます）は、外国人の目にはまだ神秘的で珍しいままです。国境を越えて、多くの国民の固定観念が広まっています。その中には、例えば、有名な日本の労働の質と効率があります。また、日本人は非常に責任があり、過労で亡くなることもあります。このような背景（そして「私たちとあなたの」の無限の比較）に対して、日本は生産性と誰かの住まいであり、これらの人々は開発プロセスについて多くを知っているという印象を受けるかもしれません。そうですか？顧客が伝統的な日本の大企業であった私たちのプロジェクトの例を見てみましょう。

前書き

私たちのチームは、既存のPoSソリューションを日本市場に適応させ、既存のソリューションからの逸脱を最小限に抑えながら、クロスプラットフォームにするという困難な課題に直面しました。一方で、製品を変更するためにカルトブランシュを入手したと言えますが、同時に、既存のコードベースによって深刻な制限を受けていました。コア機能の変更を委託し、ウォーターフォールモデルに従って開発を行いました。このプロジェクトの作業には3年かかりました。その間、ギガバイトのコード行を処理し、東京からカザンまで数十回出張し、顧客と日本の関連請負業者の両方から300人の参加者と協力しました。ロシアとフィリピン。



もちろん、日本人との仕事の詳細を完全に判断するには、1つのプロジェクトだけでは不十分です。結局のところ、多くはその詳細と会社の種類に依存します。しかし、私の印象と蓄積された経験（私自身と私の仲間の日本人学者の両方）を考慮して、今日は、日本人の同僚と一緒に仕事をしたときに遭遇したまさにその特徴と、私たちが学んだ教訓について、ポイントごとに説明しようと思います。何を学んだか。

Excelでの作業

痛みを引き起こしたまさにそのこと。日本企業のMicrosoftExcelは、非常に異なる詳細のドキュメント（UMLダイアグラムしかない場合でも）、バグのあるスクリーンショットのコレクション、そしてもちろん、メガピクセルマトリックスを追加できるセルからの無限のレポートフィールドなど、すべてに使用されます。 。私たちのマネージャーにとって、Excelはそのような苦しみに耐えることができず、働くことを拒否しました。ちなみに、この執着は奇妙な形をとることがあり ます。レポートの場合、この形式が多かれ少なかれ馴染みがある場合、開発ドキュメントの場合は、控えめに言ってもエキゾチックです。

集会が長すぎる

基本的に、日本人の同僚は非常に責任があります。彼らは彼らの決定のすべての結果を理解しているので、長い間これらの決定を下すことができません。彼らはまた集会が大好きです。そして、西洋人にとっては集会が問題を解決して報告する方法であるならば、日本人にとっては彼らの決定について同僚と合意する機会でもあり、彼ら自身の責任の負担を軽減します。







そして、それが何も終わらなかったとしても、その期間は通常、私たちのボードにあったチケットの量に正比例していました。そして、テストは日本側だったので、十分なチケットがありました。私たちプログラマーがどれだけ詳細に立ち入るのが好きか想像してみて、それを日本の要素で乗算します。あなたは通訳を伴って何時間もの詳細な技術的問題を受け取ります。そして、これに日本語から英語への翻訳、そして時には日本語とロシア語でのコメントを加えて、反対側が彼らの順番を待っているとき、私たちは8時間の記録を得る 。



私がチームリーダーになったとき、これは私には合いませんでした-そして、英語でのコミュニケーションへの焦点を誤解させることが多い翻訳の割合を減らし、詳細に立ち入る誘惑に負けないようにしました。一般に、これにより、平均会議時間が約半分に短縮され、バグの数と作業量も削減されました。

言語の壁

日本は自給自足の国であり、移民のレベルは比較的低いです。したがって、私たちが望んでいた英語はあまり人気がありません。A2レベルの対話者が私たちが信頼できる最大の言語です。覚えておいて、 あなたが日本人でプロジェクトを開始している場合、その後、あなたが通訳なしで行うことはできません！プロジェクトの当初から、日本人との交流が不可能だった人がいました。それは、交渉と重要な通信を担当する日本語を話すプロジェクトコーディネーターでした。彼に加えて、何人かの翻訳者が文書、手紙、チケットの翻訳と交渉に参加しました。

言語の壁に関連する困難はプロジェクトが終了するまで続きましたが、そのような状況では、私たちの側の多くの自信と忍耐力が助けになりました。言語が異なっていても、目標は1つであることがわかりました。

いつでもどこでもレポート

私たちのプロジェクトはウォーターフォール開発モデルで実施されましたが、その理由の1つとして、豊富なレポートとスケジュールの継続的な更新がありました。これは、豊富なレポートが純粋に日本の特徴であるということではありません。しかし、ロシアとCISでの同様のプロジェクトを日本と比較すると、極東の味がそのすべての栄光に表れています。チームリーダーとして、私は読者と著者の両方としてすべてのタイプのレポートドキュメントを完全に処理する必要がありました-おそらく財務的なものを除いて：バグの原因の分析による品質の観点から、進歩、並外れた技術、そしてもちろん、滝のスケジュールでは伝統的です。これらの各レポートは、ナーシングホームのスキャンワードの最高の伝統の表が並んだ重いExcelファイル でした。



長い冬のラリーでの継続的なコミュニケーションの過程で、理解は最初に経営陣に、次にチームに広がり始めました。私たちは、同様のロシアのプロジェクトにおけるこの種の報告との主な違いを理解するようになりました-それらは見せるために作られたものではありませんが、プロジェクトのステータスの関連する指標を含み、私たちの日本人の細心の注意と分析（そしてしばしば修正）の対象でした同僚。





和風スケジュール



それでも、それらには意味と目的の両方がありました。たとえば、品質レポートには問題のある領域が表示され、コンパイルすると問題の根底にたどり着くことができ、進捗レポートはこれまでに完了した作業の量を追跡するのに役立ちました。ちなみに、2番目の列は時間の経過とともにますます多くの新しい列を取得し、マネージャーがそれを記入するのに週に2回、場合によってはさらに頻繁に最大3時間かかる可能性があります。スケジュールを考えると、さらに困難になりました。最初は、プログラムでタスクトラッカーから見積もりと一緒にチケットを取得し、MS Projectのスケジュールに入れようとしましたが、非常に気まぐれで、スケジュールは絶えず飛んでいました。かわった。必死で、私はすぐにスケジュールの作成を投入しました-もちろん、Excelで。

時間の違い

私たちはモスクワ時間に従って働いており、日本との違いは6時です。私が出張していたとき、そのような時差は少し気のめいるようでした。あなたは、仕事中に親戚の誰かがメッセンジャーであなたに手紙を書くことさえあるという事実に慣れています、そして私が仕事を始めたとき、それはまだでしたロシアで午前3時..。しかし、最大の不便は顧客とのコミュニケーション中だった。



欧米の同僚と仕事をしていると、常に時代の先を行くように遊んでいるようです。彼らの前で仕事を始め、落ち着いて仕事の気分に耳を傾け、昨日のメールを片付け、集会の準備をすることができます。しかし、違います。日本人の代わりに自分を想像してみてください。開発者がまだ眠っている間に、緊急に修正する必要がある重大なバグを見つけました。一日の終わりからバグ修正を続けていくと理解していても、バグの緊急性に比例して永遠の遅刻感が増します。幸い、私たちのコーディネーターは、日本より1時間進んだウラジオストクで働いています。彼は英雄的に憤慨の主な打撃を受け、日本人の感情を少し弱めたので、これは大いに役立ちました。



それにもかかわらず、日本人が過労する傾向があることを思い出すと、開発者としての私たちにとって、検収試験期間は通常、一日中絶え間ないストレスの原因でした。また、「今日」それを修正することができなかったために部分的に有罪です。しかし、時間が経つにつれて、このモードに慣れ、同時に、バグのより効果的なコミュニケーションとローカリゼーションのために、日本のテスターのチームと開発者は、作業スケジュールを互いに近づけました。

品質に焦点を当てる

私たちが取り組んできた方法論には、多層テストフェーズが含まれます。最初に開発レベルでテストし、次に顧客側でさらにいくつかのフェーズをテストします。完璧主義は両刃のものです：そのような条件は、最初のパーキンソンの法則に従ってフェーズで設定されたすべての時間を食い尽くすことがよくありますが、同時に、それらの細心の注意と細心の注意は、私たちを団結させた小さなもの、つまり最終製品。



多くのプロセスと冗長なルーチンが私たちにとって無意味であると思われる場合は、コードの品質を気にし、その結果、製品は私たちが共通の言語を見つけたものです。異なる時間に、コード全体が2つの静的アナライザーに対して実行されました。クライアントは、見つかった問題を修正するために時間を割り当てました。これは、アジャイル/西洋のプロジェクトではそれほど一般的な方法ではありません。さらに、すべての新規および変更されたコードをテストでカバーしました。必ずしも完全に機能するとは限りませんでした。したがって、時間と効率を節約するために、プロジェクトのバグ修正のアクティブフェーズで主に強調されたのは統合テストでした。ちなみに、私たちの成果物の1つは、テスト実行とコードカバレッジレポートでした。品質に対するそのような懸念は私たちの心に響き渡り、この分野で妥協点を見つけることがほとんどでした。



また、コードの品質向上として、チケットの複雑さに応じて、チームリーダーを含むさまざまな人から最大4件のレビューを行う練習を日本人に提供しました。その結果、GitLabでの自動コード事前レビューの可能性を探求するようになりました。これらすべてをプロジェクトに適用することはできませんでしたが、将来のプロジェクト用に小さなテンプレートを作成しました。レビューの強化に加えて、自動テスト（ユニット、統合、スモーク）の改善に成功しました。

パフォーマンスメトリクス（KS）

記述されたコードの行数（KS）を含む、メトリックがプロジェクトに導入されました。これは、開発全体を通じて激しい論争と議論の対象となってきました。このメトリックは、進行状況を追跡し、バグ密度を推定し、予想されるテスト数、ドキュメントページ、およびレビュー時間の基礎として機能するために使用されました。



コードの行数は、プログラマーの生産性を計算するためにも使用されました。

この方法には多くの問題がすぐに思い浮かびます。UIコードははるかにボリュームがありますが、複雑さは少なく、他の10行のコードは数日間の持続的な脳活動を犠牲にして取得できます。ユースケースの数で作業の評価を開始しようとしましたが、専任のアナリストがいなかったため、開発者の能力が十分ではありませんでした。プロジェクトの途中で、前のチームリーダーは、ボリュームのメトリックとしてメソッドの数を使用することを提案しました。その結果、KSとメソッドの数の両方をカウントし始めました。



時間が経つにつれて、混乱はさらに大きくなりました。実際に費やした時間と実際に生成された量に関する履歴データを使用して、労働時間を量の見積もりに変換する係数を見つけることにしました。執筆に加えて、膨大な数のプロセスタスク、テストフェーズ、レビュー、およびドキュメントが付属していたため、このような計算機は非常に役立ちました。

見積もりと締め切り

日本では、開発者に見積もりを下げて期限を延ばし、罪悪感（「あなた自身がそう言った」）を押して、「犯人」が期限を守ろうとしてやり直すという慣習があり ます。。私たちの状況では、それは時には締め切りの交渉に似ていました。 2〜3人の追加の開発者が問題の作業をスピードアップしないことを確認しましたが、反対側では、ワイヤーが地面に立っていました。さまざまな成功の度合いで、私たちは締め切りを勇敢に擁護し、特に重要な締め切りの前夜に妥協しました。これは通常、オーバーホールで構成され、まれに追加のリソースを引き付けました。しかし、私たちはしばしばこれらの期限に間に合わなかった。



時間の経過とともに、この現象も自動化することが決定されました。私は基本としてチケットを取り、必要なレビュー、考えられるバグを追加しました...私はこれをMSProjectでプルしようとしました。残念ながら、彼は時々異なるタスクの順序を示し、未知の方法で制約を設定しました。時間があまりなかったので、Excelでガントチャートをすばやく作成することにしました。これは、より予測可能で従順であることが判明したためです。したがって、見積もりを簡単に変更できます。見積もりとともに、完了日も変更されました。スケジュールの再構築がはるかに簡単になり、顧客はそれらを気に入りました。締め切りに間に合わないという問題は解決しませんでしたが、タイムシフトについて事前にお客様に警告することができました。

伝統

私が7人で日本に出張したとき、私たちは日本のオフィスで伝統的なドレスコード（ビジネススーツ、薄手のシャツ、ネクタイ）を守るように命じられました。もちろん、日常生活でパーカーを着ることに慣れているプログラマーにとって、これは本当の挑戦でした。それにもかかわらず、時間はその役割を果たし、帰属意識 （群れの本能と呼ぶことができます）が現れ、それはエネルギーを追加し、何らかの形でそれを「私たち」にしました。その写真は面白かった。東京の品川駅には、日本の伝統的な大手企業のオフィスがたくさんあり、毎朝、首都や郊外から何千ものホワイトカラーが集まっていた。スペクタクルは素晴らしいです！





写真提供



通常、私たちの就業日は9時に始まりましたが、日本人の同僚の何人かは後でやって来ました。昼食は、職場からそう遠くないお気に入りのラーメン店に同じサラリーマンが並んでいました。日本では行列の話題を回避することはできません。非常に必要なことなしに誰も行列の前に登ることはないので、それは完全なリラックスです。そして、メトロにはキューのための特別な場所があり、誰もキューを構築するためのルールを破ることはありません、そしてこれは素晴らしいことです。



夕方までに、私たちのオフィスでの仕事はちょうど加速していました。当事務所では、就業日は18:00で終了しましたが、日本人はほとんど出かけませんでした。しかし同時に、日本酒などでストレスを解消することも大好き です。仕事の後-そして彼らはそれをかなり頻繁に行います。そして、私たちが仕事でいくつかの矛盾を持っていたとしても、非公式な設定での労働時間外に、私たちの同僚は誠実な対話者であることがわかりました。



伝統的な日本企業では、日本人は上司との関係において厳格な指揮系統を維持しています。これは、日本とロシアの開発者の間の現在の重要な違いの1つであるように私には思えます。問題が発生した場合、日本人は直接の出演者を非難することはほとんどありませんが、経営陣と双方を非難する傾向があります。ランクが高いほど、責任が大きくなり、失敗のコストが高くなります。すべてがルールに従っています： より強い、より多くの責任。

クライアントは神です

日本は、クライアントに対する特別な態度が特徴です。そして、私たちの日本の顧客はおそらく私たちに同じ態度を期待していました。



確かに日本語で「おやく様はかみさまです」ということわざがありますが、それは本当に当たり前のことです。ロシアの顧客と請負業者の関係を見ると、日本とのコントラストが非常に目立ちます。私のロシアでの生活を通して、パフォーマーとの丁寧なコミュニケーションは顧客に良いことを約束しませんでした-それどころか、サービスを提供する人（宅配便業者、ウェイター、修理業者など）とのスキャンダルと無礼が多ければ多いほど、最良の結果が保証されます。日本では、私の観察によれば、あなたは落ち着くことができます。はい、サービスは高価ですが、それは顧客を満足させることが保証されています。好みの問題ですが、私はこの方法が好きです-礼儀正しく、品質を気にしないでください。

結論

意見の相違や困難にもかかわらず、私たちは日本の顧客と彼の技術チームとの仕事に対処しました。一部の機能は私たちにとって困難で不快であることが判明しましたが、他の機能は尊敬に値し、私たちを近づけました。私たちは何かに同意するか、時間とチームワークが彼らのことをするのを待つ必要がありました。どこかで妥協点を見つけることが判明し、どこかで-回避策です。



日本人の仕事に対する固定観念のほとんどは正しいと言っても過言ではありませんか？すべてがそれほど単純ではありません。



確かに日本では上司と部下の従属が強く感じられますが、最近は若者が制度を破る傾向にあります。リサイクルは一般的ですが、日本ではロシアよりも休日が多くなっています。いつでもどこでも、どんな犠牲を払っても締め切りに間に合う傾向がある過敏な人々がいます-そしてこれは国や考え方にまったく依存しません。日本の同僚との仕事が長ければ長いほど、違いは目立たなくなり、類似点が多く見つかりました。独特の歴史と文化は、国民性と伝統を反映せざるを得ませんが、それにもかかわらず、はるかに多くの共通点がありました。そして、私はこの経験に感謝しています！