はじめに
本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。
https://xtech.nikkei.com/atcl/nxt/column/18/01394/
有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。
- 第1回：技術的負債はなぜ生じるか。
- 第2回：ソフトウエア開発を「制御」する意外な処方箋
- 第3回：技術的負債への取り組みはなぜ「２つのDX」につながるのか。
第1回：技術的負債はなぜ生じるか。
年間12兆円ものマイナスの影響をもたらす技術的負債（あるいはレガシーシステム）はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫ります。
技術的負債とは
「技術的負債」と言う言葉は、アメリカのコンピュータ技術者であるウォード・カニンガムによって、1992年に提唱された概念です。その言葉は瞬く間に流行し、システムとビジネスを繋げる用語としてもてはやされました。彼は、経験レポートの中で次のように語っています：
最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て、即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる
この言葉はソフトウェア開発者たちを悩ませる、「徐々に複雑性が増していき機能追加が困難になっていく」という現象をうまく言い表していました。
また、「負債」という経済的なメタファーであったことも伴い、ソフトウェア開発者ではないビジネスオーナーやステークホルダーとコミュニケーションをする際にもイメージを伝えやすいと、瞬く間に認知が広がりました。現在でもソフトウェア開発の現場では日常的に使われることの多い言葉です。
一方、このような「負債」というメタファーはある人にとって「借金」としてネガティブすぎるイメージを想起してしまいますし、ある人にとっては「他人資本」としてポジティブすぎるイメージを伝えてしまうため、解釈の難しい言葉でもあります。
技術的負債という言葉はネガティブなイメージが強く、またそう呼ばれる対象のシステムを開発してきた人々にとっては気分が悪いものです。なので、リスペクトをこめて遺産を意味する“レガシー”を用いて、このようなシステムをレガシーシステムと呼ぶことがあります。
本連載では、技術的負債の本当の正体や解決方法とデジタルトランスフォーメーションとの関係について深堀りしながら解説します。
これらはソフトウェアの性質であると同時にソフトウェア開発というビジネス活動における「経済学的な現象」でもあります。そのため、技術的な用語をできる限り避けながら、開発者ではない方にとってもこの不可解な現象についての理解が深まるようになればと思って負います。
「技術的負債」は年間１２兆円の経済損害！？
これは「経済的な現象なのです」とお伝えして、最初にみなさんが気になるのは、それはどのくらいの金額の話なのかということなのかと思います。
正確なところは誰にもわかりませんが、経産省の試算によるとそれは「年間12兆円規模の経済的損失」だと言われています。これは実に東京オリンピック4回分です。なかなかの規模だと思いませんか。しかもこれは毎年のことです。毎年、オリンピック4回もやっていたら大変なことです。連日ワイドショーで取り上げられてもおかしくない金額規模ですが、システムの話になると難しく感じるからでしょうか、取り上げられたのは見たことがありません。
「年間12兆円規模の経済的損失」とは、一体どういうことなのでしょうか。
JUASの調査によると約8割の企業が、「老朽化システム」を抱えていて、全体の約7割の企業がこのような老朽化システムがDXの足かせになっていると感じているそうです。
また、経産省のDXレポートによるとこのような「老朽化したシステム」が企業のDXをすすめる上で大きな阻害要因となっており、それによる機会損失を含めた影響が年間12兆円になると予想されているわけです。
このような「老朽化システム=技術的負債」の問題がなぜ生じるのでしょうか。
古いシステムであることが問題なのではない。
技術的負債≒老朽化システムと表現されたり、レガシーシステムと表現されたりするため、古くなってしまったシステムが問題なのだと捉えてしまうのは早計です。
実際には、ただ古いことが問題なのではありません。繰り返された業務変化の中で「歴史的経緯」や「担当者の不在」などでブラックボックス化し、複雑化してしまったシステムが今後のビジネス展開を滞らせることが問題になっています。
技術的負債の課題は、機能追加が遅くなることにあります。同じ変化であっても必要な変化に対する労力がどんどんと大きくかかるようになることが問題なのです。
ソフトウェアは規模が増えれば増えるほど急速に複雑化します。これは、過去の機能のすべてが動作するようにしながら、新しい機能を付け加えるためだと考えるとわかりやすいでしょう。ソフトウェアを構成するモジュールが一定のペースで増え続けたとしても、ソフトウェアの複雑性はその組み合わせの数に比例して大きくなるのです。
もう少し、想像をしやすく表現すると、ソフトウェア開発が徐々に複雑かつ難しくなっていく様は、パーティゲームの「ジェンガ」のようなものです。
ゲーム初期段階でのジェンガは、簡単にブロックを抜き出したり、積み上げることができます。このとき、ゲームはスピーディに進んでいきます。ところが、ゲームをしばらく続けると、バランスを取るのが急激に難しくなっていき、テンポがゆっくりとなっていきます。慎重に抜き差しをしないと崩れてしまうためです。
様々な要件の変化によって形作られたジェンガは、徐々に不安定に、積み上げるのが難しく時間がかかるようになります。これが開発が遅くなる現象とよく似ています。
このように、開発の初期であれば同じ機能を開発するのに1であった労力が、機能追加の積み重ねによって複雑になったあとには、同じ機能を開発するのに2の労力がかかるということが起こります。これは、ひとつの箇所を修正するにしてもどんな影響があるかを理解するのが難しくなっているからです。
ところが、過去の多くのシステム開発の現場では、開発初期にはたくさんの人員を投入し、短い期間で作ろうとします。その後、一度開発が完了したあとには少ない人数で保守するというようなスタイルが一般的でした。
その結果、開発時には多くの人が共有してきたシステム内部のノウハウが、数少ない人員のみにしか継承されなくなります。また、その人員も徐々に担当替えや引き継ぎの不足などによって知識が摩耗していき、その間にも要望に応じて機能追加はされていきます。そのため、どんどんと複雑性が増える一方、それにあらがうためのノウハウは消えてしまうことになります。
その結果、ついには特定のベンダーや個人しかメンテナンスすることができないような状態になってしまうのです。このような「属人化」や「悪意なきベンダーロックイン」状態が進み「お手上げ」になってしまうのです。
この状態になってから、思い立って急速に機能開発をしようと意気込んでも、複雑で、誰もノウハウのないシステムになってしまっていますから、修正してくれる人が見つからず、機能追加が遅々として進まないということがおきてしまうのです。
しかし古いシステムであっても、全く変化が必要ないシステムや使わないシステム、はたまた経営に十分な速度でかつリーズナブルな予算で改善がし続けられている場合には何の問題もありません。
また、業務の要求変化に対しても少ないコストで耐えられるような優れた設計アーキテクチャがもともと備わっていて、そのノウハウが喪失しないように守られてきたシステムには、このような現象は起きにくくなります。
他にも機能追加前に「リファクタリング」と呼ばれるような業務の現実的な理解や変化をシステムアーキテクチャ設計に置き換えていくことが十分にできている場合にも問題は起きづらいです。
ですから、単純に「古いこと」が問題なのではありません。ソフトウェアを作ったら作りっぱなしで、機能追加をしつづけ、状況に対応するための労力を適切に割けていない…。こんな習慣こそが技術的負債が致命的なものになる原因なのです。
##ソフトウェア開発の本質的難しさ
1970年代というソフトウェア開発の黎明期にブルックスが著した『人月の神話』では、ソフトウェア開発の本質的な難しさを以下の4つであると書いています。これは現在でも十分に通じることです。
###複雑性
前述したように、ソフトウェアはその規模に対して複雑さが非線形に増大します。基本的にソフトウェアというものは一度作られたものであれば、再利用できます。そのため、何かを新しく作らなければならないときには常にどこかしら過去になかったものになります。世の中の多くのプロジェクトや生産においては、規模を大きくする際に単純な作業の繰返しとなるフェーズが存在するものですが、ソフトウェアプロジェクトでは本質的にはそうなりません。
###同調性
ソフトウェアは、それ単独で意味を成すものではなく自分自身を動作させるハードウェアや、ネットワーク、OS、その他のシステムなどと連携しながら、同調することで初めて意味をなします。そのため、それらの動作について完璧に支配できるものではない以上、その点を考慮しながら同調して動作する必要があるという点が難しいというのが、同調性です。
###可変性
ソフトウェアは、文化・業務・経済環境・商習慣、顧客行動などさまざまな点に連動して、変わり続ける必要があります。当初の計画通りのシステムが出来上がったとしてもそれは利用者の要望により変わり続けます。これは、出来上がったシステムそのものが環境の一部となって利用者や社会に影響を与えるため、閉鎖系ではないことに由来します。つまり、完全な予測そのものがほぼ不可能であるために常に変わり続ける必要があるのです。特に価値のあるシステムであれはなおさらです。価値のないシステムは使われず、消えるだけなので、変化の必要もなくなります。
###不可視性
ソフトウェアは、目に見えません。より正確にはソフトウェアは抽象的な概念をつむぎながらコンピュータでも解釈できるように明晰でブレのない言葉（プログラミング言語）にしていくことによって作られます。それは誰にでも理解できるものではないため、一部の人には見ることができ、一部の人間には見ることができないというような非対称な性質をはらんでいます。そのため、複数の人間の間でのコミュニケーションを阻害していくことになります。このようなソフトウェアの性質を不可視性といいます。
見えないことによるコミュニケーションの分断
このように徐々に複雑になっていき、変化が必要であるソフトウェアですが、その中身の状態は、実際に触っているソフトウェアエンジニアと非エンジニアのステークホルダーとでは、見える世界が違ってきます。
それは例えるなら、CTスキャンされた図像で人体を見ているか、肉眼で表面的に見ているかというくらいに違います。エンジニアではない人は、外側から見たシステムの様子(機能要件)しかうかがい知ることができません
一方、エンジニアにとってはCTスキャンを通すように内部の構造が見えています。であるからこそ気がつく病魔の兆候も、そうでない人にはなかなか伝わりません。この非対称性が、技術的負債が問題になる最大の理由であるといえます。
ですが、多くの現場では「見えない」ものが意思決定を行い、「見えるもの」がそれに従うという構造になっています。
たとえば、こんな状況を想像してみてください。あなたの住んでいる部屋にあなたとは別の部屋の所有者がどんどんと荷物を送ってきます。これを保管しておいてくれということで、拒否する権利はありません。
仕方がないし、最初は広々とした部屋だったので、とりあえず荷物をおいていきます。時間が経過して、あまりに多くなってきたので、あなたは所有者に大規模に整理整頓をしたり棚を用意したいと申し出ます。
しかし、その申し出は無視されたり、断られたりしてしまいます。部屋を一度も見に来たことがない人に「なぜ掃除をするのか」「掃除をしたらどんなメリットが有るのか」などを言われてしまうのです。
それでも次々と部屋に荷物が届くので、部屋から荷物が溢れたときにあなたは叱責され、あまりにもバカバカしいのでその部屋から去って別の部屋に住むことにしました。
そして、もうこれ以上荷物が入らなくなった部屋の所有者は途方に暮れます。この部屋はもう使い物にならなくなってしまったと。
もう少し、双方が歩み寄りながら会話をしていたら、そして部屋がどれだけ掃除が必要なのかを「体感的に」理解していたら、早めに手を打つことができたかもしれません。ですが、この「見えない」という情報の非対称性があるがゆえに問題は、致命的な事態になるまで放置されてしまいがちなのです。
技術的負債の真の正体
「技術的負債」という言葉が生まれ、ここまで問題になる背景はなんなのでしょう。それは、ソフトウェアの本質的な課題である複雑性や可変性を直接の原因としながらも、組織間における情報の非対称性によってコミュニケーションの分断を招いてしまったことの影響が非常に大きいのです。
童話『ブレーメンの音楽隊』で巨大な化け物に見えたものは、実際には小さな動物たちが重なって影になった姿でした。技術的負債も実際には巨大な化け物に見えますが、本質は１つ１つの小さな（非機能系の）課題です。それは、機能増大や環境変化による既存システムがもっている設計上の前提と、現実のギャップが積み重なって生まれたものです。１つひとつは解決することはそこまで難しくはないでしょう。
しかし、巷にあふれるよくある議論では、「Web自社開発企業に対してSIerが技術力がないから悪い」であるとか、「古いシステムで最新技術を使ってないから悪い」、「発注者がちゃんと要件を決めないから悪い」「情報システム部門がスキルが無いから悪い」というような分断を煽るような言説がまかり通っています。
本質な課題は、コミュニケーションの構造にこそあります。誰か一個人や、これまでの経営を支えてきたシステムにはないのです。ソフトウェア開発という経済活動に対しての構造的な理解がすすみ、このようなソフトウェアに対するナレッジが蓄積しない構造にこそ課題が有るのだと認識されれば、技術的負債は単なる積み上がった非機能要件のリストでしかないのです。
第2回では、このような「技術的負債」の真の正体を背景にその意外な解決方法に迫ります。
関連記事："技術的負債"論の道案内 - アーキテクチャの資本コストと情報の非対称性
第2回：ソフトウエア開発を「制御」する意外な処方箋
技術的負債の本当の正体をつぶさに見ていくと、実はソフトウェア開発の持つ本質的な難しさから生まれた問題が、コミュニケーションの齟齬によって積み重なったものだとわかります。
企業がソフトウェア開発をしていく上でこのような問題を生み出さないようにするにはどのようにしたら良いのでしょうか。第2回ではその対策として、最新技術を用いるといった「よく聞く」アプローチではなく、意外な処方箋を紹介します。
おさらい
前回の記事のおさらいです。ソフトウェアは、機能が増えていくにつれて非線形に複雑になっていきます。その結果、最初はスムーズに進んだ開発も徐々に滞るようになってしまいます。ソフトウェアを開発するにつれて、環境の変化やビジネス理解が進んでそぐわなくなってきた設計が徐々に積み重なると、これは顕著になっていきます。
ところが、ソフトウェアというのは「見えないもの」であり、設計のズレの積み重ねが把握できない、対処ができないままでいるとそれは、致命的なギャップとなっていってしまいます。これが技術的負債と呼ばれる現象が生まれた背景でした。
技術的負債の正体は単純にシステムが古くなってしまったということではなく、ソフトウェア開発の持っている４つの本質的困難性によって生み出され、積み上げられてしまった現実とシステムのギャップです。
結果的に知らず知らずのうちに、改善のために必要な資源の量が積み上がってしまい、巨大なコストが必要になってきます。結果、交換しようと思ってもできないホールドアップ状態のソフトウェアが出来上がってしまうのです。
重要なのは「ソフトウェアコントローラビリティ」
技術的負債について考えるときに、技術的な側面で「ソフトウェアのイケていない部分の総和」として考えると、泥沼にハマってしまします。これは非常に主観的な側面も大きいですし、どこまで行っても完璧になることは難しいのです。
なので、技術的負債がなくなってから機能拡張を考えようと、完璧にイケてる設計のシステムを作ったとします。それらが終わったあとにいざ機能拡張をいろいろするぞとなっても、それらの機能拡張自体があなたの想定していたイケている設計とは異なる場合、最高のシステムはたちまち誰かにとっての「技術的負債」へと早変わりしてしまいます。
何を作っていきたいか・どのように変化しうるのかによって最適な設計はまちまちです。ですので、「どうなりたいか」を知らずに、技術的負債の解消をしようとしても賽の河原で石を積むような作業になってしまうのです。
重要なのは、ソフトウェア開発という経済活動全体を制御すべきシステムとして捉えたときに「コントローラビリティ」があるかという観点を持つことです。システム制御におけるコントローラビリティとは、簡単に言えば「決まった状態になるような入力が存在すること」です。
ここではソフトウェア開発という経済活動を対象としたコントローラビリティを、リーズナブルな範囲の予算/時間という入力条件の中で、ビジネス上必要なシステムの機能追加をしつづけられることと定義しましょう。
「技術的負債」という表現だと、多くの人々にとってソフトウェアの中身の課題にだけ目がいってしまいます。とらえるべきは、そういった狭い範疇ではなくて、ソフトウェア開発という経済活動全体が健全にビジネスの要求する変化が実現できるかというもう少し広い範囲なのです。
たとえば、古く複雑で巨大なシステムであっても、十分なスキルのエンジニアが必要数いる場合には、必要な速度で改善ができるでしょう。また、そもそも変化の必要がまるでないソフトウェアであれば、最低限の人数でもなんとかなるかもしれません。
一方、新しく小さなシステムであっても、改善要求が多すぎたり、あまりに高度で関われる人数が十分でなく属人化してしまっているのであれば、簡単にコントローラビリティを失ってしまいます。
今後ソフトウェアに追加したい機能や目指す先がある程度見えているのであれば、それに合わせて必要な部分を回収することで、輝きを取り戻すこともあります。
このようなソフトウェアを改善する組織自体をどのように経営するかがソフトウェアコントローラビリティの観点では重要になっていくのです。
適切な人員がいるか、要求の整理や取捨選択ができているか、課題の可視化は十分にできているか、プロジェクトの問題に気がつくための心理的安全性は十分に高いか、開発の生産性の課題になるような部分を適宜解決できているかなど、ソフトウェアを改善するビジネス組織全体について、十分な能力を持っているかを経営していく必要があります。さもなければ、ビジネスに必要な変化をリーズナブルな予算の範囲でする能力を失ってしまうことになります。
このような課題は、テクノロジーとビジネス、プロダクトマネジメント・プロジェクトマネジメントなどが交差する場所に存在する観点であるため、ポッカリと空白領域になってしまうことが多いのです。特に専門性で、組織や企業体をばっさりと切ってしまうような場合には、生まれやすい問題です。
「ソフトウェアコントローラビリティ」という概念について理解すると、技術的負債に係る問題についてのアプローチの仕方が変わってきます。
たとえば、技術選定のあり方も変わります。たくさんの労力が必要な部分に関しては、市場で人気があり、多くの人が扱える技術を採用するようになりますし、複雑でパフォーマンスと信頼性が求められる領域では、多少エンジニアの採用が難しくても堅牢で信頼性の高い技術を採用することになります。
最新技術で「ゼロからはじめたい」症候群
ある程度までこじれてしまったソフトウェアを見たとき、多くの経験の浅いエンジニアやベンダーはこれを最新技術でゼロから完全に作り直したら楽になるんじゃないかと考えてしまいがちです。こういう気持ちになったことは筆者は何度もあります。その結果、再構築を提案してしまう。ところがこれには大きな落とし穴があるのです。
今動作しているのと、同一のソフトウェアを完全にゼロから作り出すことを想定した場合、大抵の場合、これまでの累積工数を以前のシステムより圧倒的に短い工期で作り直すというプロジェクトになります。そうしなければ、作り直しを行うビジネス的な経済合理性があまりないからです。
たとえば、あるソフトウェアが5名で5年かけて作られたとします。全部で300人月の工数が費やされてきたことになります。このソフトウェアが技術的負債となり開発速度が遅くなってしまったとします。
これを再開発するために、さすがに5年は費やすことができないため、できれば1年くらいでプロジェクトを完了したいと思うのは自然な発想だと思います。さて、このとき開発者は何名くらい必要で、何人月のコストを費やす必要があるのでしょう。
単純に考えたら、工期を1/5にするのですから、5倍の人員の25人がいれば、1年間で300人月の総コストになります。しかし、この単純計算はうまくいきません。
これは、ソフトウェア開発者にとっては半ば常識的なことですが、同じシステムを短い期間で開発するために人数を増やした場合、総コストは急速に大きくなり、どこかで現実的に不可能なゾーンに突入します。極論すれば、3000人いれば、3日で実現できると思うかというのと同じ話だからです。これは当然不可能です。
これは、「妊婦が10人いても1ヶ月で子供をひとり生むことはできない」という喩えがよく用いられます。
古典的パラメトリックな見積もり手法(Putnam Model)で推定すると、同一のシステムを1/5の期間で作ろうとすると、同じ生産性であれば、5の4乗の625倍のコストが必要になります。実際にはある程度新しい仕組みで生産性が高くなる部分もあるかと思いますが、期間を短くして人数を多くするというロスは非常に大きく、経済合理性がないばかりかほぼ不可能になってしまうことも多いのです。
もちろん、すでにあるソフトウェアから必要な部分を抽出したり、設計のずれている部分を修正していくなどすれば、うまくいくケースもあります。しかし、本質的な難易度の高いプロジェクトであることは間違いありません。
関連記事：なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか
さらに、このような手法を取る場合、短期的に作り上げる為に一時的に開発者人数を増やすことになります。外部の開発会社や業務委託などを通じて人数を一気に増やした上で、運用フェーズに入ったら少ない人数で継続開発することを計画することも多いのではないでしょうか。
こうすると、せっかくソフトウェアに詳しくなった人々がどんどんと開発から離れていくことになり、ノウハウが伝承されません。本来、どのような機能追加をしやすく設計するかなどのドメインモデルやビジネスロジックに関するアーキテクチャをより現実環境にフィットさせるという労力よりも、多人数で同時にプロジェクトを進めるということに力点が置かれやすくなります。
結果的にこのアプローチは、相次ぐ遅延やプロダクトオーナーとのすれ違い、担当者の離職、ビジネス環境の変化、これらの組み合わせなどで非常に困難なプロジェクトになります。完成してもその直後から技術的負債になってしまうといった最悪の事態になってしまった事例も数多くあります。
多数の企業で、つくりかけのまま、ふたたび「最新技術」ではなくなってしまった「ゼロから作り直したシステム」の残骸が地層のように積み重なっているのを見てきました。みなさんがゼロから作り直すことを考えるとき、これを繰り返さない覚悟と信念があるでしょうか。
まずやるべきアプローチは「今動くソフトウェアと人に向き合うこと」
新しく最新技術で作り直すということは、やる気のあるソフトウェアエンジニアにとって非常に魅力的です、また、このようなシステムになれば十分な速度になるという提案はビジネスオーナーにとっても魅力的な話です。あまりに魅力的なので、現在のシステムに向き合うことを忘れてしまうのです。
しかし、ここ数十年間そうであったようにソフトウェア開発の本質的困難は、新しい技術を使うことではあまり変わりません。表面的で、雑多な問題はいくつも解決してくれます。しかし、銀の弾丸はないのです。ですが、ソフトウェアを継続的に育ていくための良い習慣というのはあります。
それはたとえば以下のようなものです。
- 十分に継続開発できる人数を確保する。（stop&goが最も燃費が悪い）
- 誰でも作業を始められる自動化された開発環境を構築する。
- 外部ライブラリのパッケージ管理を行う。
- 当初の抽象化の失敗から積み重なって複雑性を生み出している根源を抽出。
- 自動テスト・継続的インテグレーションを充実させる。
- APIレベルかプログラムレベルでファサードを用意して、段階的に移行可能にする。（ストラングラーパターン）
- 用のない機能・デッドコード・重複コードを棚卸し、削除する。
- 必要な箇所だけ新しいシステムと連携するためのアーキテクチャを設計する。
- 技術的な負債や状況を可視化し、意思決定者やコードの中身が見えないステークホルダーと状況を共有していく。
- 将来追加していきたい機能を多く列挙し、共有する。
- 継続的にデプロイできるように自動化と検証を行う。
- コードを見れば分かる内容ではなく、思想的なレベルのガイドラインやドキュメントを残す。
- ビジネス目標を共有する。
- 継続的な振り返りを行う。
- トラックナンバーが１にならないように属人性を減らす。
これらのノウハウが「ソフトウェアを開発する主体」となるビジネス組織に宿っていくと、ソフトウェアコントローラビリティを喪失しにくくなります。誰かがやめてしまっても、簡単に開発が止まらないように継続的にシンプルに保ち、培ったノウハウが消えてしまわないように段階的に強固にしていくことが重要なのです。
巷では時折、開発ベンダーやSIerのレベルが低いから技術的負債になるのだという分断を招くような議論があります。あるいは、開発者のレベルが低いから、または、発注者のレベルが低いからなども言われます。内製化すれば技術的負債にならないという言い方もそうかもしれません。私たちはこのような議論からそろそろ脱出するべきです。
どんなにレベルの高い自社のエンジニアがいても、それがたった一人しかおらず、ぞんざいに扱われ退職してしまったら、そのノウハウは組織から消えてしまいます。たとえ、パートナー企業との仕事であっても価値のあるコミュニケーションやノウハウが残るような開発を通じて強固な信頼関係を築くことはできます。
一方、より自社内部にノウハウを残したいのであれば、まったくコードが読めないひとしかいない場合、ソフトウェアの中身に対して良い意思決定はむずかしくなるでしょう。必要なのは、自社のソフトウェアが継続的に改善できる能力を持つための企業全体としてのあり方であって、個々の業態や個人の問題ではないのです。また、企業全体としてのあり方は、個々人のあり方の総和でもあります。
泥臭い解決策が実際もっともコスト安になる。
このような解決策は、とても泥臭くみえます。また、実際やることは大変だと思います。しかし、流行りに乗って新しい道具と戯れることだけがエンジニアリングではありません。
新しい技術はソフトウェア開発の本質的な難しさを緩和するための人類の英知です。ですから、それらを用いて、2倍から3倍程度は痛みを緩和できるかもしれません。しかし、それだけで10倍の問題解決をしてくれるというのは大きな勘違いです。
常に必要なコントローラビリティを意識し、具体的な患部を特定した上で治療していく事が重要です。この患部の箇所はときに組織であり、ときにビジネス全体にまで及ぶのです。
患部を特定できずに問題を解決しようとすることや、何かを銀の弾丸と思って飛びつくことは最終的にコスト高になります。よい学びの機会にはなるでしょうが、致命的な失敗も引き起こしえます。
ソフトウェア開発を深く理解したCTOの重要性
この泥臭いエンジニアリングのノウハウを評価できるマネジメント職というのは非常に少ないのです。ソフトウェア開発と経営、組織マネジメントに至るまで広範な洞察が必要になるからです。経営レベルでこのようなソフトウェアの活用とそこに宿るエンジニアリングの理解があるとないとでは、企業競争力に大きな差が生まれてしまいます。
現代における最高技術責任者(CTO)の仕事は、ソフトウェア開発に対する深い理解をもって、企業の競争性を高めることです。
技術力というのは、自明なハードスキルに見えますし、そのように勘違いされている人は多くいるでしょう。実際には、エンジニアリングのスキルというのは、泥臭いことを恐れず、問題に向き合い、患部を特定して、解決するという一見地道な所作に宿ります。新しいものを貪欲に学ぶ姿勢は非常に重要です。一方で、新しい道具の使い方ばかりに目移りして、『エンジニアリング』ができないエンジニアも多数いるのではないでしょうか。
第3回ではデジタル化時代の経営のあり方として、「2つのDX」のお話をします。一つは、企業のデジタル化であるデジタルトランスフォーメーション(DX)、もうひとつが開発者が生産性を発揮しやすい環境を意味するデベロッパーエクスペリエンス(DX)です。
一見関わりがないように見えるこの２つは、車の両輪のようなものです。どちらか一方ではうまくいかないのです。それはなぜでしょうか。技術的負債へのアプローチをヒントに解説していきます。
第3回：技術的負債への取り組みはなぜ「２つのDX」につながるのか。
近年の急速な環境変化の影響もあって、DXという言葉への関心が集まってきました。企業のビジネスモデル変革のためのデジタルトランスフォーメーション。いざ、それを進めようとしてもなぜだか全然進められないし、何をしたらよいかわからないということはありませんか。
経済産業省のDXレポートでは老朽化したITシステム（技術的負債)こそが最大の障害だと述べられていました。一見関係のないように聞こえる「古いシステムの改修」がデジタル技術を用いたビジネス変革につながるのでしょうか。
その本当の理由こそ、DXの最も重要な点なのです。著者が理事を務める日本CTO協会ではそれを「２つのDX」とよび、開発者体験というもう一つの”DXの頭字語”の観点を取り入れたデジタルトランスフォーメーションの進め方を解説します。
おさらい
第1回では、これまで技術的負債という概念がソフトウェア開発の持つ本質的な４つの困難性から生まれたことを解説しました。そして、第2回ではこの問題の解決には、ソフトウェアコントローラビリティという観点を持ち込むことが重要だとしました。つまり、ソフトウェアを継続的に開発し続けるための組織全体の健全性に着目するということです。
これによって、ただ単に古いからだめ、新しいから良いという単純な理解からソフトウェアを改善し続ける組織を経営していくという視座が得られます。この役割がCTOの機能の１つであると論じました。
古いシステムの改善がなぜデジタル化につながるのか
デジタルトランスフォーメーションについて語るときに、どうしても新しい技術で新しいビジネスを始めるにはどうしたらいいか、そのときに良い開発会社がないかなどを気にされる方が多いかと思います。これは自然な発想だと言えます。自社にない技術を調達して、開発を進めたほうが効率もいいし、失敗したあとには契約を切ればいいだけなので経済合理性もあります。
そのため、古いシステムのことには目をつぶって新しい事業を起こすことに力を入れるのがDXだという考え方ももちろんあります。でも、これはなかなか難しく、成功しづらいのです。よしんばうまくいっても、すぐに落とし穴にはまってしまいます。
それは第1回、第2回に述べてきたように、ソフトウェアとそれを改善するビジネス組織を分けて考えてしまう組織風土こそが技術的負債を生み出していることに関係しています。
現代のソフトウェアビジネスは、改善されるスピードが桁違いに早いのです。この改善のスピードを自分のものにしておかないと、最新技術で新しいものを１年２年かけてつくっても、出来上がった頃には陳腐化し、ビジネスとしての有効性がないということもよくあるのです。
その状態では、ソフトウェアの改善スピードが早い競合に勝っていくことはむずかしくなります。自社環境はあまり変化せず、業務の効率化に使われてきた時代のシステムに対して、現在のシステムは顧客や最終顧客に提供する商品そのものになりました。商品を通じた体験やサービスに関心の領域がシフトしてきたからです。
Amazonは、1時間に1000回以上も様々なシステムが改善されデプロイされているといいます。日本国内のベンチャー企業でも、1日に数回〜数十回というのは当たり前の水準だったりします。
ところが、日本の大企業のシステムは、関連部署やパートナーとのコミュニケーションコストの山と、上長への説明コストの山をかき分けながら、修繕のたびに手動で品質チェックを掛けています。月に一回改善できればいい方で、半年に1回、1年がかりというのも珍しくありません。
過去のシステムがこのようになってしまった本当の理由に向き合えないままだと、何度新しいシステムを作り直しても、それがふたたび「技術的負債」となるか、あるいはビジネスに敗北してシステムごと消えていくだけになります。
「見えない投資」が開発者体験：DXにつながる
第1回で述べたように、「ソフトウェアは見ることができないという性質(不可視性)」を持っています。パフォーマンスの良さ、拡張性、発展性、保守性、信頼性などソフトウェアが持っている隠れた性質を理解し、その上で必要となる「品質への投資」を進めることが重要になります。また、それを育むための組織文化も重要なファクターになります。こちらも見えにくいものです。
このような見えない部分の投資は、ビルの基礎工事や柱に宿っている強度や構造計算されたアーキテクチャのようなものです。この部分が疎かになるとたちまちビルは倒壊してしまいます。これは表面上は「見えない」というところや、専門性がないと判断のできないところも似ています。
あなたが家を建てるときに基礎工事の費用をおろそかにするような指示出すことは、まずないと思います。それは、１０００年以上の歴史を持つ建築の知識の積み重ねが、理論を持ち、基準を決め、それに準拠することができたからです。
ソフトウェアの歴史は50年ちょっとです。様々な観点での可視化の試みはありますが、スタンダードや法令があるわけではありません。そのため、言語化の努力をしていてもなかなか伝わりにくいのです。その結果、効果のわからないものとわかるものを比べてコストコントロールにかけたときに、自然と効果のわからないものが削られることになります。
ですが、別の現場やシステムを通じて実際にソフトウェア開発の経験の中で体験してしまうと「十分な自動テスト・継続的インテグレーション環境」や「安全なデプロイパイプライン」「疎結合なアーキテクチャ」など、やらないことが非常識であるというな感覚を覚えるくらい自然なことに感じられます。
たとえるなら、全自動洗濯機や食器洗い機が一体どのくらい費用対効果があるか試算しろと言われてもぱっとできないけど、さすがにもう手洗いだけの選択にもどることが自然と選択肢から消えていくというのなものです。このような一度知ったら戻れないような便利な状態だけど、導入には少し躊躇するようなことがソフトウェア開発の世界には多数存在します。
このような説明の難しさを乗り越えて、開発者環境を「当たり前品質」として導入できるようになるには、「ソフトウェアを開発する組織」としての組織風土・チーム文化を育んでいくことが必要不可欠になるのです。ある調査では、自動テストなどの普及率と開発者の「組織への帰属意識」は強い相関があったそうです。これは、直感にも即しています。見えない部分にもこだわって創るのは、その組織を良くしていこうとソフトウェアを継続的に改善するという意思が無ければ、なかなかできることではないからです。
このような状況を単純化するならば、「システム品質への投資」「組織風土・チーム文化」の掛け算が成立しないといずれ、技術的負債現象が発生し、ソフトウェアコントローラビリティを喪失することになるのです。
組織にエンジニアが「溶け込んでいく」エマルション現象
さて、競争環境からソフトウェアコントーラビリティを意識せざるを得なかったようなメガベンチャーがたどってきた開発組織の変遷をつぶさに見ていくと、奇妙な共通点があることがわかります。
それは、1つの開発部門に集中していたエンジニアが徐々に事業部門内の開発組織にうつるようになり、さらに発展すると同一のチームの中に開発者・デザイナー・プロダクトマネージャが混在して働くようになってくるという現象です。
これも、ソフトウェアの性質を考えると当たり前のことなのですが、ソフトウェア開発は意思決定の積み重ねによって進捗します。できるかぎり意思決定者と実行者が近い位置にいたほうが物事は進むものです。逆に出来上がったものを何ヶ月かに一度レビューしたり、一度も触らずに判断するといったようなことがあると、開発はどんどんと遅くなります。
開発された都度に何度も触ってもらい、手触りを確認しながら開発を進めていくほうがフィードバックが受けやすいのは想像しやすいのではないでしょうか。スクラム開発におけるレビューもこのようなフィードバックの場です。
このように意思決定やフィードバックを受けやすい組織構造に変わっていくことができると、
そのうち、一部の分析業務や文言の修正、デザインの一部変更などはプログラミングスキルがない人でもできるようになってきます。気がついたら、ちょっとした機能修正なら自分でソースコードを修正して開発者にプルリクエスト(修正案の提示)をしてくる猛者も現れてきます。こうなるともうほとんどエンジニアです。
一方、本業のエンジニアは、より難しいアーキテクチャや機能開発に専念できて効率が良くなっていきます。また、ビジネスの理解も進み、機能提案や設計も優れた精度でできるようになってきます。相互の理解がすすみ「情報の非対称性」が消えていくと、技術的負債という言葉の意味はどんどんと薄れていくようになるのです。そもそもが、コミュニケーションの齟齬を埋めるためのキーワードに過ぎないため、使う必要がなくなるのです。
このように開発速度を向上させようとするアプローチを繰り返していくと、自然とソフトウェアエンジニアは組織の中にとけていきます。様々な部門にソフトウェアエンジニアとソフトウェアの理解の進んだビジネス職があらわれるようになります。これを著者はパスタソースを作る際に水と油が溶け合うことを示す言葉をつかって、「エマルション現象」と呼んでいます。
この喩えがそうであるように、ソフトウェアエンジニアのカルチャーや体感というのは理解しにくいものでもあるため、しばしば技術職とビジネス職は「水と油」のような関係になります。ですから、これらのフェーズが進んでいく段階ではしばしば大きなハレーションや対立が置きます。一度進んだフェーズを戻すこともしばしばでしょう。
これは、人類の普遍的な性質であると思うのですが、同一の組織の中におけるマイノリティは自然と居づらくなったり、排除されてしまうという現象が起こります。また、異なる属性同士で仕事をしていくことはしばしば大きな摩擦を生みます。悲しいことですが、社会のあらゆる場所で目にする現象だと思います。
ある会社組織にとって、異物を弾く力がある事自体は本質的に悪いことではなりません。それをカルチャーや仲間意識と呼ぶこともできますし、危険分子を排除する機能とも言えます。ところが、その性質が強くなりすぎてしまい、必要な変化や多様性をも受け入れられなくなると、組織は柔軟性を失っていくのです。
たとえば、内製化を進めようと人を雇っても、ソフトウェア開発ができるような人々を危険分子として排除してしまうことがあります。こうなると、せっかく採用したエンジニアが風土に合わず退職してしまいます。多数の中のマイノリティでは、なかなか文化や主張が合わないため、小さなことに説明コストがかかります。次第に話が通じないので疲れて果ててしまうのです。転職市場が華やかな時代であればなおさらです。
だから皆、多くの優れたエンジニアがいて多数を占めるような組織に転職したがります。そうなれば、きっと話が通じるようになるし、嫌な思いをする機会が減るのではないかと考えます。そして、最新技術を使っている様子をネットで見て、それを使いたいと思うようになっていくのです。
このような組織の力学を逆流させることは大変です。異なる文化の境界面こそ、積極的なコミュニケーションと相互理解が大事になります。
たとえば、ウォーターフォール／アジャイル、SIer/Web系自社開発、ユーザ企業/ベンダー企業。ビジネスと開発者などなど、2つの価値観の些細な溝ですら、分断を呼ぶ言説が飛び交っています。その一つ一つが技術的負債の発生源になるのです。分断を招く言葉・言説こそが組織が溶け合う力を奪っていきます。
##分断を産まないための「２つのDX」
DXというキーワード、現在ではそこかしこで聞くことが増えました。著者が最初に聞いたのはもう5年以上前でしょうか。その頃にはあまり広く普及した言葉ではありませんでした。
初めて「DX」という言葉を聞いたとき、私はその言葉が「Digital Transformation:企業のデジタル化」ではなく、「Developer eXperience:開発者体験」のことだと勘違いしてしまいました。実際にデジタル化が進んでいるベンチャーのソフトウェア開発者にとっては、企業のデジタル化を指す言葉よりも、そちらの言葉のほうが馴染み深かったからです。周囲のメンバーに聞いても、ビジネス職含めその当時はほとんどの人が企業のデジタル化を指すDXを知りませんでした。
逆にデジタルをビジネスにうまく活用できていない、いわゆるレガシー企業の人々と会話するときに、DXといったら「企業のデジタル化」のことを直ちに意味します。開発者体験の方を知るものは皆無と言っていいほどです。
しかし、そのような企業のデジタル化をサポートをする中で、彼らに本当に必要なのは「開発者体験」の方だと気がつくようになります。
それは、ソフトウェアを効率よく開発する習慣や、組織文化を持っておらず、効率が非常に悪い、ゆっくりとしたサイクルでしか機能開発ができていなかったからです。デジタル化できる・効率化できるような様々な箇所があっても変化を嫌い、異物を排除するような強固なモノカルチャーができあがっていると新しい価値観をとりいれることがむずかしくなります。
そのような状況では、現代的なスピード感で開発をしていくことはできません。F1レースに軽トラで出場するようなものです。
そこで、2つのDX、企業のデジタル化と開発者体験は車の両輪だと気がついたのです。片輪だけではくるくると同じところを回ってしまいます。企業内新ベンチャーごっこ、お遊びPoCなどは、同じところを堂々巡りにほかなりません。どこかで強い信頼とリーダーシップのもと組織的なエマルションが起きていく必要があるのです。
##「DX Criteria」は「2つのDX」への羅針盤になる
筆者が理事を務める日本CTO協会は、昨年12月に自社のDXがどれだけ根付いているか、どこが強くどこが弱いのかという点をアセスメントするためのツール「DX Criteria」をインターネット上に無料公開いたしました。
DX Criteriaは、5つのテーマ毎に8つのカテゴリ、さらにそれぞれ8つの具体的なチェック項目があり、合計320もの観点から自己評価をしていただけます。それだけ仔細で具体的な項目をチェックすることで目に見えない様々な習慣や文化がどれだけ浸透しているかを確認することができるのです。
5つのテーマは、「チーム」「システム」「データ駆動」「デザイン思考」「コーポレート」です。システムだけではなく、事業全体・ビジネス組織全体としてどれだけ高速に価値を生み出しやすい仕組み・習慣を持っているかを全体像で捉えます。デジタル化とは決してシステム担当部門だけでは成し遂げられないのです。
各カテゴリの項目は、デジタル企業の多くが取り入れている目に見えづらい習慣や仕掛け・文化の数々です。それぞれが具体的で、DXという抽象的に見える流行語に指針を示す羅針盤となることを目指しています。
DX Criteriaのご利用に関して、主な使い方は次の３つです。
- 自社のDX進捗度の簡易的なアセスメント
- 担当マネージャによるチームとシステムごとの詳細なアセスメント
- 外部パートナーとのコミュニケーション
たとえば、半期に一度などの定期的な自社によるアセスメントに活用できます。自社の強み弱みを可視化し、戦略決定の議論などにご活用できます。
また、必要に応じ外部パートナー企業との間で「どのようにしたら高速な開発ができるのか」という論点での議論にも活用できます。これによって、自社では足りない部分のサポートやサービス導入をするといった商談をすすめる上でも有効です。
「新大陸」は、羅針盤を持って挑戦を続けたことから発見されました。決して、最初から新大陸を見つけようとしたわけではないのです。挑戦を続ける組織風土・マインドこそがこのような改革を実現する最大の資産になります。
本稿やDX Criteriaがデジタル化という荒波を乗り越える羅針盤となれれば幸いです。