＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
海外企業に対する教育について
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-02-21 10:43
現在、フィリピンにあるグループSI企業の教育計画の策定を行っています。
やりたいことは下記になります。 ①見やすいプログラムソースを書けるようにする。 ②Javaのスキルアップを図る。 上記に対して下記を考えています。 ・教育実態の把握を行う。 ・SJCPやSWCDを元に模擬テストを行い、基礎知識を把握する。 ・現地責任者を交えて、目標を決める。 ・教育スケジュールの作成を行い、教育を実施。 私自身、ＯＪＴでベテラン社員に教育を行ったことはありますが、 今回のように若い方に教育を行ったことはありませんし、 ましてや海外での事なのでどうした物かと考えあぐねております。 中でも①に関しては、日本人に対してさえ一朝一夕ではいかないのに、 文化の違う外国の方にたいしてですから良い案が出てきません・・・。 教育は親会社の情報システム部が中心になって行いますが、 その先陣として私が現地で教育を行うことになります。 アドバイス等頂けると助かります。 | ||||||||||||||||
|
投稿日時: 2007-02-21 11:15
るぱんです。 It depends. としか言いようがないなぁ・・・。 思いつくままに書いてみましたが、いずれも定義があいまいなので 議論にならないと思います。 まぁ、そこを策定するのがSEなわけですが。（笑） もう少し要件を定義して下さいな。 フィリピンに投げる前提って事は、上級ＳＥ的な振る舞いが求められてますよ。 とかいいつつ、それではかわいそうなので、思いつくままに。 ①に関して ・コメントを先に打ち込んでそれ以上のことをやらせない ・全体の設計のほうが優先されるので、アーキテクチャーレベルでの設計は日本で行う →まぁ、海外に投げる位なら無理かもしれませんが・・・。 ・複雑なロジックは組ませない →複雑な箇所は必ず3人以上でレビューしながら。 ・英語圏ならば英語遵守（口頭使用のローカル言語命名を排除） ②に関して ・全体のプロセスの超見える化 ・必要なドキュメントと不必要なドキュメントの選別 ・求められたドキュメント以外は作成しない。 →作成した場合は、プランを練った側の責任で全員に何かをおごる ・スキルアップの概念が抽象的なので効果は出ないと思われる →定義をして、何をいつまでにどの精度で誰が何をやるまで計画する →ここがいい加減だと全体のコンセプトがつぶれる ・ネーミング規約の作成 ・ルールの完全遵守 ・見栄えが良くなることのメリットは具体的に作成しないと無理 →期待してはいけない ・目標を具体的だが、コンパクトに掲げる ・例えば、他人のソースを引継いで読みにくかったら、前任者の給料を分捕れる仕組み →どうしたら、それが防げるかは喧々諤々でインクリメンタルでまわす →毎日30分の反省時間とか設けるといいかもしれません ・プロジェクトに教育期間を設ける ・設計書を完璧にして、書いてあること意外はやらせない ・ウォーターフォール採用 ・アジャイルでペアプロやるのはいいんですが、その分ベテランの確保も必要 ・完全計画優先 →無駄と知りつつ途中で止めない工夫をし続ける ・単一価値観による信賞必罰（含：擬似洗脳） ただ海外の場合は、研修すると別の会社に去ってしまって無駄になりやすいんですよね そこを人件費で繋ぎ止めておけるかと言うのは別の問題 と言うわけで、教育は、効果を目的としない場合効果が高いと考えますが、 投資に対するメリットと言う意味では効果を測定しないといけません 途中のチャチャにメンバーを晒さないなど、 やることが膨大です。 単一プロジェクト成果を出せと言われてるのか、 今後３年ぐらいのスパンで効果を見るのか、 その辺の前提条件が足らないので、なんとも言えませんが。 それに、現地責任者まじえて・・・ねぇ？ 期待してるのはこちらなので、期待していることを細かく策定するのみです。 相手には命令に近い形がもっとも効果が高いと思います。 まだ見ぬ相手に過度に期待してません？ 戦う前から負けてるように思いました。 大丈夫かなぁ・・・？ 文化が違うのはわかりますが、プログラミング言語は同じです。 そこを混同すると、泥沼化して、なめられて終わりです。 上級ＳＥ的に振舞うのであれば、きっちり切り分けてください。 I order to you as ～. あなたがメンバーだった時にＰＬなりＰＭに対して持っていた不満に対する手当てと たいした言い訳（エクスキューズ）が出来れば良いと思うんですね。 ただ、こういうネタ振りだと、 荷が重いんじゃないかなぁ・・・？なんて思ってしまいました。 | ||||||||||||||||
|
投稿日時: 2007-02-21 11:40
そんな問題は当然認識しています。 グループの経営戦略としてこの会社をどう位置づけていくのか、 それをまず決める必要があると言ってありますよ。
別段そん明確な目標は一切無いです。 親会社の情報システム部自体、上から指令が降りてきただけで、 未だ何も具体策なんて無いんですから。 これは私がキャリアの為に嘆願してやっているだけです。 正直、成功・失敗は二の次です。 これ終わったら恐らく私は又次のステップのために、 転職しますから。 
だから、一緒にやっていくグループ会社なんだって・・・。 命令形でやられたら一緒にやっていこうと思いますか？
初めての経験ですからそう思われて当たり前でしょう。 私は自分のキャリアにならないことは一切やらない主義です。 るぱんさんは、チャレンジしない方ですか？ るぱんさん、会議でも批判ばかりしている口ですか？ それじゃあ物事進まないんですよ。 
| ||||||||||||||||
|
投稿日時: 2007-02-21 12:31
msoです。
確認したいことがあります。
何がききたいのでしょうか？ 個人的にはるぱんさんの意見はオフシェアをしている自分に 大変参考になっています。 ちなみにtakuさんと同じ悩みももっています。 takuさんの希望する回答は 「どうやったら現地の人に教育が出来るか？」 でしょうか？ であれば、まず現地の国の言葉を覚えるとかそういうことも 含まれますか？ | ||||||||||||||||
|
投稿日時: 2007-02-21 12:56
含まれません。 フィリピンのグループ企業は日本語教育を行っており、 社員は全員日本語を話します。 ちなみに、私もオフショアをやっています。 私が悩んでいるのは、 「どうやったらきれいな見やすいソースを書かせられるか？」です。 それ以外の悩みは無いですね。 というかそういう風に聞いていると思いますが・・・。
| ||||||||||||||||
|
投稿日時: 2007-02-21 13:25
見やすいプログラムソースってどういうものでしょうか？
言われた方からしたら、見やすく書いてくれと言われた場合、自分では今書いているソースが見やすいのかもしれません。 見やすいソースは、書式などのルールが明快で、それに則って書かれていることかなと。 個人によって、その書式などのルールが異なり、論争まで発展することもあるようですが。 それでも表記や書式などがころころ変わったのでは、見づらいのは比較的多くの人が納得してくれるかと。 日本側で書式などのルールがあるのであれば、それを渡してそのルールに則って書いて貰えば良いのではないでしょうか。 命令するのがダメならお願いの形で。 ただ、日本でもそうですけど、この辺は命令して絶対にしないとやってくれない人もでてきそうですけど。 | ||||||||||||||||
|
投稿日時: 2007-02-21 13:59
るぱんです。
ソースだけって言うなら、 ネーミング規約と、 コーディング規約と、 アーキテクチャ設計の指針の作成３点に留意。 （注：アーキテクチャ設計には、メニュー、パッケージ、テーブルの設計が含まれる） 以上なわけだが・・・。 えと、どこから話したらよいのやら。 良いソース＝良い設計書＝わかりやすい であって、「結果的に」きれいが達成できてるもんだと思います。 全てがシームレスに繋がるような環境があって初めて達成できるもんだと思います。 局所的に指針作って自分はやったんだから非は無いってスタンスを取りたいなら それでも良いんじゃない？ 最初に明示したルールを守らない＝懲罰対象 で、信賞必罰にするからみんなが従うんです。 親会社がどうこう～とか言ってて 主導権をとりきれないポジションだってのは理解しても、 やらないことへの言い訳にはなりません。 親会社乗り込んでコンセプトまで受けてないって思うからです。 どんなプロジェクトでもそうですが、 やりたいからにはその背景があって、 その背景からコンセプトをひねり出すもんです。 逆に言えば、親会社に乗り込んでコンセプト植えつけて 権限かっぱらって成果を出せたなら それは賞賛に値しますよ。 尊敬します。 そうでなければそういうポジションは政治争いの温床にしかならないので 僕は避けてます。 だから、要件があいまいで定義できてないから定義したほうが良いって書いたんです。 この辺は本当にめいんどくさいんですよ。 チャレンジについては、 チャレンジしたこともあるし、 現行のプロジェクトではそれなりに成果挙げてますよ。 （正確には強制的にチャレンジさせられたわけですが。） 20人近くのプロジェクトで新人が14～5人とかでまわしきりましたからね。 今現在、ほとんど一人でメンテさせてますし。 決め付けは止めてくださいね。 [編集] 補足： 僕の作った基準を横展開してもらって、 確認している範囲内で影響範囲は50人規模まで拡大してます。 [/編集]
こういうはらならやめてくれ。 またエンジニアなんて・・・って言われてしまう。 業界全体の評判を下げないでくれ。 何事もそうですが、大局着眼小局着手なんですよ。 コンセプトが足りねーから足りねーって言ったまでです。 大局を見定めてないのに小手先だけでかわそうとしてるから、 火を噴くだろうって言ってるんです。 上級ＳＥの役回りをしようとして、 出来ませんって宣言されてるように受け止めてしまっています。 ご批判は大歓迎です。 宜しくお願いします。 少なくとも、 「きれい」の基準 「読みやすい」の基準 が不足していて、 さらに言えば、 「きれい」の基準と、「読みやすい」の基準が矛盾した時にどちらを優先させるか って言うことが足りません。 [編集] 具体的に言えば、Ｃ言語のソースはおしなべて綺麗にみえていますが、 読みにくいです。 この矛盾をどのように位置づけますか？ [/編集] [ メッセージ編集済み 編集者: るぱん 編集日時 2007-02-21 14:18 ] | ||||||||||||||||
|
投稿日時: 2007-02-21 14:15
理解出来ないポジションであり、職場だから、
やることやったら転職するそれだけですよ。 基準は私が転職してくる前から全てあったのですよ。 それでも良くならない、ＰＤＣＡのＣをやろうとしてないから。 ＰＤＣＡを回しているつもりが、実際は回ってない職場です。 るぱんさんが言っている事が通用する職場なら苦労してません。 そんな程度のことは、某ＩＴコンサル企業が全てやっているのです。 御自分の経験で物事判断するのは止めましょう。 世の中には色々な会社があるのですよ。 批判しかできないなら余所行きましょう。 | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.