ODC開設から1年経ったので大連で振り返り会をやってきました

はじめに

みなさま、こんにちはCTOの大神です。11月11日〜15日まで中国大連の帝邦科技発展有限公司に出張してきました。以前のブログ「中国の大連に開発センターを開設して３ヶ月経過した現状と今後」でODC (Offshore Development Center)を紹介しましたが、早いもので11月で開設から1年が経過しました。よその子とゴーヤは育つのが早いと言いますが、時が経つのは早いです。
この1年間にODCでは主に新機能の開発を担当し、ConfitとSMOOSYで、投稿情報インポートやプログラム日程表のエクスポート、学会ウェブサイト機能など9機能をリリースしました。
成果はあるものの、課題や改善点が溜まってきましたので、振り返り会で1年の成果と現状の課題、次の1年間をもっと良くするためのチーム目標を設定してきました。

ODCとは
オフショア開発センター(Offshore Development Center)と呼ばれるラボ型開発の契約形態です。任意の期間で契約することで、人材をアトラス専用に確保でき、サービスの業務内容や機能仕様などノウハウを蓄積できるメリットがあります。
アトラスでは、継続的にサービスの機能追加や既存機能の改善・拡張をしているので最適な契約形態です。

１年間の振り返り

大連の11月は気温10℃以下で、夜には0℃以下にまで下がり寒いですが、ODCメンバ7人とCEOの彭さん、アトラスのテックリードの計10人で、１年間の成果、現状の課題、今後の取り組みなどを熱く語り合いました。

No.	システム	リリース日	機能名	備考など
1	Confit	2019年2月26日	発表希望カテゴリの希望順位の拡張
2			大会共通アカウントの対応
3		2019年5月9日	投稿情報インポート機能
4		2019年9月12日	投稿情報インポート機能（査読用ファイル追加）
5			投稿時の査読用ファイルの登録機能
6			プログラム日程表エクスポート機能
7			予稿原稿PDFと査読用ファイルのプロパティの個人情報削除
8			プログラム区分表示色の設定
9	SMOOSY	2019年11月5日	学会ウェブサイト機能(その1)
10	Confit	2020年1月9日	参加登録のオンライン決済に GMOペイメントゲートウェイ決済サービス追加	開発中
11	SMOOSY	2020年1月中旬	学会ウェブサイト機能 (その2)	開発中

現状の課題

あらかじめ日本の開発チームで課題と改善点を出していたので、それの共有とODCメンバからも改善案を出してもらいました。ソフトウェア品質に関することやコミュニケーションに関すること、手順や規約に関することなど現状の課題や問題点を出しあいました。課題は様々ありましたが、主に3つにまとまりました。

コードレビュー時の変更依頼数の多さとソースコード品質の課題

ODCの開発チームのソースコードは、日本の開発チームがレビューしています。開設当初の比較的複雑でない拡張を開発していた時はコーディング規約に関するレビュー指摘・修正依頼が多く、さらに担当機能の業務仕様が複雑になるにつれて誤処理や処理性能に関する指摘・変更依頼が多くなり、継続してレビューの回数（修正して再レビューの回数）が多い状況になっていました。ODCでの開発が多い時は、日本の開発チームのレビューの負荷が高くなり、開発作業の進捗に影響がでてきます。
また、アトラスではソフトウェア品質管理でコーディング時のソースコードの保守性や処理速度、信頼性を重視しているので、ODCメンバがこれまでの経験で重要視していなかった観点もあります。コードレビューで指摘された変更依頼はリスト化して、レビューを依頼する前にセルフチェックするなど、改善していましたが、この振り返り会でコードレビューを1回で完了できるコーディング品質の向上を目指して対策を練りました。

コミュニケーションの課題

日本の開発チームから機能仕様をODCのプロジェクトリーダーに伝える場合は日本語力があるので、あまり問題になることはありませんが、仕様書は日本語で記載してあるので、プロジェクトリーダーからODCメンバへの仕様伝達時に理解の誤りにより間違った仕様でコーディングしてしまいレビュー時に気づくケースがあるようです。
また、ODCのプロジェクトリーダーを通さないメンバ間のチャットツールやレビューコメントでのテキストコミュニケーションでは時間がかかったり、意味がわからなかったりするケースがあります。
日本の開発チームとODCの開発チームで意思を正しく・早く伝えるには、全員が問題なく日本語でのテキストコミュニケーションできるところまで勉強が必要であることを再認識しました。

仕様理解・業務理解の課題

ODCでこの１年間は新機能の開発を担当してきましたが、新機能でも既存機能の改修が必要な拡張もあり、既存機能の仕様理解不足による手戻りや不具合に発展するケースがあります。
すでに開発対象のシステムはそれなりの規模があり、全ての仕様を理解するのは困難ではあります。これはODC特有の課題ではなく、日本の開発チームでも新しく参加するメンバは既存機能の理解に時間がかかりますので、プロジェクト開始時の仕様説明のやり方の変更や既存機能の保守作業も担当するなど対策を考えました。

次への目標設定

今後はもっと効率よく、もっと高い品質で開発していくために、プロジェクト内で取り組む目標を設定して、その日から取り組みを開始しました。アトラスではグループごとにグループ目標を設定して取り組む目標管理を10年以上継続しています。
アトラスの変化の歴史はこの目標管理の歴史でもあるので、ODCにも目標管理を導入しました。

目標管理とは
目標管理とは「目標による管理」と呼ばれるピーター・ドラッガーが提唱した組織のマネジメント手法の1つです。組織内のグループの担当者に自らの業務目標を設定してもらい、その進捗や実行を自ら主体的に管理する手法です。各担当者の自主性に任せることで、主体性が発揮されて結果として大きな成果が得られます。目的や達成目標を全員で共有して自分のこととして取り組むことが重要です。

コードレビューを1回で完了

ソースコードの品質を向上させ、保守性、信頼性、拡張性、処理速度などを向上させることが主な目的です。
この要求を満たしていないとコードレビューで指摘・変更依頼が多くなり、再レビュー時も指摘・変更依頼がありレビュー回数が多くなるという悪循環で、全体的な生産性が下がります。
まずはコードレビューを1回で完了できることを目標として、ソースコード品質を向上させる目標を設定しました。
リーダブルコードの中国語版の書籍で、以前からコーディングルールを共有していましたが、さらにこれを徹底するようにしていきます。
取り組みにはリーダブルコードの勉強会、セルフチェックリストの改善などを設定しました。

継続的な仕様理解

ConfitやSMOOSYは機能追加以外にも、利用者の操作で発生したエラーの対応や保守性、拡張性、処理効率の向上など品質向上のために必要な改修を月2回ほどリリースしています。
これらの保守業務も担当することで、既存機能の良くないコードを修正する際のソフトウェア品質の理解と既存機能の仕様理解を向上させることを目的として目標設定しました。日本の開発チームでは既存機能の軽微な改修も継続しており、この保守業務もODCで担当することで保守作業を通じて仕様を理解している範囲を広げていくことにしました。

日本語力を向上

日本語でのコミュニケーション向上を目標に設定しました。継続的に日本語を勉強することで、正しく・早く伝達できるようになり、全体的な効率向上につながります。外国語を習得するのは大変ですが、ODCのメンバは日本語理解へのモチベーションが高いので週間報告を日本語で提出するなど、徐々にでも進歩できることを設定しました。

まとめ

ODCメンバはアトラスのODC開始前から日本向けのプロジェクトの経験者が多くいますが、これまでの中国での開発プロジェクトでは、ソフトウェア品質を高く求められる経験はあまりなかったようです。
現在はアトラスのODCとして開発を担当することで、以前と異なり品質に対する要求が高くなっています。ODCでは日本の開発チームと文化や背景が異なりますが、より高い要求に答えられるように、課題や問題があれば継続的に改善していくことで、アトラスのConfitやSMOOSYの仕様理解や品質に関するノウハウが蓄積され、さらにスピードアップしていくことができます。
ODCの目的は開設当初から変わりなく、日本の開発チームがもう１つ大連にあるような状態にすることです。必要な拡張や頂いたご要望の対応など、安定的に、また、スピードアップして提供できるようにしていきます。
自社内で開発している開発チームにはODCは有効な手段になります。ODCに興味がある方は、大連帝邦科技発展有限公司に問合せしてみてください。