記事表示基盤は当初、「社内共通化」だけでなく「外販可能な製品」に発展させる構想もあった。社内向けか、グローバル市場向けかという前提が曖昧なまま開発作業は進行した。その結果、記事表示基盤にあらゆる要件に対応できる汎用（はんよう）性を持たせようとし、アーキテクチャは過度に抽象化、複雑化したという。

汎用性を高めるあまり作業量が膨大に

　記事表示基盤に過度な汎用（はんよう）性を持たせた結果、アーキテクチャは極端に複雑化した。一方、記事の署名欄のデザインや日付表示など、同社の媒体にはさまざまなこだわりがあった。媒体ごとの違いに対応するため、開発過程では「YAML」形式で記述した膨大な設定ファイル、条件分岐が必要となった。開発者は「コードを書く」という本来の業務ではなく、複雑な設定作業を処理せざるを得ず、従来の3倍の作業時間が発生したという証言もあった。

プロダクトマネジャーが不在

　ホール氏によると、専任のプロダクトマネジャー（PM）が長期間不在だったことも失敗の要因だという。PMの不在により以下が発生し、結果として記事表示基盤の機能は肥大化し、整合性を失っていった。

• 現場のニーズが適切に優先順位付けされない
• 現場の要望が無制限に追加される
• 「最後に話したメンバーの要件」が優先される

　開発者やデザイナーが実質的に方向性を決める状態になり、統制が効かなくなったことも要因の1つだ。

NIH症候群が発生

　記事表示基盤の利用が強制であったことも現場の反発を招いたという。現場の利便性を考慮せず、トップダウンで記事表示基盤の利用が強制されたため、各媒体のメンバーに「NIH症候群」が見られたという。NIH（Not Invented Here Syndrome）症候群は、「この製品やサービスは自分たちが作ったものではない」「ここで作られたものではなない」という拒絶反応を意味する。NIH症候群についてホール氏は、「プラットフォームは使わせるものではなく、使いたくなるものにすべきだ」と述べた。

技術的な学びは？

スピードと柔軟性は両立しない

　柔軟性を最大化した結果、開発工数は約3倍になったという証言もあった。

抽象化は常に正義ではない

　ホール氏によると、「同じことを繰り返すな」を意味するDRY（Don't Repeat Yourself）という理念を開発者に徹底した結果、再利用を目的とした抽象レイヤーが重なり合い、コードの意図を理解するために全体構造を追わなければならない状態になった。場合によっては、重複コードの方が健全であると再認識される場合もあった。

どのように失敗をリカバリした？

徹底的な内省

　ホール氏らは、徹底的な内省に務めたという。具体的には、1回2～3時間のグループセッションを10回以上開催。個別インタビューも実施し、大量のインタビューと書き起こしツールを活用した膨大なレポートを作成。経営陣に共有し、組織全体への周知を徹底、組織再編の設計に活用された。

チームを解散

　記事表示基盤の開発開始から7年後の2023年、中央の開発チームを解散。中央集権型の開発体制から、各媒体が迅速に動けるシンプルなスタックへとかじを切った。

共有するものを変えた

　全媒体で同じコードを使い回すこともやめた。システムが複雑になり過ぎて開発スピードが劇的に低下するという本末転倒な結果を招いた結果だ。

　システムそのものを共通化する代わりに、「ノウハウや戦略」を共有することに価値を置く方針に転換したことも有用な取り組みとしてホール氏は紹介した

「強制」から「自律」へ

　1つの基盤の利用を強制するのではなく、各媒体が独自のニーズに最適化した基盤の開発を実施できるようにした。共通化すべきは「基盤」ではなく、「課題をどう解決したかという情報のネットワーク」であると定義し直したといえる。