Part 5-d. Windows 10 導入時に考え方・やり方を変えるべきポイント – アプリ編④


さて、実際の既存業務アプリを考えると、「理想的なアプリ開発」が行われていないことが多く、「理想的なアプリ互換性検証」を行えない場合が少なくありません。短期的な対策としてはやむなしという部分も大きいですが、中長期的を見据えると、今のままのやり方を繰り返していては苦しくなるだけです。ですからここで今一度、「理想的なアプリ互換性検証」や「理想的なアプリ開発」を再考し、次のシステム開発で何に注意すればよいのか、を考えておくべきです。この観点では、マイクロソフトの社内のやり方に、参考になるヒントが多数存在しますので、少しご紹介してみることにします。

[事例:マイクロソフト社内のアプリ互換性検証作業の効率化]

当たり前のことですが、マイクロソフトの社内にも、皆様の会社と同様、多数の業務システムが存在します。マイクロソフト社内では、MSIT と呼ばれる社内 IT 部門が社内業務アプリを管理しており、経費精算アプリ、物品購買システム、マッサージ予約システム、出退勤管理システム、パフォーマンスレビューシステムなどなど、全世界トータルでは約 2,100 個の社内業務アプリが存在しています。こうした社内業務アプリをどのように Windows 10 WaaS に対応させているのかが、かなり詳細な事例情報として Web 上に公開されています。

image

https://www.microsoft.com/itshowcase/Article/Content/668/Deploying-Windows-10-at-Microsoft-as-an-inplace-upgrade
https://www.microsoft.com/itshowcase/Article/Content/519/Microsoft-IT-improves-LOB-application-testing-ensuring-readiness-for-Windows
https://www.microsoft.com/itshowcase/Article/Content/520/Microsoft-IT-prepares-LOB-apps-for-Windows

マイクロソフト社内の場合、非互換障害が発見された際には必要に応じてアプリ側の修正ではなく Windows OS 側に修正をかける、という点は一般企業と異なりますが、とはいえ非互換検証作業の具体的な効率化手法に関しては、参考になる部分も非常に多いです。なのでぜひ上記の URL をご確認いただきたい……のですが、英文全部を確認するのはさすがに大変だと思いますので、要点を私なりにざっくりと整理すると、以下のようになります。(間違ってたらごめんなさい;、古い情報と新しい情報が混在しており一部情報に食い違いがあったりしているため、完全に 100% 正しくはないかもしれませんが、細かい数字はともかくも要点は間違っていないはずです。)

  • 特に重要なポイント
    • 互換性検証を効率的に進めるため、グローバルで集約テストチームを運営している。
    • 2,100 個の業務アプリから 300 個を選出して集中的にテストしており、さらに段階的な OS 配布を併用することで、致命的な非互換問題の発生を防いでいる。
    • これらにより、互換性維持の費用を $700k/year (約 7,000 万円/年程度)にキープし続けている。
  • 具体的なテスト効率化の方法
    • ① テストケースの絞り込み
      • テスト対象システムの絞り込み
        • テストケースの絞り込みの前に、そもそもテスト対象システム(アプリ)自体を絞り込んでいる。
          • アプリケーションポートフォリオ管理ツールで、社内 LOB システム 約 2,100 個を一元管理。
          • この中から 約 300 個を Key Test Group として選出、これを重点的にテストし、その結果を元にアップグレードを判断。
        • 選出の観点は以下の 2 つ。
          • 業務の重要度 : 約 150 個
          • 技術的類似性や過去の非互換問題に基づく選出 : 約 150 個
        • 選出されなかったシステムは、特に積極的なテストはしない。
          • ただし OS 展開前に、ローカル部門の判断でテストできる猶予期間を 3 週間設けてはいる。
    • ② 見逃しリスクへの対応
      • 段階的な OS 配布
        • 社内アーリアダプタユーザ(ボランティア)が  Insider Program に参加して業務で利用
        • 見つかった障害に対しては R&D と連携し、必要に応じて OS 側を修正して互換性を向上させる
      • コード修正
        • 多くのシステム(約 80%)は内製のため、速やかなコード修正が可能。
        • 非内製アプリは修正に時間がかかるため、なるべくテスト優先度を高めている。
    • ③ テストの更なる実施効率化
      • 集約テストチームの運営
        • Key Test Group に関しては、グローバルで集約テストチームが積極的にテストを実施
      • テストの自動化
        • 自動化テストを駆使し、5 日間で全システムをテストできる状態を保ち続けている
        • 自動化率は 50~85% 程度
      • 仮想環境の活用
        • アプリ互換性検証はすべて仮想マシンで実施
        • ローカル部門のテスト容易化のために、テスト用仮想マシンの貸し出しを実施(※ 現在はクラウドを活用)

この事例でおそらく最も重要なポイントは、アプリ互換性検証の効率化を大きく高めたい場合には、会社全体としての取り組みが必要になる、という点です。これについて次に解説します。

[大企業への WaaS 導入時の注意点]

MSIT の事例では、個々の業務システムの開発チームがずっと個別に保守対応(互換性検証)を続けると限界があるため、会社全体としての最適化を図ることで全体の維持コストを抑える、ということをしています。実際、アプリ互換性検証の効率化を全社視点で考えた場合、会社全体として取り組むと効果が高いものと、個別システムで効率化を進めるべきものにわけることができます

image

しかし日本の大企業の場合、こうした全社最適化のアプローチが困難なことも実際には多いです。その理由は、以下のようなものです。

  • 各業務部門が異なる SIer・ベンダーを使っており、システムが個別最適化されている
    • 技術的アーキテクチャ、作業プロセスがすべて異なるため、全体最適化ができない
  • 予算管理・執行が分断しており、全体最適化が図られていない
    • IT インフラは標準化されているが、開発ツールやテストインフラは標準化されていない
  • IT 部門がインフラ管理に特化しており、アプリ領域の実態に関する知見を持たない
    • IT 部門側がアプリの作りや非互換検証の実態を把握できていない

image

社長目線で考えればこうしたサイロ化はどう考えても悪いわけで、これらの問題が解決されないと、ある一定以上の改善は困難なことが多いです。しかしその一方で、これらは現場の努力だけでは解決できないケースがほとんどであるため、経営層も巻き込んだ検討が必要になります。まずは自分たちだけでできる改善をしつつも、中長期的には全社視点での最適化を進められるよう、経営層に働きかけていくこともぜひ考えてください。

[近代的な業務アプリケーション開発を目指すために]

また、ここまでの話を振り返ってみると、既存レガシー業務アプリの Windows 10 WaaS への対応が困難な理由の多くが、保守フェーズを意識しない作りっぱなしのアプリ開発スタイルに起因していることもわかるはずです。私は新人の頃、先輩社員から「アプリは動けばよいというものではない、保守しやすいようにアプリを作るのがプロの開発者だ」と言われて育ち、今でもやはりこの考え方は大切にしていますし、実際、保守フェーズにかかるコストは開発フェーズにかかるコストよりも大きいと言われるぐらいですから、保守フェーズを意識してアプリを作るのは当然のことでもあります。納期に追われてそれどころじゃないとか、動かすのに手いっぱいで保守のことなんて考えてられないとか、そういう実情があることもわかるものの;、一方で、今のままのやり方を続けることができないのもまた事実です。

Windows 10 WaaS は時代の要求から生まれてきたものであり、業務アプリも、これからは基本的に「進化していく基盤上で動作を保証し続ける」ことが必要になります。このためには、開発手法や開発のガバナンスの考え方の見直しが必要になってきます。

image

では具体的にどのようなポイントを見直せばよいのか? に関して、特に重要な 4 つの点をピックアップしてみます。

  • テクニカルアーキテクチャ領域
  • 画面設計領域
  • テスト領域
  • 技術的負債への対処

テクニカルアーキテクチャ領域

先に述べたように、全社最適化のアプローチが取りづらいのは、各部門がアプリ単位に最適化を行ってしまうことが大きな理由の一つです。ですから、以下のようなポイントを検討することが重要になります。

  • 利用する開発技術と、作り方に関する開発標準の導入
    • 大企業では、各部門ごとに異なる SI ベンダーを利用し、SI ベンダーごとのやり方をそのまま採用しているケースも少なくない
    • 縛りを入れすぎると SI ベンダー側の生産性を損なうが、ある程度の「緩い」開発標準を導入して、『作り』に関する標準化を進めることは、運用や保守の容易化につながる
  • 具体的なポイントとしては…
    • クラウド PaaS モデルの考え方の利用(運用や配置などの流れを標準化できる)
    • 開発技術の「標準」パターンの策定(開発パターンごとに利用する技術を決めておく)

image

画面設計領域

日本で OS 間の非互換問題がここまで大きな問題になりやすい一つの理由は、UI に対する要求が理不尽なほど硬直的である、という点です。ですから、以下のようなポイントを検討することが重要になります。

  • 硬直的な UI デザインの回避(柔軟な UI デザインの採用)
    • 非互換問題のひとつに、日本ならではの職人的精密さを持つ UI デザインがある
    • しかし Windows OS の UI は、時代の UI トレンドに併せて進化してきている
    • 硬直的な UI デザインを行うと、OS バージョンアップ時にレイアウトが崩れやすくなる
  • 具体的なポイントとしては…
    • レスポンシブ対応による、様々なスクリーンサイズへの柔軟な対応
    • XP, 7, 10 などを振り返った際に、すべての OS で通用しうる UI デザインの採用(を考えておけば、硬直的な UI デザインを回避できる)

image

テスト領域

先に解説したように、テストの効率化は「後付け」で考えることが困難です。ですから、以下のようなポイントを検討することが重要になります。

  • 「テスタブル」にアプリケーションを開発する
    • 何も考えずに作ったアプリをテストするよりも、「テストしやすいように」作られたアプリの方が、圧倒的に効率的にテストを行うことができる
  • テスト駆動型(テストファースト)な実装スタイルを確立する
    • 「出来上がってからテスト」するのではなく、「作りながらテストも開発する」
    • 単体機能テストや結合機能テストをコードとして実装し、手作業で行うテストを最小化しておくことにより、繰り返しの互換性検証の実施が容易になる

こうした「先々の非互換検証」や「先々の機能追加」を見越した開発スタイルは、現在の多くの開発現場の開発スタイルと大きく異なるため、現場の実務レベルでの改善が必要になることにも注意してください(結構大変です;)。

image

技術的負債への対処

保守効率を落とす大きな要因の一つは、作りっぱなし・やりっぱなし文化によって発生する「技術的負債の蓄積」です。技術的負債とは、継続的・持続的な開発・テストを行う理想的な状態からの逸脱の度合いのことで、要するに、その場しのぎ・その場限りの作業を繰り返しているとものすごく保守がしにくくなっていく、ということです。

  • 開発中に積極的にテスト自動化を行っていても、ちょっとした緩みでコードが汚くなり、テスト自動化が困難になる
    • 随時更新型アプリやパッケージ製品(SaaS 型製品)などでは、テストの自動化は極めて重要
      • 特に随時更新型アプリでは、きちんとテストが自動化された状態を保つことは死活問題でもある
    • しかし、一時的であっても「実装作業」を優先させてしまうと、テスト自動化は急激に困難になることが多い
      • 開発中は「動くこと」を優先させがち = テストは後回しになりやすい
      • 結果として、設計やコードが汚くなり、テスト自動化がどんどん困難になっていくことがよくある
    • 継続的・持続的な開発・テストのためには、この技術的負債を常に一定以下に抑え込むことが重要になる
  • 主な「技術的負債」の例としては…
    • 行き当たりばったりなアーキテクチャや設計
    • 汚いコード、読みにくいコード
    • 文章化されていない仕様
    • テストコードが書かれていないソースコード
    • ソースコード中の積み残し作業(TODO 項目)
    • 無視されているコンパイラ警告
    • etc…

こうした『とりあえず動作はするが、汚いやりかけ状態の作業』をそのまま放置すると、保守・維持管理や再構築時に大問題となります。実際、業務仕様が不明なため、ストレートコンバージョンであるにもかかわらず再テストがうまくできずに膨大なコストと時間がかかる、なんていうのはよく聞く話です。こうした状況を生み出さないようにするためには、システム開発および保守フェーズにおいて、定期的かつ強制的に「技術的負債を解消する期間(リファクタリング期間)」を取ることが重要になります。

image

なお、ここでいうリファクタリングというのは、コードに限った話ではない、という点に注意してください。設計書、アーキテクチャ、テストなど、システム開発の成果物すべてについてクリーンな状態を保つことが大切です。お客様も我々も、「出来上がったアプリ」だけに目線が行きがちですが、「作ること」だけを是とするのではなく、「高品質に保つこと」も是とする考え方に変えていくことをしないと、結果的に全体コストは下がらない、という点に注意してください。

[まとめ-Windows 10 WaaS での既存レガシー業務アプリ互換性検証の考え方]

ここまで 4 つのパートに分けて、アプリの互換性検証の考え方について解説してきましたが、全体をふりかえって整理すると、以下のようになります。

  • Windows 10 → 10 の既存レガシーアプリ非互換を、過度に恐れる必要はない
    • Windows 10 WaaS に移行した後に、非互換検証を過度に繰り返す必要はない
    • 基本的なアプローチは以下の 3 つだが、既存レガシーアプリでは①②の対応しか取れないことが多い
      • ① テストケース割愛
      • ② リスク低減のための OS 段階展開と迅速な非互換障害修正
      • ③ 更なる互換性検証の実施効率化
    • 現在実施している非互換検証のレベルに基づいて、Win10 移行後の非互換検証方式を決めるとよい
  • 中長期的な対応としては、開発のやり方そのものに対する改善が必要
    • テクニカルアーキテクチャの領域
      • 利用する開発技術と、作り方に関する開発標準の導入により、全体最適化を図る
    • 画面設計の領域
      • 硬直的な UI デザインの回避(柔軟な UI デザインの採用)
    • 非互換検証の領域
      • 「テスタブル」にアプリケーションを開発する
      • テスト駆動型(テストファースト)な実装スタイルを確立する
    • 技術的負債への対処
      • 定期的かつ強制的に「技術的負債を解消する期間(リファクタリング期間)」を取る
      • これにより、アプリケーションを保守しやすい状態に保ち続ける

全体を振り返れば明らかなように、すべての施策を短期的に打つことは不可能ですが、短期的なところだけを見ていればよいわけでもありません。最終的に目指していくべきところ、すなわちシステム開発の近代化(Modernization)を意識しつつ、短期的対応と中長期的対応の両方を考えていくようにしてください。

# なお、私が所属しているコンサルティングサービスでは、(主に大企業様向けに特化していますが)Windows 10 導入支援や、開発近代化支援などのカスタムコンサルティングサービスを提供しています。Windows 10 WaaS 環境への移行や、システム開発を近代化して WaaS 対応はもとよりさらなる高開発生産性を目指したい、といったニーズに関しては、コンサルティングサービスにご相談ください。


Comments (0)

Skip to main content