パワーユーザー

「パワーユーザー」
この言葉に出会ったのは2010年の春ごろ。BIツールの記事でも書きましたが、当時の勤め先で基幹システムの入れ替えプロジェクトに参加したときのことです。SIerのエンジニアから聞きました。

Seesaaブログの記事ではあえて言葉の定義を正確に調べずに書き進めましたが、こちらのサイトではもう少ししっかり書くことにします。

調べてみると、パワーユーザーとは一般的にはパソコンに詳しいユーザーということらしい。
パソコンを自作できるようなハード面に強い人もそうですし、特定のアプリケーションソフトに精通している人をそう呼ぶこともあるとのことです。

当時私が聞いた印象としては、「ハード面」とか「ソフト面」といった切り分け方ではなく、実務レベルをアップさせる手段の一つとしてパソコンを使いこなす一般ユーザーを指しているように感じました。
つまり、システム担当者じゃないけれど、自分の担当業務用に基幹システムからデータを引っ張り出してくるとか、VBAのプログラムを書いてインターフェースをこしらえてしまうとかいったような人のことです。

ひょっとすると、私のことをそう見ていたのかもしれません。
基幹システムのサーバからデータを手に入れてツール化する術(すべ)を有していたので、SIerからは「パワーユーザー」に見えていた可能性があります。

彼らに対する説明の必要はないので黙っていましたが、私は彼らが想定するようなパワーユーザーとは全く違っていました。
そもそも経理部(のち財務部)だったので、アカウンティングの専門家で機械系は不得意。
特にその頃はプログラムなど全く書けない素人でしたし、パソコンの設定などは、いまだに想像することさえ苦痛です。

そんな自分でも、SIerに自家製システムツールの構造から開発にあたっての工夫までを細かく説明し、使いこなして見せることができていたわけです。私が作ったのではなく、自社のエンジニアに頼んで作ってもらったツールなのですが・・。

ということは、データベースを駆使してシステムツールを整え、業務を簡素化するユーザーが、必ずしもパソコンに精通しているとは限らないということです。
エンジニアとの良好な関係性を築き、彼らが開発しやすい適切な要件を提示できるならば、それも立派なIT技術だと思うのですがいかがでしょうか。

「希望したとおりに動くシステムの要件をシステムエンジニアに提示できる技術」で、自力(ラインの実務能力)と他力(エンジニアの技術能力)を組み合わせる合力(仕組む能力)というのがその実体ですが、パワーユーザーはこの「合力」にとても近い存在のように思っています。

しかし、非常に見えづらい領域の“力”であるらしく、私の経験上9分9厘の人が気付かず、説明しても理解されないシロモノでした。
当のパワーユーザーたちと話をした記憶をたどってみても、自力だけで完結してしまう人が大部分で、稀にエンジニアの技術を活用する人もいましたが、「やりたいこと」を伝えて、その実現のプロセス自体を丸投げしてしまうので、見かけ以上に工数がかかり、開発を中々進めてもらえないという実態ばかりが見られました。

一般的には、ほとんどが次のようなケースになっていると思うので、実例をひとつお話します。

●『業務に精通 × アプリケーションに精通 = ハイパー属人化』 の分水嶺

かつて会計事務所にいた頃、私とは別クライアントに常駐していた仲間が、そこの社員から引き継いだ仕事の中に「エクセルファイル30個を連携させて行う管理会計業務」というのがありました。
ノウハウを組み合わせていくうちに、エクセルも複雑に組み合わされていったようで、開く順番を間違えるとデータの整合性が破壊されるという恐ろしい造りになっていたそうですが、それを使わないと仕事にならないとのことで、習得に必死になっていました。

私の仲間であった彼はプライドの高い努力家で、やがてはその複雑さを克服し、業務をうまく回すためにさらに工夫を重ねました。
エクセルとがっぷり四つに組む、力仕事のようなその業務に張り合いを感じてもいたようです。
重ねた工夫によりエクセルのファイル数はさらに増え、久しぶりに顔を合わせた時に話を聞くと、連携させるファイル数は、さらに倍以上になったと言います。

ちなみに彼の前任者のベテランさんは、その業務に精通していた方でしたが上司との折り合いが悪く、退職の理由もそこにあったようです。それゆえ、彼に求められているのは単に業務を引き継ぐことだけではなく、個人に偏りすぎてしまったノウハウを標準化して、複数のメンバーで共有できるようにするということもあったはずです。

しかし、彼の頑張りは、そうした周囲の願いとは逆の方向へ突っ走っていきました。
抱え込んでいたスキルを気前よく開放するとしても、連関する70以上のエクセル表の説明など、業務の合間に聞いて習得できるものではありません。
「後任者に教えておいてくれ」ということになってしまいます。

前任者が独占していた業務スキルを、今度は彼が独占することになったのは当然と言えます。
そして彼は自信家でもあり、コミュニケーションは積極的ですが多少カドもあるという、要するに「生意気なヤツ」でした。

私などから見ると、そこに彼の面白さがあったのですが、どう感じるかは人それぞれです。
つまり、好き嫌いが実にはっきりしているタイプなので、何かのきっかけで前任者のような役回りを演じてしまう危険性もあったわけです。(客先なので、そこまで酷いことにはならないと思いますが)

どこの職場にも、頼れるベテランではあるが、人付き合いには難があるタイプはいると思いますが、そういう人がハイスキル業務を担当していて、誰も口出しのできないポジションに君臨している現場って、周りはかなりやりづらいと思います。
おまけに、そのスキルをさらにITスキルで二重に武装してしまったら、仮に本来の業務スキルで論破できたとしても、今度はプログラミングという厄介なタコツボに逃げ込まれてしまいます。
同じ業務ラインの人間では歯が立たず、システムエンジニアを連れてきても、彼らがラインの実務に口出しすることはまずないので戦いにはなりません。
ここまでこじれると、エンジニアの協力でシステム化しようとしても、ノウハウの提供に協力しない等の、業務スキルとは次元の違う問題が発生します。

システム化とは、その時の人間同士のコミュニケーションの姿を顕すものでもあります。
シームレスな仕組み作りが難しいのは、つなぎ目の部分がうまく作れないからです。
そして、基幹システムは言葉を換えれば「総合シームレスツール」ですから、今できるレベルのシームレス化を固定するものとなります。

だから、全社の基幹システム導入に合わせて画一的に標準化しようとしても、人間関係で厄介な問題をはらんだ部分のシステム化がうまくいくことはなく、それよりも、現場からパワーユーザーを追い出すことが基幹システムの果たす役割になったりします。
コミュニケーションを顕現化するのがシステムなら、それを逆手にとって「厄介者がいなくなった現場のコミュニケーション」を念頭にシステムを企画すれば、完成の暁には厄介者にとっての居場所がなくなるというのもまた真実だからです。

しかし、そんな「追い出し作戦」が成功するためには、よほど力を持ったリーダーが、断固たる態度でシステム化プロジェクトを仕切らねばならず、一人のパワーユーザーを追い出すためにそこまでのリスクをとるのは経営者でも二の足を踏むかもしれません。その結果、タコツボには触らずに、システム化したいハイスキル部分以外のところだけが基幹システムに乗っかるだけという、あまり効果のないシステム化になったりします。

このような失敗は、自力と自力の接触部を片手で固定しながら稼働させている状態(「仕組み」ではなく「状態」)を築いてしまったことに端を発しています。
立ち上げ当初にその状態になってしまうのは仕方ないし、当然ともいえますが、その状態が長いこと放置されていることが問題です。

この状態は、業務のボリュームが増えた時には「人を増やす」という解決法(?)が大手を振ってまかり通る危険と背中合わせです。ここで増員を渋りすぎると社員の離反や病人の発生により、ここぞという場面なのに思うようにアクセルを踏めなくなります。
かといって、単に人を増やしても教育制度が整っていないので、人件費に投資した利回りは極めて低いものになってしまいます。

それを防ぐにはどこかの時点で自力×他力の姿にするか、最初から他力と組み合わせる前提で自力を高める段取りをしておくのが、竹の節のように会社を育てていくための方法として有効です。

こういうことはパソコン操作やシステム導入に限った話ではありませんが、情報過多な現代では、キーを叩く指先の動きひとつで、何千何万の行動記録をまとめ上げることができてしまいます。
自社の社員の行動、顧客の行動、ライバル他社の行動など、様々な媒体から簡単にデータが取れるだけでなく、次の行動を読んで仕掛けることが容易な「ITを避け得ない時代」ですが、「IT」という言葉が一般化して15年程度では、まだ模索段階なのかもしれません。

「企業のシステム化」「大量データの利活用」の問題には、様々な角度からのアプローチが可能だと思いますが、私はここで「パワーユーザー」という存在から切り込んでみたいと思います。