ITプロジェクトを成功させるには「リリースの難しさ」を認識することが大切

過去10年にわたってテクノロジー業界でさまざまなプロジェクトに関わってきたというショーン・ゲーディケ氏が、「大手テクノロジー企業でプロジェクトを遂行してリリースする方法」を自身のブログにつづっています。

How I ship projects at big tech companies | sean goedecke
https://www.seangoedecke.com/how-to-ship/

◆Shipping is hard(リリースは難しい)
プロジェクトは自動的に出荷、すなわち市場にリリースされるものではありません。実際はプロジェクトが無期限に延期されたり、キャンセルされたり、中途半端な状態でリリースされて破綻したりすることがよくあります。

プロジェクトの出荷作業は通常、一人の担当者によって進められます。たとえ、すべてのコードが書き終わったり、すべてのバグ修正や改善が完了したりしても、「困難で繊細な出荷作業」を誰かが意図的に引き受ける必要があります。

これは「その人が全てのコードを書いたり全ての作業を行ったりする」という意味でもなく、「チーム全体の支援なしでリリースが可能」という意味でもなく、「プロジェクトの技術的な全体像と、製品やビジネス目的を理解している人が1人必要」ということだ、とゲーディケ氏。例えば、顧客体験の改善に時間を費やしすぎると、リリースは遠のきます。UXへのこだわりは、チームのエンジニアとしては称賛に値する行動ですが、プロジェクトリーダーとしては失策といえます。良いチームや企業はこのことを理解し、「テクニカルリード」や「DRI(直接責任者)」と呼ばれる担当者を各プロジェクトに配置するとのこと。ゲーディケ氏は「出荷作業は余暇の時間で行えるような簡単な仕事ではありません」と述べています。

◆What is shipping?(リリースとは何か)
ゲーディケ氏は、「多くのエンジニアは、リリースが単にコードをデプロイすることや、機能をユーザーが使えるようにすることだと考えがちですが、それは誤りです」と指摘。ゲーディケ氏にとって「リリース」とは会社内における「社会的な概念」であり、具体的には「会社の重要な人々がプロジェクトがリリースされたと信じること」を意味するとのこと。

ゲーディケ氏は、もしバイスプレジデント(VP)やCEOが不満を持っているなら、それは本当の意味でのリリースではないと断言しています。例えば、VPからSlackで祝福メッセージを受け取ったり、内部ブログで成功が報告されたりすれば、それはリリースの成功を示しているといえます。小規模なプロジェクトであれば、マネージャーから称賛されるだけでも十分にのリリース成功といえるでしょう、とゲーディケ氏。

ユーザーが喜び、収益を生むプロジェクトが成功とみなされるのは、それがリーダーシップチームを満足させるから。逆説的ですが、ユーザーが不満で収益も上がらなくても、リーダーシップチームが満足していれば、それは「リリース成功」として認められるというわけです。

ゲーディケ氏は、「この現実が気に入らないのであれば、ユーザーの満足度を本当に重視する企業で働くべき」と述べ、仕様の実現やコードのデプロイをリリースと考えるエンジニアは繰り返し失敗する出荷作業に向かって技術的な取り組みを延々と続けることになってしまうだろうと語りました。

◆Communication(コミュニケーション)
プロジェクトの成功に向けて、まず会社が何を求めているのかを明確に理解する必要があります。企業向け機能開発なのか、無料ユーザー向けの機能なのか、特定の大口顧客のためなのか、それともVPやCEOの肝いりプロジェクトなのかによって、アプローチは変わってきます。

リーダーシップチームは技術的な文脈を理解していないケースがほとんどであるため、見積もりや技術的な課題の予測について、リーダーを信頼する必要があります。この信頼関係の維持が最優先事項だとゲーディケ氏は指摘し、過去の実績や自信の表明、プロフェッショナルなコミュニケーション、定期的な更新報告が信頼関係の維持に特に重要だとしました。

◆Getting into production(本番環境への移行)
本番環境への移行時には、技術的な詳細、他チームとの調整、法的な問題など、様々な課題が発生する可能性があります。これらの問題に対処するには、システムへの深い技術的理解と素早い対応能力が必要です。

ゲーディケ氏は「プロジェクト終盤では実装作業の9割以上から解放されている必要があり、問題対応に集中できる状態を作ることが重要」と訴えています。また、問題が実在しないケースでも、他チームから懸念が示された際には、適切に対処できる準備が必要。そのため、実装作業に深く関わりすぎず、問題対応のための時間を確保することが重要です。

◆Can we ship right now?(今すぐリリースできるか)
フィーチャーフラグやステージング環境を活用し、できるだけ早い段階で多くの人々に機能を見てもらうことが重要だ、とゲーディケ氏。これは、実際の機能に触れることで予期せぬ問題が浮き彫りになり、リーダーシップの安心感も高まるからです。

リーダーは「今すぐリリースできるか？」という問いを常に持ち、すぐにリリースできない場合は何が必要かを考えます。また、他チームの対応待ちの場合は、その変更がなくても動作するような代替案を用意することも有効です。多くのエンジニアは恐れと不安からデプロイを後回しにしますが、「プロジェクト全体を理解している人は一番恐れる必要がないはず」という理由で、逆に怖い変更ほど早めに行うべきだとゲーディケ氏は述べています。

プロジェクトのリリースは非常に困難で、最優先事項として取り組む必要があります。出荷作業とは単なるコードのデプロイではなく、リーダーシップチームを満足させることを意味し、リリースを実現するにはリーダーシップチームからの信頼が不可欠です。技術面では、問題を予測して予備プランを作成することが重要な作業となります。ゲーディケ氏は、常に「今すぐリリースできるか？」と自問し、勇気を持って取り組むことが必要だと主張しました。