私の思い、私の主張!!

2010年5月 9日 (日)

「口蹄疫」の感染拡大がツイッターで走り回っている!!

私の住んでいる関東圏では殆ど報道されていないが、宮崎県の口蹄疫は大変な事態になっている様だ。

しかも、「風評被害」の防止の為の報道管制が敷かれ、口蹄疫の報道をテレビ等のメディアで放送する事を政府が規制しているとの事だ。

また、ネット上にアップされた報道映像などが規制により削除されているとの事だ。

ツイッターで「http://twitter.com/」”口蹄疫”というキーワードで検索してみれば現在の状況が理解できるはずだ。

新聞、テレビで報道されない内容が「つぶやき」という形で走り回っている。

もし、これ等の「つぶやき」が真実であったら、これは大変な事が日本で起こっている事になる。

2010年2月16日 (火)

以外に知らない「自分の仕事」

「業務改善」という名目でシステム化を依頼された事がありますが、その時一番驚かされる事が各担当者の人達は「自分の仕事を理解していない」と言うことです。
個々の作業やノウハウは「そんな事まで知っているんだ!?」と驚くほど知識やノウハウを持っている担当者が多いのですが、そんな担当者に「その作業の手順を書面化をお願いしたいのですが、出来ますか?」と訪ねてみると、殆どの人が「難しいですね!」とか「出来ません!」という答えが返ってきます。
更にしつこく「どうしてですか?」と聞いてみると「面倒だから!」とか「時間がかかる」と言う答えが返ってきます。
本当は自分の仕事の「立ち位置」が分からない人が大半で、自分の仕事の本当の始まり(発端)と終結(完結)の形を知らないからです。
それでも自分の担当している作業くらいは書面化出来ると思うのですが、実際に作業を手順という形に「変え」て書面化するには、作業自体の工程を細分化して整理しなければなりません。
一般的に仕事における作業は「言われた事を言われた通りに行う」というものです。
作業者としては、指示されて行っている作業自体の「順序」や作業自体の「有効性」などを考える必要が無かっただろうし、考えた事も無かったのです。
そうした背景があるからこそ「作業を細分化し、それを順序立てて整理して紙に書き出すなど私には出来ません!」と答える人が多いのでしょう。
データベース等のシステム化を考えるのは以外と簡単です。
単に蓄積したい情報の「項目」と、利用したい「場面」を想定して「画面」や「処理の流れ」を順序立てて作り込んでゆくだけだからです。
しかし、実際の「仕事で使えるシステム」を作るには、システムを企画、設計する人間がシステム化する仕事に「精通」している必要があります。
その理由は、利用する「場面」をイメージ出来なければ「機能」は整っていても「使い勝手」の悪い「使えないシステム」になってしまうからです。
システムを企画・設計する人は必ずしも「利用者」の仕事を理解しているとは限りません。
同じ業種、業態でも企業によってその仕事の進め方は違っており、そのやり方の違いこそが「企業の特色」である場合もあります。
だからこそ、システム開発を行う場合には、現場で直接作業を行っている人達にヒアリングを行う必要があるのです。
このヒアリングをいい加減に行うと、最終的に「使えないシステム」になる可能性が非常に高くなります。
「良いシステム」を構築するには「技術」や「スキル」よりも「現場」をよく知っている人と綿密に「意見のキャッチボール」をする事が重要です。
「良いシステム」とは総ての人に使いやすいシステムではありません。
システムは効率的、能率的に仕事を行うという「目的」を達成するためのツール(道具)です。
その「目的」を達成しようとする人が使い易いシステムが「良いシステム」なのです。
「良いシステム」を作る為には「自分の仕事を正しく理解している人達の助け」が無くては決して作り上げる事は出来ません。
こう書くとシステム開発者は「何の為に存在するのか?」と疑問に思われるかもしれません。
システム開発者は企画・設計の段階から「自分の仕事を正しく理解している人」から仕事を教わり、過去の開発経験等から更に「能率的、効率的」な手順を探し出し「自分の仕事を正しく理解している人」と意見交換をする事が重要な仕事になります。
そして、その企業に合ったシステムの形を説明し、納得していただく事がシステム構築の「肝」です。
システム構築や開発は「顧客が要望を出した内容を仕様書に纏め、それを基にシステムを作り上げる」と考えている方が多いと思いますが、これだけの手順で構築されたシステムの大半は「使えないシステム」となっています。
実際に稼働すると運用者が大変苦労するという場合が多いのです。
「大規模で単純な機能しか持たないシステム」であればそれで問題は有りません。
しかし、そうした「大規模で単純な機能しか持たないシステム」だけで実務が完結出来ない為、サブシステムを担当者が独自に構築する事が多い様です。
結局、仕事はシステムがあれば回るものではなく、「自分の仕事を正しく理解している人」が回しているのです。

東京日本橋カレー館の黒カレー

2010年NHK大河ドラマ「竜馬伝」の主人公になろう!
「坂元くん」

2010年2月 1日 (月)

ポータルサイトを公開しました!

ポータルサイト(http://www.ut-kokuzou.jp/)を立ち上げました!

本日デビューとなります。

今後は仕事のサイトとして育てて行く予定です!

2010年NHK大河ドラマ「竜馬伝」の主人公になろう!
「坂元くん」

2010年1月25日 (月)

POMERAでプログラムを書く

UWSCならばPOMERAでもマクロプログラムが作れます。

POMERAで直接動かせる訳では無いのですが、UWSCというツールを使えばWindowsで動くプログラムを作成する事ができます。

テキスト入力ができるツールはそのままプログラムコードが書けるからです。

私は今、求職中なのでハローワークのサイトを見る機会が多いのです。

そこで自動的にハローワークのサイトを開き、私自身の求職コードを自動入力して東京地区を選択するまでのUWSCのコードを書いてみました。

以下がそのコードです。

http://www.ne.jp/asahi/nrys/tkzw/Kyujin_UWSC.htm

http://www.vector.co.jp/soft/win95/util/se115105.html」のサイトから無料で使えるUWSCのツールをダウンロードして、上記のコードをコピーして張り付けるだけで簡単に動かす事ができます。

このツールの有償版は実行ファイルを作成できるので、自分の作成したプログラムをWindows上で実行する事もできます。

定型業務の自動実行等、高価なアプリケーションを購入する前に、こういった自作できるツールを試してみる事も面白いと思います。

MS-Office系列のアプリケーションの制御もできるのでこのマクロツールを習得する事で「毎回同じ操作をする」という「手間」を省く事が可能になる事請け合いです。

2010年1月 5日 (火)

問題解決の仕事!

この厳しい状況の中、無職の状態も三ケ月過ぎました。

年も新たに今回より過去のに経験した私の仕事について書き出してみる事とします。

今から7年程前に私はNTTコミュニケーションズのビジネス事業部に業務改善の担当者として席を置いていた事があります。

NTTコミュニケーションズのビジネス事業部の前進は「電電公社」という国営の企業であった為、非常に風通しの悪い企業組織であった様に記憶しています。

当時の私の仕事内容は、メタルの電話回線をそのまま利用してデータ通信を高速化するADSLの普及を企業相手に拡大するモノで、NTTコミュニケーションズのビジネス事業部の営業マンが技術的なサポートを受けたい時や、営業的情報を得たい場合にサポートする「サポートヘルプデスク」の業務改善が私の仕事でした。

ハッキリ言って参入当初からこの「サポートヘルプデスク」という業務事態が役割を終えた業務であり、業務改善をするよりは部門自体を閉鎖し、ホームページやWiki等の動的なシステムに機能を移行して行くべき部署であったと記憶しています。

しかし、当時の「サポートヘルプデスク」担当主任がパーキンソンの法則に従った様な人間で、自部門が役割の終えた組織である事を認めず「サポートヘルプデスク」の存続を支持し続けていたのが実態でした。

特に問題だった事は、その主任が業務内容を自分一人が持っているブラックボックス化している様な振る舞いをして、組織上層部を揺さぶっていた事でした。

当然、業務改善はその主任を「全否定」する内容から始まる為、業務改善者として参入した私が何か行動を起こす度に威嚇されたり、組合運動等と言われ突然中止されたりと度重なるな妨害を受ける事となっていました。

こうした妨害工作を平然と出きるにはそういった行動を許す風土、文化がNTTコミュニケーションズにはあるからです。

その主任は組合運動の職場リーダーでもあった為、NTTコミュニケーションズの上層部も迂闊に手を出せない問題社員でもあったようでした。

結論を言えば、私は三ケ月でこの仕事から外されてしまいました。

その理由はハッキリと問題を指摘し、解決策を出してしまったからです。

また、解決策はNTTコミュニケーションズの上層部も判っていた様子で、あえて私が後に残る人間の為にそれを提案事項として直接NTTコミュニケーションズの上層部に提示しなかった為であったかも知れません。

当初の予定では、私がNTTコミュニケーションズの業務改善プロジェクトに参入する条件として、前任者は総て退く事を強く要望をしていたそうです。

しかし上記のNTTコミュニケーションズの現場主任が「仕事が回らなくなった場合、私は責任を取れない!」等と上層部を揺さぶった結果、前任者は総て残り、その中に私が組み込まれる結果となったのです。

多勢に無勢とはよく言うもので、私の行動は常に監視されており、行動を起こす直前に必ず妨害されるパターンで追い込まれる事がしばしば有りました。

先にも挙げましたが、業務事態は役割を終えたもので、それほど難易度の高い内容では無いものでした。

また特別な経験も必要としない業務と言って良いレベルの業務内容だったので、引継や前任の支援など全く必要なかった様に思います。

むしろ新たに業務内容を組み立てた方が存在意義を見いだせたかも知れませんでした。

ここで言いたいことは「妨害工作」についてでは無く、NTTコミュニケーションズの上層部が現場主任に振り回されて判断・決断を誤ってしまったという事実です。

私はプロジェクト参入後、営業担当者と何度か打ち合わせを行いました。

そこでは現状の報告をしつつ、解決案を提示し続けましたが、営業窓口のNEXSも顧客との人間関係という不確定要素を重視して、私の意見よりも顧客の「政治」的判断を仰ぐという間違った判断を下してしまいました。

結果、私はこのプロジェクトを外され、その後、風の噂では結局「撤退」という事になったそうです。

この事例の失敗の原因は問題解決の責任者の判断と決断の誤りが揚げられます。

組織規模で大きな変化をもたらす行動を起こす時に、改革勢力を責任者サイドは全面的に援助する覚悟を決めなければ成功は望めません。

今回のプロジェクトは根本から間違った業務改善のはじめ方だったのです。

NTTコミュニケーションズの真意は「この部門の役割は終わっているので解体すべき!」と私の提案として言って欲しかった様にも感じました。

ところがそれを私が言わなかったので問題解決の時間を長引かせてしまった結果と成ったようにも思われます。

つまり、私がNTTコミュニケーションズの業務改善の責任者に頼られ過ぎた事が問題だったのかも知れません。

しかし、判断、決断をするのはあくまでNTTコミュニケーションズの業務改善の責任者です。

責任者は現場に依存し過ぎると大きなリスクを抱える事になる典型的な事例でした。

2009年10月21日 (水)

番外!「IT資産管理」はパッケージソフトのみでは不可能な仕事

番外!「IT資産管理」はパッケージソフトのみでは不可能な仕事

今話題の食用油「○○ナ」で有名な化学企業のIT資産管理のシステムはアセットスキャンという優れものだったと記憶している。
このパッケージソフトは監視用のサーバーに接続すれば各PCに設定したエージェントソフトがPCを立ち上げる度にその資産情報を送信してくる仕組みだ。
しかしこのシステムは各PC(クライアント)毎のライセンスが高価な為、エージェントソフトは導入せず、一部機能(サーバーへの接続情報の取得)のみで運用を行っていた。
当然、サーバーサイドのみの機能なのでエージェントソフトで取得できる情報は別の手段で取得せざるを得なかった。

「IT資産管理」とは、パソコン、プリンタ、ディスプレイ、周辺機器等のIT機器の資産情報管理及びソフトウェアのライセンス管理を行うものである。
こうした管理のスタートはIT機器の「払い出し」から行われるのがベストなのだが、一般的には既に払い出された機器の情報収集から手を付ける事から始めるのが普通だ。
「棚卸」というのがその作業なのだが、人手によるこの作業はハッキリ言って機器情報の取得に於いては正確性に乏しい。
既に「払い出し」されたIT機器の情報管理に重点を置くよりも、新規に「払い出し」するIT機器の資産情報管理に注力する方が効果的だと私は考えている。

先ず、新規でパソコンを払い出す場合、その企業での「標準」の企画でパソコンのセットアップを行う必要があるはずだ。
こうしたセットアップを行う作業を「キッティング」と呼ぶのだが、先に挙げた企業の様に大規模な組織では払い出す機器の数が半端でなく多い。
こうした機器に1台づつ一般家庭で行う様なセットアップは非効率である。そういった大量に同じ企画のパソコンを展開する場合、企画通りにセットアップされたパソコンのイメージをクローンコピーして「SID」を初期化(SYSPREP)してキッティングするのが一般的である。
このイメージのソフト情報を最初に整理取得しておけば、そのイメージでキッティングしたパソコンのソフト管理は容易にできる(アセットスキャンのサーバー機能はサーバーに接続したパソコンのソフト情報は取得できるが、スタンドあローンで仕様するパソコンの情報は取得できない)。
また、キッティング時にハード情報も正確に整理取得しておけばIT資産管理の大半は完了である。
過去に払い出したIT資産は修理や交換、廃棄や売却等で資産管理担当部署に返却された時に詳細情報を取得する以外に方法は無い。
ここまで述べれば理解されると思うが、「IT資産管理」はパッケージソフトのみでは不可能な仕事なのだ。

大きな企業体は事業毎にグループ化されているのが普通である。グループ毎に資産管理のルールとペナルティーも当然違ってくる。
例えば販売関係のグループにとってIT資産は間接費なので、常に正確な資産価値を行い部門利益を算定する傾向がある様だ。
そういった組織では中央の管理よりも先ず現場での管理を徹底しているのが仕事をする上での常識である(中央のシステムでの資産情報と現場での資産情報の誤差はそのままグループの利益・成績に直結するのだから当然である)。
よく起きた問題事例としては現場の情報と中央の情報の差異が甚だしく、訂正の処理依頼が頻発し、その処理が間に合わないというものだ。

資産管理を行う場合、一番大切な事は「運用体制」であると私はこの頻発している事象をみて確信した。
上記のの問題事例の「問題の原因」は資産情報の変更依頼からその情報の精査確認、そして資産情報の変更操作までを資産情報の処理担当者が独りで行っていた事だ。
私が以前提案した資産情報の変更までのフローでは、
資産情報変更の受付及び情報の精査確認は受付選任のコールオペレーターに行わせ、精査確認の終わった情報の資産情報変更処理の承認を管理者が行うようにし、承認の降りた情報のみを資産情報変更処理を担当する者に操作させるというものだ。
つまり、現場からの依頼を受け、精査確認する者、情報変更を許可する者、実際に除法を変更する者の3名の人間が関与する「体制」を確立することだ。
仕事の内容で担当者を分ける事により、仕事自体を単純化して効率を上げてゆく。
そして仕事の流れに滞りが出た場合、どの段階で問題が発生したかを正確に把握できるのが「体制」確立の狙いだった。
どういう訳か「提案」は無視され続け、現場からのクレームが止む事は無かったが、今でも私は仕事に対する「体制」を整える事が一番の問題解決だったと考えている。