「新しいカテゴリのソフトウエアとして位置付け，英語で情報発信して世界への普及を狙う」---ひがやすを氏は2008年5月24日開催されたSeasar Conference 2008 Springで新フレームワーク「Slim（Simple, Less is More）」を発表した。 Slimは，ひが氏が開発したJavaフレームワークSeasar2の機能を絞り込んでシンプルにし，習得しやすくしたものだ。Seasar2はDI（Dependncy Injection）コンテナと呼ばれることが多かったが，DIコンテナとしては海外ではSpringが普及している。Seasar2の特徴であるホットデプロイ（Webアプリケーション・サーバーを再起動することなくプログラムの修正を反映できる）機能を前面に押し出し「ホットデプロイ可能なフルスタック・フレームワーク」という，Javaでアジャイル（俊敏）な開発を行うた

私は，2007年2月2日付の記者の眼「『使えない人間』などいない」で「Java初心者で構成されるチームがいかにプロジェクトを完遂したか，という事例」があり，その事例を取材したうえで，日経ソフトウエア2007年5月号のJava特集でレポートすると書いた。その号がいよいよ明日（3月24日），発売される。特集のルポ「Java初心者のチームが挑む基幹系刷新プロジェクト」という記事である。 具体的には，群馬県内の各JAやJA関連組織のIT共同利用施設であるJA群馬電算センターが提供しているシステムの事例だ。Javaをほとんど知らなかった4人のメンバー，JA群馬電算センター 経済情報部の片野富久氏，前原貴美子氏，大久保浩治氏，渋谷知央氏が，基幹系システムの刷新プロジェクトに先立つパイロット・プロジェクトを成功させた，というものである。 もっとも，取材を終えた今では，この事例を「『使えない人間』などいな

落ちないシステムなどない----。ITプロフェッショナルにとっては当たり前だ。冗長化していても「RAIDのコントローラそのものが故障してデータ復旧に2日徹夜した」などと目も当てられない話も聞こえてくる。要件のあやふやさやテスト不足によるバグも無くなりはしない。だが，ITプロフェッショナルはこの本音を“タブー”としてひた隠しにしている。 あるユーザー企業で基幹システムを担当する情報システム部長は口にする。「利用部門は100％の稼働率を前提にしている。だが現実としてコストも限られている。100％の稼働率を保証するのは無理で，落ちないシステムなどない」。部長は続ける。「稼働率では利用部門と話せない。落ちるのは確率の問題で，例えば『今後3年の間のどこかで5時間ダウンするかもしれませんし，しないかもしれません』と利用部門に説明したところで『困る。どうにかしてくれ』の一言が返ってくるだけ。我々は100

新会社法，個人情報保護法など新しい法律が相次いで施行されています。このコラムでは，様々な法律の解釈とともに，これらの法律が企業にもたらすリスクを解説していきます。 特定電子メール法の改正 ［1］オプトイン方式による規制を導入 ［2］オプトイン方式で送信者に義務付けられた運用ルール ［3］情報提供を求める規定や罰則の強化で実効性を高める 日本版フェアユース規定の導入 ［1］現行の著作権法では技術の進展に追随できない ［2］判例で拡大される米国著作権法における適用範囲 ［3］英国のフェアディーリングによる権利制限規定 ［4］権利者側はフリーユース正当化と負担増大を警戒 ヤフーオークションサイトの損害賠償訴訟 ［1］場の提供者に一定の注意義務を認める ［2］具体的な注意義務を費用対効果で判断 デジタルコンテンツと肖像権・パブリシティ権 （1）ネットのコンテンツ・サービスで避けて通れない （2）保

チェンジビジョン社の設計支援ツール，JUDEの開発は，日本と中国での分散開発で行われている，いわゆるオフショア開発である。 私は，現在日本が行っている典型的なオフショア開発には，大きな問題があると考えている。それは「日本が上流」「中国が下流」というわけ方であったり，「いちども顔を合わせたことのない人がメールと仕様書のやり取りをしている」というコミュニケーションの仕方だったりする。 私たちは，2002年から様々な開発手法，コラボレーション手法を試してきた。やり方を変えながら，改善してきたのだが，大きくコミュニケーションが変わったのは，ある日本在住の中国出身技術者が，チームに偶然加わったことだ。それが，この連載の著者，周翼（しゅうよく：周が苗字，翼が名前）である。 もともと，私たちは英語とUMLを使った図，そしてコード自身で会話しており，いわゆる「ブリッジSE」と呼ばれるような，中国語と日本語

他人とのコミュニケーションでは、時として「言いにくい」ことを伝える必要性も生じます。仕事をするうえでも、上司と部下、同僚同士で、相手の心証を害する可能性が高いことを言わなくてはいけない場面が多々あります。年功序列が前提で、上意下達型のコミュニケーションが主流だった従来の日本企業に比べ、「自分より年上の部下がいる」「プロジェクト型組織で指揮命令形態がはっきりしない」など複雑さが増した今日の企業組織では、コミュニケーションがより難しくなっています。 こうした課題を解決する解の1つが「アサーティブ・コミュニケーション」です。アサーティブは「自己主張が強い」ことを意味しますが、自分の要求を高圧的に押し付けることではありません。自分の思いを率直に伝えながら、相手の心証にも気を配り、人間関係をいたずらに損なうことなく目的を達成するための会話術といえるでしょう。発祥は1960年代の米国といわれ、有色民族

ITコンサルタントの草分けG.M.ワインバーグが，納期遅延について面白いことを言っている。すなわち「遅延は1日ずつ生じる」と。システム構築プロジェクトでは，その日に済ませたいことをその日のうちに済ませることができない，ということがよく起きる。 提出物が不十分で後日再提出になった報告，結論を持ち越した会議，未確認事項が残ったヒアリングなど。このようにして生じた見過ごされがちな小さな遅れが1日ずつ蓄積して，ある日，1週間とか1カ月といったまとまった量の遅延となってようやく問題として認識されるようになる。 私の同僚にIさんというめったなことでは遅延を作らない，いわばスケジュール順守のプロがいる。彼は「要求定義のヒアリングは7回」と決めると，本当に計画通りの7回あるいかそれ以下の回数で完了させる。期日を越えることはないし，品質も申し分ない。 その秘密が知りたくて，Iさんの要求定義ヒアリングのための

「オープンソースが成し遂げたものづくりやコミュニティのような，小さくても確実な幸福感が得られるような場所が，よりよく生きたいと思っている人たちの数だけ，ネットの上にできたらいいな」（梅田氏）。「僕が追求するのはオープンソースであるかどうかよりも，個々の技術者が幸せかどうかなんです」（まつもと氏）――梅田望夫氏とまつもとゆきひろ氏の対談，後編は新しい時代の新しい幸福とそれを実現する生き方へと話が及ぶ。 ＜＜前編へ＜＜ ネットの上の「小さくとも確実な幸福感が得られる場所」 梅田　まつもとさんにとっての「幸せ」って何ですか。 まつもと　ご飯が食べられる範囲で，好きなことを日がな一日やっていられれば幸せですね(笑)。 梅田　「ご飯が食べられる」の定義もいろいろありますよね。今日飯を食えればいいとか，蓄えがないといけないとか。 まつもと　蓄えはあったほうがいいですね。生活に不安がない程度に。 梅田　

「データベースはブラックボックス。どんなSQL文を投げたらどんな結果が返ってくるかさえ知っていればよい」---そう思っている人も多いかもしれません。 しかし，本物のソフトウエア・エンジニアを目指すのであれば，データベースが動く仕組みを学ぶことは避けて通れません。パフォーマンスなどに問題が生じたときどこから手を付けていいのか皆目見当がつかない，といった事態に陥りかねません。 市販のRDBMSの内部はかなり複雑ですが，基本的な部分を理解するのはそれほど難しくありません。この特集でデータベースの動く仕組みを理解してください。 イントロ ●ブラックボックスのままでいいの？ 基礎から理解するデータベースのしくみ（1） Ｐａｒｔ１ ●SQL文はどのように実行されるのか 基礎から理解するデータベースのしくみ（2） 基礎から理解するデータベースのしくみ（3） 基礎から理解するデータベースのしくみ（4） 基

2004年27件，2005年24件，2006年28件，そして，2007年86件。 これはITproに掲載されたニュースのうち，タイトルに「中国」という単語が含まれている記事の検索結果である。2007年の86件は，11月13日時点の数字なので，年間では100件を超える勢いだ。平均20数件だった2004年～2006年に比べて，一気に4倍増である（ちなみに，タイトルではなく本文で「中国」に言及している記事も含めると，11月13日時点で313件）。 一口に中国のIT関連ニュースと言っても様々だが，オフショア開発（海外のIT企業にソフトウエア開発を委託すること）をはじめ，日米欧の企業が中国の企業と手を組むというニュースがよく目に付く。例えばこんな具合だ。 ・中国・無錫市、大連に続くオフショア拠点に名乗り（2007/10/19） ・日立情報が中国でアウトソーシング事業、現地法人を通じて開始（2007/

顧客別に営業の基本構想をまとめた「アカウントプラン」は、今やソリューション営業に不可欠なツールと言えます。この連載ではアカウントプランに対する誤解を解いたうえで、顧客の経営課題を把握し、ツボを押えたソリューションを提案するうえで強力な武器となるアカウントプランの作成・活用法を基礎から解説します。 第1回　計画は営業の基本業務，提案に必須のツールを作れ 第2回　「顧客の概要」の日々更新で営業活動の品質アップを実現 第3回　営業プランは顧客本位を貫け，顧客の経営課題からテーマ抽出 第4回　SWOT分析を駆使して解決すべき顧客の課題を抽出 第5回　顧客の課題を体系的にとらえソリューションにつなげよ 最終回　計画は立てるだけでは意味なし，顧客の深堀のために活用せよ

ソフトウエアの改造がトラブルの温床になっている。改造案件が増える一方で，改造ならではの方法論が未熟だからだ。プログラマやSE，プロジェクト・マネージャが一丸となって「改造力」を高めるノウハウを解説する。 第1回　ソフトウエア改造力が足りない：変更ミスがトラブルの温床に 第2回　ソフトウエア改造力が足りない：工数膨らませる影響調査と確認テスト 第3回　対応すべき案件を選ぶ：要望を集め，工数を概算する 第4回　対応すべき案件を選ぶ：費用対効果で優先順位を判断する 第5回　改造の影響を調べる：詳細な工数とソースコードの変更箇所を洗い出す 第6回　改造の影響を調べる：ドキュメントをまとめ作業計画をレビューする 第7回　テスト範囲を最適に決める：過去のテスト項目集めて漏れを減らす 第8回　テスト範囲を最適に決める：シナリオや環境整備でテストを効率化する 第9回　テスト範囲を最適に決める：本番リリース

私は以前SIベンダーに所属し，Web系システムのソフトウエア・アーキテクチャを設計，開発していました。正直に打ち明けると，そのころはシステムの設計や開発と比べ，運用や保守をあまり楽しい仕事だと考えず，そうした仕事を避けていたと思います。こんなことを書くと怒られるかもしれませんが，ITアーキテクトを志す人には，そういう方が少なくないのではないでしょうか。 現在は音楽配信サイトのベンチャー企業を立ち上げ，自分たちで設計・開発したシステムを自分たちで運用・保守する立場になりました。そしてやってみて，私は心底ガックリしました。ほかでもない，自分の設計にです。本エントリではこの経験を基に，「ITアーキテクトと運用・保守」について，考えをまとめたいと思います。 まずは，ちょっとまどろっこしいかもしれませんが，ITアーキテクトと呼ばれる役割の仕事について，レストランのシェフに例えて少し想像しながら考えて

PostgreSQLをクラスタリングするツールの新版「pgpool-II 2.0」が11月16日，リリースした。データベース・ノード間でレプリケーションを行っている際，障害が発生したノードが復活した時に再同期させて復帰させるオンラインリカバリ機能などを実装した。 レプリケーションの高速化や，複数のバックエンドから異なる結果が返ってきた場合に，同じ結果が多数返ってきた結果を信頼する「多数決方式」の実装などを行った。またノードを切り離した際と復帰した際に，ユーザが設定したコマンドを実行する機能なども備えた。 pgpool-II 2.0はSRAOSS日本支社が中心となっているコミュニティ「pgpool Global Development Group」による開発されている。オープンソース・ソフトウエアとして配布されており，以下のURLからダウンロードできる。 http://pgfoundry.o

今日のソフトウエア開発において，Javaは最も重要なプログラミング言語あるいは開発環境といってもいいでしょう。そこで，ITproではJavaの最新技術についての連載を掲載しています。著者はJavaプログラマ向け情報ページ「Java in the Box」で有名な櫻庭祐一氏です。

業務分析に焦点を絞ったパターンは，Process four（P4）と呼ぶ4人の開発者が提唱した「ワークフロー・パターン」（詳細は，http://www.workflowpatterns.comを参照）だ。業務フローを作成する際のひな型として「基本的なパターン」や「先進的な分岐と結合に関するパターン」といった六つのカテゴリに分け，全部で20種類のパターンを定義している（表1）。 表1●ワークフロー・パターン（Workflow Pattern）の概要 業務フローを作成する際に，各アクティビティの配置をどうするかについて示したパターン。六つのカテゴリに分かれ，全部で20種類のパターンがある [画像のクリックで拡大表示] Michael Havey氏が2005年に著した「Essential Business Process Modeling」という本の中で，業務プロセスを設計する際のパターンとして

プロジェクトの節目で，メンバーは課題対応やドキュメント作成にばかり気をとられ，納品作業（契約）を忘れがちになる。納品作業は，ユーザー・営業・現場を巻き込んだ一大イベントであり，契約に関わる重大なタスクだが，いつもドタバタしがちである。そんな時，全体調整に長けたPMOが力を発揮してほしい。 川上愛二 マネジメントソリューションズ マネージャー 小規模プロジェクトであれば，ユーザーと現場の関係が密になっており，日ごろから作業状況も共有されていることでしょう。そういうプロジェクトでは，納品作業が問題になることは少ないと思います。 しかし，大規模プロジェクトでは，納品作業に苦労することが多いのではないでしょうか。「納品はしたが，認識の齟齬が発生しており，検収が遅延した」という苦い経験をした方は決して少なくないと思います。 監査・内部統制が重視され，検収は厳密に 納品作業が滞らないように，大規模プロ

“ネトゲ廃人”だった大学時代，「実力がないことを会社のせいにしていた」大企業時代から，当時社員7人だったはてなに入社し，はてなブックマークを作り上げ“なりたかった自分”にたどり着いた伊藤直也のお話は，きっと見る人を勇気づけてくれると思います。 そして直也氏はこう言います。「本当の意味で世界を変えられるのはコードだけ」。 ニコニコ動画をご覧になれない方はこちらをどうぞ。 ITproによるレポートはこちらです。 「世界を変えられるのはコードだけ」---はてなCTO伊藤直也氏が明かす “ネトゲ廃人”から“なりたかった自分へ”の道のり 残りの講演は2007年10月末までにアップの予定です。タグは「itprochallenge」です。今しばらくお待ちください。

今回のテーマは、見積もりリスク回避のためのヒントや注意事項である。要件があいまいな段階で見積もらざるを得ないため、見積もりのリスクは発生する。したがって対策としては、要件のあいまい性が解消されてから見積もるか、後から修正が受け入れられるような見積もり条件をいかに設定するかである。段階契約が定着し、あいまい性の払拭後に見積もれるように、ユーザー、ITベンダーともに努力したいものである。 「見積もり精度が悪すぎたのが、赤字の最大原因でした。今後は見積もり精度の向上に努めます」―。大口赤字を出したプロジェクトの反省会をやると、こう言うプロジェクト・マネジャーが多い。しかし見積もり時にユーザーから要求仕様がはっきり示されるケースは少ないので、そう簡単に見積もり精度など上げることはできない。 金額精度が高い見積もりを目指すよりも、当初想定したシステムの仕様や見積もり条件の明解化を目指すべきである。後

本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なりますが、この記事で焦点を当てたITマネジメントの本質は今でも変わりません。 情報システムの操作方法を記述した「マニュアル」は必要不可欠のものだが，現実には手抜きのマニュアルが少なくない。システムの利用者の視点に立って，マニュアルを作り直すことで，システムの利用度合いはぐんと高まる。見直しのカギは，利用者が業務の流れとシステムとの関係を理解できる記述にすること。各操作画面ごとに利用者が疑問に思う点を整理しておくことも必要だ。 岩井 孝夫 企業情報システムを構築するプロジェクトの成果物は何か。一つはもちろん，企業情報システムそのものである。もう一つ，忘れてはならないものがある。そのシステムの利用方法を記述したマニュアルだ。 完成したシステムが現場の利用者にしっかり使ってもらってこそ，その