なぜ我々はソフトウェアの構造を時々見直さなければいけないのか (つまりリファクタリング)

我々のようなIT技術屋さんは時々ソフトウェアの構造を再整理したうえで作り直さなければいけないと言います。
これは技術的負債を減らすことで以下を獲得するためです。

• 安定性

• よりバグが少なくなる

• 価値の実現までがより短い時間で済む

• セキュリティ

• などなど

これはどの程度重要なのでしょうか。

ここではソフトウェアの構造が整理された状態でないことで実際に起こった問題を有名なリファクタリングプロジェクトの実例からお伝えします。Windows XPからWindows Vistaへの変化で起こった変化です。
(Windows XPからWindows Vistaへのアップグレードはリファクタリングであると主張します。もちろん追加機能がありましたが。)

Windows Vistaリリース当時私はサービスデスクでトラブルシューティングをしていました。

たくさんの組織から報告があったように、当時私が所属していた組織もWindows Vistaのロールアウトは、主にセキュリティ強化やアプリケーションの互換性トラブルなどにより大混乱を伴いました。

一般に非難の的となったWindows Vistaですが、私はトラブルシューティングの観点からは大きな達成だと思っています。主に日々のOSレベルの細かいトラブルを起こらないようにした点です。

Windows XPのソフトウェアの構造的な問題が起こした問題と、Windows Vistaでどのように修正されたか

Windows XPで日々報告されていた典型的なよくある問題が、Windows Vistaでは修正されて非常に起こりにくくなりました。
ここでは2つの過去よく見た問題と、それがどのような副作用を生んだかを見てみたいと思います。

フォルダ名称によるスクリプトやVBAのよく見るトラブル

サービスデスクでトラブルシューティングをし、チーム全体のパフォーマンス向上の片割れを担っているものとして、時々スクリプトやVBAを使ってサポートプロセスやチームの内部的なプロセスの短縮を実施していました。
スクリプトやVBAではデスクトップやお気に入りなど、ユーザープロファイルのフォルダ以下、つまりユーザー固有の何かを格納するフォルダを弄らなければいけないわけですが、このフォルダはこのような名前になっていました。

C:\Documents and Settings\{username}

他のシェルと同じように、コマンドプロンプトやVBAはフォルダ名スペースが入っているとフォルダ名を正しく認識してくれません。

業務側でVBAやスクリプトを書いたりするシチズンデベロッパーの皆さんは、スペースが入ったフォルダを扱うことで発生するエラーの撲滅に多くの時間を割かなければいけませんでした。

Windows Vistaや現在のWindows OSでは、ユーザープロファイルのフォルダ名はスペースを含みません。

C:\Users\{username}

非常に小さな変更ですが、スペースが含まれるフォルダ名を扱う機会を大きく減らしたことで、シチズンデベロッパーの皆さんの生産性を向上しました。

言語サポートにおけるよく見るトラブル

私は (当然ですが) 日本において日本語環境をサポートしていたわけです。

お気づきではなかったかもしれませんが、Windows XPの日本語環境って2種類あったんですよね。

• 日本語OS

• 英語OS + 言語パック

これ厳密には別のOSだったんです。
どのくらい違うかはこの後解説します。

Windows Vistaでは、もし私が覚えているのが正しければ、英語も含めてすべての言語が以下のような扱いになったと思います。

コアOS部分 + 言語パック

このアーキテクチャ的な変更がすべてのインストーラーをユニバーサルにし、多くのローカライズ言語問題を解消しました。

フォルダ命名規則

非常にわかりやすいWindows XPの日本語OS vs 英語OS + 言語パックの違いは、フォルダの命名です。
例えば我々がCドライブからフォルダ階層を辿り、ブラウザのお気に入りが格納されているフォルダにアクセスしてみたらどうだったでしょうか。

Windows XPの日本語OSの場合、フォルダのパスは以下の通り。日本語のフォルダ名が使われていました。

C:\Documents and Settings\{username}\お気に入り

英語OS + 言語パックの場合は、フォルダのパスは次のとおり、フォルダ名が英語です。

C:\Documents and Settings\{username}\favorites

つまり我々サポートする側は何か問題を修正する時に提供するスクリプトやナレッジベースの記事などでこの違いを意識した上で解決まで導くことが必要になりました。

インストーラー

影響は我々だけでなく、ユーザーサイドにもあるものです。

ユーザーは何かをインストールする際にはこのOSの違いを意識した上で適切な選択をしなければいけませんでした。

もし何かインストールするもの、例えばアプリケーションや追加機能、パッチなどがあったとして、インストーラーを実行します。
このインストーラーが日本語OSも英語OS + 言語パックも両方サポートしていれば良いのですが、もちろん環境ごとにインストーラーを提供しているものもありました。

ユーザーは自分のOSの正確な状況を把握していないことがほとんどです。
結果として我々の手元にはインストーラーの互換性問題に起因するチケットがたくさん記録されることになったのです。

OSの違いを認識しているユーザーは、何かをインストールするたびに、ある程度の時間を使って自分のコンピュータに見合ったインストーラーがあるかどうかを確認して回る羽目になっていました。

こういった余計な時間は、従業員の活動の本質であるビジネス的な価値創出に遅延を発生させます。

技術的負債が全員の生産性を下げてしまう

こういった例は通常我々が「生産性」という一言で片付けてしまうものです。
技術的負債は予期せぬトラブルを生み、それがまた別のタイプの予期せぬトラブルを生む連鎖を引き起こします。
一つ一つのトラブルが引き起こす遅延はそれほど大きくはありません。おそらく我々は今までこういったことを言ったことがあると思います。

「技術トラブルがあったので、ミーティングを来週にリスケしてもらえませんか」
「今日は残念ながらアウトプットを見せられません。予期せぬコンピュータトラブルによるものです」

しかしながらこれらが繰り返され積み重なるとビジネス的な価値の提供の深刻な遅延につながります。

技術的負債が少ければ少ないほど、ビジネス価値がタイムリーに、かつ摩擦の少ない状況で提供可能になります。
我々技術屋さんがソフトウェアの構造を再整理した上で作り直したい、という時にはこういった背景があります。