メイン

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

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

アーカイブ