Murga

個人的に言いたいコト・主張・気持ち。

クラウドやるならアプリやインフラの垣根はなくさないと

フェイクあり。

オンプレからクラウドへのシステムリプレイス案件に携わった。PM はイベントに登壇して「エンタープライズにおけるクラウド移行の勘所」みたいなのを語ってるような人だったので、さぞ見識が深いのだろうと思っていたけど、いざ蓋を開けてみたら何にも分かってないことが判明した。

インフラの構築コストと設計コスト

確かに、クラウド化によって、サーバ構築の手間は物凄く減った。マシンスペックを選択してボタンポチーして鼻ホジーして待ってたらサーバが出来上がる。ミドルウェアや監視ツールをプリインストールしてくれるような機能もあったりするし、スケールイン・スケールアウトも容易だ。

ただ、当然ながら、インフラ構築はコレで終わりではない。

サーバインスタンスに直接 Public IP を振ると冗長化しづらいし、侵入の危険性もある。そこで、仮想ネットワークに閉じてインスタンスを配置し、インターネットからの流入口はロードバランサに集約する。その上で特定のポートだけ開放して LB とインスタンス間の通信を許容するよう、ファイアウォールを設定する。DB が絡んだり、クラウド外のシステムとの連携があるとさらにネットワーク構成が複雑になる。

ココまでは、クラウドに限らずオンプレでも同様に考慮すべき、インフラ設計の一般論。

クラウドサービスを利用する場合は、どうしてもそのクラウドベンダごとの仕様や特徴に合わせた考慮が必要になる。サービスの仕様上、この外部サービスとの連携は出来ないだとか、PaaS の場合は IaaS ほどチューニングの自由度がないだとか。

先述の PM は、この「クラウドベンダごとの特色に合わせた思考」が全く出来ない人で、旧態依然なオンプレ思考が色濃く残る一般論でしか喋れず、「何で自分が思っているように簡単に行かないんだ!」とお怒り。ウーン、でもこのクラウドベンダに決めたのアンタだから、少しは勉強してくれ。

インフラ設計はアプリに依存する

さて、システムを構築するにあたり、サーバのスペックや冗長構成はどのように決まるだろうか。

それらの要件を決めるための視点は、一般的には以下のようなモノが考えられる。

  • システムの利用者数 → システムが捌きたいリクエスト量
  • システムが扱うデータのサイズ
  • スループット (処理時間。ある処理をどれだけの時間内に終わらせたいか)

システムの利用者数は、そのシステムがどんなシステムかによって決まる。社内向けなら人数はそこまで多くないだろうし、B to C な Web システムなら百万人規模のアクセスを見越すことも当然ある。

システムが処理するデータ量や、期待する処理時間を決めるにあたっては、そのシステムの実装が大きく影響してくる。ミドルウェアより上の、ソフトウェア = アプリケーションの領域で、どのようにシステムを実装するつもりかによって決まってくる話なワケだ。特に、スクラッチではなくパッケージを利用している場合は、予め最低スペック要件が提示されているはずだ。

要するに、サーバのスペックや台数を考える時は、そのサーバに載せるアプリのことをよくよく把握しておかないと決められないというワケだ。当たり前のことだが。

「インフラチーム」と「アプリチーム」という垣根

それなのに、PM の思考はオンプレ寄りなので、「キミたちはインフラ担当」「キミたちはアプリ担当」とチームを別けてしまった。

コレだと、アプリ担当の人間は自分達が使用するパッケージと、それを活用した実装部分にしか目が行かなくなり、ハード (= インフラ) 的な視点が欠落してしまう。逆に、インフラ担当の人間も、アプリ担当が何を使い、どう実装しているのか分からない (分かりにくくなる) ので、どんなウワモノが乗るかが分からず、完全に推測でハード的なスペックを決めたりしないといけなくなる。

インフラとアプリがチームとして分断されると、ミドルウェア領域の話が宙に浮いてしまう。DB と接続するデータソースの定義だとか、JVM のヒープ設定だとか、そういうミドルウェア領域の設計・実装は、アプリ担当とインフラ担当のどちらがやるの?というところがうやむやになり、お互いに押し付けあってしまう。

アプリ担当的には「マシンスペックとか決めたのはインフラ担当なんだから、その情報をベースにミドル設定もしてよ」と思いたくなるし、インフラ担当としては「そのアプリが必要な設定はインフラ側では分かんねえよ、お前らアプリ担当の連中が握ってるんだろうからお前らがミドル設定しろ」と言いたくなるワケだ。

インフラチームが別部隊に別れる組織構造は、オンプレ時代はよくあった話だ。物理的にサーバを調達し、会社のサーバルームで物理的に構築していくワケだから、アプリ開発する人間とは地理的にも離れるし、専任性が高まるのは自然な話だ。

この場合、システムを載せるとなると、「アプリ担当チーム」にあたる人間たちが、自分たちのシステムに必要なマシンスペックを計算し、「インフラ担当」に連絡してサーバを調達してもらっていたはずだ。インフラチームも自分たちの専門知識の範囲でハード寄りのアドバイスなどはするが、主導するのは「アプリ担当」側、といってよかったはずだ。そして、インフラ構築が終わると、LB やサーバの IP アドレスがインフラ担当からアプリ担当に連絡されるので、あとはアプリ担当がミドル含め設定していく流れだ。

物理的にも距離が離れているからこそ、このようなコミュニケーションルートが自然になっていたと思う。しかしそれはオンプレ時代の物理的な制約による組織構造であり、クラウドを活用するにあたっては邪魔でしかない考え方だ。

仮想化技術により色々なリソースが抽象化されているので、オンプレの感覚だけではなくクラウドに知見を持った人間がいないと、上手く話が出来なかったりすることはある。それでも、ハードウェア選定はウワモノありきでしか決められない、もしもそうでないなら、先に決めたハードのスペック内で出来ることがアプリの要件になる、という2択には変わりないはずだ。

だったら、アプリチームとかインフラチームとかいう別け方は止めて、まずは全員でアプリ寄りな視点でのシステム要件を洗い出し、それからその要件に見合うハード面のスペックを選定すべきだと思う。

インフラに知見のないプログラマばかりが集められた

コレは先述の PM が自分のコネだけで要員を調達してるからという弊害なのだが、チームの SE やプログラマは、いずれもアプリケーションの開発工程くらいしかまともにやったことのない人達が集められていた。年齢だけは重ねてるんだけど、要件定義や概要設計を経験した人間がほぼいなかったのだ。

だから、そもそもシステムの要件ってどんな要素があるのかとか、ハードウェアの性能をどうやって決めたらいいのかとか、「そういうことを考慮する必要がある」ってことすら認識していないレベルだった。

そしてクラウドの活用経験もないのに、なぜかクラウドに関しては「簡単に構築できるもんなんだろう」「とにかくお手軽で楽なんだろう」と思い込んでいて、「オンプレからただクラウドに引越しするだけっしょー?」と軽々しくのたまっていた。

先程「アプリチームとインフラチームで組織的に別けられた」と言ったが、インフラチームに割り当てられた人間たちも、こういう連中の中から適当に決められただけだった。「クラウドって GitHub ですか?」「Terraform…?TeraTerm ではなくて…?」みたいなレベルの人間たちだったのに、いきなりインフラ設計を任されてしまったのだ。

こんな感じだったから、「サブネット」の概念も分からず、ファイアウォール設定もされてない、マシンスペックの選定もパッケージの仕様を考慮してないからほとんどデタラメという有様だった。さすがに有識者からツッコミがあってだいぶ是正されてきたものの、これら諸問題の原因は明らかだった。

つまり、クラウドを使うということは、これまでサーバルームにこもって作業していた「インフラ担当」の仕事を、全てアプリ開発者が巻き取ることに他ならないのだ。オンプレ時代なら「インフラ担当」に任せっきりで知りもしなかった分野も、彼らに頼らずクラウド化するとなると、アプリ屋がハードやネットワークの設計が出来ないといけないワケだ。

勿論、個人の趣味レベルの話ではなく、エンタープライズレベルの堅牢さ・安全性が求められるワケだから、クラウド未経験とかインフラ知らないとか、そんなメンバの都合は関係なしに、「この水準以上のセキュリティは担保してもらわないと…」と社内稟議で突っ込まれるのは当然のことだ。

リリース後のことも考えて

アプリを開発するだけのプログラマは、リリース後の運用保守作業を知らない。運用保守とは何をするのか、何に手間がかかるのか、そういった知見がない。

それはその人が書くコードを読んでいても分かる。保守改修を経験してきた人のコードはリーダブルだが、開発しては転属を繰り返していた、「作り逃げ・作り捨て」が板に付いている人のコードは、読めたもんじゃない。

そういう開発屋さんの感覚では、「リリースを迎えたら仕事は終わり」なのだが、今回の案件は、クラウドリプレイス後の運用保守も、そのチームで引き受けることになっていた。

ということは、サーバの高負荷やヘルス監視、そして検知したら迅速に復旧対応、といったタスクが増える。じゃあ監視はどうするの?というと、コレもオンプレ時代は「インフラ担当」に任せっきりで、どう監視したらいいのか、何を監視したらいいのか、といった知見がなかった。

一応、24時間・365日の運用監視が必要になるという名目のシステムなので、夜間監視は別会社に委託するワケだが、委託しようにも説明資料が何もない。素人たちが混乱を極めるプロジェクトで、仕様書や手順書なんてモノは一切作られていなかった。

高負荷対応やシステム復旧に関しては、どうやらクラウド関連のバズワードを仕入れた人間がいるみたいで、「Jenkins サーバを立てといて、オートスケールしたり、インスタンス生成やアプリのデプロイを自動化したりしましょう!DevOps ってヤツです!」って意気込んでた。運用コストも下がるだろうってことでやることになっていたのだが、「Jenkins サーバ」とか言ってる時点でお察し。巷の CI・CD ツールには目もくれず、考慮不足の自前スクリプトを時間かけて実装して、後で全然実用に足りないことがバレて大問題になった。

一連の問題に気が付かない PM

ココまでの話から容易に察してもらえるだろうが、このプロジェクトの PM は、自分の考えに固執するタイプだ。自分の考え (一般論) が正しいし、それで上手くいくと本気で思っているのだ。ハードやインフラの知識がない人ではないのだが、オンプレ時代の「インフラ担当」に任せてきた仕事をまるっと巻き取ることの難しさには全く気付いていないようだった。

「インフラ担当を任命したし、あとは上手くやっといてもらえるもんだろう」と思ったのか、PM は要件定義段階から雑にフェードアウト。渡された見積書にもロクに目も通さず OK を出し、なんとなく開発がスタートしていた。

オンプレからのリプレイス案件だと言いつつ、アプリ改修も同時に大量に行っちゃう、よくあるバカな案件だったので、アプリ担当は改修作業で手一杯だった。インフラ担当も、慣れないクラウドの壁にぶつかり、数々のトラブルが多発していた。

PM が異変に気付いたのは、結合テストが完了予定日を2ヶ月過ぎても完了していなかった時だった。アプリ担当とインフラ担当の間で情報共有、知識ベースのすりあわせがされないまま、中途半端にお互い隠蔽体質なまま進んできたので、アプリをクラウドサーバに載せた後でトラブルが多発していた。ミドルウェアの設定もそうだし、アプリの都合によって「ロードバランサでこういう制御が必要だ」みたいな話が出始めたりしていた。

さすがに PM もヤバいと思ったようで、クラウドの有識者を雇ったのだが、そもそも根本的にインフラ設計に欠陥があることが判明。しかしその時点で構築されていた構成は、PM が雑に承認した見積に沿っているモノで、欠陥を改善するためにはその見積よりも大きな金額がかかることが明白だった。

開発工程も半ばを過ぎたところで、いまさら見積の不備を指摘される PM。明らかに予算が足りず、リリースにこぎつけられるか、リリース後の運用体制が整うかも分からなくなった。

読んでいなかった (もしくはクラウドの知識がなくて読解できなかった?) 見積書とはいえ、責任は PM にある。本人もパニックみたいで、「何でこんなことになるまで誰も言ってくれなかったんだ!」などとのたまっていたが、いやもういい歳した大人が「誰かに注意してもらわないと私は見積書を見過ごしちゃいます」と告白してるのに等しい発言はさすがに吹き出しそうになった。有識者からは「でもあなたがこのおかしな構成で承認しちゃってますから、認識してるはずだと思ってましたが…」と正論を言われ、苦し紛れに「この見積作った奴連れてこいや!」と怒鳴り散らしたりしてた。片腹痛い。

実は自分はこの頃にテコ入れとして雑に投入されたメンツの一人なのだが、既に1年近く開発してるはずなのに全然成果物がなく、最初は全然状況が掴めなかった。あちこちにヒアリングして回った感じだと、みんな自身がこの案件の内容に対して実力不足なのは薄々自覚してて、恥ずかしかったり、言いにくかったりして、内々で問題を抱え込もうとする傾向にあるのが分かった。だからアプリチームの都合はインフラチームに聞こえてこないし、インフラチームもアプリチームに何か言われるまで黙ってたりしたみたい。

組織構造どおりのシステムが出来上がる、「コンウェイの法則」という言葉があるが、このシステムはまさにこの法則を体現している。いや、構築が出来ていればまだいいんだけど、今のところまともに動かないからね。下手したら UAT (ユーザ受け入れ・ユーザ承認テスト) で却下されてリリースできないかもしれない。

個人的には、そもそもこのプロジェクトに絡まされた意味 (経緯) が分かんないので、どうにでもなったらいいのに、と思っている。一般論しか知らず「クラウドは楽だ」と思い込んでた連中が、いざやってみて「全然上手く使えなかった」と挫折してゴメンナサイする姿が見てみたい。そのくらいのお灸をすえてやった方がいいと思う。

クラウドは全領域に深い知識が要る・全員が高いスキルを有していないとダメ

ココからは、このチームがこうだったら成功していただろうな、という感想。

何度か述べたとおり、クラウドというモノは、アプリケーションそのもの以外に、ハードやネットワーク、運用に至るまで、システムを構成する全ての領域に対する設計が要る。設計をするには知識が要る。すなわちフルスタックでないとならないのだ。コレは IaaS だろうと PaaS だろうと FaaS だろうと関係ない。コンテナ化しようがしまいが、システムをクラウド上で動かすためには、アプリ領域だけではダメで、インフラ領域も知らないといけないのだ。

そして、チーム内で役割分担がある程度できるのはいいのだが、「アプリ領域を知らない人」「インフラ領域を知らない人」がチーム内に1人でもいると、恐らくクラウド活用は失敗する。全員がフルスタックでいるべきだ。

リーダや PM 層になると、日本では実際に開発したり手を動かさない場合が多いが、個人的には、クラウドを活用するなら上の層の人ほどコードを読み書きして、何についても一番詳しい人間でいないといけないと思う。メンバに丸投げしていい分量ではないし、全領域を俯瞰しながらのハンドリングが重要になるので、上に立つ人間は誰よりも賢く、実態を正確に知っていないといけないのだ。細部を省略していたり、一般論で語っていてはダメだし、Terraform や CLI ツールは当たり前に使っていないといけない。

「そんなの無理ゲーじゃね?」「そんな優秀な人いないって」

うん、そうだと思う。だからそういう素人しかいない古臭い日本の企業は、オンプレからクラウドへの移行なんて難しいこと止めた方がいい。彼らにはコレをやる能力がない。

クラウド化する世界~ビジネスモデル構築の大転換

クラウド化する世界~ビジネスモデル構築の大転換

Netflix オリジナルドキュメンタリー「FYRE 夢に終わった史上最高のパーティー」を観て、完全に今の現場じゃんと思ったり

Netflix オリジナルドキュメンタリー「FYRE 夢に終わった史上最高のパーティー」を観た。

2017年に開催された「Fyre Fesival」という音楽フェスは、美女たちが青い海ではしゃぐ PR 映像が SNS で話題になり、「最高の音楽・食事・アートが体験できるフェス」だとして注目された。しかし実際は、豪華な宿泊テントなどなく、避難用の簡易テントが流用され、ミュージシャンは一組も来ておらず、帰りの飛行機すら手配されていなかったという。この音楽フェスを企画したビリー・マクファーランドという男は、最終的に詐欺罪で逮捕されている。

このドキュメンタリーは、どうして Fyre Festival がこのような結末に至ったのか、その裏側を暴いている。当時の舞台裏のフッテージが利用されており、ビリーが語る大きなビジョンに対し、現実的な準備がいかに甘かったかが浮き彫りになっている。いや、彼の場合は恐らく、最初からちゃんとした音楽フェスを開催するつもりはなく、詐欺を意図していたのかもしれない。

いずれにしても、ビリーからの無茶振りをなんとか捌こうとしている現場のスタッフたちの証言を聞くに、あぁーこういう開発プロジェクトってよくあるよなぁっていうか今いる現場まさにコレだなー、とか思った。

そこで今回は、ドキュメンタリーのあらすじに沿って内容を紹介するとともに、この詐欺行為と共通する、炎上必至のダメな開発プロジェクトにありがちなポイントを紹介してみようと思う。

壮大なビジョン

2017年。当時25歳だった「起業家」のビリー・マクファーレンは、ラッパーのジャ・ルールとともに Fyre というアプリの共同創設者となる。その最初に企画されたのが「Fyre Festival」だった。彼らは「麻薬王パブロ・エスコバルが所有していた島を購入し、そこで音楽フェスを開催する」「海でレジャーを楽しんだり、豪華な食事や宿もついている」というビジョンを盛り上げていく。そして、一流モデルたちを起用したプロモーション映像を撮影。セレブやインフルエンサーに金を払って SNS を巧みに利用し、「何やら面白そうなフェスが計画されている」という情報だけを煽る。

さて、ココまでで読み取れる詐欺師の特徴は、こういうことだ。

  • 語られるビジョンが素敵過ぎる

一方、炎上する開発プロジェクトにありがちな特徴は、よく似ている。

  • 当初掲げられる計画が素敵過ぎる

「老朽化したオンプレのシステムを、クラウドにリプレイスする」だとか「イマドキの CI/CD の仕組みを導入し、運用コストを下げる」だとか「モノリシックなシステムを分割しマイクロサービス化することで開発効率を上げる」だとか。

耳障りがよく、「実現できたら素晴らしいことだな」と思えることが、企画書にはふんだんに盛り込まれている。しかし大抵は、

  • どのようにそれを実現するのか
  • 期日までに実現できるのか
  • 実現していく上での課題や問題点は洗い出せているのか

といったところが全く考えられていなかったり、浅い考えでしか記されていなかったりする。

こうした見通しの甘い計画は、「考えておくべきこと」が見過ごされていて、それが負債になり、後々のフェーズに致命傷を与えかねない。

トップの人間が「管理」していない

ビリーは企画を立ち上げ、とりあえず大々的な PR 映像に大金を使ったが、フェスを開催する島の準備に難航する。結局「パブロ・エスコバルの島」ではフェスを開催できず、近所の違う島を用意したが、そこはとてもフェスを開催できるような地形ではなかった。また、トイレの設営費用や食事、送迎、テントなど、音楽フェスを成立させるためには「華やかなステージ」以外の様々なことも検討する必要があった。

そうした諸問題に対し、ビリーは「僕は資金を調達してくるから、君たちが上手くやっといてくれ」と、スタッフたちに業務を丸投げしている。「管理がずさん」なんていうレベルではなく、何も管理できていないのだ。

  • トップが全体を把握して管理・統制を取れていない

コレは失敗するプロジェクトの一番の要因ではなかろうか。

  • PM は色々な業務が多く、管理にまで手が回らない
  • PM は技術的な細かいことまで理解できないから、スケジュール調整が大味になる (大抵少なく見積もる)

平たくいえば「PM のキャパオーバー」で、そいつが任された仕事に対してそいつの能力が足りていないのだ。

ココで、PM の性格によって、いくつかの行動パターンに分かれる。

1 : 自分で何とかしようとして過労 → 部下に指示が降りてこない

真面目な性格の PM だと、自分で何とかしようとして残業を続ける。自分が管理・制御するために時間をかけて仕事を進めていくのだが、その間、部下には何の指示も降りてこないから、部下は待ちぼうけを食らう。

残業を続けているから次第に思考能力が低下し、正常な判断が下せなくなってくる。ようやく部下に出された指示は明らかに詰めが甘く、「それってこのパターンの場合に仕様が矛盾しませんか?」とか「そのタスク、別の人と思いっきり被ってて同時進行はできません」とかいう事態になる。

2 : 分かんないから部下に丸投げする → 進捗が芳しくなく怒り駆動開発へ

もう一つは、「とにかく頭を下げたくない」「強がっていたい」タイプの PM がやらかすヤツ。「仕事は若い奴が頑張れ」とでも思っているのか、自分が分からない仕事はまるっと部下に投げてしまう。

「仕事を任せる」というのは、その人に適切な権限を一緒に与えてこそ出来ることなのだが、こういうバカ PM は「仕事は任せたが、期限は死守。」とだけ言って去ってしまい、以後一切の協力・フォローをしないのだ。

仕事を押し付けられた部下の性格にもよるが、頑張っちゃうタイプの部下は過労死するまで食い潰すし、「そんな無茶振り、できっこないですよ」と反論してくる部下にはとにかく怒鳴りつけることで無理矢理従わせる。

進捗管理も何もしていないので、気まぐれに様子を聞きに来て、自分の想定と違う状況だと (大抵はそうなのだが) とりあえず怒り散らし、怒り駆動・恐怖駆動で開発を強いるのだ。


どっちのタイプも、やれる能力がないのにそんな PM 業を引き受けるから悪いのだ。

それでも、ビジョンありきで着手してしまい、具体的な目標や計画にブレイクダウンできない (しない) まま、ズルズルと進んでしまっているのだ。言わずもがな、コレでは負債がどんどん積み重なっていくことになる。

中止・リスケの判断を下せない

ビリーのずさんな管理はフェスの開催前日までそのままで、現場スタッフたちは疲弊していた。かなり手前の段階で「このフェスは失敗する・中止した方が良い」と進言した部下はクビにしてしまう有様。前日になっても会場の設営が完了していなかったという。

そしてついにフェス当日。避難用テントがテキトーに並べられた会場に通される客たち。いつまでもフェスが始まらないわ、突然の大雨でテント内はぐちゃぐちゃだわで、現場は暴動寸前。夜は電気が全くなく、混乱を極める。

結局 Fyre フェスは初日に「中止」が宣言されるが、帰りの飛行機のチケットは手配されておらず、帰ろうとしたフェス参加者たちは空港で待ちぼうけを食らうことになる。

極めつけは、汚らしいサンドイッチの写真が Twitter に投稿され、Fyre フェスティバルの実態が世界に明らかになったのだった。

  • 事態が崩壊しているのに、中止やリスケの判断を下せない

最初に語ったビジョンが壮大なだけに、様々な外的要因によってスケジュール調整が困難になるのが、炎上するプロジェクトの特徴。

単純に考えて、壮大な計画、巨大なシステムには、多くの依存関係が存在する。いくら個々のシステムをマイクロに作ったからといって、「あるシステムが止まっていても大丈夫」なんてことはなかなかなくて、連携システムがスパゲッティのように絡み合い、どれもが欠かせない状態になる。

依存関係が多いと、開発チームとしてもお互いの開発チームの進捗に影響されたりするし、打合せばかり増えて開発に注力できなかったりするし、システム間の接続部分で必ずといっていいほど問題が起こる。

これは開発が順調に進む環境であっても起こりうることなのだが、先程のように PM が全然管理していない現場では、もっと混乱を極める。PM は何が問題なのかすら理解できないトンチンカンなのに、様々な決定権を持つため、このバカに理解してもらうための説明の時間が余計に取られる。そして基本的にはバカな PM が正しく理解できることはないので、判断を誤り、「じゃあこのタスクは1日でやれ」みたいな無茶を言ってくる。いくらその判断はおかしいと指摘したところで、おかしい理由が本当に理解出来ないし、自分を否定されたことで頭に来てしまうので、「いいからやれ!」と怒鳴りつけて立ち去ってしまったりする。

実際のところ、PM のバカどもも「ヤバさ」には気付いていて、スケジュールが絶望的に間に合わないことは薄々気が付いていたりするのだ。しかしそれでも、前述のとおりいまさらスケジュール変更なんてできないというところまで来ており、焦ってはいても何にもできないのだ。

自分にはどうすることもできなくなっているから、彼らは「怒る」のだ。「怒る」という行為は、対処法が分からないけど何とかしたい時に発する感情なので、怒っているというのは、その人が対処できるキャパを超えている証拠なのだ。

現場の人間は最後の最後まで「なんとかしたい」「せっかくやるなら成功させたい」と頑張るのだが、ある時「プツッ」と悟る。「あぁ、これ俺一人が頑張ってもどうにもならねえや」「俺が努力してもバカな PM が握り潰しちゃってて意味ねえわ」と。そうすると、もうどれだけ怒られても感情が「無」のまま、ダラダラと仕事をしたり、人によっては突然休職したりし始める。

本当は、PM が「いまさらスケジュール変更なんてできない」と思ったところで、それでもスケジュールを延期したり、「中止」の決断をしたりしないといけないのだが、彼らはゴメンナサイをするのが何よりも嫌なので、絶対に謝らない。最後まで「もしかしたら謝らなくて済むかも」という可能性の方に賭けてしまい、事態を修復不可能なところまで破滅させてしまうのだ。もしかしたら早い内にゴメンナサイしていた方が、結果的には品質の高い成果物になっていたかもしれないところを、無理矢理体裁だけ本番リリースに間に合わせた気になって、リリース当日に重大なバグを引き起こしたりするのだ。

それでも自分が悪いとは思っていない

明らかに詐欺同然の運営でフェス当日を迎え、大失敗に終わった Fyre フェス。それでもビリーやジャ・ルールは、その後の全社ミーティングで「コレは詐欺じゃない」「不運な失敗だった」などとのたまう。ビリーは逮捕されるが、その後釈放されてからも、本件に対する反省など微塵も見せず、次なる計画を語り始めたりしている。

ドキュメンタリーは、懲りずに夢を語れる、この薄気味悪い25歳の男を映して終わっていく。

  • それでも自分は悪くない
  • 「また次がある」という根拠のない自信に満ち溢れている

現場を混乱させ、誰も保守できない酷いシステムを作り上げてしまっても、PM は平気な顔をしている。なぜなら、人が何人辞めようとも、どんなにバグを含んでいようとも、「当初約束したとおりのリリース日にリリースができた」からだ。彼らはコレを「成功」にカウントする。その後に本番障害が起ころうとも、この開発プロジェクトを「失敗」とは評価しないのだ。だってリリースの期日には間に合ってるから。形だけでも。

PM 連中は実質的に何の仕事もしていないから、リリース日にさえ間に合えば、自分たちはよくやったと思えるのだ。その上で発生した障害は部下が実装したことだから、自分が悪いという意識はないのだ。

だから、現場的には「あーもうどうすんだよコレ…」という絶望的な気分でも、奴らだけは「よーし打ち上げいくかー!」なんて呑気に言えたりするのだ。

Fyre Festival は炎上プロジェクトの縮図そのもの

Fyre という音楽フェスが失敗に至った経緯は、ニホンノエスイーがよく経験する、炎上プロジェクトの現場そのものだと思った。最初に風呂敷を広げすぎて、計画性がなく、知識も知恵も足りなくて統制が取れなくなり、自分のくだらないプライドが邪魔して物事を正しい方向に導けず、最後の最後まで誤魔化そうとして、大失敗したのを頑なに認めない。病んで辞めていったスタッフを見捨て、全ての元凶を作った本人だけがケロッと忘れて、また同じことを繰り返していく。ビリーは、まさに炎上プロジェクトの PM そのものだ。

自分も今そんな現場にいるので、Fyre をこのタイミングで見直して良かった (?) と思う。トップがクソだと全てクソ。現場が頑張るのは逆に良くないこと。むしろ大失敗させて、バカな PM にはお灸を据えてやらないといけないと思った。

こんなもん、自分を壊してまでやる仕事じゃねえや。無能な PM に殺されてたまるか。明日も仕事しねぇぞ。