ぐらめぬ・ぜぷつぇんのはてダ

2008/11/24以降のメインブログはこちらになります。 : http://www.glamenv-septzen.net/

本はてなダイアリにはコメント・トラックバックを受け付ける記事を公開します。

2011-01-07

[]酒飲みながらたまには政治がらみの妄想を垂れ流す。名づけて「黄昏計画」www

全て居酒屋での戯言レベル。笑い話というかネタというか。ぶっちゃけ厨二病的な何か。

数十年後ここに書いてある内の一つでも実現されてたら「俺ってすげー!!」って見せびらかすための証拠的な何か。

「黄昏計画」って?

「もう頑張るの止めようよ、疲れたでしょ?おうちに帰ろうよ。」と、引きこもるための国家レベルの計画。経済成長率の面で言い換えるならば、「ほどほどの経済状態の維持」を目標とする。つまり、プラス成長を目指すのは疲れるからやめて、まぁゼロで横ばい。マイナスは避けようよ、程度。

これを軸として、三つの柱を据える。

  • 鉄鋼、石油、ウランなどどうしても日本国内じゃ賄えない材料以外は、基本自給自足を目指す。
  • 節約志向:贅沢はもう疲れるからやめようよ、的な。
  • 人生のリセット支援

国家レベルで、資本主義の自由経済の良さは残しつつ、「もっと金を、企業成長を、経済成長を」という貪欲さを抑えるのではなく、「放棄」する・・・つまり「本当はもっと経済成長してお金儲けてウハウハしたいんだけど、お上が抑えつけるからできない」という状態ではなくて、「なんだか経済成長、お金儲けバンザイ、ってゆーノリ疲れたな・・・。そこまで貪欲でなくとも、ほどほどでぼちぼちで生きて行けないかな?」ってユー感じで、自主的に棄権するイメージ。お金儲けの競争レースから「一ぬーけた!」でとっととリタイア・棄権しちゃおう、というのを国家レベルの基本目標としちゃうのが「黄昏計画」ww

まぁあくまでも国家としてそういう方向を目指す、そういう方向で色々支援政策を打ち出す、というスタンスで、別に「いーや、俺は会社作って大成長させるぜ〜〜〜!!」という個人や企業を制限とかはしたりしない。まぁその辺はどうぞご勝手にという。

ということで、内側に縮小していくのが基本方向なので、当然自給自足できないと辛い。で、当然、自給自足となると以前ほどの贅沢はできなくなるので、というか贅沢って疲れない?的な。なので、節約志向を支援する。

さらに、どうせ経済成長目指さないんだったら、みんなもう少しゆる〜く生きてみようよ、ってことで、人生のリセット支援も一つの柱に据える。というか「黄昏計画」がマジで実現しちゃうと雇用状態が180度どころか360度回った上に北と南が逆転するくらい環境が変わってしまうので、そもそも「ひとつの会社に50年」という前提が消滅して、どこもかしこも「ひとつの会社は長くて20年」だらけになる。いくつか専門技能や職業上の制約で完全な「スペシャリスト」として30年以上の経験を積んでいく人も出てくるだろうけど、基本、「人生リセット」による「その人なりの『ぼちぼち感』を見つける」ってゆーのを支援する。「ぼちぼち」で満足できちゃえば、無理して贅沢に走ることも無い・・・かも・・・ってなれば、節約志向とつながり、ひいては自給自足支援にもつながり、「国家レベルでのひきこもり」である「黄昏計画」の趣旨とも合致するwwww

では、今現在頭の中でぼわぼわ湧いている妄想政策を、上記三つの柱ごとにメモ。

国家レベルでの自給自足

国内でまかなえる材料に付いてはなるべく国内でまかないましょう、という方針。ただし、鉄鉱石・石油など外国から買わないとどうしようもない材料も当然出てくるので、その分、輸出できる産業は維持する必要は残る。

でもそれなら今までと対して変わらないじゃん?・・・てとこなんだけど、「黄昏計画」ではもうちょい視点を変えて、科学力と技術力を駆使して、錬金術のごとく材料を自給自足できないか?ってゆーのを重要視する。

植物からまだまだ材料は取り出せないかな?繊維や食品としてしか利用できないなんてもったいない。もっと化学製品につながるようなタンパク質やらアミノ酸やら化学反応やらは取り出せないだろうか?

海水からウランを抽出するのを効率化出来ないか?海藻から石油とかどうなった?とかとか。

日本とその周囲に存在する膨大な自然や植物から、もっともっと産業に使える材料を取り出せない?

ってことで、そういう方面の研究やら開発を国家レベルでガンガン支援しますよ〜ってーのが一点目。

二点目が、「人の自給自足」。メインとなるのが「廃村、過疎地域の有効活用」。

猫の額程度ではあるけど田んぼや畑がある廃村や過疎地域を活用して、「最低限度のインフラと、野菜や米の種、肥料代は提供するから、後は自給自足でよろしく!」としちゃう。

これは主に都市部でどうしても就職先が見つからず、もうホームレスになるしか無い・現状なってしまっている人の支援。

最低限度は賄うので、あとは自活してみて。

で、都市部や近郊で1ルーム月云万を国家で負担するのはさすがに無理なので、廃村になったエリアとか過疎地域などを活用する。

電気・水道・ネット環境かな?インフラとしては。ガスはオプション。で、ネット環境使って商売始めるのも有り。

まぁ一種のベーシックインカム。まぁ申し込み対象とか適用対象の制限とかに相当苦労しそうだけど・・・。もちろん、ある程度の収入を自力で得られるようになったらそこから立ち退かなければならない、とか制限は必要かもしれない。

廃村・過疎地域の有効活用に絡んで、「人の分散」も妄想してるんだけどこれは「人生リセット支援」と強く関連するので後述。

節約志向:贅沢はもう疲れるからやめようよ、的な。

高級店の出店規制ではなくて、もっと単純に、所得税の申告時に、一年前の預金残高と今の預金残高を比べて貯蓄が溜まっていれば、あるていど控除されるとか、中〜低所得者向けに、節約を奨励する・優遇する政策を妄想してる。

お給料は少ないけど、それに見合った程々の質素な生活を楽しんでる人をもっと支援する方針。

いや、だって国家レベルでひきこもるのが黄昏計画なんでwww

もちろん虚偽報告であるとか、複数の口座を組み合わせて申告時にだけ貯蓄額が大きいように見せかけるとか悪質行為に対するペナルティは厳しくする必要がある。

また、あくまでも自己申告制なので、まぁ気に食わない人は申告しなければ、従来と変わらない。

企業向けとしては、例えば売上高が同じでも労働時間が短くなればそれだけ効率UPっつーことでいろいろ税制上優遇されるとか。もちろん虚偽報告に対するペナルティや、そのための監査システムは組み上げる必要があるけど。

ぶっちゃけ、国家レベルでひきこもり・内向きになるのでとにかく仕事は確実に、今よりさらに無くなる。つまり企業側にとっても、まぁ企業のノリによりけりだけど、成長志向よりは「ぼちぼち」志向に切り替えないときっついかもしれない。

ようするに勝手に目標高くして「達成できない・・・」と悲嘆にくれるより、現状維持できりゃオッケー、のんびり行こうよ的な企業の活きる余地を国家側としてもなるべく用意出来ればなぁ、ってところ。

なにしろ「黄昏計画」は「ひきこもり計画」、確実に経済規模は縮小していく。というわけで、余ってしまった企業はどんどん倒産していくし、仕事は減って求人も減り、どんどん失業率は上がっていく。

そこで、前述の自給自足支援で受け皿を確保していくとともに、「人生リセット」で仕事と人生を疎結合にして再就職フォローも行っていく。

お金が足りなければ国債バンバン発行して賄う。もちろん、自給自足支援で徹底的に優遇したバイオマテリアル関連で特許取得を奨励して、そのアガリを諸外国からちゃっかりいただくのも忘れずに。

まぁ全体として「貧しくとも慎ましやかに、平穏に」過ごす人たちのことを優遇することで、節約志向を推進する。

人生のリセット支援

基本方針は2点。

  • 人口の都市部集中の解消
  • 仕事と人生の疎結合を支援

まず一点目の都市部集中の解消ですが、これ、あとは会社や仕事、住居の問題さえ解決出来ればかなりごっそり地方に戻せるんじゃないかと。

ぶっちゃけWebを介した物流や大型スーパーの地方進出により、「都会に出ないと手に入らない」日用品ってどんどん減ってるのは確かなんです。あとは「仕事」さえ都市部からひっぺがせれば、もう無理して人口過密な都市部で高い家賃払いつつ満員電車に揉まれる必要はありません。

続いて二点目の仕事と人生の疎結合ですが、これは少々強引ですが「国家による半強制的な領地替え」を妄想しています。5年、あるいは10年毎に他県への引越し・転職を国家レベルで推奨・優遇します。個人だけでなく、企業に対してもそうして移ってきた新しい人を迎え入れたり、5年や10年単位で入れ替わっても問題ない業務プロセスを構築した企業を優遇するようにします。

つまり国家レベルで終身雇用に対して「サヨナラ」を言ってしまうわけです。終身雇用なんて無くとも、個人レベルでの幸せは追求できる国家を目指すんです。少なくとも、目指しているということを各種の優遇・推奨政策で表明するわけです。しかも、5年〜10年サイクルでの転職を全ての年齢層で推奨・優遇してしまうわけですから、とんでもない混乱とパラダイムシフトが起こります。

もちろん、これらの優遇政策は強制ではなくて、自己申告制です。なので「お上はお上、ウチの会社はウチの会社」で終身雇用を貫いても何ら問題はありませんし、20年、30年と同じ会社でスキルを蓄積するのは個人や会社の好みの問題ですので行政からペナルティを与えることはありません。

とりあえず以上を基本方針として、具体的な妄想を垂れ流していきます。

  • VPNを活用した在宅業務の優遇
    • 業務によりけりになってしまうが、例えば本社は東京でも、VPNやSkypeを活用して北海道にいても仕事できるような環境を構築した企業に対しては何かしら優遇措置を行う。法人税の引き下げなど。
    • 個人宅での作業が難しければ、例えば各社の遠隔業務用の部屋が割り当てられるセンター的な建物を各地方に用意して、そこに出勤するとか。
  • 退職時の職場評価の活用
    • 「推薦状」的な仕組みをハローワークなり行政側で用意し、誠実に仕事して周りと上手くやれていれば、転職時にそれを客観的な評価として活用できる。退職後、その職場や会社からハローワークに評価シートを送るなどしてうまく連携できないか?
  • 副業支援政策
    • 例えば農村地方在住で、遠隔で仕事しているのであれば、遠隔作業の時間を少なめにして、農業を兼業するという生活形態もあり得る。そうした副業形態を所得税の申告などで優遇する。また、副業を許可し、そのための便宜を図る企業に対して何らかのボーナスを与える。
  • 海外レベルでの異文化シャッフル
    • 一生のうちに少なくとも二カ国での職業体験を推奨する。年齢は問わない。ワーキングホリデーを全年齢対象に広げ、さらにそのための休職など便宜を図る企業を優遇する。
  • 社会人学生支援
    • 一旦就職した後、大学に再入学する場合に奨学金支援などを行う。また、そうして専門性を高めた人間を雇用する企業に対して何らかのボーナスを与える。

これらにより、「一旦入った会社で一生終身雇用」という文化を破壊し、様々な職業を経験したり、外国での職業体験を通じて人生観が変わったりなどを国家として支援し、優遇する。さらに進化したコンピュータネットワークを活用して可能なかぎり都市部の仕事を地方でもできるようにしたりして、都市部集中の必要性を下げる。

また、国内でも人の入れ替わりを推進し、村社会的な閉鎖性を漸減していく。「ウチの常識はよその非常識」というカルチャーショック体験を推奨する。さらに社会人学生支援を強力に打ち出すことで、「学び直す」ことが可能であることをアピールする。

「真・黄昏計画」ww

「裏」って付けても何らおかしくないネーミングでまさしく厨二病乙www

まぁぶっちゃけると、こういう政策が仮に実現したとしても「まぁ、本来の目的に沿って有効に活用されるのは、もって30年程度じゃね?」というのを前提とするのが「黄昏計画」www

30年も経ってしまえば、世代は変わるし世界情勢は変化するし科学技術の進歩に伴い新たなビジネスは出てくるだろうし環境は変化するし、云々カンヌンで「黄昏計画」の趣旨が通用しなくなってるだろうな〜・・・というのが黄昏計画で忘れちゃいけない大前提www

ただ、その次の30年のためにどういう日本を用意しておけるのか、あるいは自分たちの子ども、さらには孫に、どういう日本社会をプレゼントできるのか・・・ってゆーのを考えたときに、「貧乏でもなんとかなったよ〜、経済成長率について国際社会からボロクソ言われも、案外なんとかやってけるから肩の力抜いていこうぜ〜」っていう「経験」を用意出来れば個人的には素敵だなぁと思うんです。

「経済成長率をプラスにするには、まだ努力が足りない、改善が足りない、もっと貪欲になれよ!!」って〜ノリですと、何時まで経っても「あれが足りない、これが足りない、あれが欲しい、これが欲しい、だから日本はもうダメだ、ウチの会社はもうダメだ、この業界はもうダメだ」と悲観論や滅亡論で堂々巡りばっかりです。

そうじゃなくて、一旦立ち止まって、「アレ?よくよく考えたら、俺らこれだけ良い物持ってるんだから、もうちょっと『ゆっくりしていってね!!』的なノリでもよくね?」って、意外と自分たちの「満たされてる点」を振り返り、活用したりするのはアリなんじゃないかなと妄想するわけです。

っていうか、今のあくせくした、滅亡論・悲観論大好きな週刊誌が飛び交う、さらにそれを目にして脊髄反射的に「だから日本は/会社は/業界はもうだめだ、海外に出ていくしか無い、なぜなら(お好きなラベリング。草食男子でも若者でも老害でもすきなラベリングをどうぞ)はもうダメだからだ」とグダグダのたまい、ブクマコメントとか発言小町で憂さ晴らしガス抜きする。

人身事故で電車が遅れたとき、事故に遭ってしまった人の安否よりも先に、会社に遅刻することを心配し、その場にいない、事故に巻き込まれた人に悪態をつく。

「○○は□□でなければならない」「○○よ、△△せよ」「これからは□□の時代」に脊髄反射で不安感や焦燥感を掻き立てられる。

そんな日本人や日本社会、子供とか孫に残したい?いやまぁ、所詮これまで書いたのも個人の妄想だし好みの問題だけど、あくまでも個人の意見だけど、こと人生と仕事の価値観に付いては、もうちょいゆるゆるでもよくね?っつーのが本音。

で、結局「黄昏計画」ってーのは「どこまで貧乏でも国家として維持できるか」を試すチキンレースでもあるわけで。

とにかくひきこもり+内需縮小確定な計画なので、人が余る余る。公務員も余る。余分な企業は倒産する。転職も支援はするけど、専門技能の蓄積が不要なオフィスワークや単純作業が中心となってしまうかもしれない。

「黄昏計画」のもうひとつの狙いとしては、国家レベルで「まぁ60年〜80年が寿命の人間が作る組織なんて、せいぜいもって30年だよねwww」というのを明確に各種支援・優遇政策で打ち出し浸透させるっつーのもあったり。

もちろん50年以上活動を続ける、立派な大企業もあるわけだけれど、まぁ無理してそれを目指さなくてもいいじゃない、っていう。

計画自体がその根っこに「まぁこの計画ももって30年だよねwww」としてるので。

なので、ホントのホントに最後の狙いとしては、「さて、どうやって死のうか?」っつーのをかなり早い段階からデザインさせるっつーのがある。まぁ狙ったとおりに死ぬことなんて運絡みもあって難しいとは思うけど、それでも、老いて病気になって苦しんで死ぬことを前提とした人生設計や組織設計ができるようになれば、結構世の中変わるんじゃない?ってーのは根拠のない妄想としてあるんです。

お酒も無くなっちゃったので、今宵の妄想はこれまで。

2010-08-15

[][] 派遣PGの感じる「怒り」をデコンパイルしてみた

はてなブックマーク - 未ブックマークエントリー

昨日〜今日にかけてはてブで盛り上がりを見せたエントリです。ここぞとばかりに、IT業界の日頃の不満をブクマコメントに叩き付け、「これだから日本のIT業界は、大企業は駄目なんだ(嘆息)」と溜飲を下げる技術者が多数続出しています。

自分もその一人で、ブクマコメントで愚痴を呟いています。

技術面での良し悪し・新旧・正邪ではなくて、リーダーやマネジャー・組織文化・経営レベルの好き嫌いや不安感で、辛い縛りが根付いてる。一人の作業者じゃどうにも出来ない。どこにでもある人間の問題。

はてなブックマーク - msakamoto-sfのブックマーク / 2010年8月13日

しかし、このエントリでは少し視点を変え、「何故自分は、こうしたネタに挙げられている現場に対してエントリと同様の怒りを覚えるのだろう、あるいはエントリの著者は怒りを感じているのだろう」という点について自分なりに掘り下げたいと思います。

端的にまとめると、次の三つが「怒り」を作り出した犯人です。

  • 「最新技術へのキャッチアップ」という名の脅迫状
  • 「WHY」の断絶
  • 独りよがりの「美しいソースコード」

「最新技術へのキャッチアップ」については、その裏側に「『自分だけ』向上心」という真犯人が居ますがそれは最後に紹介します。


「最新技術へのキャッチアップ」という名の脅迫状

システム構築の現場作業員として、マネージャやリーダであろうと、SEやPGであろうと、真面目に知識や技術を向上させようとしている人間であれば、昨今のITニュースやWEB+DB PRESS、ソフトウェアデザインなどの専門誌、@ITやITProなどをこまめにチェックして「アンテナの感度」を高めていることと思われます。メディアでは技術を世に広めるという目的で最新技術や既存技術でもより深く掘り下げた解説記事が目に飛び込んできます。

すると、真面目に勉強しようとしている人ほど次々と目に飛び込んでくる記事に対し、「あ、Subversion良さそうだな、試してみよう、上手く行ったら会社でも使いたいな」と反応してしまいます。バージョン管理の話題であれば、一昔前であればSubversion, 昨今はgitなど分散管理系の記事をよく目にします。DBであればMySQLなどのオープンソースから、最近はKVSでしょうか。Web開発のプログラミング言語に目を向けますと、JavaからPHP、すこしPerlが盛り上がったところでRuby on Railsが波に乗ったかと思えば今度はクラウドでGoogle様が使っているからPython、それを脇目にScalaやJavaScriptなど・・・というふうに挙げていくだけでも大変です。

では、こうした技術を真面目に、真面目に勉強してキャッチアップしたとして・・・「システム構築の現場作業員として」使うことがあるのでしょうか?そもそも、技術の流行廃り自体が、SI現場の時間の流れと大きくずれてしまっているのではないでしょうか?

プログラミング言語にせよ、DBにせよ、バージョン管理システムにせよ、アジャイルなど開発プロセスの技法にせよ、一度現場に導入されて使われ始めると、その現場の文化や組織風土に根付いて慣性を持ってしまいます。半年後、数年後により新しく使いやすいオープンソースが登場したからといって、すぐに乗り換えることは出来ません。特にレベルの高い技術者を常時確保できるわけではない現場であれば、多少使いづらさがあったとしても、ツールを変更してトラブルになるリスクを避けたい場合もあるでしょう。

しかし真面目な真面目な技術者は、「そうと分かっていても」雑誌やWebで新しい技術が話題になる度に焦燥感に駆られるかもしれません。

「次はこれを勉強して身につけておかないと、あなたの市場価値が無くなる(かもしれない)」

と脅されているように感じてしまうからです。

雑誌自身は別に脅しているわけでも、ましてや脅迫状を配布しているわけでもありません。単純に最新技術をわかりやすく紹介し、広く世の中に広めるという目的を遂行しているだけかもしれません。

単に「受け手側が、勝手に、」脅されていると感じてしまっているだけの話です。

「自分がせっかく勉強した最新技術も、現場で活かせない」という不満を持っているエンジニアの皆さん、一度、自分が「最新技術へのキャッチアップ」という脅迫状に踊らされていないか振り返ってみては如何でしょうか?

今誌面を飾っているプログラミング言語は、はてなブクマで話題になっているデータストアの最新ソフトウェアは、本当に、本当に、現場で使いますか?自分の役職や組織風土、文化を念頭において考えてみた上で、現実問題として現場で使えるものでしょうか?

例えばあなたが3ヶ月契約でPGとして派遣された現場がVSSすら使わず、コードをコメントアウトして残しておくことでバージョン管理していたとします。当然真面目で勉強好きなあなたは、「これではイカン!!Subversionを or gitを導入すべきだ!!」と怒りに身を震わせるでしょう。

ですが、あなたは3ヶ月でその現場とおさらばする作業員でしかありません。

現場で前から、そしてこれからも開発作業に携わる人にとってみれば、「新参者が何口出してんだゴルァ、うちのやり方に文句つけるのか!?」と感じてしまうかもしれません。

無理してSubversionを導入したとしても、あなたが3ヶ月後その現場を去った後、「やっと口うるさいのが居なくなった、せいせいしたwww」と以前の管理方法に戻すかもしれません。

自分自身書いてて鬱になってきましたが、とにかく、「最新技術へのキャッチアップ」に踊らされて「怒り」に身を任せたとしても、楽しい結末を迎えることは無いでしょう。

IT技術者の「怒り」を生み出す原因その1,「最新技術へのキャッチアップ」という名の脅迫状でした。

「WHY」の断絶

  • 「なんで時間がCHAR(14)なんだ。DBのタイムスタンプ型使えよ。」
  • 「予備カラムが凄い数。ALTER TABLEあるだろう?」
  • 「とにかく、現場の常識は世界の非常識!」

「最新技術へのキャッチアップ」でも触れましたが、真面目な勉強好きの技術者は今日もせっせと@ITやITmedia、gihyo.jp、ソフトウェアデザインやWEB+DB PRESSに目を通しているかもしれません。

そうしたメディアでは最新技術とその活用法がたくさん出てきますが、大抵は移り変わりの激しいWeb開発の世界を舞台にした解説記事・サンプルコードになってきます。

そうなると、その技術者にとってのコードの標準、ひいては世界の常識はWeb開発の世界の常識になってきます。そうした技術者が下請けのPGやSEとして、COBOL文化が息づいている現場に出向くと、まさしく異文化衝突が発生します。

問題は、衝突が発生した常識について「なぜ、それが常識として定着したのか」のWHYが誰も語れない点ではないでしょうか?

例えばヒンズー教徒に日本のカレーをご馳走したとしましょう。あなたが精魂込めて煮込んだビーフカレー、しかしそのヒンズー教徒は口をつけようとしません。

ここでもしかりに、「WHY」の部分をあなたが知らず、ヒンズー教徒に質問しても答えられずただ「ビーフカレーは駄目」とだけ言われたら、あなたは納得できずに厭な思いをするでしょう。

しかしヒンズー教では牛は聖なる動物なので食べることができない、という理由を説明されれば、WHYを知ることができたあなたは少なくとも納得は出来るでしょう。「じゃぁチキンカレーを振る舞おうか、豆カレーを振る舞おうか」と次善策を考えることも出来るでしょう。

常識が異なる点に対して怒りを覚えているわけではないと思います。

「なぜ」それが常識となったのか、納得できる理由が説明されず、ただ盲目的な服従を強いられるから、怒りを覚えてしまうのではないでしょうか。

とはいえ、理由を説明できない相手だけを責めることは出来ないでしょう。「なぜWeb開発の世界では時刻をDBのタイムスタンプ型で保持するのですか?」「なぜ簡単にレイアウトできるTABLEレイアウトを使わず、floatやbox-sizeに関するIEのbugなどに苦労しつつCSSを使ってレイアウトするのですか?」などなど、逆に自分たちが問われたときに、どれほど「納得できる理由」を説明できるのでしょうか?

只何となく「雑誌や書籍でそうしていたから」では、「先輩がそうしていたから」と同様、何ら自分の頭で考えたわけではないことになってしまいます。

これについては組織やチーム内での知識の伝承というテーマも絡みますので単純な解決策は考えつきません。しかし「WHY」を説明できないのは、相手も自分も一緒、と考えることで少しは「怒り」も収まるかもしれません。

IT技術者の「怒り」を生み出す原因その2,「WHY」の断絶でした。

独りよがりの「美しいソースコード」

自分が最新技術へのキャッチアップに踊らされていると分かっていても、WHYの断絶が怒りを生み出していることを理解していても、現場で「メソッド分けるな、一つのメソッドにまとめろ」とか「クラスを作るな、オブジェクト指向するな」とか言われると怒りを感じてしまうのではないでしょうか。

自分自身が美しいと思えるソースコードと真逆のことと思われます。

しかし「美しいソースコード」とは何でしょうか?もちろんアルゴリズムの妙技というのもありますが、SI現場のソースコードで「美しい」と感じる観点は、クラス設計であったりフレームワークの切り分け方、使い方、デザインパターンの活用などではないでしょうか。

それらは「ソースコードの保守性」を向上させますので、「美しいソースコード」というのは「変更・拡張がしやすい、読みやすいソースコード」と言い換えても、特にSI現場に絞れば異論は少ないと思います。

つまり「美しい」ソースコードと真逆のソースコードを書かされる時に感じる「怒り」というのは、「将来的に変更・拡張がしづらく、他人のコードを見ても何が書いてあるのか分からないソースコード」を書かされ、それにより「デバッグ作業が大変になる」ケースや「将来また自分が担当して変更・拡張するのが大変になる」など、自分に火の粉がかかる可能性を想像したために「怒り」を感じているのではないでしょうか。

将来大変になることを分かっていてその作業をやらされる、それも納得できるWHYを説明されずただ盲目的に服従を強いられる・・・書いているだけでも辛い状況です。

ところが、「保守しやすい」「美しい」というのはかなり主観的なもので、他人に説明しづらいと思います。それこそ「なぜオブジェクト指向を使う必要があるのか」というレベルから「WHY」を説明することになりかねません。

ある人にとっては、適切にメソッド分割されたソースを「保守しやすい」と感じますが、別の人にしてみれば「処理が上下に飛んで分かりづらい、保守しにくい」と感じるわけです。

個々人の感性の問題も絡みますので、結局の所「ソースコードの美しさ、保守のしやすさ」は個々人に依って感じ方が異なってしまう、独りよがりなものになってしまいます。

そしてそれが積み重なり、作法として組織に定着してしまうと、ぱっと出の派遣PGが異を唱えたところで覆すことは難しいかもしれません。

上手い解決方法は見つかりませんが、とりあえず開き直って、組織に定着したと言うことは、自分から見てどんなにおかしな作法であったとしても、少なくともその組織に限って、それなりに保守・メンテしやすい・・・のかもしれない、なぁ、と割り切るというのはどうでしょう?でないと、独りよがりな「保守しやすさ・メンテしやすさ」のギャップから来る「怒り」をひたすら押さえ込まなければならず、相当辛い日々になると思います。

IT技術者の「怒り」を生み出す原因その3,独りよがりの「美しいソースコード」でした。

「『自分だけ』向上心」で疲れ切った自分を振り返りつつ。

向上心、それ自体は悪いものではないと思います。どの方向に向けるかによって社会の役に立ったり犯罪になってしまったりと変化してしまいますが、少なくともIT技術者として、技術や開発技法を学ぼうという向上心は無いよりは有った方が良いでしょう。

しかし、今から考えると、自分はそのベクトルを少し間違えていたな〜と思わないでもありません。

というのは、「なぜプライベートタイムを削ってまで勉強するのか?」と問われたときに、本心から現場を改善したいから、とは言えなかったからです。

ぶっちゃけると、「単に上司から褒められたいから勉強していた」のが本音でした。

上司から、「よく最新技術を勉強して、活用してくれたね〜いいこいいこ」してもらいたかったから、プライベートタイムを削ってまで勉強していたのです。

上司より身近で共に現場で作業している同僚や、お客様のプロジェクトマネジャー、リーダー、開発メンバーなど全く視野に入れていませんでした。(なので、仕事が終わった深夜に「お勉強」してその結果遅刻したこともそれほどクリティカルにはとらえていませんでした)

「会社が倒産しても『自分だけは』すぐ次の会社に就職できるように」と、技術習得に励んでいた面も否定できません。

このように、単なる自己満足や自己の保身を目的とした向上心を、ここでは「『自分だけ』向上心」と名付けてみました。

「『自分だけ』向上心」にとらわれてしまうと、どうしても上から目線になってしまいます。「上司から褒めてもらいたい」というのは「立場が上の者からの権威付けが欲しい」という裏の欲求に基づいています。「権威付けされて威張りたい」というのが真の目的です。

「オレはこれだけ勉強してるんだ、偉いだろう、知識も技術もおまえらより凄いんだ」と威張り散らしたいだけです。

振り返ると、それは自分の普段の言動や態度からにじみ出ていました。

「何で○○(数ヶ月前雑誌やWebでみかけたオープンソースソフトや開発技法)を活用しないんですか?」

→(本意):「私は最新技術である○○の知識を持っています、あなた方より偉いんです。」

こんな輩の言うことを真剣に聞いてくれる人なんているはずがありません。

結局、現実が思い通りにならずに

「自分はこんなに勉強しているのに周りは聞く耳持たない、だから今の現場は駄目なんだ」

となるわけです。

もしも真面目で勉強好きな人でこの話にドキリとしたら、一度「なぜ自分はこれほど真面目に最新技術を勉強しているのか」自問してみると良いかもしれません。

いやホント、本気で最新技術を導入たいのであれば、まずは普通に現場で働き、お客様と仲良くなることが先だろう・・・と今では思います。

Webで愚痴らない人たち

冷静な現実派エントリを見つけましたので紹介します。

彼らにはスキルが無いんだ。

彼らには新しい技術を学ぶ学習意欲がないんだ。

彼らはバカだからそうやっているのだ。

そのように結果からだけ断じ評価してしまうのは簡単ですが、本当にそれでいいのでしょうか?

本当に他人事でいいの?

ITドカタを笑ってすましてちゃだめだろ - 紅茶屋くいっぱのあれこれ日記

結局、Web上で誰かが発言した「IT土方ワロス」に反応して、合わせ鏡の間を行ったり来たりしながら、延々と「IT業界って終わってるよねー」と鏡に映る自分相手に愚痴を呟いているだけなのかもしれません。

そろそろ、そんな無間地獄、終わりにしたいですよね。

2008-09-18

[][]誰だよ、新人をそんなAさんの下に配置したやつ。

元ネタ:ページが見つかりません|gihyo.jp … 技術評論社

実はAさんは職場で有名なお局様で,周りの人は,常に気を使って話をしている状態でした。そんな方の逆鱗に触れ,新人としては異例の異動となりました。

ページが見つかりません|gihyo.jp … 技術評論社

新人がそうした背景を知らないのは当然。むしろ社内のコネクションもツテもない(記事を見た感じでは一緒にAさんの下についた人も居ない=ひとりぼっち)新人なのだからこういう結末も想定通りの筈。

周りの奴らが一言新人に教えてあげるとか、フォローの仕方も有った筈。

AさんもAさんだし、K君もぷっつんしかかってるAさんからの詰問に対して軽口で返すなど対応間違えてない?と問いたい部分があってどっちもどっちという感じはあるけど、それでも周りの動きで別の展開も有り得たのじゃなかろうか。

気分が悪くなる話だ。

ムカツクので好きなように「続き」を書いてやる。

ケチのついたK君は問題のある職場を転々とする羽目になりましたが、その時その時で必死に勉強するようになり、やがてマネジメント・技術力共に社内で一目置かれるようになりました。

新人時代の過ちは教訓としてK君の中に残り、人間関係の面でも成長を遂げたK君は現在は独立し、自分の人生を歩んでいます。

あー、スッキリした!

[][][][]この報告書見て、一体何人がRoRを使おうと思うか興味津々なんです。


元ネタ:2007年度「自治体等におけるオープンソースソフトウェア活用に向けての導入実証」成果:IPA 独立行政法人 情報処理推進機構

2007年度「自治体等におけるオープンソースソフトウェア活用に向けての導入実証」成果 Rubyの普及を目指した自治体基幹業務システム構築:IPA 独立行政法人 情報処理推進機構

実際に報告書読んでみましたが、

  • 和暦換算やレポート出力など自前で開発する必要があった。
  • DBの構造的にActiveRecordの長所を活かせない。(人工キー"id"が利用できず、自然キーを手動で用いた)
  • 数日間の研修だけでは不十分で、RubyとRailsに熟達した人達のサポートが不可欠。
  • ウォーターフォールで、Railsのテスト機能を活かせなかった。

という点が気になりました。あとコーレビューのあたりで「1行の桁数が80桁以内に収まっていない。」という部分はこだわり過ぎじゃないのかと正直思いました。

正直なところ、Railsはあんまりこのシステムには合ってなかったんじゃないかなーと思ったり。

Railsの長所であるWeb開発における「割り切り」が殆ど封印させられた状態になってしまった気がします。

Railsって、Railsの敷いたレールに沿って動かせば簡単に作れますよー、というのが売りだと自分では理解して居るんですが、この報告書を読む限りでは、そのレールが業務システムに合ってないので、わざわざ自分達なりのレールを用意する必要があったと感じます。

Rubyが、じゃなくてRailsが、です。一応。

あとDBとのやりとりでトランザクションの話が出てこなかったのが気になりました。MyISAMでやったのか、InnoDBでトランザクションを使ったのか、テーブルの用途によって使い分けたのか興味あります。

2008-03-18

[] "test early and fail fast"

「リーン開発の本質」メアリー・ポッペンディーク, トム・ポッペンディーク 日経BP社

読書中。

p35:

品質管理組織は、後からテストによって品質を保証するのではなく、最初からコードに品質を作り込ませるプロセスに重点を置くべきである。

...

「人為的なミスが原因と思われる欠陥の8割は、実際には、そのミスの発生を許すシステムが原因で起きている」

目から鱗。いや・・・これ、Webアプリのフレームワークにとって非常に重要な哲学だし、元々こうした狙いが含まれていたことは確かだと思う。

p145:

ムラリーは「早期にテストし、速く失敗する("test early and fail fast")」という哲学を説いた。

...

プラット・アンド・ホイットニーの新型エンジンは、十分にテストされていたので、フライトテストの必要はないと考えられていた。だが、エンジニアたちの知恵によって、とにかくテストをしてみようということになった。

...

その結果、エンジンのバックファイアが激しく、大事な部品のひとつを設計しなおさなくてはならないことがわかった。ムラリーはこう答えた。「すばらしいじゃないか!問題を早期発見したぞ」

禿同。また、テストを思いつき、実行したエンジニア達に脱帽。

これ以外にも有益な示唆を得ることが出来ている。それでいて、まだ半分までしか読んでいない。十二分に元が取れそう。

実は最近気になっているとあるテーマ*1が、かなり本書と関連していることがわかってきた。また、これをWebアプリケーションのセキュリティの確保という視点を絡めることで、フレームワークについても新しい角度から眺められるかも知れない。

*1:「レッスン4,敬意を払え」