ソフトウェアエンジニアリングにおけるリファクタリングの重要性
日経電子版の記事
中の「デジタル敗戦」の要因について、GAFAではないが似たような企業でのエンジニア経験から少し追加したい。
リファクタをつねに考えるべき
リファクタもしくはリファクタリングとは、定義は完全に定まっているわけではないけれど、基本的には
機能追加などを前提とせずに、プログラムの中身を(部分的あるいは全面的に)書き換える
ことを指す。どちらかというと部分的よりも全面的に書き直すことを指すことが多いように思う。もちろん、いったん完成してから改善や機能追加された部分も含めて、仕様や設計をも見直してコードを書き直すことが多いけれど、それだけではなく、前提としているフレームワークやミドルウェア、果ては「言語」まで再評価したうえでそれらも変更して書き直す、というよりも全面的に作り直すことも含まれる。
で、GAFAをはじめとした特にアメリカのIT企業では、このリファクタが日常的に行われている。
特に「書き直す」期間は決まっておらず、短いもの・規模の小さいものでは半年、大きいものだと完成後数年たって、というものもあるが、特に市場で使われているものあるいは企業の中で基幹システムとして使われているものほどその頻度は高く、コストや工数を十分に確保したうえで行われることが多いように思う。
リファクタの効能は、一般的にはパフォーマンスやレスポンスが向上したり、書き直す時点で新しいアイデアを思いついてそれを実装できたり、最新のフレームワークを取り込んだことによってさらに拡張する余地を広げたりする、といったものがある。また、書き直す際にバグや仕様上の矛盾に気づいて、顕在化していなかった問題も修正できるチャンスとなることもある。
ただ、それ以上に、プログラムの中身を一から再構築することによって、かかわっているエンジニアの「頭の中」をもう一度リフレッシュすることによる効果のほうがはるかに大きい。
特にアメリカIT企業では、この記事に書かれているようにアジャイルが重視され、詳細な設計書は残されないことのほうが多い。大きな機能単位で分割され、エンジニアが割り当てられると、エンジニアはさらに細かい機能単位でブレイクダウンしたうえで、タスクに分解して工数を積み上げ、それぞれを自分で実装することがほとんどなので、細かい設計書を残す必要もなければ、事前に書いた仕様に全部従う必要もない。
目的とスケジュール、それに品質さえきちんと守られていれば、実装は各人の裁量に任されることがほとんどだ。もちろん、ジュニアなエンジニアはデザインレビューやコードレビューによってフィードバックを受けて「自分で」成長していく。
必然的に、システム更新やバージョンアップの際、「コードを読んで」何をすべか、どのように実装していくか考えることになる。つまり、頭の中に積みあがっている設計がすべてであって、その唯一のアウトプットがコード、ということになる。そのどちらも最新に保つためには、一定期間ごとに「全面的に書き直す」ことが必要になるのだ。
わたしが知る限り、日本企業のソフトウェアエンジニアでリファクタの重要性を真に理解している人は皆無に近い。
なぜ日本の企業ではリファクタしないのか
一番の理由は、「実装は外部ベンダーに丸投げ」することがとても多いからだ。IT専業の企業やSIerですら、詳細設計以後の実装は外部ベンダー(良くても客先常駐派遣)や国外にアウトソース・オフショアすることがとても多い。つまり設計者が自分でコードを書いていないのだ。
わたしが働いていたアメリカ資本のソフトウェア企業では、外部ベンダーによるコード流出が起きたこともきっかけの一つだったが、いまから15年ほど前に「すべての」コード実装作業、つまりモノづくりのすべては社員または直接雇用(インターン含む)のエンジニアのみが携われることになった。コードは会社の重要な資産であり、価値であり、かつ将来のプロダクトのための礎でもあるからだ。
わたしは「シニアソフトウェアエンジニア」として、プロダクトの技術的方向性や使用するプラットフォームの策定、アーキテクチャ、工数管理、スケジュール管理、エンジニアの採用育成、そしてタスクのアサインメントまで責任を負っており、かつ10人のエンジニアを抱えるチームのマネージャーでもあったが、設計・実装それにユニットテストも自分で行う点については例外ではなかった。
対して、日本のソフトウェア業界ではなぜか数十年前からコードを書くことが「下流の」仕事とされ、「上流の」つまり要件定義や仕様確定、概要設計が高級な仕事とされてきた。コードを書くことはしばしば「製造」と呼ばれることもある。エンジニアのキャリアパスも、コードを書くところからいかに早く抜け出すかがフォーカスされていたりする。
そして、製造現場あるいはコードを書くエンジニアからの設計へのフィードバックはあまりなされず(受託関係があると請負元にケチをつけるということにもなるから)、結果としてコードレベルでのクリエイティビティあるいは新しい発見や提案のほとんどは無視される。またフレームワークやプラットフォーム、あるいは使用する言語についても、実際にコードを書くエンジニアに裁量があることはほとんどなく、「上流の」コードを書かないエンジニアによって決定される。
上流工程のエンジニアも、人によっては最新テクノロジーに精通している場合もあるが、やはりコードを書くことから離れてしまうと、コードの書き方自体のトレンドや最新フレームワーク、デザインパターンなどからは距離を置いてしまう。キャッチアップの時間が少なくなってしまうから、それは必然的ともいえる。またそもそもコードをほとんど書いたことがない「エンジニア」が仕様を決めたり、設計していたりすることもとても一般的だ。
つまり、ソフトウェア・プロダクトあるいはシステムなのに、コードと一体となった管理やメンテやリフレッシュがそもそも必要だと理解されていないのだ。またコード作業が外部ベンダーに委託されるということは、コード作業そのもにいちいちコストが発生することになる。当然、リファクタという概念とは相いれないし、経営側から見ても単純に「コスト」にしか見えず、そこに経営資源を投入する発想そのものが出てこないことになる。
以上のようにソフトウェア業界そのものの構造的な違いから、リファクタが根付いていない・導入されてない、と言えると思う。
ソフトウェア・システムがリファクタされないと…
リファクタされないデメリットは明らかだ。
一番顕著な例は、すでに「寿命」の尽きた言語が延々と使われ続ける、ということ。COBOLしかり、最近ではPerlも含めてもいいかもしれない。
オープン系のシステムではセキュリティの欠陥が残ったままになるという致命的な問題も招くが、閉じたシステムでも言語を知るエンジニアがどんどん少なくなり、システム更新に負荷とコストがかかるがゆえにどんどん先延ばしになり、さらに言語経験のあるエンジニアが減って更新が難しくなる、という悪循環に陥る。
言語自体は生き残っていても、使用されているライブラリやフレームワークが古いままだったりすると、せっかくハードウェアを更新しているのに思っているほどパフォーマンスが出なかったり、電力効率が悪かったりする。
またオンプレミスからクラウドへの移行も、クラウド自体がサポートしている対象言語バージョンやフレームワークのバージョンに追いついていないために進まない、ということも起こる(これは頻繁に起きている)。結果として古いシステムを遅いパフォーマンスで延々とオンプレミスのまま使い続ける、ということになる。
その時点ではコストは変わらないわけだが、実はコスト削減の可能性をどんどんつぶしている、ということだ。これに気づかない経営者も多い。
ソフトウェアはコストではない。当然それを実装するエンジニアもコストではない。企業の重要なアセットであり、未来のための資源でもある。1を作るだけで10の価値を呼び込むこともできる。リファクタは、「誰かの要求のままに」ソフトウェアを作ることから一旦離れることであり、エンジニアリングの観点から全体を最適化するチャンスでもある。まずその必要性に気づくこと。それなしには敗因を認めて追いつくことは不可能だと思う。
サポート Welcome! いただいたサポートは今後の研究開発や寄付に使わせていただきます。