1. はじめに

二十年にわたり、提案は同じであり、その計算は抗いがたく見えてきた。インドのエンジニアは西欧や米国のエンジニアのごく一部の費用で済み、その供給は豊富でよく訓練されており、英語が実務言語である。したがって、ソフトウェア業務をそこへ移す企業は、紙の上では、同じ業務をはるかに安く行えるはずである。まさにその論法によって膨大な業務が移され、インドはその上に世界水準のITサービス産業を築き上げた。それでもなお、結果は企業ごとに著しくばらついている。ある組織は何年にもわたりインドから優れたソフトウェアを得る一方で、別の組織は上昇する請求書、低下するデリバリー品質、そして節約した給与では到底埋め合わせられない欠陥の流れを受け取り、ついにはオフショアリングを失敗と宣言して業務を自国へ引き戻す。そしてしばしば、問題はインドにあったと結論づける。インドが問題だったのではない。

問題は、企業が間違ったものをオフショア化することにある。オフショアリングの背後にある直観は、ソフトウェア開発とは実行であり、人時で測ることができ、人時が最も安いところで買える量だ、というものである。その直観に基づき、企業は仕様と要員数を引き渡し、成果物を待つ。しかしソフトウェア開発は主として実行ではない。それは千もの小さな曖昧性の解消であり、そのそれぞれが、事業が実際に何を意味したのか、この部分が全体にどう収まるべきか、そしてここで「完了」とは本当に何を意味するのかを知ることを要する。そしてその知識は、キーボードのある場所ではなく、事業のある場所に宿る。企業が実行をオフショア化するとき、それと知らずにこれらの決定までオフショア化してしまう, それらをうまく下すのに必要なコンテキストから最も遠い人々へと。その結果が、局所的にはもっともらしく、全体としては誤った作業であり、それは遅れて、十二時間のギャップを越えて発見され、ゆっくりと修正される。労働裁定は実在する。だがそれが引き起こす調整と手戻りは、まずく扱われれば、より大きい。

本稿は、その過ちを犯さないことによって過ちを正すオペレーティングモデルについてのものであり、そのモデルには本稿を通じて用いる名がある。オンショア・コマンドセンターである。その発想は、素朴なオフショアリングが混同する二つのものを、意図的かつ構造的に分離することにある。一つは実行、すなわち構築であり、これは才能が豊富で手頃なところ、インドで、真に拡張できるし、拡張すべきである。もう一つがコマンドである。何をどの順序で作るかを決め、アーキテクチャと各部の間のインターフェースを所有し、事業が漠然と望むものを、会話なしに遠隔地で構築できるほど精密な仕様へと変え、戻ってきたものが正しいかを判断する。コマンドは小さく、上級で、高価であり、それが存在する目的たる意図を担う事業の隣、オンショアに留まる。本稿の主張は、オフショアリング・プログラムの成否は、このコマンド層が存在しそれが優れているか否かによってほぼ全面的に決まり、オフショアチームの素の能力, これは通常問題ない, によってはほとんど決まらない、というものである。そして企業が失敗するのは、まさにコマンドが、オフショアリングが排除するはずだった高価なオンショアの部分であるがゆえに、コマンドへの投資を怠るからである。

本稿の貢献は、ベンチマークではなく、論と小さなモデルである。第2節では、この主張をオフショアリングとグローバルソフトウェア工学の記録に照らして位置づける。第3節では、真の失敗, 単なる実行ではなく責任をオフショア化すること, を診断する。第4節では、コマンドセンターと、それが所有するものを述べる。第5節では、コンテキスト負荷と仕様の完全性を軸として、コマンドとデリバリーの間の線をどこに引くべきかのモデルを与える。第6節では時計を扱い、フォロー・ザ・サンがいかにして遅延ではなくてこになるかを示す。第7節では最適なコマンド比を導く。第8節では構成された事例をたどり、第9節から第12節ではその帰結を引き出し、反論に答え、限界を述べ、結論づける。全体を通じての問いはこうである。企業は何を、どれだけ自国に保持すれば、インドへ送った作業が正しく戻ってくるのか。

2. 背景

2.1 オフショアリングの実績

ITのアウトソーシングとオフショアリングは、情報システム分野で最も大きな実証研究の蓄積の一つを持ち、その評決は、オフショアリングが引き合わないというものではなく、その見返りがどう管理されるかに左右されるというものである。Lacity, Khan and Willcocks (2009) は、二十年にわたる研究を概観し、成功と失敗の事案の差を説明するのは賃金差だけではなく、顧客とサプライヤーのケイパビリティ、契約設計、関係管理であると見出した。Carmel and Tjia (2005) は、グローバルな労働力への調達についての実務者向けの記述を与え、距離が裁定利益を蝕む諸様態を目録化した。Sahay, Nicholson and Krishna (2003) は、インドの境界を越えたソフトウェア開発についての一冊規模の記述を与え、Oshri, Kotlarsky and Willcocks (2007) は、ある有力なインドのベンダーが分散した専門知識を軸にグローバルデリバリーモデルをどう組織したかをたどった。Rottman and Lacity (2006) は実証済みの実践を抽出し、成功した企業は、仕様化・調整・ガバナンスというオンショアの作業, まさに本稿がコマンドと呼ぶ作業, に多大に投資していたことを見出した。一貫した知見は、削減は総額であって正味ではないこと、そして両者の間に立ちはだかるのは、おおむね自国に留まる管理努力であるということである。

2.2 なぜ距離はコストを生むのか

第二の文献、グローバルに分散したソフトウェア開発についてのものが、その機構を説明する。Herbsleb and Mockus (2003) は、本稿にとって最も中心的な研究において、複数拠点の人員を要する作業項目が、比較可能な単一拠点の項目よりも完了に相当長くかかることを実証的に示し、その遅れを、拠点間の調整が要する通信のコストと遅延に帰した。Ramasubbu and Balan (2007) は、インドと米国の間に分散したプロジェクトを研究し、同じペナルティをプロジェクト性能のうちに直接測定した。Olson and Olson (2000) は、「distance matters（距離は重要である）」という表題のもとに一般的な結果を与えた。すなわち、同一拠点の作業は、分散した作業が失う迅速で豊かな非公式の通信から恩恵を受けるが、いかなるツールもそれを完全には回復しない。Kraut and Streeter (1995) はすでに、ソフトウェア開発のいかに多くがコーディングではなく調整であるかを示しており、Brooks (1975) ははるか以前に、分散した作業に人を加えるとそれが遅くなりうる理由を与えていた。通信経路は人よりも速く増えるのである。得られる教訓は、分散開発が機能しえないということではなく、一片の作業が越えねばならないあらゆる境界には代償があり、その代償は時間と欠陥で支払われるということである。

2.3 コンウェイの法則と境界のアーキテクチャ

本稿が依拠する最も深い発想はコンウェイ (1968) のものである。システムの構造は、それを構築する組織の通信構造を映すに至る、というものである。オフショアリングにとってのその系は的確でありながら十分に活用されていない。オフショアとオンショアが疎に通信する二つの集団であるなら、ソフトウェアは、両者の間の境界が真のアーキテクチャの継ぎ目, 定義されたインターフェースを持つモジュール, に沿って落ちるときに最も清潔になり、密に結合した一塊の作業がギャップを越えて分割される場所で最も厄介になる。Herbsleb and Grinter (1999) はこれを直接に裏づけ、分散開発は、アーキテクチャが各拠点が一部を所有し各部の間のインターフェースが明示的であるほどにモジュール化されているときに成功し、そうでないときに苦しむことを見出した。Parnas (1972) は、そうしたモジュールを可能にする設計規律、情報隠蔽を与えた。第4節で展開する実務上の帰結は、アーキテクチャを所有することがコマンドセンターの多くの仕事のうちの一つではなく、他のすべてを可能にする仕事だということである。なぜならそれが、高価な境界がどこに落ちるかを決めるからである。

3. 真の失敗：責任のオフショアリング

特徴的なオフショアリングの失敗は、遅いタイピングではない。それは、自信をもって完成され、静かに誤っている作業である。送り手の頭の中では完結しているが紙の上では曖昧な要求が引き渡される。送り手は、受け手が共有しないコンテキストを事業と共有しているからである。有能で意欲あるオフショアのエンジニアは、十二のタイムゾーンの彼方から使える唯一のやり方で曖昧性を解消する。すなわち、もっともらしく推測し、構築するのである。その推測は、受け入れがあれば受け入れの段階で、なければ本番で誤りと判明し、修正はギャップを二度越える, 一度は説明のため、一度は検証のため, その各横断で時計に一日を失う。これを実システム内のあらゆる曖昧性で乗じれば裁定利益は消える。誰かが無能なことをしたからではなく、コンテキストを要した決定が、それの存在しない場所で下されたからである。

本稿の言い方で言えば、起きたことは、企業が実行だけをオフショア化するつもりで責任をオフショア化してしまったということである。ソフトウェア一片についての責任とは、その曖昧性を正しく解消するために蓄積された権限である。すなわち、事業が何を意味したかを知り、その部分が全体にどう資するかを決め、「正しい」とは何かを言う権限である。その権限はコンテキストと切り離せず、コンテキストはローカルである。実行、すなわち曖昧性が解消された後の物の構築は、コンテキストに縛られず、よく移動する。過ちは、この二つを一つの小包として扱い、ともに出荷することである。修復策は、それらを分け、責任はそのコンテキストが宿るオンショアに保ち、オフショアへはその曖昧性がすでに仕様へと解消された実行だけを送ることである。以下のすべては、その分割をどう、どこで行うかの敷衍である。

4. コマンドセンター

オンショア・コマンドセンターは、移動してはならない責任の組織的な住処である。それは意図的に小さく、意図的に上級である。そのてこは成果物の量ではなく少数の決定の質から来るからであり、それはキーボードの隣ではなく事業の隣に座る。図 1 はこのモデルを描き、表 3 は分業を区分する。コマンドセンターは五つのものを所有し、このモデルの規律は、その五つすべてを所有し、それ以外は何も所有しようとしないことにある。

意図から仕様へ。 コマンドセンターの最初の生産物はソフトウェアではなく仕様である。事業が漠然と望むものを、身を乗り出して尋ねることのできない誰かが構築できるほど精密な記述へと翻訳したものである。これは、コンテキストのある場所で曖昧性を解消し、ない場所では何一つ解消せずに済むようにする作業であり、モデル全体のなかで単一で最も高いてこを持つ活動である。仕様に残されたあらゆる曖昧性は、のちにギャップを越える往復の全費用で支払われるからである。

アーキテクチャとインターフェース。 コンウェイの法則により、ソフトウェアは組織の通信の継ぎ目に沿って割れるため、コマンドセンターは、まさにその継ぎ目がどこに落ちるかを選ぶためにアーキテクチャを所有する。すなわち、各オフショアのポッドが、境界を越える依存の少ないまま構築できる一部を所有するよう、システムを明示的なインターフェースを持つモジュールへと分解する。境界をうまく引くことこそが、距離を、あらゆるやり取りに支払われる税から、少数のよく定義されたインターフェースでのみ支払われる税へと変えるものである。

優先順位付け。 何が最初に作られるかは、デリバリーの判断ではなく事業の判断であり、それは単一のバックログとその順序を保持するコマンドセンターに留まる。優先順位付けをオフショアチームへ、あるいは一度に複数のステークホルダーへ分散させることは、このモデルが封じ込めるために存在するまさにその調整を、ギャップを越えて再び持ち込むことである。

受け入れと品質ゲート。 コマンドセンターは「完了」とは何かを決め、戻ってきた作業をそれに照らして試験し、事業が信頼するゲートを保持する。これは仕様の対をなすものである。正しさを前もって定義しておき、戻ってきたときにそれを検証する。そしてそれはオンショアにあり事業に近いため、単なる機能ではなく適合性を判断できる。

単一の説明責任者。 最後に、コマンドセンターは説明責任が分割されない場所である。すなわち、提供されるものについて事業に対して責任を負う単一の所有者であり、ギャップの向こうを指差すことができない者である。境界を越えて分割された説明責任は、行方不明になった説明責任であり、それを一つのオンショアの点に戻すことが、モデルを統治可能にするものの多くを占める。

5. 線を引く

コマンドがオンショアに留まり実行がオフショアへ行くなら、すべては、両者の間の線がどこに、タスクごとに引かれるかにかかってくる。その選択を支配するモデルには二つの軸がある。第一は、タスクのコンテキスト負荷である。それを正しく解消するのにどれだけローカルで暗黙的で事業固有の知識を要するか。微妙な規制上の規則や長年の顧客への約束に触れる変更では高く、明確な契約を持つよく境界づけられたコンポーネントでは低い。第二は、コマンドセンターがそれに与えうる仕様の完全性である。その曖昧性が、会話なしに、紙の上で、どれだけ十分に事前に解消できるか。オフショアのポッドに到達する残存曖昧性, それに適用された仕様の完全性を差し引いたコンテキスト負荷, が小さいとき、タスクはオフショア化しても安全である。コンテキスト負荷を $\kappa$、仕様の完全性を $s$ とし、両者を共通の尺度上に置くと、残存は

であり、手戻りを予測するのは、作業の素の難しさではなく $\alpha$ である。このモデルには、表 1 に描かれた鋭い管理上の読みがある。低コンテキストのタスクは、その技術的難しさがどうであれ、清潔にオフショア化できる。高コンテキストのタスクはオフショアリングに不向きなのではない。それは仕様化されないままのオフショアリングに不向きなのであり、コマンドセンターの仕事は、$\alpha$ が送れるほど小さくなるまで $s$ を上げることである。コンテキスト負荷が真に還元不能なところ、知識をそもそも書き下せないところでは、タスクはオンショアに留まり、それを正直に認めることが規律の一部である。このモデルが名指す失敗様態は、低完全性の仕様とともに出荷された高コンテキストのタスクである。すなわち、最大の残存曖昧性が、最大の距離で、オフショアの当て推量によって解消されるのである。

6. 時計

西欧の事業とインドの間の時差、おおよそ九～十二時間は、実務者が純然たる負債として扱うことの最も多い特徴であり、コマンドセンターが最も清潔に資産へと変えうるものである。放っておけば、ギャップは遅延である。オフショアの一日の終わりに問われた質問は、オンショアの一日の終わりに答えられ、一つの明確化はその中身がどうであれ暦の上の一日を費やし、したがって明確化の連鎖は、一時間ぶんの実質的な内容を解消するのに一週間を費やす。これが、皆が懸命に働いていても、まずく運営されたオフショアリングが遅く感じられる機構である。クリティカルパスがギャップを通り、ギャップは一横断ごとに一日を加える。

うまく運営すれば、同じギャップは第二の勤務時間である。コマンドセンターが、曖昧性のすでに解消された作業を引き渡せば、オフショアのポッドはオンショアの夜を通して実行し、オンショアの朝までに結果を返す。そして事業が眠って過ごす一日は、待機の一日ではなく進捗の一日となる。この二つの結果の違いは、全面的に、引き渡されるものの残存曖昧性 $\alpha$ である。$\alpha \approx 0$ の引き渡しは往復を要さず時計は純然たる利得である。未解決の問いに満ちた引き渡しは、各問いが丸一日であるがゆえに、時計をあなたに敵対させる。それを粗く見て取るなら、第二の勤務時間からの実効的な速度向上は

であり、ここで $\eta$ は作業がどれだけ清潔に引き渡せるかを測り、$\alpha$ は式 (1) の残存曖昧性である。$\alpha\to 0$ につれて時計は真の追加勤務に近づき、$\alpha$ が上昇するにつれて利得は崩れ、やがて一問一日の税へと反転する。コマンドセンターは、$\alpha$ を小さくする仕様と完了の定義を所有することで時計を稼ぐ。だからこそフォロー・ザ・サンは、別個に買える日程上の小細工ではなく、良いコマンドの帰結なのである。

7. コマンド比

コマンドはどれだけあれば十分か。この問いには実在する答えがあり、それは、壁の向こうへ放り投げるオフショアリングを生む直観である「できる限り少なく」でも、オフショアリングが削ぎ落とすはずだったコストをオンショアに再び築く「できる限り多く」でもない。$r$ をコマンド比、すなわちオンショア・コマンドセンターのキャパシティを、それが統治するオフショアのデリバリー・キャパシティに対する割合として表したものとしよう。コマンドは単位あたり高いオンショアのレート $w_c$ を要し、デリバリーは単位あたり低いオフショアのレート $w_o$ を要する。コマンドの価値は、ポッドに到達する残存曖昧性を、したがって彼らがしなければならない手戻りを、低下させることにある。コマンドが多いほど、ギャップを越える前後でより多くの作業が仕様化され、レビューされ、ゲートを通され、したがって提供される作業に対する手戻り乗数が低くなる。その乗数の使い勝手のよい形は

であり、ここで $a$ は、コマンドが皆無なら被るであろう手戻りを尺度化し、作業の固有の曖昧性によって定まる。$b$ は、コマンドがどれだけ効果的に解消された曖昧性へと変換されるかを測る。完成した作業一単位を提供する総コスト、すなわちコマンドと手戻り済みのデリバリーの合計は、したがって

であり、上昇する項、すなわちコマンドのコストと、低下する項、すなわちコマンドが防ぐ手戻りの和であるから、単一の内部最小値を持つ。$C'(r)=0$ と置けば、コスト最小化のコマンド比

が得られ、これが本稿の中心的な定量的結果である。これは管理者が行動に移せる三つのことを述べる。コマンドの最適量は正である。$w_o a b > w_c$ であるかぎり、すなわちコマンドが少しでも効果的で曖昧性が少しでも実在するかぎり、$r^\ast > 0$ であり、したがって作業を壁の向こうへ放り投げること（$r = 0$）が最適であることは決してない。それは有限である。$r^\ast$ を超えたコマンドは、それが節約する手戻りよりも高くつくため、すべてをオンショアに保つこともまた最適ではない。そしてそれは正しい向きに動く。$r^\ast$ は作業の曖昧性（$a$）とともに、またコマンドがそれをどれだけよく解消するか（$b$）とともに上昇し、オンショアのコマンドがオフショアのデリバリーに比して高価になるにつれて（$w_c/w_o$）低下する。したがって曖昧で高コンテキストのポートフォリオはより厚いコマンド層を正当化し、単純でよく境界づけられたものはより薄い層を正当化する。図 2 は $C(r)$ と、最適の両側の二つの失敗領域を描く。

8. 構成された事例

この事例は観察されたものではなく構成されたものである。その数値は例示的で内部的に整合しており、結果を報告するためではなく、モデルの諸量がもっともらしい値をとる様を示すためのものである。ある西欧の集団は、そのバックオフィス・システムのアプリケーション開発を運営しており、三年前、その大半を人員増強方式でインドのベンダーへオフショア化した。オンショアの一握りのプロジェクトマネージャーを残し、要求を従来どおりの形で書き、成功を、移した要員数と節約した日額で測った。紙の上では、開発者のコストを半減していた。実際には、一つの機能の、要求から受け入れられた本番変更までの一気通貫のデリバリーは長くなり、本番への欠陥流出率は上昇し、オフショアチームの工数の大きく増えゆく割合が、曖昧な要求のもっともらしいが誤った読みに沿って構築された機能の手戻りに費やされていた。削減は総額であり、正味では薄く、減少していた。表 2 が導入前の列を与える。

その集団は、その後、取り組みをコマンドセンターを軸に再構築した。ベンダーを変えもせず、作業を自国へ戻しもしなかった。全要員数の数パーセントにあたる、薄く上級のオンショアの層を加え、それが第4節の五つのものを引き受けた。すなわち、要求を明示的な受け入れ基準を備えた仕様として書き直し、各オフショアのポッドが定義されたインターフェースの背後でモジュールを所有するようアーキテクチャを切り直し、単一の順序付けられたバックログを保持し、何かが本番に到達する前に受け入れゲートを実施した。オフショアチームとそのレートは変わらなかった。変わったのは、そこへ到達する残存曖昧性 $\alpha$ であった。仕様が、それを駆動していた当て推量を解消するにつれて手戻りは減り、ゲートがギャップのかつて隠していたものを捕らえるにつれて欠陥流出率は下がり、引き渡しが往復を要さなくなるにつれて時計は遅延から第二の勤務時間へと転じた。加えられたコマンドのコストは、それが取り除いた手戻りのごく一部であり、これが実務における式 (5) である。取り組みは $r^\ast$ のはるか左で運営されており、それへ向けて動くことは、オンショアのコストを上げつつも総コストを下げた。表 2 がその変化をたどる。

9. オペレーティングモデルにとって何が変わるか

コマンドセンターを採用することは、企業が何に長けていなければならないかを変え、その変化は、オフショアリングを動機づけた直観に逆らうがゆえに居心地が悪い。削減は依然として実在するが、それは、素朴な事業計画が排除すべき無駄として扱ったコマンド層に、オンショアで、上級のレートで支出することによってのみ捕捉される。表 3 が、このモデルの要求する分業を示す。希少な資源は、意図・アーキテクチャ・受け入れをうまく保持できる一握りの上級の人々となり、企業のオフショアリング・キャパシティは、何人のオフショアのエンジニアを雇えるかではなく、そうした人々を何人持つかによって限られる。指標もまた変わる。壁の向こうへ放り投げるオフショアリングをよく見せる数値である移した要員数と節約した日額は、機能リードタイム、欠陥流出、そして手戻りに費やされるオフショア工数の割合という、コマンドが仕事をしているか否かを明かす数値に取って代わられる。

もう一つの転換がある。上級性がどこに座るかという点においてである。壁の向こうへ放り投げるオフショアリングは、面白く上級の作業を残りとともにオフショアへ送り、下級の調整層を自国に残しがちである。コマンドセンターのモデルはそれを反転させ、上級性をコンテキストのあるオンショアに保ち、オフショアチームには、持ちえないコンテキストの供給を求めることなく、実行において卓越させる。これはしばしば、オフショアチームへの不信と誤読される。それは正反対である。それは、有能なオフショアチームが最良の仕事をできるようにする取り決めなのである。その距離では誰もうまく解消できない曖昧性の解消を求めず、その能力が当て推量ではなく構築に費やされるほど明確な仕様を与えることによって。

10. 反論と応答

コマンドセンターはオンショアのコストを足すだけで、削減を蝕む。 それはオンショアのコストを足し、正味の削減を上げる。それこそが式 (5) の眼目である。失敗している取り組みの大半は $r^\ast$ のはるか左に位置しており、そこではわずかに多いコマンドが、それが費やすよりもはるかに多くの手戻りを取り除く。コマンドセンターは削減への間接費ではない。それは、総額の削減を正味の削減へと変える機構である。真にすでに $r^\ast$ にある企業はコマンドを加えるべきではないが、そうした企業はほとんど存在しない。

何もかもそれほど精密に仕様化しなければならないなら、いっそオンショアで作ればよいのではないか。 仕様化と構築は、きわめて異なるコストと、きわめて異なる希少性を持つからである。仕様化は少量の、上級で、コンテキストに縛られた作業である。構築は大量の、いったん仕様化されればコンテキストに縛られない作業である。このモデルは、大量で立地の安価な量を、それが手頃なところへ送り、少量でコンテキストに縛られた量だけを自国に保つ。二つを再び一つに潰すことは、まさに実在する裁定利益を手放すことである。

現代のツールやビデオ通話が、距離を無関係にした。 それらは距離をより小さくしたのであって、無関係にしたのではなく、距離が依然として重要であるという証拠は堅牢である（Olson & Olson, 2000; Herbsleb & Mockus, 2003）。ツールは横断のコストを下げるが、往復に時計が加える一日を取り除きはせず、同一拠点のチームが気づかぬうちに曖昧性を解消するのに用いる非公式で環境的な通信を回復しもしない。コマンドセンターは、ツールが補完するが置き換えはしない構造的な答えである。

我々のオフショアのパートナーは非常に有能で、全体を所有できる。 問題は能力ではない。コンテキストである。きわめて有能なオフショアチームでも、事業が何を意味したかを知ることを解消に要する曖昧性は依然として解消できず、それを求めることは、その能力を、距離が解けなくする問題に対峙させることである。このモデルが責任をオンショアに保つのは、オフショアチームが弱いからではなく、責任がオンショアにあるコンテキストに縛られているからである。

11. 限界

これは意図的に単純なモデルを備えた実務者向けの論であり、その限界は明白であるべきである。第5節から第7節のモデルは例示的である。式 (1) の残存曖昧性の形、式 (3) の指数的な手戻り乗数、そして式 (5) の単一の最適比は、読みやすさのために選ばれた単純化であり、定数 $a$、$b$、$w_c$、$w_o$ はここでは測定されていない。企業は自身の手戻りとレートのデータからそれらを推定でき、定性的な形状、すなわち曖昧性と相対コストとともに動く内部最適は、正確な形が残らないところでも残ると我々は見込む。この論は、その曖昧性が努力によって仕様へと解消できる作業に限定される。真に研究のような作業、まだ誰も正しさが何かを知らない作業は、このモデルにうまく収まらず、おおむね同一拠点に留めるべきである。本稿がインドに依拠するのは、供給の深さと実践の規模がそこにあるからであるが、モデルのうちに特定の国に固有のものは何もない。それは、実在する距離と時計を越えたあらゆるオンショア–オフショアの分割に当てはまる。そしてこのモデルは、そもそも上級のコマンド層を配置できる企業を前提とする。それができない企業は、まずくオフショア化してその結果をインドへの評決と呼ぶのではなく、自分がまだうまくオフショア化できる状態にないことを正直であるべきである。

12. 結論

インドへのIT業務のオフショアリングは、間違ったものをオフショア化する企業を失望させる。すなわち、実行とともに責任まで送り出し、作業を、それを正しいものにするコンテキストと判断から切り離し、そのうえで、求めてやって来た削減を手戻りと時計が食い潰すのを眺めることになる。修復策は、作業を自国へ戻すことではなく、それを正しく分割することである。事業の隣に留まらねばならない薄く上級のコマンドをオンショアに保ち、何を作るかを決め、アーキテクチャとインターフェースを所有し、意図を仕様へと変え、受け入れを保持する一方で、実行は才能が豊富で手頃なインドで拡張する。線をどこに引くかは、タスクの残存曖昧性が答える問いであり、コマンドセンターの技は、その曖昧性がギャップを越えられるほど小さくなるまで仕様を上げることである。どれだけのコマンドを保つかは、実在する最適を持つ問いであり、それは正かつ有限で、作業の曖昧性とともに上昇し、コマンドが高価になるにつれて低下する。このように行えば、距離は税であることをやめ、十二時間の時計は第二の勤務時間となり、常に実在していた裁定利益がついに保たれる。構築をオフショア化せよ。そしてそれを自国から指揮せよ。二つのうちどちらがコンテキストに縛られ、どちらがそうでないかを覚えている企業は、インドへのオフショアリングを使いこなすことができる。忘れる企業は、問題は線の向こう端にあったのだと、誤って結論づけ続けるだろう。

付録 A. コマンドセンターの立ち上げ

以下の実践は、第4節の分割を実務において保持させるものである。いずれも新奇ではない。規律こそが価値である。

参考文献

Brooks, F. P. (1995). The mythical man-month: Essays on software engineering (Anniversary ed.). Addison-Wesley. ISBN 978-0-201-83595-3. (Original work published 1975.)

Carmel, E. (1999). Global software teams: Collaborating across borders and time zones. Prentice Hall. ISBN 978-0-13-924218-6.

Carmel, E., & Agarwal, R. (2001). Tactical approaches for alleviating distance in global software development. IEEE Software, 18(2), 22–29. https://doi.org/10.1109/52.914734

Carmel, E., & Tjia, P. (2005). Offshoring information technology: Sourcing and outsourcing to a global workforce. Cambridge University Press. ISBN 978-0-521-84355-4.

Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28–31.

Herbsleb, J. D., & Grinter, R. E. (1999). Splitting the organization and integrating the code: Conway’s law revisited. In Proceedings of the 21st International Conference on Software Engineering (ICSE) (pp. 85–95). ACM. https://doi.org/10.1145/302405.302455

Herbsleb, J. D., & Mockus, A. (2003). An empirical study of speed and communication in globally distributed software development. IEEE Transactions on Software Engineering, 29(6), 481–494. https://doi.org/10.1109/TSE.2003.1205177

Kraut, R. E., & Streeter, L. A. (1995). Coordination in software development. Communications of the ACM, 38(3), 69–81. https://doi.org/10.1145/203330.203345

Krishna, S., Sahay, S., & Walsham, G. (2004). Managing cross-cultural issues in global software outsourcing. Communications of the ACM, 47(4), 62–66. https://doi.org/10.1145/975817.975818

Lacity, M. C., Khan, S. A., & Willcocks, L. P. (2009). A review of the IT outsourcing literature: Insights for practice. Journal of Strategic Information Systems, 18(3), 130–146. https://doi.org/10.1016/j.jsis.2009.06.002

Malone, T. W., & Crowston, K. (1994). The interdisciplinary study of coordination. ACM Computing Surveys, 26(1), 87–119. https://doi.org/10.1145/174666.174668

Olson, G. M., & Olson, J. S. (2000). Distance matters. Human–Computer Interaction, 15(2–3), 139–178. https://doi.org/10.1207/S15327051HCI1523_4

Oshri, I., Kotlarsky, J., & Willcocks, L. P. (2007). Managing dispersed expertise in IT offshore outsourcing: Lessons from Tata Consultancy Services. MIS Quarterly Executive, 6(2), 53–65. https://aisel.aisnet.org/misqe/vol6/iss2/3/

Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053–1058. https://doi.org/10.1145/361598.361623

Ramasubbu, N., & Balan, R. K. (2007). Globally distributed software development project performance: An empirical analysis. In Proceedings of the 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE 2007) (pp. 125–134). ACM. https://doi.org/10.1145/1287624.1287643

Rottman, J. W., & Lacity, M. C. (2006). Proven practices for effectively offshoring IT work. MIT Sloan Management Review, 47(3), 56–63. https://sloanreview.mit.edu/article/proven-practices-for-effectively-offshoring-it-work/

Sahay, S., Nicholson, B., & Krishna, S. (2003). Global IT outsourcing: Software development across borders. Cambridge University Press. ISBN 978-0-521-81604-5.