クライアント展開作業計画のポイントについて

今回はクライアント展開作業計画のポイントについての話です。クライアントをまとまった台数で入れ替える…というのは、機器が古くなり、OSが新しくなって古い物がサポートされなくなる以上、未来永劫ずっと続く作業です。全体的な流れも大切ですが、作業時間が長くなってしまいがちなのがこの作業です。計画作成時のポイントについてまとめてみます。

雛形の作成

端末を入れ替えるにあたっては、旧端末で動作するアプリケーションや各種設定等はすべて引き継ぐようにするのが基本路線となるでしょう。もちろんOS自体のメジャーバージョンアップ時や何かコンセプトを変更することを目的に作業する場合には必ずとは言えないですが、一度動き始めてしまったらずっと使い続ける事が「安全」ととらえてしまう人が多いのも現実であり、すべて引き継ぐことが非常に多いはずです。

多数のアプリケーションや多数の設定をすべて1台づつ行うわけには当然行きませんので、企業での端末展開では

  • 雛形を作成する
  • 雛形を展開して個別の機器を作る

ということはほとんどの案件で実施されると思います。

さらに単純ミスや仕様変更ふくめて雛形には多数修正が入ります。雛形自体の修正はしないで展開後に修正作業を行う事も可能ですが、効率を考えるとやはり雛形の段階でできるだけ多くの設定を取り入れておくべきであり、現実的には「雛形の修正を簡単に行える環境および雛形展開方法」を取っておくのが望ましいです。

  • 雛形作成用のマスター端末は案件終了時まで確保しておく
  • 雛形作成後のイメージはCD,DVD等に焼くのではなく、ネットワーク経由での配布ができる環境を整えておく(CD,DVDを焼く時間、メディアを入れ替える時間が短縮できる)

また、雛形の種類は極力少なくしておくべきです。機器構成や、ソフトウェア構成上どうしても複数の雛形になってしまうケースもあるとは思いますが、何か修正をするたびにすべての雛形への修正を間違えずに確実に行えるように管理しなくてはいけません。できれば1種類にしておきたいですね。

ミスや仕様変更発生時の自動修正ポイントを作っておく

前述のようになるべく雛形の修正や雛形への追加作業を行うのが望ましいのですが、それを確実にやって行ったとしてもどうしてもどこかでミスは発生してしまう物です。展開作業がある程度はじまった後でミスが発覚し、修正を行う必要が発生することも想定しておかなくてはいけません。

そのために

  • 雛形展開後、自動的にファイルサーバーの特定の場所にあるスクリプトを実行する
  • 展開作業中にファイルサーバーの特定の場所にあるスクリプトを実行するように手順書に明記し、チェックポイントとする

など、「修正を盛り込む場合にはここに盛り込む」というものを作っておくのがおすすめです。

もちろん構成がきちんとしていて、あとからグループポリシーやクライアント管理ソフトウェア等を使って修正を対象端末に確実に適用できるならそれで良いのですが、そういう事が文化的に、あるいは運用ルール的に難しいお客様の環境(他チームへの依頼事項となってしまう等)もあると思います。あらかじめ用意しておくとスムーズです。

雛形展開後のセットアップ作業は極力自動化する

これは私の好みなのですが、セットアップ作業は極力「自動化」しておくべきだと思います。なぜかというと、「人間はミスをする」からです。もちろん自動化してもその自動化プログラム自体にバグ、間違いが紛れ込むことはあるのですが人間の多種多様な間違い方やなれからくる油断のようなものとはプログラムは無縁ですから。分厚い手順書を毎日毎日同じ人間にずっとやらせるのは危険だと思います。

ただし、自動化する際にも「そこで何をしているのか」ということは別途明確にしておく必要があります。これを怠ると、自動化したものがうまく動いている間は良いのですが一度なにかの原因で動かなくなると作業が完全にストップしてしまいます。手動作業バージョンの手順書と自動化バージョンの手順書の両方が用意されているのが理想的です。

そして、自動化したものも間違いや修正が発生するのが世の常ですので、すぐに修正がきちんとできる状態にしておくのが望ましいです。一番はじめの処理でファイルサーバー上から最新バージョンを取得する仕組みにしておいて、修正はファイルサーバー上の1カ所で修正すればよいようにしておくなどの方法が考えられます。

作業の流れを工夫する

作業の中で時間短縮のためには流れを工夫する必要がでてきます。作業には主に以下の4つの種類があります。

  1. 雛形に組み込めるもの
  2. 管理者権限があればできるもの
  3. ドメインに参加した状態が必要なもの
  4. ユーザーアカウントで設定が必要なもの

雛形に組み込めるものはもちろん雛形に組み込めば良いでしょう。

管理者権限があればできるものにはドメイン参加やソフトウェアのインストール等があります。雛形に組み込めないこの手の作業は雛形展開後に自動実行されるのが望ましいです。

ドメイン参加後にしかできない作業はドメイン参加後に自動化して実施します。ドメイン参加後の再起動からの自動的なログオン、自動的なコマンド実施等自動化の流れを作ってしまうのが良いと思います。場合によっては先にドメイン参加してその上で設定後、ドメインから外した上で雛形を作成する……という荒技も場合によっては選択肢になります。(一応動くようです。)

最後にユーザーアカウントでの設定が必要な物ですが、ここが一番作業には効いてきてしまいます。

ユーザーアカウントで入った後にしかできない設定をどうするか?

ユーザーアカウントでログオンし、作成されたプロファイルに対して設定を行う必要がある…というものが結構な量存在するはずです。ソフトウェアの構成しかり、ユーザーの保持しているデータしかり。ユーザーアカウントに依存してしまうので、雛形の段階で組み込んでおく事もできません。なので、必ずユーザーの席に設置したあとでユーザーにログオンしてもらったあとで作業する必要がある……というのが自然な流れなのですが、その作業が1時間も2時間もかかるようだと時間的に問題になる可能性が高いです。

どのように時間短縮をすることが可能かというと、以下のような選択肢があると思います。

  1. ユーザーに長時間のセットアップを我慢してもらう。
  2. 事前にユーザーアカウントでログオンし構成を済ませる。
    1. ユーザーにログオンしてもらう。
    2. パスワードを教えてもらう。
    3. パスワードをリセットさせてもらう。
  3. 作業用のDCを別途作成し、そこでパスワードをリセットする。
  4. 手順書を用意し、ユーザー自身に行ってもらう。

どの方法で行くかは実際に作業に必要な時間やその会社の文化によって選ばれる事になると思います。何が正しい、正しくないという事もありません。ただ、引き出しは沢山持っておいた方が良いでしょう。

3の「作業用のDCを別途作成」というのは例えばネットワーク的に切り離した環境にDCをバックアップからリストアし、そのDCに対してクライアントを接続し、ログオンし、プロファイルを作成してしまうという荒技です。SIDがきちんと同一の物になるので本番環境のユーザープロファイルとひもづきますし、何も気にせずにユーザーのパスワードをリセットしてしまう事ができます。ただ、展開中に新規で作成されたユーザー等に関しては対応できないので、注意が必要です。

ユーザーデータの移行はどうするか?

クライアント展開作業で実際のところ時間の振れ幅が多く読みづらいのはユーザーデータの移行作業だと思います。ユーザーによっては全くデータを持っておらずすぐに終わるユーザーもいれば、しこたまデータを溜め込んでいるユーザーまで千差万別だと思います。さらに顧客によってデータはそもそもローカルに保存すること自体が禁止で、すべてファイルサーバー上に保持しているところもあれば、デスクトップ、マイドキュメントなどユーザープロファイルの場所に置く文化の所、どこに何があるかわからない無法地帯になっているところまで本当に色々です。移行に対する方針も顧客ごとにまちまちになりますが、多いのは以下のようなパターンでしょうか。

  • ファイルサーバー等を使って、ユーザーデータはユーザー自身が移行する。
  • 事前に移行が必要なデータはすべて指定した場所(マイドキュメントフォルダの中など)に移動しておいてもらい、それ以外は移行しない。
  • 拡張子で移行対象を決定し、すべてのデータを検索したうえで移行する。
  • 特定のアプリケーションの特定のデータはきちんと作業員が確認した上で移行する。(OutlookのPSTファイル、辞書ファイル等)

特にケアが必要なのは「ユーザーが普通認識していないが重要なユーザーデータ」です。ブラウザのお気に入りの情報や辞書ファイルなどが該当し、ユーザーが使用しているアプリケーションを把握した上でどこまでのデータを移行させるのかきちんと合意しておく必要があります。

データコピー作業自体のやり方も複数のやり方があります。

  • クロスケーブルで接続して直接コピーする。
  • 新端末、旧端末の両方を社内LANに接続し、コピーする。
  • ファイルサーバーを経由してコピーする。
  • 事前にrobocopy等で同期をとっておき、移行当日差分のみ移行する。
  • 重要で必要最小限なデータのみ先にコピーしておき、残りのファイルはネットワーク経由で順次送り込む。(その間ユーザーには使っておいてもらう。)

これもどれが良い、悪いというのは一概には言えません。何を優先するのかによって最適な方法は変わってくると思います。

手順書、チェックシートはとても重要

さて、実際に方式も決まって展開作業を開始…と行く前に、実際にクライアント展開作業を実施する方に対しての説明が必要です。手順書をわたし、チェックシートの記入方法も説明します。大規模な案件になると日本中、世界中で同時に展開…ということにもなりますし、関係者の数が多くなります。誰が見てもわかる手順書ときちんと確認ポイントが抑えられているチェックシートが必須になります。もちろんセットアップ後に自動でそれが成功したかどうかチェックするようなプログラムを実行させ、それによって確認をするようなことも部分的にできると思いますが、やはり何といっても人間が最後の砦です。

実際には展開作業を行う人数はかなりの大人数になる事もあり得ます。スキルもバラバラ、経験もバラバラということになるでしょう。だれがみても明確にわかる手順書が必要です。作業の現場はいろいろとイレギュラーなことも発生します、都度そこで得られるノウハウは手順書およびチェックシートに反映される必要があります。更新方法、再度の展開方法も確立しておく必要があります。

モチベーション管理

実際の展開作業はチームで行う事が多いと思います。スケジュールや台数にもよりますが、展開作業が数ヶ月におよぶ事もあると思います。人によっては毎日毎日同じ作業をずっと継続するような事にもなります。人間ですから慣れも油断もでてきます。そして、ミスもでてくる可能性が高くなります。これを避けるためにチームリーダーはメンバーのモチベーション管理が非常に重要になります。単に機械のようにこなすだけではなく、その裏側でおこなわれているソフトウェア、ハードウェアの仕組みを想像したり、もっとより良い手順にするにはどうしたら良いかなどの改善案を考えたり等、できる人は色々と自分なりの視点を持って経験を得ているものです。「良いところ」「悪いところ」「盗むべきノウハウ」等を意識させながらうまくモチベーション管理をする必要があります。

半分冗談だと思いますが、「メンバーには必ず女性を1人は入れる」なんてノウハウも聞いた事があります。(たしかにタイプによっては有効なのかもしれない。)

今回はクライアント展開作業計画のポイントについて書いてみました。「これが正解」というものが無いのが難しいところでもあり、腕の見せ所でもあります。その他、ポイントとしてあげておくべき点があれば是非コメントにて教えてください。よろしくお願いします。

子供3人。家族優先。都内SIer勤務。Windows系中心のインフラよりの何でも屋。脱原発。 Microsoft MVP for Cloud and Datacenter Management.

コメントを残す

メールアドレスが公開されることはありません。