企業を変革するプロジェクト：企業を滅ぼさずに

プロジェクトシャルドネ

シャルドネ-Corpは、高価な製品を製造する有名なメーカーです（曖昧にする必要があります！）。収益の多くは、製品を販売するのではなく、リースすることによって得られるようになっています。リースは難解で複雑なビジネスです。リース事業が成長するにつれて、コンピュータシステムも成長する必要がありました。そこで私たちは、いわゆるフロントエンドリースシステムを構築するために参加しました。フロントエンドリースシステムは、リース契約（またはリース用語でいうと、予約）に署名する前に発生するすべての処理を扱います。これには、リース人の信用調査、取引の提示、契約締結、および書類の作成が含まれます。開始前は、これらの業務のほとんどがせいぜい半自動化されていました。

私たちが構築したシステムは、多くの技術者の夢を満たすものでした。最新のエンタープライズJavaテクノロジー（EJB、JSP、その他の3文字略語）をすべて使用しています。もちろん、重要なのは、それがビジネスにもたらしたものにあります。シャルドネ-Corpは、複数の地域オフィスから単一のオフィスに移転することでオフィスを統合し、人員数を削減し（リース処理件数は維持）、プロセスの整合性を高め、サイクルタイムを改善しました。見積もりには以前は2日かかっていたものが、今では45分で行えるようになりました。また、インターネットのおかげで、シャルドネ-Corpのディーラーは見積もりを直接システムから取得できるようになり、シャルドネ-Corpの製品を顧客にとってより魅力的なものにするのに役立っています。

プロジェクトグルナッシュ

グルナッシュ-Corpは、大手小売業者の1つであり、アメリカの退屈なショッピングモールすべてに支店があるだけでなく、私がこれまで肘を突き合わせて歩いたことのあるすべての高級ショッピングストリートにも支店があります。他の小売業者と同様に、サプライチェーンを非常に重視しています。彼らは、裕福な顧客に、裕福ではないサプライヤーから商品を届けなければなりません。彼らは悪夢のような倉庫の複雑さを持っています。各SKUには、複数の異なる種類があります。

グルナッシュを単一のプロジェクトとして言及しますが、実際には、4年間かけて行われた、それぞれ6～9か月間のプロジェクトのシリーズです。各プロジェクトは、クリスマス前に配送センターに到着した大量のコンテナが数日間放置され、人々がコンテナ内の品目が小売業者が実際に期待していた品目とどのような関係にあるかを解明するといった特定の問題に取り組んでいました（答えは「思っているほどではない」です）。私たちは、共通のリレーショナルデータベース上に構築されたForteテクノロジーを使用してシステムを構築しました。

プロジェクトテンプラニーリョ

テンプラニーリョ-Corpは、シンプルな金属製の箱から複雑で広大な冷蔵庫まで、さまざまな貨物コンテナをレンタルしています。海運会社はコンテナをレンタルし、世界中を移動させてから、それを返却します。コンピューターがコンテナの位置や回収時期を追跡する上で重要な役割を果たします。テンプラニーリョ-Corpの既存システムはY2Kコンプライアントではなく、当初は新しいシステムがこれを修正する最も安価な方法と見なされていました。しかし、すぐにこれは企業変革システムへと発展しました。私たちはForteを使用してこれを開発しました（私たちは以前、Forteを使って多くの作業をしていました）。

プロジェクトサンテミリオン

サンテミリオンはシャルドネと非常によく似ています。少なくともプロジェクトはそうです。大企業、フロントエンドリースシステム、エンタープライズJava、多くの重複があります。（そして、いくつかの再利用もありました。）違いとしては、サンテミリオン-Corpの非常に高価な製品も技術的に非常に高度であるため、製造を開始した瞬間に陳腐化してしまうという事実があります。そのため、サンテミリオンの大きな利点の1つは、ERPシステムに接続することで在庫管理を改善できたことです。また、サンテミリオン-Corpのリース事業はシャルドネ-Corpよりも未成熟であったため、見積もりの整合性のあるアプローチをまとめることでより大きなメリットがありました。営業担当者がスプレッドシートで取引をまとめることは柔軟性がありましたが、会計と利益管理に混乱を引き起こしました。

頻繁にデリバリーする

これらの種類のプロジェクトにおける成功と失敗の共通の差として私が気づいたことが1つあるとすれば、それは頻繁なデリバリーにあります。私は、現在取り組んでいる主要な企業変革イニシアチブについて話す人によく出会います。彼らは、5年間のプログラムの2年間を経て、物事がいかにうまくいっているかについて、大きな熱意を持って話します。統計的に有効なサンプルではありませんが、5年間のプログラムの5年目にこのレベルの熱意を持った人にまだ出会っていないということは重要だと思います。私が通常得られるのは、「…だったら成功していたのに…」というものです。

私たちの成功したプロジェクトの共通のテーマは、プロジェクトの期間を通じて稼働するソフトウェアを頻繁にデリバリーすることです。実際、最近のプロジェクトほど、より頻繁にデリバリーしようと試みています。一連のプロジェクトの中で最も古いプロジェクトであるグルナッシュは、6～9か月ごとにデリバリーを行いました。これはサプライチェーン全体を刷新するという壮大な計画でしたが、各プロジェクトは独立したプロジェクトであり、それ自体が実行可能なビジネス提案となるように設計されていました。非公式な話では、通常これらのプロジェクトは1年以内に投資額の2倍の収益を上げるだろうということです。シャルドネはより最近の例であり、サイクルを短縮する傾向を強調しています。ここでは、2～3か月ごとに新しいソフトウェアを展開しています。

なぜこれが重要なのでしょうか？まず、信頼性を構築するためです。企業は、イニシアチブに多額の資金を投入している間、辛抱強いことで有名ではありません。会社の刷新のための5カ年計画を後援する準備ができている人を手に入れたとしても、その人は5年間続くとは限りません。多くの場合、大きな新しいイニシアチブは、約3年目頃に彼らの首の周りにある重荷になります。その段階で実現可能性を示せなければ、プロジェクトは犠牲にされるか、スポンサーとプロジェクトは行き場を失います。

一方、デリバリーは信頼性を構築し、特にメリットが見られる場合（コスト削減、タイムリー性の向上など）は、期待されるメリットよりもはるかに重要です。人々はシステムが実際に動作しているのを見ることで、それがもたらす価値と、それが強制する変化を見ることができます。この可視性は、ソフトウェア開発者の信頼性も高めます。自信に満ちたプロジェクトのブリーフィングを聞いているにもかかわらず、プロジェクトが軌道に乗っているかどうか実際に分からないとビジネス関係者が嘆くほど悪いことはありません。展開されたソフトウェアは明確であり、進捗状況をはっきりと示します。期待どおりに進捗していない場合は、それほど良いとは言えません。しかし、そのような場合でも、それは価値があると私は思います。開発が遅くなると、それを隠せるのは限られています。最終的に現実はあなたを追い越すという厄介な習慣を持っています。しかし、人々が着実な進捗を見れば、遅延により寛大になるか、プロジェクトを早期にキャンセルします。どちらの場合も、長く続く失敗よりもビジネスにとって優れています。

頻繁なデリバリーにより、開発から学ぶこともできます。多くの人にとって奇妙な表現に聞こえるかもしれませんが、私たちの経験では、この種のプロジェクトを行う際には、誰も全体像を本当に理解していません。前にその道を進んでいればどこに向かっているかは分かりますが、企業変革とは全く新しい世界に入ることを意味します。クライアントと請負業者にとって予測不可能な世界です。サンテミリオンでは、フロントエンドリースソフトウェアの経験を活用することができました（4番目のシステムでした）が、実際には、その規模では、すべてのビジネスには独自のひねりが十分にあるため、新しい旅となります。

これは、企業変革プロジェクトでは非常に新しいテクノロジーが関与することが多いため（後述します）、さらに複雑になります。この場合、初期のデリバリーは、技術者がテクノロジーについて学び、ハイリスク領域の一部を調査することを中心とする必要があります。これらの発見は良いものも悪いものもあるため、計画を適切に調整できるように、早期に行う必要があります。

新たな道を切り開くという方法の他に、一つ代替案があります。それは、他社が既に経験済みの道を歩むまで、企業変革プロジェクトを試みないことです。そうすれば、もちろん、どこへ向かうべきかある程度の見当がつきます。しかし、この方法の問題点は、パーティーにたどり着いた時には、食べ物が全てなくなっているということです。

これまで説明してきたように、デリバリーとはビジネスへのデリバリー、つまりソフトウェアの本番環境への投入を意味していました。しかし、この概念はさらに拡張できます。数ヶ月に及ぶ展開サイクル内においても、ソフトウェア開発者はより短いサイクル（数週間程度）でソフトウェアを構築できます。これらのサイクル全てを本番環境に投入したいわけではないかもしれませんが、これらの開発イテレーションから多くの学びと追跡のメリットを得ることができます。ここ1年ほど、いくつかのプロジェクトでこのような短い内部サイクルを使用しており、成功事例が増えるにつれて、ますますこの手法を採用しています。

予期せぬ事態を想定する

先に触れたように、企業変革は予測可能な作業ではありません。新しいビジネスプロセスは、せいぜい漠然としか、あるいは全く知られていない領域へと進むことを意味します。このようなプロジェクトには、予期せぬ事態がつきものです。中には悪いサプライズもあれば、良いサプライズもあります。それらに反応することでのみ、悪いサプライズの損害を回避し、良いサプライズの利益を最大化できます。

Tempranilloプロジェクトは、両方の例を示しています。悪い面では、修理に関する不快な発見がありました。プロジェクトの初期計画では、コンテナの修理追跡はプロジェクトのごく一部になると予想されていました。しかし、プロジェクトが進むにつれて、作業の約半分が修理の追跡であることが判明しました。これにより、プロジェクトのコストとタイムラインが大幅に増加しました。この状況では、問題に正面から取り組み、計画を練り直すしかありませんでした。

私は別のやり方を見てきました。それは、計画からの逸脱の失敗を避けるために、元の計画が依然として有効であるかのように進めようとするものです。これは、計画と現実の乖離につながります。これをしばらくの間続けることができ、時折、他の嬉しいサプライズによって軌道に戻ることもあります。しかし、ほとんどの場合、乖離は続き、現実が無視できなくなるほど大きな差が生じるまで続きます。その結果、通常は非常に大きな痛手を被ります。

嬉しいサプライズは、様々な形で起こり得ます。TempranilloプロジェクトのプロジェクトマネージャーであるGregは、ビジネス担当者がコンテナ追跡用のリレーショナルデータベースを保有していることに気づいた時の話をしています。彼らは、簡単なSQLクエリで、コンテナの修理を遅延させており、その費用を支払っていない企業を全て見つけることができることに突然気づきました。この情報へのアクセスはシンプルでしたが、Tempranillo-Corpは相当な金額を節約できました。このメリットはプロジェクト計画では見過ごされていましたが、新しいシステムの重要なメリットであり、実現するためにちょっとした迂回をする価値がありました。

Tempranilloには、これよりも大きな例もありました。Tempranillo-Corpはコンテナレンタル以外にも多くの事業を行っており、新しい経営陣がコンテナレンタル事業の一部を売却することを決定しました。その際、巨大な冷蔵庫などの珍しいコンテナが売却対象であることが判明しました。新しいシステムにより、これらの事業を容易に分離することが可能になり、古いシステムでは悪夢のような作業だったでしょう。それだけでなく、Tempranillo-Corpが「タンク」（化学薬品、食品などの輸送）の事業を売却し、それでも買い手のためにコンテナを管理するためにシステムを使用することで、両方の取引で利益を得ることが容易になりました。綿密な要件分析では、この変化を予測することはできませんでした。なぜなら、それはビジネスの深い変化だったからです。

この予測不可能性に直面して、計画はほとんど努力する価値がないと結論づけるのは容易です。結局のところ、計画はプロジェクトの途中で破棄される可能性が高いのであれば、どのような価値があるのでしょうか？しかし実際には、これらの予測不可能なプロジェクトにおいて、計画は非常に重要であることが分かります。ただ、計画の重点が異なるだけであり、特に定期的に計画を練り直す継続的な計画プロセスになります。このような環境では、長期計画は不安定で曖昧ですが、それでも方向性を設定するのに役立ちます。短期計画はより安定していますが、必要に応じて変更される可能性があります。

Chardonnayプロジェクトはこのようなプロセスの優れた例です。チームが現在の2ヶ月の展開のためのソフトウェアに取り組んでいる間、アナリストチームは今後2ヶ月間に行うべきことを検討します。ChardonnayプロジェクトのプロジェクトマネージャーであるScottに、6ヶ月先のタスクについて何を把握しているか尋ねたところ、「箇条書きのリストです。ほとんどの意味が分からず、顧客にも分からないと思います。」と答えました。それでも、このプロジェクトはThoughtworksとChardonnay-Corpの両方にとって成功を収め続けています。

高レベルの経営陣の支援を得る

これは驚くべきことではありません。少なくとも、驚くべきことではないはずです。ビジネスプロセスの大きな変化には、経営トップのコミットメントが必要です。そうでなければ、何も起こりません。変革は歓迎されることはめったにありませんが、人間は自然に、どんなに素晴らしい未来だと人々に言われても、知られた悪魔を未知の未来よりも好む傾向があります。この自然な抵抗を克服するには、リーダーシップが必要です。そして、大量のリーダーシップが必要です。

将来へのビジョンを提供するためにも、高いレベルのリーダーシップが必要です。これは非常に詳細なビジョンである必要はありませんが、これらのプロジェクトの性質から、詳細である必要はありません。必要なのは、計画が変化しても進捗を導く何かです。これには、優先順位の設定、何をすべきか、何をすべきでないかについての難しい選択が含まれます。また、先に説明した頻繁なデリバリーへのコミットメントを維持することも重要であることが分かりました。しばしば、本当に素晴らしい機能のために展開を延期するという誘惑があります。しかし、一つの優れた機能が別の機能につながり、すぐにデリバリーを行わず、信頼性と学習の利点を失うという罠に陥ります。ここでは、非常に頻繁な展開が役立ちます。Chardonnayが現在の展開で機能をスキップしなければならない場合、次の展開までわずか2ヶ月待つだけです。その短い時間間隔があれば、何をすべきでないかという難しい決定を下すのが容易になります。

必要な高いレベルのビジネスサポートを得られない場合はどうすればよいでしょうか？私たちのアドバイスは圧倒的に、「そのプロジェクトは諦めなさい」です。特に、そのプロジェクトが会社にとって有益だと確信している場合、これは少し厳しいように聞こえるかもしれません。しかし、経営陣の注意は限られており、それがないと企業変革は、ラスベガスで給料を15に賭けるのと同じくらいの成功確率しかありません。

プロジェクトが経営陣の支持を得たとしても、それが継続される保証はありません。Grenacheプロジェクトでは、当初のリーダーが新しい仕事に移りました。これは驚くべきことではありません。成功した人は、新しい課題に進んで挑戦したいものです。新しいリーダーは、カスタムソフトウェアではなくERPシステムに依存する別の方法を好みました。これもまた、人間の自然な行動です。新しい人は、現在の体制が機能していても、前任者とは異なるアプローチをとることを好むことがよくあります。その結果、サプライチェーン全体の刷新前にGrenacheプロジェクトは終了しました。頻繁なデリバリーは、ここでも貴重な手法です。Grenacheプロジェクト全体の壮大な計画が実現しなかったとしても、構成要素となる全てのプロジェクトが成功し、優れたROIをもたらしたため、ビジネスはこれまでの作業から利益を得ています。お金が無駄になっただけでなく、投資はうまく回収されています。

ビジネスとソフトウェア開発をパートナーとして扱う

企業変革プロジェクトで最も難しいことの1つは、プロジェクトのビジネス面とテクノロジー面の真のパートナーシップを確実にすることです。もちろん、私たちはクライアントとは別の会社なので気づきますが、社内プロジェクトでもよく見られます。ビジネス担当者と技術担当者は、異なる目的と性格を持つ異なる個性の人間です。

社内テクノロジーグループであっても、固定価格契約を結ぼうという強い願望があります。これが私たちのニーズです。さあ、それを構築して、完了したら教えてください。しかし、既に述べたように、このようなプロジェクトはそうではありません。多くの予期せぬ事態が伴います。固定価格契約の方が良いことは完全に同意します。それが機能するならばですが。しかし、固定価格契約は、非常に明確に理解された要件に依存します。そのような要件を持つソフトウェアプロジェクトもありますが、企業変革プロジェクトでは見当たりません。したがって、計画への異なるアプローチ、そしてビジネス/テクノロジー関係への異なるアプローチが必要になります。

私が言っているパートナーシップには、先に説明したような共同計画が必要です。新しい要件が出現し、ビジネスとテクノロジーの両方で問題が発生することを期待する計画です。両者が合意した内容について争い始めるとすぐに、プロジェクトは深刻な問題に直面します。このような関係では、信頼に頼らなければなりません。その信頼が崩れると、プロジェクトも一緒に崩壊します。そうなることもあります。テクノロジーサプライヤーが製品を納品していなかった事例も確かに見てきました。その場合、プロジェクトを終了するか、少なくとも新しいサプライヤーが見つかるまで保留する必要があります。

では、信頼できるサプライヤーを見つけるにはどうすればよいでしょうか？（「Thoughtworksに電話してください」と言う衝動を抑えようと努力します。）明白なアドバイスは、プロジェクトを社内で実行することです。テクノロジー提供企業の人間がこのようなアドバイスをするのは奇妙ですが、営業担当副社長に卒倒させないよう、敢えてそう言います。社内チームであれば、商業的な綱引きのかなりの部分を排除できます。実際、私はかつて、このようなプロジェクトは、私たちのようなテクノロジー企業ではなく、社内で実行するべきだと考えていました。

私の考えを変えたのは何でしょうか？（月給以外に。）問題は、多くの企業が社内でこの作業を行うためのリソースを持っていないことです。テクノロジー企業は、多くの企業よりも幅広い興味深いプロジェクトを最先端のテクノロジーを使用してソフトウェア専門家に提供できます。また、私のようなオタクに適した、自由奔放な環境も提供しています。その結果、より優れたオタクが集まります。企業変革プロジェクトでは、通常、可能な限り最高のオタクが必要となるため、これは重要な点です。これは、プロジェクトをテクノロジー企業に完全に委託する必要があるという意味ではありません。私たちは、ThoughtWorkersとクライアントスタッフの両方からなるチームを使用する多くの作業を行っています。GrenacheとTempranilloプロジェクトは、このモデルで成功しました。

必要なのは、単に頭の良いオタクの集団だけではないことを認識することが重要です。うまく協力して働く人々は、協力しない頭の良い人々の集団よりもはるかに効果的です。したがって、賢い人々の集団ではなく、共通の文化を持ち、以前一緒に仕事をしたことがあるチームを探してください。また、この文化の一部であり、この種のグループと協力することに慣れているマネージャーとアナリストを見つけることも有益です。

では、外部委託する場合、プロジェクトのための技術提供者を選ぶにはどうすればよいでしょうか？一つの要素は、彼らの担当者の質です。彼らが本当にその仕事を遂行できるスタッフを有していることを確認してください。履歴書を見るだけでは通常不十分です。良い方法の一つは、彼らが数ヶ月間作業するために担当者を派遣できるプロジェクトを見つけることです。この期間中に、彼らのスキルを評価し、彼らの文化を知る事ができます。彼らの過去のプロジェクトを見てみましょう。ビジネスドメインはここではそれほど重要ではありませんが、以前そのビジネスに関わったことがあれば確かに役立ちます。重要なのは、このパートナーシップスタイルでクライアントと協力して成功したかどうかを確認することです。参照先の確認は、明白かつ賢明なステップです。他の技術提供者の担当者と協力することに対する彼らの反応を見てみましょう。私は、外部の人間を排除しようとする企業は、たいてい当然の自信の欠如からそうする傾向にあることを発見しました。

もちろん、技術提供者を選んだら、物事がどのように進むかを監視する必要があります。ロナルド・レーガンの有名な言葉「信頼するが、確認する」が思い浮かびます。あなたは目に見える進歩の兆候が必要です。確認できるマイルストーンを含む明確なプロジェクト計画がここでの鍵であり、頻繁なデリバリーという私の繰り返しの文句に驚かないでください。進捗状況を測定するには、動作するソフトウェア以上のものはありません。

また、問題が発生することを予想し、技術提供者がそれらについて率直であることを期待してください。Tempranilloは、これがなぜ重要であるかの優れた例を提供します。前述したように、Tempranilloの修復部分が誰の予想をはるかに超える複雑であることが明らかになった時点で、納品まであと4ヶ月でした。プロジェクトは数ヶ月遅れることになりました。状況についてオープンであることは重要でしたし、状況を評価し、その評価に同意したクライアントのプロジェクトマネージャーも重要でした。これにより、プロジェクトは完全な機能を提供する予定よりも遅れましたが、それでも成功であり、反復的なデリバリーを使用することで、部分的ながらも依然として有用なソフトウェアを出荷することができました。

この例は、プロジェクトに深く関与し、発生する問題を理解できるビジネスプロジェクトマネージャーを持つことの重要性を示しています。これは完全に不可欠ではありませんが、私たちはしばしばマネージャーなしで管理していますが、確かに役立ちます。

もちろん、問題が発生したとき、それは時々私たちのせいでもあります。結局のところ、私たちは完璧ではありません。しかし、繰り返しますが、重要なのは解決策を見つけるために努力することです。St Emilionでは、仕事の複雑さを過小評価するという間違いを犯し、経験不足の初期チームを投入することになりました。これが判明したとき、プロジェクトは困難に直面していました。緊急措置をとる準備が整ったより経験豊富な担当者を派遣することで一部を対応しましたが、クライアントが作業の再計画を支援することも不可欠でした。当初からリスクについて非常にオープンにしており、そのオープンさが必要な信頼関係を築くのに役立ちました。最終的にSt Emilionは成功しましたが、それを実現するために私たち両方が犠牲を払う必要がありました。

将来を見据えた技術を選択する

このようなプロジェクトの技術選択には、特定の問題があります。現在は最適な技術を選択することはできません。プロジェクトが本格的に稼働する数年後までに最適な技術となるものを評価する必要があります。技術が変化する中で、それは難しい選択です。

GrenacheとChardonnayは、ここで興味深い対比をなしています。Grenacheは1990年代半ばに開始され、Forteを選択しました。多くの点でForteは優れた選択でした。それはマルチティア情報システムのための成熟しつつあるプラットフォームだったからです。現在ではより一般的なプラットフォームにはない多くの機能を備えています。しかし、結局のところ、ForteはJavaの急成長に押され、現在は将来性のない技術となっています。1995年にはこれを予測することは不可能でした（Javaは同年になって初めて登場したため）、そのため、20/20の事後分析では悪い決定に過ぎませんでした。

Chardonnayは正しい選択の例です。1997年、エンタープライズJavaテクノロジーはリスクの高い選択でした。ツールとテクノロジーは非常に未成熟であり、ForteやPowerbuilder、VBなどの確立されたクライアントサーバーツールよりもはるかに未成熟でした。しかし、事態は非常にうまくいきました。ツールとエンタープライズJavaに関する知識の未成熟さは、本来あり得たよりも物事を遅くしましたが、現在はエンタープライズJavaは、多くの企業が支援する将来性のある安定したプラットフォームであることが証明されています。

プラットフォームの選択は長期的なツールの選択であるだけでなく、獲得できる担当者にも影響を与えます。ソフトウェア開発者は、特に優秀な開発者は、知性が高い傾向があります。そのため、彼らは、将来性に疑問のある技術を使用することはキャリアにとってマイナスになることを知っています。Javaの世界が技術的に追いついてくるようになる前から、Grenacheで働く準備ができている人を見つけることがますます難しくなりました。

これに対して、完全な技術プラットフォームではなく、統合戦略を選択することが重要になります。Grenacheでは、それを構成するプロジェクトが別々に実行されたため、当初から明らかでした。Grenacheの場合、このプラットフォームはリレーショナルデータベースでした。すべてのプロジェクトは、データの共有基盤として機能する共通のリレーショナルデータベースで動作することが期待されていました。その結果、異なるプロジェクトはかなりの程度の独立性を持って動作することができました。このようなアプローチは、GrenacheにForteの問題からの脱出方法も提供します。将来の開発はJavaで行うことができますが、既存システムの変更には依然としてForteが必要です。

エンタープライズJavaでは、処理ユニット間の通信にXMLを広く使用し、Javaプラットフォームをますます使用しています。Javaの良い見通しに加えて、XMLも長期間にわたって存在する可能性があると見ています。XMLはかなりの宣伝を受けていますが、エンタープライズ開発において重要な役割を果たしています。

これはこのテーマとはやや関係ありませんが、オブジェクト指向プラットフォームの最も宣伝されている利点である「再利用」に関するアドバイスを紹介するのに良い機会です。長年、次世代のアプリケーションを構築しようとする再利用可能なフレームワークの基盤を構築することについて語っている多くの人々に遭遇してきました。成功例にはほとんど出会っていません。技術プラットフォームが消滅した場合の問題は考慮していません。問題は、フレームワークをゼロから構築することが非常に難しいことです。Grenacheは典型的な例です。高度なセキュリティフレームワークの構築には長い時間がかかり、必要以上に複雑なものになってしまいました。

しばらくの間、私と他の多くのフレームワーカーの見解は、フレームワークはそれを使用するアプリケーションの一部として進化させる必要があるということです。いくつかのアプリケーションを構築し、共通点からフレームワークを抽出します。結果として得られるフレームワークは、憶測ではなく、既知のニーズに合わせて設計されています。これは簡単ではないと警告しておく必要があります。実際、初期の基盤を構築するよりも簡単ではありません。唯一の違いは、うまくいく可能性がはるかに高いということです。

人材が成功の鍵である

このようなプロジェクトを成功させるのは、プロジェクトに従事する人々と、彼らがどのように協力するかです。最終的に、これが最も重要な要素です。技術の選択、方法論、ビジネスの変動性、これらはすべて二の次です。うまく協力する優秀な人々のグループは、乗り越えられない問題を克服する方法を見つけ出すでしょう。一方、劣悪なチームは6フィートの壁を乗り越えようとはしません。そのため、このようなプロジェクトを担当する場合は、優秀な人材を獲得し、維持し、彼らがうまく協力できるようにすることが最も重要です。

優秀な人材を獲得して維持することは、主に彼らが自分の仕事を適切に遂行する責任を与えることです。エンパワーメントや新しい人材管理アプローチについて多くの話を聞いてきましたが、実際には、無料のコーヒーを提供すること以上に及ぶことはめったにありません。

人々が難しいと感じるのは、実際には一歩下がってチームが知っていることについて選択をできるようにし、意思決定を行う人々が意思決定を行うための知識を持っていることを保証することです。技術者は技術的な意思決定を信頼される必要があり、ビジネスの専門家はビジネスの意思決定を信頼される必要があります。管理の役割は、多くの場合、適切な人が適切な意思決定を行うようにすることです。

管理のもう一つの重要な役割は、情報が豊富で定期的に流れるようにすることです。コミュニケーションの組織的および物理的な障壁を探し、それらを排除します。その多くは単純なことにあります。一緒に働く人々が互いに近くに座っていることを確認してください。共同作業のための会議室を十分に確保してください。チームビルディング活動に投資してください。結束したチームは、作成する価値のある多くの努力に値します。

ここでは、ビジネスの専門家と開発チーム間の定期的な連絡が特に重要です。Grenacheは、プロジェクト期間中、ビジネスの専門家をチームに常駐させるという慣習に従っていました。Chardonnayには、Chardonnay-Corpのビジネス専門家と協力して、Chardonnay-Corpのビジネスプロセスの方法と理由を知る主要な監督者を選定する、Thoughtworksのリース専門家の大きなグループがいます。必要なのは、定期的な対面での接触であり、通常はビジネス関係者と開発者間の毎日のやり取りが見られます。これは、コミュニケーションと信頼が崩壊するため、プロジェクトのコスト無視されることがよくあります。ビジネス側は、プロジェクトを成功させたいのであれば、プロジェクトに人材を投入する必要があります。

この体制が機能しているかどうかを判断する重要なテストは、悪い知らせへの反応です。開発担当者は現場で問題に遭遇することが避けられず、多くの場合、スケジュールに影響を与える問題が発生します。経営陣の反応が物事を隠したり、皆に「もっと一生懸命働きなさい」と言うことである場合、効果的に機能するような経営陣は得られていません。問題に対する正直な反応とそれらへのオープンさは、開発者と効果的に協力するためにも、ビジネスの良いパートナーになるためにも重要です。

学び続ける

複雑で新しい分野で作業することは、必然的に発見につながります。上記で説明したように、驚きに対処する重要なことは、それらから学ぶことです。実際、長期プロジェクトの成功の重要なテーマは、継続的な学習の概念です。この学習は、ビジネスのニーズ、私たちが使用している技術、そして私たちが行っている作業のプロセスに関するものです。

ソフトウェア開発においてよくある発見の一つに、システムの初期バージョンを見た段階で、人々が要件について考えを変えるという事実があります。これは自然な効果です。なぜなら、システムの存在がビジネス関係者の理解を明確にするからです。その結果、彼らは自身のニーズと、テクノロジーが提供できること、の両方を理解します。頻繁なデリバリーの利点の一つは、この学習プロセスを加速させることです。ビジネス関係者は、これらのデリバリーと開発プロセスへの没頭を利用して、ソフトウェア開発に伴い価値のあるものについてさらに学ぶべきです。シャルドネとサンテミリオンの両プロジェクトは、短い開発サイクルから大きな恩恵を受け、ビジネス関係者が最も価値のある機能を提供するようプロジェクトを導くことができました。

継続的な学習は、テクノロジーにも当てはまります。エンタープライズ変革プロジェクトでは多くの場合、新しいテクノロジーが使用されるため、テクノロジーを最大限に活用するための学習が不可欠です。テクノロジーが新しく、または急速に進化している場合（現代においてそうではないものはほとんどありません）、テクノロジーを使用する最善の方法の多くは、初期段階では明確ではありません。また、初期段階では現れない隠れた落とし穴がある可能性もあります。優れたチームは、使用しているテクノロジーを検討し、プロジェクトがテクノロジーを最適な方法で使用し続けるにつれて、アプローチを変更します。サンテミリオンとシャルドネは、エンタープライズJavaを使用する初期の真剣なプロジェクトのいくつかでした。両チームは、エンタープライズJavaの使用方法について多くのことを学び、その学習と、他のThoughtworksプロジェクトからの学習、そしてJava使用に関する記事の洪水を利用してシステムを進化させました。

見落としやすい学習の形態は、開発プロセスについての学習の重要性です。定期的に、チームの働き方を見直し、チームが改善方法を考えることが重要です。サンテミリオンでは、開発チームとクライアントチームの両方がプロセスを見直し、改善策を決定する、いくつかの重要なレトロスペクティブを行いました。これらのプロセスチェックは、問題を抱えていたプロジェクトを成功裏に導く上で不可欠でした。一方、グルナッシュは自らの成功の犠牲となり、後のプロジェクトは自らの経験を十分に活かすことができず、ここ1年ほどで効率性が低下しています。