ルワンダのソフト開発会社を立ち上げていくお話の第4回目になります。
これまでは、事のきっかけから、現地に会社を立ち上げるまでのお話をストーリーとして書いてきましたが、今回は実際にルワンダとオフショア開発をやってくにあたっての課題や、結果としてどのような形で体制を作り、業務を進めているかなどを紹介できればと思います。
過去記事はこちらからご覧ください
時差の課題
まずは時差。
最初の課題であり、ルワンダでオフショア開発をしていると話をしたときに最初によく聞かれるポイントになります。
日本とルワンダは時差が7時間あります。これはどうやっても変えられない事実なので、これをどうするか。
まず、弊社の営業時間 9:30 ~ 18:30 に対して、ルワンダの営業時間は、8:00 ~ 17:00
時差が7時間なので、ルワンダ側が動き始めるのが、日本時間で午後3時です。そのため、営業時間としてかぶるのは、日本時間で 15:00~18:30の3時間半です。
中国や東南アジアなど、時差1~2時間のところは、営業時間があまり変わらず、ほぼ同期的に仕事ができますが、ルワンダとのこの時差だと同期的な業務遂行はまぁ無理です。
そのため、弊社ではこのような流れをとりました。
| 日本時間 | 日本 | ルワンダ |
|---|---|---|
| 午前中 | 前日分のルワンダ側の成果をチェック、テスト | 寝てる |
| 13:00~15:00 | フィードバック、チケット作成 | 朝早いので人によっては現地時間の6時とかにリプライ返ってくる。 |
| 15:00~15:30 | 同上 | 出社、朝会 |
| 15:30~18:30 | ルワンダ側とコミュニケーションをとりながら仕事進める | 開発作業 |
| 18:30~23:00 | 帰宅 | 開発作業 |
| 23:00~24:00 | 私については自宅でも夜中仕事していることが多いので、ルワンダ側の終了時間頃に今日の報告を聞く、またはチャットで経営的な話をしている。 | 報告、日本側とのコミュニケーション |
なお、上記表の日本側の23:00~24:00については、私自身がブリッジエンジニアとして動くことが多かった初期〜中期のパターンで、今は切羽詰まってない限りは、翌朝にレポートと含めて確認しています。
ご覧の通り、同期的に仕事ができないので、ルワンダが休んでいる時間には、ルワンダの成果をチェックし、フィードバックや指示をチケット化して伝えるところに注力し、日本が帰った後は、ルワンダ側はその指示に従い作業を進めていく、という感じです。
これらをきちんと回すためには、密なコミュニケーションが取れることが前提の作業体制ではなく、ツール群を導入し、ルールに基づいてしっかり運用していくということが大事になります。
これまでの記事でルワンダ人の気質については少し書きましたが、実際ルワンダにいるエンジニア達は、上記のように設定した業務ルールに沿ってしっかり仕事をしてくれたので、このようなワークフローでも大きな障壁なく順調に立ち上がり、今日においてもこの流れに大きな変化はありません。
言葉・コミュニケーションの課題
こちらも当然ですが100%聞かれる課題です。
中国やベトナムなど、アジア近隣諸国は日本からの仕事をとるために、日本語ができる必要があるということで、日本語が出来る人材を育成し、ブリッジSEとして立てていると聞きますが、ルワンダには当然ながらそのような人材はいませんでした。育てようにも、日本語教室など現地に無いですし、我々も外国人に日本語を教えるスキル・ノウハウなどは持っていません。
幸い、ルワンダは英連邦に加盟していることもあり、高校教育から英語となっています。
大学までいってITを学んできた人材は100%英語が出来る状態だったのと、こちらも英語はできないわけではないので、英語でのコミュニケーションとしました。ちなみに、弊社のルワンダにおいてのオフショアは、最終的に現地での日本語ができる人材の育成はしない、という方針をとったので、今現在においてもやり取りは英語になっています。
では、日本語で使われるソフトウェアはどうしているのか？というと、日本側のエンジニアチームで翻訳対応しています。スマートフォンアプリ開発にしてもWEBアプリ開発にしても、今は多言語対応がフレームワークの基本機能として搭載されている環境です。
日本の中で、日本向けだけにソフトを作るときはあまり使わない機能かもしれませんが、弊社で開発する場合はこの機能の活用は必須であり、日本側のチームはフレームワークの機能を利用し、おもに言語ファイルを作成し差し込むことで日本語化しています。
そのため、弊社が請負い、ルワンダでオフショア開発して納品するソフトウェアはいずれも日本語、英語両対応で納品されています。（ブラウザ設定の影響で、ふいに英語が出てしまうことを防ぐため、設定で日本語固定とかしていますが・・）お客さんによっては、両対応のままとして、外国の方にも使ってもらおうと有効に使ってくださっているところもあります。
また、現地とのコミュニケーションは、Slackを中心としています。事業を始めた頃は、Slackがまだ存在してなかった（その後もしばらくはプロダクトとして初期だったので未採用）ので、HipChatというツールを使っていました。HipChatはSlackに買収されたので、サービス終了に合わせてSlackに移行して今日に至ります。
そして意外かもしれませんが、我々の日本〜ルワンダ間の開発プロジェクトでは、オンラインのビデオ会議を必須としていません。1回もオンラインのビデオ会議を行わずに完了しているプロジェクトの方が実際多いです。
これには理由があります。
先ほど書いたように、現地側の日本語教育・対応をやらないと決めたため、必然的に日本側が英語での業務に対応していく必要があります。そうなったとき、オンラインでの英語でのミーティングを必須とした場合、実際問題日本側のブリッジに求められる要求が極端に上がると考えています。すなわち採用の難易度が上がるということ。
また、オンラインでの英語ミーティングに不慣れな人に無理やりやってもらったところで、お互い中途半端な理解で伝えた気になってしまうために、その準備も含め多くの時間を使うことに意味があるのか、ということもあります。
オンラインでのビデオミーティングをやならない場合、仕様やフィードバックについては、ドキュメントやSlackでのコミュニケーションに頼ることになりますが、そのほうが仕様をより具体的、詳細にドキュメントに書き込むことになりますし、テキストとして履歴に残るため見返すこともできる。何より、日本人は聞く話すが苦手ですが、読み書きはある程度できる人はエンジニアだと多いですし、テキストベースの方が多少時間はかかるにしても、翻訳ツールを併用し、しっかり理解し、しっかり意味を伝えることが出来ると思います。
そのように考えるとトータルで見た時、聞く話すのスピード感に必ずしも遅れをとるものではないと考えています。
後述のプロジェクト管理にも関わりますが、このようなやり方をしているためにドキュメントは多くなります。そのため、フォーマットについては定めていません。仕様書というよりコミュニケーション用のドキュメントであるためです。例えばエラーなどは言葉で伝えようとせず、どんどんスクショ＋お絵描きで伝える、動画でとってこちらの様子を伝える、といったこともしています。
余談
最近、Zoomなどのオンライン会議におけるリアルタイムの翻訳機能の実用化が現実味を帯びてきました。我々はテキスト中心と言いつつも、オンラインでのビデオミーティングに価値がないとは思っていません。これらが本当に実用に足るものになってきたとき、我々の業務フローもこれありきで見直すこともできると思いますし、日本から見た時オフショアの敷居が劇的に下がる可能性があり、これは日本のエンジニア業界に大きな変化をもたらす物として非常に注目しています。
意識せずとも日本語バリアに守られている国内エンジニアは、いつの間にかグローバルの競争に晒されている、なんてことが起こるかもしれません。逆に世界で目を向けられるチャンスでもあるため、海外のエンジニアと一緒に仕事をするという経験値がより価値をもつ時代が、遠くないうちにやってくると見ております。
プロジェクト管理の課題
プロジェクト管理という点では、一般的にいうアジャイル開発に近い体制をとっております。ただ、厳密なアジャイルかというとそうではなく、我々のやりやすい形でコンセプトを取り入れていると言って良いかと思います。この辺りはまだまだ改善の余地はあると思っていますが、初期から現在に至るところをお伝えできればと思います。
基本的には受託開発が中心であるため、クライアント〜日本側プロジェクトチーム〜ルワンダ開発チームというプロジェクト構造となります。対クライアントにおいては、要件の決まった、納期のあるプロジェクトにおいては、やはりウォーターフォール的な見せ方の方がクライアントの理解は得やすく、スケジュール表としてはそのように引いています。一方で、日本のチームとルワンダチームの間は、短い期間でスプリントということで期間を区切り、小さくリリースできるようにしています。小さいリリースは、小さいウォーターフォールのような構造になります。
オフショア開発では、仕様書書いて丸投げはNGだと思っております。
日本人同士でもそうですが、仕様書を書こうとコミュニケーションを密に取ろうと、どうしても認識の齟齬は発生する物です。我々の場合、時差や言語の課題がより大きいため、仕様を伝えることと、それに対応して実装した物のスコープが大きくなるのはリスクだと考えています。その意味で、全ての仕様を書き切って伝えて、数ヶ月経った後に完成品をレビューするのはリスクして最大という意味で、丸投げはNGとしています。
プロジェクト管理ツールとしてはRedmineを長く採用しており、1つのチケットのスコープをなるべく小さくし、チケット単位でチェックするような形です。日本側のブリッジエンジニアはほぼ毎日、最新コードを取り込み、手元の環境で動作させ、確認やフィードバックをおこなっています。
そのため、日本側も常にルワンダ側で作っているものと同じものが動かせる環境を維持することにつながっています。
これは納品前後での急な問題の対応などにおいて、ルワンダ側が深夜帯で動けない時に、日本側でも対応できる体制を維持することにもつながっており、これにより時差による本当の問題、日本側で緊急の時にルワンダが稼働するまで対応できないという状況を防いでいます。
このようにすると、やはり日本側の負担もそれなりにあって、コスト面で不利ではないかと思う方もいらっしゃるかと思います。はい、それは100％ではないですが、事実であり、そのような課題があるのは否定できません。ただ長い目で見た時にはまた話が少し変わってくることと、将来に向けた我々の戦略の一部でもありますので、単にオフショアだから安いという点を我々の売りとはしていません。
このあたりどのような考え方をしているかは、また書いていければと思います。
まとめ
ここまで、時差、言語、プロジェクト管理体制などについて、どのような課題感をもちどのような体制でやっているのかを書いてきましたので、簡単に要点をまとめます。
- 時差はハンデとならず、やり方によりむしろより長く業務にあたれる。
- コミュニケーションはテキストベースとし、翻訳ツールなども活用し、時間が多少かかっても正確に伝える。そして、履歴を残す。
- 日本側で同等の作業ができる環境と技術力を維持し、小さいスコープで成果物を確認していく。
これらが全てではなく、細かいところまで書いていくと書ききれないので、大雑把ですがまとめてみました。
コメント欄などに質問等いただければ、また次回以降の記事に反映するなどして書いていきたいと思います。
参考: 使用しているツールなど
弊社ではプロジェクトを進めるにあたって、下記のようなツールを中心においています。
- ソースコード管理: Git / GitBucket（オンプレ）
- プロジェクト管理: Redmine（オンプレ）
- コミュニケーション: Slack (最初はHipChat)
- ファイル共有: Google Drive / Dropbox (メインはGoogleだが過去Dropboxだった経緯で残っている）
- プロトタイピング・仕様書: Figma (XDを導入した後、Figmaに切り替えています。並行して共有フォルダで運用）
- IDE: 最終的には開発者次第ですが、JetBrains社のライセンスを定期購読しており、それの利用を推奨しています。（やっぱり最近VSCodeが増えてて、JetBrainsのサブスク続けるか悩み中・・）
第5回