ブログ

「楽しむ」

「楽しむ」

 

うちのお客様に

「楽しくなければ仕事ではない　

楽しくなければユニフォームじゃない」

というＣＩを掲げるところがあった。

 

つまり、ユニフォームを着る喜びを提供する立場。

 

この話をあるお客様でしたら

「仕事を楽しいと思ったのは最初の頃だけ」

と返ってきたのだ。

 

確かに「限界効用逓減の法則」があって

例えば、ビールは初めの一口が美味しいというように

二口、三口となると美味しさが薄れる

という事があるように

何事も最初は興味があって、

結果に期待感がありワクワクするのだが

そのワクワクが回を重ねる度にドンドン薄れる

というのが一般的なようだ。

 

つまり、「未体験」という要素が大きいのだ。

 

ビールは「未体験」ではないにしても

その時の一口が喉を潤す際のインパクトが新鮮

という事と考えると

「仕事」においてもヒントになる。

 

このお客様は大手ソフト会社の１次下請けのポジションで

業務の大部分は大手が作った仕様書に基づくソフト開発で

自社要員と派遣会社からの要員で行なっていた。

 

つまり、マクロに見ると

開発言語は同じであり、仕様書に従って作業する

という感じだったので

できたソフトがお客様で喜ばれる姿に接する事がなく

納期遵守やクレーム処理というプレッシャーがある

という構図だった。

 

従って、「喜ばれる」という期待感が殆どなかったのだ。

 

しかし、ある会社の販売管理システムの改善があり、

業務のサブシステムだが打合せから制作までを

若いＳＥが担当したことがあった。

 

ＩＢＭのＡＳ４００というオフコンのお客様で

規格された階段を図面に従って現場に合うように設計変更して納める

という業務だったが、大きく４工程に分かれていて

製造番号の商品が「どの工程にいるか」を表示する

という要望だった。

 

この業務に作業指示書にバーコードを印刷して、

バーコード・リーダーを使って読み取り

各工程に届いた時、作業の内容に応じたリードタイムを加えて

工程作業完了予定の日付を記録する

という仕掛けだった。

 

この最大課題は

ＡＳ４００でバーコード処理をした経験がない

という事であり、

チャレンジという意味で若いＳＥが担当した

という経緯があった。

 

会社として未体験だったが、ＩＢＭの担当ＳＥなどに相談して、

端末の５２５０エミュレーションで読み取る方法を調査して

納入時にＯＳに設定する条件変更も用意したのだ。

 

勿論、販売管理のソフトを改良する打合せも行い

指示書にバーコードを打ち出す方法や

読み取った工程データを管理する方法

なども打ち合わせてサブシステムを開発した。

 

実際に納入した際に

工程データのデータベースを

工程毎に完了予定日の順に表示する

筈だったが、仕様ミスでうまく表示できなかったのだ。

 

そして、各営業所から自分の伝票番号で照会すると

本来なら現在地を示す筈だったが出来ていなかったのだ。

 

これを現地でお客様の要望を再確認して、

データべ－スのパラメータを変えてスンナリと出来た時

若い担当者とお客様が喜びで握手したのだった。

 

しかし、このような力量に応じた開発は少なく

大手が着手しない少額のソフト開発を請け負った時には

お客様の業務を理解することもままならず

予定通りの日程で進まない上に、納めたソフトの調整が多発

となって会社自体も能力オーバーとなり、

外部からの要員を追加して納期短縮に追われた

という結果になった。

 

つまり、単機能のサブシステムでは「喜び」を感じて

「楽しい」を実感できたが、

企業全体の総合的な開発になると業務知識が不足して

お客様との打ち合わせも遅々として進まないのでストレスばかり

挙句の果てはチームで制作していたが、

会社の予算管理の要求圧力が負担になり

終にはノイローゼになったのだ。

 

何事も能力以上のことにチャレンジすることが大切だが

普段は下請けなのでお客様と向き合わないので業務知識に欠如があって、

お客様もイライラするので「楽しむ」ということが出来なかった。

 

ホンマ、利益中心の考え方で経営されていたが

人材育成という視点に「業務知識」というベースが

下請けばかりで欠如していたのだった。

 

「人材育成」は永遠の課題だが

「お客様へのお役立ちがあって喜ばれるというベーシックな課題」

と認識して、その為に「喜ばれる」ように工夫することが

「楽しむ」ということの根本だと痛感したのだった。