実録レガシーコード克服秘話、必要なのは「ソフトスキルを生む環境」【デブサミ2016福岡レポート】

　苦労して作ってきたプロダクトのコード資産が、レガシーとなり新たな価値創造の足かせになる――。エンタープライズのLTS（Long Term Support）を担うエンジニアなら誰もが抱えがちな悩みといえるだろう。株式会社ドリーム・アーツでも大企業向けパッケージ・ソフトウェアの開発現場において同様の状況に陥り、試行錯誤しながら打開してきたと言う。その経緯と得られた知見について、同社取締役 CTOの石田健亮氏が紹介した。

株式会社ドリーム・アーツ 取締役CTO 石田健亮氏

過去のプロダクツのコードが
次世代の付加価値創造の足かせに

　2016年のIPA（情報処理推進機構）IT人材白書では、75％のIT技術者が事業会社の情報システム部門、SIベンダー、ソフトハウスといった受託開発に携わっていると言う。そうした多くのエンジニアが、レガシーとなったコード資産の管理・対応を担っていることが伺える。

　一方、株式会社ドリーム・アーツもまた石田氏が担当してきた多店舗運営を支援するコミュニケーションツール「Shopらん」をはじめ、大企業向けのプロダクトを提供しており、1996年よりVer.1が提供開始となった企業グループウェア「INSUITE Enterprise」など、延々とメンテナンスを行ってきた製品がコミュニケーションや業務の基盤を支えていることも多い。石田氏もまた、自由にプロダクツを開発していた立場から、「INSUITE Enterprise」の改訂・メンテナンスに携わることになり、その中でさまざまな問題に取り組むこととなったと言う。

　そうした中で、石田氏がエンタープライズに携わるエンジニア100人に問題についてヒアリングしたところによると、第3位はブラウザが古い、第2位がUIを変えにくい、そして第1位は保守が困難となった。

　まず、第3位の「ブラウザが古い」について実際に調査すると、エンタープライズで使われているブラウザはいまだIE8が約3割を占め、Firefox、Chrome、IEのさまざまなバージョンが続き、その上5％がいまだIE6を使っているということが分かった。

　さらに第2位の「UIを変えにくい」については、石田氏が「登録する」ボタンの位置が1pxずれたことで「社内マニュアルの変更がある」とクレームになったことを紹介。それだけ、UIはセンシティブで変えられない存在であることを強調した。

　そして、第1位の「保守が困難」については、オンプレミスであり、大規模で複数のバージョン、カスタマイズ、データ連携なども多々行われており、さらには導入パートナー会社も多いという、がんじがらめの状態であることが多いと言う。これが生じるのは、LTS（Long Term Support）が求められるから。いわゆる「レガシーコード」が発生してしまっているというわけだ。

　「レガシーコード」とは、ドキュメントもなければテストコードもない、そもそも"クソコード"であることが多く、設計もひどければ、使われている技術も古いという状態だ。しかし、そうはいってもそれが現実であり、なんとかしなれば何も変わらない。次の世代に、"ちゃんとした状態で"手渡すためには、どうしたらいいのか。

伏魔殿と化したエンタープライズの裏側
運用の原理原則も現場では無効

　石田氏はまずレガシーコード発生の背景について、「プロダクツ側ではなく、システム構築側に起きやすい」と分析する。つまり、よくあるSIer案件では、要件定義からカットオーバー、保守という時間軸の中で、価値はカットオーバー直後が最も高くなだらかに下がっていく。しかし、実際には要件定義で理想を描きつつも、なかなか進まずに納期だけが迫ってくるため、結局"やっつけ"で仕事をせざるを得なくなり、カットオーバーには要件が満たせず、ずるずると作業をやらざるを得ない……という状況に陥りがちだ。

　「会社からは予算オーバーするなと言われ、その間システム価値はどんどん目減りする。エンタープライズというとスマートな印象があるが、その実内部はドロドロのめちゃくちゃ。さらに何か連携先のシステムが変わるということで修正要望が上がり、調べてみると伏魔殿的で、よく分からず適当に修正し、再びトラブルが起き、調べてもよく分からず……というデススパイラルに陥ることになる」

　石田氏はレガシーコードが生じる背景をそのように説明し、「これに若者を巻き込むのは心苦しい。レガシーコードをこのままにしていても闇は深まるばかり。なんとかきれいにして渡すべきではないだろうか」と語った。

　「レガシーコードに光を」と、解決先を考えたときに、その方法として一般に言われているのが、ソースコードを発掘・管理し、バージョンコントロール下におくこと。そしてビルドやスクリプトを動かせる環境を用意し、テストケースでガードして、リファクタリングしながら少しずつ改善していくという方法だ。

　詳細は『レガシーコード改善ガイド』（翔泳社）や『リーダブルコード』（オライリージャパン）などの手引書に委ねるとして、石田氏は「それ以外の部分の知見も重要であり、今回はそこを紹介したい」と語る。

　実際、ドリーム・アーツでは、ジョエル・スポルスキが2000年に出した、ソフトウェアの開発チームのレベルを判定する「ジョエルテスト」をクリアしており、ソースコードも共有サーバーから、CVSなどを経て2016年からGitHubに切り替えられている。自動ユニットテストやテストカバレッジ計測、外部からSeleniumのテストも行い、ジョエルテストにもあった静かな環境を整えている。つまり、組織としては"ちゃんとしている"わけだ。ジョエルテストもほぼクリアしており、過去の仕様書の一部を整理するのみだと言う。

　しかし、エンタープライズの開発では、そこまでしても"伏魔殿"になりがち。その理由について、石田氏は「ソースコードの発掘などもろもろを作業しようとしても、『動いているものに触れないこと』が大前提となる」と語る。日本の美徳である整理整頓ができていない状況ながら、いわゆる原理原則では実際の現場には通用しない。それでは、どうしたらいいのか。