xDD(〇〇駆動開発)アンチパターン
最近、チームで非常に有益な振り返りと向き直りを行えた。やはり定期的にこれまでの道程にあった楽しかったこと、辛かったことを見つめ直すことはより良い未来を考えるうえで必要なことなのだと強く実感する。
そういった文脈で、そういえばこんなこともあったな程度の温度感で「僕の開発体制失敗談」を振り返っておきたい。自戒として、二度とこれらのアンチパターンにハマらないよう気をつけていきたいのだ。そして何かしらの形でこれを見るあなたの助けになれば幸いだ。
1. 肩書き駆動開発
中長期的なプロジェクトに参画していると、しばしば「鶴の一声」というゲリライベントに遭遇することがある。そもそも鶴の一声という言葉の由来は、周囲の動物や人を驚かせるほどに鶴の鳴き声が大きいということにあるらしい。つまり、鶴の一声には迫力があるのだ。これは正に一般的に言われる鶴の一声という言葉と合致している。何か力を持つ人がたった一言の迫力で物事をひっくり返し、前進させたり後退させたりする。
鶴の一声は、プロジェクトが停滞している状況を打破するようなものであればとてもいいものである。現実的な方針を指し示し、皆の視点を揃える目的で叫ばれた声であれば、その声は美声と呼べる。しかし現場では、なかなかそんないい鶴には出会えない。
さらに問題なのが、鶴が一羽でない場合だ。二羽以上の鶴がいる場合、現場の人間はどの鶴がより大きな声を出すのかを即座に判断しなければならない。つまりどちらの肩書きが強いのか、そしてその鶴は番いなのか否か。場合によっては二羽の鶴の間を取り持つ案を考えなければならないし、最悪のケースでは鶴同士の喧嘩に巻き込まれてしまう。そうなってしまえば我々小さきものは萎縮し何もできなくなるだろう。最近はてな界隈でバズっていた「メテオフォール型開発」もこの状況をよく示している言葉だと思う。
エンジニアを美化するつもりも卑下するつもりもないが、エンジニアは他の職種以上に「正しさ」にこだわるきらいがある。今何をするのが最も効率的で本当に必要なものはどんなものなのか。我々はそれを出来るだけ明らかにし、納得したい生き物なのだ。そんな我々にとって、「何を言ったか」ではなく「誰が言ったか」ドリブンで開発を進めざるを得ない状況は非常に大きいストレスとなる。肩書き駆動開発がもたらすものは疲弊と破滅、世界の崩壊だ。
とはいえ、たかが鶴ごときの迫力に負けてその声に盲目的に従うエンジニア自身にも責任がある。鶴といっても鳩ぽっぽと同族なのであるから、最悪耳栓をするか、自身がより大きな声を出して追い払ってしまえばいい。過去、僕は正に肩書きと迫力に動かされてしまった。丁度先日、前職の先輩とお会いした時も「お前は意外にも真面目すぎる」としみじみ言われ、当時のことを鮮明に思い出させられた。
僕はもっと、鶴とうまくやるべきだった。鶴が大きな声を出す前に静かな会話をする機会を持つなり、他の餌を与えて溜飲を下ろさせるなり、より強い鶴を連れてきて喧嘩させるなり、味方の方の鶴に守ってもらうなり、幾つか僕にも取れる手段があったのは確かだ。今思えば、あの程度の鶴の一声に驚き騒ぎ回るなど愚かの極みだ。次このようなことがあれば、もっと平和的な解決を目指したい。そして肩書きに踊らされず、僕自身の目と耳でその声の正しさを見極めたい。ときには僕自身が鶴になって戦うことも必要だと、今なら思える。
2. 妄想駆動開発
「これを開発すれば三億の金が稼げる」と夢のような話からプロジェクトがスタートすることがある。具体的な金額的目標と、その仮説を持つこと自体は非常にいいことだ。しかし、その夢のような話が実現可能なものなのか、はたまた非現実的な妄想にすぎないものなのかは冷静に見極める必要がある。
妄想駆動開発がもたらすものは「なんで今それやってんの？」という冷たい視線のストレスと「やっぱり次はあれを作ろう！」という無計画な思いつきの連鎖反応、即ち破滅と世界の崩壊だ。
いくらデータを集めたところで確実に成功するビジネスなどない。市場の変化、大手の参入、既得権益の壁、社会的規制の壁など限りなく想定不可能に近い要因があるのだから仕方ない。しかし、仮説は検証してこそ意味がある。検証とは、事実と仮説の乖離、または仮説の正当性を確かめることを言う。検証しない仮説など、夢とも理想とも呼べない単なる妄想にすぎない。夢や理想、理念に共感して行動することと、妄想に付き合うことは違う。
我々エンジニアは無駄を最も嫌う人種のはずだ。提示されたデータ、社会の現状、それなりに根拠のあるように見える仮説。例えそれが自分の仮説であろうと、自らの時間を無駄にしたくないのであれば一度全てを疑うべきなのだ。それでも可能性を感じるのであれば、シリコンバレーのようにリーンにMVPを確認しながらマイクロに仮説検証をしていけばよい。
ハーメルン現象
妄想駆動開発現場によく見られるのがハーメルン現象である。ハーメルンの笛吹き男は、ハーメルンの人々に害獣駆除の仕事を依頼され、安請け合いをしてしまった。笛吹き男パイド・パイパーは結果的に仕事を成功させる。しかしクライアント、つまりハーメルンの人々は笛吹き男に報酬を払うのを渋ってしまう。このことに憤慨した笛吹き男は、笛を吹くことで村の子供、つまり未来を連れ去る復讐を為した。
この話は昨今のIT業界では本当によくある話になっている。まず入社時点の説明と入社してからの勤務実態、ビジョンと実績が異なる場合。これはまさしくハーメルンの人々がパイド・パイパーを騙したことに当てはまる。するとパイドパイパーは何をするか。他の就職先を探しつつ、今いるメンバーの中で優秀な人材も連れて行こうとするのである。当然だ、優秀な人材は正当な評価を受けられる場所を求めている。パイド・パイパーに正当な報酬を与えなければ、彼らは未来を奪っていく。このことを企業は肝に銘じるべきである。
この寓話から我々エンジニアが学ぶべきことは、第一にハーメルンの人々が確かに報酬をくれるのか見極めなければならないということである。第二に、自らの中で確信を得て仕事を始めたのであれば、常に裏切られないよう警戒をしなければならないことも挙げられる。そして第三に、それでも裏切られた場合、我々には人材を引き抜き独立するという大層残忍な報復方法を所持していることを忘れてはならない。
とはいえ、我々はエンジニアは出来る限り笛吹き男パイド・パイパーになってはならない。妄想駆動開発においても、その妄想を妄想でないと自身で断じたのならば、責任は自身にある。全てを人に押し付けて「だからやめろと言ったのに」などとは口が裂けても言うべきでない。自らを棚に上げて人の未来を奪うことはこの世で最も忌むべき罪の一つだ。
3. 自我駆動開発
エンジニアは、エゴドリブンに仕事をしたがる。新しい技術を試したい、自身のスキルアップを優先したい等のバイアスから、本来ならば簡単な仕事をわざわざ大変な仕事に変えてしまうことがよくある。自身はそれでいいのかもしれない。しかし未来の後輩エンジニアや保守担当は貴様のコードを見て死ぬ。即ちこれもまた世界の破滅をもたらす開発と言える。
破滅主義でもない以上、案件には適切なアーキテクチャを選定しよう。単純なRESTAPIを作るのにフルスタックなフレームワークは必要ないし、短期的なサービスでクオリティよりもスピードが求められているのであればドキュメントの精度はある程度犠牲にしてよい場合もある。また、近々自身の部署移動やドメイン知識が豊富な人間が抜ける予定があるのであれば、アーキテクチャの選定の前に運用計画を改善する提案をするのが先である。
言語やツール、FWは日々進化しておりそれに触れていないと他のエンジニアから遅れをとっているような気がする。それは非常にわかる。しかし、その漠然とした不安から負債を未来に残してはならない。極端な例で言えば、自分しか書けない状況でホワイトスペースという言語をドキュメントなしで業務に利用するようなことはあってはならない。
エンジニアが新技術を取り入れるのは、エゴではなく効率化を目的としなければならない。自身の市場価値を上げたいだとか言語に飽きただとかスキルアップの実感が欲しいとか、それはあなた自身にとっては非常に重要な事柄ではあるが、あなたに給与を支払っている側からすれば時には自分勝手な行為と見られかねない。
新技術を取り入れるのであれば本当に今それが必要なのかしっかりとタイミングを見るべきだ。そして何より、その有用性を周囲に説明し合意を得ておくことが自身を守る最強の証拠となる。
4. 気合い駆動開発
エンジニアは正直、基本的にどこかで手を抜いている。それは営業や事務でも同じことであるとは思うが、本気を出せば1日で終わることであっても二、三日の工数を読んでおきたいことが多い。それはセルフマネジメントという観点と、緊急の案件が舞い込んできた際のバッファというリスクヘッジの側面がある。これらは決して悪いことではない。
一方で、一定数のエンジニアは本当にギリギリの工数読みをする。限界まで頑張ったとしても何か問題が一つでも起これば破綻する計画を立てようとする。これは愚かだ。製品が完成すると想定してスケジュールを立てていた他の仲間に迷惑をかけることになるし、そのせいで結局破談になり世界も崩壊するだろう。
気合いがあることはいいことだ。しかし気合い駆動で開発をしてはならない。冗談でなく人死が出る。あなたはその責任をとれるのか。取れるわけがない。気合いで全てがうまくいくのであれば計画など最初から必要ない。気合い駆動をするのであれば無計画に突っ走る方がまだ生存確率は高いだろう。
5. お友達駆動開発
これはある程度しょうがないことではあるのだが、チームで働いているとチームメンバーの馴れ合いというか行き過ぎたお友達化が進行してしまうことがある。この開発は決して悪いことばかりではなく、仲間の為にがんばろうというモチベーションを獲得できたり、円滑なコミュニケーションが取れたりする利点はある。
しかし、人間関係は距離が近すぎると結局破綻を迎える。そして、世界は崩壊する。私はこのようなお友達駆動開発体制を作り上げてしまったことがあり、チームも自身の心も破綻させた。最終的にオフィスで首をくくる寸前まで追い詰められたのも今ではいい思い出である(そんなわけない)。ビジネスの関係は友達関係とは違う。越えてはならない一線のようなものは用意しておくととても優しい世界になる。一部、それでもその線を越えたいと思える人がいたのなら、それはとても幸運なことだから大切にしていこう。
6. 感情駆動開発
仕事をしている人は、大抵プライドを持っている。彼らのプライドは彼らの仕事の支柱になっていることも多く、それ自体は素晴らしいことだ。しかし、そのプライドを元に開発を進めてしまうと感情駆動の開発になり君は死ぬ。
古いやり方、今までうまくいっていたやり方、暗黙の独自ルール、そういったものを全て守り続ける必要などはない。世界や文化は保護するものではなく、改変していくべきものである。そのルール、やり方は本当に今もなお守り続けるべきものなのか。我々は利用者やプライドの保持者と一丸となってこのことを議論すべきだ。この議論を飛ばしてしまうと、感情や慣習に引きずられて不必要な機能を追加してしまったり、せっかく作ったものがユーザーの感情的要因により利用されなくなったりしてしまう。
人間には感情があってしかるべきである。しかし感情は業務という場において負の作用をもたらしてしまうことがある。我々はどちらの感情も尊重しつつ、最大多数の最大幸福を目指し歩み寄る姿勢を見せるべきなのである。私のおすすめは、製作者と利用者の顔を見せ合う場を設けることである。人は顔の見えない人なら簡単に批判できてしまう。しかし知り合いを批判するのは気が引ける。そういった心理学的なテクニックによって感情の軋轢を最小にとどめる努力をしていこう。
おわりに
私は現状、上司やチームに非常に感謝している。私事により、今の私は完全にお荷物状態というか不安定な状況に陥っている。誰の役にも立てない、プライベートでもパートナーの足を引っ張ってばかりで、悔しさに鳴咽する日々が続いている。それでも皆が優しくしてくれていて、どうにか私を社会と繋いでいてくれようとしていて。変な言葉のようになってしまうが、なんというか彼らに対し愛がある。そしてそんな彼らの役に立てず、何者にもなれない自分自身に本当に嫌気がさす。
今度のチームは、いいチームだ。先述したような悲惨な開発体制には決して陥らないよう自戒して終わりたい。
