運用中のプロダクトに新機能を追加するとき、エンジニアはまず相談を受けるはずです。

モダンなチームなら リーンスタートアップ や スクラム を駆使することで効率的にハックできますが、すべてのエンジニアがそんな環境にいるわけではありません。

これはエンジニア発想でチームをより健全にする、非エンジニア向けのテキストです。

悪魔との取引

エンジニアが拒んだ機能を強制的に実装したり、十分な相談もなく理解のない人だけで機能を決定することは、まさに悪魔との取引です。

その悪魔はあなたにとって甘い蜜をもたらします。しかし組織を疲弊させ、取引を忘れたころに重い足枷で束縛してきます。

モダンなチームならそんな危険な取引はしないと信じていますが、なぜ危険なのかは知っておくべきです。

では始めます。

プログラムの作り方は 1 つではない

プログラムをよく知らないとしたら、あることを実現するためのプログラムは 1 つのパターンしかないと思うかもしれません。

そんなことはありません。

世界中のエンジニアが今でも、もっと良い、もっと正しい作り方を模索しています。

プログラムとその他の製品との違い

ハンバーガーやワイシャツ、歯ブラシやヘッドフォンとの大きな違いは分かりますか？

形があるかないか、それも確かな違いです。

しかしチームにとっての明らかな違いは 作って終わりではなく変更し続けるもの ということです。

いいプログラムとは変更しやすいプログラム

ある機能を変更したいとします。

するとエンジニアが「その変更はできない」と言います。

でも大抵の場合、その変更は 技術的には できます。

もしくは、あなたの考えている 2 ~ 3 倍の工数でもよければ できます。

だからこそその変更が無駄に終わらないように リーンスタートアップ を実践すべきですが、ここではその話はやめておきます。

もしもこのような不毛なやりとりが続いているとしたら、そのプロジェクトは次の課題を抱えているかも知れません。

変化に耐久できないコード

レガシーなコードや突貫で書いたコードによくあるのが 変化に耐久できない状態 です。

どんなプログラムが変化に耐久できないかというと、こんなプログラムがよくあります。

単機能が密に絡み合っていて、全体が奇跡のバランスでなんとか動いている。
似通った機能をコピーアンドペーストで複製し続けていて、変更箇所が無数に増えている。
テストコード( テストを自動化するコード )が書かれていないので、正しい仕様が誰にも分からない。

このような状態のことを 技術的負債が貯まった状態 などと言います。

技術的負債は会社の負債

プログラムによって利益を得ているすべての企業にとって、技術的負債は実際に負債です。

なぜならば、プログラムを更新して利益向上を図るプロジェクトが、次第に長期化し、ことごとく遅延し、バグを生み、事業機会を逃す可能性を限りなく高め続けるからです。

エンジニアにとっても、技術的負債を放置し続けたプログラムを改変するという行為は、大きな精神的苦痛と体力的苦痛を伴います。そんな行為を強制されるとしたら、優秀なエンジニアは集まりません。

だから、技術的負債を減らして( =返済して )、変更しやすい いいプログラム を作る必要があります。

エンジニアが技術的負債の話を持ち出したら、それを聞き入れてください。

技術的負債から目を逸らすことは、会社に無断で会社名義の借金をしていることと同じです。

変更しやすいプログラムとは

端的に言えば、抽象化 されたプログラムです。

抽象化とは

ある1つの機能のことだけを考えるのではなく、その機能の上位概念を考えるということです。

その上位概念の下位にあたるものとして、当初考えていた機能を当てはめます。

なぜそのような面倒くさい工程を踏むのか、それは当然、こうすることが 技術的負債を増やさないプログラムの作り方として強力 だからです。( 他にも様々な手法があり、エンジニアはそれらを組み合わせて使います )

シチュエーションの例示

例えば、会員制のコミュニティサイトを運営しているとします。

会員のプロフィールは今までハンドルネームと写真、自己紹介だけでしたが、新たに「友だちを募集中かどうか」を表す機能を追加することになりました。

単純に考えれば、プロフィール情報に「友だちを募集している」というフラグを追加するだけで終わるでしょう。

しかしこの機能は次のように抽象化できます。

{ what } を { do } している

つまり、「仕事を募集している」という使い方や、「テーブルを探している」という使い方にも応用できます。

これはごく単純な抽象化ですが、非常に強力な抽象化でもあります。これだけで応用の幅が一気に広がることに気づくはずです。

もう少し簡単に、次のようにも抽象化できそうです。

{ want }

いま求めているものは何か、という機能になります。「友だち」や「仕事」はその中の 1 つになるでしょう。

応用の幅が広がるということは、将来の変更もしやすいことになります。

実際に変更する予定がないとしても、変更しやすい状態になっていることが重要です。¹

抽象化できない機能は将来の障害

例示したように抽象化ができれば良いですが、逆に抽象化できない機能というのは 将来の変更の障害 になります。

それこそがエンジニアが機能追加を拒む理由です。

理論上は抽象化できない機能はありませんが、どう考えても 1 つの目的しかない機能 は事実上、抽象化できない機能と言えます。

不幸なことにそれは 根本的な問題を隠蔽するための機能 だったりします。本当にそれを優先すべきですか？

これらは技術的負債となり得る機能であり、会社の借金と同義ということを思い出しましょう。

プログラムだけの話ではない

例示を見て、当初は「友だち募集中」を表示するだけの機能が、いろいろな使い方のできる機能へと昇華したことが分かりました。

この発想をエンジニアだけのものにするのは勿体無いはずです。

提案をブラッシュアップする過程にも使えるかも知れません。

悪魔を断ち切る

先述したようにプログラムは 変更し続けるもの です。

そのことを理解すれば、技術的負債から目を逸らすことがいかに邪悪な行為か、分かるはずです。

今まで悪魔と取引していたことに気づいていなかったなら、今日はそれを断ち切る第一歩としてください。

オーバースペックなほど抽象化して複雑になったプログラムや、抽象化の方法を誤った場合も技術的負債となることに注意してください。 ↩