今はもう遠い昔。あの雲のむこうにはFlashがあった

どこか遠い場所の話をするように、人々は「昔のWebは楽しかった」と言う。結論から言えば、昔も今もWebは楽しいし、つまらない。昔と今で何が違うかといえば、大統領やその側近がSNS中毒でなかったことと、Flashムービーがあったことぐらいだ。

*

Flashとは何だったのか、という話をするのに私はそれほど向いていない。著名な制作者や会社の名前をシーンとしてちゃんと把握していないし、作り手としてもグラフィックやアニメーションのセンスがなかった自分は、ActionScriptプログラマではあっても、Flasherだと言えるほどではなかったからだ。

ただ、技術スタックとしてのFlashのことは好きだった。Perlと同じぐらいには愛していたかもしれない。Flashのプログラミング環境は、今でいうリアクティブの走りのようなもので、シンボル化したムービークリップのプロパティをいじれば、それがすぐ表示に反映されるし、「シンボル化」することで、カプセル化めいたことができるのもオブジェクト指向のパラダイムのグラフィカル版みたいでエキサイティングだった（今のScratchの書き味にけっこう近いと思う）

制作サイドから見たFlashのいいところは、こだわりが目に見えるところだった。それこそ1フレーム単位で調整ができたから、当時の貧弱なWebブラウザが、MSPゴシックのアンチエイリアスに手間取ってる一方で、Flashのレンダリング結果は美しかったし、努力次第でいくらでも美しくすることができた。

あの頃の「Webデザイナー」の頂点はだいたいFlashを嗜んでいたし、一流Flasherと同義語ですらあった。Webサイトがあって、ブランディング戦略があって、差別化する必要があったら、そこにはギチギチにチューンされたFlashムービーがある、というのが当たり前のことだった時代だ。

だから、iPhoneのブラウザにFlashが搭載されなくて、色々あってからPCのFlashがなくなった時も「まあ、しばらく待てば同じようなオーサリング環境は、もっとオープンでアクセシビリティに対応した形で出現するんだろう」と高をくくっていた。

……いくら待ってもでなかった。というか未だに出ていない。

ある日突然、クライアントの頭からFlashという「概念」が消失したみたいに、Webサイトに求められるのは「そこ」ではなくなったからだった。

確かにWebサイトのアニメーションを調整するのに1日かけるぐらいなら、その時間で、聞いたこともないAndroidの機種に対応して、一人でも多くの人がWebサイトをピンチインして見なくてすむようにしたほうが有益かもしれない。それはそれで、とても正しい判断だと思う。だけども、WebGLでゴリゴリに演出されたようなWebサイトがここまで珍しくなるとは予想外だった。それを必要だと思う人が、こんなにも少なかったんだ、という驚きが今でもある。

その驚きの正体は、自分たちが参加していたゲームのルールが、そもそも幻想だったと気づいた時のそれに近い。私たちは顧客の要望に応えているつもりで、実は同業者との「こだわりチキンレース」に夢中になっていただけだったのかもしれない。

どれだけ滑らかなイージングを実装するか。どれだけ斬新なインターフェースを編み出すか。ライバルサイトのモーショングラフィックスを見ては、「次はもっとすごいのを作ってやる」と夜を徹して、それは職人のプライドであり、作り手としての純粋な喜びだった。だが、ゴールテープを切った先に、顧客はいない。彼らは、レースコースの遥か手前で、もっと別のものを――例えば、スマートフォンの小さな画面でも文字が読める、というような――待っていただけなのだ。

そして、最も残酷で示唆に富む事実は、iPhoneという黒船によってレースが強制中断された時、誰もそれを再開しようとはしなかったことだ。あれほど熱狂していたはずのFlasherたちも、クライアントも、まるでそんなレースなど存在しなかったかのように、口笛を吹きながら別の道を歩き始めた。

これは、ビジネスというものが、私たちが思うよりずっと「面白くない」ことの、何よりの証明なのかもしれない。ビジネスは、クリエイターの情熱や職人のこだわりを燃料にはしない。それは、コストとリターンという、冷たく乾いた計算式で動いている。Flashという過剰なまでの表現は、その計算式の中では、真っ先に切り捨てられる要素でしかなかったのだ。

*

最近、私のようなおじさんたちと、妙齢の女性が雑談する機会があって、優しい子だったものだから、我々インターネット老人会の話に付き合わせてしまった。

インターネットを最初に見たのはいつだったか？という話になった。

彼女は「6歳ぐらいの時ですね」と礼儀正しく答えた。

私たちが嘆息していると、誰かがさらに尋ねた「どういうサイトを見ていたの？」

「マクドナルドかピザーラか、なんかそういうページを見てて、そこにあったFlashゲームをずっとしてました」

と何気なく答えた。

そういえば、自分もお菓子メーカーのホームページにFlashゲームを納品したことがあったなあ、と私は思い出した。予算より工数をかけて叱られた案件で、本当に楽しい仕事だったのでよく覚えていた。

「思い出すと、またやりたくなりますね」

と彼女は付け加えた。

私たちが走っていたチキンレースにも、案外、観客はちゃんといたのかもしれない。

チキチキマシン猛レース コレクターズボックス [DVD]

プロジェクト炎上のこころ

炎上しているプロジェクトで、タスクが溢れて捌ききれません。優先順位の付け方や効率的なタスク管理術を教えてください！

おやおや、今日のお客さんは随分差し迫った様子だね。シャツの裾が燃えてるんじゃないかっていうぐらい、焦げくさい匂いがするよ。

まずは落ち着こう (Don't Panic)、君がやるべきことは、そこに座って、ネクタイを緩めることだ。コーヒーはどうだい？紅茶はフォションのアッサムなら用意できる。これはちょっと渋い茶葉なんだけど、ミルクを入れると丁度良い案配なんだ―――
焦らない焦らない。気持ちはわかるけどね。えっと、なんだっけ優先順位とタスク管理だっけ？それも大事だけど、まずは君が落ち着くこと、これが一番必要なんだよ。わかってるわかってる、こちとら長く生きてる分、君なんかより何倍も炎上現場の場数を踏んでるんだ。そういう僕が大丈夫って言ってるんだから、問題ないんだよ。まずは、そのソファーに座って、僕の話を聞いてくれるかな？ほらホットミルクティーを淹れたよ。

*

昔、同じような状況にいたことがあってね。僕の参画してるプロジェクトじゃないんだが、チケットシステムや日報を見れば大体の状況はわかる、って奴さ。帳票システムのマイルストーンがどんどんスケジュールの奥に追いやられててね、こりゃマズいんじゃないか、って思って人づてで状況を聞いたんだよ。
デザイン案と全然違うから修正、っていうチケットが山ほどあってね。なんだこりゃ、って思ってみたらひっくり返ったよ。デザインがIllustratorで作られてたんだ。信じられるかい？JavaでIllustratorで作られたテンプレートを禁則処理付きでPDF帳票できるエンジンがあるんなら、是非とも欲しいし、何なら外販しても売れるレベルの話だよ。

もちろんそんなものは存在しない。存在しないから、哀れな新人プログラマーはせっせとドット単位で文字位置をプログラミングしてた。こんなチケットが100個はあったんじゃないかな。さらにひどかったのは、PMが帳票エンジンの遅れをタスク管理の問題にすり替えてたことだよ。PMはこの状況で何をしていたと思う？チケットの消化を時間単位で区切って、新人プログラマーたちのその日の予定に次々と放り込んでいた。10:00～13:00までに#219の修正、13:30～16:00までに#242の修正って具合にね。

そう！マイクロマネジメントだよ！さすがの僕も腹に据えかねて、ほうぼうに今すぐ止めたほうがいいと触れ回ったけど、外部チームの人間にはどうにもならなかった。
結局、納期にいたっても帳票エンジンは未完成、新人プログラマー君は体調不良で休職、PMは事実上クビになったよ。

――悲しい話だろう？ でも、これは炎上現場でよく起きることなんだ。PMは『管理』という幻想にすがり、プログラマーは『実現不可能』という壁に頭を打ちつけ続ける。僕に言わせれば両者とも、見るべきものを見ていないんだ。

じゃあ、何を見るべきなのか。

優先順位？ タスク管理？ それも大事だ。でも、火事場で一番最初に確認すべきは、そんな小難しいことじゃない。『どこが一番、人の心をかき乱しているか』だ。燃えているのはプロジェクトのスケジュールだけじゃない。顧客の、そしてチームの『心理状態』なんだよ。

*

僕が途中から放り込まれた、別の炎上プロジェクトの話をしようか。そこでも状況は最悪だった。コアチームはバグのモグラ叩きに追われ、僕みたいな途中参画のプログラマーに構っている暇はないみたいで、返事もロクに帰って来ない。正直、僕にできることなんて何もないように思えた。

そこで僕は、プロジェクトから一歩引いて、棒立ちになっている営業に声を掛けたんだ。『今一番目立っている問題は何だろう？』ってね…

営業は「全てだ」と言いすてて、頭を振った。
それでも、僕はさらに食い下がった
「最近、エンドクライアント（顧客）が一際怒った出来事があったと思うんだけど、それは何だった？」という具合にね。

そしたら営業ははっとして「それなら1ヶ月前から修正要望が出てるUI修正の進捗がなかったことだね、あれについてはずいぶん絞られたよ」と言ったんだ。
これだって思ったね。そりゃコア部分で、問題が多発してる状況で、UIを直してる暇なんてないだろうけど、顧客から見えるのはUIだから、ある意味ではそのUI修正の遅れが炎上プロジェクトの象徴になっていたんだ。

あと、UIってのは普通のフレームワークを使っていればある程度コアロジックからは分離できてるものだから、こちらで問題修正する分にはコアチームとのコミュニケーションの手数は最小限になるだろう、という目算もあった。

僕はバグトラックシステムを見回して、コアに関わらない、UIだけの修正でなんとかなるような、バグチケットをいくつか取りだして、コアチームに向かってこう宣言した「こちらのブランチでこのUI修正のチケットを直しておく。コアの修正で僕の修正が無効になるのを、僕は全然気にしないし、できる限りすぐに追従する。もし僕の修正でコアの修正がプレビューできないようなら、こちらのブランチを無視してくれても構わない。ブランチをマージするタイミングもそちらに完全に任せる」という具合にね。

コアチームからは、正直いい反応はなかったけど、コア部分の修正に僕をオンボーディングさせるためのリソースも時間もないのは明かだったから、最終的には「途中で放り込まれた以上、僕も仕事をしてるポーズは見せる必要があるんだよ」という言葉でOKを貰えた。

僕がやろうとしていることが、わかるかい？
コアチームは必死で火元を探している。でも、顧客は『玄関のドアノブが1ヶ月も壊れたままだ！』と叫んでいる。

そこで、僕はドアノブを直しに行ったということさ。ピカピカの真鍮製のに付け替えてやったんだ。コアチームは『何を遊んでいるんだ』という顔をしていたけどね。でも、それでいいんだ。僕は彼らにこう言ったのさ。『これは僕と、このドアノブに文句を言ってるお客様との間の問題だ。君たちは安心して家の中の火を消してくれ』ってね。

そこからはシンプルな話で、僕は修正する、変更がJSやHTMLやCSSに留まってる限りはマージしてもらえたから、画面は次々と最新「仕様」に変わっていく、そうやって、焦点の問題を僕はコアチームの作業から引き剥がして、UI調整屋の僕と顧客の問題にすり替えていった。そしたら顧客側のコアチームに対するプレッシャーも実際に減っていったんだ。

最終的に納期時点でフル機能の実装までは届かなかったんだけど、少なくとも最後の2週間ぐらいは、コアチームは立て直した体制で作業できたんじゃないかな、と思うよ。最後までお礼は言われなかったけどね！（正確には、僕を呼んでくれたコアチームの会社の役員からは感謝されたよ。「炎上プロジェクトに役員である自分が手を打った」部分の実績としては十分だったからね！）

この話における教訓はこうだ。
プロジェクトにおける仕事ってのは、コードを書くことだけじゃない。誰かの『心配事』を引き受けてやることでもあるんだ。たとえそれが、技術的には些細なドアノブの交換だったとしても、だれかの心を鎮めることができるなら、それは立派な鎮火活動なんだよ

*

さて、僕の長い話もそろそろ終わりだ。どうだい？君のシャツの裾で燻っていた火は、少しは落ち着いたかな。ホットミルクティーも、もうすっかり冷めてしまっただろう。

君が今すぐやるべきことは、分厚い仕様書や、真っ赤に染まったガントチャートを睨みつけることじゃない。JIRAやBacklogの画面を一旦閉じて、人の顔を見ることだ。

そして、君のプロジェクトの『ドアノブ』はどこにあるかを探すんだ。
顧客が、あるいは上司が、一番顔を曇らせている些細なこと。チームが見て見ぬふりをしている、でもずっと心のどこかで引っかかっている小さなトゲ。
それを見つけて、君が引き抜いてやるんだ。

それは君のヒーロー願望を満たすような、派手な仕事じゃないかもしれない。誰にも感謝されないかもしれない。
でも、その小さな一手で、確実に空気は変わる。チームに呼吸するだけの、ほんのわずかな隙間が生まれる。炎上時の優先順位やタスク管理ってのは、そういう隙間をつくる目的でやるべきなんだ。

そのためには、まずは、君自身がパニックから抜け出すこと。そして、誰かの『心配事』を引き受けること。
それができれば、君はもう立派な火消しのプロさ。

…おっと、もうこんな時間か。じゃあ、頑張ってくれよ。それじゃ―――

吉原炎上

潰れたほうがいいようなマイナーなサービスと世界の守護者

CRMならSalesforce、勤怠管理ならfreee、在庫管理ならスマレジ。SaaSの世界にも代表選手はいて、その機能や安定性を思えばリーズナブルな価格で提供されている。それでなくとも、業界5位ぐらいまではそこそこ使いやすく、よくメンテナンスされたサービスを使える時代だ。

だが、どこにでも光が当たらない場所があるように、地図に載らない村があって、忘れられたサービスが存在する。数社しか使っていない受発注システム、特定の業界のニッチな慣習のためだけに作られた顧客管理ツールのことだ。

それらは総じて使いづらく、最近のサービスが当然のようにサポートしている機能が存在しないことも多々あって、めっぽう、古くさい。もしあなたが、古いmac osのaquaテーマや*1、Tableタグの二重線を見たいと願ったなら、きっとこれらのサービスが要望に応えてくれるだろう。

なぜ、そんなサービスが存在し続けるのか。

一つは、ユーザーである中小企業の「業務フローが硬直化している」からだ。新しい担当者が聖域に踏み込むような決断をしない限り、昨日と同じ今日が繰り返される。そして、その種の決断ができる人間は、そもそもそんな会社にはいない。この世界では、変化はリスクであり、停滞は安定なのである。

もう一つは、そこで奇妙な「均衡」が成り立っていることだ。このようなマイナーなサービスを維持する事業者にスケールメリットは存在しないのだが、その分システム運用コストは抑えられている（なにしろバージョンアップも何もしないことにしているシステムなのだ）。問題は使う側だが、事務員の手数が数十手増えたところで、そんなコストは全体予算にかき消されてしまう。サービスを維持するための僅かなコストと、非効率な業務が生み出す見えない損失。その天秤が、絶妙なバランスで釣り合ってしまっている。
彼らも「業務プロセスの硬直化そのものがサンクコストで、リスクだ」という、お題目を知らないわけではないが、だからといって何か手を打てるわけではないので、知らないと同じことなのだ。

では、その安泰な村のインフラを、誰が守っているのか。

答えは僕だ。「いけてるサービスを作る側に回れなかった」人間だ。

景気が良くなれば、腕のいいエンジニアはもっと輝ける場所へと去っていく。後に残されるのは、誰も触りたがらないレガシーシステムと、何かを諦めた顔をした営業担当者だ。そのシステムは市場をぐるぐる回り、やがて僕のような「ゴミ拾いのエンジニア」の元にやってくるというわけだ。
ついこの間も、そういったシステムのパフォーマンス問題を解決した。slow_queryログを有効にして、書き出されたクエリをコピペしてEXPLAINした結果をAIに読み込ませるだけの簡単なお仕事だ。いくつかのどう考えても必要なINDEXを張っただけで、前の画面に戻るためにユーザーが待機する時間は平均10秒から2秒まで短縮した。みんな、感謝して欲しい。そもそも前の画面に戻る度に再フェッチする必要があるのかと言われれば、どう考えてもないんだけどな。
僕のような場末のエンジニアは、ガラスの上から落っこちてきた、そういう仕事で食い繋ぐしかない。これは使命感でもなければ、職人技への誇りでもない。ただのババ抜きだと感じている。

さて、こうした「作業」をやっていると、自分がやっていることは、果たして「正しい」のだろうか、というナイーブな考えが浮かぶ、このサービスがもし明日「死んだ」ら、どうなるんだろう？

どう考えても、長期的に見れば、その死は「善」だ。

ユーザー企業は数ヶ月の混乱の末に、業務の変革を迫られるだろう。硬直化は終わり、淀みには流れが生まれる。ステークホルダー達が、一丸になって取り組むことで、不必要なプロセスは抹消され、事務員は快適なReactフロントエンドを画面を操って定時に帰れるようになる。それは彼らにとって、ささやかだが確実な前進の筈だ。つまるところ、僕が延命させているのは、彼らの未来を蝕む小さな病巣に他ならない。

困るのは、仕事を失う僕だけだろう。いや、ババ抜きのカードが一つ消えるだけなのだから、僕ですら困らないのかもしれない。
ならば、僕がやった仕事の価値とは一体何なのだろう。 日々の労働は、小さな悪を存続させ、大いなる善の到来を遅らせるためだけにある。
これこそが、「マイナーなサービスを保守する空しさ」の正体だ。価値が不在であること。むしろ、価値がマイナスであることに加担しているという、静かな虚無感がある。

ただ、ここまで書いた上で自分が、エンジニアの陥穽の一つに落ちてることがわかった。今作った格言を聞いてほしい「技術的に可能は不可能」だ。

例えばクライアントがSalesforceに移行することにしたとする、社長がゴルフの最中に、DXとはSalesforceのことだと聞きかじったせいだ。僕らが愛した薄いMySQLラッパーシステムは僕ごと放棄され、様々な業務を厳格なフローで制御するプロジェクトが始まる。

会議室に集められた各担当者はなぜか最初から怒っている。余計な仕事を増やすな、という態度が椅子の座り方から伝わってきて、哀れなセールスマネージャーは愛想笑いを浮かべるしかない。Excelと内線電話と、どこかに眠っていたOracleデータベースシステムのCSV出力との突合が始まり、会計士は絶句する。

システムは無事に完成するかもしれないし、完成しないかもしれない、あるいは完成したことにされるかもしれない。後に残るのは、絶対に後戻りができない、承認ボタンの順方向フローと、社長が滅多に開くことのない奇怪なダッシュボードだけだ、ということになるのかもしれない。

もちろん上手くやる方法はある、バラ色の未来は「技術的には可能」だ。しかし、そのための人的リソースと予算が、簡単に見いだせないのも事実で、中途半端にやれば今より状況が悪化することだって十分にあり得る、というわけだ。

そう考えると、僕のような「ババ抜きの敗者」の役割も変わってくる。

僕は、単に古いシステムの延命に加担しているのではない。来るべき「審判の日」を、破滅的なカタストロフィを、か細い指で必死に先延ばしにしている存在なのではないか。

もしそうなら、この無価値に見える労働にも、ダムの決壊を遅らせるような、悲壮な「正当性」が生まれる。 だが、問題は、そのダムがどれほど巨大で、亀裂がどれほど深刻なのかを、誰も知らないことだ。
なにしろ変革のコストを見積もる人間が、どこにもいないのだ。皆、自分が毎日何を保守しているのか、その本当の意味を理解しないまま作業を続けている。

先延ばしにしているのは、数ヶ月の業務混乱か、それとも会社の倒産か。

さらに論理を飛躍させると、 「審判の日」を待ちながら、その日を先延ばしにするためにだけ存在するシステム。それは、目の前のマイナーなサービスだけの話だろうか？ 老朽化した社会インフラ、複雑怪奇な金融システム、社内政治と慣習だけで回る大企業、少子高齢化という名の国家レベルの技術的負債。この世界全体が、いつか必ず訪れるカタストロフィを、無数の「保守作業」によって先延ばしにしているだけなのではないか。

そう考えると、僕たちが対峙しているのは、単なるjQueryのコードではない。世界の縮図だ。 僕の空しさは、個人的なものではなく、この世界の構造的な空しさそのものなのだ。審判の日が来るまで、僕は自分が何をしているのかもわからぬまま、キーボードを叩き続けるし、それは特段、僕に限った話ではないのかもしれない。

そこまで考て、ようやく僕は、このレガシーシステムの厳かな画面遷移を、PHPコードを愛おしく感じることができるのだった。

SaaS時代のDX――一流企業の働き方

*1:https://x.com/DOGE/status/1890593889314038216