メイン

「システム開発」のアーカイブ

2008年2月12日

システム開発版ビフォー・アフター

全力でプログラマーを「人気の職業」に押し上げたい - Attribute=51

  • 顔や名前を出してもいいと思う人は、もっと出したらいいと思う。ハンドルネームでもいい。開発ブログと作ったアプリをリンクさせる。※これは結構やってる人がいる!ステキだ! でも足りない気もする。あと一押し欲しい。
  • Webサイトを立ち上げたら、「このサイトを作った人」というページを1枚作るべき。オレが知りたい。

システム開発って建築によく例えられるけど、有名建築士が設計した建物とかは書籍にまとめられたりするのに、システム開発者はそういうのがないわけですよ。

せめて、システム開発版「ビフォー・アフター」があっても良いじゃないかとか思ったりして。

Case.1 問題だらけのシステム

依頼人(以下、依) 「サイトのアクセス数が増えてきたのでそろそろサイトを作り替えようと思いまして」

匠 「なるほど。どういうサイトに作り替えたいかというイメージはありますか?」

依 「ぱっと、サイトを訪れた人が明るくなるような、夢のあるサイトにしたいです」

匠 「分かりました。やってみましょう」

ナレーション(以下、ナ) 「匠は、早速ソースコードを見てみることにしました」

匠 「これは・・・酷いな・・・」

ナ 「そこで匠が見たものは、バージョン管理されずただWindowsの共有フォルダに入れられているだけのソースコードでした」

匠 「・・・Subversionを導入しましょう」

ナ 「匠が取り寄せたのは、昨今バージョン管理ソフトウェアとして注目を浴びているSubversionでした」

匠 「よし。これでバージョン管理はOKだな」

ナ 「一安心してソースコードを眺める匠。しかし、そこにも大きな問題が」

匠 「これは・・・セキュリティ対策が全然なされてない・・・」

ナ 「なんということでしょう。今動いているシステムは、セキュリティ対策がまったく施されていなかったのです」

匠 「Aさん、ちょっとこれ、見てよ。ここの入力フォームに、こうやって入力して、送信すると・・・」

依 「あ!」

ナ 「Aさんの目の前に現れたのは、画面いっぱいの顧客情報でした」

匠 「これまでにハッキングされていないかどうか、チェックする必要がありますね・・・」

(中略)

ナ 「完成後、初めてサイトを訪れるAさん」

依 「どきどきしますね(と、画面をクリック)。おお!」

ナ 「Aさんの目の前に広がったのは、画面一面に広がった白。その真ん中に、ぽつんとたたずむ一組の入力フォーム。日本人のわびさびを表現した匠の傑作デザインです」

依 「いやー、シンプルで美しいですねー」

ナ 「ログインすると、一転、そこには極彩色の楽しげな商品一覧画面が広がります。Ajaxを駆使して動的で広がりのある一覧画面を表現しました。Ajaxで利用されているフレームワークは、匠の特注品です」

依 「楽しいですねー」

ナ 「時が経つのを忘れて夢中で一覧画面を眺めるAさん。今回のリニューアルには満足していただけたようです」

依 「ほんと、匠にお願いして良かったです」

 

こんな感じ。

 

システム自体のビフォー・アフターじゃなくても、開発現場そのものに対してのビフォー・アフターでもおもしろいかも。

Case.2 どんよりした開発現場

依 「ほんと、困ってるんです」

ナ 「今回の依頼者は、開発現場が暗くどんよりしていて、開発効率が上がらないと言うBさん」

匠 「分かりました。お任せください」

ナ 「早速開発現場に向かう匠」

匠 「これは・・・酷いな・・・」

ナ 「そこで匠が見たものは、目がどんよりと曇り、数日間入浴したようすもなく、黙々とモニタに向かってキーボードを打ち続ける開発者の姿でした」

匠 「まずは、これを使いましょう」

ナ 「匠が取り出したのは、カレンダーと赤・青・黄のシールでした。これを一体何に使うのでしょう」

匠 「気分が良い日には青、普通の日は黄、悪い日には赤のシールを貼って帰ってください」

ナ 「なんということでしょう。匠はカレンダーにシールを貼ることで、開発者の気持ちを可視化することに成功したのです」

(中略)

ナ 「改善後、初めて開発現場を訪れるBさん」

依 「緊張しますね(ガチャ、とドアを開ける)。おお!」

ナ 「扉を開けたBさんが見たものは、ミーティングスペースで立ち朝ミーティングを開いている開発者達でした。どの開発者も皆すっきりした顔をしています」

開1 「じゃあ、このタスクを○さん、このタスクを×さん」

ナ 「モニタに映し出されたプロジェクト管理ツールのタスクを適切に割り振る開発リーダー」

開2 「了解。ぱぱーっと終わらせて、今日はさくっと飲みにいっちゃいますか」

開3 「おー、いーねー」

ナ 「なんと開発者達はタスクを適切に割り振り、定時に帰ることができるようになっていました。定時後にはみnなで飲みに行ける余裕まであります」

依 「ここまで、変わるものなんですね」

ナ 「こうしてまた、匠によって不毛な開発現場が一つ救われたのでした」

 

なんか自分で書いていて見てみたくなったよ。

2008年2月11日

関係者多数の開発でのソースコード管理とか情報共有とか

デザイナが作成したHTMLファイルを、JSPなりrhtmlなりにプログラマが変換して、いざ画面を表示してみたらデザインが崩れてしまった、というのは昔からよくある話。

これに加えて、デザインFIXのタイミングがプログラミング開始の後になってしまうとか、デザインFIX後も何らかの問題が生じてデザイン変更をお願いするも、デザイナがオリジナルのHTMLファイルを編集するから、変更点の反映が大変だとか、まあそんなこともよく言われてます。

そういうのを受けて、JavaならTapestryとかWicketとか、テンプレートが.htmlという拡張子で終わるから、デザイナがオリジナルのファイルを普段使っているツールで開けるみたいなフレームワークが登場してきました(もちろんそれだけがうりじゃないですが)。

先日、Wicket-jaの矢野さんにちょっと話を聞いたときは、Wicketは、イテレートでぐるぐる回すようなところも、デザイナが書いてきた部分は「サンプル」的な扱いにできて、そのまま残しておいても、Wicketのフレームワークと通してページ出力されるときは、その部分は無視されるとかできるそうで。

それを聞いたときは「おー、便利便利!」とか思ったわけです。

でもその便利さを、僕らSIerの開発の中で活かすためには、超えなきゃいけない壁が2つほどあります。

1つは、デザイナさんにもバージョン管理システムを使ってもらうということ。

いくらHTMLのテンプレートを直接利用できても、

開発者「すみません、デザインのここを直して欲しいのですが」

デザイナ「はーい。じゃあ、メールで送っておいてください」

だと、結局修正後のファイルをいちいちdiffとって比較したりしなきゃいけないし、地味に面倒な作業になっちゃいます。

こんなとき、デザイナさんが、

「じゃあ、リポジトリからチェックアウトして修正しておきます」

なんて言ってくれたら良いのにと。

で、もう1つは、上にも関連する話ですが、ソース管理リポジトリをインターネットに公開できないかなぁと。

まあ、インターネットに公開といっても、https通信、ID/Password認証、WebサーバでのIP制限等々セキュリティは万全にしてのことなのですが。

SIerで大規模開発となると、結構パートナーさんに一括で持ち帰ってもらうというケースが最近増えてきてるんですよね。その方が、元請け的にも偽装請負の問題とかクリアになるし、パートナーさん的にも一括受託の方が利幅を多く取る余地ができて、お互いにメリットがあったりするわけです。とはいえ、そんなメリットがあっても、システム開発自体がうまく行かなければまったく意味がないわけで。

個人的には、Redmineみたいなプロジェクト管理ツールやSVNを先に書いたように、セキュリティを万全にしてインターネットに公開して、そこを通じてパートナーさんとかデザイナさん、顧客等々と情報共有ができたらなぁと思っているわけです。

プロジェクトの中で、意外と時間を取られるのが、MTGの準備だったりするわけで。いちいち、資料を「綺麗に」整えたり、紙を人数分印刷してホッチキス止めしたり、MTG資料を何度も印刷→レビュー→修正したり。この辺の作業が簡略化されて、MTGのときにはredmineのレポートの画面を見るとかしたら、良いのになぁと。

もしかすると、他の会社だったらこういうこと普通にやられているのかもしれないですね。

2007年12月25日

Think IT 連載第4回「バグ管理で陥りやすいワナ」公開

Think IT で連載している「バグ管理のノウハウ」の第4回が公開されました。

第4回:バグ管理で陥りやすいワナ

今回の内容は、バグ管理で陥りやすいシチュエーションについて書いています。

書いていることは、結構あちこちの現場で起きていることだと思うんですが、どうでしょうか。

メール、コメント等でフィードバックいただけると嬉しいです。

【バグ管理の作法】バグ管理のノウハウ
第1回:バグはなくならない?
第2回:紙か? Wordか? Excelか? BTSか?
第3回:バグの優先順位はこう付けろ!
第4回:バグ管理で陥りやすいワナ
※第2回目以降が僕の担当です。


普段、「プロジェクト管理」「テスト管理」という切り口で考えることはありましたが、「バグ管理」という切り口で考えることはなかったので、良い経験になりました。

2007年12月16日

国内SIベンダーの強みを力説?

今度は住商情報システムさんですか。

【IT Service Forum 2007】「摺り合わせ文化など日本には日本の良さがある」,国内SIベンダーの強みを力説:ITpro
Matzにっき(2007-12-10)

講演後半の日経BP社田中克己主任編集委員との対談では,「システム開発において日本のSIベンダーはインドのSEと戦えるのか」という問いに対して「(顧客企業の業務ノウハウに強いなど)日本独自の世界でなら,日本がインドに負けるわけがない」と断言。「シリコン・バレーと同じことをしていたら,日本は他国に勝てるわけがない。逆に,日本独自の世界でなら,他国に負けるわけがない」とした。

ほんと? 本当にそう思ってます?

「日本独自の世界でなら」って前提が、そもそもおかしくないっすか?逆に言うと、「日本独自の世界じゃなくなったら、日本がインドや他国に負けることもあり得る」って言ってるわけで。昨今の問題はその日本的な世界がなくなるんじゃないの?ってところに焦点があるんじゃないかなぁ。

あと、SIer とかは「オフショア」言うて、他国のSEやプログラマに日本の仕事をやらせようとしてるわけで。なんかそういうことすることで、自ら墓穴を掘っていることに気が付かないのかなぁ。

2007年12月11日

thinkITでバグ管理についての連載始まりました。

thinkITの今月の特集が「バグ管理の作法」なんですが、その中の「バグ管理のノウハウ」というコーナーで連載することになりました。

全4回で、僕の担当は第2回~第4回。

本日、第2回が公開されました。

[Think IT] 第2回:紙か? Wordか? Excelか? BTSか?

バグ管理の基本のキについて書いたつもりです。

第3回では、バグ修正の優先順位の付け方について、第4回では、実際に遭遇したバグについて書くことになっています。

メール、コメント等でフィードバックいただけると嬉しいです。

文体が「だ・である調」なのは、第1回目がこの文体で書かれており、それに合わせる形となったためです。なんかキャラと合ってませんが、そこはスルーしてください。

2007年12月 3日

Re:「ワード・エクセルできます!」

はてな増田より。

「ワード・エクセルできます!」

  1. セルの中で改行(スペースを大量に入れて調節するの禁止)
  2. 電話番号みたいに、0ではじまる数字を表示(頭に'付けるの禁止)
  3. 入力すべきセルに最初に色を付けておいて、何らかの数値が入ったらセルを白くする。値を検証して、矛盾するようなら赤くするとなおよし。
  4. A1に「=10/3」、B1に「=10/3」と入力されていて、C1に「=A1+B1」と入力されていたとき、C1に「7」と表示されても「あれ?」とか言わない。
  5. すでにできあがったシートがあるとき、「このシートでC列の値が最も高いもの」を探す方法が分かる。

はてぶとか見てたら3が出来ない人結構いるみたいですね。

僕なら「条件付き書式」使います。

Excel で タスク管理シートを作る (でぃべろっぱーず・さいど)」とか「Excel でスケジュール管理 (でぃべろっぱーず・さいど)」で公開しているExcelは、この条件付き書式を使ってます。

Excelってほんと不思議で、ctrl + C / X / P / Y とか使ってないひとが、複雑な関数でマニアックな業務処理の計算をしてたりするんですよね。その人の中ではそれが常識になっているから、普段の所作を見て、「この人Excel使えないんだろうなー」とか思って会話してると痛い目にあうことも。

ちょっと複雑な計算とかになってきたら、Excelで関数やマクロ使うより、DBに入れてプログラムで処理した方が早いんじゃないかとか思ったり。

2007年12月 1日

SIerはもっとオープンソースに関わるべきだ

NTTデータが自社のフレームワークをオープンソース化しました。

NTTデータ、Javaや.NETのフレームワークをOSS化:ITpro

NTTデータってSIerの業界(敢えてIT業界とは言いませんが)の中では、やっぱり巨人で、売上金額とか従業員数とか群を抜いているわけです。でまあ、お役所仕事的なところもあるのかなぁとか思っていたんですが、最近の流れにのってこういう手を打ってくるところはすごいなぁと素直に感心しちゃいます。

普通のSIerならこういう「自社ノウハウ」的なものって外部に公開したがらないものなんですけどね。

SIerも、もっとオープンソースコミュニティに積極的に参加していくべきですよね。

strutsとか使って、自前のフレームワークを作っているところはたくさんあると思うんですけど、そういう閉じられたところにある技術って、外の空気に触れることでもっと良くなったりする可能性はあるわけで。

国産ベンダが目覚める前にエンジニアの空洞化が始まる - @IT

そのうえで、山野井氏は、優秀なエンジニアを日本につなぎとめるには「プロフェッショナルな人材の流動性を高める仕掛けが必要」と話した。優秀なエンジニアを正しく評価し、給与で優遇し、高い生産性を維持して働ける職場環境を用意することがポイント。エンジニアのコミュニティの中でその企業の評判が高まれば、優秀なエンジニアが集まり、面白いサービスが生まれる。エンジニアを単なる作業者と考える企業からは人材が流出するだろう。このエンジニアの自由な移動を実現するには流動性を高める仕掛けが必要というのだ。

SIerが本気を出して、すげーおもしろい/良いフレームワークとかをオープンソースに提供しだしたら、そういうことをしている会社ってエンジニアにとって魅力的に見えると思うんだけどなぁ。

SIerじゃないけど、Google には広告収入で得た利益を、オープンソースにどんどん還元していこうって雰囲気があるようだし(現にいくつもオープンソースプロダクトを発表してるし)、楽天も今後そういう風に動いていきたいと、この間のテクノロジーカンファレンスで言ってたし。

まあ、3Kだなんだと言われている職場で、どこにオープンソースと関わる時間があるんだよと言われると、「スケジュール管理の問題」だから自分でなんとかして、としか言えないんだけどね。

2007年11月 2日

"社内"を捨てOSSへ

Seaserの比嘉さんが情報処理推進機構(IPA)のイベント「IPAフォーラム2007」の中で行った「開発を夢のある仕事にするには」という講演の内容。

上司に認めてもらえないエンジニアは“社内”を捨てOSSで行こう - ZDNet Japan

自分で開発したアプリケーションサーバがネットで動いているのを見た感動した同氏は、会社の中でフレームワークを開発するようになり、会社の中で使ってもらうようにしている。しかし、開発したフレームワークに対する社内からの「反応がなかった。みんな意見は持っていたとは思うが、正面切って“こうした方がいい、こういう機能があればいい”と言われることがなかった」と寂しいものだったようだ。

ひがさんと比べるのは恐縮ですが、この気持ち、超分かります。

"社内"を捨てると言っても、会社を辞めるわけではないというところがポイントかな。

会社の仕事をちゃんとした上で、そういう対外的な活動をすることで、会社にとっても自分にとってもメリットがある形が一番良い気がします。


「エンジニアが自分の活動を認めてもらうには、社内に閉じこもっていては意味がない。社外で自分の存在価値を認めてもらうと、会社の中で働くことにも、“助け”となる」


まさしく、これですね。


まあ、この話、逆から見ると、社内の優秀な技術者の優秀な技術を社外へ出さず、自分の会社で囲い込みたいのであれば、その技術者が納得するだけの待遇を用意しろってことで。

2007年11月 1日

業界の重鎮が語るIT業界不人気の理由

IT業界不人気の理由は? 現役学生が語るそのネガティブイメージ - @IT

IT業界の重鎮とは、自身ではメインフレーム開発しか行ったことがないというNTTデータ 取締役相談役で、情報サービス産業協会 会長の浜口友一氏と、TISの代表取締役社長 岡本晋氏だ。加えてIPA理事長の藤原武平太氏が答えた。


さりげに自分の会社の社長がいたりする。

学生達の意見は辛辣で、「トヨタ自動車やソニーのようなユーザー企業と違い、IT(の導入)しか行っていないNTTデータのような会社が一番謎」とか、「(情報を発信するテクノロジなのに)IT業界が何をしているのか分からないのは問題」とか。


ネガティブイメージを突きつけられた浜口氏は、「必ずしも全員が3Kではない」と反論。

この反論がちょっと笑える。

「必ずしも~でない」ってことは、3Kの人も結構な割合でいるってことでは・・・。

岡本氏も「3Kの“帰れない”は、帰りたくない人が帰れないだけ。スケジュール管理の問題だ。私は40年間近くIT業界で仕事しているが、何が一番幸せかというと退屈している暇がないことだ。技術が進歩するにつれわれわれの仕事も複雑化してくるが、一生懸命追いかけていくだけでも退屈しない。いい仕事を選んだと思う」と自らの仕事を振り返りつつ、学生に反論した。

これは近年まれに見る酷い発言だと思う。↓はてぶでも結構やり玉に挙げられてたし。

はてなブックマーク - IT業界不人気の理由は? 現役学生が語るそのネガティブイメージ - @IT

帰りたくない人が帰れない「だけ」って・・・。

あと、「技術が進歩するにつれわれわれの仕事も複雑化してくる」ってところも疑問。本当にそうですか? 本当に追いかけてますか?


「工程ごとにいろんな呼称があるが、ITコーディネータやITアーキテクトなど、具体的に何をやっているのかさっぱり分からない。横文字だけが並ぶ」と、ITスキル標準をプロモートする重鎮を前に指摘した。

僕も分からん!

いや、分からないことはないけど、そういう呼称があるってだけで、仕事がその通りに分けられるわけでもないし。


だが、学生たちは、コミュニケーション能力とは具体的にどういうことかと首をかしげる。学生の1人は「コミュニケーション能力の重要性は、就職活動をしているとどこの業種でもいわれること。だが、例えば、ドキュメント化能力のようにIT業界に限って必要な能力とは具体的に何か」と質問した。

SI業界でなく、IT業界であるならば、パソコンが好きなことなんじゃないかと思う。たまに、パソコンは仕事でしか使わない人とかいるけど、そう言う人はこの業界向いてないんじゃないかなぁと密かに思っていたりします。といっても、そう言う人が活躍する場面ももちろんあるんだけど。


Webサイトの記事ってことで、会場の雰囲気ややりとりの細かいニュアンスとか色々抜け落ちているんだろうから、あまりこの記事をもって、IT業界の重鎮達がこんなことを考えてるんだと決めつけない方が良いのかなと。(ここに書いてある発言が嘘でしたと言って欲しいという、願いも込めて)

2007年10月11日

プログラミング工程を軽視するなかれ

Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている

同意する部分多し。

「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月30万円というケースもあるという。

これと似たような話を僕も経験したことがあって、SIerの知人に「僕は社内に実装を請け負う部門なりベンチャー子会社を作りたいです。」みたいなことを言ったら、「やったらいいじゃん。その代わりお前単価30万だぞ」みたいなことを言われたことあります。

正直、はぁって感じでした。もの作りの工程がだいぶ軽視されているなぁと。

「自分でプログラムを書かない上流のエンジニアが詳細設計書を作り、下流のエンジニアがコーディングをする」という工程そのものが、根本的に間違っているとしか思えないのだ。」

やっぱりね、設計する人もプログラムを書けるべきですよ。

上記引用のような構図はどう考えても間違っているし、気持ち悪いです。

2007年9月20日

Excel でスケジュール管理

Excel で タスク管理シートを作る」に引き続きExcel シリーズ第2弾。

Excel のシートでスケジュールを管理してみます。

縦軸にタスク、横軸に日にちを取ったシンプルな作りですが、開始日・終了日を入力すると、前回紹介した「条件付き書式」を利用してスケジュールの線表っぽいものが書けます。


excel_schedule_preview.png


シートは2枚用意してあって、1枚目は予定の線だけですが、2枚目は実績の線も出るようになっています(その分若干もっさりしてますが)。

こんなのはMS-PROJECT のお仕事だよ!という声も聞こえてきそうですが、小規模なプロジェクトならこっちの方がシンプルで簡単に管理できるかと。

↓ダウンロードはこちらから

ファイルをダウンロード

気が向いたらバージョンアップしていきますので、不具合・ご要望ありましたら、よろしくお願いいたします。

2007年9月 7日

情報処理技術者試験がてこ入れ

情報処理技術者試験がてこ入れされるみたいですね。

「初級シスアド」消える――情報処理技術者試験が大改革へ - @IT

会社からは試験受けろと言われているけれど、個人的に資格より優先させたいことがいくつかあるから、ついつい後回しになっちゃうんですよね。

これを機に考えを改めるか。どうしようかな。

新試験は最終決定をした後、平成20年度秋期にまずはエントリ試験を実施する。ただ、CBTではなくペーパー方式で実施。初級システムアドミニストレータ試験は実施しない。そのほかの試験は現行の試験制度で行う。全面的に新試験に移行するのは平成21年度春期からを予定している。

ペーパー試験なのは変わらないんだー。

論文書かせたりするのもよいけれど、鉛筆よりもキーボード使わせて欲しいな。

試験対策で、あらかじめ書くことを決めて、当日は書くだけ、みたいなメソッドが紹介されているけれど、それはそれでどうなんだろ。

2007年9月 5日

アジャイルな環境作り

アジャイルな環境作りについてのプレゼン資料が公開されています。

masuidrive on rails ≫ Blog Archive ≫ アジャイルな環境作り - そんなに急いでどこへ行く


アイデアとコーディングの間に立ちふさがる「テンション」という高い壁は、確かに存在しますね。

何か作ろうと思っても、あれもしなきゃ、これもしなきゃ・・・。確かに面倒です。

格安レンタルサーバはいっぱいあるし、ネットワーク環境も日本は世界一だって話ですから、気軽に色々試している人がもっといても良いと思うんですが、なかなか。

スクリプト組んで、自動でなんでもできるようになるってのは素敵ですね。

やっぱ自由に使えるレンタルサーバがもっと増えて欲しいなぁ。

Perl や PHP だけじゃなく RoRも動いて欲しいし、もっと言えば Java のサーバサイドアプリが動作する環境が欲しいですね。

2007年8月15日

ソフトウェアは無料か有料か

37Signals は、ソフトウェアを無料で提供してもビジネスとして成功できるという意見の持ち主を批判しているそうです。

TechCrunch Japanese アーカイブ ≫ 37Signals、他社をDeadPoolに追い込む

もし、自作ソフトウェアを有料でリリースできる立場にあり、それに、市場を独占するつもりがないのなら、もちろん有料化にすれば良いと思う。しかし、ソフトウェア制作に時間と労力を注いだからという理由だけで、「ソフトは有料でなければダメだ」というアイディアをむやみと信じて、ビジネスモデルを決定すべきではない。そして、すでにコモディティ化につれて無料化が進んだビジネス分野(ここで指すのはオンラインフィードリーダー市場)に有料サービスとして参入しようというのは、正気の沙汰ではない。


世間的にそういう無料のビジネスモデル流行っているから、「無料で提供しよう」なんて思っちゃいけないわけですよね。

世の中で当たっているサービスは、皆それなりにしっかりとした戦略とコンセプトに基づいて作られているわけで。いやね、たまに「まぐれで当たった」とか「たまたまヒットした」とかいうものを聞きますけど、それはあくまでもイレギュラーケースであるからこそ、ニュースになるわけで。

サービスに必要なのは、しっかりとしたビジネスモデルと、確固たるコンセプトだと、僕は思っています。

まあ、偉そうに言っておきながら、そういうサービスを運営したことはないんですけどね。

2007年8月 7日

IT技術者は仕事に対する満足度が低いのだとか。

IT技術者は仕事に対する満足度が低いのだそうです。

「IT技術者は仕事に対する満足度が低い」--英大学調査:ニュース - CNET Japan

今回の調査では、4万ポンド(約960万円)以上の年収は、通常、仕事に対する満足度の向上に大きなプラス効果をもたらすことが分かった。それにも関わらず、高収入のIT労働者らは自分たちの仕事に満足していないようだ。

なんなんでしょうね。分かるような分からないような。

そういえば、@ITには↓こんな記事が出ていました。

Googleは人材を飲み込むブラックホールか - @IT

この中で、

フリーソフトウェアや、日本のいわゆるフリーウェアといった趣味のプログラミング活動は、昼間の仕事に対する不満が原動力になっている、というのだ。例えば、本職では好きでもないプログラミング言語を使って、特におもしろくはないシステムを粛々と作るばかりで、ワクワクするような、知的好奇心を満たすチャレンジが何もないという状況が考えられる。自分の仕事はシステムの一部の歯車でしかないということもあるだろう。そうした不満があるから、たとえ残業して遅く帰ってとしても、夜更けまで趣味のプログラミングに打ち込むことができる。

こんなこと言われているわけです。

うちに帰ってからも、趣味グラミングしている僕としては、半分はうなずける内容ですね。

一生懸命最新の技術動向を追っても、なかなか仕事の中で使う機械がないというのは良くあることで。

逆に、仕事に不満を持っている人(満足していない人)は、どうなったら満足する状態になるんでしょうか。

お金がたくさんもらえるれば良いのか、それとも、最新の技術を使って刺激的なシステムを作れれば良いのか、納期に追われずゆったりとシステムを作れれば良いのか。

僕は、プライベートの時間がしっかりと確保できるのであれば、ある程度の仕事で十分満足できるような気がします。裏を返せば、そういうプロジェクトはなかなかなく、デスマーチがいたるところに転がっているってことなんですけど。

2007年6月29日

IPA セキュア・プログラミング講座 改訂版

IPAがセキュア・プログラミング講座を改訂していました。


IPA セキュア・プログラミング講座


従前は、ソフトウェア開発工程における下流の工程において、セキュリティ脆弱性が発見され、それらについて対処されることが多かった。

しかし、作り込まれた脆弱性によっては、容易には修正できないものもありうる。また、たとえ修正できたとしても、不経済な事態になってしまう。

下流の工程においては、取り返しがつかない脆弱性をもってしまわないように、するためには、上流工程(要件定義、設計)から脆弱性対策の論点を意識できるようにする必要がある。


セキュリティは超重要。

そんなこと誰でも分かっているよと良いながら、XSS対策もままならないサイトが多数存在するのも事実です。

今度の改訂では、開発の上流行程からセキュリティに関する不具合をつぶせるようになっているみたいですね。

SIerとして働いていると、実装をしたことがないSEが設計を行い、実装するときにプログラマが苦労するというシーンをよく見かけます。

「こんな設計じゃうごかねーよ」というプログラマに、「こんな実装へぼすぎる」と嘆く設計者。

なんか三谷幸喜監督作の「みんなのいえ」を彷彿とさせます。

やはり上流工程やる人間は下流工程の実作業や苦労するポイントを身をもって知っておくべき。

「そういう仕事がまわってこない」と嘆く前に、家のPCに開発環境導入して日曜プログラミングでもためしてみりゃ良いんです。知識だけじゃなく、実際に試してみて、自分の中の知識を生きたものにしていく。それでこそプロフェッショナルなんじゃないかと。

まあ他の人はどう思うか分かりませんが、少なくとも自分自身はそういうスタンスで仕事に臨みたいですね。


みんなのいえ スタンダード・エディション
東宝 (2005/12/23)
売り上げランキング: 2991
おすすめ度の平均: 4.0
4 のほほんと………
4 ドーナッツ?
5 すごいな

2007年6月26日

国家資格という紙切れを何が何でも手に入れろ!SE編 --- ヘルプマンより

今週号のイブニングの「ヘルプマン!」に熱いシーンがありました。(国家資格という紙切れを何が何でも手に入れろ! --- ヘルプマンより (くりす流)

国家資格取る取らないの話だったので、これはSEにも当てはまるのではと思いテンプレ化。

元ネタは上記リンク先です。


百 「資格資格資格……。試験試験試験……。
   一体それが何になるんだよ!! 
   実装するときにメモリのヒット率を求めたりするか?
   コードを書くのに会計の知識やら法律に関する知識が必要か!?」

仁 「必要なんだよ。
   情報処理技術者の資格がなければ働けなくなるんだよ。
   どんなにプログラムが好きでも
   どんなに腕利きのプロジェクトマネージャでも
   企業に勤めるSEも在宅勤務のプログラマも
   資格がなけりゃ働かせてもらえねぇ
   法律はそういう方向で動いているんだ……」

百 「何で……
   んなことになってんだよ」

仁 「それだけ出来上がったシステムの質が悪いってことだ……」

百 「それと資格と何の関係があんだよ!
   資格もっててもろくでもない奴いっぱいいるじゃん!」

仁 「現場から離れたくなきゃ一生に一回くらい勉強しろ」

百 「国会議事堂の前でうんこしてやる」

仁 「殺すぞ…
   もう一度オレに同じことを言わせたら……
   勉強したくてもできねえ体になるぞ」

百 「(やばい…仁がキレる…)
   わかった!
   学校へ行く
   勉強する!
   あー早く学びてえなぁ!!!」

仁 「とんでもねぇ時代が来るんだよ
   わかってんだろ?
   ああ?

   単価が安くて優秀な外国人プログラマが溢れ出す…
   システム予算の大幅削減
   目減りする給料
   不況で従業員を支えきれない企業……
   システム構築現場からの人材の流出

   どんくさい お国のクソ政策の谷間で
   もがき苦しむ年寄りを指をくわえて見ているのが
   いやなら…

   お国と正々堂々戦争をしたいなら
   国家資格という紙切れを何が何でも
   手に入れろっつってんだよ
   ああ!?」


どうでしょうか。

まあ、こんなこと書きながら、僕自身基本情報しか取ってなくて、しかもあまり資格を取ることに対して積極的じゃなかったりします。

介護業界みたいに法律で縛られるのなら話は別ですが。


ヘルプマン! (1)
ヘルプマン! (1)
posted with amazlet on 07.06.26
くさか 里樹
講談社 (2004/05/21)
おすすめ度の平均: 5.0
5 介護の現実が良く描写されています
5 あなたの すぐそばの事
5 老人介護とは

2007年6月23日

仕様書は Excel か Word か他の何かか

みなさん、仕様書は何で書かれてますか?

アルファルファモザイクより「仕様書をExcelで書くんじゃねぇ」
はてなブックマーク - アルファルファモザイクより「仕様書をExcelで書くんじゃねぇ」

私の会社では、仕様書のテンプレートがExcelとWord形式で管理部門から提供されているのですが、利用されているのはExcelが多いようです。

個人的に思う仕様書として重要な要素は、まず「書かれている内容」、次に「意味・意図が適切に伝わるかどうか」、そして「メンテナンス・運用のしやすさ」かなぁ。

これが守れていれば、何で書かれていたって良いと思います。

何を選択するかは、当然、システムの規模や内容にもよってくるわけで。

数名で作り上げ、運用もそのメンバーでやるシステムなら、仕様書は手書きで、重要事項はWikiへという運用でも大丈夫でしょうし、数百名が関わるような大規模PJでは、電子データで運用しなければ情報がうまく伝わらないでしょうし。

一番ナンセンスなのは、「いつもそうだから」という理由で、何も検討せずにフォーマットを決めてしまうことかなと思います。

Word と Excel どちらで書いてもそれほど変わらないと言う場合は、僕はWordを選択するかなぁ。
印刷のときに変な気遣いをしなくて良いというところが好きです(とはいえ、たまに貼り付けているオブジェクトがバグることがありますけど)。

ドキュメントがメンテナンスしづらいと、ドキュメントと画面の乖離がどんどん進んでいくので、Web系のシステムならいっそ画面に書き出したら良いんじゃないかと思い↓こういうのも作ったことあります。

showyou --- HTML に Ajax でドキュメントを出力 (でぃべろっぱーず・さいど)
showyou-0.0.2 Release (でぃべろっぱーず・さいど)


最終的に一番頼りになるドキュメントはソースコードだと思うので、ひたすらテクニックに走るだけじゃなく、後から見て分かりやすく、誤解を生まないようなロジックやコメントを書いて欲しいです。

↓笑い話として、こんなソースコードの例が良く挙げられますよね。

// hoge が 5 より大きいとき処理する。
if ( hoge < 5) {
hoge += 10;
}

2007年6月21日

名前って大事

数日前にはてブでホッテントリになっていた↓これ。

まだ読んでない

僕が5月の頭に作った↓これとよく似てるんですよね。

超簡易ほってんとりーだ(はてなブックマーク + livedoor clip)


ぱくられたー!とか言いたい訳じゃなく(こんなの誰でも思いつく&実装できるし)、注目されたアプリと注目されなかったアプリでどこがどう違うのか、どこをどうすれば注目されたのか、そういう情報を得る良い機会かなぁと思います。

タイトルの付け方とか、情報の表示の仕方とか、プッシュしているポイントとか。

今後の参考にいたします。

↓ちなみにページを作ったときのエントリはこちら。

Google AJAX Feed API でほってんとりーだ作ってみたよ (でぃべろっぱーず・さいど)

2007年6月20日

SIer としてどう働くか

スターロジックはぶさんのSIerについての日記です。

六月水無月はぶにっき --- SIなんてつまらん仕事ですよ
六月水無月はぶにっき --- SIって最高の仕事ですよ

SIerとして納得できる部分もあり、環境によるよなぁと思うところもあったり。

ただ、最近思うのは、「ものづくり」といっても色んな立場や規模があるということ。

うん百億円、うん千億円かけた大規模システムにかかわるのも、数名でWebサービスを作るのも、同じ「ものづくり」という呼び方をするから混乱するのかなぁ。

SIerとして働いて6年になりますが、ここ数年で自分のやりたい仕事がおぼろげながら見えてきた気がします。

それが今いる会社で実現できるのか、はたまたはなから相手にされないのか。

今年来年あたりは正念場だなぁと思ったり。

2007年5月25日

エンドユーザをプログラムの一部と考える

秋元@サイボウズラボ・プログラマー・ブログにて紹介され、はてぶ界隈で話題になっていた「reCAPTCHA」というサイト。

コメントの投稿などでユーザに画像の中の文字を認識させる「CAPTCHA」という仕組みに、ひとひねり加えて、OCRでうまく読み込めなかった文字を、ユーザに認識させ、OCRの精度を高めようという仕組みです。詳しくは、下記サイトを見た方がよく分かります。


秋元@サイボウズラボ・プログラマー・ブログ: reCAPTCHA - キャプチャを利用した人力高性能OCR
「CAPTCHA」技術を応用して書籍のデジタル化を進める新ツール「reCAPTCHA」 - CNET Japan


サイボウズラボの秋元さんの「ネットの向こうのたくさんのユーザを、仮想的なプログラムにしてしまう」という表現は、この仕組みを端的に的確に表しているというか、すごく素敵な表現だなぁと思いました。

これに限らず、ソーシャル・ブックマークや口コミ投稿サイト、広く言えばSNSやブログへの投稿など、いわゆるCGM系のサイトは、その仕組みもさることながら、「コンテンツ」の「量」と「質」がとても重要になってきます。

そしてそのコンテンツをシステムに投入するのは、今のところ生身の人間なわけで。

ユーザインタフェースを快適にしたり、ユーザがコンテンツを投入しようと言う気分にさせたりすることも、システムを設計する上で重要なポイントになります。というより、むしろそのこと自体がシステム設計であると言っても良いかもしれません。

そういう視点(システムの外側にいる利用者、エンドユーザすらプログラム/システムの一部と考える)からシステム設計を考えると、また違った発想が生まれきそうですね。

ちなみに、「ネットの向こうのたくさんのユーザを、仮想的なプログラムにしてしまう」という意味では、以前に紹介した「Google Image Labeler」や「Google Translate」もそれに当てはまると思います。

エンドユーザは楽しくシステムを使うことができ、その一方で、システム自体が成長していくという仕組みは本当に面白いですね。

<関連エントリ>
楽しく情報をまとめあげる方法 (でぃべろっぱーず・さいど)
機械的に処理したものを人がフォローする仕組み (でぃべろっぱーず・さいど)

2007年5月19日

SEを目指す若者へ

Javaの専門誌がなくなった理由 (でぃべろっぱーず・さいど)」というエントリのコメント欄にSEを目指しているという高2の方からコメントをいただきました。

僕の書き方がうまくなかったからか、ちょっと誤解を与えてしまったなぁと思い反省。

返事をコメント欄に書こうかと思ったのですが、高2でちゃんと目標を持って勉強している若者へのメッセージということで、ちゃんとエントリとして書いた方が良いかなと思い、このエントリを書くことにしました。

あと、昨年、会社の新卒採用のお手伝いをしたことがあって、そのときに意外とSEという職種が理解されていないもんだなぁと思ったからというのも理由の一つだったりします。

SEとは何者か?

SEとは、言うまでもなく「システム・エンジニア」の略なんですが、仕事の内容は人によって色々。幅がかなり広いです。

個人的には「業界人」的なニュアンスだととらえています。「業界人」って、芸能人もいれば、ディレクタ、プロデューサ、ADとかいたり。それぞれ役割は違うけれど、ひとくくりにして「業界人」というような言い方をしますよね。

SEも同じで、提案する人、要件定義する人、設計する人、管理する人、プログラム書く人、みーんなひとくくりにSEと呼ばれています。一人でいくつもの役割をこなすことなんてざらですし、何かに特化したエンジニアというのも珍しくはありません。

というわけで、SEを目指す人は、自分がどんなSEになりたいのかをよーく考えておいた方が良いです。

それによって入るべき会社が大きく変わってくると思います。

パソコンが好きだからなんとなくシステム・エンジニアかな、と簡単に考えて会社を決めちゃうと、後々苦労することになるかもしれません。

大規模なプロジェクトを管理をして、自分の下にいっぱい人を従えて、というのを希望する人は、大手SIerを目指すと良いでしょうし、利用者の顔を見ながら仕様を決めて、自分でシステムを作っていきたいという人は、企業のシステム部とか、或いは勢いのあるネットベンチャーを目指してみるのも良いでしょう。

同じ「システム・エンジニア」でも、その仕事の内容、境遇は人それぞれ、SEとして一生食っていくつもりの人は、ちゃんと事前にリサーチしておいた方が良いです。


Java は勉強しなくても良いか

上記エントリで誤解を招くような書き方をしてしまいましたが、Java は勉強しておいた方が良いです。

理由は以下の通り。

・Java で作られたアプリは多い。
 →当然保守運用が発生するので、Java エンジニアの仕事がなくなることはしばらくなさそうです。

・最近流行のLight weight Language (LL) とは棲み分けが進むだろう。
 →最近 Ruby on Rails とか流行っていますが、Java アプリがすべてその手のLLに移行するわけではなく、得意分野で棲み分けが進みそうです。ということで、それぞれの特徴なりをしっておく必要があります。また、実際にJavaでのアプリ開発を経験しておくと、俗に言われているLLとの開発生産性の違いが良く分かります。

・なんだかんだいってとても流行した言語である。
 →Java については色々と問題点も指摘されてますが、FWの数が裏打ちするように、ものすごく流行した言語であります。その魅力はいったい何なのか。実際にJavaを学んで体験しておいた方が良いです。

上記エントリでは「実際のシステム構築業務において、"最新"のJavaの技術はもはや必要なくなっています。 」と書きました。

これはそれほど的はずれではないと思っていますが、あくまで僕個人(そこそこ大きなSIerに勤めるSE的な視点)の意見と考えてください。この点に関しては、「いや、Javaの最新動向を押さえておくと、市場競争で優位に立てる」と主張する人がいるかもしれませんし、仮にそう言う人がいてもその意見を否定することはできません。

また、今SEを目指している人は、今時点での最新動向を押さえておくと、働く頃にそのときの知識が生きてくるかもしれませんしね。

いずれにせよ、「勉強するくせ」を付けておくことは重要で、インターネットで調べることはもちろんですが、技術書や雑誌をチェックする習慣をつけておけば、入社した後も苦労することなく情報を仕入れることができると思います。

ちなみに僕が定期的にチェックしている(毎号買っているわけではないです)のは以下の雑誌達。あと、大きめの書店に行ったら、技術系の本棚をざっと見て最近の流行動向を見てみることにしています。


開発の現場 vol.007
開発の現場 vol.007
posted with amazlet on 07.05.19
SE編集部
翔泳社 (2007/01/17)
売り上げランキング: 52418


エンジニアマインド Vol.1
エンジニアマインド編集部
技術評論社 (2006/09/15)
売り上げランキング: 84086
おすすめ度の平均: 5.0
5 特集:チーム力アップのカギについて
5 IT技術ビジュアルマップが秀逸!


WEB+DB PRESS Vol.38
WEB+DB PRESS Vol.38
posted with amazlet on 07.05.19
WEB+DB PRESS編集部
技術評論社 (2007/04/24)
売り上げランキング: 2516



とまあ、コメント欄での返信ではなくエントリにした割には、なんだか上手くまとまりませんでしたが、IT系の職種の人気がなくなっている中、SEを目指してくれる人にとって何かのヒントなればと思います。

2007年5月 8日

被はてなブックマーク画像表示ページにXSS攻撃してないよ。

被はてなブックマーク表示APIにXSSの脆弱性があるというネタエントリがはてブされてました。

被はてなブックマーク画像表示ページにXSS攻撃してみる。 - ぎじゅっやさん

「dozoさんはブックマーク数表示しないんですか?(・ω・)」 「うん。XSS攻撃されるのがいやだから。(・∀・)」 「・・・(゜Д゜)」

アレ?(・ω・)
オレなんか変なこと言ったか?
オレの中では常識だったんだが。。


・・・(゜Д゜)

ネタすぎて、はてブされている割りに、誰も突っ込まないんですが、勘違いしている人も多いようなので余計なこととは分かりつつ突っ込んでみます。


この状態でURIに細工をする。
こんな感じのURIでどうだろうか?
http://hain.jp/index.php/tech-j/2007/04/09/p140"/><b>hoge</b>
ブラウザはIE6。

結果は?


これで、hogeが太字になった、と、でもってこのbタグがscriptタグだったら大変だ、みたいなことをおっしゃってるわけですが、んなわけない。

はてなブックマーク取得APIの仕様をよーく見てください。

<img src="http://b.hatena.ne.jp/entry/image/サイトのURI">

これで指定するわけです。

勘のよい人はもうお分かりですよね。

さっきのURIと組み合わせてみると、こんな感じになります。

<img src="http://b.hatena.ne.jp/entry/image/http://hain.jp/index.php/tech-j/2007/04/09/p140"/><b>hoge</b>

はい、見事bタグのhogeははてなブックマーク表示APIに送られていないことがお分かりでしょうか。

要はこの方、自分のサイトにbタグ書いて、「ほら太字で表示されたよ、このタグをscriptタグにしたら大変だよ」と騒いでいるだけです。

これでセキュリティに問題があるのであれば、全世界のHTMLページはセキュリティに問題があることになりますので。

んなわきゃない。

URIのパラメータの/や&をescapeしないといけないのは、そのパラメータが、親URIのものなのかパラメータに指定されているURIのものなのか分からなくなるから、というのが一番の理由じゃないでしょうか。

ただ、このAPIは、パラメータとしてURIだけを受け取る仕様なので、escapeしなくてもOKということだと思います。

ユーザにとっても、その方が直感的で分かりやすいですし、そもそもescapeされたパラメータを持ったページのはてブ数を表示したいとき、さらにescapeが必要になって大変ですよね。

pathinfoの取得方法が通常の方法とは異なっていることはおそらく事実で、URIに正規表現で当て込んでいるんじゃないかと。

↓似たような質問に回答したことがあるので、そのリンクも貼っておきます。

現在Ajaxを利用した簡単なノートパットを作成しています。保存の際にAjaxの機能を利用し、リアルタイムで保存できるようにしたのですが、サーバーとのやり取りが分けありでGETメソッドです。


単に埋め込まれるだけダロ(゜Д゜)?
と思うような人がターゲットだ。
私も最初はそう思ったが、
攻撃可能なアドレスをいろんな掲示板サイトなどで公開されたりすることも考えられる。
世の中HTMLについて知らない人の方が大半なわけで、
海外のよーわからんサーバやASPにページを一枚置いておき、
「女子○生○×△□」などのキャッチーなタイトルでXSSできるサイトにリンクを張るなり、iframeに埋め込むなりするだけでCookie位は楽勝で取れるだろう。


これはこれで別のお話でして、例えばmixiや2chといった「有名な」「誰でも書き込みできる」サイトの投稿欄から、scriptタグを含んだ文字列が投稿でき、さらにそれが実体参照に変換されないまま表示されてしまうときにXSSが問題になるんですよね。

間違っていること書いていたら突っ込みお願いします。

2007年5月 2日

GET か POST か

知っている人は「そんなの当然」的な話なんですが、僕自身上手く整理出来ていなかった部分があったのでメモ。

画面を表示する際に、パラメータの引き渡しを GET にするか POST にするかをどう決めるか。

RailsによるアジャイルWebアプリケーション開発」の章16.9 に簡潔に書いてありました。


1996年には Tim Berners-Lee が、サーバからの情報を取り出すには GET リクエストを使用し、サーバの状態の変更を要求するには POST リクエストを使用する、と記しています。


「GET か POST ってどうやって決めるの?」と聞かれたとき、簡潔に答えられそうです。

2007年4月26日

ティーアンドエフカンパニーの出羽健一さんに会ってきました。

会社の先輩倉貫さんの紹介で、ティーアンドエフカンパニーの出羽健一さんに会ってきました。

紹介していただくきっかけとなったのは、「showyou --- HTML に Ajax でドキュメントを出力」で作った showyou という「Ajaxで外部からテキストを読み込んでWebページに画面仕様を書き出す」ツールが、「「HTML画面をそのまま仕様書に」,5カ月で1000画面を構築した就職サイトPuffの高速開発手法:ITpro」で紹介されていた出羽さんの会社のツールに発想が似ていたから。

というか、僕がこの記事を読んで、似たようなことができないものかと作ったのが showyou なのです。

この記事だけじゃ分からない部分が多いので、色々聞いてみようと、ティーアンドエフカンパニーのオフィスを訪問してみました。

社外の方に会う機会はなかなかないので、ちょっと緊張しましたが、出羽さんはとても気さくな方で、記事には載っていないお話や、今作成中のツールなどなど、楽しくお話を聞かせていただきました。

話していて感じたのは、出羽さんってものすごーくSIer視点のハッカーなんだなぁということ(違ってたらごめんなさい)。

コードジェネレートとか、いわゆる「フレームワーク」的な開発をシンプルにするということを考えているんですが、そこに「いかにして仕様書を作るか」とか、「うまく顧客とプロジェクトを進めて行くにはどうしたらよいか」とか、「管理者が仕様変更や不具合の傾向を上手くつかむにはどうしたらよいか」といった、一つ上の視点があるんですね。

同じSIerとして勉強になる部分が多く、良い刺激になりました。若くして大学院の助教授というのも納得です。

このMTGを通じてshowyouのバージョンアップポイントも明確になってきました。

・画面からテキストファイルが更新できること。
・コードの埋め込みの面倒さをなんとかすること。

とりあえずは、この2点ですね。


そうそう、先日発売された「WEB+DB PRESS Vol.38」に、「無駄なコードを書かない技術」として、出羽さんをはじめティーアンドエフカンパニーの方が執筆されています。

コードジェネレータやAOP、O/Rマッパ、HTMLテンプレートについて、より詳細に書かれていますので、興味がある方は読んでみてください。

読んだ私は、早速仕事で S2 シリーズを使いたくなりました。

WEB+DB PRESS Vol.38
WEB+DB PRESS Vol.38
posted with amazlet on 07.04.26
WEB+DB PRESS編集部
技術評論社 (2007/04/24)
売り上げランキング: 379

あ、そうそう、「WEB+DB PRESS Vol.38」には、小飼弾さんのアルファギーグに会いたいのコーナーに、amachangさんと、Hamachiya2さんが登場してます。

これも面白い記事でした。

2007年2月 5日

tomcatのソースやバグ情報をチェック

現在開発中のシステムで、POSTパラメータの送受信でちょっとした不具合が発生しました。

原因究明のため色々と調査していく中で、アプリサーバのtomcatのソースコードまで見ることに。

そういや今まで、POSTパラメータの取得方法なんて気にしたこともありませんでした。

良い機会なので、色々と学習。

「電文はこんな形式で飛んでくるのかー」「tomcatってこうやってパラメータ分割してるんだー」と、一々勉強になりました。

この対応の中で、Google Code Searchの使いどころがようやく分かった気がします。

一通り見た後で、今度はtomcatのバグチェック。

バグレポートを見ると、思いの外たくさんアップされてました。全部が全部対応されているわけでもないようなので、バージョンを上げたら意外と解決しちゃうのかしら。

オープンソースってこういうことできるから楽しいですね。

2007年1月 2日

生産性を高めるために

404 Blog Not Found:生産性の凄惨性

弾さんのブログで「生産性」について触れられていました。

会社で働いていると、何かにつけ「生産性」というキーワードが持ち出されます。

私の会社でもご多分に漏れずそうなっていて、「生産性」を高めるために色々な社内ルールが制定されています。

顧客への提案資料にも「我が社は○○のような方法で生産性をUPしています」みたいなことを書いたりして。

でも、実際に働いていて思うのは、こういう「ルール」が生産性を「保つ」ことはあっても、「高める」ことはないということです。

おそらくそういう「ルール」化されている様式は、仕事ができる人が、テンプレートやノウハウを周囲に広めて「お、その方法良いね」「今度からそれでいこうか」みたいなノリで広まっていったのが最初なのではないかと思うのです。

そのレベルであれば、そういう様式を提案した人も、定番のやり方にしようと決めた人も、もっと良いやり方があるんじゃないかと試行錯誤、レベルアップしていけるんでしょうが、一旦会社が決めた「ルール」になってしまうと話が違ってきます。

「決められているから」というだけの理由で、なんの疑いもなくテンプレートを埋めることにだけ注力しだしたら、そこに無駄な作業があったとしても改善していこうとは思わないでしょう。

なんとなく工場の生産方式に似ている(あくまで「似ている」レベルですが)気がします。

ベルトコンベアに乗って運ばれていくるパーツを黙々とはめ込んでいく「ベルトコンベア方式」と、一つの製品を最後まで責任もって組み立てなければならない「セル生産方式」。

作業は複雑に、煩雑になっても、そこに職人の工夫や技術が入る余地があるため、生産性は後者の方が高くなるということを聞いたことがあります。

システム開発も、これと同じ考え方で挑まなければならないはず。

自分が仕事をするとき、ただ惰性で作業していたら、それはベルトコンベア方式で仕事をしているのかもしれません。

多少ルールを逸脱したとしても、そこに正当な理由と論拠があれば、周囲を説得してやり方自体を変えていくことを考えていかなければ、生産性なんて高くならないのです。

2006年12月23日

プログラムの美しさ

304 Not Modified: プログラマの美意識
404 Blog Not Found:美しいプログラムの美しくないソース

「美しい」という価値基準は、時代や場所、組織、ひとそれぞれで異なるものです。流行もあるので、昨年「美しい」とされていたものが、今年になると「美しくない」と評価されることもあるでしょう。

システム開発に従事している仲間で話をしていると、ときおり「プログラム(ソースコード)の美しさ」についての話題になることがあります。

その中で、「あそこの協力会社は良いものを作ってくる」とか「あの会社のソースは汚い」とか、そういった会話が出てきます。

ここで気を付けなければいけないのは、ここで会話をしている人それぞれがそれぞれの「美しさ」の価値基準を持っているということ。

あるプログラマは、「コードは短ければ短いほど良い」と考え、あるプログラマは、「コードは共通化されていればされているほど良い」と考え、あるプログラマは、「コードは読みやすければ読みやすいほど良い」と考え、あるプログラマは、「不具合が少なければ少ないほど良い」と考えていたりするわけです。

そういう場での会話では、それぞれがどういう価値基準を持っているかを確認することなく、会話が進み終わってしまうことがよくあります。

多種多様な言語が活躍し、コードを書くプログラマの数も膨大になった今、一つの美意識に固執し、「自分以外みんなダメ」的な発想に陥ってしまうのは非常に危険です。そのプログラマ自身の成長も止まってしまうし、そのプログラマの下についた若手のプログラマにとっても変な価値観を植え付けてしまうことになります。

「美しい」という言葉を使うとき、プログラマ(エンジニア)は自分が思う「美しさ」を説明できなければいけないと思います。

僕自身も、他人の作ったプログラムを評するときに「美しい」「美しくない」という言葉を使ってしまうことがあるので、まなめさんのように自分の考える「美しいプログラム」とはどんなプログラムなのかをよく考えてみることにします。

2006年12月22日

ゲームの開発をお手軽に

手軽にゲームソフトの開発環境を - マイクロソフトが国内でもXNAを提供開始 (MYCOMジャーナル)

XNA Game Studio Expressは、マイクロソフトが提唱する次世代ゲーム開発環境で、Windows XPとXbox 360向けのゲーム制作を同一の環境で行えるアプリケーションだ。Visual C# 2005 Express Editionと.NET Compact Frameworkを基盤としており、制作に必要な各種ツールも統合化されているという。ダウンロードはMSDNサイトで可能で、Windows XPユーザーなら誰でも無償で提供されている。

WindowsXP上で手軽にゲーム、しかも家庭用ゲーム機で動くものが作れるのは魅力的ですね。

プログラマの間で話題になって、このツールで作られたゲームがいくつかヒットすれば、次世代ゲーム機争いで苦戦しているXBOXも盛り返すことができるかもしれません。

2006年12月21日

美しいシステムとは

404 Blog Not Found:美しいプログラムの美しくないソース

弾さんのエントリより。

実装が美しいけどツカエないプログラムと、実装は醜いがツカエるプログラムとどちらがよいかといえば、後者の方に決まっている。もちろん実装も美しくかつツカエるプログラムというのもありで、プログラマーは皆それを目指しているのだけど、プログラマー側の美と、ユーザー側の美と、どちらかの選択を迫られたら、迷わず後者をとるのが私にとっての美しいプログラマーの定義だ。

まったくもって同意。プログラム、ソースのもう一つ上の視点で考えると、SIerにとっては顧客に提供できるものが「美しいシステム」であれば良いのであり、その中身が美しくなくとも良いのだと思います。

中身の美しさにこだわり、顧客にとっての「美しさ」を否定して、強弁にエンジニアの美意識を押しつけるのは、もはやオナニーであり、ある意味レイプといっても過言ではありません。

とはいえ、こだわりのないエンジニアは、それはそれで困ったもので。結局、「なにごとも中庸」というごくごくありきたりな結論に達してしまうのです。

顧客と「美意識」を共有できる。或いは、始めはまったく異なる美意識だったもの同士が、互いに歩み寄り新たな価値観を作り上げていく。そんな仕事の進め方をしたいものです。

2006年12月20日

外国人SEから見た日本人SE

外国人のホンネ「ソコがヘンだよ!日本人エンジニア」/Tech総研

中国、インド、アメリカのSEが、日本人SEの「ヘン」な部分を色々と指摘されています。

的はずれな意見もあれば、的確な意見もあり。

僕が「そうだよなぁ」と納得したのは、以下の意見です。


日本人は命令が苦手。相手を気づかうあまり、とかく語尾を問いかけ調にしてやわらげる。「こうしたほうがいいんじゃない?」と上司に言われたチャンさんは「やってもやらなくてもいい」と受け止め、結局やらないほうを選択してしまった。

確かに命令されることって少なくなりました。

上司はともかく先輩から「こうしろ」「ああしろ」という口調はまず聞かれません。だから悪いというわけではなく、日本人の同じ世代の人は、だいたい似たような共通体験がバックボーンとしてあるので、ある程度柔らかい言葉遣いでも、それが「マスト」なのかそうでないのかを判断できるんだと思います。

だから、全く背景が異なる人(例えば外国人)と接するときは、ここを注意しましょう、ってことですね。


インドではプロジェクトが終わると、次のプロジェクトまで暇な時間が与えられ、2週間ほどバカンスをとることも可能だ。「バリバリ元気に働き続けるためにもバカンスは大切」とヴァールさん。勤務時間が長すぎるため、平日は仕事だけで終わってしまうことに寂しさも感じている。

プロジェクトが終わった後のバカンスは、すごく賛成!

勤勉な日本人は、それほど仕事がないときも、なんとなーく会社に来て、ちょろちょろ仕事をして、インターネットで時間を潰して帰る、なんてことがしばしば見うけられます。そんな感じだったら、いっそ休んでしまってぱーっと羽を伸ばした方が良いんじゃないでしょうか。


仕事の効率を重視するピーターさんにとって日本企業はインフラ投資をおろそかにして、安い給与で長時間働かせる労働力に頼って見える。そこで一言「スパルタン!」。アメリカで同じやり方をしたら「みんな辞めてすぐに潰れる」と話した。

企業はインフラ投資をおろそかにしてますよねー。

うちの会社は大手IT企業ですが、社内からインターネットを見る速度が遅い遅い。インターネットで調べものをしても、ストレスが貯まる一方です。特に、新しいソフトウェアとかをダウンロードするときは、ストレスが頂点に達します。

社員に生産性を上げろと命令する前に、まずはその基盤となるインフラを整備することに手を付けて欲しいです。


ピーターさんの考えでは、日本人はメールに頼りすぎ。大量のメールを読むだけで時間が過ぎてしまう。「まずは電話で話して、その後に確認してメールを使うべき」と話す。プロジェクト管理をすべてメールで行うのも非効率と感じている。

メール!

大規模プロジェクトがメール文化に染まると、悲劇以外のなにものでもありません。一日休むと未読メールが300通なんて状況はフツーにありえますからね。

Googleさんは、メール文化ではなくブログ文化だそうで。情報はPUSH型ではなくPULL型にするほうが、重要な情報はちゃんと着信されると思います。が、それは若い世代に取っての話で、どっぷりメール文化に染まりきっている世代の人たちを、どうやって意識改革させるかというのが、若いSEに課せられた使命なんじゃないかと最近は考えてます。


日本にはお酒の席で親交を深める「飲ニケーション」文化がある。宗教的理由から飲酒の習慣がないインド人にとっては未知の文化。また、アメリカ人のピーターさんによれば、「こうした慣習を受け入れない若い日本人が増えはじめ、先輩と部下の絆が弱まり、技術の継承がない」と分析した。

仕事以外の付き合いって重要なんですよね。それは同意。

じゃあそれが「飲み」や「プライベートの遊び」だけなのかと聞かれると、NOだと思います。

SEがホワイトカラーで、成果だけを問われるのであれば、業務中にももっと仕事以外のコミュニケーションがあっても良いはず。だからこそ、いけてるベンチャー企業には、ビリヤード台があったりダーツがあったりするんでしょう。

「もっと呑みに行け」とプライベートの時間を使うよう促す前に、もっと業務中に打ち解けあえるような工夫をしていきたいですね。まあ、これは僕が子持ちで、家に早く帰りたいからというのもあったりするんですが。

2006年12月17日

If programmers have make a plane

もしプログラマが飛行機を作ったら・・・というCMです。



飛んでいるはずの飛行機は、胴体はスケルトンだし、座席は取り付けられていないし・・・。飛行機にしがみつきながら、必死で組み立てていくプログラマ達。

ベータ版でサービスをリリースして、不具合を修正しながら運用していく様を例えているのでしょうか。

VTR最後のメッセージを読むと「顧客のビジネスと共に成長していきます」みたいなことが書いてあって、そういうメッセージを伝えるのに、飛行機に例えたらまずいんじゃないですかね。人の命が関わっているだけに、制作者の意図とは異なったものが伝わりそうです。

2006年12月 9日

XBOX360のゲーム「カルドセプトサーガ」が大変なことになっているらしい

痛いニュース(ノ∀`):【Xbox360】「カルドセプトサーガ」で、プログラマーがランダムなサイコロを作れなかったことが発覚
痛いニュース(ノ∀`):カルドセプトサーガのプランナー、mixi内バグだらけのソフトに懺悔と自社批判

カルドセプトと言えば、カルト的な人気を誇るボードゲーム。

僕もPS2版を持っていて、結構はまって遊んでいました。

その最新作がXBOX360で発売されたのですが、その品質があまりにも悪すぎて、ユーザから不満続出なのだとか。挙げ句、ゲームを作った会社のプランナーがmixiで心情を吐露してしまう始末。

ユーザは、↓こんなブログを作成して必死でバグを潰しているようです。

カルドセプトサーガ不具合情報

それにしても信じられないバグが続出のようです。

ランダムなサイコロの目が出せなかったり、コンピュータの操作が無限ループに陥ってしまったり。どう考えてもテストをした品質とは思えません。

このゲームがオンラインゲームであるという点から、「納期に間に合わない」→「テスト工程を短くする」→「テストが充分でない」→「パッチをあてればなんとかなるだろ」という思惑が制作者サイドにあったんじゃないでしょうか。

それにしても、YouTubeの登場で、「ほら見て、こんな不具合が」というバグ報告のやり方が大きく変わりましたね。手軽だし、分かりやすいし。動画を共有できるメリットが活きているシーンだと思いました。

通常のシステム開発のテストも、こういうノリで動画でエビデンスをためることができたら、やりやすいかもしれません。

2006年12月 8日

システムの価値はどうやって測る?

システムの価値はどうやって測る?

[R30]: コンテンツ品質とIT活用のコストはタダではありません
仙石浩明CTO の日記: なぜ人月見積もりが優れているのか
音極道茶室: 首相官邸WEBサイト+メルマガで7億2千万はありえない(2006/12/10追加)

はてなブックマークで上の2つのエントリを読んで、ちょうど最近、ソフトウェアの値ごろ感について色々考えていたので、自分の考えをまとめる意味でもこの問題について書いておこうと思います。

最初に僕の立ち位置をはっきりしておきます。この問題は、その人が会社の経営者なのか、管理者なのか、普通の社員なのかで大きく変わってくると思うので。

僕は、大手SIerの入社5年目(中堅社員の入り口)で、入社以来Webアプリの新規構築の仕事を主にやってきました。役職は特にありません。

まず最初に、社民党が指摘している首相官邸HPとメルマガに7億円使っている問題について、その額が妥当かどうかという点から。

過剰広報予算:小泉メルマガ、官邸HPに年間7億円超-今日の話題:MSN毎日インタラクティブ

社民党は、「1日当たり200万円になる。税金を使ってジャブジャブと自分たちの政策を垂れ流している」と批判しているようですが、これは割り算の方法で色んな印象になる数字ですよね。

1日当たり200万円ということは、1週間で1,400万円。このメールを200万人(今は160万人)が読んでいたわけですから、1人1通あたりの負担金額は7~10円負担なわけです。

さて、首相官邸メールは、国の政策や大臣が考えている(とされている)ことが書かれていて、手を抜いているなぁと言う印象は受けず、「首相官邸」メールとしての役割は充分に果たしていたと思います。

過去、これほどダイレクトに国民に対してメッセージが届けられることがあったでしょうか。若者はNHKの放送なんて見ていないし(政治関係のニュースもね)、民放の報道は結構バイアスがかけられているわけで。

そんな中、1通7~10円、年間50通来るとして年500円の負担は大きいのでしょうか?

単純にメルマガの価値から考えると、僕は「格安」価格だと思います。この辺りの感じ方は人それぞれだとは思いますが。

7億円の中には、首相官邸HPのコンテンツ保守・運用費がのっかっていると思うので、実際のメール1通当たりの値段はもっと下がることになりますしね。


一方で、じゃあ7億円の使い道はどうだったのか、という話もあります。

PGやSEの単価をならして月100万円とします(あくまで見積上の単価です。PGやSEの手取り月収じゃありませんよ)。

7億円を割ると、700人月になります。12ヶ月で割ると、1ヶ月あたり約60人が関わっている計算になります。人月から計算するとtoo muchのような印象を受けます。

まあこれは単価が100万円で計算しているんで、倍にすれば関わる人数も半減するわけです。


気になるのは、初年度以降多少の変動はあるものの、それほど大きな額の変化がない点。

おそらく初年度はハードウェア一式等を納入したはずで、その分他の年よりも高くなっているんじゃないかと思うわけです。

逆に言うと、2年目以降は、初年度よりも割と安く運用できるはず。それが、大体毎年同じ予算でやっているというところに、「予算を減らさないように色々調整する」役所独特の慣習が働いてるんじゃないかなぁと。


まとめると、こんな感じです。

  • メールを受け取る個人的感覚だと、メルマガ、官邸HPに7億円は、そのものの価値から考えると「格安」だと思う。
  • 工数から割り算していくと、割高感がある。(個人的にはもっと安く押さえられると思います)
  • 官公庁にありがちな「予算を使い切らなきゃいけない」という思惑の中で、実際の経費と異なる部分がありそう(これは完全に推測ですが)。


さて、これを踏まえて、人月見積もりについての考えはまた別のエントリで書くことにします。

2006年12月 3日

データを自動で大量生成

瞬時にテストデータを大量生成してくれる『Data Generator』 | i d e a * i d e a

システム開発のテスト時に、いつも頭を悩ませるのが「テストデータ」の作成です。

特に最近はパフォーマンス要件の確認のために、大量のデータを積み上げる必要がある案件が多いそうで。

リンク先で紹介されているサイトは、そういうデータを出力してくれる便利なサービス。

人名や電話番号など、ある程度ランダムな値が求められるときは重宝しそうです。

ただし、2006/12/3 23:00の時点では、サイトはデータ転送料の制限にひっかかってサービス停止中のようです。

こういうサービスが社内にあると便利かも。

それほど難しいロジックじゃなさそうなので、余裕があるときに作ってみよ。

2006年11月29日

改善 or not ?

余剰人員2300人…“トヨタ方式”じわり浸透 郵政公社-ITニュース:イザ!

「改善」するのは難しい (でぃべろっぱーず・さいど)」で書いたトヨタ方式の郵政公社への導入結果の報告があったようです。

郵便区分けや配達作業などの基本動作に加え、局内レイアウトの見直しなどで、最も忙しい年賀状シーズンだけをみると生産性は約20%も向上。平成17年度は約30億円のコスト削減効果があったという。

ということですが、「最も忙しいシーズンだけ」を見ない場合はどうなるんでしょうか。平成17年度の30億円のコスト削減効果も、全体の額が分からないとなんとも評価しようがないですね。

ただ気になるのが、「ただ、余剰人員は生産方式を伝授する専門指導係に配置され、実際の人件費削減は進んでいない」というところ。

結局、働く部署が変わっただけだったら、実はあまり改善されている部分はないんじゃないかと。

報告で挙げられている数字も、色々なところの数字をやりくりした結果何じゃないかと疑ってしまいます。

無駄をなくして、効率を高めようという動きは素晴らしいので、これが正直な報告であることを願います。

2006年11月28日

バグを指摘されたときは

Geekなぺーじ:バグを指摘されたプログラマの返答ベスト20

バグを指摘されたときのベタな返答集だそうです。

1位が「私の環境では動作する」というのは納得。僕も良く聞きますし、良く言ってました。

デスマってるPJで僕が聞いたことあるのは、

「その程度はバグじゃない」

「そんなバグよりもっと大事なバグを見つけてくれ」

「とりあえずバグ票書いておいて」

「・・・はぁ(ため息)」

「そのバグは直しました!(怒)」

こんな感じですかね。

人は失敗したときにこそ本性が出ると言いますから、プログラマの方はバグを指摘されたときの作法を身につけておいた方が良いかもしれませんね。

2006年11月26日

徹夜はやっぱりしちゃいけない

小野和俊のブログ:徹夜をしてはいけない理由

だいぶ前のエントリですが、面白かったので。

徹夜をしてはいけない理由が書かれています。

「個人の精神的症状」のところがよーく分かります。

・恩着せがましくなる
例: 朝のミーティングで「先ほどやっと完成しました」

・先のことを考えている人間に対する怒りが芽生える
例: 「そんなこと言っている時間があったらちょっとは手伝ってよ」

・被害者意識を持つ
例: 「この会社でまともに仕事している人間は自分しかいないわけですから」

確かにそうなんですよね。徹夜して脳の活動が弱くなっていくと、視野と心がが狭くなっちゃうんですよね。で、最後はグチグチと恨み言を言うようになって。

徹夜でやらなきゃいけないときもありますが、それはあくまで最終手段と思わないといけませんね。

2006年11月11日

iBATIS

仕事でDBへのアクセエスにO/Rマッピングを使おうと言うことになって、色々と検討した挙げ句iBATISを使うことにしました。

O/Rマッピングと一口に言っても、実装の種類は結構たくさんあって、以下のような製品があります。

O/Rマッピングツール 特徴
iBATIS SQLMapsとDAOFrameworkという2つのフレームワークで構成されている。SQL文をマッピングファイルに記述する点が特徴。
Torque Generator(開発環境)とRuntime(実行環境)にモジュール分割されており、SQL文を記述せずにデータベースを操作することができる。
Hibernate 機能が豊富にあり、オブジェクトクエリ言語の「HQL」や、シンプルで扱いやすいAPIを提供する。
PriDE 軽量で、高速なO/Rマッピングツール。Active Recordパターン(エンティティがO/Rマッピングツールの基底クラスを継承する)に基づいているのが特徴)。
Cayenne データベースのエンティティをJavaのオブジェクトとして扱うことができ、GUIツールも提供している。
OJB クラス生成は行わず、すべてのマッピング情報をXMLファイルに定義し、その定義を参照しながらデータベースとやりとりを行う。
O/R Broker 開発者が外部の設定ファイルにSQL文を定義し、その設定ファイルを利用してデータベース・アクセスを行うタイプのO/Rマッピング・フレームワーク。
Mr. Persister 開発者がSQL文を使用してデータベースアクセスを行うタイプのO/Rマッピングツール。
(出典:[ThinkIT] 第1回:O/Rマッピングとは? (3/3)

この中で一番メジャーなのはHibernateだと思うんですが、今回はiBATISを選択しました。

というのも、やはりSQL文を記述しないというのは、結構リスクが高いと思うのです。

DBへのアクセスが頻繁に発生して、かつ利用ユーザ数も多いシステムであればあるほど、DB部分のチューニングが必要になってくるわけで、SQLを記述しないタイプのO/Rマッピングだと、後々のメンテナンスで痛い目にあいそうな気がしたからです。

で、SQLがXMLファイルに直接記述できるiBATISを選択したのですが、正解だったかなぁと思ってます。

今回の構築では、開発期間が短かったこともあり、さらりそしか使ってませんが、もう少しiBATISの勉強をして色々と良さを理解していきたいなぁと思いました。

難点を挙げるとするとまだ日本語のドキュメントがそれほどない点ですね。

O/Rマッピングでどの製品を使おうか迷っている方は、是非検討する製品の一つに加えてみてください。

2006年10月30日

「改善」するのは難しい

asahi.com:郵政公社、トヨタ式に混乱 指導社員「上辺のみ改善」ツꀀ-ツꀀビジネス

トヨタのカンバン方式と言えば、その世界では結構有名は方式ですね。よく知らないと言う方は↓こちらでご確認下さい。

教えて!goo トヨタのカンバン方式って?

ものすごく省略して言うと、作業の無駄をなくして効率的に仕事をする、というのを目指した作業の方法です。

で、このトヨタの方式を応用したものを、郵政公社に導入したところ、現場は混乱し、結局査察があるときだけ利用して、それ以外のときは普段通り仕事をしていたそうです。

東京都内のある郵便局員(57)は「郵便局の仕事は、定型の部品を使う自動車の製造とは異なる」と指摘する。「日によって郵便物の量に波があるし、一つひとつ形や大きさ、重さも違う。必ずしも一定の時間ではできない」

この言い分は分かります。製造業のノウハウを無理に当てはめようとしても、なかなか上手くいかなそうです。

そもそも、「改善活動」って、トップダウンの号令ではなかなかうまくいかないものです。それでうまくいくのは、経営があぶなくなっていて、トップも現場も「このままじゃいけない」という強い思いがある場合。現場が「今のままで良いじゃん」と少しでも思っていたら、「改善活動」はほとんどの場合失敗します。

この記事のように、改善の形だけ残って、形骸化している作業やしきたりがどれだけあることか。

まず最初の改善は、そういった「意味のない作業」を「止める」ことから始めなければいけません。それにもまた、強い意志が必要なんですけどね。

2006年10月28日

SQL-DESIGNER

Web2.0ナビ: SQL-DESIGNERがスゴイ
WWW SQL Designer

DBのE-R図を作成し、SQL文を発行したり、XML形式でDB情報の書き出しができるWebベースのアプリです。

こういった類のソフトは、PCにインストールするタイプのものがいくつかありましたが、どれもライセンス料がそれなりにして、個人で使いたいときに二の足を踏んでしまってましたが、これなら無料で使えるようなので気軽に使うことができます。

また、PHPをダウンロードして、ローカル環境で動かすことも可能なようなので、Web上にDB情報を置くのは気が引けるという人も利用できそうです。

DBって、最初に設計した後、メンテナンスを繰り返していくに従って、ドキュメントに情報が反映されなかったり、ドキュメントのデグレが発生したりししがち。こうしたWebベースのアプリなら、複数人が同時に同じファイルを編集できるので、ドキュメントのデグレが発生する心配はなさそう。

MSSQLやMySQL、PostgreSQLには対応していますが、Oracle、DB2には対応していないですね。

対応するDBの種類が増えて、機能や性能などがもっと向上すれば、かなり使えるツールになりそうです。

以下のリンクで、Demoサイトに行くことができるので、使い勝手を試してみてはいかがでしょうか。

SQL Designer --- Demo

2006年10月27日

視力回復マッサージ

意外に効き目のある視力回復マッサージ

パソコンを使ってのデスクワークをしていると気になるのが視力低下です。

その昔、「ファミコンは1時間に10分休憩を入れましょう」と言われていましたが、仕事を始めてからはそんなルールを守れるはずもなく。プログラミングしているときは、何時間もモニターを見続けるなんて当たり前です。

それでも「目が疲れてきたなー」と感じるときは、目のマッサージをやってます。

リンク先で紹介されているマッサージは、僕も昔からやっているマッサージで、結構効き目があります。

あと僕がやっているのが、眼球の運動。

眼球を上下左右動かして、左回り右回りにぐりぐり動かします。この動きをやったあとは、眼球が疲れた感じがして、いかに普段眼球を動かしていないかが分かります。

パソコン仕事に従事している人は、こういうちょっとしたマッサージや運動を色々知っておくと、体調管理に役立つかも知れませんね。

2006年10月25日

くだらない会議の処方箋

ITmedia Biz.ID:第1回 会議の何が問題なのか?

記事中で挙げられている一般的な会議の問題が以下の4つ。

  • 会議が迷走する
  •  議論をしているうちに、そもそも議題が何であるのかが分からなくなり、やがて関係のない議題が絡まって、自分の話したいことを勝手に話し始めてしまいます。

  • 会議が決まらない
  •  結論があいまいで参加者の間でコンセンサスができていないために、次回の会議でまた同じ議題が取り上げられたり、認識の齟齬をめぐるトラブルが生じたりします。

  • 会議で決まったことが実行されない
  •  誰が誰にどのようなToDoを振ったのか、その期限がいつなのか、ということが明確にされないために、ToDoが実行されないままになり、次回の会議で同じようなToDoが再び発行されることになります。

  • 会議が長い
  •  会議が迷走したり、結論がなかなか出なかったりで、会議は予定時間を大幅に超えてしまいます。集中力がなくなるので、ますます会議の生産性が落ちてしまいます。

    どれも心当たりがあります。特に、3番目と4番目。

    3番目の「会議で決まったことが実行されない」というのは、会議の目的を「TODOを出すことだ」ということにこだわってしまうからかもしれません。

    ああだこうだ言い合って、頭が疲れてきた頃に、到底やれそうもないTODOを合意させられてしまい、結局できていない、とか。

    あと、会議が長いってのは、「15分で話をまとめて」と言っても、だらだら喋って時間をオーバーしてしまったりとか。何のための会議資料なのか分からなくなったり。

    そして恐ろしいのは、一回でもこういった会議を経験してしまうと、すっきりした会議をやったときに何か「物足りなさ」を感じてしまうというところにあります。

    「長いこと時間をかけてやる」=「建設的な意見が出る」と勘違いしてしまうんですよね。

    会議系の本や雑誌は何冊か読んでみましたが、なかなかこれというのがないですね。だからこそ、この連載には期待大です。

    まあ、会議に出席する全ての人が「この会議を有意義なものにしたい」と強く思わないかぎり、どんなメソッドを用いたとしても、会議が失敗する確率は高くなっちゃうのが現実なんですよね。

    2006年10月24日

    テストチームでリーダが心がけるべき10のポイント

    ウノウラボ Unoh Labs: チームリーダーが心掛けるべき10のポイント(テストチーム編)

    テストチームでリーダが心がけるべき10のポイントだそうです。

    1. 聞き上手になる
    2. 「おいしい仕事」を独り占めしない。
    3. 仕事に気分を持ち込まない。
    4. 日和見主義なくらいがよい。
    5. 人の能力を見抜き、適切に扱うよう努力する。
    6. 採用に参加し、信頼出来るメンバーを集める
    7. 仕事をさせるのではなく、仕事しやすい環境を作る
    8. 頑張らせ過ぎないように気をつける
    9. チームの結束を第一に考える。
    10. 常にマネジメントの手法について学ぶ姿勢を持つ。

    こうやって箇条書きにされて「お前できてるか?」と問われると、どきっとしますね。

    4とか得意なんですけどね。あ、こうやって得意と思っていることの方が危ないのかも。

    6とかは現実的に難しいですね。テストチームとして別働隊を作るだけでも結構大きな規模のプロジェクトになってしまい、そのチーム編成はお上の一存ということになりますから。

    5はかなり難しいなぁ。

    と、振り返るとなかなか出来ていないことばかりなのですが、実は今仕事がちょうどテストフェーズ。こういうことを少しでも取り入れて、良い結果を出さないとなぁ。

    2006年10月23日

    オフショア

    オフショア。中国やインド、ベトナムなどの海外の安い労働力を使ってシステムを作ることです。

    オフショア開発とは 【offshore development】 - 意味・解説 : IT用語辞典 e-Words

    昨今注目されているこの手法。もっぱら上位の経営陣やマネージャ層はオフショアを推進したがり、その下、現場で働くメンバーはオフショアを嫌がるという構図になりがちだとか。

    一時期は、言葉や労働に対する習慣の違いから、納期遅れや品質などでトラブルになりがちでした。

    最近はその傾向もややなくなり、大手SIerでは、「オフショアを考慮するのは当たり前」的な風潮すら見えてきています。

    僕個人としてはオフショアには断固反対。

    ちょっと前、製造業でやってしまった失敗を、システム業界もまた繰り返すつもりなのでしょうか。

    不当に安さだけを求める風潮が強まり、それに慌てた日本の製造業は、海外に工場を建てまくり、実際の製造を海外任せにするようになりました。その結果何が起こったか。安さだけを追求するがあまり、品質は二の次になり、日本人が得意としてた高品質なものを作れる人間が少なくなってしまいました。そればかかりか、技術が海外へ流出し、日本の工業製品を縁の下から支えていた中小企業は相次いで倒産。工業大国日本の名は廃れつつあります。

    近頃起きた、SONYの乾電池リコール騒ぎなど、まさしくこの現象の末期症状の一端が見えたに過ぎないのです。

    このままでは、システム作りでもきっと同じことが起きるでしょう。

    本来は、この流れを止め、システムは安さだけではないことをアピールし、顧客との信頼を勝ち取っていくよう指揮をとるべき会社の上の人々は、10年後のことなんか考えちゃいないんです。自分が定年退職をむかえるほんの少し先のことだけ見て、3、4年の「利益」「売上」だけを見ていけば良いわけですから。

    海外の技術者に負けないだけのスキルを身につけるか、それともこの業界からあっさり身を引くか。今まさに覚悟を決めて決断すべきときなんでしょうね。

    2006年9月23日

    上司への弱音の吐き方・伝え方

    ツライ!でも言えない!上司への弱音の吐き方・伝え方/Tech総研

    「仕事上の悩みを、上司や周りに相談することができますか?」というアンケートへの回答をまとめたものです。

    エンジニアたちは弱音を吐いているのだろうか? 上司、同僚を合わせると、弱音を吐いたことがある人は約7割。

    なかなか相談できないみたいですね。その理由としては、以下のものが挙げられるようです。

  • 弱音を吐いても無駄

  • プライドが許さない

  • 評価が下がる

  • 弱音を吐く人がいない
  • 「弱音を吐いても無駄」というのはよーく分かります。特に男性に多いんじゃないですかね。女性の場合、「泣いて」ストレスを発散するという術を上手く使える人が多いように思います。人前でなくても、トイレで一人泣き、とか。男性の場合は、それができないんですよね。不器用ですから(高倉健風)。感情をぐっと押し殺して、「仕方ない」と諦めてしまう人が多いように思います。

    でもって、弱音を吐いてみても、状況が変わったのは3割程度の人のみ。後はまったく変わらずというのですから、弱音の吐き甲斐がありません。

    難しいのは、「困ったり」「悩んだり」することの対象やレベルが、人によって大きく異なると言うこと。例えばもし、自分が相談される側の立場だったとき、「そんなことくらいで」と思って、そのまま「そんなことくらいでくよくよするなよ」と言っても、相手にとっては「そんなこと」のレベルではないわけです。

    相手の気持ちや立場になって、適切な態度が取れて、アドバイスができるようになりたいものです。

    2006年8月31日

    ホワイトカラー・エグゼンプション

    残業代なしでただ働きを強制される時代の到来 ~ ホワイトカラー・エグゼンプションって何? ~

    「ホワイトカラー・エグゼンプション」とは、ホワイトカラーを労働基準法の労働時間規制から除外する制度のことだそうで。

    ホワイトカラーは労働時間と非労働時間の境界があいまいなため、現在の労働基準法にはそぐわないと言うのがその理由。

    まあ確かに、残業が多いといっても、午前中や日中にだらだらと過ごして、夜に頑張るタイプの人も多いですし、ヘビースモーカーは「またタバコ行ってる」とあきれるくらい喫煙ルームに入り浸ってますから、この主張も分からなくはないです。

    ただ、「労働時間評価」の代わりになる「成果評価」の基準があいまいなままでは、サービス残業や無償の休日出勤が増えるだろうなぁと言うのが正直な感想。

    この「成果」に対する評価の課題がクリアされないままならば、日本でホワイトカラーになろうって人はいなくなっちゃうんじゃないですかね。それこそ、バイトで時間給で働いた方が、収入も読めるし、自分の時間の確保もまだ簡単になる気がします(バイトに追われてそれどころじゃないかもしれませんが)。

    最近、労働環境が改善されたうんぬんの記事を良く見かけますが、はっきりいってSIer業界ではそんなこと感じることができません。まるで異国のニュースのようですよ。

    今年の春頃、会社の就職試験のお手伝いをしましたが、学生さんから聞くにはやはりこの業界の人気はないようでした。このままでは、この業界に未来はなさそうです。

    2006年8月 8日

    洗う前に、わざと汚す

    百式 - 指示は明確に! (SquidSoap.com)

    ハンドソープの押すところにスタンプを付けて、手のひらについたスタンプを消さないとちゃんと洗ったことにならないという記事の紹介です。

    綺麗にするには、一旦汚して分かりやすくしてから、洗わせる。

    歯垢に色を付けてから歯磨きさせる赤いインクみたいなやつに似ている発想ですね。

    これをシステムにも応用できないかと。

    つまり、システム構築に参加していない人が、任意でバグを埋め込んで、それらのバグを「発見」して「修正」しなければシステムが完成したことにならないという仕組み。

    調べたら「ミューテーション・テスト」という名前でちゃんと存在するんですね。

    一度トライしてみたいですが、納期が迫ると真っ先にテストフェーズが削られる昨今のご時世だと厳しいかな。

    2006年8月 6日

    悪魔に心を売っても納期を守る!帳尻あわせの裏技術/Tech総研

    悪魔に心を売っても納期を守る!帳尻あわせの裏技術/Tech総研

    納期を守るための裏技(?)集です。

    「分割リリースにする」「正常系のテストしか行わない」「べた書きソース」と、デスマPJにありがちな項目がずらり。ニワトリと卵の話じゃありませんが、こんなことをするからデスマになるのか、デスマだからこうなるのか。

    僕は大手SI会社に勤めてるので、こういう現場をいくつか知ってます。僕の会社だけじゃなかったんだなぁと安心する反面、この状況をうまく回避する決定的な方法がないことに無力感を覚えたりも。

    2006年7月 8日

    レスポンス問題

    大量のデータを扱うシステム、利用者が大勢いるシステムに携わるとき、避けて通れないのが「レスポンス問題」です。

    僕も仕事柄何度かこの問題に直面したことがありますが、今はこのブログを書いている「ココログ」でユーザの側からレスポンス問題に直面しています。

    21時以降、とにかく管理画面に繋がらないのです。

    ココログのブログエンジンとなっているムーバブル・タイプの特長上、表示用のファイルはDBにアクセスせず、静的なHTMLを生成しているようなので、閲覧は問題なくできるのですが、記事の作成等を行う管理系の作業が、夜の時間帯だと全くできない状態なのです。

    これに対して、ココログを運営している@niftyは「ココログレスポンス問題お知らせブログ」というのを開設して、問題への対策を報知しているのですが、当然のようにユーザの怒りの声がコメント欄に集まっています。

    「なんとかしてください!」的なレベルのものから、「金を返せ!」「他のブログサービスに移る!」など多少過激な意見まで様々。ただ、@niftyに対して友好的なコメントはほとんどありません。

    というのも、このレスポンス問題が発生したちょっと前に、ココログがココログフリーという無料のブログサービスを開始して、@nifty会員でなくてもブログを開設できるようにしたのですが、フリー版の方が有料版より機能が上という訳の分からないサービスレベルになり、既存ユーザの信用をかなり落としてしまったのです。

    ちょうど僕も、有料版のココログプラスというサービスに切り替えたばかりだったので、内心ムッとしました。

    と、ここまで書いた時点で、そういえば前にも似たような記事を書いたことを思い出したので探してみました。

    ココログバージョンアップの障害

    3月末に書いてましたね。ということは、この問題、3ヶ月近くも長引いていることになります。うーん。ここまで対応が長引いてしまうと、もう二度と快適なレスポンスは得られないような気になってしまいますね。

    今度は2日間もサービスを停止してメンテナンス作業を行うことを報知しているので、なんとかそれで問題が解決することを祈っています。

    でぃべろっぱーず・さいど http://dev.chrisryu.com/ 鹿児島出身子持ちSEのディベロッパーとしての一面 ja Copyright 2013 Tue, 12 Feb 2008 20:10:09 +0900 http://www.sixapart.com/movabletype/ http://blogs.law.harvard.edu/tech/rss システム開発版ビフォー・アフター 全力でプログラマーを「人気の職業」に押し上げたい - Attribute=51

    • 顔や名前を出してもいいと思う人は、もっと出したらいいと思う。ハンドルネームでもいい。開発ブログと作ったアプリをリンクさせる。※これは結構やってる人がいる!ステキだ! でも足りない気もする。あと一押し欲しい。
    • Webサイトを立ち上げたら、「このサイトを作った人」というページを1枚作るべき。オレが知りたい。

    システム開発って建築によく例えられるけど、有名建築士が設計した建物とかは書籍にまとめられたりするのに、システム開発者はそういうのがないわけですよ。

    せめて、システム開発版「ビフォー・アフター」があっても良いじゃないかとか思ったりして。

    Case.1 問題だらけのシステム

    依頼人(以下、依) 「サイトのアクセス数が増えてきたのでそろそろサイトを作り替えようと思いまして」

    匠 「なるほど。どういうサイトに作り替えたいかというイメージはありますか?」

    依 「ぱっと、サイトを訪れた人が明るくなるような、夢のあるサイトにしたいです」

    匠 「分かりました。やってみましょう」

    ナレーション(以下、ナ) 「匠は、早速ソースコードを見てみることにしました」

    匠 「これは・・・酷いな・・・」

    ナ 「そこで匠が見たものは、バージョン管理されずただWindowsの共有フォルダに入れられているだけのソースコードでした」

    匠 「・・・Subversionを導入しましょう」

    ナ 「匠が取り寄せたのは、昨今バージョン管理ソフトウェアとして注目を浴びているSubversionでした」

    匠 「よし。これでバージョン管理はOKだな」

    ナ 「一安心してソースコードを眺める匠。しかし、そこにも大きな問題が」

    匠 「これは・・・セキュリティ対策が全然なされてない・・・」

    ナ 「なんということでしょう。今動いているシステムは、セキュリティ対策がまったく施されていなかったのです」

    匠 「Aさん、ちょっとこれ、見てよ。ここの入力フォームに、こうやって入力して、送信すると・・・」

    依 「あ!」

    ナ 「Aさんの目の前に現れたのは、画面いっぱいの顧客情報でした」

    匠 「これまでにハッキングされていないかどうか、チェックする必要がありますね・・・」

    (中略)

    ナ 「完成後、初めてサイトを訪れるAさん」

    依 「どきどきしますね(と、画面をクリック)。おお!」

    ナ 「Aさんの目の前に広がったのは、画面一面に広がった白。その真ん中に、ぽつんとたたずむ一組の入力フォーム。日本人のわびさびを表現した匠の傑作デザインです」

    依 「いやー、シンプルで美しいですねー」

    ナ 「ログインすると、一転、そこには極彩色の楽しげな商品一覧画面が広がります。Ajaxを駆使して動的で広がりのある一覧画面を表現しました。Ajaxで利用されているフレームワークは、匠の特注品です」

    依 「楽しいですねー」

    ナ 「時が経つのを忘れて夢中で一覧画面を眺めるAさん。今回のリニューアルには満足していただけたようです」

    依 「ほんと、匠にお願いして良かったです」

     

    こんな感じ。

     

    システム自体のビフォー・アフターじゃなくても、開発現場そのものに対してのビフォー・アフターでもおもしろいかも。

    Case.2 どんよりした開発現場

    依 「ほんと、困ってるんです」

    ナ 「今回の依頼者は、開発現場が暗くどんよりしていて、開発効率が上がらないと言うBさん」

    匠 「分かりました。お任せください」

    ナ 「早速開発現場に向かう匠」

    匠 「これは・・・酷いな・・・」

    ナ 「そこで匠が見たものは、目がどんよりと曇り、数日間入浴したようすもなく、黙々とモニタに向かってキーボードを打ち続ける開発者の姿でした」

    匠 「まずは、これを使いましょう」

    ナ 「匠が取り出したのは、カレンダーと赤・青・黄のシールでした。これを一体何に使うのでしょう」

    匠 「気分が良い日には青、普通の日は黄、悪い日には赤のシールを貼って帰ってください」

    ナ 「なんということでしょう。匠はカレンダーにシールを貼ることで、開発者の気持ちを可視化することに成功したのです」

    (中略)

    ナ 「改善後、初めて開発現場を訪れるBさん」

    依 「緊張しますね(ガチャ、とドアを開ける)。おお!」

    ナ 「扉を開けたBさんが見たものは、ミーティングスペースで立ち朝ミーティングを開いている開発者達でした。どの開発者も皆すっきりした顔をしています」

    開1 「じゃあ、このタスクを○さん、このタスクを×さん」

    ナ 「モニタに映し出されたプロジェクト管理ツールのタスクを適切に割り振る開発リーダー」

    開2 「了解。ぱぱーっと終わらせて、今日はさくっと飲みにいっちゃいますか」

    開3 「おー、いーねー」

    ナ 「なんと開発者達はタスクを適切に割り振り、定時に帰ることができるようになっていました。定時後にはみnなで飲みに行ける余裕まであります」

    依 「ここまで、変わるものなんですね」

    ナ 「こうしてまた、匠によって不毛な開発現場が一つ救われたのでした」

     

    なんか自分で書いていて見てみたくなったよ。

    ]]>
    http://dev.chrisryu.com/2008/02/before_after.html http://dev.chrisryu.com/2008/02/before_after.html システム開発 Tue, 12 Feb 2008 20:10:09 +0900
    関係者多数の開発でのソースコード管理とか情報共有とか デザイナが作成したHTMLファイルを、JSPなりrhtmlなりにプログラマが変換して、いざ画面を表示してみたらデザインが崩れてしまった、というのは昔からよくある話。

    これに加えて、デザインFIXのタイミングがプログラミング開始の後になってしまうとか、デザインFIX後も何らかの問題が生じてデザイン変更をお願いするも、デザイナがオリジナルのHTMLファイルを編集するから、変更点の反映が大変だとか、まあそんなこともよく言われてます。

    そういうのを受けて、JavaならTapestryとかWicketとか、テンプレートが.htmlという拡張子で終わるから、デザイナがオリジナルのファイルを普段使っているツールで開けるみたいなフレームワークが登場してきました(もちろんそれだけがうりじゃないですが)。

    先日、Wicket-jaの矢野さんにちょっと話を聞いたときは、Wicketは、イテレートでぐるぐる回すようなところも、デザイナが書いてきた部分は「サンプル」的な扱いにできて、そのまま残しておいても、Wicketのフレームワークと通してページ出力されるときは、その部分は無視されるとかできるそうで。

    それを聞いたときは「おー、便利便利!」とか思ったわけです。

    でもその便利さを、僕らSIerの開発の中で活かすためには、超えなきゃいけない壁が2つほどあります。

    1つは、デザイナさんにもバージョン管理システムを使ってもらうということ。

    いくらHTMLのテンプレートを直接利用できても、

    開発者「すみません、デザインのここを直して欲しいのですが」

    デザイナ「はーい。じゃあ、メールで送っておいてください」

    だと、結局修正後のファイルをいちいちdiffとって比較したりしなきゃいけないし、地味に面倒な作業になっちゃいます。

    こんなとき、デザイナさんが、

    「じゃあ、リポジトリからチェックアウトして修正しておきます」

    なんて言ってくれたら良いのにと。

    で、もう1つは、上にも関連する話ですが、ソース管理リポジトリをインターネットに公開できないかなぁと。

    まあ、インターネットに公開といっても、https通信、ID/Password認証、WebサーバでのIP制限等々セキュリティは万全にしてのことなのですが。

    SIerで大規模開発となると、結構パートナーさんに一括で持ち帰ってもらうというケースが最近増えてきてるんですよね。その方が、元請け的にも偽装請負の問題とかクリアになるし、パートナーさん的にも一括受託の方が利幅を多く取る余地ができて、お互いにメリットがあったりするわけです。とはいえ、そんなメリットがあっても、システム開発自体がうまく行かなければまったく意味がないわけで。

    個人的には、Redmineみたいなプロジェクト管理ツールやSVNを先に書いたように、セキュリティを万全にしてインターネットに公開して、そこを通じてパートナーさんとかデザイナさん、顧客等々と情報共有ができたらなぁと思っているわけです。

    プロジェクトの中で、意外と時間を取られるのが、MTGの準備だったりするわけで。いちいち、資料を「綺麗に」整えたり、紙を人数分印刷してホッチキス止めしたり、MTG資料を何度も印刷→レビュー→修正したり。この辺の作業が簡略化されて、MTGのときにはredmineのレポートの画面を見るとかしたら、良いのになぁと。

    もしかすると、他の会社だったらこういうこと普通にやられているのかもしれないですね。

    ]]>
    http://dev.chrisryu.com/2008/02/management_of_source_code_in_system_development.html http://dev.chrisryu.com/2008/02/management_of_source_code_in_system_development.html システム開発 Mon, 11 Feb 2008 18:48:54 +0900
    Think IT 連載第4回「バグ管理で陥りやすいワナ」公開 Think IT で連載している「バグ管理のノウハウ」の第4回が公開されました。

    第4回:バグ管理で陥りやすいワナ

    今回の内容は、バグ管理で陥りやすいシチュエーションについて書いています。

    書いていることは、結構あちこちの現場で起きていることだと思うんですが、どうでしょうか。

    メール、コメント等でフィードバックいただけると嬉しいです。

    【バグ管理の作法】バグ管理のノウハウ
    第1回:バグはなくならない?
    第2回:紙か? Wordか? Excelか? BTSか?
    第3回:バグの優先順位はこう付けろ!
    第4回:バグ管理で陥りやすいワナ
    ※第2回目以降が僕の担当です。


    普段、「プロジェクト管理」「テスト管理」という切り口で考えることはありましたが、「バグ管理」という切り口で考えることはなかったので、良い経験になりました。

    ]]>
    http://dev.chrisryu.com/2007/12/report_of_bug_management_part4_at_thinkit.html http://dev.chrisryu.com/2007/12/report_of_bug_management_part4_at_thinkit.html システム開発 Tue, 25 Dec 2007 21:23:35 +0900
    国内SIベンダーの強みを力説? 今度は住商情報システムさんですか。

    【IT Service Forum 2007】「摺り合わせ文化など日本には日本の良さがある」,国内SIベンダーの強みを力説:ITpro
    Matzにっき(2007-12-10)

    講演後半の日経BP社田中克己主任編集委員との対談では,「システム開発において日本のSIベンダーはインドのSEと戦えるのか」という問いに対して「(顧客企業の業務ノウハウに強いなど)日本独自の世界でなら,日本がインドに負けるわけがない」と断言。「シリコン・バレーと同じことをしていたら,日本は他国に勝てるわけがない。逆に,日本独自の世界でなら,他国に負けるわけがない」とした。

    ほんと? 本当にそう思ってます?

    「日本独自の世界でなら」って前提が、そもそもおかしくないっすか?逆に言うと、「日本独自の世界じゃなくなったら、日本がインドや他国に負けることもあり得る」って言ってるわけで。昨今の問題はその日本的な世界がなくなるんじゃないの?ってところに焦点があるんじゃないかなぁ。

    あと、SIer とかは「オフショア」言うて、他国のSEやプログラマに日本の仕事をやらせようとしてるわけで。なんかそういうことすることで、自ら墓穴を掘っていることに気が付かないのかなぁ。

    ]]>
    http://dev.chrisryu.com/2007/12/advantage_of_domestic_sier.html http://dev.chrisryu.com/2007/12/advantage_of_domestic_sier.html システム開発 Sun, 16 Dec 2007 21:31:46 +0900
    thinkITでバグ管理についての連載始まりました。 thinkITの今月の特集が「バグ管理の作法」なんですが、その中の「バグ管理のノウハウ」というコーナーで連載することになりました。

    全4回で、僕の担当は第2回~第4回。

    本日、第2回が公開されました。

    [Think IT] 第2回:紙か? Wordか? Excelか? BTSか?

    バグ管理の基本のキについて書いたつもりです。

    第3回では、バグ修正の優先順位の付け方について、第4回では、実際に遭遇したバグについて書くことになっています。

    メール、コメント等でフィードバックいただけると嬉しいです。

    文体が「だ・である調」なのは、第1回目がこの文体で書かれており、それに合わせる形となったためです。なんかキャラと合ってませんが、そこはスルーしてください。

    ]]>
    http://dev.chrisryu.com/2007/12/report_of_bug_management_at_thinkit.html http://dev.chrisryu.com/2007/12/report_of_bug_management_at_thinkit.html システム開発 Tue, 11 Dec 2007 12:45:30 +0900
    Re:「ワード・エクセルできます!」 はてな増田より。

    「ワード・エクセルできます!」

    1. セルの中で改行(スペースを大量に入れて調節するの禁止)
    2. 電話番号みたいに、0ではじまる数字を表示(頭に'付けるの禁止)
    3. 入力すべきセルに最初に色を付けておいて、何らかの数値が入ったらセルを白くする。値を検証して、矛盾するようなら赤くするとなおよし。
    4. A1に「=10/3」、B1に「=10/3」と入力されていて、C1に「=A1+B1」と入力されていたとき、C1に「7」と表示されても「あれ?」とか言わない。
    5. すでにできあがったシートがあるとき、「このシートでC列の値が最も高いもの」を探す方法が分かる。

    はてぶとか見てたら3が出来ない人結構いるみたいですね。

    僕なら「条件付き書式」使います。

    Excel で タスク管理シートを作る (でぃべろっぱーず・さいど)」とか「Excel でスケジュール管理 (でぃべろっぱーず・さいど)」で公開しているExcelは、この条件付き書式を使ってます。

    Excelってほんと不思議で、ctrl + C / X / P / Y とか使ってないひとが、複雑な関数でマニアックな業務処理の計算をしてたりするんですよね。その人の中ではそれが常識になっているから、普段の所作を見て、「この人Excel使えないんだろうなー」とか思って会話してると痛い目にあうことも。

    ちょっと複雑な計算とかになってきたら、Excelで関数やマクロ使うより、DBに入れてプログラムで処理した方が早いんじゃないかとか思ったり。

    ]]>
    http://dev.chrisryu.com/2007/12/re_i_can_use_excel.html http://dev.chrisryu.com/2007/12/re_i_can_use_excel.html システム開発 Mon, 03 Dec 2007 22:47:16 +0900
    SIerはもっとオープンソースに関わるべきだ NTTデータが自社のフレームワークをオープンソース化しました。

    NTTデータ、Javaや.NETのフレームワークをOSS化:ITpro

    NTTデータってSIerの業界(敢えてIT業界とは言いませんが)の中では、やっぱり巨人で、売上金額とか従業員数とか群を抜いているわけです。でまあ、お役所仕事的なところもあるのかなぁとか思っていたんですが、最近の流れにのってこういう手を打ってくるところはすごいなぁと素直に感心しちゃいます。

    普通のSIerならこういう「自社ノウハウ」的なものって外部に公開したがらないものなんですけどね。

    SIerも、もっとオープンソースコミュニティに積極的に参加していくべきですよね。

    strutsとか使って、自前のフレームワークを作っているところはたくさんあると思うんですけど、そういう閉じられたところにある技術って、外の空気に触れることでもっと良くなったりする可能性はあるわけで。

    国産ベンダが目覚める前にエンジニアの空洞化が始まる - @IT

    そのうえで、山野井氏は、優秀なエンジニアを日本につなぎとめるには「プロフェッショナルな人材の流動性を高める仕掛けが必要」と話した。優秀なエンジニアを正しく評価し、給与で優遇し、高い生産性を維持して働ける職場環境を用意することがポイント。エンジニアのコミュニティの中でその企業の評判が高まれば、優秀なエンジニアが集まり、面白いサービスが生まれる。エンジニアを単なる作業者と考える企業からは人材が流出するだろう。このエンジニアの自由な移動を実現するには流動性を高める仕掛けが必要というのだ。

    SIerが本気を出して、すげーおもしろい/良いフレームワークとかをオープンソースに提供しだしたら、そういうことをしている会社ってエンジニアにとって魅力的に見えると思うんだけどなぁ。

    SIerじゃないけど、Google には広告収入で得た利益を、オープンソースにどんどん還元していこうって雰囲気があるようだし(現にいくつもオープンソースプロダクトを発表してるし)、楽天も今後そういう風に動いていきたいと、この間のテクノロジーカンファレンスで言ってたし。

    まあ、3Kだなんだと言われている職場で、どこにオープンソースと関わる時間があるんだよと言われると、「スケジュール管理の問題」だから自分でなんとかして、としか言えないんだけどね。

    ]]>
    http://dev.chrisryu.com/2007/12/sier_have_to_concerned_with_opensource.html http://dev.chrisryu.com/2007/12/sier_have_to_concerned_with_opensource.html システム開発 Sat, 01 Dec 2007 23:56:57 +0900
    "社内"を捨てOSSへ Seaserの比嘉さんが情報処理推進機構(IPA)のイベント「IPAフォーラム2007」の中で行った「開発を夢のある仕事にするには」という講演の内容。

    上司に認めてもらえないエンジニアは“社内”を捨てOSSで行こう - ZDNet Japan

    自分で開発したアプリケーションサーバがネットで動いているのを見た感動した同氏は、会社の中でフレームワークを開発するようになり、会社の中で使ってもらうようにしている。しかし、開発したフレームワークに対する社内からの「反応がなかった。みんな意見は持っていたとは思うが、正面切って“こうした方がいい、こういう機能があればいい”と言われることがなかった」と寂しいものだったようだ。

    ひがさんと比べるのは恐縮ですが、この気持ち、超分かります。

    "社内"を捨てると言っても、会社を辞めるわけではないというところがポイントかな。

    会社の仕事をちゃんとした上で、そういう対外的な活動をすることで、会社にとっても自分にとってもメリットがある形が一番良い気がします。


    「エンジニアが自分の活動を認めてもらうには、社内に閉じこもっていては意味がない。社外で自分の存在価値を認めてもらうと、会社の中で働くことにも、“助け”となる」


    まさしく、これですね。


    まあ、この話、逆から見ると、社内の優秀な技術者の優秀な技術を社外へ出さず、自分の会社で囲い込みたいのであれば、その技術者が納得するだけの待遇を用意しろってことで。

    ]]>
    http://dev.chrisryu.com/2007/11/join_in_oss.html http://dev.chrisryu.com/2007/11/join_in_oss.html システム開発 Fri, 02 Nov 2007 21:55:56 +0900
    業界の重鎮が語るIT業界不人気の理由 IT業界不人気の理由は? 現役学生が語るそのネガティブイメージ - @IT

    IT業界の重鎮とは、自身ではメインフレーム開発しか行ったことがないというNTTデータ 取締役相談役で、情報サービス産業協会 会長の浜口友一氏と、TISの代表取締役社長 岡本晋氏だ。加えてIPA理事長の藤原武平太氏が答えた。


    さりげに自分の会社の社長がいたりする。

    学生達の意見は辛辣で、「トヨタ自動車やソニーのようなユーザー企業と違い、IT(の導入)しか行っていないNTTデータのような会社が一番謎」とか、「(情報を発信するテクノロジなのに)IT業界が何をしているのか分からないのは問題」とか。


    ネガティブイメージを突きつけられた浜口氏は、「必ずしも全員が3Kではない」と反論。

    この反論がちょっと笑える。

    「必ずしも~でない」ってことは、3Kの人も結構な割合でいるってことでは・・・。

    岡本氏も「3Kの“帰れない”は、帰りたくない人が帰れないだけ。スケジュール管理の問題だ。私は40年間近くIT業界で仕事しているが、何が一番幸せかというと退屈している暇がないことだ。技術が進歩するにつれわれわれの仕事も複雑化してくるが、一生懸命追いかけていくだけでも退屈しない。いい仕事を選んだと思う」と自らの仕事を振り返りつつ、学生に反論した。

    これは近年まれに見る酷い発言だと思う。↓はてぶでも結構やり玉に挙げられてたし。

    はてなブックマーク - IT業界不人気の理由は? 現役学生が語るそのネガティブイメージ - @IT

    帰りたくない人が帰れない「だけ」って・・・。

    あと、「技術が進歩するにつれわれわれの仕事も複雑化してくる」ってところも疑問。本当にそうですか? 本当に追いかけてますか?


    「工程ごとにいろんな呼称があるが、ITコーディネータやITアーキテクトなど、具体的に何をやっているのかさっぱり分からない。横文字だけが並ぶ」と、ITスキル標準をプロモートする重鎮を前に指摘した。

    僕も分からん!

    いや、分からないことはないけど、そういう呼称があるってだけで、仕事がその通りに分けられるわけでもないし。


    だが、学生たちは、コミュニケーション能力とは具体的にどういうことかと首をかしげる。学生の1人は「コミュニケーション能力の重要性は、就職活動をしているとどこの業種でもいわれること。だが、例えば、ドキュメント化能力のようにIT業界に限って必要な能力とは具体的に何か」と質問した。

    SI業界でなく、IT業界であるならば、パソコンが好きなことなんじゃないかと思う。たまに、パソコンは仕事でしか使わない人とかいるけど、そう言う人はこの業界向いてないんじゃないかなぁと密かに思っていたりします。といっても、そう言う人が活躍する場面ももちろんあるんだけど。


    Webサイトの記事ってことで、会場の雰囲気ややりとりの細かいニュアンスとか色々抜け落ちているんだろうから、あまりこの記事をもって、IT業界の重鎮達がこんなことを考えてるんだと決めつけない方が良いのかなと。(ここに書いてある発言が嘘でしたと言って欲しいという、願いも込めて)

    ]]>
    http://dev.chrisryu.com/2007/11/the_bosses_of_sier_talks_about_unpopularity_of_it_company.html http://dev.chrisryu.com/2007/11/the_bosses_of_sier_talks_about_unpopularity_of_it_company.html システム開発 Thu, 01 Nov 2007 21:59:47 +0900
    プログラミング工程を軽視するなかれ Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている

    同意する部分多し。

    「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月30万円というケースもあるという。

    これと似たような話を僕も経験したことがあって、SIerの知人に「僕は社内に実装を請け負う部門なりベンチャー子会社を作りたいです。」みたいなことを言ったら、「やったらいいじゃん。その代わりお前単価30万だぞ」みたいなことを言われたことあります。

    正直、はぁって感じでした。もの作りの工程がだいぶ軽視されているなぁと。

    「自分でプログラムを書かない上流のエンジニアが詳細設計書を作り、下流のエンジニアがコーディングをする」という工程そのものが、根本的に間違っているとしか思えないのだ。」

    やっぱりね、設計する人もプログラムを書けるべきですよ。

    上記引用のような構図はどう考えても間違っているし、気持ち悪いです。

    ]]>
    http://dev.chrisryu.com/2007/10/dont_brush_away_programming.html http://dev.chrisryu.com/2007/10/dont_brush_away_programming.html システム開発 Thu, 11 Oct 2007 23:46:05 +0900
    Excel でスケジュール管理 Excel で タスク管理シートを作る」に引き続きExcel シリーズ第2弾。

    Excel のシートでスケジュールを管理してみます。

    縦軸にタスク、横軸に日にちを取ったシンプルな作りですが、開始日・終了日を入力すると、前回紹介した「条件付き書式」を利用してスケジュールの線表っぽいものが書けます。


    excel_schedule_preview.png


    シートは2枚用意してあって、1枚目は予定の線だけですが、2枚目は実績の線も出るようになっています(その分若干もっさりしてますが)。

    こんなのはMS-PROJECT のお仕事だよ!という声も聞こえてきそうですが、小規模なプロジェクトならこっちの方がシンプルで簡単に管理できるかと。

    ↓ダウンロードはこちらから

    ファイルをダウンロード

    気が向いたらバージョンアップしていきますので、不具合・ご要望ありましたら、よろしくお願いいたします。

    ]]>
    http://dev.chrisryu.com/2007/09/manege_shedule_on_excel.html http://dev.chrisryu.com/2007/09/manege_shedule_on_excel.html システム開発 Thu, 20 Sep 2007 22:30:14 +0900
    情報処理技術者試験がてこ入れ 情報処理技術者試験がてこ入れされるみたいですね。

    「初級シスアド」消える――情報処理技術者試験が大改革へ - @IT

    会社からは試験受けろと言われているけれど、個人的に資格より優先させたいことがいくつかあるから、ついつい後回しになっちゃうんですよね。

    これを機に考えを改めるか。どうしようかな。

    新試験は最終決定をした後、平成20年度秋期にまずはエントリ試験を実施する。ただ、CBTではなくペーパー方式で実施。初級システムアドミニストレータ試験は実施しない。そのほかの試験は現行の試験制度で行う。全面的に新試験に移行するのは平成21年度春期からを予定している。

    ペーパー試験なのは変わらないんだー。

    論文書かせたりするのもよいけれど、鉛筆よりもキーボード使わせて欲しいな。

    試験対策で、あらかじめ書くことを決めて、当日は書くだけ、みたいなメソッドが紹介されているけれど、それはそれでどうなんだろ。

    ]]>
    http://dev.chrisryu.com/2007/09/change_the_exam_of_ipa.html http://dev.chrisryu.com/2007/09/change_the_exam_of_ipa.html システム開発 Fri, 07 Sep 2007 23:41:37 +0900
    アジャイルな環境作り アジャイルな環境作りについてのプレゼン資料が公開されています。

    masuidrive on rails ≫ Blog Archive ≫ アジャイルな環境作り - そんなに急いでどこへ行く


    アイデアとコーディングの間に立ちふさがる「テンション」という高い壁は、確かに存在しますね。

    何か作ろうと思っても、あれもしなきゃ、これもしなきゃ・・・。確かに面倒です。

    格安レンタルサーバはいっぱいあるし、ネットワーク環境も日本は世界一だって話ですから、気軽に色々試している人がもっといても良いと思うんですが、なかなか。

    スクリプト組んで、自動でなんでもできるようになるってのは素敵ですね。

    やっぱ自由に使えるレンタルサーバがもっと増えて欲しいなぁ。

    Perl や PHP だけじゃなく RoRも動いて欲しいし、もっと言えば Java のサーバサイドアプリが動作する環境が欲しいですね。

    ]]>
    http://dev.chrisryu.com/2007/09/make_environment_for_agile.html http://dev.chrisryu.com/2007/09/make_environment_for_agile.html システム開発 Wed, 05 Sep 2007 23:05:45 +0900
    ソフトウェアは無料か有料か 37Signals は、ソフトウェアを無料で提供してもビジネスとして成功できるという意見の持ち主を批判しているそうです。

    TechCrunch Japanese アーカイブ ≫ 37Signals、他社をDeadPoolに追い込む

    もし、自作ソフトウェアを有料でリリースできる立場にあり、それに、市場を独占するつもりがないのなら、もちろん有料化にすれば良いと思う。しかし、ソフトウェア制作に時間と労力を注いだからという理由だけで、「ソフトは有料でなければダメだ」というアイディアをむやみと信じて、ビジネスモデルを決定すべきではない。そして、すでにコモディティ化につれて無料化が進んだビジネス分野(ここで指すのはオンラインフィードリーダー市場)に有料サービスとして参入しようというのは、正気の沙汰ではない。


    世間的にそういう無料のビジネスモデル流行っているから、「無料で提供しよう」なんて思っちゃいけないわけですよね。

    世の中で当たっているサービスは、皆それなりにしっかりとした戦略とコンセプトに基づいて作られているわけで。いやね、たまに「まぐれで当たった」とか「たまたまヒットした」とかいうものを聞きますけど、それはあくまでもイレギュラーケースであるからこそ、ニュースになるわけで。

    サービスに必要なのは、しっかりとしたビジネスモデルと、確固たるコンセプトだと、僕は思っています。

    まあ、偉そうに言っておきながら、そういうサービスを運営したことはないんですけどね。

    ]]>
    http://dev.chrisryu.com/2007/08/software_is_free_or_not_free.html http://dev.chrisryu.com/2007/08/software_is_free_or_not_free.html システム開発 Wed, 15 Aug 2007 22:31:06 +0900
    IT技術者は仕事に対する満足度が低いのだとか。 IT技術者は仕事に対する満足度が低いのだそうです。

    「IT技術者は仕事に対する満足度が低い」--英大学調査:ニュース - CNET Japan

    今回の調査では、4万ポンド(約960万円)以上の年収は、通常、仕事に対する満足度の向上に大きなプラス効果をもたらすことが分かった。それにも関わらず、高収入のIT労働者らは自分たちの仕事に満足していないようだ。

    なんなんでしょうね。分かるような分からないような。

    そういえば、@ITには↓こんな記事が出ていました。

    Googleは人材を飲み込むブラックホールか - @IT

    この中で、

    フリーソフトウェアや、日本のいわゆるフリーウェアといった趣味のプログラミング活動は、昼間の仕事に対する不満が原動力になっている、というのだ。例えば、本職では好きでもないプログラミング言語を使って、特におもしろくはないシステムを粛々と作るばかりで、ワクワクするような、知的好奇心を満たすチャレンジが何もないという状況が考えられる。自分の仕事はシステムの一部の歯車でしかないということもあるだろう。そうした不満があるから、たとえ残業して遅く帰ってとしても、夜更けまで趣味のプログラミングに打ち込むことができる。

    こんなこと言われているわけです。

    うちに帰ってからも、趣味グラミングしている僕としては、半分はうなずける内容ですね。

    一生懸命最新の技術動向を追っても、なかなか仕事の中で使う機械がないというのは良くあることで。

    逆に、仕事に不満を持っている人(満足していない人)は、どうなったら満足する状態になるんでしょうか。

    お金がたくさんもらえるれば良いのか、それとも、最新の技術を使って刺激的なシステムを作れれば良いのか、納期に追われずゆったりとシステムを作れれば良いのか。

    僕は、プライベートの時間がしっかりと確保できるのであれば、ある程度の仕事で十分満足できるような気がします。裏を返せば、そういうプロジェクトはなかなかなく、デスマーチがいたるところに転がっているってことなんですけど。

    ]]>
    http://dev.chrisryu.com/2007/08/it_engineer_dosenot_satisfy_own_work.html http://dev.chrisryu.com/2007/08/it_engineer_dosenot_satisfy_own_work.html システム開発 Tue, 07 Aug 2007 21:33:25 +0900
    でぃべろっぱーず・さいど: アーカイブ

    アーカイブ

    /* Base Weblog (base-weblog.css) */ /* basic elements */ html { margin: 0; /* setting border: 0 hoses ie6 win window inner well border */ padding: 0; } body { margin: 0; /* setting border: 0 hoses ie5 win window inner well border */ padding: 0; font-family: verdana, 'trebuchet ms', sans-serif; font-size: 12px; } form { margin: 0; padding: 0; } a { text-decoration: underline; } a img { border: 0; } h1, h2, h3, h4, h5, h6 { font-weight: normal; } h1, h2, h3, h4, h5, h6, p, ol, ul, pre, blockquote { margin-top: 10px; margin-bottom: 10px; } /* standard helper classes */ .clr { clear: both; overflow: hidden; width: 1px; height: 1px; margin: 0 -1px -1px 0; border: 0; padding: 0; font-size: 0; line-height: 0; } /* .pkg class wraps enclosing block element around inner floated elements */ .pkg:after { content: " "; display: block; visibility: hidden; clear: both; height: 0.1px; font-size: 0.1em; line-height: 0; } * html .pkg { display: inline-block; } /* no ie mac \*/ * html .pkg { height: 1%; } .pkg { display: block; } /* */ /* page layout */ body { text-align: center; } /* center on ie */ #container { position: relative; margin: 0 auto; /* center on everything else */ width: 720px; text-align: left; } #container-inner { position: static; width: auto; } #banner { position: relative; } #banner-inner { position: static; } #pagebody { position: relative; width: 100%; } #pagebody-inner { position: static; width: 100%; } #alpha, #beta, #gamma, #delta { display: inline; /* ie win bugfix */ position: relative; float: left; min-height: 1px; } #delta { float: right; } #alpha-inner, #beta-inner, #gamma-inner, #delta-inner { position: static; } /* banner user/photo */ .banner-user { float: left; overflow: hidden; width: 64px; margin: 0 15px 0 0; border: 0; padding: 0; text-align: center; } .banner-user-photo { display: block; margin: 0 0 2px 0; border: 0; padding: 0; background-position: center center; background-repeat: no-repeat; text-decoration: none !important; } .banner-user-photo img { width: 64px; height: auto; margin: 0; border: 0; padding: 0; } /* content */ .content-nav { margin: 10px; text-align: center; } .date-header, .entry-content { position: static; clear: both; } .entry, .trackbacks, .comments, .archive { position: static; overflow: hidden; clear: both; width: 100%; margin-bottom: 20px; } .entry-content, .trackbacks-info, .trackback-content, .comment-content, .comments-open-content, .comments-closed { clear: both; } .entry-excerpt, .entry-body, .entry-more-link, .entry-more { clear: both; } .entry-footer, .trackback-footer, .comment-footer, .comments-open-footer, .archive-content { clear: both; margin: 5px 10px 20px 10px; } .comments-open label { display: block; } #comment-author, #comment-email, #comment-url, #comment-text { width: 240px; } #comment-bake-cookie { margin-left: 0; vertical-align: middle; } .comments-open-header { clear: both; } #comment-post { font-weight: bold; } img.image-full { width: 100%; } .image-thumbnail { float: left; width: 115px; margin: 0 10px 10px 0; } .image-thumbnail img { width: 115px; height: 115px; margin: 0 0 2px 0; } /* modules */ .module { position: relative; overflow: hidden; width: 100%; } .module-content { position: relative; margin: 5px 10px 20px 10px; } .module-list, .archive-list { margin: 0; padding: 0; list-style: none; } .module-list-item { margin-top: 5px; margin-bottom: 5px; } .module-presence img { vertical-align: middle; } .module-powered .module-content { margin-bottom: 10px; } .module-photo .module-content { text-align: center; } .module-wishlist .module-content { text-align: center; } .module-calendar .module-content table { border-collapse: collapse; } .module-calendar .module-content th, .module-calendar .module-content td { width: 14%; text-align: center; } .typelist-thumbnailed { margin: 0 0 20px 0; } .typelist-thumbnailed .module-list-item { display: block; clear: both; margin: 0; } /* positioniseverything.net/easyclearing.html */ .typelist-thumbnailed .module-list-item:after { content: " "; display: block; visibility: hidden; clear: both; height: 0.1px; font-size: 0.1em; line-height: 0; } * html .typelist-thumbnailed .module-list-item { display: inline-block; } /* no ie mac \*/ * html .typelist-thumbnailed .module-list-item { height: 1%; } .typelist-thumbnailed .module-list-item { display: block; } /* */ .typelist-thumbnail { float: left; min-width: 60px; width: 60px; /* no ie mac \*/width: auto;/* */ margin: 0 5px 0 0; text-align: center; vertical-align: middle; } .typelist-thumbnail img { margin: 5px; } .module-galleries .typelist-thumbnail img { width: 50px; } .typelist-description { margin: 0; padding: 5px; } .module-featured-photo .module-content, .module-photo .module-content { margin: 0; } .module-featured-photo img { width: 100%; } .module-recent-photos { margin: 0 0 15px 0; } .module-recent-photos .module-content { margin: 0; } .module-recent-photos .module-list { display: block; height: 1%; margin: 0; border: 0; padding: 0; list-style: none; } /* positioniseverything.net/easyclearing.html */ .module-recent-photos .module-list:after { content: " "; display: block; visibility: hidden; clear: both; height: 0.1px; font-size: 0.1em; line-height: 0; } * html .module-recent-photos .module-list { display: inline-block; } /* no ie mac \*/ * html .module-recent-photos .module-list { height: 1%; } .module-recent-photos .module-list { display: block; } /* */ .module-recent-photos .module-list-item { display: block; float: left; /* ie win fix \*/ height: 1%; /**/ margin: 0; border: 0; padding: 0; } .module-recent-photos .module-list-item a { display: block; margin: 0; border: 0; padding: 0; } .module-recent-photos .module-list-item img { width: 60px; height: 60px; margin: 0; padding: 0; } /* mmt calendar */ .module-mmt-calendar { margin-bottom: 15px; } .module-mmt-calendar .module-content { margin: 0; } .module-mmt-calendar .module-header { margin: 0; } .module-mmt-calendar .module-header a { text-decoration: none; } .module-mmt-calendar table { width: 100%; } .module-mmt-calendar th { text-align: left; } .module-mmt-calendar td { width: 14%; height: 75px; text-align: left; vertical-align: top; } .day-photo { width: 54px; height: 54px; } .day-photo a { display: block; } .day-photo a img { width: 50px; height: 50px; } /* Vicksburg II (theme-vicksburg.css) */ /* basic page elements */ body { font-family: 'trebuchet ms', verdana, helvetica, arial, sans-serif; font-size: 12px; } a { color: #666666; text-decoration: underline; } a:hover { color: #66cc33; } #banner a { color: #fff; text-decoration: none; } #banner a:hover { color: #fff; } .module-content a { color: #666666; } .module-content a:hover { color: #66cc33; } h1, h2, h3, h4, h5, h6 { font-family: 'trebuchet ms', verdana, helvetica, arial, sans-serif; } .module-header, .trackbacks-header, .comments-header, .comments-open-header, .archive-header { color: #000000; font-family: 'Trebuchet MS', Verdana, sans-serif; font-size: x-small; border-bottom: 1px dashed #999999; text-align: left; font-weight: bold; text-transform: uppercase; padding: 3px; letter-spacing: .3em; } .module-header a, .module-header a:hover, .trackbacks-header a, .trackbacks-header a:hover, .comments-header a, .comments-header a:hover, .comments-open-header a, .comments-open-header a:hover .archive-header a, .archive-header a:hover { color: #fff; } .entry-more-link, .entry-footer, .comment-footer, .trackback-footer, .typelist-thumbnailed { font-size: 11px; } .commenter-profile img { vertical-align: middle; } /* page layout */ body { min-width: 720px; color: #333; background: #FFFFFF; } #container { width: 720px; margin-bottom: 20px; background: #fff; } #container-inner { border-width: 0 5px 5px 5px; border-style: solid; border-color: #FFFFFF; } #banner { width: 710px; /* necessary for ie win */ background: #66cc33; } #banner-inner { padding: 15px 13px; border-width: 0px 0px 0 0px; border-style: solid; border-color: #fff; } .banner-user { width: 70px; margin-top: 5px; font-size: 10px; } .banner-user-photo { border: 1px solid #fff; } #banner-header { margin: 0; color: #fff; font-size: 30px; font-weight: bold; line-height: 1; text-shadow: #666666 0 2px 3px; } #banner-description { margin-top: 5px; margin-bottom: 0; color: #fff; background: none; font-size: 12px; line-height: 1.125; text-shadow: #666666 0 1px 2px; } #alpha { margin: 15px 15px 0 15px; width: 480px; } #beta { width: 200px; background: #e6ecf2; } #gamma, #delta { width: 180px; background: #dddddd; } #beta-inner, #gamma-inner, #delta-inner { padding: 10px 10px 0 10px; border-width: 0px 0px 0px 0; border-style: solid; border-color: #fff; } .date-header { margin-top: 0; font-size: 11px; font-weight: bold; text-transform: uppercase; } .entry-header { margin-top: 0; border-left: 5px solid #66CC33; padding: 0 0 0 10px; color: #000000; font-size: 18px; font-weight: bold; } .entry-content, .comment-content, .trackback-content { margin: 0; line-height: 1.5; } .entry-tags { margin: 0 0 10px 10px; } .entry-tags-header, .entry-tags-list, .entry-tag { display: inline; } .entry-tags-list { list-style:none; padding: 0px; } .entry-footer, .comment-footer, .trackback-footer { margin: 0 0 20px 0; border-top: 1px solid #DDDDDD; padding-top: 3px; color: #666; font-size: 10px; text-align: right; } .comment-content, .trackback-content, .comment-footer, .trackback-footer { margin-left: 10px; } .content-nav { margin-top: 0; } #trackbacks-info { margin: 10px 0; border: 1px dashed #66cc33; padding: 0 10px; color: #292e33; font-size: 11px; text-align: center; background: #dddddd; } .comments-open-footer { margin: 10px 0; } /* modules */ .module { margin: 0 0 10px 0; border-bottom: 1px solid #f3f6f9; background: #DDDDDD; } .module-content { margin: 0 0 10px 0; padding: 10px 10px 0 10px; font-size: 10px; line-height: 1.2; } .module-search input { font-size: 10px; } .module-search #search { width: 100px; } .module-mmt-calendar .module-content table, .module-calendar .module-content table { font-size: 10px; } .module-powered { border-width: 0; } .module-powered .module-content { margin-bottom: 0; border: 1px dashed #66cc33; padding-bottom: 10px; color: #292e33; background: #fff; } .module-photo { background: none; } .module-photo img { border: solid 1px #fff; } .module-list { margin: 0 15px 10px 15px; list-style: disc; } .module-list .module-list { margin: 5px 0 0 0; padding-left: 15px; list-style: circle; } .module-list-item { margin-top: 0; color: #666; line-height: 1.2; } .typelist-thumbnailed .module-list { margin: 0 0 10px 0; list-style: none; } .typelist-thumbnailed .module-list-item { margin: 1px 0; padding: 0; background: #f3f6f9; } .typelist-thumbnail { background: #fff; } .module-photo img { border: 1px solid #fff; } .module-featured-photo { width: 398px; } .module-featured-photo .module-content { margin: 0; border-width: 0; padding: 0; } .module-featured-photo img { width: 398px; } .module-recent-photos .module-content { padding: 10px 0 0 19px; } .module-recent-photos .module-list { margin: 0; } .module-recent-photos .module-list-item { width: 64px; /* mac ie fix */ margin: 0 10px 10px 0; padding: 0; background: none; } .module-recent-photos .module-list-item a { border: #cfd4d9 1px solid; padding: 1px; background: #fff; } .module-recent-photos .module-list-item a:hover { border-color: #666666; background: #fff; } .module-tagcloud .module-list {text-align: center; } .module-tagcloud .module-list { list-style: none; } .module-tagcloud .module-list-item { display: inline; } .module-tagcloud li.taglevel1 { font-size: 19px; } .module-tagcloud li.taglevel2 { font-size: 17px; } .module-tagcloud li.taglevel3 { font-size: 15px; } .module-tagcloud li.taglevel4 { font-size: 13px; } .module-tagcloud li.taglevel5 { font-size: 11px; } .module-tagcloud li.taglevel6 { font-size: 9px; } /* calendar tweaks */ .layout-calendar #alpha { width: 260px; } .layout-calendar #beta { width: 420px; } .layout-calendar #gamma, .layout-calendar #delta { width: 190px; } .layout-calendar #gamma-inner, .layout-calendar #delta-inner { border: 0; padding: 0; } .module-mmt-calendar { width: 398px; } .module-mmt-calendar .module-content { margin: 0; border-width: 0; padding: 10px; } .module-mmt-calendar table { width: 378px; background: #66cc33; } .module-mmt-calendar th { color: #fff; border-top: 1px solid #fff; border-right: 1px solid #f3f6f9; border-bottom: 1px solid #cfd4d9; padding: 2px; text-align: right; font-weight: bold; } .module-mmt-calendar td { border-top: 1px solid #fff; border-right: 1px solid #f3f6f9; border-bottom: 1px solid #cfd4d9; padding: 2px; text-align: right; font-weight: normal; background: #dddddd; } th.weekday-7, td.day-7, td.day-14, td.day-21, td.day-28, td.day-35, td.day-42 { border-right: none; } .module-mmt-calendar td { height: 70px; } .day-photo { width: 49px; height: 49px; } .day-photo a { border: #cfd4d9 1px solid; padding: 1px; background: #fff; } .day-photo a:hover { border-color: #666666; background: #fff; } .day-photo a img { width: 45px; height: 45px; } /* artistic tweaks */ .layout-artistic #alpha { width: 260px; } .layout-artistic #beta { width: 420px; } .layout-artistic #gamma, .layout-artistic #delta { width: 190px; } .layout-artistic #gamma-inner, .layout-artistic #delta-inner { border: 0; padding: 0; } /* moblog1 tweaks */ .layout-moblog1 #alpha { margin: 0; width: 180px; background: #dddddd; } .layout-moblog1 #alpha-inner { padding: 10px 10px 0 10px; border-width: 0px 0 0px 0px; border-style: solid; border-color: #fff; } .layout-moblog1 #beta { margin: 15px 15px 0 15px; width: 320px; background: none; } .layout-moblog1 #beta-inner { padding: 0; border-width: 0; } .layout-moblog1 .module-recent-photos .module-content { padding: 10px 0 0 10px; } /* moblog2 tweaks */ .layout-moblog2 #alpha { margin: 0; width: 86px; background: #dddddd; } .layout-moblog2 #alpha-inner { padding: 10px 10px 0 10px; border-width: 0px 0 0px 0px; border-style: solid; border-color: #fff; } .layout-moblog2 #beta { margin: 15px 15px 0 15px; width: 260px; background: none; } .layout-moblog2 #beta-inner { padding: 0; border-width: 0; } .layout-moblog2 #delta { width: 154px; } .layout-moblog2 .module-recent-photos { border: 0; background: none; } .layout-moblog2 .module-recent-photos .module-content { padding: 0; border: 0; } .layout-moblog2 .module-recent-photos .module-list-item { margin: 0 0 10px 0; } /* timeline tweaks */ .layout-timeline #alpha { width: 260px; } .layout-timeline #beta { width: 420px; } .layout-timeline #gamma, .layout-timeline #delta { width: 190px; } .layout-timeline #gamma-inner, .layout-timeline #delta-inner { border: 0; padding: 0; } /* one-column tweaks */ .layout-one-column body { min-width: 520px; } .layout-one-column #container { width: 520px; } .layout-one-column #banner { width: 510px; } /* necessary for ie win */ /* two-column-left tweaks */ .layout-two-column-left #alpha { margin: 0; width: 200px; background: #dddddd; } .layout-two-column-left #alpha-inner { padding: 10px 10px 0 10px; border-width: 0px 0 0px 0px; border-style: solid; border-color: #fff; } .layout-two-column-left #beta { margin: 15px 15px 0 15px; width: 480px; background: none; } .layout-two-column-left #beta-inner { padding: 0; border-width: 0; } /* three-column tweaks */ .layout-three-column #alpha { margin: 0; width: 180px; background: #DDDDDD; } .layout-three-column #alpha-inner { padding: 10px 10px 0 10px; border-width: 0px 0 0px 0px; border-style: solid; border-color: #fff; } .layout-three-column #beta { margin: 15px 15px 0 15px; width: 320px; background: none; } .layout-three-column #beta-inner { padding: 0; border-width: 0; } /* * Preliminary styles added by Jay for Vicksburg II * for review by Luke/Walt and rest of team */ /* All or multiple templates Suppress underlines on linked entry titles */ .entry-header a { text-decoration: none; } /* Suppress the prev/next nav */ .content-nav { margin: 0px; display: none; } /* Search results templates */ .mt-search-results .search-results-header { border: 2px solid #669; background-color: #666666; color: #eee; padding: 5px; } .mt-search-results .search-results-container { margin-left:10px; } .mt-search-results form#search-form { width: 400px; margin: 0px auto 20px auto; } .mt-search-results form#search-form input#search { width: 80%; } .mt-search-results form#search-form p#search-options { text-align:center; } /* Entry tag display */ div.entry-tags { margin:0 0 10px 10px; } ul.entry-tags-list { list-style:none; padding: 0px; } h4.entry-tags-header, ul.entry-tags-list, li.entry-tag { display: inline; } /* Main index styles Suppress date header on main index */ .main-index .date-header { display: none; } /* Comment preview and individual entry Widen the comment form */ form textarea#comment-text { width:400px; } /* All archive templates Informational "where am I?" module at top of sidebar */ .module-welcome p { font-size: 12px; } .module-content p.first { margin-top:0px; } /* Date-based and category archives Archive title banner at top of page, below blog banner */ .master-archive-index #archive-title, .individual-entry-archive #archive-title, .date-based-archive #archive-title, .category-archive #archive-title { /* ie win (5, 5.5, 6) bugfix */ p\osition: relative; width: 100%; w\idth: auto; margin: 0; border-left: 10px solid #66cc33; padding: 5px; color: #fff; background: #666666; } /* Experimental comment styles Not currently in use anywhere in default templates For testing only... */ #comments-experimental .comment, #comments-experimental .comment .comment-inner { width:36em; } #comments-experimental .comment { padding: 0px; margin: 10px 15px; background-color:#eef; border:2px solid #bbb; } #comments-experimental .comment .comment-inner { position:relative; margin:-5px 0 0 -3px; background:#f3f3ff; border:1px solid #003; } #comments-experimental .comment:hover .comment-inner { border:1px solid #000; background-color: #fff; } #comments-experimental .comment a { text-decoration: none; border-bottom: 1px dotted #666666; } #comments-experimental .comment:hover a { color: #333; border-bottom: 1px solid #666; } #comments-experimental .comment .comment-footer, #comments-experimental .comment .comment-content { margin-right: 25px; margin-left: 25px; margin-bottom: 15px; } #comments-experimental .comment .comment-header { font-size: 16px; margin: 5px auto 5px 10px; text-shadow: #99A 2px 2px 1px #66F; color: #666; } #comments .comment-header { display: none; } #comments .comment-footer-experimental { display: none; } #comments-experimental .comment-footer { display: none; } でぃべろっぱーず・さいど: コメントの保留

    コメントを受け付けました。

    コメントを受け付けました。受け付けたコメントは、ブログの管理者の承認のため保留されています。

    エントリーのページに戻る