③グローバル開発チームを作ろう (開発編)

前回の記事 ②グローバル開発チームを作ろう (採用編)では主にUpworkを用いた場合での採用フローのポイントを説明した。ここでは、グローバル開発チームで納品のないラボ型受託開発を行う場合での社内外での動きに関して自分なりのポイントを説明する。

採用活動が一段落し、海外在住のリモートワーカーがSlack, Teams, Chatwork ワークスペースに入ってくるので、チームの一員としてオンボーディングを行う必要がある。ロゴやUIデザイン作成などの単発の作業依頼ならSlackなしで、Upworkメッセージ上で、完結するかもしれない。ファイル送受信も問題なく行えるし、かなり高機能で普通に使える。但し、1対1でやりとりする前提のUX設計になっており、チームでのコミュニケーションでは使用不可。

ここからは、プロジェクトマネージャー(Webディレクション含む)の領域である。目指すはグローバルチームを率いて高速かつ高品質でプロダクト開発を継続的に改善するチーム組成である。フルスタックエンジニア出身の方ならシステム設計、タスクチケットの分解、開発者へのタスクアサインが精度高く行えるので失敗することはない。開発経験がない方でも、ロジカルで、コミュニケーション能力が高ければ開発者からシステム設計に関する論点を効率的に吸収して、プロジェクトを問題なく進めることができる。期待した成果物が短期間・高精度・再現性を持った状態で何度も出現するのはかなり楽しい。

グローバル開発チームの公用語は英語になり、Slack上は英語で溢れる。しかし、本質は日本語でも英語でも変わらないので、日本語でディレクションがうまくできる方なら、英語でも慣れればうまく動けるだろう。なので、目新しい話しは多くない。社内と社外に分けて気になるポイントを挙げていく。

社内編
(開発者・デザイナーとの協業)

基本

メンバーを揃え、ロールを定義し、プロジェクトが開始し、流れを作りだすと、まずツールの選定があると思うが、本当にその時に必要なツールだけ導入したい。1人しか開発者がいない場合にプロジェクト管理ツールは入れる必要がない。Slack上でのピンでタスク管理で十分だろう。変にGithub Issueで会話する必要もない。人数が増えてくるとGithub Projectなどでカンバンの運用でタスクの管理を始めるがチケットラベルを必要以上に細かく使い分けるなどの作業フローの最適化にこだわり過ぎないで程々の状態で止めたい。プロジェクト人数が増えすぎると複数チームに分解が必要になるが、TOC理論で提唱される全体、各チームのボトルネックフロー(生産量 < 需要 の工程)を素早く見つけ出しひたすらトータル生産量を最大化する施策を打ち続ける。ボトルネックが自分自身になっている場合もあるので注意。

プロジェクト開始後なるべく早くに、デプロイ自動化でレビュー速度を上げたい。開発者のコードプッシュ後のプロダクトマネージャーによるレビューを如何に早くできるかが序盤は効くのでこのフローの簡略化に拘る。WebアプリだとFirebase HostingやNetlifyなどでブランチベースの自動デプロイ、モバイルアプリだとGithub Action + Fastlaneでブランチごとのビルド自動化(App Store, Play Store)をなるはやで構築する。

テキストチャットベースでのプロジェクト進行に慣れすぎた場合はWEB会議する機会がなくなるが、たまに温度感を合わせるためにもオンライン上でカメラON付きの挨拶はしたい。定例、朝会、夕会はやはりあった方が良い気がする。各社のベストプラクティスがあるだろう。

各国の長期休みには注意する。インド Diwaliの10月、中国、ベトナム 旧正月 の2月等の長期休みがある。長期休みやその他諸事情での休暇がある場合には、事前に知らせてもらうようにする。一方で、正月は海外エンジニアはフル稼働で日本側で対応できないケースもある。また、インドの住環境は日本ほど発達してないので、リモートワーク在宅の場合の停電(オフィスだとバックアップ電源がある)や毒キノコや腐ったチキンによる食中毒などの問題が発生し、急遽稼働不可になる可能性もある。突然連絡が取れなくなったと思ったら、冤罪?のような話で、インド現地警察に逮捕されて留置所に入っていたという話も過去にあった。

採用した海外エンジニアが期待通りに動いてくれない場合に、パブリックチャネルでの過度な叱責はやめる。日本的な公の場で叱る文化は海外に基本的にないし、自分の感情をコントロールできない能力が低い人間だとレッテルが貼られる。労働組合が勝手に形成されたり、怪文書が送られてきたりする。DMを用いて、契約条件の更新や低パフォーマンスの指摘改善依頼などを行おう。一方で褒め称える場合はパブリックチャネルで派手に行うというので良いだろう。

優秀で熱意あるフリーランサー達は思いやりがないと去っていく(多くはより良い条件を求めて)。ジョブホッパーを惹きつける著名な会社にはなりたいところではあるが、人の出入りが激しいと採用コストはやはりかかる。Slack Botのメンション付きで、Daily Reportの提出を要求するなどで、日々のルーティーンワークの自動化は計っても良いが、必要以上に自動ワークフローにフリーランサーを入れ込まないようにする。不必要な非同期コミュニケーションを乱発して、開発者のコーディーングフロー状態を阻害するのは避ける。SlackやTEAMSでの不必要な通知をミュートするようにこちら側から提案したい。VoicePing ( https://voice-ping.com/ )の目指すべきところは、モニターは必要最小限に抑えて、最も生産的なチームコラボレーションを長期的に実現するコミュニケーションツールである。

主にインド人エンジニアとSlack上で仕事をすると、Very Good Morning!!! hope you are doing well などの挨拶をパブリックチャネルでたくさん見かける。毎日に感謝している姿勢は大変尊敬できる。日本人同士の日常Slack会話だと、おはようございますという前置きに加えて伝えたい内容を結論から求められるので面倒である(挨拶だけ連発すると間違いなくハブられる)。何気ない挨拶を大事にしたい。

チーム内に英語ができるテック寄りPMがグローバル開発で力を発揮き、重宝されるが、必須ではなくミドルマンで代替可能ではある。要素分解すると、日本語・英語ができる日本人(ロジカル強め) と 英語ができるエンジニア(テックリードレベル以上)がいれば原理的にプロジェクトは回る。英語ができる日本人は近年オンライン英会話の影響もあり、増えているような気がする。但し、ミドルマンを挟むとコミュニケーションコストはもちろん増える。持続可能なチームで長期的な開発を進める必要があるので、単一障害点はなるべく避ける形で合理化を計っていく。

蛇足ではあるが、自分みたく開発エンジニア出身だと、開発組織の最適化に力を入れすぎて、開発力はかなり馬力をだせるが、開発物が顧客にとって最適でなく自己満足というのが発生しやすい。顧客の課題は顧客に聞くしかないので、あまり開発組織の最適化に力を入れすぎるのも良くない気がするので、外に遊びに行こう。

英語を使いこなす

英語力でディレクション力が決まると言っても過言ではない。特に重要なのはリーディングとライティング力である。スピーキングとヒアリング力は最悪カタコト英語(出川イングリッシュだと厳しい…)でもなんとかなる。Slack上での英文が読めないので機械翻訳を使ったり、英語でのテキスト入力ができないので日本語から英語への機械翻訳を毎度するというのは現実的でない。最低限の英語力はやはり必要となる。慣れてきたら、英単語のスペルミス、英文法のミスも犯さないように心がけたい。神は細部に宿る。自分も今だに英語学習している。Grammarly ( https://www.grammarly.com/ )などのChromeプラグインで楽にリアルタイム英語校正できる。短い文章で正確に物事伝えて、ディレクションできると、自分の持ち時間がどんどん増える。常日頃から、結論ファーストで根拠など基本的な意見の主張方法は鍛える必要がある。もし、相手がこれらの能力不足な場合には短時間で指摘補正させて、コミュニケーションを円滑にする。良い教育者になる必要がある。自分で認識できてないと、相手に指摘できないので、常日頃から上級者のテキストチャットスキルを盗む必要がある。要件を伝える場合に、Aであって、Bでない(not A, but B)というような論理補強はできる限り入れたい。グローバル開発チームで使われる英語のパターンはほとんど決まっている。Vinegared Rice(酢飯)などの英単語が出てくるケースは少ない(寿司の写真がアップされて飯テロがなければ)。

英会話もマスターできると何かと便利。たまに、インド人やベトナム人の英語訛りが酷いので英語を聞き取ることができないという話を聞くが、日本人の英語訛りが一番酷いと思っている。Googleの音声認識アプリでUS英語認識に設定して長時間スピーチを行い、どの程度正しく発音が正しくできていかを自己チェックしたい。Otter.aiだと日本人英語もよく認識されるという話も聞くが。現代だと、音声認識アプリを利用することで発音練習できるのでかなり助かる。昔は正しく発音できているかの判定がネイティブに聞いてもらって判定しかなかっただろう(英検のスピーチ面接)。

英語でコミュニケーション取っているとかなり省エネと感じる瞬間が、"お世話になっております or お疲れ様です" とか "了解です。" が hi, okで済む点である。Webディレクションにおいては、これらの日本語単語をSlack上でテキストタイプしてる時間は無駄。社内公用語を英語化したい。

日本には英語を日常的に使える職場が実はそこまで多くないので、英語を使いたい高学歴ハイスペ職歴層の方が英語必須の環境だと進んでジョインしてくれるというケースが何度か起こっている。英語を公用語にすることで日本国内側からも優秀な人材が集まってくるというケースがある。国際結婚をした女性、外国人留学生、外資系出身者は優秀で熱心。

動画でのコミュニケーション(Loomを使おう)

動画を使ったコミュニケーションは導入コストは低いが効果が大きいので、早い段階でLoom文化 ( https://www.loom.com/ )を取り入れたい。Loom動画作成時間はわずか数分になるが、情報量がかなり大きいので効率的なコミュニケーションを実現できる。弊社開発チームではGithub Pull Requestに含める項目として、Loom動画の音声付きプレゼンテーション(顔出し不要)で要求動作の証拠提出を必須としている。これは、開発者もしくはPdMのレビュー速度と精度を上げる。必要があれば、URLで簡単に共有できるのが良い。開発中タスクの進捗具合をLoom動画で共有するような流れも作っておきたい。また、バグ報告のフォーマットとして、テキストでの説明的な再現手法に加え、Loomでの再現動画も提出を必須としたい。但し、Loom動画のみで相手に結論を探させるようなことはしないように、テキストでの補足は常に加えるようにルールを決めておく。数分の動画を最初から全部見るのは大変。

QA・ソフトウェアテスト(品質管理)

プロダクトの品質管理を継続的に高い水準で行なっていくのかは非常に難しいと感じる。自分も未だに絶対的な解は見つけ出せないでいる。Autifyなどのテスト自動化ツールをうまく運用すれば楽できるのかもしれないが、やったことはない。グローバル開発チームのQAは日本語・英語扱えるテスター・QAというロールが必要で社内外でリソース確保する必要がある。小さなチームで、有能なQAを求めると、行き着くのは、ユーザー課題をどうやって解くかという観点把握 や 開発者にうまく改修依頼させるディレクション能力をQAに求めることになる。PdM・PjM力が必要となる。ユーザー体験に本質的に影響がないマイナーバグチケットの生成に溢れPMや開発者の時間が奪われるのは避ける必要がある。高度なQAスキームの構築がプロダクト成功の鍵となるのは間違いない。今だに継続的かつ生産性の高いスキームの確立ができていない。他社がどのようにうまくやってるのかは気になる。

社外コミュニケーション
(クライアントとの会話)

信頼関係を作る

仕事に流れ着くまでに、良くあるケースが特定の問題が解決できない、知識が不足している(コンサル)で困っているか、汎用的なリソースが足りないである。新規開発受注を行う場合には、信頼関係を作るところから始まると思うが、徹底的にGiverであることが求められる。成功者や事業主は金を持っており、こちら側が与える価値が妥当であれば、報酬という形で返ってくる。但し、金がないと報酬は出せないので、その場合は他の付加価値に期待するか見返りを求めないスタンスになる。

ラボ型受託開発・請負開発・月額コンサル・その他時間単価契約問わず、社外でのコミュニケーション御作法は異なる。胡麻すりは要らないが、顧客のビジネス成功を導く為に、工夫は必要。絶対的な信用を勝ち取るというスタンスを貫く。信用は短期間では生まれず、長期的に結果を出し続ける必要がある。結果が出せずに、金の切れ目が縁の切れ目というのは避けたい。成功する起業家・経営者は常に時間に煩い。即レスが重要という話がTwiterでよく流れるが、やはり即レスは必須と断言せざる得ない。SES 準委任契約だとバグを生むこと や 知識の属人化でLTVを最大化させると結果として儲かるという話をどこかで聞いたが、この時代だと悪い噂はすぐに広まる。誠実に生きたい。バリューを出していない状態で報酬をもらっていたら、契約期間も無視して、こちら側から早期契約終了を打診したい。

月額ラボ型受託開発で支援を行う際に、こちら側のリソースの都合でマイナーな言語やフレームワーク, 不必要なネイティブアプリ開発、レガシー技術は行わないようにして、内製化が進んだ際にスムーズに移行できるように開発支援したい。生産性が低く、エンジニアに不人気なレガシー技術を使うと、開発の内製化時に、将来的に追加で採用・開発コストを負担してもらう必要がある。

信頼を獲得していくと、プロジェクトチーム内での重要なステークホールダーとなり、多様な意見を求められる状態になる。この状態が複数のプロジェクトで発生すると忙しいと感じるようになる。

効率性

誰が発言・判断したかというのはやはり重要になるので、プロジェクトが始まる前にステークホールダーの力関係を全て理解した上で発言したい。組織図を考慮せずに、発言を繰り返すと先方側で、誰にどの情報を伝えるかのワークフローを追加で考慮させることになるので、不必要な担当者が出現する。クライアント側の見えないワークフローに関するヒアリング・理解・予測を行い、クライアント側での時短になるべく貢献できるようなコミュニケーションを心がけたい。正社員契約と違って業務委託契約はパフォーマンスが低ければいつでも打ち切られる。

細かいところまで気をつける。やりとりする際に、タイミングを見て一度に重要なこと聞けば効率的だろう。非同期でいつでもコミュニケーションが取れるからといって、都度細かいボールを相手に渡していてくと、コミュニケーションに難があるやつだとすぐに判定される。質問する場合でも、仮説を常にセットで用意する。成果物のプレビューURLの確認依頼をする際もWebブラウザのシークレットWindowで問題なく見れるかどうか確認し、Google Spread Sheetの共有URLを送った際に先方からパーミッション許可お願いしますなどの不要なコミュニケーションはゼロにしたい(セキュリティポリシーの把握はした上で)。また、開発やデザインの成果物ができた際に、"できました、こちらで確認お願いします"で終わらせずに、Loom動画で確認手順から差分アップデート内容を網羅してプレゼンしたい。普段のやりとりで、質問を受けた際に、的外れだと思って背景意図を考慮した返答をしたくなるが、まずは質問に対する的確な返答を"はい or いいえ or 内容"で返した後にしないと印象は悪くなる。

進捗催促がある場合は危険フラグ。プロジェクトマネージャーがフォーカスすべきWhenの共有・可視化が足りておらず、クライアント側で追加で進捗催促する工数が発生している状態。

クライアント側への提案・教育も常に必要。相手の要望通り、言いなりになっても、投下資源(時間・カネ)に対する生産量は最大化になるわけではない。そもそもの課題設定が良くない場合は、ソリューションを検討・実装するのが無駄というのがよくある。また、開発した機能にバグがある場合に受けるテキストでの報告。OOが動きませんという情報だけではこちらがも動けない。バグ報告して頂く際に、あまり手間がかからない場合は、Loom動画のURL、再現手順のテキストを貰い、根が深く緊急性が高い場合はWEB会議でなるはやで対応する。Loom動画でバグ報告を受けると、どのURLでそもそも開いているのか、ブラウザやOSが何なのかという情報がすべて手に入る。

当たり前だが、ビジネスが継続して成功しない限り、コンサル・映像制作・デザイン作成・開発等の仕事が継続発注されることはない。クライアント側の成功を導くために、期待された依頼内容 + 新規提案で頑張ることしかできないが、全てやり尽くしたかは毎日考えたい。

https://twitter.com/atyenori
Twitterで、グローバル開発チームに関して呟いてますのでフォローお願いします！