リーン開発_第9章_パートナー - ゆるい感じのプログラムを書きたい。

相乗効果

パートナーシップを結ぶのは、コスト削減のためでも、リスク軽減のためでも、また能力向上のためでもない。パートナーシップが必要となる最大の理由は、相乗効果、人（や会社）が協力し合えば、個人が別々に取り組むよりも、優れた成果が出せる。

オープンソース

オープンソースプロジェクトには、たいていリーダがいる 全てのオープンソースオブジェクトに、「コミッター」がいる。

コミッターとは、新しいコードをコードベースにコミットする権限を持つ、信頼された中枢をなす人たち

オープンソースの新しいプロジェクトにボランティアを募集するには、プロジェクトリーダが魅力的なアイディアを持ち、優れた取り組みをする必要がある。

ボランティアを夢中にさせておくには、そのリーダー（後になれば、コミッターのコミュニティ）が出来の良さを認め、感謝し、拍手を送らなければならない。

「いい仕事」とは、非常に小さな単位でシステムにコミットさせる。

簡潔で読みやすいコードをもって、問題を解決すること
オープンソースの開発者たちは、ぐちゃぐちゃになったり、壊れたりしたソフトウェアを相手に、時間をムダにしたりはしない。
誰一人として、オープンソース開発者に指図を出していない。
規律のある有能な開発チームとっては、尊敬や信頼、喝采を超える報酬はない。

グローバルなネットワーク

グローバルなネットワークや、分散した作業グループは、ただ「チーム」という呼び名をつけるだけでチームになるわけではない。

チームメンバーが別々のタイムゾーンにいる場合十分にコミュニケーションを取り合えるような手段を用意するのは、非常に重要だが、それだけで作業グループをチームに変えることは到底出来ない。
地理的に離れていようと、同じ場所にいようと、人と人の間で相乗効果を生み出すのが難しいことには変わりはしない。
何よりもまず、チームメンバーが共通の目標の達成に関して、互いに約束し合っていなくてはならない。
互いに約束し合うだけでも難しいが、グローバルなチームの場合、チームメンバー間で効率的なコミュニケーションが取りにくいという、別次元の問題が加わる

グローバルな作業グループから、グローバルなチームへ

地理的に遠く離れた作業グループ同士で、約束を交わし合いコミュニュケーションを取りやすくするために役立つテクニック

頻繁な結合

地理的に隔たりがある小さなチームをいくつか集めて、作業グループを組み立てることは非常に多い。
チームの役割がシステムの機能上のアーキテクチャどおりに分割されているのであれば、チームは、ある程度独立して、別々のモジュールに取り組める。
これが非常に効率的な構造となることもあるが、入れ子にした同期を行って、作業の成果を頻繁に結合しなくてはならない。
定期的かつ頻繁に統合を行えば、結束が強まったり、知識の共有データベースが作り出せたりと、いろいろなメリットが生まれる。
コードベースを通じて、知識を早く伝達すれば、それだけコードがわかりやすくなり、プログラマテストで各ローカルチームの意図がうまく伝わるようになり、それを組み合わせた成果もより優れたものになる。

人の交換

ある国のひとつのチームが、システムの開発に必要な、すべての技術力を持っていることがよくある。
彼らへの「要求」は、遠く離れたタイムゾーンで書かれたドキュメントというかたちで、大きなバッチで送られてくる。
要求の到着から数週間後、あるいは数カ月後、アプリケーションが完成してみると、予想通り、それは顧客が本当に必要としたものではない。
顧客やアナリストと、実装チームとの間に（壁越しのコミュニケーションによる）大きな隔たりがある場合、うまくいくことはめったにない。
このような状況に対処するには、一方のチームのメンバー何人か、もう一方のチームに送って、長期的に一緒にやるのがいちばん。
メンバーを交代で行かせると、さらに望ましい。
顧客を理解するチームメンバーを何人か、開発チームにつかせてもいいし、開発メンバーを何人か、顧客を理解する人たちにつかせてもよい。
送り込むメンバーを交代させれば、はるかに効率が良くなる。

テストを交換する

チーム間で要求を引き渡す際、離れたチームに要求ではなく、実行可能なテストを送り合って対処した例がある。
顧客を理解する人たちは、コードが通るべき詳細なテストを作った。
彼らはそのテストを離れたチームに送り、コードがそのテストを通れば、機能していると見なせる。
それでも、毎週イテレーションを完了させて顧客の現場でテストを行わなければ、距離という障害は大きすぎて、離れたところにいるチームが流されてしまい、顧客が本当に欲しがっている物を提供できない。

窓口(Proxy)

ある分散チームでは、1人の人物を通してコミュニケーションを取り合って、非常に上手くいっていた。
遠隔地の職場から誰かを出し、中核となっているチームのメンバーになって、離れた職場に残っている人たちの窓口の役割を果たす
この人物が毎日、遠隔地のチームに電話をかけて、やるべきことを説明したり、質問に答えたり、完了した成果物を受け取ったりする
そして、明確に定義された大量の作業に対する責任を負い、遠隔地にいるチームにそれを送る。
このようにして、遠隔地のチームは中核のチームにいる一人の人物と、十分なコミュニケーションをとる
また、中核のチームは、遠隔地のチームを数人分の作業を受け持つ。

動き回るチームリーダー

あるケースでは、サブチームの置かれた場所ごとに大部屋（戦術ルーム）が１つあり、そこにはプロジェクトの進捗状況と懸念事項を示す大きな図が貼られていた。
進捗図は、世界中の4つの部屋それぞれで、まったく同じように保守されていた。
プログラムリーダーが、各地で進捗ミーティングを額て、部屋を一つずつまわる、他の場所のチームは、そのミーティングに電話で参加した。
すべてのチームが共通の目標に向けて、新たな約束を交わし合う。

差別の撤廃

他のメンバーは母国語を使っているのに、チームの一部が自分たちの母国語でない言語を使って作業をしなくてはならない場合。
あるいは、あるグループは下請けで、ほかのグループは元請けである場合。また、あるグループにほかのグループよりも明らかに高い報酬や地位が与えられている場合。
人は簡単に、あるグループがほかのグループよりも「よい」という認識を持つようになる。
そのような認識は、真のチームワークに欠かせない尊敬や信頼や約束を、あっという間に破壊してしまう。

アウトソーシング

アウトソーシングでは、仕事の一部を別の企業に肩代わりしてもらうことになる。 + その企業は、すぐそばにあることもあれば、地球の裏側にある場合もある。 + アウトソーシングによって、距離とはまた別の問題、つまり忠誠の問題がある。

作業者はトレードオフを行う際、自社の利益と相手企業の利益、そして、共同事業の利益に、どのように比重をかけるだろうか？ そして、自らの仕事の存続とのバランスを、どのようにとるだろうか？

アウトソーシングに関して、最善の合意が取れた時に、これらの問への答えが明確になる。
共同事業社の利益を重視すれば、それぞれの企業と、それぞれの社員に対して、最高の結果となる
その点を明確にしてなければ、作業者が水面下での利益の対立に苦しむことになる。

どうしたら、このような利益の対立を回避できるだろうか？

その答えは、アウトソースする作業の性質に応じて変わる。

インフラ、事務処理、開発の３つの場合について

インフラ

インフラは最もアウトソーシングしやすい
インフラに求められる機能は、市場でははっきり定義されており、ベンダーも多く、価格も手頃
技術的には自前でインフラを構築することも可能だが、それに費やす時間を考えれば、アウトソースするメリットのほうが大きい。
自分たちでするよりも、上手にコスト効率よくインフラを構築するサービスが提供されているなら、アウトソースを行う意味は十分にある。

事務処理

事務処理はアウトソーシングができる。

例をあげると

ある企業で、大量の書類を電子フォーマットに変換しなくてはならないのなら、
書類をスキャンして世界中どこにでも送って、変換すれば良い。

しかし、注意すべき点がひとつある、業界における真の競争優位が、データをいかに電子的に記録し、いかに書類なしですませるかという点にかかっているとしてらどうだろう？

変換をアウトソースしてコストを抑えている企業は、なぜ文章の変換が必要なのかを自問するどう気を失う。
事務処理をアウトソースする前に、まずバリューストリームをシンプルにし、事務処理の必要性をなくす努力をする。
事務処理のアウトソースの利益の対立は、ほとんどの場合、単価制での報酬が原因になる。
アウトソース先の企業が、事務処理に応じて支払いを受けるのであれば、１事務処理にかかる時間を短縮するはず。

しかし、事務処理数を減らすことに本当の価値がある場合、単価制の報酬によって、雇用者側への忠誠と、事務処理を生み出す企業への忠誠との間に対立が生まれる。

例をあげると

イギリスの航空会社BMIが富士通にコールセンターをアウトソース
富士通はBMIに扱う通話数を減らすことを示す
同時に、BMIの運用コスト削減できることを示した

そのため、富士通はBMIに、見込み通話数に応じた支払いへと変更させることが出来、BMIのコスト削減を手助けすることで利益を得た。

両者にとってよい（Win-Win）パートナーシップ
報酬に対するこの手法は、共同事業の利益を求めることが、全員にとって最大の利益になるということを明確に示した。

開発

インフラのアウトソースに十分に意味があるのと同様、一般的な（例えば、購買プロセス）のソフトウェア開発をアウトソースするのにも十分な意味がある。

しかし、この種のアウトソースでは、業界での平均しか手に入らない通常、同業他社も、同じくアウトソースを利用しているから。

実情が標準以下なのであれば、アウトソーシングによってすばやく業界平均まで上げることも可能
この種の開発のアウトソーシングは、基本的にはインフラのアウトソーシングと同じであり、忠誠にまつまわる問題が起きることは殆どない。
開発の一部をアウトソーシングしている企業もある
ユーザインタフェースを通じて行う手作業のテストは、労働集約型の作業なので、アウトソースされることが多い。
本当の優位を握るのは、ユーザーインターフェースを通してテストを行う必要が無いことを理解している企業。
そのような企業は、ユーザーインターフェースの下でテストを自動化し、テストを開発プロセスの出来るだけ早い段階に組み込むはず。
テストを最初に作り、それからテストを通るコードを書くようにする。

手作業でのテストをアウトソースする企業より顕著な競争優位を、ソフトウェア開発プロセス全体で得ることになる。

製品やソフトウェアの差別化要因になる開発コンポーネントをアウトソースするには、注意が必要

この種の開発を完全に社内でしか行わず、競争優位を生み出す根源としている企業もある
このような重要な開発部分を、効率的にアウトソース出来るようになった企業もある。
アメリカでは、トヨタの自動車部品の70パーセントは、サプライヤが開発・製造している。
従来社内で行われてきた先進的な開発は、他企業とのパートナーシップによって実現されるようになった。

重要な開発部分をアウトソースして顕著な優位を得ている企業はいくつかの基本原則にしたがって動いている。

１．重要な機能のアウトソースは、その企業が保有するよりも幅広い技術力に触れる必要があるため、あるいは、市場理解を広げる必要があるため、あるいはその両方の理由から行われている。
２．重要な機能のアウトソースによって、かならず両者にとってよいパートナーシップを生み出している。　パートナーシップから相乗効果が生まれることを期待するだけではなく、相乗効果を生むようにパートナーシップを管理する。　報酬制度や共同作業の規則、経営目標を通して、作業者に、共同作業への忠誠は自社への忠誠と同等であり、　共同事業の成功が自分たちへの最高の利益になるというサインを送る。
3．企業はパートナーに深い敬意を示し、その敬意がパートナーシップの詳細を定義するプロセスや手続きに組み込まれている。　うまくサプライヤを管理すれば、サプライチェーンが製造業界にもたらしたような、劇的な優位が開発業界にもたらせることになる。　まずは、アウトソーシンがコスト削減のため、リスク削減のため、あるいは能力向上のためだけではない、　ということを認識しなくてはならない。それは、相乗効果を生み出すためでもある。

契約

契約の目的は何だろう？これについては、２つの流派がある。

１．契約の目的は、一方の利己的な振る舞いからもう一方を守ることである。
2．契約の目的は、企業同士が相乗効果を海用に協業を進めるため、適切な報酬を規定することである。

このどちらかを取るかによって、規約に基づくリーンソフトウェア開発が非現実的となるか、最高の成果の達成を目的として協業を進めるための枠組みを全員に提供するかが決まる。

事例：T5合意

イギリスの空港会社は、ヒースロー空港の第5ターミナルを2002年に着手し、2008年春にオープンした。そのプロジェクトは巨大で、最初から、この規模のプロジェクトにつきものの、コスト超過や遅れは許容できないとわかっていた。

イギリス空港会社では、T5合意とよばれるものを考案した。従来の契約に代わる法的拘束力を持つ文章で、建設業界のルールを変える。

すべてのリスクを負うことに合意する
その代わり、請負業者は統合チームで作業し、リスクを軽減し、再現の成果を達成できるよう出来る限り努力することを合意する。
プロジェクトごとに建設会社がつき、合意された目標コストがあり、リスクへの対応や報奨金のための資金プールがある。
請負業者は、時間と資材に応じた支払いを受ける。
再作業が発生した場合にも責任のなすりつけあいになることはなく、再作業分の費用も支払われる。
サブプロジェクトが目標コストを超過した場合には、そのサブプロジェクトの資金プールから支払われる。
サブプロジェクトの終わりに、それに携わったチームが資金プールに残っている資金の3分の２を分ける。

T5合意は、イギリスの空港会社が確信を持って実施した、まったく型破りなやり方で、リスクと報奨金の両方の課題を解決するための契約形態である。

T5合意は、リスクを抑えつつ、資金の大幅な節約にも貢献している。

事例：PS2000契約

PS2000契約は、ノルウェーコンピュータ協会が、ノルウェー科学技術大学(NTNU)やノルウェーの主要企業、主要公的機関との協力によって開発したもの。大規模な公共ITプロジェクトに向けに開発されたPS2000契約は、調達や入札の段階でITシステムの詳細仕様を描くのは難しい場合が多い、という所見から生まれた。

１．ベストプラクティスから、多くの大規模ITプロジェクトでの不確実性やリスクには、柔軟な反復型の開発モデルのほうが適しているということがわかる。
２．そのためには、契約者と顧客の共通の理解を樹立するための仕組みが必要である。
３．システムを開発する団体は、顧客の目的やニーズを満たす最善の方法を見つけ出す能力を備えて無くてはならない。

PS2000契約でユニークなのは、提供内容の仕様ではなく、顧客と契約者がどのように協業を進めるかを定めている点である。契約の本体では、意思決定委員会を作り、意見に相違が生じた場合の調停役に指名し、契約主体の一般的な権利や義務について想定している。

プロジェクト目標や目標コストは、付属文章に書かれる。契約では、システムを反復的に目標が合意内容に置き換えていく、目標コストについての付属書類では、余剰資金や超過コストを契約主体がどのように分割するのかを想定しており、全体のコストの下限と上限が決められている。

事例：関係的契約

T5合意もPS2000契約も関係的契約

関係的契約は各当事者の利益と共同事業の利益を一致させることに重点を置いている。
その根底には「人は通常、自社の利益を追求するものである」という想定がある。
そこで、共同事業で最大の利益を上げることに集中すれば、各社の利益も最大になるという点を作業者に明確に示すために、関係的契約が作られている。