突然ですがみなさんは「キッティング」という言葉をご存じでしょうか。
私はIT業界に入るまではこの言葉を知りませんでした。
キッティングとは、一言で言うとPCのセットアップ作業を行うことです。
オフィスで使うPCは、そのほとんどが会社の持ち物（資産）であり、管理されています。
そして、ユーザーが不自由なく安全に使えるよう様々な設定でセットアップされた状態で設置されています。
かつて私は、PC管理者として数年間キッティング業務に携わり、どのような設定を施すかを設計し、実際にキッティングしユーザーに配備する所まで経験してきました。
「ただPC設定するだけでしょ？」と侮るなかれ。
この記事を読んでいただき、キッティングの苦労が少しでも伝われば良いと思います。
キッティングについて
キッティングとは先に述べました通り、手順に沿って間違いなくセットアップを行うという事であり、単純作業のように見えますが、気を付けておきたい事が色々とあります。
まずはキッティングとはどんなものか、もう少し詳しく見ていきましょう。
キッティングは統一された環境を提供するための作業
改めて、キッティングとは何のために行うのでしょうか。
オフィスで使うPCは、OSの設定やインストールソフトが統一された環境のものを使う場合が多いです。
理由としては、みんなが同じ環境のPCを使いセキュリティ設定や共通ソフトウェアを使うことで、一元管理し易くするためです。
私がかつて経験した現場では、その統一されたPC環境を「標準環境」と呼んでいました。
古いモデルのPCから新しいモデルのPCへ入れ替える場合や、PCが故障した時に端末交換をする場合は、標準環境にPCをセットアップするためキッティング作業を行います。
（キッティング手法や標準環境についても色々と奥が深いですがまた別の機会に解説します）
決められた手順通りにPCのセットアップを行いユーザーに配備することで、みんなが同じ機能を同じように使うことが出来ます。
また、OSやインストールソフトウェアのアップデート時にも、全台に同じ更新プログラムを共通のやり方でインストールすることができ、一元管理が可能になります。
キッティングは役割分担が決まっていることが多い
会社で管理しているPCの規模（台数）にもよりますが、何百～何千台と管理している場合、責任分界点を明確にするため開発部門と運用部門が役割分担として分かれていることが多いです。
私がかつて務めていた現場でもそうでした。
キッティングにおいて開発部門と運用部門は、以下のように分担されています。
開発部門・・・・PC管理者。PC設定や手順の設計を行い、手順書を作成し運用部門に提供
運用部門・・・・提供された手順書通りにキッティング作業を行ったり端末の入れ替えを実施
PCの設定内容やキッティング方法の検討、またキッティングの手順書作成など、設計部分にかかる責任は開発部門にあります。
設定内容の検討や検証を行い、手順に落とし込んで運用部門に手順を提供し作業を依頼します。
新しいソフトウェアの導入やアップデートにより手順書の修正があった場合は、その都度、開発部門が手順書を修正し、運用部門へ手順の差し替えを依頼したりもします。
一方、PCへのキッティングなどの作業面においての責任は運用部門にあります。
PCの設置や交換（端末の入れ替え）の手配等においても運用部門が担当する事が多いです。
新機種への入れ替えなどの大型案件では、まとまった台数を短期間でキッティングを行う場合があります。そのような場合、キッティング要員が多く必要になるため外部へ委託し人員を手配することもあります。
キッティングの大変さ
単純作業のような印象のあるキッティングですが、日々業務を行っていると様々な苦労や見えてくるものがあります。
出荷後に不具合（障害）があった場合はどこに原因があったのか追及
出荷後、実際に使うユーザーから、「ネットにつながらない」「アプリが起動しない」等の不具合があった場合、障害としてどこに原因があったのか突き止め、そして再発防止に努める必要があります。
ユーザーが問題なく使えるというサービスの提供が大前提なので、ユーザーが使用中に不具合があるとダイレクトに業務に支障が出てしまいます。
これは一番避けなければいけません。
障害発生時、開発部門は設計に問題が無かったか確認
開発部門としては、そもそもの設計に問題が無かったかを調査し必要に応じて修正を行います。
また、キッティングを行う時に使用する手順書に不備が無かったかも確認します。
紛らわしい表現であったり、ミスを誘発しそうな記載の仕方があった場合は修正します。
キッティング手順書は、作業者ファーストである必要があります。
障害発生時、運用部門は作業時にミスが無かったかを確認
運用部門としては、
・手順を飛ばしていないか？
・手順に無いことをやっていないか？
など作業時に人的ミスが無かったかを調査します。
（キッティングに限った話ではないですが）
手順に記載されていないことを実施したり、手順に書いてあるにもかかわらず、いらない手順だと勝手に思い込んだりしてその手順を飛ばしたりすることはやってはいけません。
キッティングの作業において手順通りに実施するというのは鉄則です。
自分の勝手な判断で進めるのは一番やってはいけない事であり、何か疑問に思う事があったらそこで一旦中断し、責任者へ確認する事が大事です。
手順通りに実施したことが確認できたら、そもそもの設定内容や設計に問題の可能性があるため、開発部門へエスカレーションし、調査を依頼したりもします。
開発部門と運用部門は仲が悪い！？
組織であれば当然の事として、開発部門も運用部門もそれぞれの自らの役割分担を明確に定めて業務を行っています。
何か問題が発生した際に、「こちらはしっかりやっている。原因はそっちでしょ？」的な事がしばしば起こります。
キッティング手順書ひとつ例にあげてみても運用部門からすれば、
「我々は手順書通りにやっている。問題があるとすれば手順書に不備があるんじゃないの？」
というスタンスであることが多いです。
作業ミスがあるとユーザー影響がもろに出てしまうのでこれは当然ですね。
一方、開発部門からすると、どこまで詳細な手順書にするか悩みどころです。
私もこれまでたくさん手順書を作成してきましたが、その中のエピソードとしてこんなことがありました。
コントロールパネルを開いてプログラムをアンインストールするという手順の際に、作業者から「どうやってコントロールパネルを開くのかわからない」と質問されたことがあり、正直「どこまで細かい手順にすればいいんだ・・・？」と悩みました。
当時よく「誰が見てもわかる手順書を作成しなさい」と言われており、その一件があってからは、作業者が迷う手順ではだめだということを特に心掛けるようになりました。
自分の立場や目線だけでみると正当化したくなりますが、目的はユーザーが不自由なく安全に業務を行えるようにする事なので、その目的を達成するためにお互いの立場を良く理解する事が大事だと思います。
まとめ
一言でキッティングと言っても、ただPCのセットアップをするだけではなく、
それぞれの立場でそれぞれの苦労があります。
この記事を通して、「ITにはそんな仕事もあったんだ」と知っていただけたら幸いです。
コメント