＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
外部発注の管理について
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-09-17 11:48
燃上れ「＠IT情報マネジメントコーナー」第６弾！
なんて勝手に思っていますが。 
「プロジェクトの納期遅延について」 「SEが業界に精通している」必要があるか？ を読み勉強させて頂きました。そんな中、私自身、仕事、職業、職務、技能と言う 副題について、４つカテゴリを強く関連付けて認識し、各々の話の際に暗黙的に視点の切替を している事に気が付きました。 そこで、この関連を明示的に一旦バラして考えると「プロジェクトの納期遅延について」の 根本的な問題の１フェーズとして 本来、外部発注と言うのは非常に高度な業務であるのに対し、その自覚が無い事、そして 外部発注の管理が非常に疎かであり体系化が遅れている要因に強い興味を持ちました。 また「プロジェクトの納期遅延について」スレッドでの議論は立場的な発言が主体となり 「外部発注」自体の性質、問題、対策についての話が不十分だと考え スレッドを立ち上げた次第です。 個人的な意見として 外部発注を行う際に必要とするスキルは、下記のステップを経て身に付く物だと考えており、 そしてこの考えが「外部発注が非常に高度な業務である」とする背景で、その先の考えとして 「意識的に外注管理をしないと外注が失敗するのは当然である」とまでも思っています。 # 比喩を用いてシステム処理に言い換えれば、 # 『プロセス内の処理連携は容易でも、別サーバ間の処理連携は困難である。』 # と受け取って頂ければ宜しいかと思います。 １．個人として仕事を依頼され果たす ２．個人として仕事を依頼し目的を達する ３．企業として仕事を依頼され果たす ４．企業として仕事を依頼し目的を達する また、 外部発注する際の一連の作業を「外注管理」と称するならば、 「外注管理」は「要件定義」と対を成す重要な話 だと思っています。 何がしか、ご意見のある方お待ちしております。 | ||||||||||||||||
|
投稿日時: 2004-09-17 15:34
ちっす。がるざます。
面白そうなので一枚噛んでみたいかと。…土日でえらい 膨れ上がりそうで怖いのですが(苦笑 個人的に、外注でまず確認すべきだと思っている事柄は ・外注する範囲 だと思われます。 つまり「丸投げ」なのか「部分発注」なのか。 非常に手厳しい言い方をすると、「プロジェクトの納期遅延について」で 見ている限りにおいて、発注側と受注側で、注文範囲の認識に 大きくずれが生じているのが一因に見えていました。 ちなみに私もこの辺でなんど煮え湯を飲まされたことか……… 発注側の良くあるミスは ・大体設計のフェーズとか必要範囲なんて良くわかんないしでも 適当に見繕って全部やってくれるんでしょ？ という甘えがあり、一方で受注側はといえば ・作ってくれって話はきてるけど金額安いし話の内容からしても これ以上突っ込んだ部分は要求してきていないしだからこんな もんでしょ っていうある種の逃げがあるわけで。 これじゃうまくいきませんわな(苦笑 っちゅわけで、個人的には、はにまる氏の「仕事を依頼」の中から ・仕事ってなに？ ・依頼ってどこからどこまでを示しているの？ の二つの明示化からなんじゃないかなぁ、って思ってたりします。 範囲決まってないと管理もできないし :-P | ||||||||||||||||
|
投稿日時: 2004-09-18 23:32
ソフト会社のSEとユーザー部門のSEを両方経験した者です。
月並みですが、ソフトウェアの場合、目に見えないものだけに、その契約範囲を明確にすることは非常に難しいと思います。 例えば、画面プログラムの動きを例にとっても、入力のチェックや操作性など、全てを盛り込んで、委託するということは、それ自体が詳細設計をするに等しいことだと思います。製造工程での発注ということであれば話は別ですが。 範囲を明確にしないことを「一括」と定義するのであれば、それは非常にリスキーなプロジェクトなので、発注者側にも資金的な余裕があり、受注者側もそのリスクを回避できるだけの人的資源と技術的な裏付けがあるからこそ可能ではないかと思います。 そうしたリスクの負えない業者は仕事を受けるべきではないと思いますし、発注者もそうした業者を避けるように選定に最大限の注意を図る必要があります。 しかしながら、多くの場合、金銭的な理由から、またマンパワー不足から、不透明な部分を見込んだ発注・受注を行わざるを得ないことが有り得ます。中堅・中小企業はとくにそうだと思います。受注者である中堅・中小ソフトウェアハウスも同じです。 立場的な考え方かもしれませんが、こうした現実を外して、外注管理を語っても教科書的なものにしかならない気がします。 そこには、駆け引き的な要素や、受注者側対発注者という強弱関係があることは否めなません。 外注される側から見ると、工数オーバーの場合は正当な理由をもって追加費用の請求に望むべきだと思います。出来ないものはできないと素直に言うことこそが開発者の良心なのかも知れません。範囲を規定するスキルもSEの重要なスキルなのでしょう。 外注する側から見れば、プログラマとしての委託ではなく、ＳＥとして委託したのであれば、それなりのスキルを求めます。自社のこと、業種のことまで知っていることは求めませんが、常識的なこと、ドキュメントの書き方や会議の進め方、などテクニカルSEではなく、アプリケーション系・マネジメント系のスキルを求めます。 ＳＥのスキルを見極めて要件を出すのも発注者に求められることかもしれません。 範囲を規定せずに、ずるずると強い立場である開発者の言うがままに要件を受けた場合、受けた側にとってみれば、やってあげたんだ、無理に受けたからこそこうなったという貸しの意識があり、その後の開発にしがらみを残します。 発注者にとってみれば、受けたからにはやって欲しいと思うのが当然だと思います。 そうならないようにすることこそ、発注する側、受注する側の管理ポイントがあるような気がしてなりません。 | ||||||||||||||||
|
投稿日時: 2004-09-22 09:40
どうも返答ありがとうございます。
只今、気合を入れて外注管理をお勉強中です。 
勉強中ですが思った事、偉そうにそのまま書き連ねます。 殆どの場合、依頼側は請負側に比べ優位な立場にあり、その内の大半の方は努力を怠ります。 今日では作業の専門化、伝達コストの低下を要因とした新たな作業分割と作業連携が 増えており、その状況変化と合わせて管理能力が無く仕事内容が理解出来ていない 依頼者の増加が少なからずとも作業上の問題にもなっていると感じています。 # これは縦連携が横連携に変わった事による新たな問題と言った方が通じるのでしょうか？ 実際、仕事の依頼を請負う際に作業目的を尋ねると回答出来る依頼者は少なく、 必須達成目標、希望達成目標、依頼作業の状態、開始条件など基本的な情報を抑えに 掛かるとほぼ壊滅状態で、この結果をもって依頼者が自分の仕事を理解していない為に、 依頼行為自体に対する基本情報を明示出来ないのだと想定しています。 # その一例が、部下に作業させる事が上司の仕事と勘違いされている方です。 この問題が単純作業で社内ならばよいのですが「高度なサービスを要求」する場合、 依頼者が依頼内容の仕事を理解していないと話になりません。 しかも、その状態に輪を掛けて「短納期」、「低予算」の条件を従えて且つ、 これでもか！と依頼先を「初めての外注先」とした場合、終わったも同然です。 そしてこの結果として下記状況を御見受けします。 ・必須達成目標がクリア出来ずに、希望達成目標だけが一時的にクリアされる ・必須達成目標がクリア出来ずに、受託側での契約上の責務が完了する また がるがるさん の仰る通り『仕事ってなに？』を規定すると次に 『依頼ってどこからどこまでを示しているの？』の問題が発生致しますが、 この際に感じるシステム業界固有の問題要因の一つとして、 専門家は、あくまでも技術や知識の専門家であって、サービスの専門家では無い事、 コンピュータシステムが魔法の杖では無い様に、ＩＴ業者が魔法使い集団では無い事を 未だに認識されていない方が多い事です。 下記文書はユーザ／ＩＴ業者の視点で考えた場合、請負側の問題となりますが、、、 上記の話にて認識されていない方が、まだお客様ならば誇大広告の影響だと 理解出来るのですが、コンピュータ・システムが魔法の杖では無いと判っていながら、 キャッチコピー・サービス名との矛盾にあえぐ現場技術者の存在が腑に落ちません。 無論、個人として志高く持ちキャッチコピー・サービス名を掲げる事は宜しいですが、 キャッチコピー・サービスを実現する為に必要とする 実務定義、必要なスキル定義、手順とそのレパートリを考慮せずに 魔法使いの如く依頼者へ振舞う事に懸念を感じます。 ### 追記-開始 ### 何時も通りに、読み直して駄目だこりゃ！と思ったので大幅に改定！ ### 追記-終了 ### [ メッセージ編集済み 編集者: はにまる 編集日時 2004-09-22 12:41 ] | ||||||||||||||||
|
投稿日時: 2004-09-22 16:04
どもでふ。がるでございます。
ですねぇ。はにまるさんが後半で書いてらっしゃることと重なって しまうのですが。どうしても「魔法使い」的ニュアンスを持ってる クライアントさんって多々いらっしゃいます(苦笑
んと、この辺はちょいと「異議あり！！」とか格好よく叫んでみようかなぁ、と(笑 受注の側として、当然のように「技術の専門家」は手持ちのカードに そろえている必要があるのですが。 同じくらいのウェイトで「顧客とシステムをつなぐ専門家」ってのも 重要なのではなかろうか、と思ったりします。 世間だと「せぇるすエンジニア」とか言われるカテゴリになるのでしょうか？ # ひらがなだと、腹の黒い人が出てきそうで怖い(笑 ユーザのニーズを嗅ぎ取り、ヒアリングし、逆提案もできるくらいの、 ある種コンサル的能力を持つ人間が、必要であるように思います。 …私の中では、それもまたSEのスキルの一つなのですが :-P ただ。 今回は基本的に「外部発注の管理について」ということで、どちらかと 言うと「発注側」の視点からのお話になると思うので、そっちに戻しますと。 発注側としては ・きちんと仕事の工程を(ある程度)学ぶ 事がベターであるといえ、学べないにしても最低限 ・きちんと質問をする ことがMustであるといえるのだろう、と思います。 ただまぁ結局のところ質問をするにしても最低限の知識とかが 必要なわけで。 …どうでしょう。いっそ「発注先の会社がきちんとした仕事を しているかを検査するエンジニア」というマーケットを作っていく ってのはどうでしょう？ :-P 専門化が必要な領域であれば、そういうのもありなのかなぁ、 とかつい考えちゃいます。 # まぁ実際、自分は技術顧問とかいって近いことをやってるので :-P 外注会社に任せるのなら「よい会社を見分ける眼力か得られる人脈/運」、 発注側が管理をするのなら「工程の把握と管理手法の習得」が 必須なんだろうなぁ、とか思ったりする今日この頃。 ある程度ガイドライン的な枠組みがあればいいのですが :-P | ||||||||||||||||
|
投稿日時: 2004-09-22 16:36
外部発注自体がアジャイルを阻害している。
アジャイルな視点で見ると「仕事の内容・範囲を明確にして工程に流す」という外部発注形式がそもそもうまくいくわけない、ということになる。外部発注せずに、人を派遣してもらって自社内に常駐してもらう開発スタイルが今後増えていくだろうと予想。 ちゃんとやれば外注管理がうまくいくはずだ！ というのが、そもそも理想論。 | ||||||||||||||||
|
投稿日時: 2004-09-22 17:32
どもです。がるです。
んっと…とりあえず確認などをはさみつつ。
まず「アジャイル」の定義ですが。 「すばやく作成する、または変化に対して柔軟に対応する、または 最低限のものを無駄なく作成する」というニュアンスで使われている、 と捕らえてよろしいでしょうか？ とりあえず上記を前提に話を進めていきたいと思います。
なぜでしょう？ 確かに「すばやく」というエレメントを基準にした場合、外注形式が 「速度を阻害する要因になる」というのは、それ自体はある程度正しい と思います。 が、それは「常駐に比べて遅延する」であり、「外注ではうまくいかない」 には結びつかないと思うのですが。 アジャイルな視点と「外注ではうまくいかない==失敗する」という構図 をもう少し噛み砕いて教えてもらいたいなぁ、と個人的には思って みたりします。
これも難しいですねぇ。 というか、正直なところ常駐を期待するところって多くの場合、 「より早く」とか「伝達ミスを防いでより正確に」という理由ではなく、 単純に「人が目の前にいるほうが仕事が進んでいるように感じる」 っていうところにウェイトを置いている人が多いように見受けられます。 いわゆる「残業しているほうがたくさん仕事をしている」と同じ 理屈ですね。 そのあたりを知っている人間としては、むしろ外注によって、 きちんと「仕事の質そのものを見る」会社のほうが今後業績が伸びて いくだろう(希望的観測込み :-P )と思っているので。 且つ、実際に今在宅形式ってのはまた重視されつつあるので。 (技術屋なら、ICとか <- 宣伝です :-P ) まだまだ状況がどちらに転ぶかは分からないと思ってます。
理想論を「現実にもってこれるかどうか」を議論するスレだと思っている のですが、そのあたりどうなんでしょう？ シニカルなモノの見方をして終わり、っていうのはとても格好よい と思うのですが。 私は泥にまみれてでも理想を追いかけていたいほうなので :-P 個人的には「どうやったら外注管理がうまくいくか」っていうのを、 もう少し追い求めて議論してみたいところですね。 | ||||||||||||||||
|
投稿日時: 2004-09-22 17:48
私は「システム開発プロセス」と「契約」に関する相性の悪さを考慮して 契約の仕方も考え直さんと駄目だなと考えています。（宿題状態です。） まず相性が悪いと思う背景についてですが、 ・契約は継続的な責務、最終的な責務を最初に明示化して取り交す物であり、 ・システム開発は作業の進行と共にやるべき事を一つ一つ明示化して行く物である と捉えています。 つまりは一括契約で契約を行う場合、作業開始時点でシステム開発プロセスにおける 最終工程の状態を保障も無く予測するか、形式目標に添った作業契約にするか またはどちらかが譲歩する決断をしなければならないと想定しています。 無論この譲歩は、ごんたさんが後述されている弊害として付きまとうでしょう。 そこで基本契約と個別契約という概念を用いて ・システム開発プロセスの全工程に関する基本契約 ・各作業工程に関する個別契約 に契約を分離し管理手法、システム開発プロセスと融合させてはどうかと考えています。 この２段階の契約方式は資金的事情にて行っている事は耳にした事はありますが 管理を目的とした手段としては耳にした事がありません。 無論それによって新たな弊害は発生致します。 それは特に管理期間の増加と管理費用の増加という形で謙虚に現れます。 しかし、それは逆に言えば管理費用と管理期間が明確になる事により 管理とシステム開発プロセスとの親和性は良いと考えています。 ただ、この最もたる弊害は経営者や上位管理者のリスク対策への無関心かもしれません。 # 勉強して別案が浮かんだら報告いたします。（気が向いたら）
当業界をかなり贔屓目に見ても、社会的な悪意がなくても意見の相違というのがある以上 是非、発注側の方には選定に最大限の注意を図って頂きたいと思います。
きっとどれだけ議論をして優秀な方がここで知識公開をしても教科書の域を超える事は 無いと考えます。 知識は知識、事例は事例と冷静な目を持ち、個人個人の経験と見識や思想を主体として 対応しなければならないと考えます。 仮に完璧な理論が存在したとしても実務に適用するのは並大抵の事ではないでしょうし。
ご意見へ勝手に追記させて頂くと しかしながら、画然たる知識差が存在する中では、金銭的力学が有効では無い事を 依頼者は認識して置かなければならない。 と考え、その発展的な意見として 無茶な注文を公開しているにも関わらず、寄ってくる業者はそれなりの 裏がある事位は認識しておく必要がある とも思っています。 ------------------------------------------------------------------ 念の為、私の発言背景を明示して置きますが、 私はユーザ／ＩＴ業界の視点からすると請負側の人間です。そして経験上から請負側としての 意見が強い事も否めません。 しかし、一方では開発企業に対し発注する側の人間でもあり、専門家を目指している私に とっては所属する組織がユーザ側になる事も将来十二分にありえる事を想定しております。 [ メッセージ編集済み 編集者: はにまる 編集日時 2004-09-22 17:54 ] | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.