こんにちは。テクノロジー部、テクニカルディレクターのSarahです。
テクニカルディレクターはオフショア開発を行っているテクノロジー部のなかでも、開発拠点であるセブのエンジニアと密に連携して開発を行う職種です。
今回は、テクニカルディレクターとしての職務を行うなかで学んだ仕事の進め方や、工夫していることについて書きます。
「オフショア開発／注意点／気をつけること」と検索をかけてみると、「メリット・デメリット」や「失敗の原因」というワードが頻繁に検索結果に上がってきます。しかしこの記事では失敗か成功かの二項対立ではなく、実務ベースで「どうすれば効率的に開発を進められるか」「より良いコミュニケーションを図れるか」を考えます。
この視点はオフショア開発に限らず、日本人同士のチーム開発・海外拠点とのやりとり・日本のビジネス文化に慣れていない人との協働にも適用できるかと思いますので、参考にしていただけたら幸いです。
理由・経緯をできる限り詳しく説明する
改修の理由やその仕様である理由は、たとえ推測できるものであっても明記しています。
現在の問題点や改修が必要な理由がわかっているのとわかっていないのでは、改修内容の理解度や仕様の把握にかかるコストも変わってくるためです。
例えば、「マフィンを作るので中力粉と個包装になっているバターを買ってきてください」と言われたとします。パッと見、「なるほど！ オッケー！」と素直に受け取りたくなりますが、私のようなポンコツはきっとスーパーに着いた時点で初めて「小麦粉のコーナーにきたけど中力粉なんてない。薄力粉じゃダメなの？」「個包装より普通のバターのほうが割安だなあ」とあれこれ考え込み、良かれと思って安いほうのバターを買って帰って怒られたりすることになりそうです。
これが「マフィンを作るので材料を買ってきてください。今回はずっしりした食感にしたいので中力粉でお願いします。オイルを併用するのでバターは少量でいいため、個包装で使い切りのものを買ってきてください」と言われたらどうでしょうか。
理由がわかっているので無駄に悩む必要もありませんし、良かれと思って的外れな提案もしなくて済みます。
やることとやらないことを明確にする
基本的に設計では「やること」を記載すると思いますが、「やらないことを明示する」こともときには必要になってきます。
具体的に言うと、「アラートのメッセージを表示する」という処理の場合、「アラートのメッセージを表示する。エラーではないため処理は中断しない（正常終了する）」のような感じでしょうか。
特に上で書いた「理由・経緯を説明する」と併せてやるのが一番効果的です。理由を説明したから敢えて書かなくてもわかるだろう……と油断しそうになるところですが、「Aの理由でBという変更を入れるため、CはせずにDを行う」のような構文にするのがベストかと思います。
上記の例に当てはめると、「操作ミスが多発しているためアラートメッセージを表示する。仕様上この操作は許容されていてエラーではないため、処理は中断せずにメッセージの表示のみを行い正常終了する」といった感じです。
私が一緒に働いているエンジニアは行間を読んで理解してくれる人が多く、設計書に書き漏れている事項があったとしても適切な対応をしてくれるため、私の説明不足により間違った判断で時間を取らせてしまい、申し訳なく思ったことがあります。
ドキュメントと通話を使い分ける
テスト方法はビデオ通話の画面共有で積極的にハンズオンするようにしています。
日本語のシステム＝セブのエンジニアからすると読めない言語のシステムの開発をしているので、私からすれば簡単な操作でも、躓いて時間がかかってしまうこともあります。今私が携わっているシステムでは、ブラウザ上の翻訳機能が使えるため頻繁には発生しないものの、明らかにエラーが出力されているのにエンジニアが気づかなかったこともありました。
テストで画面遷移が必要なものは設計の時点でスクリーンショットを添付して手順を共有していますが、条件が複雑な処理を通したいときなどコードを辿るのも限界がありますし、画面共有して説明してしまうのが一番わかりやすく手っ取り早い方法だと思います。
一方、複雑な改修内容はなるべく文章で共有しています。
一度読んでもらって、改めて質問があればしてもらうことができるのと、口頭での説明だけだと後になって忘れてしまったり、気になったことがあっても会話の中で流れてしまったりするためです。
また、開発以外でも、重要な決定事項や組織変更については対面での共有と併せて、文面での共有をしています。
悪い例として、あるミーティングで日本側のリーダーが日本側のメンバーAがチーム異動になったことを伝えていたのですが、そのミーティングのメインテーマが全く関係なかったこともあるのかうまく伝わっておらず、後日セブ側のチームリーダーに「Aさんは最近朝会に参加していないけどどうしたの?」と聞かれたことがありました。それ以降、重要なことは口頭で連絡するだけでなく、社内の連絡ツールでもアナウンスするようにしています。
おわりに
入社したときはオフショア開発も上流工程のみの業務も初めてで、今もちゃんとできていると言えたものではありません。
失敗する度に、同じ轍は二度と踏まないぞ！ と泣きながら上流工程の記事を読み漁ったり、セブ側のリーダーと集合して話し合ったり、タスク管理しているノートアプリの一番上にデカい文字で「〇〇に気を付ける！！！」と書いたりしているうちに、なんとなく見えてきたものがあります。今回は「これ気を付けてるとそこまでひどい失敗はないかも……」というポイントをシェアしてみました。
オフショア開発並びに日本人同士のチーム開発の上流工程・海外拠点とのやりとり・日本のビジネス文化に慣れていない人とのコミュニケーションで苦戦している方々の力に少しでもなれれば幸いです。これからも一緒に爆速で成長していきましょう〜〜〜👦🏻
