限りなく透明に近いおぢ

最近死に支度をしている。具体的にいつ、というのがあるわけではないが、もう46歳だし、飼っていた猫は死ぬし、やることもないし、死に支度は早いに越したことはないという話だから。

死についての遠藤周作の本に、「老年に達すればあとは邪魔をしないように生きれば良い」というのがあって、確かにな、と思った。例えばWebエンジニアたちが技術記事を書かなくなって、今やネットにはAIエージェントの効果的な使い方しかない。もうあの言語が良い、フレームワークが良い、あれは時代遅れ、これは革新的、という話もなくなって、今や素PHPで新規プロジェクトを立ち上げても、このほうがAIの通りが良いんですよ、と言えば、誰も文句を言わないじゃないかとすら思う。みんな誰かの邪魔をしない生き方をするようになった。その点では良かったと、わりと本気で思っている。

とにかく死にまつわることばかり考えているので、Webプログラマの死についても考えている。僕たちは老境に差し掛かったプログラマというモデルケースに出会ったことがなくて、単に年老いたプログラマがCOBOLかCの流儀でWebプログラミングに挑んで、わけのわからないPHPコンパイルオプションをいじくり出すのしか見ていないから、なんというか、あまり参考になるものがないんだけど、とりあえずどんどん透明になっていけばいい、というのはわかる。

道に転がってる石とか、そういうものを黙って拾ったり、困ってる人がいたら手を取って、自力で歩けるようになったら手を離す。誰にも気づかれないように、ただひたすら川の流れを遮らないように生きればいいのだと思っている。具体的に業務に当てはめて考えれば、仕様書を覚えて、認識の間違いをそれとなく指摘したり、心配性のPMに寄り添ったり、彼が上司に出す対策案の叩きを作ったり、といったところで、これはこれで心地良い生き方なのだ、ということが最近わかってきた気がする。

問題はそういう生き方をしても誰もお金をくれないということだ。何しろ透明だから、そこに金を払うという習慣が日本人にないのだ。思えば僕は昔からこれぐらいの役割で、とびきり難しい問題だったり、行き詰まっている問題に解答を出してきたつもりで、例えば、前のブログで「パフォーマンスの悪化したアプリのMySQL slow　queryログを出して、インデックスを作ったりプロシージャを作り替えて速くするみたいな業務をやってるけど、ゴミ拾いしかさせて貰えてない」みたいなことを書いたときに、そんなわけねーだろ、みたいなツッコミをした人がいたけど、本当にゴミ拾いしかさせて貰えてねえんだよね。あの後ミーティングがあって、MySQL何もわからないマンに一から説明して、その分のギャラも一円も貰ってないわけだから。今後ともよろしくお願いします、って満面の笑みを浮かべて、それっきり話も来ない。
金を貰えるのは出来る出来ない関係なく伴走してる若者だけで、まあ彼らには金を貰う権利があって、金が有限なんだったら、僕らの取り分がなくても仕方ない話。

いかんね、俗っぽいところが出ちゃったね。こういう金を貰えなかった、認めてくれなかった恨みみたいなものだけはまだマグマみたいに貯まってる。恐ろしいことだと思う。きっとこれからの年月こういうのを全部許して、忘れて、ということに時間を使わないといけないんだろうと思う。何しろ悪いのは僕で、世界はあるがままにあるだけなんだから。

死について考える (光文社文庫)

今はもう遠い昔。あの雲のむこうには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の画面を一旦閉じて、人の顔を見ることだ。

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

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

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

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

吉原炎上