【ITニュース解説】Business value > Shiny tech

このニュース記事は、ソフトウェア開発の現場でよく見られる「技術そのものの新しさや華やかさを追い求める姿勢」と、「顧客が本当に求めているビジネス価値の提供」との間に存在する重要なギャップについて指摘している。筆者は10年間の開発経験を通じて、多くの開発者が最新の技術トレンドに目を奪われがちだが、最終的に顧客が関心を抱くのは、その技術がもたらす具体的な成果や便益であると強調する。

ソフトウェア開発の世界では、様々な技術が日々進化し、新しいフレームワークやライブラリが次々と登場する。例えば、ウェブアプリケーションのユーザーインターフェース（UI）を構築する技術では、Angular、React、VueといったJavaScriptフレームワークがあり、それぞれに熱心な支持者がいる。また、サーバーサイドの処理を担うバックエンド技術では、JavaやNode.jsなどが主要な選択肢として挙げられる。これらの技術のどれが優れているかという議論は、開発者コミュニティの中で頻繁に繰り広げられる。しかし筆者は、AngularからReactへの書き換えが行われたり、VueとAngularの間で優劣が争われたり、JavaのバックエンドとNode.jsのミドルウェアの間でどちらが良いかという論争が起きたりしても、結局のところクライアント（顧客）はそれらの技術的な選択そのものには興味がないと述べる。彼らが本当に望んでいるのは、自社のビジネスに貢献する具体的な価値、つまり「ビジネス価値」なのだ。

これは、技術をあたかも芸術作品のように、それ自体が目的であるかのように扱ってしまう開発者の姿勢への警鐘でもある。筆者自身も過去にそのような経験があったと認めている。新米開発者、あるいは経験が浅い中堅開発者の頃は、アプリケーションのドメイン、つまりそれがどのような業務で使われ、どのような課題を解決するのかという「ビジネスの本質」にはほとんど関心がなかった。コードを書くこと自体は得意で、どんな技術的な課題でも解決できる自信はあったが、使う技術に関しては、常に最新で最もクールなものを取り入れたいという欲求が強かったという。

例えば、新しい「ステートマネージャー」が流行し始めると、次の日には自分の担当プロジェクトにそれを導入したがる傾向があった。ステートマネージャーとは、アプリケーション内のデータや状態を効率的に管理するための仕組みで、特に大規模なアプリケーションではその重要性が増す。多くの開発者が使っているのだから、それは正しい選択に違いない、と当時は考えていたのだ。幸いにも、経験豊富な先輩開発者たち（シニア開発者）が筆者のそのような考え方を冷静に諭してくれたが、中には技術の流行に流される姿勢から抜け出せない開発者もいると指摘する。

このような「技術ありき」の考え方は、無意味なリファクタリング、つまりコードの外部的な動作を変えずに内部構造を改善する作業に繋がり、結果として顧客の資金を無駄に燃やすことになりかねない。筆者が挙げる無意味なリファクタリングの具体的な例はいくつかある。一つは、まだアプリケーションが小さく、複数のコンポーネント（部品）間でデータをやり取りする際に特に問題が生じていない状況で、新たなステートマネージャーを導入することだ。これは、必要のない複雑さを追加するだけで、実際の改善効果は薄い。もう一つは、単純に構文がより見やすいという個人的な好みの理由だけで、Angularで書かれたアプリケーションをReactで全面的に書き換えることである。これは膨大な時間とコストを要する割に、顧客にとっての新しい機能や改善された性能といったビジネス価値はほとんど生まれない。さらに、真の必要性がないにもかかわらず、多くの「抽象化レイヤー」（複雑な詳細を隠すための階層）を追加したり、「モノレポ」（複数のプロジェクトのコードを単一のリポジトリで管理する手法）や「パッケージ」（再利用可能なコードのまとまり）を無闇に増やしたりすることも、不必要な複雑性をもたらし、メンテナンスコストを増大させるだけで、顧客のビジネスに貢献しない。

しかし、もちろんリファクタリングや、システム全体の変更を伴う「マイグレーション」（移行）が常に悪いわけではない。筆者は、それが実際に意味を持つ状況も明確に示している。例えば、古くから使われているReactのクラスコンポーネントという記述方法を、より現代的で簡潔な「フック」という新しい記述方法に書き換えることは、コードの可読性やメンテナンス性を向上させ、将来的な開発効率を高めることに繋がるため、有意義なリファクタリングである。また、プロジェクトが成長し、既存のステートマネージメントの仕組みではデータ管理が追いつかなくなったり、機能の追加が困難になったりした場合に、より強力なステートマネージャーを追加したり変更したりすることは、システムの安定性や拡張性を確保するために不可欠な判断となる。新しい技術やツール、いわゆる「新しいおもちゃ」を導入する場合でも、それが実際にチームの生産性向上や開発効率の改善に役立つと判断された場合に限り、段階的に取り入れていくことは理にかなっている。

筆者は自身の具体的な業務経験から、意味のある技術導入の例を挙げている。それは、型付けが全くされていない「レガシーフロントエンド」（古くて複雑な、ウェブアプリケーションのユーザーインターフェース部分）に対して、「TypeScript」を導入した事例である。TypeScriptは、JavaScriptに「静的型付け」という概念を追加した言語で、コードを書いている段階で型に関するエラーを発見しやすくなるという特徴がある。このTypeScriptの導入は、単に「流行の技術だから」という理由で行われたわけではない。その真の目的は、バグの発生を減らすこと、新しい開発者がプロジェクトに参加した際の「オンボーディング」（業務に慣れるまでの期間）を短縮し、よりスムーズに開発に参加できるようにすること、そしてコードベースが将来にわたって保守・拡張しやすい状態を保つ、つまり「将来性」を確保することにあった。これらはいずれも、顧客のビジネスにとって具体的なメリット、つまり「ビジネス価値」として明確に認識されるものだ。バグの減少はサービス品質の向上とコスト削減に繋がり、オンボーディングの改善は開発効率を高め、将来性の確保は長期的なシステム投資の安定化に寄与する。

この経験から筆者が導き出す最終的な結論は、非常に明確である。どのフレームワークが最も優れていて、最も輝いているかという議論や対立は、経験の浅い若手開発者や、特定のコミュニティで知名度を上げたいスターたちに任せておけばよい。私たちソフトウェア開発者は、そうした技術論争に終始するのではなく、常に「ビジネス価値の提供」という本質的な目標に焦点を当てるべきだという。顧客の課題を解決し、彼らのビジネスを成長させるために、どの技術が最適かを判断し、それを適切に導入・活用することが、真のプロフェッショナルな開発者の役割である。