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

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

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

悪魔との取引

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

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

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

では始めます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

技術的負債は会社の負債

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

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

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

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

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

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

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

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

抽象化とは

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

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

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

シチュエーションの例示

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

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

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

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

{ what } を { do } している

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

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

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

{ want }

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

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

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

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

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

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

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

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

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

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

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

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

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

悪魔を断ち切る

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

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

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