＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
協力会社とのつきあいかた
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-08-12 11:21
[quote]
ＮＡＯさんの書き込み (2005-08-10 17:14) より: （１）面談の時にその人の技術的なスキルをきちんと確認しない [/quote] 短い時間（せいぜい２時間程度）で確認出来ますか？ ＃派遣だと面接≒採用となってしまうみたいだし。 OUTPUTに対して対価を支払う契約にして この手のリスクを協力会社に転嫁するにしても 協力会社のコストはいわゆる人月いくらなので 協力会社が傾いてしまっても困るし・・・。 | ||||||||||||||||
|
投稿日時: 2005-08-12 11:24
私も気になったので、ちょっとGoogleで検索かけてみました。 http://dictionary.sanseido-publ.co.jp/topic/10minnw/007proper.html
ということで、私自身は、 「協力会社等の外部の方に開発を依頼し、プロジェクト管理を行う人」 ではないかと考えています。 正直、「だったらプロジェクト管理者でいいじゃないですか。」って 思ってしまいましたが。 | ||||||||||||||||
|
投稿日時: 2005-08-12 11:28
ある程度の確認はできます。 ただ、紙の上での知識ではなく、実践で確認することが大切です。 プログラマならば、何かを組ませるなどです。 ただ、技術的なスキルよりも人間性の方が大切だと思います。 外に出ちゃう方は特にです。 スキルがなくても何とかなってますし。(私のことです) _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||||||
|
投稿日時: 2005-08-12 12:00
ﾉｼ 同じ事言われます。（笑）
腕で黙らせるような○○にお会いしてみたいものですなぁ ※ちと脱線
同じくプロパーを○○に変更。
なので。面接をする方も、採用するにあたって 最低限必要なスキルが何であるか？ 短時間でそれを聞く為には何を聞かなければいけないのか？ って事を考えておく必要があるわけですね。 短時間で人間的かつ技術的に確認しなければ いけないわけですから、聞く方も頭の中に 「聞かなきゃいけない事リスト」を作っておかないと 
※ちとじゃんぬさんとかぶってる気もするが、そのままUP | ||||||||||||||||
|
投稿日時: 2005-08-12 12:44
「特有のもの」と言う意識の人もいるかもしれません。 差別化したいのでは？ そういう人は差別してあげたらよいのかと。 | ||||||||||||||||
|
投稿日時: 2005-08-16 09:35
完全に乗り遅れました 
まぁ、皆さんが書かれている内容は現実問題としては常に付きまとうことですね。 ●当たりはずれ（できる人になかなかめぐり合わない） ってこれは単なる確率論ですね。 つまり、外注（協力会社）に委託なり派遣依頼をする際に、自分の会社よりも 知名度や規模の大きい会社（同業の場合）に依頼することは稀なわけです。 そこには人数的にもすべての契約先に出せるだけの優秀な社員を保有している という状態でも無いでしょう。ましてやもし優秀な人が派遣されて来れば、 仕事を作ってでも引き止めておくということをされると、他の会社には回って 行きませんね。本当にタイミングというか運の問題でしょうね。 ●その他 他にも外注という呼び方や育成のことも出ていましたが、これ元請、下請け、 孫受けという伝統的な（？）契約から来る文化なんでしょうね。 最近大規模プロジェクトとかも少なくなって来てますが（あるところにはある のでしょうけど）プロジェクトでもＪＶ（ジョイントベンチャー）のような プロジェクトを経験すれば、まったく意識が変わるでしょう。 筆頭ＪＶ企業というものは存在しますが、プロパーや外注という考え方は存在 しません。（ＰＭのみその筆頭企業社員という場合もあります。） 右を見ても、左を見てもある意味「外注」ばかりで、しかもいろんな企業から 来ています。もちろんフリーの方も。 ま、そういう中ではプロパーがとか外注がというよりも、プロジェクトの中で の役割によって権限が与えられますから、普通の関係では一番立場の弱い企業 から来ている人がリーダーであれば、他の業務ではプロパーと呼ばれるような 立場の人が従うわけです。 まぁ、このあたりは意識の問題かもしれませんけどね。 [ メッセージ編集済み 編集者: Beatle 編集日時 2005-08-16 09:37 ] | ||||||||||||||||
|
投稿日時: 2005-08-17 20:41
乗り遅れました。
一応、[2005-08-16 09:35]のBeatleさんまで読みましたが、指摘がなかったので。
１． これって、「機能仕様定義からテストまでお願いします」とか、「機能仕様はこれなので、詳細仕様定義以降をお願いします」って、発注するんですか？ それで、『マトモにこちらの要求に応える』というのは、具体的にどの様な要求があり、どの様に発注し、どの様な納品があって、「マトモではない」と判断されているのでしょうか？ 私の経験では… 要求： ＊施設設備のライフサイクルを求めたい ＊ライフサイクルの計算式は４つある ＊４つのうち１つをユーザが選択する ＊結果を画面上にグリッド状に表示する に対して、発注時に、「グリッドのこれを、これの状態で色を変えてください」と、ちょっとややこしいかな？と思ったことを追加しました。 納品された“アプリケーション”は、ほぼ、こちらの要求通りの仕上がりでした。「マトモではない」と判断したのは、コードです。コードの看板に、「楽な仕事と聞いていたのに、こんなめんどくさいことさせやがって」と書かれていました。 誰宛に書いてあるのかわかりませんが、親請け、子請け、孫請けでチェックして消しておくべきものだったはず。 もうひとつ、エラーメッセージを「×アイコンと、文字列『＊＊＊』、“はい”“いいえ”のボタンを表示する」のように指定していたのですが、がんばって独自のフォームを作ってくれていました。MessageBox でよかったのに。。。これは作り直してもらいました。こっちでやってもよかったのですが、上のペナルティということで。 ２． 最近思うのですが、テスト工程って、コーディングの後ろにあるのでしょうか？ というのも、“テスト工程”の中で、工程が細分化できると思うのです。つまり、テストする項目／内容を決めることと、テストを実行することです。 言い直すと、「テストする項目／内容を決める」ことを、コーディングの後ろに行うのでしょうか？ テスト工程のうち、「テストする項目／内容を決める工程」を、仕様定義工程の後ろに持ってくれば、各仕様書に過不足がないかのチェックにもなるし、テスト項目としてユーザがするであろう操作を考えれば、仕様書に抜けているエラー時の振る舞いにも気づけると思うのです。 実際、先期に行ったプロジェクトでは、これによってコーディングとテスト項目の設計が並行して行え、日数を短縮することが出来ました。また、仕様設計者がテスト項目の設計を行うことで、コーダーの思いこみによる仕様とテスト項目の乖離をなくせ、乖離がないために本当は NG なのに OK になってしまうテストがなく、後戻り修正がなくなりました。 まぁ、これを考えるようになったのは、 要求定義 ： 総合テスト ↓ ↑ 機能設計 ： 結合テスト ↓ ↑ 詳細設計 ： 単体テスト ↓ ↑ →→→ という図を見てから、なのですが。 つまり、要求定義で要求されたことが満足しているのか確認するのが総合テスト。 機能設計で定義されたことが満足しているのか確認するのが結合テスト。 詳細設計で（略 であるなら、要求定義がすんだ時点で、総合テストでテストしなければならない項目は出そろっている、ということです。 まるさんの「テスト」というのが、どの部分を意図して用いたのかわかりませんが、私は単体テスト以降すべてを指していると取りました。 | ||||||||||||||||
|
投稿日時: 2005-08-17 21:06
横槍っす。失礼します。 要求定義がそこできちっと終わるような事があれば可能なんですけど、 詳細設計してたらそれは無理だって事もありますし。 テストしてたら仕様を変更して、無理矢理ねじ込んで来る事も・・・ <心の声> 総合テストの項目が要求定義が終わった時点で作れるプロジェクトに参加したいなぁ〜 </心の声> | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.