« May 2007 | Main | August 2013 »

July 29, 2013

リテラシーについて(2)

コンピュータリテラシーの問題は、なかなか解決するのがむずかしい。ちょっと考えてみても、實はプログラマでもない限り、パソコンじゃないと出來ない仕事はほとんどないからだ。どこの會社の業務でもパソコンがなかった頃は紙ベースでやっていたはずで、既にシステムに投入してしまったデータを除けばその頃に戾るだけで良い。日々の業務に限って言えば、元々紙ベースで仕事をしていた人はその方が速いと思うだろう。もし月次處理とか決算のような業務がなければ、傳票と帳簿だけで事足りるのかもしれないし、今でも零細企業や身内だけでやっている商賣などではそうしているに違いない。

よくある話として、同じシマの同僚とメールのやり取りなんてするな!という人が居る。面と向かって話せば良いではないかと。しかし、對面で話をするには相手が居なければならない。居なければ相手を待つ必要があるが、メールを打っておけばその人と意識合わせまでは出來ないにしても連絡は出來る。それと、直接話をするなら事前にあまり考えなくても良いが、メールとなるとそうはいかない。ある程度話を整理する必要がある。そこでリテラシーの問題が出てくるわけだ。

では、リテラシーを高めるにはどうすれば良いか。殘念ながらこれまで私が知っている限り、リテラシー向上硏修などというのは聞いたことがない。たとえばSEを10年もやっていればイヤでもリテラシーは向上すると思うが、そうでない人は何か別の、もっと具體的な目的のための硏修を受けて向上させていくのだろう。とにかくリテラシーを高めたければ、手當たり次第に硏修を受けたり、資格取得のために勉強し受驗したりするのが良いのかもしれない。ただし、會社組織などにリテラシーの多寡を評價する基準はないし、評價する方法もない。

むかしインタネットメールは、屆くかどうか分からない(途中で紛失するかもしれない)んだから業務に使用すべきでないと言われていたことがあった。しかし今ではどうだろう。そんな時期があったことすら知らない人たちが、每日當たり前のようにメールを書き、屆いたメールを電車の中でチェックするというのが日常化した。つまりメールは確實に相手に屆くというのが仕事上の前提になっていて、忙しい人は四六時中メールのチェックをするし、さらにはメールが屆いたら攜帶電話を鳴らす設定までしている人が居る。

電子メールがそこまでインフラとして定着すると、今度はメールの内容がどんどん陳腐化するようになった。まるでチャットのようなメールがどんどん行き交うようになったのである。むかしの郵便メールなら「オッハー!元氣?」とだけ書いて手紙を出す人など居なかったのが、電子メールではそれが當たり前のようになった。攜帶電話による電子メールの弊害である。こんなのはまるでリテラシーが無いのを宣傳しているようなものだが、本人たちはそういうことに氣付いていない。

| | Comments (0) | TrackBack (0)

July 28, 2013

リテラシーについて

リテラシーという言葉は、よくパソコン應用力の脈絡で使われるが、元々は言葉の讀み書きが出來るかどうかを表わすようだ。打合せ資料をサクサク作れない人はリテラシー不足と言われるが、これは、考えていることを文章に表現出來ないと言うと失禮なので、オブラートに包みたいときに便利な言葉かもしれない。

最近は、TVドラマなどで會社のオフィス風景が寫されると、ほとんどの机の上にパソコンがあり、みんなそれを使って仕事をしている。會社の業務がシステム化されるとイヤでもパソコンを使わざるを得ない。しかし、會社の大半の人がパソコンを使うのがイヤだとすると、會社の業務システムがどうあるべきかを檢討するのがたいへんだ。なにせ、パソコンを使って仕事をするのがイヤな人に、システムのこの部分はどうなっていれば良いかを聞いたって埒が明かない。

業務システムのSEをやっていて常に思うのは、こんなこと適當なデータベースとCSVファイルの處理方法を知っていれば、何千萬圓、場合によっては何億圓もお金を出す必要ないのに・・・ということだ。大きな會社ならデータベースの技術者を一人や二人會社に置いたって何ともない。でも、そういう體力が有り餘るような會社でも業務システムの構築はシステム屋に委託することになっている。そして、システム屋からその會社の業務知識ゼロのSEが何人もやってきて、高いお金で要件定義を開始する、というのがお決まりのパターンだ。

こういう一見して非效率なやり方は、最近流行の内部統制とかガバナンスとかによるものらしい。會社の業務システムを社員に作らせたとして、もしその社員たちが集團退職したらどうするのか、あるいは、その社員たちが昇給・昇格しないならシステム運用を止めるとか、會社の營業情報を競爭相手の會社にリークするとか、脅迫してきたらどうするのか、それらを想像したら恐ろしくて社員なんかに業務システムを任せられるはずがない。

しかし、リスクヘッジの觀點だけでシステム屋に任せておいて良いのだろうか。

| | Comments (0) | TrackBack (0)

日本人の誇りを失わないために

日本人の誇りを失わないためにこの動画をご覧ください。


| | Comments (0) | TrackBack (0)

July 21, 2013

いじめ

タイトルはあえて「いじめ問題」にはしなかった。そもそも「いじめ」というものの定義が曖昧だ。定義が曖昧なものは問題が起きても原因がはっきりすることはない。

いじめが明らかに問題になるのは、いじめが激化して被害者が死亡してしまったとき、または、被害者がいじめを苦に自殺してしまったときだ。では、誰かが死ぬまで問題にならないのか?!ということになるが、結果的にはそういうことになっている。また、被害者が死亡してしまったときでさえ、關係者が取材拒否すればメディアの報道にのらないことだってある。

いじめは、誰がどう見ても異常だと思わない限り表面化しないことが多い。いじめが原因で誰かが死んでも、周圍の人に取材すると「いじめには見えなかったんですけどねえ」という類の話がほとんどだ。まあ、人が死んでいるんだから「あれは明らかにいじめだと思っていました」などと話したら、なんで注意しなかったのか?とか、なんで通報しなかったのか?などと、問われるのが當然なので誰も正直に話そうとはしないだろうし、取材する方もする方だと思う。

いじめ問題の世の中の扱いでは、被害者をこの上ないほど美化することになっている。被害者側に非があったなどとは、假に事實がそうであったとしても絶對に誰も言わないし、報道もされない。まして、いじめの原因などどうでも良いし、誰も追求もしない。下手に原因を探って誰も期待しない事實が判明するよりも、常に被害者は何の問題もなし、100%加害者が惡い・・・ということになっている。

これで良いのだろうか。

| | Comments (0) | TrackBack (0)

July 19, 2013

サミータウン(3)

で、サミータウンをはじめて約1年が過ぎた。パチンコとスロット兩方出來るVIP會員になって、最初の20萬ドルバを無くさないよう愼重にプレイした。今では3000萬ドルバを超えている。勳章は79個(パチンコ72個、スロット7個)。四六時中出來るわけではないので、やはり1年で100個は無理だった。

いったいどういうやり方をしているのか知らないが、勳章(パチンコなら50000個、スロットなら10000枚でもらえる)を30783個持っている會員が居る。日に1個ずつ獲得しても84年かかる計算だ。サミータウンは今年8周年なので、日に約10.5個、つまり約2時閒に1個のペースになるが、2時閒ではメダル(パチンコなら10000個、スロットなら2000枚でもらえる)すら取れないことが多い。しかもその人はサミータウンがオープンすると同時に入會したのかどうかも分からないので、實際にはもっとハイペースなのかもしれない。

まあ、どこの世界にも唖然とするような人は居るものだ。

好きな臺は主にパチンコで、CRシャカRUSH R、ニュービッグシューター、ニューヨーカー、ファインプレー、マジックカーペットⅠくらいか。スロットはあまりやらないが、たまにBlack Lagoonをやる程度か。たぶんCR大シャカRUSHがあったら1日中やっていると思う。

會費は月2300圓くらいだと思う。たいていのパチンコ好きは「そんなのやってて面白いの?」と聞いてくるが、個人的にはリアルパチンコやって負けるくらいならこっちの方がよっぽど面白いと思う。面白いかどうかはその人次第だ。自分が面白くないからといって他人もそうだとは限らない。なにしろ、パチンコ屋に行かなくてもパチンコが出來るというのは私にとっては非常に好都合だ。

おそらく、もうリアルパチンコをすることは無いだろうと思う。

| | Comments (0) | TrackBack (0)

サミータウン(2)

パチンコでやられたときの自分を冷靜に振り返ってみよう。儲かったときの自分を振り返る必要は全くない。儲かった理由など誰にも分からない。まして本人に分かるはずがない。しかしパチンコでやられる人ほど儲かったときの理由を氣にする。そして次囘、儲かったときと同じことをして、前囘儲けた分をすべてお返しすることになる。

ある有名な哲學者は「良いことに原因はない」と言った。良いことに原因がないというのはパチンコに限った話ではなく、これは世の常だ。會社ではよく成功事例發表會なるものをやって、みんなこれを見習って成功しよう!みたいなことをするが、全く以って的外れである。たとえば「今囘の案件では、終始お客樣の立場に立った對應が評價されて成功した」という説明があったとしよう。それに對し「その案件はお客樣の立場に立った對應をしなかったら成功しなかったのですか?」とツッコミを入れると答えられなくなるか、氣合で「そうです」と答えるのだろう。つまり、成功の原因として擧げられるもののほとんどはそういう極めて曖昧なものなのだ。

反對に「お客樣の立場に立った對應をしなかったために失敗した」というのはほとんどの場合において正しい。くどくなるが「お客樣の立場に立った對應をしていれば失敗しなかった」というのもある程度は成り立つからである。

一番惱むのは、あとどれだけ黏れば大當たりするかという判斷だ。自分がその臺をあきらめたら、次にやった人がすぐに大當たりするというのはよく見る光景だ。でも、そのまま黏っていてもたいてい大當たりしない。では、なぜ人が變わると大當たりするのだろうか。人が變わるとパチンコ臺の確率が變わるのか。いくら惱んでも分からない。そういう場合は、人知の及ばない力が働いていると素直にあきらめた方が良い。

まあでも、勝ちたい人はパチンコ必勝法などの雜誌を讀んで頑張るしかないのだろう。ただし、必勝法が原因で勝ったのか、何か別の原因で勝ったのかは結局誰にも分からない。

| | Comments (0) | TrackBack (0)

July 18, 2013

サミータウン

言わずと知れたネットパチンコサイトである。禁煙パイポみたく、私はこれでパチンコをやめました。というか、今でもパチンコに夢中だ。何?この地味な矛盾。

リアルのパチンコは儲からない。こう書くといつもはトントンなのか?と思われるかもしれないが、もちろん大損している。もしパチンコでやられた金額を合計したら、輕く自動車1臺くらいは買えたのではないかと思う。でも、自分を含めたいていの人は「儲からない」と言う。たぶん氣が滅入るので「やる度に負ける」とは言いたくないのだろう。

パチンコで勝てる人は出ないかもしれない臺では打たない。これは閒違いなく鐵則だ。負ける人は出ないかもしれない臺でも打つ。出る確率がゼロでない限り、儲かる可能性があるという理屈だ。しかし、萬が一の確率で出るかもしれないとか、このところずっと負けてるからたまには出るだろうとか、そんな甘い考えで勝てる道理はない。パチンコ屋が「いくらでも出しますから、どんどん出していってください」と大盤振る舞いしていても、負けるときは負ける。

現實問題として、人はパチンコしたくなったときにパチンコ屋に行く。理由として、ただ單に暇だからという人はそんなに多くない。今はむかしと違って暇を潰す方法などいくらでもある。たいていの人は「123番臺は昨日すごく出ていた(または凹んでいた)から、今日も出るかもしれない」とか自分勝手なポジティブ思考でその氣になる。そして、お目當ての臺に先客が居たら、速攻で歸宅するか、その店をあきらめて別の店に行けば良いのに必ずお目當て以外の臺でもやってしまうものだ。なぜかと言えばパチンコしたいからである。パチンコがしたいからパチンコ屋に來たのに、やらずに歸れるわけがない。

そしてたいていの人はボロ負けする。誰も負けなかったらパチンコ屋が潰れるだけだ。それでもパチンコはやりたいときにやるのが一番樂しいものだ。お目當ての臺じゃなければやらないという意志の強い人は、そうでない人ほど樂しくないと思われる。だからこそ、みんないくら負けても、サラ金で借りてでもパチンコをするのだ。

| | Comments (0) | TrackBack (0)

忙しい人

每日每日忙しい忙しいと言っている人が居る。何がそんなに忙しいのか分からないが、ことある每に忙しいと吹聽しているし、ときには「こんなに忙しいのにまだ仕事を持ってくるの?」とか言って斷っている。でもその人をよく觀察していると、意外なことが分かる。

まず、ほとんど殘業をしていない。忙しいのを解消したいのであれば、一時的に新たな依賴を全部遮斷して、殘業すればある程度落ち着くのではないだろうか。いい歳をした大企業のサラリーマンなんだから、自分に出來る仕事量は分かっているはずだし、引き受けたのなら文句を言わずにやるべきだ。周圍の人はみんなそうしている。

そもそも仕事の依賴が多いのは自分が撒いた種だと思う。うちには對應すべき營業が60人ほど居て「この新商材については私が對應します!」などと言ったとしたら、營業はそれを自分の顧客におすすめするだろう。そして顧客は別に大して興味がなくても「じゃあ提案してください」と言うだろう。ひとりの營業がそれぞれ10人の顧客に對應しているとすれば、それだけで提案件數が100や200になっても不思議じゃない。それだけの數の案件が集中して飛び込んでくれば、誰だって忙しくなるに決まっているのだ。自分で撒いた種は自分で刈り取ってもらわなければ困る。

また、そのような新商材の案件は本當にその人でなければ對應出來ないのか?という疑問もある。自分で撒いた種だから他の人に渡したくないのかもしれないが、そのせいで、その人が本來對應すべき難易度を持った案件が、すべてその周圍に降りかかってきているのだ。何となく、むずかしい案件に對應しなくて濟むよう仕向けているのではないかと勘繰りたくなってくる。

先日電話しているのを橫で聞いていたら「・・・去年はまだ良かったんですけどねえ、今年はもうホントにどうしようもないくらい忙しいんですよ・・・」とか言っていた。たしか去年も同じようなことを言っていた氣がするが・・・。しかも、自分勝手に依賴を斷ってるし。そういうのって擔當全體で判斷することじゃないのかな。とにかくその人の仕事のやり方って疑問だらけで、何を考えているのかさっぱり分からない。

| | Comments (0) | TrackBack (0)

July 17, 2013

プログラミングの話(14)

プログラミングが好きな人はUNIXが大好きだ。最近のUNIXというとLINUXが主流かもしれないが、私がシステム開發の世界に入った頃は、BSD系のSunOSとか、SYSV系のHP-UXが主流だったと思う。當時はまだSun3の時代で、GUIはSunViewだった氣がする。日本語などの2バイト文字のコメントが入ったC言語ソースは、コメントを取り除かないとCプリプロセッサが處理出來ないので、いちいちフィルターをかけて半角英數文字だけのソースファイルに變換していた。そしてファイル管理にはDECのPDP-11を使っていたと思う。タイプライターのコンソールにビックリしたものだが、周圍ではメモリのことをバブルと呼んでいる人も居た。もちろんバブルが彈ける前の話だ。

なぜみんながそんなにUNIXが好きだったかというと、UNIX上にはCコンパイラはもちろん、便利なテキストエディタ、ソースレベルデバガ、プロファイラ、カバレッジツール、シェル、sed、awkのスクリプト言語などがあって、プログラミング環境として非常に快適だったからだ。emacsとviはどっちが良いかというエディタ論爭もあった。Sun3全盛の頃はまだまだemacsは重たかったので、viの使用が推奬されていた。私はemacs派だが、當時からexをスクリプトとして使うのは好きだった氣がする。一番感動したのはemacsの中からgdbを使用したときだった。GUI無しであの操作性は畫期的だったと思う。

しかしいくらUNIXが樂しくても、それは10年くらいしか續かなかった。10年もプログラマをやっていると、さすがにもうプログラミングさせてはもらえなくなった。でも生涯現役プログラマでありたかった私は、何か良い獲物はないか探していた。そして出會ったのがemacs-lispだった。そしていろんなテキスト處理をemacs-lispで書いているうちに、今までC言語のプログラムに感じていた違和感がやっと分かった氣がした。UNIX上のシェルスクリプトやperlスクリプトをかじっているうちに、C言語にLispのデータ構造や制御構造を求めてしまっていたのだ。その證據に、關數呼び出しが果てしなくネストするLispのプログラムに全く違和感を感じなかった。これでもうCやJavaのような書式の言語に夢中になることはないし、Lispのプログラムなら一生書き續けられるような氣がした。

まさに第二のプログラミング人生である。

| | Comments (0) | TrackBack (0)

July 16, 2013

プログラミングの話(13)

プログラミングが好きな人は、コンピュータのことをよく知っている。それはプログラミング言語でコンピュータと話すのが好きだからだ。しかし世の中にはコンピュータのことを理解しようとしないプログラマも居る。そういう人たちはコンピュータのことを知らなくてもプログラムを書くことが出來る。つまり頭が良い人たちだ。

コンピュータと話すのが好き、などと書くとキモいと思われるかもしれない。たしかにコンピュータとだけ話して、周圍の同僚、友達、家族とは一切話さないというのなら氣味が惡いかもしれないが、誰もそんなことは言ってないし、そんな人は稀なので、直感的にそんなふうに決め付けたがる人の方がよっぽどキモい。一體何を想像しているの?と言いたくなる。

頭が良い人たちはとにかく飮み込みが早く記憶力が優れているので、言語仕樣を理解するのも私のような低能では想像もつかないくらい格段に早い。そうなるとコンピュータのことなんか理解しなくてもどんどんプログラムを書くことが出來るのだろう。頭の良さに任せて強引にねじ伏せるといったところだろうか。

私がシステム開發の世界に入って閒もない頃は、とにかくC言語が理解出來なくて、まずCPUやオペレーティングシステムの本を好んで讀んだ記憶がある。CPUの本を讀むと、コンピュータがどのようにして動くのか書いてあって、C言語はかなりアセンブラに近いのだという感覺を據り所に、いろんなことを假定しながら檢證していった。それをやったおかげで、CTRONで動く交換機の保守運用モジュールや、OSがない世界で動くプログラムの構成や處理方法なども、割とすんなり理解出來たように思う。

つまり、コンピュータにはプログラミング言語の仕樣を理解しているだけでは決して分からない部分があるのだ。たとえば、コンピュータに特殊なデバイスを接續したとして、それはメモリマップドIOのXX番地を參照し、ゼロだったらレディ狀態だから、その鄰の番地に1を書き込むと起動する。起動結果はさらに鄰の番地がステータスになっているから、1m秒以上の周期で參照して、ゼロ以外の値になるまで待つこと・・・などと説明されても、C言語しか知らないプログラマにはお手上げだ。

| | Comments (0) | TrackBack (0)

プログラミングの話(12)

プログラミングが好きな人は、プログラムを書く前の段階で設計書を書くのが大嫌いだが、書き上がったプログラムをみんなでレビュするのはもっと嫌いだ。

ソースレビュという作業はホントに憂鬱だ。ソースレビュとは、プログラムをプログラム設計書どおりに作っているかどうかを確認する作業である。つまり前提として、プログラム設計書は正しく、プログラムは閒違っているかもしれないからレビュするのだ。もちろんプログラム設計書は、機能設計書の詳細化として妥當かどうかのレビュを濟ませている。だから、プログラム設計書よりもプログラムの方が正しいと主張することは出來ない。そのためにレビュ中は幾度となくイラっとしてしまう。

プログラム設計では、機能設計書の詳細化として、モジュール構成圖、モジュール一覽表、モジュール設計書(モジュールを關數と讀み替えることもある)を作成する。開發したことがある人なら分かると思うが、機能の中身というのは他の機能に影響しない、性能をスポイルしない範圍で自分の自由に考えることが出來るはずだ。しかしレビュの場では、モジュール構成が分かりにくいだの、機能名とかけ離れた構造に見えるだの、處理手順が分かりにくいだのと、レビュアはまるで審査官にでもなったように無遠慮なコメントをしてくる。プログラム設計レビュの段階からそういう狀態なので、ソースレビュになればさらにその傾向が顯著になる。

もし彼らに分かりやすいプログラム設計書やプログラムを書こうと思うなら、途中で何をしているのか分からなくなるくらいベタベタに書かないといけないのだが、そうするとプログラムステップが增大して、單體試驗項目が增えてしまう。たとえば「if文の條件式に關數呼び出しを書くと分かりにくくなるから、手前で關數を呼び出して結果を變數に格納し、その變數をif文の條件式で判斷するよう修正してください」というお決まりのコメントをされる。「何が分かりにくいの?」と聞くと「if文の條件式は變數と演算子だけの方が單純だから。あと知らない人が見ても分かりやすい」と言われる。單純な方がよりベターだという考え方だ。單純を好む人は、ひとつのモジュール(關數)がどれだけ巨大になっても何とも思わないので、ときに化け物のようなプログラムを平氣で書く。

もちろん分かりやすいプログラムを書くのは、保守性や移植性にとって重要なことだ。しかし、1行1行に至るまで誰にでも分かるように單純に書くというのは、あまり行き過ぎるとかえって何をしているのか分からなくなる。處理を細切れにするにはそれだけ無駄に多くの變數を定義し的確に使用する必要があるからだ。

| | Comments (0) | TrackBack (0)

プログラミングの話(11)

プログラミングが好きな人は、プログラムのロジックをプログラミング言語で思考するらしい。我々が何か言葉を話すときに、事前に日本語よりも簡單な他の言語で下書きしておいて、それを日本語に變換しながら話す方が、日本語で直接思考しながら話すよりもはるかに效率的だというのなら、誰に命令されなくても自然とそうするだろう。そういう意味で、プログラミング言語で思考してプログラムを書くという行爲が存在したとしても何ら不思議ではない。

AI屋の人に言わせると、人閒は言葉で思考しているのではないと言う。しかし、思考した内容は言葉にならない限り認知することが出來ない。考えたことを言葉ではなく、繪や圖に表わす人が居るが、それは言葉で考えていないのではなく、繪や圖にした方が分かりやすく、容易に傳達可能だからというだけだ。

英語でペラペラ話している外國人を見ると、日本人は「なぜあんなふうに英語がスラスラ出てくるのか」と不思議に感じると思うだろうが、外國人だって「なぜあんなふうに日本語をペラペラ話せるんだろう」と不思議に思っているに違いない。同樣にプログラムをスラスラ書く人を、書けない人の側から見ると、ものすごく不思議な氣がするのだろう。

でも、どこの國の言葉でも一度話せるようになってしまうと、そうなるまでのプロセスをほとんど忘れてしまう。そうなると、日本語の何がむずかしいのかを説明出來なくなり、つい「日本語って簡單ですよ」と言ってしまうことになる。プログラミング言語だって、それでペラペラ話すことはないにしても、一度プログラムが書けるようになってしまうと、「プログラムなんてむずかしいから書けるようになるわけがない」と思っている人の方こそ不思議に見えるようになる。

だから、英語にしてもプログラミング言語にしても、必要に迫られなければ話せるように(書けるように)なろうとは思わないのが當然である。

| | Comments (0) | TrackBack (0)

プログラミングの話(10)

雜談ぽく書いているうちに10囘目になってしまったが、まだプログラミングの核心に觸れるようなことは何も書いていない氣がする。

プログラミングが好きな人は、プログラムの内容を日本語で表記する、いわゆる設計書を書くのが大嫌いだ。そういう人たちはプログラムとして作るべき仕樣を確認する段階で、既にある程度プログラミング言語で考え始めているからである。しかしプログラムを書いたことがない前世代のオジサンたちは、そういう思考を經驗していないし、そんなことが出來るとは夢にも思っていない。これすなわち、プログラミングに對するトラウマのようなものではないかと思う。

プログラミング言語は、人閒が日常讀んだり書いたり話したりする日本語や英語よりはるかに簡單で制約が多い言語であると言う人は多いが、プログラミング習得の容易性はそこではない。16ビットパソコンが普及し、その上で動くコンパイラやデバガが登場すると、プログラミングを習得したい連中は四六時中それに沒頭するようになった。相手はコンピュータなので三日三晩それをやり續けても、のどが渴いたとか、休憩したいとか言わないし、文句ひとつ言わずに壞れるまでこちらの要求に應じ續ける。それは誰か外國人を相手に英會話を習得するのとは雲泥の差だ。

頭の固いオジサンたちの世代は、プログラミングというとあらかじめ何を書けばよいかを日本語で詳細に書き、次にコーディング用紙に書かれている日本語のとおりにプログラムを書き、それをカードパンチしてコンピュータに投入した。プログラムを書き閒違えるとコンパイルできない、もしくは動かないのでコーディング用紙に書いたプログラムを見直す・・・我々には想像もつかないような面倒な作業だ。しかも、そういう面倒な作業を經驗しているのならまだしも、ほとんどの人は經驗しておらず、面倒な作業という印象だけが頭にこびり付いている。

それが今ではパソコン上の便利なテキストエディタを使ってプログラムをタイプするだけで、コンピュータに投入濟みとなる。そしてコンパイルすればすぐに實行可能だ。コンパイルエラーが出てもエディタの機能でエラー箇所をすぐに開くことが出來るし、實行中のエラーはデバガで追いかければすぐに分かる。

既にオジサンたちにはついていけない世界なのかもしれない。

| | Comments (0) | TrackBack (0)

プログラミングの話(9)

16ビットパソコンが普及する前は、ドキュメント作成は基本的に手書きで、それをワープロのお姉さんがオアシスなどで電子化していた。その後、16ビットパソコンが1人に1臺ずつ配備されるようになると、ドキュメントを手書きするのはやめて、最初から一太郞などのパソコン用ワープロソフトで作成するようになり、ワープロのお姉さんは次第に職場から姿を消していった。すると、オジサン慣れしたワープロのお姉さんに代わって、經驗値の低いプロパーの女子社員がエロオジサンたちのちょっかいの的になり、セクハラ問題が起きるようになった・・・かどうかは定かではない。

ドキュメント作成方法の變化は他の作業にも波及して行き、工程每に居た擔當はどんどん集約されていった。そして氣が付くと、仕樣書作成から總合試驗完了までの全工程を1人で擔當するようになり、開發規模と生産效率から計算された要員で、實現機能を分擔して開發するスタイルに變貌した。したがって、今までのように「バグの原因はおまえが設計書を書き閒違えたからだ!」「いや仕樣書にはこう書いてあるから仕樣どおりだ!」などと人のせいに出來なくなってしまった。

このような傾向は、プログラムを作りたくて仕方がない症候羣どもを喜ばせる結果(設計をすっ飛ばしていきなりプログラムを作る)になるかと思われたが、そうはならなかった。16ビットパソコンという文明の利器によって作業の集約は出來たが、頭の固いオジサンたちはその變化に對應した品質管理方法を作り出せなかったので、全工程1人で擔當するにもかかわらず、仕樣書を作成し、それを元に設計書を作成し、プログラムは設計書どおり書くという從來のフローを變えることが出來なかった。

そのため、プログラミングスキルが高い人たちは、既に頭の中でプログラムが出來上がっているのに、それをわざわざリバースして設計書を書かなければならなかった。我慢出來ずに「なんで設計書なんか書かなければならないのか?!」と聞くと品質確保だと言われて、さらにイラつくことになる。

頭の固いオジサンたちは、設計しないでプログラムを書くと、設計書を書いたときに混入する誤りを摘出することが出來ないから、その誤りがプログラムに殘存すると考えている。しかし、それならソースレビュを入念にやる方がはるかに理に適っているのだが、オジサンたちはプログラミングをしたことがないために、プログラミングスキルが高い者などそんなに居るわけがないと思い込んでいて、設計審査をしないと不安で堪らないのだ。

そういう、セクハラか人の足を引っ張るしか能のないオジサンたちは、ワープロのお姉さんを見習って、さっさと最前線の開發現場から去って慾しいものだ・・・と、若かった頃に何度思ったことか。

| | Comments (0) | TrackBack (0)

July 15, 2013

プログラミングの話(8)

プログラムを書きたい症候羣の人が入社したがるソフトウェア會社では、プログラミングよりもそれ以外の作業の方が壓倒的に多いということを書いた。システムはプログラムの集まりであり、それ以外の仕樣書とか設計書とか試驗項目の類は作っても、それがシステムの中で動作するわけではないし、それをエンドユーザに提供したって讀むとは思えない。にもかかわらず、なぜプログラムを書くのにかける時閒の何倍もの時閒をかけてそれらを作らなければならないのだろうか。

私がシステム開發の仕事に攜わるちょっと前まで、プログラムはパンチカードでコンピュータに投入されていた時代があった。おそらく、その頃の開發はほぼ工程每に擔當が分かれていて、設計屋さん、コーダー、カードパンチャー、ファイル化擔當(LIB管ともいう?)、試驗屋さんなどが居た。そのような體制で開發をやっていた頃は、設計する人とプログラムを作る人が同じ人というのは想像すらしなかったと思う。設計屋さんは設計書を書くのが仕事なので、プログラミング言語を學ぶ必要がない。また、コーダーは設計屋さんが書いた處理手順を言語仕樣書どおりにプログラム化しているだけなので、それが意圖したとおりに動くかどうかは氣にしない。動かなければそれは設計が閒違っているのだと思うだけだろう。

つまりプログラムを作る作業は出來るだけ、局所化、極小化して、他の人はプログラムを書けなくても良いような開發フローになっていたというわけだ。そのように擔當が細分化されていれば、仕樣書や設計書が出來たあとは、コーダーがプログラムを作るのと竝行で、試驗屋さんがその仕樣や設計に基づいた試驗の檢討に入ったり、レビュに參加することが出來たし、いくつもの開發を掛け持ちすることも出來た。

そういう體制の下では、試驗でバグが見つかり、プログラムを變更する場合、設計屋さんが設計書を修正し、修正された設計書を元にコーダーがプログラムを修正し、修正されたプログラムをカードパンチャーがコンピュータに投入し、LIB管がそれを受け取ってファイル化し、修正濟みのファイルを使って試驗屋さんが再試驗するという流れにならざるを得なかった。それにより、各擔當で同樣の觀點での見直しも當然のごとく行なわれ、それらの修正も同時に反映された。

このようなやり方をやっていれば、確かにプログラムを作る時閒の何倍もの時閒をかけてそれ以外の作業をやる必要があるだろう。しかし、このような開發スタイルは16ビットパソコンの普及により一變することになる。

| | Comments (0) | TrackBack (0)

プログラミングの話(7)

プログラムを書きたい人が、プログラムを書く仕事に就いたとして、仕事の中に占めるプログラミングのウエイトは時閒的にも感覺的にもかなり低い。場合によっては、ソフトウェア會社に入社したにも關わらず、ほとんどプログラムを作らせてもらえないような部署に配屬されることだってあり得る。また、入社後もずっとプログラムを書きたいという氣持ちが持續するかどうかは分からない。

ソフトウェア會社において、プログラムを作る作業は製造工程と呼ばれている。どういう方式でどういうプログラムを作れば良いかまで規定するのが機能設計だとすると、製造工程を擔う者は機能設計書を元にどのようにプログラムを書くかを規定するプログラム設計書を書き、それを元にプログラムを作る・・・このような開發スタイルをウォーターフォール型と呼ぶ。このスタイルでは前工程の生産物が正しいことを前提とするので、たとえプログラミングのことなんて全く考えないで作られた拙い設計書であっても、そのとおりにプログラムを書かなければならない。こういうことは設計者と製造者が別の場合にしか起きないのではないかと思われるかもしれないが、自分で設計して、自分で製造する場合でも不思議とよく起きるものだ。

システムを開發する場合、仕樣と機能の區別(境界、階層)が明確でないと仕樣書や設計書を讀んでもよく分からないし、そこから製造すべきプログラムもよく分からないということになる。しかし、ソフトウェア開發の現場で、仕樣はこうで、設計はこうだ!みたいな高尚な話はほとんど聞いたことがない。もちろん開發現場は硏修じゃないので、そんなことを説明とか議論とかしている暇はない。あるのは、以前どこかでやった開發の實施計畫書から無理矢理引っ張ってきた仕樣檢討方法や機能設計方法のコピーであり、それを今囘どう流用し、どこがポイントで、注意事項は何かなどはほとんど語られることはない。

たとえば、エンドユーザの操作レベルは仕樣書にしようとか、その1個1個の操作を機能單位として、機能設計していこうとか、最低限その程度の指標なり方針がないと、みんなで一齊に仕樣書や設計書を書いても内容がバラバラになるのは目に見えている。方針が曖昧なまま作業を進めれば、書類は出來上がるかもしれないがレビュする段階になって大騷ぎになる。

こうして、プログラムを書きたいと思って入社した新入社員は、徐々にプログラミングなんてどうでも良いじゃないか!と思うようになっていく。

| | Comments (0) | TrackBack (0)

プログラミングの話(6)

プログラムが書けるようになりたい人が、どのプログラミング言語を習得すれば良いのかについては、ほとんどの人が最初に仕事で開發したシステムの記述言語を習得するのであり、選んでいる餘裕などないのが實情だ。選ぶというからには2つ以上のプログラミング言語の特徵を少なくとも比較出來る程度には習得しなければならない。

これはある意味、配偶者を選ぶのに似ている氣がする。結婚したいと思ったときに、誰とすれば良いのか、そんなことはいろんな人と結婚生活を送ってみなければ分からないものだ。しかし、多くの人は最初に結婚した人と一生生活し續ける。それは、現在の生活を放棄し慰謝料や養育費を拂ってまで、他の人と一緖になるのが如何に困難かということだ。

以上から、普通、プログラムを書けるようになりたいと思う人は、ソフトウェア會社などのシステム開發を行なう會社に入社しない限り、プログラムが書けるようにはならない。また、プログラムが書けるようになったとしても、自分の好きなプログラミング言語を習得している人は稀であり、ほとんどの人は成り行きで特定のプログラミング言語のみを習得することになる。さらに、プログラムを書けるようになりたいと思わない人が、プログラミングを習得することは稀であるとも言える。

しかし、世の中には「プログラムを作るのって意外に簡單ですよ」と公言して憚らない奇特な人が少なからず居る。既に習得してしまったものを後で振り返って、なんであんなに惱んでいたんだろう?と思うことはあるのかもしれないが、だからといってそれが簡單だったとは言えないのではないだろうか。そういう人は、自分がジグザグに步んできた道を眞っ直ぐに步くよう指導すれば、誰もが簡單だと思うのではないかと考えているのだろうが、それは自分勝手な妄想でしかない。そもそも自分にとってジグザグな道や眞っ直ぐな道が、他人にとっても全く同じ道に思えるかどうかさえ怪しいものだ。

「こう考えれば簡單でしょ?」といくら力説しても、實際に簡單かどうかは相手次第である。

| | Comments (0) | TrackBack (0)

July 14, 2013

プログラミングの話(5)

で、結局どのプログラミング言語を習得するのが一番良いか、という問いに對する解は存在しないことを示す一例を書いたわけだが、さらに續ける。

誰でもそうだと思うが、どれが一番良いかは分からなくても、どれが一番好きかはたいてい分かるものだ。ただ、好きなプログラミング言語のアンケートをとって1位になったものが、みんなが好むプログラミング言語だということは出來るとしても、個人が實際にどのプログラミング言語を好むかにはほとんど關係がない。これは見た目ではなく味なのだ。食べてちゃんと咀嚼してみなければ分かるはずがない。

しかし、プログラミング言語を手當たり次第に食べて、それぞれの味を云々するというのはなかなか大變なことだ。それは食べたプログラミング言語が持っている味をちゃんと味わえるかどうか、何を食べてもソコソコ美味しいじゃないかという印象にならないか、という點が非常に氣になるのである。そういう問題は、習得へのハードルが高く、學習カーブが緩やかなプログラミング言語であればあるほど、その傾向が強くなる。

平たく言えば、プログラミング言語の味が分かるほどに習得するのはなかなか面倒なことなので、そもそもそんなに數多く手を出せるものではなく、そういう狀況の中では、仕事でたまたま習得せざるを得ず、バグを出しながら苦勞して覺えたプログラミング言語に愛着を持ってしまうのはある程度仕方がないことではないかと思う。

そして、それ以上にプログラムというものに貪慾になれる人が少數ながら居て、そういう人たちがプログラミング言語のウンチクを語っているに過ぎないのではないかと思うのだ。そういう中で、同僚の誰かにこういう面白い、すごく役に立つプログラミング言語があるんだけど勉強してみない?などと言っても、言われた方は「何言ってるの?この人」みたいな反應しか返ってこないのは至極自然なことではないだろうか。

| | Comments (0) | TrackBack (0)

プログラミングの話(4)

プログラムを書けるようになりたいと思っている人は、どのプログラミング言語でどういうプログラムを書きたいと思っているのか知らないが、「何らかの機能を持ったプログラムは入力データを元に出力データを作り出すものである」ということに變わりはない。まあ、これに異を唱える人は居ないだろうが、この理をすんなり受け入れられないプログラマはたいてい何かを勘違いしている。

いくらプログラムを書きたいと言っても、既知のプログラムを書くのは無駄以外の何物でもない。たのしいUNIXの世界では、何か處理をしたい場合、まずシェルのコマンドラインで出來ないかを考え、次にシェルスクリプトで出來ないかを考え、それでもダメならC言語などでプログラムを書くことを推奬している。C言語で・・・というのは當時(SunOS4.3が流行った頃まで)のUNIXはCコンパイラを標準で搭載していたからだ。しかし、その後のSolarisなどでは、Cコンパイラがパッケージとして別賣になっている。これはカーネルパラメータの變更をカーネルに反映するのにCコンパイラを必要としなくなったからであるが、感覺的にコンパイラがないのにランタイムライブラリだけはちゃんと漏れなくあるというのがどうも薄氣味惡い。なので、プログラミング環境としてUNIXを使いたい人はたいていLINUXかBSDを使っていると思われる。

さらに、新入社員向けプログラミング硏修を擔當するお利口さんインストラクタは、システムはどのプログラミング言語にも依存しないよう仕樣を決め設計するものだということを、賴みもしないのに敎えてくれる。システムの設計書がどれ程特定のプログラミング言語に依存しないように書かれていたとしても、結局どれかのプログラミング言語で書かなければいけないのであれば、早い段階から決定し、それを前提に設計し、問題點を見つけ出して解決しなければならない。現實問題として、プログラム設計の手前までプログラミング言語が決まっていない開發など一度たりともなかったので、こういう勘違いを新入社員に仕込まないでもらいたいものだ。

元々システム開發の上ではプログラムを書く前にコマンドラインで、などとは考えないし、ほとんどの場合、提案段階からどのプログラミング言語で開發するか決まっている。だから、その開發に着手した段階で、どのプログラミング言語で作るかを檢討する餘地はない。それはごくごく當たり前の話で、プログラミング言語を決めない提案では、その開發作業の生産效率が分からないので、開發費を見積もることが出來ず、提案が成り立たないのである。もちろん、提案は事前のコンサルで要件定義をした上で・・・というやり方もあるにはあるが、その場合リスクが無意識のうちにすべてエンドユーザ持ちになるという點で好ましいやり方とは言えない。

| | Comments (0) | TrackBack (0)

プログラミングの話(3)

プログラムを書けるようになりたいと思っている人は、プログラムでないと不可能と思われるような大量のデータを處理することが出來るという他に、もしプログラムが作れるようになったら、それこそどんなシステムだって作ることが出來ると、獨りで勝手に興奮し舞い上がってしまう人たちだとも言える。しかし、プログラムが書けるようになったら、大量のデータを處理するホンのちょっとしたプログラムを書くと言うならまだしも、どんなシステムだって作れるようになると思っているのだとしたら、それは大閒違いだ。

むかし「C言語でのシステム開發で1人の開發者で把握出來る仕樣の規模はせいぜい50K程度である」と言った人が居た。50Kというのはだいたい有效ステップで50000行くらいあるプログラムのことである。これはおそらくリーダをどのくらい配置すべきかという指標であろう。そしてその當時の開發者の生産效率はだいたい5K/人年、つまり1人の開發者が1年に約5000行のプログラムを開發する。そのペースだと、1ヶ月で作れるプログラムは約400行になり、1日だとたった20行(C言語の關數だと1~2個くらい?)しか作れないことになる。

ひょっとしたら「そんなバカな、俺だったら月に20~30Kくらい樂勝で開發出來る」という人も居るだろう。しかし、誰もがそんなキチガイみたいな效率で作れるわけではない。かの有名なヨードンさんの話では、效率が良い人と惡い人の閒でなんと28倍の差があったと言う。假に0.4K/人月を標準とし、最高と標準の閒の差を14倍とすると優秀な人の生産效率はせいぜい5~6K/人月だ。よって20~30K/人月が樂勝というのはまさに驚嘆すべき生産效率であり、そんな人がもしこの世に存在するのなら神と呼ばれても不思議ではない。ちなみに20K/人月という生産效率の元では、1日に約1000行ほどプログラムを作る必要がある。

知らない人のために書くと、システム開發はプログラムを書くという作業だけではなく、少なくとも機能設計書、プログラム設計書、單體試驗項目表、結合試驗項目表くらいは作成するし、試驗をするには自分のプログラムを呼び出すドライバと、自分のプログラムが呼び出す他擔當の機能、つまりスタブを作成しなければならない。また、すべての設計書、プログラム、試驗項目表には作成後のレビュが必要であり、他擔當のレビュにも參加しなければならない。さらに深刻なバグが發生したときの對處や、開發マシンの不調に伴うロスなどを考えると、1日に1000行のプログラムを完成させていく生産效率を維持するのは竝大抵のことではない。

まあ、プログラムを書くという作業はシステム開發の全工程のせいぜい1/5以下であり、他の4/5以上は打合せ、ワープロ作業、マシン時閒の奪い合い、他擔當との喧嘩、喫煙、病氣による休暇に費やされる。

| | Comments (0) | TrackBack (0)

July 13, 2013

プログラミングの話(2)

今ではほとんどの職場のほとんどの机の上にパソコンがある。なので「もしもプログラムが書けたなら・・・」と思っている人は意外に多いかもしれない。しかし、實際に書いてみようと思う人は意外に少ないかもしれない。

プログラムを書いてみたい、書けるようになりたいと思っても、では一體何のプログラムを書けば良いのか。コンソールにHello World!と表示するのは簡單だ。でも、プログラムを書いてみたい豫備軍はそれが最初の一步だと分かっていても、別にそんなことがしたいわけではない。おそらく、Excelなんかじゃとても讀み込めないような大量のデータがあって、それを一兩日中に處理してレポートを作らないといけない・・・などという場面に遭遇したときに、「もしもプログラムが書けたなら、こんなの一瞬で處理出來るのに!」と齒軋りするのであろう。

そういうときのために、プログラムを書けるようになっておきたいと思い、プログラムを書く仕事に就きたいと思う學生が、手っ取り早く就職先に選ぶのはソフトウェア會社だが、ここでよく考えるべきことは、プログラムが書けるようになりたいからソフトウェア會社に入社したいとは何事か!ということである。ソフトウェア會社はプログラマの養成所ではないし、入社したら誰でもすぐにプロのプログラマになれるわけでもない。

そういう勘違いが橫行しているからか、ソフトウェア會社に入社して最初に命じられる仕事は、たいていドキュメント作成という名のワープロ作業である。それは、先輩方がマシン室で段ボール箱を布團代わりに寢るような每日を經て作り上げた、まさに血と汗の結晶とも言うべきプログラムなのか、それとも誰かが鼻歌交じりに遊びで作ったようなプログラムなのかは分からないが、それが一體どういうものなのかを説明するドキュメントを作成する仕事である。その作業は、それがどんなプログラムなのかを理解し、その技の粹を窺い知る上で非常に有意義な作業であると思われるが、プログラムを書けるようになりたいと思って入社した新入社員にとって、それはおそらく相當過酷なものであろう。

そもそもそんな仕事は、順調に推移しているプロジェクトにはなく、たいてい火事になっているプロジェクトに付きものだ。なので、プログラムというものを一度も見たことがないような新入社員をいきなりそういう鐵火場に放り込んでコキ使うなんてことをしたら、その社員は暗澹たる氣分になり、極端な場合はすぐに辭めてしまうのではないだろうか。まして、そういうところにはたいてい2~3日寢なくても何ともないような、惡魔のような體力の持ち主が居て、新入社員につき定時退社しましたなんて言おうものなら、どんな恐ろしい説敎(というよりは愚癡)を受けるか分からない。

プログラムが書けるようになりたいなどという理由でソフトウェア會社に就職したがることが如何に馬鹿げているか、よく考えた方が良い。

| | Comments (0) | TrackBack (0)

プログラミングの話

「もしもピアノが彈けたなら思いのすべてを歌にして君に傳えることだろう」という有名な歌の歌い出しがあるが、「もしもプログラムが書けたなら・・・」という歌はない。たいていの人はこういうプログラムがあったらなあと思うことがあっても、それを自分で書こうなどとは思わない。そんなものはプログラマにやらせておけば良いのだと考えているのだろう。

むかしは、コンサルタント、システムアナリスト、システムエンジニアなどと呼ばれる人たちはシステム開發の經驗者で、さらに元を辿るとプログラマだった。プログラマが年を取ると、プロジェクトリーダになり、さらに經驗を重ねると、營業寄りの仕事に變わるか、エンジニアのまま進むかというキャリア選擇を迎える。エンジニアのまま進む場合は、營業と組んでエンドユーザの要望を聞き、開發よりもさらに上流のシステム提案をするようになる。

最近では、コンサルタントやアナリストという役割が明確になり、開發經驗はなくても資格を取れば、そういう肩書きを名乘れるようになった。おかげで私の周りにはプログラムを全く書いたことがないSEがたくさん居る。彼らは、要望を聞いてそれに對應出來るベンダを選定し、提案書と見積書を作らせて、エンドユーザにそれを提示する、受注したらベンダが構築するのを監督し、完成したら納品する・・・という一連の作業を正確にこなす。それに要するスキルとしては、そのような作業を實施するのに必要な經驗や技術よりも、内部統制や法令順守に關するものの方が多い。要するに實務經驗の有無などどうでも良いし、ましてプログラムが書けるかどうかなど完全に議論の對象外となっている。

このような狀況は、2000年問題の頃から言われている「深刻なSE不足」という問題から始まっていると思われる。システム開發などの實務經驗がなくてもSEが務まるようにするにはどうすれば良いのか。そういう逆轉の發想の元に、システム開發の業務やフローが規定されるようになった。

氣になるのは、システム開發におけるリスクの考え方だと思う。たとえば、下請けベンダが100萬圓で見積を出してきたときに、リスクを取りたいからベンダに20萬圓下げろと言う。ベンダは仕方なく積んでいたリスクを削って、80萬圓の見積に修正してきたとする。これならリスクを積んでいるのがベンダから元請に移っただけだから、エンドユーザにとってはプラマイゼロだと思われるかもしれないが實際は違う。これによって、ベンダは見積書に明示していること以外一切出來ないと態度を硬くしてしまう。實はこれが最も大きなリスクなのだが、にわか仕込みのSEにそんなことが分かるはずがない。なんでもかんでもベンダの言い値でやれば良いというものではないが、ベンダの立場で言えば儲からない仕事をしているのは、自分が惡いわけでもないのに社内で冷遇されるなど非常に嫌なことなのだ。嫌な仕事になれば、やる氣は失せ、ことごとく負のスパイラルに入っていく。こんな案件が良い結果で終わることはない。

そのあたりの機微が分かるSEを育てる必要がある。エンドユーザに媚びるばかりのSEでは上手く行かない。それにはやはり開發經驗は必要であり、そのためにプログラミングに無關心では居られないのだ。

| | Comments (0) | TrackBack (0)

July 09, 2013

食べ物の話(2)

子供の頃の母親の口癖は「ご飯モノを食べやあ」だったと思う。

外食してメニューに惱んでいるとよくそう言われた記憶がある。だが、何となくその場の解決策としてそう言っているのではなく、いつも口癖のように聞こえた。これはおそらく祖母の口癖だったんだろうと想像している。ついでに、困った口癖が「ほかったった(捨ててやった)」だった。これも祖母の口癖を受け繼いでいるらしく、私が何かを大事なものを探しているとよく言われた。しかし、今にして思うと非常に便利な言葉だと思う。こう言えばもう探す必要はなくなるからだ。言われた方は怒り心頭でも、捨てられてしまったものはどうしようもない。そしてしばらく經つと「これ出てきた」と笑っている。そんな母親だったので、子供の頃からよく面と向かって批判したものだ。そしてその都度、パワーでねじ伏せられた。

母親の話ばかりになるが、子供の頃はよく腐ったものを食べさせられた記憶がある。母親はそういうものを食べても何ともないか、少し腹が痛くなる程度だったらしいが、こっちはそんなものに耐性があるはずもなく、あとで大變な目に遭っている。そしてそういうときにいつも言われたことは「腐ったものでも承知で食べれば何ともない」だった。當時は全然理解出來なかったが、要するに氣合で食え!ということなんだろうと思う。

子供の頃のそういう食生活は、外出すると腹痛を起こしたり、氣分を惡くしたり、熱を出したり、ということにつながった氣がするし、外出すると體調を崩すというトラウマは今でも少なからずある。

こんなことを書くと、とんでもない親だね!って言う人も居るかもしれないけど、戰爭中に生まれた人は多かれ少なかれそんな感じではないかと思うし、私と同年代の人ならそういう經驗をしている人は居ると思う。たしかに戰爭中に比べたら、今は夢のような世の中かもしれないけど、親と子の閒には埋めようのない世代ギャップがあるということをもう少し考えて慾しかった氣がする。

| | Comments (0) | TrackBack (0)

July 08, 2013

食べ物の話

食べ物の話で眞っ先に思い出すのは・・・まだ新米社員の頃、現場で晝食を食べることになり、メニューに惱んでいて先輩に怒られたことだ。「おまえのために、みんなが待ってるんだぞ!」これを聞いて、ハッと我に返り「同じものをお願いします」と言った記憶がある。と同時に、そういうことを敎えてくれなかった親に少し恨みを感じた。うちの親は躾には嚴しかったが、集團行動の機微のようなものはほとんど敎えられなかった氣がする。

うちは子供の頃から外食することが多かったので、それなりにいろんなノウハウが自然と身に付いた。ここの店ではこういうものは美味しくないとか、これは時閒がかかるとか・・・一番強烈だったのは親が食べたいものしか注文出來ないということだった。なんで自分が食べるものを親に決められないといけないのか。でも、大人になって思い返すと、親の言うことに閒違いは無かったし、殘したときに食べてあげられるものを注文して慾しいと思うのが當然だ。そして殘し方がおかしいとよく怒られた。おかずだけ食べてしまってご飯だけ殘すなんてことは許されなかった。でも、それはちゃんと理由を話してくれれば、すぐに納得出來るようなことなのに、そういう話は無くて、とにかくよく怒られた。

そう、とにかく子供の頃はなんで怒られているのか分からないことが多かった氣がする。理由を言わないで怒ると言うのは、今にしてみれば理解出來る。ホントにすり込みたい重要なことは、頭ごなしに怒るしかないのだ。そうすると子供は腹が立ち、あれは何だったのか?とイヤでも惱むことになり、それは後々まで身體に染み付くことになるのだ。

| | Comments (0) | TrackBack (0)

July 07, 2013

パッケージ開発(2)

アクセス解析の檢索フレーズを見ると「パッケージ開發」による檢索が多いようだ。まあ、日々のアクセス數がが極微量なので、その中でも他に比べて多いという程度だが・・・。

この數年、民需系SI案件のSEをやっている。これは職場ではそういう位置付けになっているが、一般的ないし客觀的に見れば案件の監督をやっているようなものであって、SEと言えるほど大した檢討も設計もしていない。そういう作業の多くは下請けベンダがやることになっている。つまり下請けがする作業に問題が無いかどうかを確認する役割を擔っているというわけだ。

しかし、顧客の要望を整理してベンダに傳え(實際には顧客との打合せにベンダを同席させる)、構築・導入させると、要望と合わなかったり、實現機能に過不足があったり、バグがあったりする。そういうことが出來るだけ起きないようにするのが我々のミッションだとしても、これをもし顧客と下請けベンダが直に契約してやったら、一體どうなるんだろうと恐ろしくなってくる。もちろん元請になれば、それなりの體制をとってキッチリ仕事こなすベンダもあるとは思うが、明らかにそういうことが出來ないベンダもある。

なぜそうなるのかと言えば、そういう下請けベンダは案件每の、初期ヒアリング、實現方式檢討、提案、積算・見積など、引き合いから受注前までに發生するオーバーヘッドに耐えられないからだ。逆にそういうオーバーヘッドをも擔っている大規模なベンダは總じて(どれだけ客の足元を見れば氣が濟むの?というくらい)高額な費用を要求してくる。中でも、企業の販賣管理、生産管理、財務會計などの基幹系システム案件ではそういう傾向が強い。要するに元請として對應可能なベンダを下請けにするべからずということだ。

個々の案件に接していて強く感じることは、この程度のことなら箱物のパッケージを買ってきて、會社の業務が分かっている人に運用檢討させれば濟むことじゃないかという氣がすることだ。しかし、事務員が數人しか居ない中小企業なら良いが、パッと見でそれぞれが何をしているか分からないくらい社員數が多い會社では、決してシステムの中身の詳細(特にデータ仕樣)までを社員に任せたりしない。その社員が豫告無しに長期休暇を取ったり、退職したりすることを考えただけでも恐ろしいが、脅迫や背任行爲も懸念される。よって、ある程度大きな規模の企業は假に基幹システムを自前で構築・運用可能でも外部に委託せざるを得ないことになっているし、それによって高額な投資が必要となってもやむ無しという認識になっているようだ。

こうして、大して便利でもない、傳票投入して帳簿を作るという程度のシステムを作るのに何億圓ものお金が使われることがある。また、投入ミスや處理漏れを防ぐためのチェックや見直しに關する業務は、人が擔うべきと思い込んでいることが多く、要件に出てこないことが多い。もちろんそういう機能をシステムに具備したら、首筋が寒くなる人も居るのだろうが、コンピュータの處理を人がチェックするような運用は、何の疑義も無く至るところに存在する。こういう問題を永遠の課題とあきらめるのは齒痒い限りである。

| | Comments (0) | TrackBack (0)

July 06, 2013

スキル把握の時期(4)

書いているうちに以前にもどこかで同じようなことを書いたような氣がするが、とりあえず氣にしないことにする。

組織がスキル管理に苦勞するのと同樣に、組織に居る社員も自身が持っているスキルを氣にしている。地味に考えても、スキルに對する個人の考え方は樣々だが、自身が置かれている狀況に最も左右される。IT系の會社に居る惱めるプログラマが、業務上の理由で調理師の免許を取りたいと思うことは無い。自分がプログラマに向いていると自負しているのであれば、プログラミングスキルを向上させたいと思うのが當然だ。

自分でどういうスキルを身に付けたらよいかを分析し實行に移すのは、なかなか困難なものである。ただ單にプログラマとかシステムエンジニアという肩書きが慾しくてIT系の會社に入った人は、スキルアップよりもクビにならないよう振舞いたいだけなのかもしれない。そうでない大部分の人は眞面目にスキルアップしようと努力するが、どうすれば自分が現在擔當している仕事、自分が擔っている役割、將來の自分の姿にとって有效なスキルアップが出來るのかを考え始めると、解を見つけるのが難しくなるのである。思い付きで何かのセミナを受け、資格を取るだけでは解決するかどうか分からない。

また、肩書きが慾しいだけという不純な考えではないにしろ、どういうSEになりたいかは人それぞれ漠然としたイメージを持っている。何でも屋はダメだ。何でも出來ますというアピールは上司を不安にさせるだけである。基幹系システムが得意なSE、インフラ系システムが得意なSE、サービス系システムが得意なSE、業務コンサルが得意なSE・・・どうなるのが一番氣持ち良いか、幸せなのかは分からないが、それらを得意とするにはベースとなるスキル項目と、それらを應用するスキル項目があり、それらを上手く選擇して賢く身に付けた者が有能なSEになれる。

これは最近氣付いたことであるが、エリートになるか職人になるかの境目は、物事をどの程度深く追求すれば氣が濟むかにかかっているということだ。職人になれるほど極めてしまうと、視野が狹くなり、モノの見方や考えに客觀性が無くなっていき、他のことをバランス良く見ることが出來なくなってしまう。エリートは個々のスキルに長けてはいないが、必要な職人を集めて動かすことが出來る。あとは、自分がどちらのタイプの人閒なのかに出來るだけ早く氣付いて、それを意識しながら行動する必要があるということだ。

| | Comments (0) | TrackBack (0)

スキル把握の時期(3)

組織がやってるスキル把握なんて、上手くいくわけないという主旨でダラダラ書いています。

誰が何と言おうと、ある程度大きなIT組織はスキル把握をやろうとする。組織はどういうスキルを把握したがるのか。それは当然のことながら、ビジネスの成功に結び付く(と思われる)スキルに他ならない。そしてIT組織の場合、スキル=資格と考えているようだ。

資格にはいろいろあって、それぞれその資格を取得するための試験があり、それで合格点を取ったものに資格が与えられる。これは運転免許と同じで、資格に関わる営みすべてがひとつのビジネスになっている。資格を得るには試験を受けなければならず、そのためには受験料を払わなければならない。ものによっては資格を得た後も3年に一度は更新試験を受けなければならない。それらの受験料はその資格を扱う団体の主な収入であり、その資格を持ったものがビジネスの現場で活躍すればするほど(というより、活躍していると宣伝すればするほど)、その資格の権威は高まり、さらに多くの人がその資格を得ようと試験を受けるようになる。

資格を得るには試験で合格点を取れば良い。普通に考えれば、既にその資格を得るに足るスキルを持っている人が試験に合格することになるが、スキルが無くても、その試験向けに勉強をすれば合格することが可能になる。つまりスキルが無くても試験に合格すれば資格が与えられ、有スキル者になれるわけだ。

スキルが無いのに試験に合格さえすれば資格が与えられるなんておかしい!と思われるかもしれないが、世の中にある資格なんてたいていそんなものだ。もちろん、資格取得のための勉強をしているうちに真にそのスキルを身につけてしまうこともあるのだろう。反対に、試験に合格して資格をとってしまえば、そのスキルがあるかどうかなどどうでも良いと考える人も多いと思われる。

なぜスキル=資格になったのかと言えば、組織においてはそれ以外に把握のしようがないからだ。IT組織の中に驚嘆すべき開発スキルを持った者が居たとして、資格を持っていなければ組織はその人を有スキル者と認めることは無い。もう少し正確に言うと、そういう人を有スキル者として認めるルールにはなっていない。「認められたいなら、資格を取れば良いじゃないか!」と組織のルールを言われるだけだ。

資格は持っていないが誰が見ても高スキル者に見える者を、組織は有スキル者と認定することが出来ない。無理に認定しようとすれば、それは評価者の主観による認定にならざるを得ないからだ。組織の認定基準として最も客観性の高い公平なものとなると、やはり試験による認定以外に方法が無い。

これまでの言い方からすれば、有スキル者なら試験に合格するはずだが、どうやらそうでもないらしい。それは有スキル者なら合格する試験内容にすると、スキルの無い者は合格出来なくなってしまい、資格ビジネスとして成立しなくなるからだ。それよりも勉強して試験に臨めば、合格出来るかもしれないというイメージにしておくことが重要である。なので、有スキル者が勉強しないでそういう試験を受けると、こんな試験でこのスキルを計れるの?という疑問が湧いてしまう。

まあ、組織のスキル管理なんて概ねこんなものなので、マトモに対応する気にはなれないのである。

| | Comments (0) | TrackBack (0)

July 04, 2013

スキル把握の時期(2)

前の記事で、スキル把握の結果を自組織のあるべき姿に照らしてスキルアップ計画を立てる、と書いた。組織にはあるべき姿というのがある。それを考え、それに導くのが組織を良い状態に保つ責を負う者の役目だ。では、組織のあるべき姿とは何だろうか。

組織の長となる者は、早ければ2年、遅くとも数年のうちには居なくなる。よって「あるべき姿」は数年毎に別の姿に置き換わる。そして組織の長が変わる度に、組織の形が変わり、配下の社員はまるで将棋の駒のように新組織の枠にはめ込まれる。多くの社員は前の年まで取り組んでいた自身のスキルアップ計画を放棄し、新たな組織のあるべき姿に基づいたスキル把握をやらされ、新たなあるべき姿とのギャップを埋めるためのスキルアップ計画に従った社員教育を受けることになる。

しかし、組織があるべき姿になろうとするのはビジネスで成功するためだが、スキルの多寡がビジネスの成功を保証するものだとは限らない。社員全員が高度情報処理資格を有するからビジネスに成功するわけではない。社員全員がプロジェクト管理のスペシャリストだから、高収入・高収益になるわけではない。なにせ、成功に理由なんて無い。

| | Comments (0) | TrackBack (0)

スキル把握の時期

今年も会社ではスキルは悪、じゃなくてスキル把握の時期がやってきた。

スキル把握は組織の構成員がどのスキル項目についてどの程度のレベルにあるかを計るものと思われる。組織はスキル把握の結果に基づいて構成員の実力を知り、スキルレベルが高い項目はどれか、あるいは低いのはどれかを、少なくともマクロ的に知るのであろう。

組織はスキル把握の結果を自組織のあるべき姿に照らしてスキルアップ計画を立てる。そしてスキルが低い部分に投資し、社員を教育し、組織のスキルアップを図る。これにより、次回のスキル把握では投資したスキル項目のレベルが上がっていなければならない。つまり、スキルが低い部分には投資をすれば(必ず?)スキルアップするというのが前提になっている。

社員教育への投資というのは、仕事をする代わりに勉強するための原価と、セミナーなどを受講する場合はそのための費用、の2つを足したものである。さらに忙しい組織では、投資を受けない社員にしわ寄せが発生する。A君はお勉強しないといけないので、B君はA君の仕事も代行してくれ給え!というわけだ。B君にとってはトンだ災難である。そして、B君がA君の仕事を遂行するのに必要なスキルを有しているかどうかは無視されることが多い。仕事よりも社員教育を優先する組織は、いずれ仕事が来なくなり、何のために社員教育をやっているのか分からなくなる、のかな?

| | Comments (0) | TrackBack (0)

July 03, 2013

とりあえずコメントは

削除しました。ほとんどが外国からの読めないようなコメントばかりです。ソニーの記事にたくさんコメントがあったのは意外でした。最近は翻訳して読めるようですけど、意味分かるのかな?

| | Comments (0) | TrackBack (0)

July 02, 2013

8年ぶりの投稿?

8年ぶりの投稿なんて笑っちゃう気がしますが・・・。実はこの数年間別のブログに夢中になっていて、こうなってしまっているわけです。「そんなブログどこにある?」という詮索は無しということで。

あと、スパムの温床に成り下がったメーリングリストをやめた後はSNSをやっていましたが、ノンポリと、何年経っても認識の変遷が見られない書き込みばかりで急速に面白みがなくなりつつあるようです。なんでそうなるのか?SNSというのはメーリングリスト以上に直接的で、ワルぶった書き込みがほとんど出来ないことに今さらながら気付いたのでした。そんなのよりは、もっと衆目を気にせず自分の好きなことを書く方が性に合っているようです。

また暫くはひと通り頭が空っぽになるまで書き続けるのではないかと思います。

| | Comments (0) | TrackBack (0)

« May 2007 | Main | August 2013 »