RMSタイタニック号とオリンピック級船舶のプロジェクトマネジメント
R.M.S. タイタニックとその姉妹船、R.M.S. オリンピックおよびH.M.H.S. ブリタニックの建造構想が形になり始めたのは1907年のことです。この3隻は合わせてホワイト・スター・ラインのオリンピック級 大型客船でした。（本文では明確さのために、この船級を指す際に「オリンピック（ス）」という表現を使用します。）人類の歴史においてR.M.S. タイタニックほど広く知られ、悪名高い船はほとんどありません。
R.M.S. タイタニックをプロジェクトマネジメントの観点から検討するにあたり、まずこのプロジェクトが生み出そうとしていた製品の種類を特定することが重要です。最終的な顧客が製品を所有する多くのプロジェクトとは異なり、タイタニックはエンドカスタマーにサービス、特にフェリーサービスを提供するために設計されました。これは「プロジェクト・タイタニック」を議論する上で興味深い課題をもたらします。なぜなら、プロジェクトマネジメントのほとんどの見方では、プロジェクトには明確な始まりと終わり、そして明確に定義されたステークホルダーがあるとされているからです。
R.M.S. タイタニックのようなプロジェクトでは、二つの視点から問題にアプローチできます。一方では、オリンピック級の3隻が構想・設計・建造され、ホワイト・スター・ラインに引き渡されるまでのプロジェクトがあります。もう一方では、タイタニックがその先輩にあたるR.M.S. オリンピックを超えてカスタマイズされ、初期生産が完了し、サウサンプトンとニューヨーク間をフェリー輸送する乗客にサービスとして提供されるまでのプロジェクトがあります。スコープを維持するため、タイタニック沈没後に2隻の姉妹船に施されたテスト、バグ修正、修理、スコープ変更、改良という、さらに大きなプロジェクトについては議論しません。R.M.S. オリンピックとH.M.H.S. ブリタニックはどちらも、就航期間中に多くの変更を受けました。ブリタニックの役割が大型客船から第一次世界大戦中の陛下の海軍主力病院船へと再スコープされたこと、そして乗組員がより安全になるまで乗船を拒否したことでオリンピックに二重船底と追加救命艇が装備されたことなどが含まれます。（「Olympic」）
ここでの私の目標は、タイタニックを構想からサービス提供、そして最終的なサービス失敗まで、一つのサービスとして検討することです。この観点からタイタニックは、現代のサービスとしてのソフトウェア（SaaS）プロジェクトと同様に扱うことができます。タイタニックのような船やSalesforce.comやSugarCRMのようなSaaS製品の性質上、製品の意図された耐用年数と、それを稼働し続けるために必要な継続的なアップグレードおよびメンテナンスを考慮する必要があります。タイタニックは航海中に大勢のパイロット、船員、シェフ、ポーター、スチュワードなどのスタッフを必要とし、艤装、修理が必要であり、もし沈没しなければR.M.S. オリンピックが受けたような新しい二重船底も必要だったでしょう。SaaSプロジェクトも同様に、データセンターとネットワークを維持するスタッフ、継続的なアップグレードとバグ修正、新機能などが必要です。タイタニックとSaaSプロジェクトのどちらの場合も、非常にコストのかかるサービス中断が起こる可能性があります。安定した信頼性の高い運用の維持は、これらのビジネスプランの成功における主要な要因です。
タイタニックを実現させるプロジェクトの分析をステークホルダーの検討から始めましょう。タイタニックの乗客と乗組員、会社としてのホワイト・スター・ライン、プロジェクトエンジニア、建設者としてのハーランド・アンド・ウォルフ、ハーランド・アンド・ウォルフの造船技師兼デザイナーであるアレクサンダー・カーライルとトーマス・アンドリュース、サービス提供の責任者であったエドワード・ジョン・スミス船長、そして最後にプロジェクトスポンサーの役割を担ったホワイト・スター・ラインの重役ジョセフ・ブルース・イズメイとその経営陣を容易に特定できます。この規模のプロジェクトには多くの重要な関係者がおり、その全員がプロジェクトに何らかの利害関係を持っています。ここではタイタニックプロジェクトの最も主要なステークホルダーとして、これらの主要人物に焦点を絞ります。
タイタニックプロジェクトは、ITプロジェクトマネジメントの用語で言えばウォーターフォールモデルに最も近いものでした。プロセスは、ホワイト・スター・ラインを代表するジョセフ・ブルース・イズメイと、造船パートナーであるハーランド・アンド・ウォルフを代表するジェームズ・ピリー卿との間で共同で生まれた高レベルの構想から始まりました。プロジェクトは両社共同で発案されました。タイタニックは両社に大きな名声と利益をもたらし、両社からの多大な投資を必要とするものでした。今日では当初のプロジェクト憲章が入手できないようですが、イズメイとピリー卿の会合を非公式のプロジェクト憲章およびプロジェクト開始として見ることができます。（Sadur）
オリンピック級船舶の技術設計は、イズメイとピリー卿が高レベルの計画を策定した後、ハーランド・アンド・ウォルフの主任造船技師アレクサンダー・カーライルが担いました。カーライルはプロジェクト開始から1910年に引退し、主任設計の役割をハーランド・アンド・ウォルフの専務取締役であるトーマス・アンドリュースに引き継ぐまで、プロジェクトのリードデザイナーを務めました（Brander 1998）。アンドリュースはタイタニックの設計の最終段階を担当することになります。1910年秋に進水したオリンピックは、おそらくカーライルの指揮のもとで設計が完成していたでしょう。タイタニックはオリンピックのインフラのほぼすべて（船体設計、羅針盤の配置、救命艇、ブリッジなど）を共有していたため、タイタニックの設計に対するアンドリュースの貢献は主に美観的なもの、あるいはソフトウェア開発の用語で言えば「インターフェース」に関連するものだったと安全に推測できます。（Thinkquest）
造船の建設的な性質、特にオリンピックスのような巨大な船では、設計プロセスには大規模な事前設計が伴い、設計者が実際に船を検査できるようになった後のフィードバックループは非常に限られています。ソフトウェアの用語では、これは「ビッグ・デザイン・アップフロント」（BDUF）と呼ばれます。要件変更が一般的なソフトウェアでは、これは非常に悪い慣行とされていますが、機械工学や構造工学では、これが唯一の合理的な解決策です。
オリンピックスの作業が進むにつれ、船の中核インフラ設計に関していくつかの決定が下されました。この方法論では、計画が承認された後にこのような性質の変更を許容するようには設計されていないため、これは特に危険です。船はすべての安全システムが相互依存する総合システムとして設計されており、高度に複雑です。ほとんどのソフトウェアとは異なり、安全性を確保するために必要な精度で船をラピッドプロトタイプすることは非常に困難です。安全システムへの重要な変更を正しく行うには、仕様の全面的な見直しが必要だったでしょう。しかし、コスト削減、スケジュール問題、高級設備のために変更が行われたため、変更に際して全体的な思考はほとんど行われませんでした。（Kozak-Holland）
オリンピックスの当初の設計と意図は、最新の安全技術を組み込むというものでした。初期設計が完了した後、ホワイト・スター・ラインから、特にJ.B. イズメイから、一等客室の豪華設備のために安全機能を取り除くよう建築家やエンジニアへの圧力がかけられました。最も有名な2つの変更は、もちろん、客室からの眺めを妨げないよう救命艇を撤去したことと、拡張されたグランドボールルーム施設のためにいくつかの隔壁を密閉しないよう変更し、水面上わずか3メートルまで高さを下げたことです。ITプロジェクトと同様に、中核システムの工学的決定は一般的にビジネスエグゼクティブの理解の及ぶ範囲を超えています。ビジネス側の決定が技術的決定に影響を与えることを許すのは危険です。なぜなら、通常の注意事項と思考プロセスが無視され、専門知識が見落とされるからです。この場合、これらは人命の保護と維持に関わる問題でした。ソフトウェアではこれほど重要な課題に直面することは稀ですが、主要システムの理解のないビジネスマネージャーがその設計に関与することは、結果がビジネス上の損失や運用コストの増大程度であっても、非常に有害になりえます。
オリンピックスの設計への後期変更から生じた最も劇的な問題の一つは、それぞれが単独では小さな変更であった各変更が、元の船の設計が検討されたような方法で全体として検討されることがなかったということです。救命艇が撤去されたとき、関係するエンジニアたちは、船は浮かぶ救命いかだとして設計されており、救命艇の目的は「最悪の場合」にタイタニックまたはオリンピックが動力を失ったとき、乗客を動かない大型客船から別の船へ運ぶことに過ぎないと考えていました。衝突があっても、水に浮かんだまま低くなるだけで、沈むことはないと予想されていたのです。ホワイト・スター・ラインの経営委員会の要請で、法定最低数のみが残るまで救命艇が撤去されました。エンジニアたちにとって、これは推奨されないものの許容できる安全上のトレードオフだったでしょう。追加の救命艇は法的要件ではなく、追加の救命艇の有用性は最小限であると信じられていたため、それらを残す必要性もありませんでした。最終的には、エンジニアの決定ではなく、造船会社への最終的な顧客であり、その決定が彼らの生計を支えていたホワイト・スター・ラインの決定でした。
単独では、救命艇を撤去する決定はおそらく軽微なものだったでしょう。しかしさらに、オリンピックスの中核構造設計を、すべての高い隔壁から4つを水面上わずか3メートルまで大幅に低くするという決定が下されたことで、船が浮かぶ救命いかだであるという概念が損なわれました。隔壁はマーケティング資料が信じさせようとしたほどには真に水密ではありませんでしたが、かなり高く、非常に水の「抵抗力」があり、たとえ非常に深刻な船体破損があっても、隔壁間を水が移動するのをほぼ防げたでしょう。船の初期設計には安全機能が豊富だったため、これは救命艇と同様に冗長な機能と見なされ、その撤去は船をより一般的な安全基準に下げるだけだったでしょう。個別に見れば変更のほとんどは無害でしたが、まとめて見ると変更は船の完全な再設計となり、完全な災害をもたらしました。資格のあるエンジニアが一度も戻って、すべての変更が施された状態で船の安全機能の完全な再評価を行うことはありませんでした。
ある意味でJ.B. イズメイはマイクロマネジャーと見なすことができます。彼は技術的な専門知識のために雇った人々の決定を信頼せず、直接的または間接的な圧力を通じて彼らの決定を覆しました。マイクロマネジメントには多くのマイナスの結果があります。明らかなのは、訓練を受けておらず資格のないマネージャーが、他の人々が資格のある専門家から来たと信じている決定に影響を与えることです。その他には、プロジェクトチームが生み出す価値の低下、従業員のロイヤルティとモラルの低下などがあります。
造船において、タイタニックのような船級が建造される状況では、3つの主要なプロジェクトフェーズを考慮する必要があります。プロトタイプであるオリンピックの設計と建造、タイタニックの設計改良と建造、そして最後にサービス提供と運用です。特にタイタニックの場合、主要な設計と構造的変更はオリンピックの完成前に行われていたことがわかります。トーマス・アンドリュースはオリンピックに乗船しましたが、これは主にタイタニックのための美観的な修正を行うためであり、その時点では構造的な作業を変更するには時期が遅すぎました。同じ理由で、アンドリュースはタイタニックに乗船し、間もなく進水するブリタニック（アンドリュースにはジガンティックとして知られていた）のために同様のことを行う予定でした。
プロジェクトスコープの観点からは、プロジェクトが当初策定した計画に密接に従ったことがわかります。建設は事前承認された計画に基づいて行われ、変更はほとんどありませんでした。スコープにおける最も劇的な変更は、オリンピックの修理を受け入れるためにプロジェクトを一時停止しなければならなかったタイタニックの建設中に発生しました。ハーランド・アンド・ウォルフとホワイト・スター・ラインの両者は、タイタニックが遅延するが、オリンピックの就航性が優先されることを理解していました。資本建設プロジェクトにおける主要な要因は、建設が始まると範囲変更がほぼ不可能なため、建設フェーズ間の契約レベルの合意が必要であることです。（「Olympic」）
生産プロトタイプに続いて、プロトタイプに基づくが同一ではない一連の生産実装がこのタイプのモデルに密接に従うソフトウェアプロジェクトを見つけることは困難です。私が提示できる最も近い例は、エンタープライズ・リソース・プランニング（ERP）パッケージのSAPです。このパッケージ、およびその種のものでは、顧客はそのプロトタイプ的なパフォーマンスと機能に基づいてパッケージを購入し、その後独自に、またはコンサルティング会社や元のベンダーを通じて、パッケージを自社のニーズに合わせて大幅に改修します。このようなアプローチの利点は一般的に、ソフトウェアパッケージの中核であるインフラが非常に安定していて十分にテストされており、幅広い状況で使用されているため、プロジェクト側とクライアント側の両方のテストが行われていることです。もちろん注意が必要で、顧客主導の改修には、中核インフラに行われたと期待される深いテストの恩恵がなく、より広いクライアントコミュニティからの「多くの目」の恩恵もありません。
オリンピック級船舶の場合、15フィートモデルで深刻なテストが行われ、完成時にオリンピックでテストが実施されました。オリンピックの複雑さでは、個々のシステムの単体テストに加えて、実世界のテストを行うことが重要です。オリンピックはこのタイプの船の標準的なテスト措置を受けました。しかし、タイタニックが建造されたとき、建造者と海運会社は、タイタニックが本質的にオリンピックのコピーであるため、オリンピックで行われたテストとオリンピックの継続的な成功した使用がタイタニックのテストとして十分であると決定し、タイタニックはほとんど追加のテストを受けませんでした。しかし、船乗りがすべての船、たとえコピーであっても、異なる振る舞いをすることを知っており、各船は固有であり、単独でテストされなければならないことを知っているため、これはベストプラクティスではありません。（Kozak-Holland）
タイタニックにはテストや性能試験のための時間がほとんど与えられませんでした。これは部分的には、オリンピックが深刻な事故に遭い、ベルファストの造船所で修理を受けなければならなかったために起こりました。オリンピックが修理中、タイタニックは待機しなければなりませんでした。その大きさの船は同時に1隻しか作業できなかったからです。これによりタイタニックにはビジネス上の時間的制約が生じました。タイタニックは定期的な大西洋横断路線の任務が予定されており、すぐに必要とされていたからです。そのため、おそらく行われていたであろういくつかの追加テストがスキップされ、タイタニックはベルファストからサウサンプトンへの航海を主要なテストとして出港しました。この航海の区間においても、少なくとも1人の有料乗客がいたため、適切なテストというよりも低容量の本物の航海に近いものでした。（Kozak-Holland）
ホワイト・スター・ラインとJ.B. イズメイは、できるだけ早く船を定期航路に就航させるために、並外れたプロジェクトリスクを喜んで受け入れていたように見えます。標準的な海事手続きを通じて、彼らは海上保険によって自本のリスクの多くを軽減しました。これにより多くの潜在的な未知のリスクから保護されていました。
19世紀後半、海運会社と政府の両方にとってリスクを低優先事項として見ることがますます一般的になっていました。1858年に建造されたS.S. グレート・イースタンは、その後54年間にわたって続いた、ますます安全性の低下する外洋航行船の設計よりも、実際の事例においてはるかに安全であったと考えられています。状況はタイタニック沈没を受けて企業と政府が状況を再評価するまで悪化し続けました。海運会社は、比較的事故のない航行が数十年続いたことで、安全に対するいい加減な態度が正当化されると見なしていたと主張されています。金融市場の圧力が、緩い安全基準を持つ会社を優遇し、業界全体を高価なリスク管理から遠ざけることを促しました。（Brander 1995）
テストと訓練の不足によるリスクをさらに軽減するという名目で、最も注目すべきはスミス船長など数人の乗組員がオリンピックからタイタニックの処女大西洋横断に移籍してきました。これはイズメイが、タイタニックを直接テストせずに航行することから生じる「未知の要素」を減らすために見える経験を求めており、少なくともプロトタイプ船からの最大の経験を持つことで補おうとしたと見なすことができます。しかし、これが決定の根本的な理由ではないかもしれず、スミス船長が選ばれたのは、タイタニックの出航を遅らせたオリンピックに緊急修理を必要とさせたH.M.S. ホークとの深刻な事故を起こしたばかりで、ホワイト・スター・ラインでの立場が疑わしくなっていたからかもしれません。スミス船長はおそらく不安を感じ、キャリアを心配し、会社からの圧力が彼の判断に反する方向に向かった場合に、船の最終的な責任者として行動する心境でも立場でもなかったでしょう。これはまさにホワイト・スター・ラインが求めていた運用上の抜け穴だったかもしれません。この状況は、サウサンプトンに停泊中にスミス船長がS.S. シティ・オブ・ニューヨークに近づきすぎたか速度が速すぎたことで、同船が係留を解いてタイタニックとほぼ衝突しそうになったことによっても悪化していたかもしれません。（Kozak-Holland）
慣習的な海事法のもとでは、船長は船の絶対的な指揮官であり、上位の軍事的または民間の役人が乗船していても、航行中は完全な管轄権を持っています。船長は道徳的および法的に、まず乗客と乗組員の生命と安全に対し、次に貨物と船に対して責任を負います。（Kuntz）
タイタニックが建造され、艤装され、航行可能な状態になると、段階の変化が訪れ、タイタニックプロジェクト全体のサービス提供フェーズに移行します。この段階では、従来のプロジェクトマネジメントの段階を超えています。ほとんどのシナリオでは、この時点でクライアントが完成した製品を受け取ったことになります。しかしタイタニックの場合、これがサービス提供フェーズとなります。
サービス提供のもとでホワイト・スター・ラインは、船で生じる新たな問題に対する責任を負いました。この時点で、従来の設計・建造・テストのシステムはもはや使用されず、代わりにサービス提供が標準運用手順（SOP）によって監督されることになりました。船の継続的な改修、修理、調整などは引き続き行われましたが、これらはサービス中断を必要としないレベルを意図したものであり、最終的な顧客である乗客の知識なしに行われる軽微なものでした。この段階で乗客が最も重要なステークホルダーとして登場します。なぜならこのシナリオでは、彼らは単に財務的なステークホルダーではなく、文字通り自分たちの命を船の信頼性と乗組員の運用にかけているからです。
アジャイル・プロジェクトマネジメントのコミュニティには、ステークホルダー内の役割を示すために使われる寓話があります。これらの役割は豚と鶏として知られています。この寓話は、一緒にレストランを開くことに興味を持っていた鶏と豚について語っています。豚が鶏に何を出すかを尋ねます。鶏は「もちろん、ベーコンと卵よ」と答えます。これに対して豚は「私は興味がないと思う。あなたは関与するが、私は完全にコミットすることになる」と答えます。（Schwaber 7）
豚と鶏のメタファーは通常、本物のお金やキャリアが危うくなっているステークホルダーと、利害関係があるが重要でない利害を持つステークホルダーの違いを表現するために使われます。鶏はプロジェクトが失敗することを好まないでしょうが、失敗は必ずしも彼らにとって壊滅的ではありません。タイタニックの場合、財務的なステークホルダーであるハーランド・アンド・ウォルフとホワイト・スター・ラインは、実質的に鶏でした。彼らには多くを失うものがありましたが、投資は保険で保護されており、後に見るように、政府でさえもオーストリアとドイツとの戦争が迫っているため、当時このような性質の会社を保護する意志がありました。ホワイト・スター・ラインもハーランド・アンド・ウォルフも「完全にコミット」していなかったのです。タイタニックの成功は彼らにとって非常に重要でしたが、タイタニックの乗客と乗組員こそが、文字通り命を賭けた真の豚でした。豚と鶏のメタファーがこれほど適切なことはめったにありません。
より高い質の継続的なサービスを確保するために、ハーランド・アンド・ウォルフからの保証グループが処女航海に同行しました。このチームには、主任設計者のトーマス・アンドリュースを含むハーランド・アンド・ウォルフの設計・建設スタッフの多くの重要なメンバーが含まれていました。この保証グループはハーランド・アンド・ウォルフのすべての主要プロジェクトで慣例となっていました。このスタッフは航海時間を利用して、テストとは異なる条件下での建設を評価し、顧客満足度を測定し、改善の機会を探しました。トーマス・アンドリュースはまさにこの目的でオリンピックに乗船しており、タイタニックを改良するための多くの小さな変更を行っていました。例えば、彼はこの航海の一部を、客室用のより安価なコートフックを設計することに費やしていました。（「Guarantee Group」）
保証グループはハーランド・アンド・ウォルフ内の多くの異なる技術的専門分野のスペシャリストで構成されていました。フィッター、電気技師、建具師、製図技師、設計チームなどの代表者が見られます。さまざまな専門分野を持つこのグループは、シニアと見習いを含む異なるレベルの経験を持ち、船を建造したプロジェクトチームの優れた代表的断面であったでしょう。職人技、設計、その他の最終的なコンポーネントの評価に細心の注意を払った彼らの乗船は、主に2つの観点から見ることができます。
一つ目の観点では、これをタイタニックプロジェクトに対して行われた「事後分析」と見なすことができます。このチームの役割は、プロジェクトの技術的な成功を評価し、改善の余地を探し、将来のプロジェクトがここで得られた経験から恩恵を受けられるよう「教訓」を生成することでした。大西洋横断旅行のコストと通常業務からの時間を考えると、これはハーランド・アンド・ウォルフによるプロジェクト知識への真剣な投資であり、非常に賞賛に値します。
別の観点では、この保証グループは建設のイテレーションに対するフィードバックを提供していると見なすことができます。オリンピックの建設が第1イテレーション、タイタニックが第2、ブリタニックが第3です。このアプローチでは、このような極端な資本建設プロジェクトにおいても顧客の意見を取り入れられるよう、可能な限り活用された一種のアジャイル フィードバックループが利用されていることがわかります。イテレーションは非常に長いですが、これは必要性から来るものです。このようにして、タイタニックを個別の成果物としての独自のプロジェクトとして、またオリンピックファミリーの船を通じて旅客サービスを提供するという継続的なプロジェクトの一部として見ることができます。
保証グループが乗船していたことで、技術チームが自分たちの製品の実世界への応用を直接体験する機会が生まれました。1912年には、技術専門家がこのレベルの贅沢な船に乗る機会はほとんどなかったでしょう。ハーランド・アンド・ウォルフがスタッフに自分たちの仕事が実際に機能しているところを目撃する機会を提供するスポンサーシップなしには、彼らは最終的な顧客へのサービス提供における自分たちの役割を理解できなかったかもしれません。
保証グループに見習いが含まれていたことで、直接的な一対一または小グループの非公式なトレーニングが行えました。見習いとシニア技術者は共に多くの日を過ごす機会があり、見習いたちはチームビルディングと知識伝達に適した環境でシニアから学ぶ大きな機会を得ました。多くの点で、この時間は今日多くの企業やプロジェクトグループで人気のあるオフキャンパスのチームビルディングセッションや合宿と似ていると見なすことができます。
タイタニックの分析で最大の驚きを見つけるのは、船上での標準運用手順がほぼ完全に欠如していたことです。いくつかのプロセスと手順は文書化されていましたが、多くはそうではありませんでした。標準化されていなかったプロセスの例には、無線室からブリッジへのメッセージの転送、船が沈没していることを乗客に警告すること、カラスの巣がブリッジに氷山を目撃したことを警告することなど、重要な通信プロセスが含まれていました。（Kozak-Holland）
標準運用手順は、あらゆるサービス提供の状況において絶対的に重要です。一部の企業では、これを会社の中核的な知的財産として非常に価値のあるものと見なすことさえあります。SOPなしでは、会社は本質的にスタッフの「チームとしての資質」以上の結束力を持ちません。新入社員の場合、それはわずかなものかもしれません。スタッフはベストプラクティス、慣例、非公式なスタッフ指導、または願わくはトレーニングのみに頼って仕事とプロセスを学ばなければなりません。しかし、書き留めておかなければ標準化されることはなく、トレーニングは必然的にトレーナーによって異なり、どの従業員もすべての可能なシナリオのすべての指示を記憶することはできません。
通常の状況では、標準運用手順の欠如はそれほど重要ではないかもしれません。スタッフは、SOPがなくても、特に訓練されていれば、ほとんどの業務機能を適切に遂行できます。必要ならば常にSOPを携帯する必要があるでしょう。SOPが極めて重要になるのは、「通常の運用手順」がもはや利用できない場合、または現代的な言い方では、運用がBAU（通常業務）条件ではなくなった場合です。タイタニックにとって、BAU条件は氷山事故の数時間前に壊れていました。
タイタニックの場合、標準運用手順を、通信についても議論せずに論じることは困難です。そのため、BAU条件下での通信から始め、SOPの欠如がいかに状況を急速に悪化させたかを見ていきます。
タイタニックは最初から通信設計の欠陥に悩まされていました。タイタニックに出入りするすべての通信を担当する無線室は、ホワイト・スター・ラインではなく、乗客のために最優先で、時間が許す限り船のためにのみ通信する報酬を受けていたマルコーニの人員によって運営されていました。無線通信士は過労で低く評価されており、雇用主であるマルコーニによってより優先度の高いとされる他の業務があったため、ブリッジへのメッセージ伝達をしないことが多かったのです。少なくとも8つの氷山警告がタイタニックの無線室に送られましたが、そのうちのいくつかしかブリッジに伝達されませんでした。（Kozak-Holland）
この場合、サービスレベルアグリーメント（SLA）を通じてサードパーティの請負業者を管理することの重要性を強調することが重要です。マルコーニ社が無線室に人員を配置することを許可したホワイト・スター・ラインは、船の安全および緊急通信が乗組員の個人的なメッセージに絶対的に優先することを要求する明確なSLAを持つべきでした。また、SLAに従わないことによるマルコーニへの追加利益や財務的恩恵を許可すべきでもありませんでした。外部請負業者としてのマルコーニは、相互利益のために設計された契約を持つべきでした。つまり、契約通りに実行されたとき、すべての当事者の相互利益のために正しく行動するよう設計されているべきでした。クライアントの利益に反して機能することへの財務的インセンティブをベンダーに与えるベンダー間の契約は非常に賢明ではありません。
マルコーニの通信士が関わった最も重要な単一の事件は、SSカリフォルニアから送られた最後の氷山警告でした。カリフォルニア号はタイタニックの非常に近くにいました。後にタイタニックから打ち上げられた緊急ロケット信号を目撃したのもこの船でした。カリフォルニア号はタイタニックに、流氷に閉じ込められ、危険な状況のために一切前進できないという警告を無線で送りました。マルコーニの通信士は「黙れ、黙れ、忙しい。ケープ・レースと通信中だ、お前が邪魔している」と答えました。これほど近くにそのような危険が迫っているにもかかわらず、無線室の優先事項がどこにあったかはこれ以上明確にはなりえません。無線室はカリフォルニア号との通信を維持しなかっただけでなく、この最後の外部警告をブリッジに伝えることも断りました。いら立ったカリフォルニア号の無線通信士はタイタニックへの警告の試みを諦め、無線機を切って就寝しました。マルコーニの通信士たちは警告を無視しただけでなく、唯一十分に近くにいて救助できた船が、タイタニックが沈み始めても対応しなかったという形で、外部チャンネルを疎遠にさせてしまいました。（Kuntz）
ブリッジから乗組員全体や乗客への通信には公式なプロセスがなく、手動で行われ、試みられた場合でも最善努力で行われるものでした。ブリッジは衝突が差し迫っていることを誰にも通知せず、非常に深刻な衝撃になったかもしれないものに対してだれも身構えていませんでした。船が沈み始めてから1時間以上経ってようやく、ブリッジは残りの船に沈没中であることを伝え始めました。乗客と乗組員の命に関わる重要な情報が彼らから隠され、おそらく事件を秘密にしたり、人命への明らかなリスクへの注目を最小限にしようとしていた一握りのブリッジ要員によってのみ保持されていました。ブリッジから一般の船に向けて通信するシステムもプロセスもなかったため、これは簡単なことでした。乗客にいかなる情報を伝えるためにも意図的な努力が必要だったからです。（Kozak-Holland）
乗組員間のコミュニケーションも大して良くはありませんでした。例えば、当直士官はブリッジの外に位置していましたが、重要な通信リンクはブリッジハウスの内側に位置していました。そのため、当直士官は他のブリッジ要員に迅速に通信したり、カラスの巣や他の関連する機能エリアと調整したりすることができませんでした。カラスの巣と当直は、双方向通信を許さず非常に遅い一方向のベルシステムで繋がっており、当直は緊急命令が出された際にブリッジ内の操舵手からのフィードバックを得る手段がありませんでした。命令は屋外から密閉されたブリッジに向かって叫ぶことで伝えられました。当直は、ブリッジ内の操舵手がそれらの命令を聞いて理解し、実行しているかどうか願うしかありませんでした。標準コンパスからの通信も同様に問題がありました。コンパスは、ブリッジの上方や近くに配置されるのではなく、船尾の遠くに設置されており、ブリッジは定期的にコンパスと連絡を取ることを余儀なくされていました。これにより多くの混乱と遅延が生じました。ブリッジを効果的または安全にするための設計上の考慮はほとんど行われておらず、この通信設計の欠如は、迅速かつ正確な通信が必要だったタイタニックにとって何の助けにもなりませんでした。（Brown）
ボストンのホワイト・スター・オフィスへの外部通信がようやく送られたとき、伝えられた情報は深刻な損傷はなく、事件は非常に軽微であるというものでした。しかし今日一般的なポイント・ツー・ポイント情報とは異なり、この情報は放送されており、他の船や中継局によって容易に傍受される可能性がありました。船と陸の通信は、内部通信を装いながら実際にはプレスへの情報発信に使われることがよくありました。そのため、正直で重要な情報を伝える代わりに、無線は状況に「スピン」をかけるように設計されたものに過ぎないプレスリリース同然のものを送るマーケティングツールとして使われました。（Kozak-Holland）
通信はあらゆるプロジェクトのあらゆる段階で重要です。タイタニックの場合、壊滅的な状況は通信が原因で生じた問題を浮き彫りにしていますが、これは単に最悪のシナリオにすぎません。プロジェクトは意思決定を行う際に、できるだけ最新かつ正確なデータを持つ必要があります。それなしには、利用可能な情報の一部しか使って決定が下されず、正しい情報が少なければ少ないほど、良い決定がなされる可能性は低くなります。
しかし、タイタニックに影響を与えた最大のプロジェクトマネジメント問題は、標準運用手順の欠如でした。SOPは、建設プロセスの後期段階で必須のプロジェクト成果物として作成されるべきでした。船を操作するためのSOPがない状態で航行可能と見なされるということは、真に信じがたいことです。最もアジャイルな開発手法でさえ、エンドユーザードキュメントの必要性を見落とすことはありません。
プロジェクトの設計と建設部分がタイタニックの乗組員にSOPを提供できなかったか、少なくとも合理的なSOP（ホワイト・スター・ラインのマニュアル自体にいくつかの一般的な標準手順はありました）を提供できなかったため、通信の処理、警告の追跡、警告の提供などのための明確に定義されたルールやプロセスがありませんでした。緊急手順はなく、乗組員は経験と一般的な船乗りの知識のみに頼って行動することを余儀なくされました。
緊急条件下での乗組員の行動を検討したとき、指揮系統の完全な崩壊を目撃する段階に至ります。伝統的なビジネスでは、ビジネスエグゼクティブは一般的に、法的な境界内にある限り、またしばしばそれを超えても、あらゆる企業行動の最終的な意思決定権を持つと認められています。平均的なビジネスでは、悪い運用上の決定は人命の喪失ではなく、収益の損失をもたらします。賢明なエグゼクティブは、運用上の決定を行うために雇用されたスペシャリストの決定を覆す必要がないことを理解するでしょう。あるいは取締役会がエグゼクティブに部下の意見を聞くよう要求するかもしれません。それでも、ビジネスサイドのエグゼクティブがプロジェクト運用に干渉するというアイデアは、ベストプラクティスに反しており、悪いアクションコースとして広く受け入れられています。
タイタニックの場合、スミス船長は海上で船を指揮し、船と乗船者に対して個人的な責任を負っていました。彼の上司であるJ.B. イズメイは、港に戻った際にスミスを指揮から外す能力を持っていたかもしれませんが、海上ではその権限はなく、英国の海事法のもとでは、彼は免許を持った船乗りではないため、ブリッジから命令を下す権利もありませんでした。（Kuntz）
氷山との衝突に至るまでの時間、J.B. イズメイはスミス船長に対し、無謀な速度—24ノット超または75回転—で船を駆るよう圧力をかけていました。「テスト」と見なされていたオリンピックはこの速度で大西洋を横断したことがなく、タイタニックは通常の条件下での大西洋横断を一度も行う時間さえなかったにもかかわらず、オリンピックでのテストの範囲をも超えて運用されていました。イズメイとスミスはタイタニックを既知のパフォーマンスパラメーターを超えて、そして重要なことに、乗組員の既知の運用パラメーターを超えて動かしました。この速度での船の運用にどのようなリスクが伴うかは単純に不明でした。氷山が散在していることが知られている海域を進みながら、安全でないと考えられるべき速度を維持することは極めて無謀でした。
パニック、混乱、不安などのためかはわかりませんが、タイタニックが氷山に衝突したとき、スミス船長は素人のJ.B. イズメイをブリッジに入らせ、代理船長として管理命令を下し始めることを許しました。スミス船長はイズメイを退去させる権利と義務がありました。イズメイは緊急通信、乗客への通知、そして最も重要なこととして、タイタニックを氷棚から前進させるという重大な運用上の決定を下しました。これが船の主要な亀裂の実際の原因であると考えられており、その後、船が沈没するという追加情報が得られた後も、船を低速で前進させ続け、船体を引き裂き続けました。（Kozak-Holland）
タイタニックから時間的に離れている今となっては、何がうまくいったかを評価し、何がうまくいかなかったかについてこれほど多くを知りながら、プロジェクトで何がうまくいったかを知ることは難しいかもしれません。タイタニックの沈没は私たちの心にとてもアイコニックなものであるため、それをマーケティングと組織的な災害以外のものとして見ることは、せいぜい困難です。
結局のところ、タイタニックプロジェクトは巨大でしたが、よく管理されていました。スコープは管理され、必要なときには変更が受け入れられました。十分に確立された契約インターフェースを持つ建設フェーズへの大規模な事前設計が使用され、この仕様の固定化が注意深く正確なスケジューリングを可能にしました。船が建造されたプロセスは標準的でよく知られていました。歴史的な建設データを使用して、ハーランド・アンド・ウォルフは建設に必要な時間を正確に予測できたため、ホワイト・スター・ラインは船の実際の就航よりずっと前にマーケティングと販売を開始できました。タイタニックはオリンピックのほぼ同一のコピーであったため、さらに驚きが少なかったのです。唯一の真の驚きは、タイタニックプロジェクトが約1ヶ月間一時停止する結果をもたらしたホワイト・スター・ラインからの優先順位の変更から生じました。
J.ブルース・イズメイの言葉を借りれば、「彼女（タイタニック）は契約によって建造されたのではありません。単純に委託によって建造されたのです。」これは、ハーランド・アンド・ウォルフに対し、タイタニックの引き渡しを確保するために自社のプロセスと監督を使用する例外的な権限が与えられたことを示しています。両社はベンダーと顧客の関係ではなく、パートナーとしてより機能しました。（Kuntz）
タイタニックのプロジェクトリスクは、主に外部保険会社に頼り、最終的には主に英国と米国の乗客を犠牲にして会社を責任訴訟から守るために英国政府に頼るという形で、うまく扱われませんでした。リスクは非常に低いと見なされ、そのため最初にオリンピックで、そして運用上の災害が最小限であったとき、さらにタイタニックで、より多くの不注意な決定が下されました。慎重なリスク評価は行われませんでした。熟練した船乗りは、対処が必要な多くのリスク領域を容易かつ迅速に定義できたでしょう。完全な標準運用手順の欠如などの問題は指摘され、現在のタイタニックチームからリソースを必要とせず、引き渡し日やホワイト・スター・ラインが当時主要な懸念事項として理解している変数のいずれにも影響を与えることなく、容易に対処できたでしょう。
プロジェクト上のコミュニケーションは、サービス提供が開始されるまで非常にうまく処理されていたようです。この時点で、設計上の欠陥、疑問のある決定、SOPの欠如が船上の通信ネットワークに影響を与え始めました。この通信は運用的なものと見なされ、プロジェクトベースではないかもしれませんが、論争は意味論的なものです。タイタニックの問題は総合的なものであり、適切な設計手法に従っていれば、リスク分析が見落とされることはなかったでしょう。リスク分析はSOPの作成を強制させたでしょうし、SOPは通信の問題を強調し、あるいはおそらく修正さえしていたでしょう。
その核心において、問題は品質についてのものでした。タイタニックは最高品質の大西洋横断旅行オプションとして提案・販売されました。品質はタイタニックについて語られたほぼすべての言葉の中で、直接的または間接的に喧伝されました。顧客インターフェースはできるだけクリーンで簡潔に保たれていました。顧客が目にする結果になるなら、費用を惜しまなかったのです。しかし、この「品質」が依拠すべきプロジェクトの基盤となる中核またはインフラ（Kozak-Hollandによれば非機能要件—ただし私はこの文脈でのその使用に同意しません）は無視され、タイタニックの真の品質とホワイト・スター・ラインの運用の品質は最終的に明らかになることとなりました。
参考文献・引用元：
Schwaber, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, 2003.
Kuntz, Tom. Titanic Disaster Hearings: The Official Transcripts of the 1912 Senate Investigation, The. New York: Pocket Books, 1998. Audio Edition via Audible.
Kozak-Holland, Mark. "IT Project Lessons from Titanic." Gantthead.com the Online Community for IT Project Managers. (2003): 22 February 2008
Brown, David G. "Titanic." Professional Mariner: The Journal of the Maritime Industry. (2005): 23 February 2008
Sadur, James E. Home page. "Jim's Titanic Website: Titanic History Timeline." (2005): 23 February 2008.
ThinkQuest Library. "Designing the Titanic." (Date Unknown): 25 February 2008.
Titanic-Titanic. "Olympic." (Date Unknown): 25 February 2008.
Titanic-Titanic. "Guarantee Group." (Date Unknown): 25 February 2008.
Brander, Roy. P. Eng. "The RMS Titanic and its Times: When Accountants Ruled the Waves - 69th Shock & Vibration Symposium, Elias Kline Memorial Lecture". (1998): 25 February 2008.
Brander, Roy. P. Eng. "The Titanic Disaster: An Enduring Example of Money Management vs. Risk Management." (1995): 25 February 2008.
追記：
Mark Kozak-Hollandは2003年のGantthead記事をタイタニックに関する本として再出版しています：
Kozak-Holland, Mark. Lessons from History: Titanic Lessons for IT Projects. Toronto: Multi-Media Publications, 2005.
さらに読む：
Kozak-Holland, Mark. Avoiding Project Disaster: Titanic Lessons for IT Executives. Toronto: Multi-Media Publications, 2006.
Kozak-Holland, Mark. On-line, On-time, On-budget: Titanic Lessons for the e-Business Executive. IBM Press, 2002.
1912年の米国上院および英国公式聴聞・調査議事録（Titanic Inquiry Projectより）。
広告
