IThaiのブログスマートフォン用の表示で見るIThaiのブログIT関連の話題やタイに関する様々なことを書いていきます。*プログラミングJavaPythonミドルウェア関連タイ小ネタ海外旅行記バンコクチェンマイ日常の徒然この広告は、90日以上更新していないブログに表示しています。某国と設計書とソースコードのやり取りをすることがありました。あれはどうすれば良かったかなぁと考えていました。反省点や改善点などを整理して書き残しておこうと思います。プロジェクトの概要です。・Webアプリケーション作成プロジェクト・システム規模としてサーバ10台くらい・人数は日本10人、某国15人くらいまた、基本的なオフショア工程は下記になります。日本で受入リリース間近は納期の遅れがでそうだったので、受入+共同開発みたいになりました。日本語で書かれた一語一語をきちんと訳しているようでした。設計書の連携だけでなく、ちょっとしたQ&AはRedmine上で行っていました。それでは、以下の事柄について振り返ってみようと思います。詳細設計書の連携についてオフショア先に連携するのは詳細設計書になりますが、これは日本語で書いていました。条件分岐の条件とか数値の大小とかは、なるべく英語や共通言語の数字など共通言語で書いていました。詳細設計書では、どこまで書くか、どのように書くかなど不明確な部分が多かったので、試しに書いてみてフィードバックでさらに改善していくという感じでした。具体的にしないといけないときは、プログラム言語で書いていきましたが、書くときに変数名とかをこちらで考えて書いていたのでコストがかかってしまったような気がします。・反省点また、詳細設計書を具体的に書いてしまいがちになり、基本設計での変更(条件の変更やテーブル名の変更)で設計書の変更が多発したときに、修正コストがかなりかかってしまいました。結論として、設計書作成時間の短縮、修正コスト、理解してもらうことをた第一にすると、入出力だけ丁寧に書き、後は一文のみにシンプルにしてあげるのが良かったんじゃないかなと思います。受入についてオフショア先が作成したコードのレビューとプログラムの動作検証を行うことになりますが、単体テストが完了している場合でも、動作しない場合もありました。単体テストが完了していることを念頭においていたので、動作確認から入っていましたが、動作しないコードが多かったことを踏まえば、ここは単体テストのレビューから入るべきだったと思います。単体テストが正しい仕様で行われていれば、少なくても動作しないということは防げただろうと思います。サイクルを早めつつ、コードレビューをしっかりやることですかね。共同開発について納期が近づいてきて、日本でも開発を行うことになりました。ここで問題になったのはソースの管理でした。品質・工程に対する考え方の違いなのか、マージに失敗しているケースや日本側で作成したソースコードに上書きしているケースがありました。コミット時間をずらすことで問題はあまり起こらなくなりました。当たり前のことかもしれませんが、Q&Aや受入などのレスポンスは早くしなければいけませんでした。レスポンスの遅れはスケジュールの遅れに直結しますからね。ここらへんのことは日本人同士でも同じですね。大変な思いもしましたが、それだけ学ぶべきことも多かったです。次にオフショア開発を行うときはこの教訓を生かしていけたらと思います。タイに移住したSEです。IT関連の話題やタイに関する様々なことを書いていきます。(14)月別アーカイブはてなブログをはじめよう!kkvさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。