仕事をしていて感じたこと、トラブルプロジェクトでの経験を生かして、
ここに教訓を書いておく。
ライブラリ・ソース管理
大規模開発において、必ずトラブルが発生するライブラリ・ソース管理。
開発するに当たって相当の工数を取られてしまうのが現状だと思われる。
管理を簡素化するためにいくつか覚書。
(1)ディレクトリ構造を同一にする
開発を行うメンバーは、開発に関する全てのディレクトリ構造を同一にする。
(2)ソース管理はバージョン管理ソフトを使用する
ソース管理は、フォルダを分けて「old」「new」などやるのは時間と手間の無駄。
バージョン管理ソフトを導入する。
VSS(Visual Source Safe)やCVS、SVN(Subversion)など。
CVSとSVNはフリーなので、導入が楽かもしれない。
VSSはファイルベースの管理ソフトなので、サーバが不要。ネットワークフォルダとクライアントソフトがあればOK。
SVNはサーバソフトとクライアントソフトが必要で、通常SVNといわれているのはサーバソフトのこと。SVNクライアントでは、TortoiseSVN（トータスSVN）がWindowsシェル統合で使いやすい。
(3)プロジェクトファイルを共有する
EclipseやVisualStudioなど、統合開発環境（IDE）のプロジェクトは必ず共有し、全メンバーで同一のものを使用する。
IDEのプロジェクトファイルには、様々な設定（例えばjavaの開発ならクラスパスや参照ライブラリの設定）が入っているため、各メンバーでバラバラの設定を持ってしまうと、ソースを新しくすると動かなくなる、などの事態が発生する。当然プロジェクトファイルもバージョン管理する。
(4)ビルド・メイク環境を一つにする
プログラムのビルド・メイクは、必ず一つの環境とし、バージョン情報を付加する。
2009年9月26日土曜日
教訓 外国人SE
仕事をしていて感じたこと、トラブルプロジェクトでの経験を生かして、
ここに教訓を書いておく。
外国人SE
原価低減のため、外国人SEを投入することが多い。
まぁ結局高くつくことが多いわけだが、それは指示を与える日本人の問題。
外国人SEの方が技術レベルが高いことが多く、
使いようによってはうまくいくはず。（うまくいったのを見たことないが）
(1)資料を作らせるときは、枠を予め決めておく
外国人SEに資料を作らせる際、「こうこうこういう資料を作れ」という指示はNG。
こちらでほしい資料を作ってくれることなど絶対にない。（日本人でも無理だと思う）
そのため、例えばエクセルの一覧を作らせる場合は、予め枠、つまりカラム名を全て書き、
「そのカラムには何を書くのか」という説明をつけて渡す。
そして、「このエクセルの空白を埋めろ」という指示を出す。
また、文章での資料などがほしい場合、章立てを予め作っておく。
そして、あるならサンプルを渡す。サンプルがなければ、「この章にはこういうことを書く」という説明をつける。
(2)日本語での会話は信じない
日本に仕事をしている外国人SEの中には、流暢に日本語を話せる人もいる。
しかし、その人は日本人ではない。
日本の文化として、「阿吽の呼吸」や「暗黙の了解」などがあるが、
その人には通用しない。
外国人SEに限ったことではないが、こちらには当然のことが、外国人には当然でないことがほとんどである。
もしコミュニケーションをとるなら、メモやメールなど、文章・図にまとめさせるほうが良い。
会話よりまだましだ。
(3)慣習を教え込む
外国人SEの中には日本のシステム開発での慣習を理解している人もいる。
例えば、本番サーバに気軽にアクセスしないことや、勝手にテストモジュールを入れ替えたりしない、など。
だが、外国人SEの下にいる（まさに母国語しか話せない人たち）プログラマは守ってくれない。
やってしまう人がいる場合、すぐさま注意し、やってはいけないことを理解させる。
ここに教訓を書いておく。
外国人SE
原価低減のため、外国人SEを投入することが多い。
まぁ結局高くつくことが多いわけだが、それは指示を与える日本人の問題。
外国人SEの方が技術レベルが高いことが多く、
使いようによってはうまくいくはず。（うまくいったのを見たことないが）
(1)資料を作らせるときは、枠を予め決めておく
外国人SEに資料を作らせる際、「こうこうこういう資料を作れ」という指示はNG。
こちらでほしい資料を作ってくれることなど絶対にない。（日本人でも無理だと思う）
そのため、例えばエクセルの一覧を作らせる場合は、予め枠、つまりカラム名を全て書き、
「そのカラムには何を書くのか」という説明をつけて渡す。
そして、「このエクセルの空白を埋めろ」という指示を出す。
また、文章での資料などがほしい場合、章立てを予め作っておく。
そして、あるならサンプルを渡す。サンプルがなければ、「この章にはこういうことを書く」という説明をつける。
(2)日本語での会話は信じない
日本に仕事をしている外国人SEの中には、流暢に日本語を話せる人もいる。
しかし、その人は日本人ではない。
日本の文化として、「阿吽の呼吸」や「暗黙の了解」などがあるが、
その人には通用しない。
外国人SEに限ったことではないが、こちらには当然のことが、外国人には当然でないことがほとんどである。
もしコミュニケーションをとるなら、メモやメールなど、文章・図にまとめさせるほうが良い。
会話よりまだましだ。
(3)慣習を教え込む
外国人SEの中には日本のシステム開発での慣習を理解している人もいる。
例えば、本番サーバに気軽にアクセスしないことや、勝手にテストモジュールを入れ替えたりしない、など。
だが、外国人SEの下にいる（まさに母国語しか話せない人たち）プログラマは守ってくれない。
やってしまう人がいる場合、すぐさま注意し、やってはいけないことを理解させる。
教訓 開発環境を整える
仕事をしていて感じたこと、トラブルプロジェクトでの経験を生かして、
ここに教訓を書いておく。
開発環境を整える
トラブルプロジェクトの場合は特にだが、急にメンバーを増員することが多い。
急に人が増えたところで、開発環境についての資料がないと、無駄に終わることが多い。それだけならまだしも、開発当初からのメンバーが質問攻めに合うこと必至。
そんなときのために、環境資料を必ず先にまとめておく。
(1)テスト機の情報を一覧にまとめる。
論理サーバ名、ホスト名、IPアドレス、リモート接続プロトコル、OSログインユーザ、パスワード、注意点など。
(2)各テスト機の起動・停止など、システム操作の手順を処理フローと一覧にまとめる。
例）
(3)作成したアプリケーションが出力するログのパスを一覧にする。
(4)アプリケーションのテストにログインが必要な場合、ユーザ一覧を作成する。
その際、そのユーザを誰が（どのチームが）使用するかを明確にする。
ここに教訓を書いておく。
開発環境を整える
トラブルプロジェクトの場合は特にだが、急にメンバーを増員することが多い。
急に人が増えたところで、開発環境についての資料がないと、無駄に終わることが多い。それだけならまだしも、開発当初からのメンバーが質問攻めに合うこと必至。
そんなときのために、環境資料を必ず先にまとめておく。
(1)テスト機の情報を一覧にまとめる。
論理サーバ名、ホスト名、IPアドレス、リモート接続プロトコル、OSログインユーザ、パスワード、注意点など。
(2)各テスト機の起動・停止など、システム操作の手順を処理フローと一覧にまとめる。
例）
(3)作成したアプリケーションが出力するログのパスを一覧にする。
(4)アプリケーションのテストにログインが必要な場合、ユーザ一覧を作成する。
その際、そのユーザを誰が（どのチームが）使用するかを明確にする。
登録:
投稿 (Atom)