ニューマン氏は3日間の会期で開かれたGilbane Conferenceの講演者の1人。同カンファレンスは、コンテンツとコラボレーションの専門家たちが、主にIT部門やビジネス部門の管理職で構成される参加者と、さまざまな経験や洞察を共有するための会議だ。2015年の主要なテーマは、デジタル顧客の急速に変化するニーズに迅速に対応できるコンテンツおよびマーケティング戦略をいかに構築するか、というものだった。

　そのテーマは、まさにHBRのITチームが2013年に直面した問題そのものだった。そのころ、読者とeコマース、広告ビジネスのそれぞれのニーズのバランスを取ることは、HBRの8人のITチームだけでは手に負えないことが分かってきた。

　「われわれは、それらの問題を解決する明確なプロセスがなかった」とニューマン氏は振り返る。同氏のチームは、さまざまな方法でプロジェクトの優先順位付けを試みたが、いずれも基本的にはウォーターフォール型アプローチだった。「成功したものも、そうでないものもあったが、とにかく一貫性に欠けていた」（ニューマン氏）

　その結果、「われわれは単なる出されたチケットに対し対応する係になった。プロジェクトの重要性を考慮せず、緊急性を優先して対応していた」とニューマン氏は振り返る。

ウォーターフォール型からアジャイル型へ

　このHBRのWebサイトは読者や広告主のニーズの変化によって全面刷新が必要となった。それがHBRのプロダクト開発のアプローチをウォーターフォール型からアジャイル型へ移行させるきっかけとなった。異なる手法への移行は、もう1つの幸運な結果をもたらした。HBRのITチームは、仕事を受けて対応する立場から会議の席に着くメンバーになったのだ。

　「全面刷新は非常に大掛かりなものだったので、われわれは手を取り合って問題に立ち向かう必要があると考えた」とニューマン氏は語る。

プロジェクトも連帯も簡単ではなかった

　この大規模プロジェクトでは、適応型（アダプティブ）プラットフォームから応答型（レスポンシブ）プラットフォームへの転換が求められた。バージョン管理システムは英Apacheソフトウェア財団の「Apache Subversion」からオープンソースの「Git」へ移行し、サイト構築はページベースのアプローチからモジュラー型に変更。そして最大の課題はウォーターフォール型からアジャイル型アプローチへの手法の転換だった。

　新しい手法では、ITチーム内だけでなく全社レベルの緊密な連携が求められた。

　「ソフトウェア開発のための共有ウェブサービス『GitHub』を利用して、1週間で特定の機能のバグフィックス、ホットフィックス、その他をブランチにデプロイした。そして関係者やその他の部門でテストし、承認後、木曜日にそれを実稼働環境に送り出した」と語るのは、HBRで技術プロダクションマネジャーを務めるフレッド・ラランド氏だ。

　2週間の全力疾走は、刷新プロジェクトに関わる関係者全員の集中力を維持することに役立った。しかし最も重要な点は、会社が強い意志を持つパートナーであったことだ。

　「マーケティング部や販売部、編集部の人々がITチームのパートナーになる意志を示した。今回のプロジェクトでもわれわれをサポートし、チームが一丸でソフトウェアを開発するアジャイル型開発手法『スクラム』のトレーニングも一緒に参加してくれた」と、Webサイト開発者の1人、マット・ワグナー氏は語る。

スクラムから離れる

　興味深いことに、HBRは今はスクラムから離れている。ラランド氏によると、非常に規範的なアプローチは、サイトの刷新後、自らの重みで崩壊したという。

　「プロジェクトが終了したとき、何が起きたか。誰もが異なる優先順位を持ち、異なるタスクを持ち、異なる目標を持つようになった。結集力は低下し、スクラムでさらに細分化が進行した」とラランド氏。

　その後、ITグループはアジャイル型のさまざまなバリエーションでプロジェクトを始めた。幸運なことに、スタッフにアジャイル型アプローチに関するコンサルタントがいた。「迷いが生じたときは、いつでも彼の肩をたたき、やっていることが正しいかどうか聞いた」とニューマン氏は話す。

　そうこうするうちに、スタッフはスクラムの支配から離れていった。現在、彼らは独自の手法を用いているが、それでもなおアジャイル型のフレームワークに大きく依存している。

　「スクラムを離れたことによる大きな効果は、われわれは正しいことをしているのか、われわれは本当に必要としているものを目指しているのか、といった自己認識と内省のステップが要求されるようになったことだ」と同氏は語る。