minor tranquilizer

先日の談義が続いていたので、またまた私的に追加整理しとくことにしました。
「カレーなる辛口Javaな転職日記」さんリンクありがとうございます。

>>>>>[SIer][システム開発]技術的老化というSIerの持病（2007年9月25日 GoTheDistance）

　前回の後半各エントリへの返信。「ダメエンジニアをかき集めて仕事を進めるスキーム」をどう変えるのかという議論を見据えつつ、SIerの人材マネジメントをどう考えるのか？を議論したい。特定領域に強みを発揮する専門会社群っていうのは総合病院のようなものが出来るイメージだなって話。
　そして後半は本議論とは少し別の話だが、この業界が抱えるもうひとつの構造的問題「人月とExcelとスーツで出来たオヤジ」との世代間闘争の話。（というか階級間闘争か？）

　[コメント]
　良い意味で白熱してまいりました。良い技術者と悪い技術者を統一的且つ網羅的に判断できるクライテリアは確かに必要だと思います。でも仰るようにこの業界の親父さん達はITSS!コールをしだすんだろうなっていう予想は同感。
　私的には、もう少し地に足ついた属性情報・・・つまり言語ごとの習得レベルとか、設計技法（DOAやOOAなどの考え方、UMLなどの表記技法や、テストの技法、etc…）とか、EclipseやTracなどのツール操作スキルとか、それぞれで知識レベルや経験レベルを整理できると、いい感じな気がするんですよね。そういう意味では、最近ではRubyなんかも技術者認定制度を始めるみたいだし。まあ資格オタクみたいな人もいて、やたら資格もってるけど実戦は・・・みたいなこともありましたが。

>>>>>>なんか誤解されてるな（2007年9月26日 雑種路線でいこう）

　「[SIer][システム開発]技術的老化というSIerの持病」への返信。

ポイントは駄目なエンジニアを切れないことが問題なのではなくて、ユーザー企業が必要とする技術は変わるのに、そこで機動的に技術者を入れ替えられないことが問題なんだけどな。
なんか誤解されてるな（2007年9月26日 雑種路線でいこう）

　[コメント]
　ITSSは、自分が前にいた会社の場合「いままでの、つぎはぎを重ね老朽化した制度に変わる救世主として」採用を検討したために、頓挫しました。だからといって、あるべき論から入れば導入できるのかっていうとそうでもないような気がします。結局、資格を軸にした制度ってのが分かりやすいのかなあって気がしました晩年は。その際に資格オタクの問題と陳腐化の問題が出てきますが、前者はキャリア制度と組み合わせて、あまり関係ない資格を取得しまくらないような足枷を設けたり、後者の陳腐化っていうところは、必要性が薄まっていきそうな技術に関しては、重み比率をわざと経年劣化させていくことで自発的なスキル移転を促すっていう・・・書いてて妄想レベルになってきたのでこの辺で。

>>>>>[雑記]SIerにキンタマつかまれてるユーザー企業はSIerと心中するしかないね（2007年9月22日 ザキンコの日記）

　どっちにしろモラルのないSIerに未来はないけど、社員を使い捨てにして自分達の退職金だけはせしめようってお偉方が居るSIerには気をつけろっていう話。

　[コメント]
　逃げきり世代に逃げきられないためにはどうすれば良いんでしょうね？
　なんだか　「丸山眞男」をひっぱたきたい　をふと思い起こしてしまいました。

>>>>>[システム開発]SI屋と顧客の未来（2007年9月23日 masayangの日記（ピスト通勤他）

　利益追求を求められる会社組織としてみれば、キンタマつかんだSI屋ってのは、実は「モラルのある」行動をとってきた。そのワケは・・・って話。それで、予想されるシナリオを披露。

　[コメント]
　私もシナリオ１→シナリオ２が濃厚な気がします。でも既存の制約に縛られない会社が絶対勃興してくるはず。それがつまり外資なのかも知れないけど。日本人ってもしかしてDNAレベルでパラダイス鎖国と出遅れスタートが大好き民族？

>>>>>>[システム開発][Agile開発][どうでも良いこと]どーしたらいいんだろうね（2007年9月25日 masayangの日記（ピスト通勤他）

　「[SIer][システム開発]技術的老化というSIerの持病」への返信。

　[コメント]
　ウォーターフォールモデル自体が既に破綻してますよね近年は。でも決裁するオヤジがそれしか分かんないから、当面は無理矢理ウォーターフォールをあてはめて破綻するか、周囲の理解やサポートなしでアジャイルを適用しようとして習熟不足で破綻するか。たしかに詰んでますな。
　こうしたblogに書きなぐっているだけだと打開できないのは同感ですが、こうして整理しとくことで少しでもオヤジ抵抗力がUPすればそれはそれで。

以上、元記事にも追加。蛇足ですが。

ookawara.com 記事に反応！ SIer

100時間録画OK ワンセグ搭載のフラグシップウォークマン「NW-A910」（2007年09月27日 ITmedia +D）
公式情報はこちら

　ワンセグEPG予約録画対応、ノイズキャンセリング機能搭載、など機能がけっこうすごい。あと、ナニゲに重さが74gって書いてあった。
　液晶サイズとスタイリッシュなUIではiPodに負けてるけど、これはこれでiPod対抗としては良いバランスだと思う。
　けど、iPodの凄さってハードウェアだけじゃなくてiTunesも重要なファクターっぽいですよね。使ったことないんで良くは知りませんけど。
　SonicStageも地道にVer.UPしてるけどどうなんだろう。特に動作性能は気になるところ。Linux版でないかなあ。

　それにしても、ワンセグってすごい供給量ですよね。全ての携帯電話に搭載される日も近そうだし。ただでさえ整合性がアヤシイNHK受信料モデル、完全に崩壊な気が。

ワンセグ受信機も受信契約の対象です。
ただし、ご家庭ですでに受信契約をいただいている場合には、
新たにワンセグの受信機を購入されたとしても、
改めて受信契約をしていただく必要はありません。
（公式サイト）ワンセグNHKサービス受信料について

　苦しいね・・・

ookawara.com 記事に反応！ NHK, Sony

[Java][プログラミング]プログラマなら人月なんかさっさと超えろ（2007年9月25日 矢野勉のはてな日記）

　別に私、凄い人じゃありませんので恐縮ですが、脊髄反射的エールを。

　これってJavaに限らず、重層下請け構造の中では、どこも程度の違いこそあれ、似た状況ですね。

　逆に「人月」というものをうまく利用して、割り当てられた仕事をさっさと終わらせ、あとは自分の成長のためにうまく使っていけ！という風に受け取りました。総じて同感です。

　でも「人月」っていう単位そのものについて言うと、受託開発において作ったプログラムをお金に換えるツールとして「人月」よりよいものが思いつかないし、プログラムであれ何であれ、開発におけるタスク1つ1つのコストを見積もるための原始単位は時間（分）なので、それを積み上げていったら人月になっちゃった、という感じです。
＃DanKogai様のようなスーパーな方は、秒って噂も・・・

　「人月」をやめようとしても、それに変わるものがまた必要となり、結局は問題が出てくるんだと思います。

　グラムとかメートルとか、要するに単位ですよね。同じ100グラムでも店によって値段も質も違うと。だから値段と質が重要なんだと。
　さらに言えばソフトウェアの質を表現すること、基準化することに、皆四苦八苦しているし、プログラマでも直接的に良し悪しに影響をあたえられる部分が、質である。

　なので個人的には、プロジェクトリーダーとかじゃなくて、プログラマという立場であったなら「人月を越えろ」っていうより「人月は忘れて別のことを考えよう」って言いたい。

　具体的には、過去の自分との戦いですね。20代でバリバリだったころの自分と比べて、体力に任せてつくれる「量」は減ったけど、「質」を高めて、過去の自分よりも効率よく成果が出せているか？
　もっとミクロな世界では、昨日の自分よりも良い仕事ができているか？明日もっと良い仕事をするためには何が問題で、どう解決すべきか？

　それを考えていると、1人月が多いとか少ないとか、どうでもよくなってしまいます。

　でも仕事を直接お金に換える必要がある立場に立ったら、先に書いたように結局「人月」を使うんですけどね。

　以上、勢いの余波を食らって書きました。あんまりノリノリじゃなくてすみません。

関連記事：明日の自分を創る

ookawara.com すごい奴ら, 記事に反応！ SIer

ソフトウェア会社が投資すべきたった3つのもの（2007年9月24日 shi3zの日記）
に禿しく共感しますね。特に以下の点が。

どんなプログラムでもまずループの内側から高速化しろ、というのは最適化の鉄則です。
ソフトウェア会社が投資すべきたった3つのもの（2007年9月24日 shi3zの日記）

　作業環境を良くする、ってのを真っ先にやるべきだと、自分も思います。
　個人でPC買うときも「ディスプレイ」と「マウス」と「キーボード」でかなり悩むわけだから、それが人にとって自然ってことで、会社も「人が資本、財産です」って言ってるとしたら、それは会社の最優先課題でしょう。
　それやらずして、経営効率が云々とかエライ人に言われても、はあ？って感じだし。

　そして、さらに、作業環境改善を「会社がやってくれるのを期待する以前に、現場の当人達で考えて会社に提案する」っていう意識が社員にも必要であると思う。

　自分のやるべきことを棚にあげて、何につけても、会社が、会社が、っていう社員がたまーにいたけど「オマエの言ってる会社ってのは誰のことなんだよ。オマエは会社に扶養してもらいにきているわけじゃなくて、”働いて”金をもらいに来てるんだろう？」と言いたくなるときが、過去に多々ありました。

　次にこれも共感。

この「未知への投資」は全くのムダに終わることもあれば思わぬ副産物を生み出すこともあります。
重要なのは、死なない程度に未知への投資をし続けることです。
それは結局のところ社員の発想を停滞から救い、新しい発想でものごとに取り組めるよう刺激を与えるためです。
ソフトウェア会社が投資すべきたった3つのもの（2007年9月24日 shi3zの日記）

　技術者の理想。これがないと、やってて楽しくないですよね。そもそも、ソフトウェアという分野を仕事に選んだこと自体が、これだったり。
　安定した生活とか、そこそこ楽して高めの給料ほしかったら、頑張って資格とかとって、他の業種を選ぶ方がよいような。（実際は選んだことないし、選べるほど多才じゃなかったのが自分の場合ですが）

　これって例えば、自分がトヨタよりホンダが好きな理由が、ここにあるような気がした。実際は、トヨタだって未知への投資はたくさんしているだろうけど、なんかイメージがね。より「お硬い」感じなんですよね。

　でもってトヨタの話題。

トヨタカレンダーってご存知ですか（2007年9月24日 一般システムエンジニアの刻苦勉励）
トヨタが生産台数・販売台数で世界一になれた理由とは?（2007年09月25日 安藤怜のロンドン灯）
トヨタ自動車 利益2兆円生む「プチ北朝鮮」の実態（2007年9月21日 9:07 My News Japan）

　日本のみならず世界的にもトップ集団に属する企業なだけに、視点が違えばいろいろな評価・評論があるけど、世の中の全ての会社がトヨタモデルでうまくいくとは限らない、ということと、いまは我が世の春を謳歌し、かつ日本にとっても主力産業の1つである自動車産業も、いずれはいまよりも沈むときが来るだろうから、それらにとって変われるくらいの産業を盛り上げておかないと、ヤバイんじゃないですか日本は、というある種ありがちな評論的感想を抱いてしまいました。

　でもやっぱりトヨタに見習うべきは、一貫した現場主体、現場重視の姿勢なんでしょうね。
　トヨタのどこを見習って、どこを見習わずに自分たちで独自に編みだすのか。

　なんか、自分の経験してきたソフトウェア業界に限って言えば、もうそろそろ業界の主導権を、トヨタに代表される「高度成長期産業」パターンをつぶさに見てきた人たちから、Googleパターンを肌で感じている人たちに、移譲していくべきだと思いました・・・

　ソフトウェアの生産性が、相も変わらず共通化とかフレームワーク化を主軸にして語られるとしたら、それって工業全盛期の、亡霊にとりつかれすぎてない？
（そうではない人たちも沢山いるのは知ってるけど、私が過去属していた重厚下請構造の頂点にいるSIerの経営者は結構硬直な人が多いと思うのであえて言ってみる）

　ってのと、結局、ソフトウェア作りは頭脳労働の比率が高いので、より科学的に頭脳労働の効率化を追求していくことが必要なのかなあと。ガジェットだけじゃなくて、職場の物理的な色とか、温度とか、時間帯とかね。脳を活性化させるためのTIPSが、いろいろあると思うんですよね。

　ソフトウェア業界でも、元気のいい会社、うまくいってる会社の典型的パターンとして、冒頭の紹介のような事例が増えると良い。そして自分もそのパターンを見習って世の中に貢献できるくらいの成功を手にしたいと思いますっていう結論。

ookawara.com 記事に反応！ SIer

　ネット上や同業者の界隈で、古くから長きに渡って議論されている、日本のSIビジネスにおける問題点の1つ。
　ここ数日、わりと濃厚な議論がネット上で交わされていた。
　自分も類似の問題意識を持っているので、自分用メモとして、一連の記事を追っかけてみた。

　というわけで早速。

親子丼的ビジネス奮闘記（４）IT業界構造（2007年09月19日 09:45 mark-wada blog）

　たぶんこれが元記事。日米比較対比的な視点からIT業界構造の問題点に言及している。解決策の1つとして BPM on SOA を提案。

　see also:「ビジネスから考えてこそSOAの意味がある」、IBMと豆蔵の両エバンジェリストが強調（2007年9月14日 ITPro）

　[コメント]
　恥ずかしながらSOAというものを、最近になってやっと「聞き流しではなく、しっかり見聞」するようになりました。
　確かにマクロな流れとしては、SOAというのは、あるべき方向なんでしょうね。
　ただ個人的な印象として、わりと今までキーワードバブルになっていた感もあるので、ユーザ企業に「またSI屋に騙された！」みたいな感覚をいかに抱かせないか、がポイントである気がする。
　SOA化自体が目的にならないように、手段としてのメリットデメリットや、今までの手法との違い、をちゃんとユーザに分かる言葉で説明する必要があると思いました。

>[会社組織][SIer]アメリカにはSIerなんて存在しない（2007年9月20日 01:37 GoTheDistance）

　一連の議論の、実質的なルート記事がこちら。
　アメリカにSIerが存在しないという話から、なぜSIerなんてものができたのか、SIerというのは、いわば奇形児のような存在ではないか、という話。

　see also:第81回 コストDownと売上Up－情報システムにおける負の因果律（株式会社クラステクノロジー 代表取締役 四倉幹夫氏コラム）
　see also:そんなに甘くない（2007年8月31日 22:22 秋の気配のはぶにっき）

　[コメント]
　ご本人ブクマ数に驚いておられるようですが、きっとタイトルの妙があったんでしょうね。断定的なタイトルとは裏腹に内容は示唆的かつ発散的で、いろいろと考えさせられる内容なのですが、そのタイトルとのギャップが尚更、他者をインスパイアさせたのでしょうきっと。ブクマを呼ぶ、ひとつのパターンなのかな。

>>平和な日本の平和じゃないSI業界の話（2007年9月20日 寝ても覚めても技術屋）

　そもそもSIerがない米国で生まれ育った考え方をそのまま日本に持ち込んでも、うまくいかない。日本に合ったモデルを考えるか、業界構造自体を変えるか、しかないよ、という話。さらに後半はΣの話など。

　see also:海外と日本は違う．違うなら違うでやるべきことがあるハズ（2007年9月9日 寝ても覚めても技術屋）
　see also:デスマーチ撲滅への「飛躍」なるか–大手SI事業者、外部設計書の記述を標準化（2007年09月19日 21:06 ZDNet Japan）
　see also:プロジェクト×(ペケ) －失敗者たち－「Σ(シグマ)計画」（2001年2月26日）

　[コメント]
　Σの話は私も先輩から聞かされました。もしかすると、現代における構造的問題は、過去のΣみたいに「分かりやすい失敗事例」というか「みんなが叩きやすい、議論の叩き台としての大々的な砲撃目標」がない分、責任も問題もぼやけがちで、たちが悪いのかも知れません。

>>日本のSIerが育んできたもの（2007年9月21日 0:58 眠る開発屋blog）

　SIerがマーケティングまで完遂させ成功したソリューションが思いつかないなあ、という話。それに絡んで、優秀さってなんだろう？という問題提起。

　see also:優秀さの定義を言い換えてみる（2007年8月5日）
　see also：優秀さの定義。（2007年8月4日 もち肌ビジネスマン奮闘記）

　[コメント]
　SIerって根本的に受身でやってきたから、世の中に向かって提案する、なんてことは急にやろうとしてもできないのでしょうね。解決策としては、世の中へ直接提案してビジネスを発掘している会社に、社員を送り込んで勉強させるとか、どうでしょうかね。意識改革するには、意識改革しなければ話が通じない世界に飛び込むのが唯一の方法のように思えます。
　なお、記事中で紹介されている「優秀さの定義」という記事は、秀逸です。（厳密には、そのさらに元記事が秀逸なのであるが）

>>[雑記]脊髄反射で書く小ネタの数々（2007年9月21日 キングフラダンスの恍惚と快楽。）

　米国ではSIerの代わりに会計系コンサルティングファームがシステム構築を請け負ってたよ、という話。

>>[SIer]SIerという奇形児と、SIという珠玉の仕事（2007年9月21日 GoTheDistance）

　前出の「[会社組織][SIer]アメリカにはSIerなんて存在しない」の補足というか続き。システム開発におけるディフェンシブ／オフェンシブの話。SIerの生きる道。

　see also:[SIer]ディフェンシブな開発 ～ SIビジネスの致命的欠陥 2006年1月16日 kuranukiの日記）
　see also:[仕事]SIって最高の仕事ですよ 2007年6月20日 秋の気配のはぶにっき）
　see also:情報サービス産業に明日がなくても構わない 2007年5月13日 雑種路線でいこう）

　[コメント]
　ディフェンシブ／オフェンシブの境界は、システム規模や開発体制（下請け段数の少なさ）にもよると思いますが、同時に世代間論争である気もします。要するに、新たなビジネス環境、新たな開発手法、にたいして、物事の決定権を持つ「エライ人（≒大体おじさん）」がどれだけ理解を示すか、みたいな。
　また、SIは最高の仕事だ、というのは同意ですが、それはつまり、やりようによっては「最高に難しい」仕事であるということで、最高に難しい仕事なのに、最高に頑張った人の対価が最高でないところが、結局は歪みの一因なのでしょう。誰だ、ピンハネしているやつは。

>>親子丼的ビジネス奮闘記（６）（2007年09月22日 11:06 mark-wada blog）

　「[会社組織][SIer]アメリカにはSIerなんて存在しない」へ返信しつつ、自らの記事「親子丼的ビジネス奮闘記（４）IT業界構造」を補足。さらに、ITゼネコンピラミッドを解体してある領域に強みを発揮する専門会社群を形成し、それをネットワーク化して、適宜組合せを変えながらビジネスを展開することを提唱。

　[コメント]
　同感です。私がある程度の規模のシステム開発会社を経営できたとしたら、強みに特化したいくつかの会社へ分化させていって、連合体を作ることを模索すると思います。
　それ以前に、最近、私はそのような会社の経営者を目指す道からドロップアウトしてしまいましたが。

>>>[医療IT]ITベンダーSEとしての「電子カルテ」のあり方　２　～「SIerという奇形児と、SIという珠玉の仕事」に関して（2007年9月22日 アイム　ア　ビジネスマン）

　医療ITに関して、ディフェンシブな開発に向かってしまう要素を考察。そして医療ITベンダーの取るべき道を模索。

　[コメント]
　私の経験上、1つ1つの案件が小さく、かつユーザの運用ルールに合わせざるを得ない風潮で、N件のSIをこなしても儲からないという問題は、医療の世界のみならず、共通した問題だと思われます。

>>>SIerも変革を迫られている（2007年9月22日 流されず逆らわず）

　SIerの今のビジネスモデルは破綻寸前で、このままでは縮小均衡にしかならないという問題提起。

　[コメント]
　ちなみに、一度崩壊したら？というのが私の暴論。

>>>どっこいSIerは簡単になくならない（2007年9月22日 雑種路線でいこう）

　既出の議論を背景に、SIerが沢山の問題点を抱えていることは認めるが、少なくとも解雇規制がなくならない限りはSIerはなくならない。また、SIerがいる／いらない、システム開発の丸投げがいい／わるい、といった単純な二元論ではないよ、という話。

　[コメント]
　非常に包括的であり、この問題をマクロ視点で見た場合、もっとも「腑に落ちる」内容です。
　雇用に対する考え方、システムの違いが、この問題の根底にあるポイントの1つだと思ってます。
　よく語られる「モジュール型」と「調整型」の違いみたいなもので、ソフトウェア開発というのは「モジュール型」の仕事の典型なのに、人材や人材を取り巻く仕組みはモジュール型になっていない。
　SIerという、小回りの効かない大型トラックに閉じ込められている「できる技術者」達がトラックから降りて、その人の専門性や能力がもっとも活かせる車に柔軟に乗り換えられる状況を作りだすこと、そうした営みをサポートする「職業別組合」みたいなものを構築していったらいいんじゃないか、なんて論拠のない妄想を抱いています。
　そして、相思相愛ならまた大型トラックに集まるもよし。結果は同じでも、当事者同士が選択したかどうか、選択できるかどうかが重要。

>>>>[システム開発]キンタマをつかむ（2007年9月22日 masayangの日記（ピスト通勤他）

　SIerとユーザ企業は、いままで、半ば意図的に互いの重要部分（＝キンタマ）をつかみ、つかまれ、もたれあってきたので、その構造はそう簡単には変えられんよ、という話。
　本気でインハウス開発を目指すなら、SI屋に任せているシステムを買い取る、くらいの決断が必要なのでは？という問題提起。

　[コメント]
　この構造をつくり出した大元は、国とNTTと電電ファミリーと呼ばれたNFHであり、そしてそれを増幅させたのは、独自の「公共システムブラックボックス化」を編みだしたNTTD、だと思うのが私の歴史観。
　長い間ソフトウェアはハードウェアの付属物でしかないという認識が、ソフトウェアに対する理解不足を生み、市場の進化を遅らせてしまったのではないか。最終的にはそうした経緯を経てきた古い世代が表舞台からいなくなるころに、変わるかもな、と。その時まで日本市場の主導権が日本企業に残っていれば、の話だけど。

>>>>それなりの人がいればいいのかな（2007年9月23日 1:23 眠る開発屋blog）

　「それなりにイマドキのトレンドを理解して、それなりにコードも書ける人」がユーザ企業にいれば十分という状態になっていくのではないだろうか」

　[コメント]
　個人レベルの視点で見た場合、同感できて、そうしていきたいと思う内容です。
　ユーザ企業はITのこと（とくにPMとか要求定義とか）を勉強しなさすぎだし、SIerを頂点とするシステム屋は、同じくユーザ企業の仕事を勉強せず、自分たちの手の内を隠して自分たちの殻に引きこもりすぎ。
　そして、どっちが歩み寄るか、それはシステム屋である程度マネジメントレベルまで学んだ技術者が歩み寄るほうが、自分には自然に見える。

◆◆◆

2007年9月28日 追記。「カレーなる辛口Javaな転職日記」さんリンクありがとうございます。

>>>>>[SIer][システム開発]技術的老化というSIerの持病（2007年9月25日 GoTheDistance）

　各エントリへの返信。「ダメエンジニアをかき集めて仕事を進めるスキーム」をどう変えるのかという議論を見据えつつ、SIerの人材マネジメントをどう考えるのか？を議論したい。特定領域に強みを発揮する専門会社群っていうのは総合病院のようなものが出来るイメージだなって話。
　そして後半は本議論とは少し別の話だが、この業界が抱えるもうひとつの構造的問題「人月とExcelとスーツで出来たオヤジ」との世代間闘争の話。（というか階級間闘争か？）

　[コメント]
　良い意味で白熱してまいりました。良い技術者と悪い技術者を統一的且つ網羅的に判断できるクライテリアは確かに必要だと思います。でも仰るようにこの業界の親父さん達はITSS!コールをしだすんだろうなっていう予想は同感。
　私的には、もう少し地に足ついた属性情報・・・つまり言語ごとの習得レベルとか、設計技法（DOAやOOAなどの考え方、UMLなどの表記技法や、テストの技法、etc…）とか、EclipseやTracなどのツール操作スキルとか、それぞれで知識レベルや経験レベルを整理できると、いい感じな気がするんですよね。そういう意味では、最近ではRubyなんかも技術者認定制度を始めるみたいだし。まあ資格オタクみたいな人もいて、やたら資格もってるけど実戦は・・・みたいなこともありましたが。

>>>>>>なんか誤解されてるな（2007年9月26日 雑種路線でいこう）

　「[SIer][システム開発]技術的老化というSIerの持病」への返信。

ポイントは駄目なエンジニアを切れないことが問題なのではなくて、ユーザー企業が必要とする技術は変わるのに、そこで機動的に技術者を入れ替えられないことが問題なんだけどな。
なんか誤解されてるな（2007年9月26日 雑種路線でいこう）

　[コメント]
　ITSSは、自分が前にいた会社の場合「いままでの、つぎはぎを重ね老朽化した制度に変わる救世主として」採用を検討したために、頓挫しました。だからといって、あるべき論から入れば導入できるのかっていうとそうでもないような気がします。結局、資格を軸にした制度ってのが分かりやすいのかなあって気がしました晩年は。その際に資格オタクの問題と陳腐化の問題が出てきますが、前者はキャリア制度と組み合わせて、あまり関係ない資格を取得しまくらないような足枷を設けたり、後者の陳腐化っていうところは、必要性が薄まっていきそうな技術に関しては、重み比率をわざと経年劣化させていくことで自発的なスキル移転を促すっていう・・・書いてて妄想レベルになってきたのでこの辺で。

>>>>>[雑記]SIerにキンタマつかまれてるユーザー企業はSIerと心中するしかないね（2007年9月22日 ザキンコの日記）

　どっちにしろモラルのないSIerに未来はないけど、社員を使い捨てにして自分達の退職金だけはせしめようってお偉方が居るSIerには気をつけろっていう話。

　[コメント]
　逃げきり世代に逃げきられないためにはどうすれば良いんでしょうね？
　なんだか　「丸山眞男」をひっぱたきたい　をふと思い起こしてしまいました。

>>>>>[システム開発]SI屋と顧客の未来（2007年9月23日 masayangの日記（ピスト通勤他）

　利益追求を求められる会社組織としてみれば、キンタマつかんだSI屋ってのは、実は「モラルのある」行動をとってきた。そのワケは・・・って話。それで、予想されるシナリオを披露。

　[コメント]
　私もシナリオ１→シナリオ２が濃厚な気がします。でも既存の制約に縛られない会社が絶対勃興してくるはず。それがつまり外資なのかも知れないけど。日本人ってもしかしてDNAレベルでパラダイス鎖国と出遅れスタートが大好き民族？

>>>>>>[システム開発][Agile開発][どうでも良いこと]どーしたらいいんだろうね（2007年9月25日 masayangの日記（ピスト通勤他）

　「[SIer][システム開発]技術的老化というSIerの持病」への返信。

　[コメント]
　ウォーターフォールモデル自体が既に破綻してますよね近年は。でも決裁するオヤジがそれしか分かんないから、当面は無理矢理ウォーターフォールをあてはめて破綻するか、周囲の理解やサポートなしでアジャイルを適用しようとして習熟不足で破綻するか。たしかに詰んでますな。
　こうしたblogに書きなぐっているだけだと打開できないのは同感ですが、こうして整理しとくことで少しでもオヤジ抵抗力がUPすればそれはそれで。

◆◆◆

　最後に、下記は、手前味噌だが自分自身の、過去の戯言。
　上記の猛者達が書いた内容と比べると、我ながら、局所論的というか独りよがり感は否めないけど、根底の問題意識は同じだと思っている。

関連記事１：たしかに本当の大変化はこれから始まるのかもしれない。でもその前に大崩壊が
関連記事２：重層下請け構造のなかから見た、周囲の変化と不変化
関連記事３：いっそ壊滅してみる？

ookawara.com 記事に反応！ SIer

　空き時間で（要は仕事サボって）、写真展「鈴木理策：熊野、雪、桜」を鑑賞しました。

東京都写真美術館では、これまで重点収集作家個展、新進作家グループ展を開催していましたが、国際的に活躍する日本の中堅作家の作品表現を積極的に紹介する機会を設けることとなり、 その第１回目の作家展として卒業生で、講師でもある鈴木理策さんの展覧会が開催されます。

東京都写真美術館

■会　期：9月1日(土)→10月21日(日)
■休館日：毎週月曜日（休館日が祝日・振替休日の場合はその翌日）
※ただし10/1は都民の日で臨時開館します(観覧無料)
■会　場：2階展示室
■料　金：一般 700(560)円／学生 600(480)円／中高生・65歳以上 500(400)円
※（　）は20名以上の団体および東京都写真美術館友の会会員
※小学生以下および障害者手帳をお持ちの方とその介護者は無料
※第3水曜日は65歳以上無料

東京都写真美術館　鈴木理策：熊野、雪、桜

　熊野：すばらしい。特に白い空に浮かび上がる木々に、非現実的な美を感じる。あと夜の火を使った祭りの情景もいい。夜の炎をなんであんな風に撮れるんだろう？
　雪：新作らしい。個人的には好みじゃないけど「真っ白」とか、斬新ではある。展示室も真っ白。一瞬、マトリックスのネオになった気分になる。
　桜：繊細。これは海外でウケるでしょうね。少ししか展示がないのが残念。

　全体的に、ちょっと展示数が少ないのが残念だけど、いいもんみせてもらいました。

　鑑賞しに来ている人たちに、若い人（自分も若い！つもり）が多かった。鈴木理策さん自身もお若いからかも知れないけど、我々30代以下がこうしたものを積極的に鑑賞していくことは、よいことだと思う。

ookawara.com 未分類

　優秀な人を採用でき、育成できる組織は「シグニチャー・エクスペリエンス」を提供している事に注力しているという事がまとめてありました。人は給料や、福利厚生だけを求めているわけではない。「シグニチャー・エクスペリエンス」という、その職場で働くことでしか得られない経験、職務経験を人は求めているということです。

誰もが理想と感じる職場など作れない!「自分の仕事に対する考え方」にマッチした職場を選ぶことの重要性（2007年9月18日 モチベーションは楽しさ創造から）

　逆にリーダーの立場であれば、自分の職場の「シグニチャー・エクスペリエンス」は何なのかを鮮明に打ち出していくことが求められるという事ではないでしょうか？万人受けがする、全ての人に心地よい職場は作れません。しかし、「○○のようなタイプの人には理想の職場」であれば作れると思うのです。そのような人達に満足してもらう為の、「シグニチャー・エクスペリエンス」を提供し続けていくことがリーダーには求められるのでしょう。気持ちよい職場を作ろうとすれば、自分の組織の「シグニチャー・エクスペリエンス」に共感できる人達を採用していく事も重要になってくるでしょう。

誰もが理想と感じる職場など作れない!「自分の仕事に対する考え方」にマッチした職場を選ぶことの重要性（2007年9月18日 モチベーションは楽しさ創造から）

　同感。耳がイタイ。自分が前の職場でそれをつくり出すべき立場でありながら、できないどころか、自分が飛び出してしまっただけに。

　ちょっと観点がずれるけど、経験上、「特定の人そのもの」が「シグニチャー・エクスペリエンス」になっていることが多かったようにも思う。

　いわゆる一流の会社は違うのかもしれないけど、自分の周りには、「自分の信念」とか「自分のライフプラン」とか、確固たる考えを持っている人ばっかりではなくて、なんとなく「こんなことしたいけど、何から手をつけてよいか皆目分からんなあ」とか「はたして自分は何をしたいのだろうか」なんて人たちも沢山いた。いやむしろそういう人のほうが多い。

　そういう環境下で、何が人を会社につなぎ止めるか、「あの人は自分のやりたい方向性に導いてくれそうだ」とか「あの人がやっていることがまさに自分がやりたかったことなのだ」とか「あの人と一緒に仕事ができるなら、今後もいい仕事ができそうだ」とか「あの人からまだいろんなことを学び取りたい！」みたいなことなのかなあと。

　もちろん、先にあげた「ぼんやりとした自己意識しか持たない人たち」をつなぎ止めることにどれだけのメリットがあるか、それは不明だが、特定の人がロールモデルとなることによって、ぼんやりとした潜在意識が開眼して、以前よりも増してチームに貢献できる人材に成長することも、なくはないと思う。（ぶら下がり体質が顕著になる逆のリスクもあるけど）

　実際、入社したときは「彼はスキルアップの速度も意識も弱くて、どうかなあ」なんて評価を下していた人間を、厳しいけど高い理想を持っている上司につけたら、２年後には見違えている、なんてこともあったし、仕事のできる人間で「今の職場で自分が一緒に仕事をしたいと思う人間がいなくなったら辞める」と公言する人間もいた。

　結局、「リーダー」ってのは部下にとってのロールモデルを提供し、部下の成長の触媒とならなきゃイカンな、と自戒する次第。

　きっと、特に学生段階では「おれの仕事に対する考え方！」みたいなものを持っている人もさほど多くないと思うし、持っていたとしても、その殆んどは「心意気は認めるけど、もう少し世の中を広く見てから考え方を固定したほうがいいんじゃないかなあ」と助言したくなるような荒削りなものが殆んどだ。（実際、自分自身もそうだった）

　よって、学生に補足するとしたら、入社したら、すぐに周囲の人たちを観察し、仕事や雑談を通じて、その人たちの考え方を聞いてみると、いいですよ。その際はやっぱり、オフラインコミュニケーションも大事な気がします。

　なんだ結局飲み会賛美論じゃないか。元記事とは関連の薄い内容になって、すんません！

ookawara.com 未分類

ookawara@lx1:~$ cat a.pl
$s = "ABC";
$s =~ s/A//;
print "Match=$&\n";
$s = "BBC";
$s =~ s/A//;
print "Match=$&\n";
ookawara@lx1:~$ perl -f ./a.pl
Match=A
Match=Aそうなんだ・・・

ookawara.com Perl

貼り付けテスト。

ookawara.com 未分類

LPO（Landing Page Optimization）

LPOの定義

　LPO（Landing Page Optimization）とは、ユーザーが最初に着地するページ（ランディングページ）を最適化することによって、目的のページへの誘導を容易にし、途中離脱などの無駄を抑えてコンバージョン率を高めるという考え方、または施策のことを指します。

「LPO（ランディングページ最適化）について」 – (((SEM-ch)))－検索エンジンマーケティング情報チャンネル

　PC ではサイト訪問者の興味を引くコンテンツが無い場合、8秒で40～60％が直帰する（SEM 総合研究所調査結果）が、モバイルでは5～6秒が限界で、7秒で読み込みが遅い（※3）と感じ始める。PC よりも時間の感じ方が多少短いようだ。

　7秒までに読み込まれるページサイズを平均（※3）すると、約20k 以下がモバイル LPO では最適なサイズとなる。

　この体感速度の差には、PC ユーザーとモバイルユーザーのシチュエーションの差が一因として考えられる。

　モバイルユーザーが最も検索行動を行うシチュエーションは、「通勤通学時・就寝前・起床後・夜間・待ち合わせ時・外出先・旅行先」（※3）など、通常の生活時間の合間であり、休息時間などの10分20分の間に見ている傾向が見られる。

　このシチュエーションの中で短時間に訴求を刺せるかどうかが、モバイル LPO の構成の要となる。PC 版の LPO においても、訴求の絞込みはクリティカルな問題であるが、モバイル LPO では文字数制限（PDC 8文字 W-CDMA 10～12文字など）や、画面サイズが横幅平均約 240pix と小さい事もあり、ファーストビューに盛り込む訴求については、より慎重に精査する必要がある。

「モバイルランディングページ最適化（モバイル LPO）の実力」 – 2007年9月11日 Japan.internet.com コラム/アイレップのSEMフロンティア

• むかーし携帯系のサービスで導線解析やったなー。そのときは決済手段がクレジットカードだったために、クレジットカード番号を入力させる画面があったんだけど、ことごとく、もう面白いくらいにそこで跳ね返されているという、まあ予想できる話ですが。いま思えば単に「クレジットカード番号だから仕方ない」というよりは、画面遷移のテンポとかそういうLPO的な考え方で導線を見直せば少しはマシだったかも知れないけど、LPOという言葉は知らなかったし。
• PCだとタブブラウザだし、画面もでかくてマルチウィンドウだからってのが待ち時間ストレスを感じさせない一助になっていると思う。トロいページだ！と思うと他のことしながら待ったりできるから。そのまま元のページに戻らないケースもあるけど・・・携帯の場合、ページロード中に何もできないってのがイタイ。ロード中画面をいろいろカスタマイズできたら少しはいいかもね。
• 携帯電話も、新機能よりもページロードを完全にマルチスレッド化するとか、CPUやI/O性能を高めるとか、電池の持ちを良くするとか、そういう基本性能を頑張ってほしい気がする。

ookawara.com ことのは