複雑さがあなたの会社のソースコードの特徴である場合、大抵、それはいくつかの失敗の結果です。次のどれかに見覚えはありますか?
- 構想が悪いアーキテクチャ。例えば、アプリケーションコンポーネント間でデータを渡す方法。
- あり余るほどのデッドコード(もはや使われることのないコード)。
- オブジェクト指向設計や依存性の注入のような確立されたパターンを考慮することなく表現されたコード。
- リレーショナルデータベースの使われていないカラムや廃止されたテーブルのある保存データのメンテナンス状態の悪い構造。
- メンテナンスや機能拡張を行う開発者がコードを読むのを難しくする、不適切な埋め込みドキュメント。
ソフトウェア開発者たちはこのような失敗に名前を付けて、技術的負債と呼びます。このことについて話したい人はいないかもしれませんが、会社のコードが進化する時に「こうすれば」「こうであったら」「こうすべきだった」ことの累積コストは、気付かないうちに製品開発の締め付けとなるでしょう。会社ができて間もない頃は新製品の発売に数日から数週間かかっていた機能が、今では何ヶ月もの開発時間が必要になっています。
簡単さは複雑さと対になります。コードがよく整理され、論理上は最小(または、それに近い)であり、簡単に読める時に、コードは簡単さを表します。はっきりさせておくと、複雑さと簡単さは、コードベースのサイズに固有の関連を持ちません。大きなコードベース(Googleのコードベースはおよそ20億行)は複雑でない必要があり、小さなコードベースは簡単さを表していないかもしれません。
複雑さの問題
複雑さは、ソフトウェア会社の成長と収益性に対するもっとも大きな障害の1つです。開発コストは、複雑さに対して加速的に増加します。この加速的な関係が存在するのは、ソフトウェア製品が複雑になればなるほど、より多くの開発者たちがそれを拡張してメンテナンスする必要があるからです。そして、開発者の数が増えるに従い、会社のマネジャたちは複雑さがさらに増加するのを防げなくなっていきます。
それならば、なぜ多くのソフトウェア会社、大抵は、ソフトウェアの成功によって暮らしている、頭のいい勤勉な人たちは、コードベースを危険にさらす複雑さを許すのでしょうか? 複雑さのコストを認識している経営者(とより少ない個人投資家、ベンチャキャピタリスト)は少ししかいません。なぜなら、彼らは、自分たちが売っている製品の本質を理解していないからです。ソフトウェアは製品に他なりません。ソフトウェアを販売する時、実際には、とても珍しい保証で混合の製品サービスを売っています。(下記の「AかBか?」を見てください。)
ソフトウェア会社の経営者は、かつてエンジニアだった人でさえ、大部分はビジネススクールプログラムの卒業生です。彼らは、販売、マーケティング、マクロ経済学の視点からこの業界を見ます。そして、先行者利益 - または、もっと一般的に速く動く人 - が優位であるという信条によって動きます。
最初であることはよいですが、最高であることの方がよりよいでしょう。初期の検索パイオニアYahoo!は、Googleが優れたアルゴリズム、ビジネスモデル、そして、リーダシップチームでずっと後に検索マーケットに入ってきた時に、このことを発見しました。もちろん、ある時点で会社が参加するのは遅すぎることもあるでしょう。例えば、今になって、検索のGoogleのリーダシップポジションに挑戦することを考えるのは難しいでしょう。しかし、業界優位のレースはマラソンであり、スプリントではありません。トラックの最初の1、2周は、長期間の結果にほんのわずかしか影響しません。
中間管理職ができる限り早く製品を市場に出すように要求することにより、速く動く人の利益に執着すれば、会社は消滅する危険にさらされます。一方で、アジャイルのようによく誤解されて間違って実施される作業工程管理の手法は、スピードを重視するプラクティスを慣行化することによって、問題を大きくします。簡単さは静かな犠牲者です。ソフトウェア開発者たちは、大抵、会社の中でこれを現実のものとする人たちです。
もちろん、ソフトウェア会社は、まだ設計や組み立てを行なっている製品から収入を得ることはできません。しかし、投資資本と資本利益は、経営者たちがコードベースの健全さよりもリリース速度を選んだ時にもっとも危険です。複雑さのコストは、加速されたリリース日から得られるお金よりも、疑いなく重くなります。
皮肉なことに、スピードと簡単さの間の選択は誤った二分法です。簡単さの投資はスピードの投資です。簡単さはソフトウェア製品をより速く市場に出して、より効率的にメンテナンス・拡張する手段を提供します。それは知的財産の主鉱脈であり、一度失ったら、再度手に入れるのがほとんど不可能な競争上の優位性です。
ゼノンのパラドックス (あなたも?)
アキレスと亀において - 古代ギリシャ哲学のパラドックスの1つ - 俊足のアキレスは、好きなところからスタートする、どっしりとした亀を追い越さなければなりません。追いかける人は、いつも最初に追いかけられる人の出発点まで追いつかなければならず、アキレスは、亀が歩いた距離を毎回後から追いかけなければなりません。だから、少しずつリードが減っているにも関わらず、いつも亀はリードしています。
ゼノンのパラドックスは、あなたの会社も亀を追いかけているアキレスと同じである理由を説明する役に立ちます。ソースコードが複雑になると、新しいコードを追加するのが難しくなり、古いコードをデバックするのはほとんど不可能になります。簡単さと秩序に対する固有のバイアスを持つ開発者たちは、不満を持つようになります。そして、彼らは辞めます。もちろん、すべての開発者たちが辞める訳ではなく、辞めなさそうな人たちが同時に辞めます。それにも関わらず、全面的に広がる影響は大きく、あなたの会社の発展の割合は、辞職や求人リクルート、新人研修の関連コストの割合とともに減少します。
さらに、代わりの人を雇用するのは難しく、なぜならば、今日の社会的に繋がった世界では、あなたがリクルートする必要のある開発者たちのコミュニティの間で、あなたのコードの状態は原則的に公然の知識となっているからです。あなたが雇用できる範囲では、複雑なコードで仕事をしたエンジニアに払った報酬は、市場よりも高く、今までよりもさらに上がる必要があります。とりあえず、機能の追加と複雑さの段階的拡大が確実なことで、さらに多くのエンジニアが必要になります。だから、死のスパイラルが続きます。
私が働くソフトウェア会社は、複雑さの問題に直面してきました。他の多くの人たちのように、私たちがこの苦境の影響の原因をはっきりと認識したとは思いません。そして、多くの人たちと同じように、私たちはこの状況を改善しようとして、(オンショアとオフショアの両方に)アウトソーシングしました。しかし、複雑さは、アウトソーシングできない問題です。アウトソーシングは問題を悪化させるだけです。アウトソーシングと雇った人たちは、知識に群れをなし、コードの複雑さを増やす経済的な動機を持っています。
AかBか?
これを想像してください。自動車メーカ間の競争と中古車在庫の供給過多が、新車販売を抑制しています。だから、あるラグジュアリなメーカの経営者は、永遠に新しい保証という大胆な動きで応えます。シールに書かれた価格の20%の値上げのために、- 需要に対する価格の適応性の注意深い分析から導かれた割増金 - 同様の高品質の自動車だけでなく、保証期間(4、5年としましょう)を通して完全に責任を持つことを約束します。すべての定期的なメンテナンスと、将来のモデルで利用できる新しい機能を組み込むことを含みます。
2つのシナリオでこの新しい保証の利点を評価しましょう。
シナリオA : その企業の自動車はうまく設計されています。エンジニアたちは、モジュール方式とオープンアーキテクチャの恩恵を活用します。そのため、機能を追加したり、うまく作動しないコンポーネントを取り替えたりするのは、比較的、簡単です。新しい自動車の収入が20%増加するだけでなく、その企業の販売サービス部門は、今までにないほど忙しくなります。同時に、環境保護論者、政府機関、そして、運転する人たちは、継続的に改善する効率のよさと安全の機能で自動車を維持することで、その企業をほめたたえます。オーナーたちは、また、Forever Newで払ったオプション料を軽減しながら、保証期間の終わりに、自分たちの自動車の再販価格がかなり高いという事実を喜びます。このイノベーションは、すぐに勝利として告知されます。2、3年以内に他の製造業者は、自分たち自身の「forever new」を試していますが、自分たちの自動車の劣った設計、つまり、複雑さが、そのような試みを一時的なものにしています。
シナリオ B:その会社の自動車は、機能が豊富でよく機能しますが、ボンネットの中はちょっとごちゃごちゃしています。プログラムの導入は、継続するメンテナンスと機能拡張の費用を相殺するなんらかの方法をとるため、新しい自動車の販売収入は20%増加します。しかし、拡張し続けるにつれて、保証を履行する困難さと費用が段階的に増加します。Forever Newに入ってわずか2年で、これらの費用は維持できなくなります。自動車製造業者はこのオファーを撤回します。もちろん、既存の顧客に対する義務は履行しなければなりません。経営者は、ほぼ10億ドルと損失を見積もり、事業を存続するべきかという難しい決断に直面します。
今、自動車業界でForever Newは実行不可能だと指摘できます。しかし、あなたがソフトウェア会社の経営者ならば、Forever Newの保証をすでに提供していることを認識すべきです。質問は、あなたはA、それとも、Bのシナリオで事業を実行していますか、ということだけです。
常識のためのマニフェスト
これは、よりよいソフトウェア開発のためマニフェスト、もっと控えめに言えば、常識への訴えです。あなたの会社がまだ限界点を過ぎていないならば、次の処方に従ってください。これは、際立って低い開発コスト、より速い製品化までの時間、あなたの通った後に競合相手を残して、あなたの会社の将来を安全にする、維持可能な開発プロセスに到達するためのソフトウェアの複雑さを解くロードマップです。
学ぶ。複雑さを直せるのは、トップダウンからだけです。リーダーは、ソフトウェア開発製造ラインで起こるすべてのことを理解する時間を持つ必要があります。どのくらいの時間でしょうか? 製品化までの時間がコードの簡単さの次に考慮すべきことになった時に、目的を達成したことを知るでしょう。
リードする。エンジニアリングの管理をする人たちに、簡単さを強調することを徐々に教え込みましょう。そうすれば、あなたの組織は新しい価値の周りが整理されます。この手始めの戦略的な価値を伝えましょう。
再評価する。アジャイルのようなワークフローマネジメント手法が、実装スピードよりも設計の質を強調する別のアプローチよりも、本当にあなたのニーズによりよく合っているか評価しましょう。
戦略的に雇いましょう。簡単さを愛する開発者を採用しましょう。そのような人たちは、コードの保守性、実行時間、メモリ消費、そして、データストレージに関して、要求を分析し、最適なソリューションを設計するために長い時間を過ごすことを好む代わりに、実際のコードを書くためにもっとも時間がかかる人たちです。また、自分たちの作業を文書化し、同僚と知識を共有することに誇りを持っています。
知見を管理しましょう。コードの知見は、会社の生命のもとです。知見は手元に残すよりも、組織全体を通して広める必要があります。広がった知見構成を維持することは、知見の共有により多くの時間を投資することを意味します。それでも、ビジネスの変化のニーズによってエンジニアがより素早く再デプロイできるようになるでしょう。
道をしっかりと見ましょう。魅力的でますます増える技術とツールは、今、ソフトウェアを書いて、テストして、デプロイする、そして、監視するために存在します。徐々に増える利益と高い切り替えコストを与えるように、大抵、大部分は二重になっています。これらの提供物の小さな部分を賢く選びましょう。エンジニアたちがすでに知っている技術を主に検討しましょう。
進捗を測定する
あなたが雇うエンジニアの数と離職率を追跡することで、複雑さに関するあなたの会社の進捗を基準に従って評価できます。ハイテク産業以外で、エンジニアリング部門の大きさが、オンライン販売よりも速く成長しているならば、それは本当に悪いサインです。ソフトウェア会社でスタッフが急激に減っているならば、それも悪いことです。ソースコードが簡単な会社は、比較的、小さく安定したエンジニアのチームを持ちます。製品の機能が前進していても、チームはゆっくりと成長します。逆に言えば、ソフトウェアの複雑さに苦しめられている会社は、常に人を雇って、亀を追いかけるために息もつけないほどの努力をして、今までにないほど走っています。
著者について
Paul Merlyn氏は、Targetのデジタル活性化を補助するConsensus Corp.の複数の技術に精通しているエンジニアで、思想的指導者です。彼は、活発な起業家で、Fynancially(金融サービス産業を民主化するベンチャ)、Abridgソーシャルノットワーク、そして、National Mediation Training Registryの設立者です。同時に主張が強く、さらに、外交的手腕により、JavaScriptがJavaを負かして、その後、JavaScriptが世界を支配するのは確実だと信じています。