仕事で大変なミスをしたら（下）

(「仕事で大変なミスをしたら（中） 」の続き)

さて、修正用ファイルの作成に取り掛かり始めた。修正が必要なデータを特定し、そのデータのIDを修正後データ1件1件に付与するという作業である。

2万件を手作業で処理することは膨大な時間がかかってしまうので、データを判定するためのスクリプトを書いてIDを付与した。
すぐに1万5千件くらいまではIDを付与することができた。これだったら19時くらいまでになんとか終われるだろうと思ったが、それは甘い考えであった。

20時くらいに”一応”全部対処した。確認をしてみるとどうもおかしい。正しいIDが付与されていないのである。よくデータを調べるとブランクとNULLが混在していて、意図した結果が得られていなかった。やり直しである。

スクリプトを書き直して、やはり、1万5千件くらいまではすぐに終わらせることができた。

夜中の3時時点で残りが1500件。疲労のせいで思考が鈍くなり、スクリプトを作ることが難しくなってきた。それでまた間違えても問題なので、1件ずつ目で確認して処理することにした。しかし、1時間かけて対処できたのは100件である。このままではあと14時間かかり、終わりが金曜日の17時を過ぎてしまう。ここから至難の業である。

4時を過ぎて睡魔にも襲われ始めた。なんとか7時までには終わらせたい。ちょっと目をつむると気が遠くなるのを感じながら、ロジックを考え、スクリプトを作った。理論的な思考がままならない中、何とか自分を奮い立たせ、眠くならないように暗示をかけながら作業をした。

6時になりあと300件が残っていた。最後は大きな山であった。スクリプトは一捻りのアイデアが必要なロジックであった。ときどき不意に頭がカックンと船を漕いでしまいながらも、意地でスクリプトを書き上げた。

なんとか朝9時までに修正用データファイルを準備することができた。そして2万件のデータを修正することができた。

プロジェクトの目的に使命を感じ、約束したことは必ず達成する。私はそこに自らの価値の最低ラインを置いた。つまり、少しでも人の役に立つために、「あいつに頼めば、約束したことは必ずやってくれることだけは間違いない」と言われることを目指しているのである。

今回のプロジェクトは期間が比較的短く、人的リソースも通常の半分くらいであったので、何度か時間的に厳しい状況に置かれたが、期限だけは死守してきた。

プロフェッショナルとして、またはそれを目指す者として、自分に対する甘えや言い訳を許さないことが重要であろう。

仕事で大変なミスをしたら（中）

(「仕事で大変なミスをしたら（上） 」の続き)

システム導入直前にミスに気づき、簡単に修正できないことがわかって、すぐにどう説明しようか悩んだ。素直に認めて「ごめんなさい」と言って済む問題ではないからである。かといって気づかなかった振りをするのは最低だ。それこそ問題が大きくなる。できるだけ詳しく正確に説明するしかない。さらにある程度の手を打って素早い対応ができるようにしておくことが必要である。

ここで「プロフェッショナル」ならばどうするかを考えた。

システムを利用するビジネスはもちろんのこと、可能な限りプロジェクトの進捗にも影響を与えずに修正することが最低条件であろう。

そのためにはどうしたらよいか。それには、ITのサポートを得ることが必要である。ただ、誰もがぎりぎりのリソースでこのプロジェクトに取り組んでいるため、多くの時間を獲得できる可能性は低い。修正用のデータを一発流して完了できるようにしたい。

気づいたのは夜だったので、次の日の朝まではまだ時間がある。この時間も使ってデータの準備しておくことにした。また、試しに手作業で修正を試みたが、1時間かけても1%も進まなかった。

そして、ITのサポートを得られない場合は、自腹を切ってでもoutsourceして修正する覚悟を決めた。

次の日、まずプロジェクトマネージャーに朝一で報告した。そしてまだアメリカは夜の8時くらいだから、向こうの担当者を摑まえられるかもしれない、ということですぐに連絡を入れた。運良くすんなりコンタクトを取ることができた。これからミーティングがあるからその後で詳しく話を聞こう、ということになった。

そのミーティングには私も電話で出席することになっていたので、その始まる直前に関係者に簡単に説明した。そうしたら、偶然か必然か、修正用のデータファイルさえあればシステムに投入できる権限を持っている人がいた。

ミーティングの後、修正用データファイルの要件を確認し、必要なシステムデータをもらい、修正用データファイルの作成に取り掛かることにした。

この日は木曜日であったから、この日中にデータファイルを作成して、金曜日の朝にはシステムへ投入して、午前中には確認作業を終了させいと思った。

(続く )

仕事で大変なミスをしたら（上）

プロジェクトで営業支援のシステム導入を進めている。その使用開始日の4日前に大変なミスをしたことに気づいた。とても1人で修正できる量ではない。プロジェクトメンバーは数名しかおらず、それぞれがタスクを抱えている状況で、これに時間を費やしている場合ではない。約束した日にちに達成できなければプロジェクトチーム自体の信用にも関わる。さあプロフェッショナルとしてどうすべきか。

そろそろ帰ろうかと思っているときに1通のメールが届いた。「（私が登録した）データがずれている」というのだ。指摘されたのは2件のデータだけであったから、「これだけ修正すればいいだろう」と思った。でも「ずれている」ということがどうしても気になった。よくよく調べるうちに、ある部分において全部のデータが間違って登録されていることに気づいた。

各営業から集めた約8万件のデータをvalidationしてデータベースに登録した。その内の2万件が間違っているのである。MS AccessからExcelにデータをコピーした際に、改行が含まれていて10数列ある内の2列だけが1行ずつ下にずれたのである。

日にちは約束している。既に数100名に2日間のトレーニングも行っている。今更延期が許される状況ではない。問題はcriticalである。このままでは絶対にシステムの導入はできない。

ITのサポートを得ることができなかったら、手作業でやらなければならない。その場合、4日間で修正するためには、10人が1日10時間集中して対応しなければならない。outsourceしたとして約100万円はかかるだろう。予算はもうない。

（続く ）

お金と時間以外のコストを考える

「コストを引き下げて利益を増やす」...資本主義においては使い古され、これからも使われ続けるセンテンスであろう。

コストは単なる時間やお金の出費だけではない。コストを下げるにはどうしたらいいか、を考える前にコストとは何かを考える必要がありそうだ。

コストは発生する場所で大きく３つに分けられる。

自社で発生するコスト、取引先で発生するコスト、顧客で発生するコスト。

私の長期的目標は「地球社会に貢献する会社」の実現であるから、自社のコストさえ低ければいいとは考えない。直接的、間接的に関係する人などのコストを引き下げることも対象とする。

さて、コストといった場合、お金と時間以外にどんなものがあるだろうか。

低い信頼性、面倒くさいこと、理解しにくいこと、、、これらもコストである。

クラウゼヴィッツ『戦争論』では、不確実性の源泉を「摩擦」と呼んでいる。計画通りに物事が進まないのは、摩擦があるからだ。だから摩擦を減らすことでその確度を高める努力をする。参画者が計画を理解していることが成功の鍵だとすると、その計画がどんなに優れたものであっても理解しにくい、1つ1つのタスクが面倒で気乗りしないようなものであったとしたらどうであろう。恐らく、摩擦が多すぎて成功は困難であろう。

言い換えれば、成功をより確実なものとするためには摩擦を減らすことである。摩擦を減らすにはコストを減らす必要がある。

企業が外部のリソースを内部に取り込むのもこれで説明がつく。簡単な例では、エクセルを高度に使える人を社内に配置しておくことで、いつでも希望通りにグラフを作成することができる。しかし、そのような人がいない場合、外部に委託しなければならない。そうすると、その手配から始まり、委託業務内容の詳細を伝え、費用と時間の調整をしなければならない。摩擦だらけである。

一方、顧客で発生するコストとは、ユーザビリティの低い製品を使うこと、予約が必要でその手間がかかるサービスを利用する、信頼性の低い情報システムを使うことなどである。得られるベネフィットと比較してコストが大きい場合、言うまでもなく顧客はコストを嫌い離れていく。

このように考えると、コスト削減のアプローチが変わってこないだろうか。つまり、使うお金を減らすことではなく、利便性や信頼性の改善と捉えることができる。そしてそれは同時に付加価値を高め、売上げを増加させる。

インド 有名プログラミング書籍は有名か

昨年から今年の3月にかけて 『Let Us C』 （邦題 『インド式プログラミングバイブル C言語入門 (上)』 ）というCプログラム言語の書籍の日本語訳をした。ヤシャバント・カネットカールというインド人が書いた本である。

インド式プログラミングバイブル C言語入門 (上)/Yashavant Kanetkar

￥2,520

Amazon.co.jp

これは、インド ITエンジニアではCプログラミングのバイブルであり、100万冊以上が販売され、大学や専門学校の教科書に使われているという。さらに、就職試験の出題はこの本からだされることが多いという。

たしかに、わかりやすい内容になっている。多くのプログラミング書籍が省略する、プログラム上では当たり前の、しかしながら重要なことがきちんと書かれている。実際に、この本を翻訳するにあたって巷に出ているプログラムの書籍を研究したが、売れている本はその点がもれなく掲載されている。

また、一度プログラムを勉強した方で、配列やポインタなどがわからずに断念した経験があるのであれば、再度チャレンジしてみて欲しい。丁寧な説明がされているので理解できると思う。確かに、プログラミングをするにあたって、細かいルールがたくさんある。でも、この本はそのことに触れながらも、難しさを感じさせない。とりあえず、こういうルールがあるんだな、という程度で頭の片隅に置いておいても、進められるようになっている。

さて、最初に、この本はCプログラミングのバイブルだと書いたが本当だろうか。

それを確かめるべく、職場のインド人たちで確認してみた。まず、翻訳した本を片手に彼らの前を歩いてみた。するとすかさず興味を示してきた。「何でそんな（インドの）本を持っているのか」と聞かれ、日本語訳された本であることを伝えると、「おー日本語もあるのか」と驚いていた。別のインド人はパラパラとめくりながら「イッツ ベリー フェイマス（とても有名な本だからな）」と言った。

この本は誰でも知っているのかと聞くと「ほとんどの人が知っている」と、そして就職試験にもでるのかと尋ねたら「そうだ」と言っていた。

確かに有名であることは確認できた。

すごい本を翻訳したんだな、と改めて思った。

生きることが社会貢献

社会貢献とは、何か。募金活動ではない、物資の提供ではない、ボランティアでもない。

社会貢献は、する人とされる人がいるが、それは違う。社会に貢献していない人はいない。生あるものは皆、社会に貢献している。

つまり、日常の生活が社会貢献に連なっているのであるが、人の中ではそれだけでは不十分である。

そう考えると、社会貢献は自らの身を削って行うことである。

仕事、家事、研究、勉強、遊びなど、何でも一所懸命やれば、少なからず社会に貢献するだろう。

同時に身を削ることが、自らのパワーの源泉にならなければ継続できないし、楽しくない。

誰もが生きることで社会に貢献することになる。貢献が生きる意味を与える。その貢献を一定のレベルを超えたものにするには、やはり努力が必要である。

組織の重さ by 沼上幹

今日は、仕事の後、組織学会の定例会に参加してきた。

「うん、うん」とうなずきながら聞いてきた。こんなことを私が言うのは僭越だが、今度投稿しようと思っている私の研究と（少し）重なるところがあった。

目的は異なるものの、利用できる調査項目はけっこうあった。そして、その結果も私が調べた結果と同じ方向なので、やっぱりこの流れだな、と実感し、少しだけ自信をつけた。

今日の内容は、組織がどれほどストレスなく活動できるかを「重さ」を使って説明したものである。重い組織とは、根回しばかりに時間が取られてしまっているような組織である。私なりに要約すると、これまでの日本の組織は創発が強みであった。しかしながら、その有機的組織ならしめていたプロセスは、時とともに組織を重くすることとなってしまっている。一方で、機械的組織は有機的組織と比較して鈍重のように言われてきたけれども、実は時とともに重さを増す有機的組織を軽くする効果があることがわかった。

私の研究は、知識労働者に焦点を絞ったもので、組織の重さ研究を参照して要約すると次のとおりである。

流動的な環境においては、それまでのように、上司やリーダーが指示・命令・統制をするよりも、1人1人の知識労働者が「相互作用」を繰り返しながら、主体的に行動することが重要である。だからといって、上司が不要なわけではなく、人事評価をすること、パートナーやメンターといった役割を果たすことが重要である。

(会計) 会議費

以下は、勘定科目「会議費」とする。

(1) 社内会議費 --- 1人 3,000円以内の社員のみの飲食。

ただし、ビール1本程度を超える場合、バーやスナックでの飲食は、勘定科目「交際費」とすること。

1人 3,000円を超える部分は、勘定科目「交際費」とすること。

領収書には必ず、出席者の氏名、を書くこと。

(2) 小額接待交際費 --- 1人 5,000円以内で社外の人と一緒の飲食。

1人 5,000円を超える部分は、勘定科目「交際費」とすること。

領収書には必ず、出席者の氏名、を書くこと。

テレビ・映画業界がオンデマンドでお金を稼ごうとしている矢先に

テレビ・映画業界がオンデマンドでお金を稼ごうとしている矢先に、ユーチューブで多くの個人たちが思い思いの映像を流し始めた。

この流れは誰にも止められない。著作権の問題は残っているが、加速するばかりである。あるデータによると、ユーチューブには毎分6時間分の映像がアップロードされ続けているという。

つまり、既に私たちは一生かけてもユーチューブの映像をすべて見ることはできないということである。

さて、倖田來未さんの一件について、メディアから流れるメッセージだけではなく、単純に事実を自分の目と耳で確認したかった。そのために、テレビに出演した時の映像が見たい、ラジオでの実際の発言をすぐに聞きたいと思った。ユーチューブで検索するといとも簡単に見つけることができた。しかも、複数のコンテンツがアップロードされていた。中には、アップローロドした人の意図が織り込まれて編集されていたものもあったが、未編集のものもきちんとあった。

私は未編集のものを見極めるためにいくつかのビデオを見なければならなかったが、それでも目的を達成することはできた。

マイクロソフトのヤフー買収についても、日本のメディアが流すメッセージ以外の情報を得ることができる。

たとえば、グーグルのCEO シュミットがヤフーのヤンに電話して、マイクロソフトの買収を防ぐ方法について話し合ったらしい。詳細は明らかにされていないが、ヤフーの検索サービスをグーグルにアウトソースするのではないかという「憶測」すらあるという。いずれにしてもグーグルは、マイクロソフトの今回の提案はインターネット業界の停滞を招くとして懸念している。

後日書きたいと思うが、グーグルとマイクロソフトは対極に位置している。そして誰が見てもマイクロソフトに分はない。だからヤフーの買収となるのは当然といえば当然の提案であるが、これはまだまだ些細な出来事であろうと思われる。

不眠症と企業との関係

コンピュータ、インターネットの普及とともに、平均睡眠時間が減少しているという。さらに不眠症を訴える人が増加傾向にあり、薬の宣伝もされるようになった。しかし、不眠症に対する理解はまだ低いように思われる。
不眠症は、交通事故、重大な労働災害、うつ病、心筋梗塞につながるから軽視してはいけない。

不眠症とは眠れない病気ではない。実際には眠らなければならない時に目が覚める、眠ってはいけない時に睡魔に襲われる、という病気である。
不眠症には4つの種類がある。「夜になかなか寝付けない」、「寝ても眠りが浅い」、「夜中に何度も目が覚める」、「早朝目が覚めてその後眠れない」というものである。さらにすべてについて共通で、本当の問題は、朝方や日中に眠くなってしまうことである。
たとえば、日中会社でどうしても眠くなってしまう。だから夜眠らないといけないがなかなか眠れない。12時くらいに布団に入ってもなかなか眠れない。そうこうしているうちに夜が明けて、5時、6時くらいにどうしようもないほどに眠くなる。それで寝て起きると、遅刻寸前であったり、遅刻してしまう。そして会社でまたどうしようもなく眠くなってしまう、というものである。

不眠症と「うつ」は、両方とも、周囲の人は「がんばれ」などと言ってはいけない。
本人は辛いので、なんとかしようと努力し尽くしているケースがほとんどだからである。むしろ、がんばらない方がいい。
薬もあるがそう簡単ではない。薬を飲んですぐに眠れるわけではないし、場合によっては朝に起きられなくなってしまう場合がある。

不眠症は精神的なものが原因であることが多いようで、生活習慣を変えるとか、眠る前に本を読むとかですぐに解決できるものではない。やはり、その原因となっている「気持ち」の部分が解決されないといけない。
ところで、寝る前の飲酒、テレビ、パソコンは覚醒の原因であることは確からしい。

さて、会社でのストレスや責任に対する重圧がきっかけとなって、不眠症を引き起こすケースがある。本当に重症であれば、職務を変えるとか、職場を変えることが必要であろうが、それでも本人はなかなか受け入れがたいであろう。なぜならそれは、降格にも匹敵するし、環境の変化を乗り越えるのも容易ではないと推測されるからだ。

残念ながら、特効薬がないのでここでは結論がない。
ただし、企業として（現実的には上司が）、不眠症の従業員をどう扱うか改めて考える必要がある。
「不眠症は本人の問題で会社は関係ない」、「いかなる理由があろうとも居眠りするのはダメだ」、「人は入れ替えればよい」という考え方をするのか、そうではなく、問題を主体的に捉え、少なからず原因は会社にもあるのだから一緒に解決しようとするのかということである。
従業員の能力を十分に発揮させたないならば、まずは不眠症をよく理解した上で後者の対応をすることが望まれる。