要求定義の手法を見直す動きが活発になってきた。これまでの開発者視点の手法では，社外ユーザー向けのシステムなどが開発しづらくなってきたからだ。旧来の手法で無理に進めれば，使われないシステムや赤字プロジェクトが増すばかり。要求工学，ユーザー中心設計，超上流など，システマティックな手法を取り入れ，いち早く要求定義の問題解決に挑んだ現場から，実践のノウハウを探った。 「システムの利用目的や対象ユーザーが大きく変わった。要求定義の認識を改める必要がある」──。30年間にわたり，情報システム部門，ユーザー，ベンダーと立場を変えながら金融システム開発の現場に携わってきたアイネスの菊島靖弘氏（金融システム本部 副本部長）は，こう警鐘を鳴らす。 帳票作成などの定型業務をシステム化していた時代，システムの利用ユーザーは発注者そのものであり，きちんと要求を語ることができた。ところが「Webシステム全盛の今は，社

前回は，私が添削で実際に指摘した事項を，原因別に分類しました。今回は，未完成であった表を完成させて，どんな指摘が多いのかを明らかにしながら，「説得力のある文書」を書くために気をつけたいことを説明していきたいと思います。 では，完成した表をご覧下さい。

日経コンピュータ副編集長，日経ビジネス編集委員， ビズテックプロジェクト担当，経営とIT新潮流2006編集 ITproの中で「ユーザー」と書けば，ITを利用する企業あるいはそこに勤務する社員を意味する。ITを生業にしている企業やそこに所属する社員をユーザーとは呼ばない。ただし，広く普及している製品を使う利用者については，所属企業を問わず，全員をユーザーと呼ぶこともある。いずれにしても，以上の言い方が許されるのはITproや日経コンピュータなど専門サイトや専門誌においてであって，一般のサイトや雑誌では通用しない。 ユーザーに対する言葉として「ベンダー」があり，ITベンダーとも書く。ITを生業にしている企業群，すなわちコンピュータ・メーカーやソフトウエア・メーカー，ソフト開発会社，コンピュータ販売会社の総称である。かつてはソフトハウス，システムハウスという言葉があったが，いつの間にか使われなく

トヨタグループの社員は、トヨタ用語とでもいうべき社内の共通言語を大切にしている。トヨタの社内で日常的に交わされている「生きた言葉」を、トヨタマンの口ぐせという形でまとめた書籍が10月初旬に発売になる。それが『トヨタの口ぐせ』（中経出版）だ。トヨタ自動車とリクルートグループが共同出資するコンサルティング会社のOJTソリューションズ（名古屋市）が、同社に所属する元トヨタマンの口ぐせを集めて一冊にまとめた。 本書に登場するトヨタマンの1人である山森虎彦氏は、1964年から2004年までの約40年間をトヨタで過ごした大ベテランで、現在はOJTソリューションズのトレーナーとして、トヨタ以外の企業にトヨタの改善手法を指導して回っている。 山森氏の口ぐせは「データで仕事しよう、ワーストから潰そう」「真因を探せ」「カイゼンは巧遅より拙速」であるが、なかでも最後の「カイゼンは巧遅より拙速」は同氏が一番大切に

「経営情報化サミット2006」（日経情報ストラテジー主催：9月6日開催）では，竹内和彦・豊田自動織機顧問（今年6月に副社長を退任，現在アドバンスト・ロジスティックス・ソリューションズ会長）が「トヨタ流カイカク～物流改革から経営改革～」と題して講演した。 豊田自動織機はここ数年，物流関連のコンサルティング事業に力を入れている。竹内顧問は大手スーパーマーケットやコンビニエンストアの業務効率化に取り組んだ際の経験について語った。 「トヨタ流で一番大事にしているのは手法ではなく，精神・文化・風土を変えていくこと。カイゼンする土俵を一緒に作りましょう，というのが我々のやり方。一方的に押し付けることはない」と語る竹内氏。 例えば，全員参加による改善アイデアの提案制度と優秀なアイデアに対する表彰制度を打ち出したという。アイデアは掲示板に張り，情報を共有した。指導した小売業はいずれも先進的な大手企業。「業

海外アウトソーシングでは，言語，文化そして考えが異なる海外技術者のチームや組織が日本の開発案件に対応します。日本側が｢上から押さえつける」やり方で対応すると失敗します。今回はその失敗事例をお話ししましょう。 それはベトナムにオフショアした開発プロジェクトで起こったことでした。以前に発注したオンサイトとオフショアによる２つのプロジェクトで期待以上の成果が出たため，次のオフショアプロジェクトもベトナムに発注しました。それは一定のボリュームはあるものの技術的難易度はあまり高くない開発案件でした。ベトナムでの初期打合せで要求仕様，開発計画を確認し，それまでの実績により成功は間違いなしと確信していました。 そして，3ヵ月後，現地で進捗をレビューしました。そこで，開発が大幅に遅れていることが判明しました。レビュー初め，日本側メンバは｢そんなはずはない！｣と半信半疑でしたが，遅れの実態と客先納期に間に合

オブジェクト指向技術の浸透や，反復型開発の広がりなど，システム開発を巡る状況が大きく変化している。見積もり方法も，従来のやり方では通用しないケースが増えてきた。反復型開発における見積もりの基本的な考え方や，ユースケース・ポイント法の活用手順について解説する。 オブジェクト指向開発の普及に伴い，ソフトウエアを段階的に繰り返して開発していく「反復型開発（イタラティブ開発）」を採用するプロジェクトが増えている。反復型開発は従来のウォーターフォール型開発とは基本的な考え方やフェーズの分け方が異なるため，従来型の見積もり技法を適合できない面がある。 そこで第4部では，反復型開発における見積もりの基本的な考え方と，現在，一般的に用いられている「ユースケース・ポイント法」を中心とした見積もり技法について解説する。なお，システム開発のプロセスは反復型開発において最も標準的な「統一プロセス（Unified

「自分を変えられるのは自分しかいない」。2006年9月5日，ソフトウエア開発プロセスの一つ，eXtreme Programming（XP）を提唱しているKent Beck氏を囲んで記者懇談会が開催された。自分が変われば，必ずまわりは変わる。そんな信念が感じられた懇談会だった。 Beck氏の著書である「XPエクストリーム・プログラミング入門 第2版」は「XP is about social change.」という文章で始まっている。日本語版では「XPとは社会改革のことである」と訳されているが，ソーシャルのニュアンスが少し違うという意見もある。そこでまず「XPでいうソーシャルとはどういう意味か」と質問した。 Beck氏はソーシャルの例として「14歳になる私の娘は，ある友人と1時間くらい話をし，別の友人と同じ話をまた1時間くらいする。彼女はソーシャルな子供だ」と語った。つまり「社交的」「コミュニ

前回に引き続き，M社の社長の案内で，生産ラインを見学しています。今日の社長は，筆者の前を小走りに歩き回り，若手社員を中心に声をかけています。 お盆休みが明けて，社員が随分と増えましたね。 「いまの生産体制は，春先の凪(ナギ)の状態に合わせて正社員を確保していますから，夏以降は派遣社員やアルバイトを受け入れることになります」 2004年に労働者派遣法が改正されて，製造業でも派遣受け入れが認められましたからね。ただし，派遣社員の弱点は，思うような人材が集まらないことや，単純な作業しか任せられないことなどですよね。 「現在は，熟練工の高齢化に頭を痛めているところです。技術を伝承させようにも，派遣社員では難しい。おまけに最近のフリーターくんは，『オレ的な仕事じゃないっす』とかいって，翌日から来なくなるんですよねぇ」 M社の社長は，苦り切った表情を筆者へ投げ返しました。 M社ではここ近年，製品の不具

訪問履歴を残さないWebブラウザを英Browzarがベータ公開している。同ブラウザの名称は企業名と同じ「Browzar」。現在，Windows版を同社Webサイトより無償で入手できるほか，Mac OS版，Linux版もまもなくリリースする予定という。 Browzarは「完全にプライバシを保護するために」（同社），履歴，キャッシュ，クッキーを保存せず，入力時の自動補完機能を使用しない。 プログラム・サイズは264Kバイトと軽く，「ダウンロードにかかる時間はわずか数秒」（同社）。例えば，旅行先のインターネット・カフェで電子メールをチェックしたり，家族で共有しているパソコンでネット・サーフィンしたり，職場のパソコンでオンライン・バンクにアクセスしたりする場合に，即座に同ブラウザをダウンロードして利用できる。 パソコンのハードディスクやメモリー・スティック上に保存して起動できるほか，「Intern

■今回からは、商談や会議・ミーティングにおける上手な会話の仕切り方について解説していきます。第1回目は、話の長い人を相手に、いかに会話の主導権を握るかです。 どこの世界でも話の長い人というのは、いるものだ。 私も会議進行のお手伝いをよくさせていただくが、一度しゃべりだすと止まらない人を多く見かける。しかも、そういう人に限ってエライ人だったりするので、始末が悪い。 商談などもしかり。早く本題に移りたいのに、まったく関係のない話が延々と続いて、なかなか本題を切り出せない。あるいは、すぐに話が飛んでいってしまって、なかなかこちらの要件についてじっくり話ができないことがある。 時間に余裕のある場合はいいが、急を要する場合は困ってしまう。大事なお客さんの話の腰を折るわけにもいかず、あせりながら、ただじっと長話が一刻も早く終わってくれるのを祈るしかない。 私は会議のファシリテーションをしていて、進行上

前回は，「使われないシステム」が出来上がる原因が要求定義にあると考えていた折に，要求開発方法論Openthologyに出会い，筆者の悩みを解決する大きな助けとなったことを述べた。今回は，Openthologyを実際のプロジェクトに適用する際のヒントをいくつか紹介したい。 システム開発に取り掛かる前段階としての要求定義では，様々な問題が発生する。筆者がこれまで携わったプロジェクトでも，「システム化する部分ばかりに目がいって，ビジネス上のゴールまできちんと詳細化できない」「要求仕様が膨れ上がってまとめきれず，時間切れになる」といったケースがあった。問題を簡単にまとめると，以下の2つになるだろう。 (1)要求を検討する際の目的とゴールが明確になっていない。 (2)本来議論すべき対象が可視化できておらず，議論が発散する。 こうした問題を解決するために，筆者は身近なプロジェクトにOpentholog

最近、いわゆる“偽装請負”の問題が、ITサービス業界で何かと話題になっている。2004年末に東京都労働局がその実態を調査・公表したのが“騒ぎ”の発端だが、巨額のIT投資を復活させIT技術者確保に動く金融機関が、コンプライアンスの観点からナーバスとなっていることも、この古くからの問題を再びクローズアップさせたようだ。「常態化している」と指弾される、この問題を改めて考えてみた。 偽装派遣とは、請負契約で客先に常駐していながら、実態は派遣と変わらない業務状態を指す。契約に基づいた成果物を提供するというよりも、顧客企業の社員から直接指示を受けて言いなりで作業するといった形で、隠れ派遣とも言う。本当に古くからある“慣行”で、私が以前務めていた企業でも当たり前のように行われていた。20年も前のことだ。 当時は、請負と派遣の区別もつかない若輩者だったが、その記憶が底流にあるのか、今まで私はこの問題に対し

Windows XP SP2とWindows Server 2003 SP1のTCP/IPスタックでは、不完全な外向きのTCP同時接続数を10接続に制限しています。接続数が10に達した場合、接続要求はキューイングされ、ある一定間隔で処理されるようになります。 この制限は、ホストがワームに感染した際、他のホストへの影響を最小限にするため、Windows XP SP2とServer 2003 SP1で新たに実装されました。しかしこの制限は、不完全な外向きのTCP接続を大量かつ同時に張るアプリケーションにおいては、大きなパフォーマンス低下を招く可能性があります。例えば、P2Pシステムや脆弱性スキャナなどが挙げられます。特に脆弱性スキャナは業務で利用するケースが多いと思いますので、パフォーマンス低下は非常に致命的です。 これを回避する選択肢の一つとして、TCP同時接続数制限の無いプラットフォームを

■「交渉に勝つ」とはよく言いますが、お客様との交渉においては、それが商談であれ、トラブル交渉であれ、お客様を敗北に追い込むことは目的ではありません。特にトラブル交渉では、自らが負けずに、そして「相手にも負けさせない」ことが大事です。 トラブル交渉では、お互いに深い傷を負いたくない。なんとか責任を回避して自分の傷は最小限にしたい。そのせめぎ合いだ。 こちらが「売り手」の立場であっても、それは同じだ。言いがかり的なクレームは当然のこと、こちらに責任のないことまで責めを負わされるいわれはない。冷静に責任の所在を明らかにし、主張すべきは主張して責任に応じた対応をする。それが原則だ。 ITにおけるトラブルというのは、障害にしろ、仕様変更にしろ、実は顧客側に非がある場合が意外と多い。「すわ障害だ」と、いきり立ってベンダーを呼びつけたら、顧客側がとんでもない運用をしていた、なんてことはしょっちゅうだ。

HTMLからXHTMLにスムーズに移行するには、「書式の違い」をきちんと押さえておくことが不可欠。今回は「XML宣言」「文書型宣言」「XML名前空間と言語コード」「MIMEタイプ」「style要素とscript要素」について見ていこう。 HTMLよりも書式が厳格なXHTML XHTMLはHTMLをXMLで再定義したマークアップ言語であり、HTMLの簡便さを残しつつXMLの論理的厳密性を備えている。そのため、HTMLのようにルーズなコーディング（たとえば終了タグがないなど）でもブラウザで問題なく表示される、ということはほとんどない。したがって、書き方にエラーがないかどうか少し神経質にならなければならない。 また、CSSがきちんと適用されないというトラブルも、実はXHTMLが正しく書かれていないことに起因していることが少なくない。 これらの問題を避けるべく、エラーのないソースにするには、バリデ

「自分の経験上，モラル（責任感や倫理観）を維持したくてもできない時期があった。過酷な作業の中で，本来必須の作業すらこなせない。それが原因で問題が発生して非難されたとき，もう自分が悪いとは思わなかった」 日経コンピュータが5月30日から6月7日にかけて実施した，IT業界のモラルに関するアンケートに寄せられた自由意見の一つである。ソフトハウスに勤務するこの30代のエンジニアは，「後から結果を見て非難するだけなら，誰でもできる」と心情を訴えた。 本誌は，5月30日に公開した記者の眼「危機に瀕するIT業界の『モラル』」の中で，Webによる調査への協力を呼びかけた。短期間にもかかわらず，785人の方にご回答いただいた。この場を借りて御礼を申し上げたい。 記者がとりわけ強烈な印象を受けたのは，回答者が寄せた自由意見である。こうした調査に回答する人は，元から問題意識が高いのだろう。それを差し引いても，回

プロジェクトの失敗を招く大きな要因の1つが「組織の作り方」にある，と言ったらどう思うだろうか。だが，情報伝達がうまくいかない，必要なスキルを持つメンバーを確保できない，といった問題の根はそこにある。プロジェクトを遂行する上で最適な組織体制を決める「組織デザイン」の理論や手順を，具体例も交えて解説する。 「プロジェクトが失敗する原因の多くは，技術的な問題ではなく，組織と人間の問題にある」――。米国の著名なコンサルタント，トム・デマルコ氏が1987年に記したベストセラー「ピープルウエア～ヤル気こそプロジェクト成功の鍵」の中で警告した有名なメッセージだ。 情報システムがスケジュール通りに完成しない，あるいは開発コストが予算を大幅に超過する，といったプロジェクト失敗の原因として，開発プロセスやプロジェクトマネジメントの問題，あるいはメンバーの技術スキルの不足が指摘されることが多い。しかしデマルコ氏

写真1●新人研修での最終発表会の様子を再現してくれた，今年春にトヨタグループに入社したばかりの新入社員の2人 [画像のクリックで拡大表示] 朝から晩までトヨタ生産方式にどっぷり浸かる1カ月半---。これが，この春トヨタグループに入社したばかりの新入社員の新人研修メニューである。筆者は特集の一環として，この研修の詳細な内容を取材する機会を得たので，紹介したい。 取材に協力していただいたのは，豊田自動織機の物流子会社であるアドバンスト・ロジスティックス・ソリューションズ（ALSO，名古屋市）に今年4月に入社した9人の新入社員のうちの2人。真新しいスーツに身を包んだ稲垣誠氏と鈴木宏和氏である。 5月19日にALSO社内で実施された研修日最後の発表会の内容を，2人に改めて再現してもらった。記者を目の前にして最初は緊張気味だった2人も，いざ始まると，実際の発表会の時のことを思い出したかのように，詳し

上司に意思決定を仰ぐというプロセスはあまり楽しくないものです。もちろんリスクある案件を上司との連帯責任(言葉が悪いですね。^^;)にできるという意味ではとても重要なプロセスなわけですが、反対に誰がどう考えても結果は明らかでわざわざ意志決定を仰ぐほどでもないことに関してはあえて自分の責任で意志決定を仰がないのも良いのではないかと思います。そこで今回は意志決定を仰がないためにはどうしたらよいか考えてみたいと思います(?!)。 技術1: 報告をした上で既成事実を作る 自分の考えていることは絶対に正しい。だけど上司や周りの人や経営陣が全然理解してくれないと感じる機会は多いと思います。いくら意思決定を仰いでも保留にされてしまうと頭にくるものです。そんなときは強気に出るのが良いと思います。例を出しましょう。 ×悪い例 「○○の件ですが、○○を○○にすると作業効率が上がりとてもやりやすいです。お忙しいと