同じ作業手順を何度か行うと、手順書を確認しなくても体が覚えてしまう。

その熟練状態を想定して工数を算出している会社もあれば、あくまで手順書を読みながら進める事を求める会社もある。どちらの言い分も良くわかるし、それぞれが各々に発注して戴けるのであれば、その通り対応するだけだ。

しかし、実際は、手順書を読みながら作業するだけの充分な時間を確保せずに、熟練状態の工数を元に作業人数を設定して、尚且つ手順書を一つずつ追うように求めてくるご依頼企業もあって、分厚い手順書を当日に渡し、熟練者のベストパフォーマンスを期待されても、作業者は困ってしまう。

それでもこの業界は、不思議なもので初見である程度のスピードを保ち、手順書を漏れなく追って、一度通してしまえば手順覚えてしまう、なんて作業者もいる。それで、手順書を全然見なくなってしまうのも困りものなんですが、手順を覚えてしまうよ系の作業者は、どうして初見の作業で覚えれてしまうんでしょう。

今日は、そんな手順を覚えてしまうよ系の作業者の話ができればと思いました。

すっごい記憶力・・みたいなものも確かにあるにこしたことはないのですが、まずは経験です。類似作業をいくつかやっていると、項目の名前でまず並びが理解できます。自分が手順組むならドメイン参加してからこの設定だなとか、このアカウントのうちにこっちの作業も並びでやっておくんだ・・とか、大まかな手順がまず整理されます。そして、細部も、このチェック外すのか、こことここはデフォだよね。とか、印象に残していくので、イチから記憶しているわけではないのです。

それでも、そういう作業者を想定して工数を組むのはやはり愚かです。普通に慎重な作業者を想定して工数予定を立てないと、時間はいくらあっても足りないし、手順書遵守は絵に描いたモチになってしまう。でも、作業者の姿勢として、いつもいつも手順書の表面だけを追って意味を理解しないのではいつまでたっても技術力は向上しないし、時間に対する感度も鈍いまま。向上心足りないよね・・と思われてしまうのです。

いつもいつも、管理者としては手順書遵守を唱えているのですが、ちゃんと理解して一見で覚えてしまえるような作業者がたくさんいると心強いですね。

今日は、当社の鉄則の1番目を紹介。

１．作業開始時間には、充分余裕を持って到着する。

エンタープライズものの下請けをする上で、まずはじめに意識しなければならないこと。それは遅刻の撲滅です。遅刻してしまうとその後どれだけいい品質の作業を行おうともリカバーできません。一般的に法人向け業務で作業開始時間に遅れた場合、お客様より契約違反と言われてしまいます。単なる遅刻とはとらえられないのですね。一般的なビジネスシーンであれば電車の遅延などの交通トラブルがあれば一報入れれば済むことですが、ＩＴサービサーはそうはいきません。トラブルを想定した上で、時間には十分な余裕を持って到着して頂けるよう作業者にはお願いしています。

また、出発・到着をメールで入れてもらう発着管理や、30分前集合等、お客様だけでなく同業者からも評価いただいている仕組みを多く持っています。

特に、集合場所から作業場所まで距離のある工場や、入管申請の時間がとられそうな建物内テナント、人数が多く点呼に時間のかかりそうなところでは、更に注意喚起をおこなって作業者に余裕をもった集合を意識してもらっています。

当社はフィールドエンジニアリングの会社だ。

フィールドエンジニアというのは、お客様先にご訪問して導入・設定・保守等のサービスを行うＩＴエンジニアで、プログラマだったりシステムエンジニアだったりするところとは業務の守備範囲が異なる。

サービスエンジニア・カスタマーエンジニア等と呼ばれたりもする。

当社は、大企業や官公庁などいわゆるエンタープライズをメーカーの下請けとして行うスタイルを得意としているけれど、中小企業向けのコーポレートソリューションを得意としているところや、一般家庭向けのコンシュマーを得意としているところなど、同業者でも特色は色々ある。当社も一応全てに対応している。

作業者もどこを向いているフィールドエンジニアかによって、必要となる技能や常識が大きく異なり、それぞれをきちんと説明できる人というのはなかなか存在しない。多くは自分たちこそ常識的だ、とそれぞれ特化してしまっている。

まず当社の主力である、エンタープライズでは、「作業者は勝手な判断をしない」が全てのベースとなる。コントロールするセンターが作業内容を全て取り決め、イレギュラー情報を全て吸い上げ、決定した対応を作業者に伝えて作業を行う。切り分けの前提となる予備動作が行えないことから、いわゆる「スキルが高い」人が問題行動を起こしやすい分野で、ここのノウハウは一般的には常識的では無いことも多く貴重なものだ。

次に中小企業、いわゆるコーポレート対応のソリューションでは、「解決力」がベースとなる。試行錯誤や短時間でゴールにたどり着くための切り分けの優先順位、トラブルシュートのための引き出しの多さ等、一般的にイメージしやすい「技術力」がものをいう世界だ。属人的なノウハウが多く、単金も難易度によってバラつきが大きい。

そして最後にコンシュマー。コンシュマーも直接契約型と、量販店や回線業者、プロバイダ等を経由したBtoBtoCタイプがある。直接契約のBtoCタイプでは、直収になるので金額を回収するスキーム作りやクレーム処理等のノウハウが大切だし、BtoBtoCタイプではセキュリティの厳しさや単金を採算ベースに乗せられるかなどの課題をクリアする必要がある。作業者のスキルとしては、完結力に加えて一件当たりの訪問時間を短縮していく効率性が求められる。

しかし、総じてフィールドエンジニアの仕事は楽しい。役に立っている実感が直接味わえるし、プログラマなどのデスクワークにはない魅力がある。だから一回この業界にきてしまうとずーっとフィールドエンジニアで良いかなと思ってしまう人は後を絶たないし、ある程度年をとっても続けられる職種だとも思う。

キッティングの話の続き。一つ目のノウハウは正確さだった。

もうひとつは、効率。

キッティングに時間をたっぷりかけられることなんてスケジュール的には殆どない。だから正確さを追求しながらも、効率を最大限上げていかなくてはいけない。パソコン触ったことのない安い労働力と、ＩＴのプロでは、そもそも手の速さがまるで違う。単純に時給換算してしまっては最適な効率を導き出せない。

更にキッティング単価を詰めてしまうと何が起こるかというと、なんとキッティングをせずに現地に送り込む、という事をしだす。現地で一台一台行うことと、一斉にできる設定を広い場所で並列作業を行うのではどちらが効率的か、なんてことは誰だって知っているし、そもそも事前キッティングというのが、お客様先での工数を極力減らすことと全体効率を最適化するために存在するのに、事前キッティングをしないなんて選択肢はあり得ない。

短納期で、現地作業の日数を減らしてしまうとしても、キッティングをしてから送り込んだほうが効率的だ。しかし、それが見えなくなってしまう。

手順書の作成を端折ってしまったり、初回の作業者説明を省略してしまうのも、後の効率を考えずに目先の進捗にとらわれてしまった結果だ。

かくしてプロジェクトは炎上し、最終的に追加要員をどんどん放り込み人海戦術で最終処理を行うことになる。予算も無尽蔵に必要となる。

効率を考えたときに、単純作業の流れ作業と思われがちなキッティングにプロの手を使うのは大切なことだ。安く・安くは、高くつく事になる。

当社はフィールドエンジニアリング、サポートエンジニアリングを中心にＰＣサポートを行っている会社で、ＩＣＴ業界では珍しく開発を行わずに導入・運用フェーズに特化した会社です。

特に、「キッティングサービス」においては、創業以来力を入れていて倉庫内・工場内・客先問わず、経験豊富なスタッフをたくさん抱えていて、ノウハウが面々と築かれている。

キッティング、と言われても一般的にはピンと来ないかもしれないけれど、ＰＣ導入などの際に使える状態まで設定を作りこんでいく作業の事だ。企業によっては、現地の導入作業前の出荷前作業だけをキッティングと呼んでいることもあれば、現地作業（動作確認）まで含めてキッティングと呼んでいる会社もある。また、現地で会議室などを借りてまとめて行える設定作業を現地キッティングと呼びならわして、個別に行う導入フェーズと分けていたりもする。

キッティングは流れ作業だ。ノウハウなんてあるのかと思う担当者もいるかもしれないけれど、間違いなく存在する。

一つ目は、正確さ。

流れ作業であるゆえに、なんとなく一つ一つの精度が低くなってしまいがちである。単純作業の繰り返しのため、普段ＩＴになじみのない人たちが動員されているケースもある。しかしながら、キッティングされたマシンはその後現地に送り込まれ、キッティングミスしたマシンは、その後の工数に多大な影響を与える。一定の割合でミスが発見されようものなら大変なことだ。お客様の要求で現地にて再確認作業が追加発生等の事案はいくらでも存在する。

では、どうすれば正確に作業を行ってもらえるか。一つは、「その1台1台が現地では大切なオンリーワンの1台で、この川上の工程であるキッティングがミスっているとその後の工数に多大なる影響がある」という事を作業者に認識させること。この説明を怠って、「ダブルチェック・トリプルチェックを行う」「チェックシートの項目を莫大に増やして・・」のような対策をよく見かけるが、キッティング品質向上の対応はそうではない。作業者の「認識」が第一だ。

続きは明日。