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

個人が成し遂げられることはどんどん大きくなっている。常識は短期間で変わる。今貴重なものは，やがて過剰になる。日本市場を世界からへだててきた日本語の壁はなくなろうとしている。ネットの向こうにいる仲間を信じよう---「U-20プログラミング・コンテスト」という，20歳以下を対象にしたコンテストに参加した若い技術者たちに，伝えたかったことだ。 ここ3年ほど，このコンテストの審査会にオブザーバという名目で立ち会わせてもらっている。なにしろ審査員のひとりであるまつもとゆきひろ氏が「私が応募しても入賞できないかもしれない」というレベルの高さである。思わず唸る完成度の高い作品あり，思わず吹き出してしまうユーモアのある作品あり。記者は好きに意見だけ言って審査の責任は負わないという美味しい役目でもあり，こんなに無料で見させていただいていいのだろうかというくらい楽しませていただいている(関連記事）。 ところで

前回は，"話が分からない"と言われたことがある人向けに，「上手く説明するために，どんなチェック・ポイントがあるか」を藤井と坂本の説明力を比較しながら見ていただきました。 さて，今回も前回の続きとして，藤井に説明力についてアドバイスした際のエピソードを紹介します。今回も，“仕事に役立つ7つの科目”の「(3)説得的会話」に関するノウハウがテーマです。なお，PDFファイルで「"話が上手くない人"が説明時に受ける質問10例と原因，対策表」を用意しましたので，会社の研修，教育にご活用いただければと思います。 「話が分からない」と言われる人は，どんな質問をされているか。

最近，WebアプリケーションやWindowsソフトの取材で，“このソフトは担当者が一人で作っています”という事例に続けて遭遇する機会があった。フリーソフトや趣味のソフトではなく，会社が商品として提供し，不特定多数のユーザーが使っているアプリケーションを一人で作って，一人でメンテナンスしているという点に興味を覚えた。 先週都内で開催された開発者向けイベント「ITpro Challenge!」でも，ドワンゴの戀塚昭彦氏がニコニコ動画を一人で（しかも3日間で）作ったと語っていた（関連記事）。よく考えてみれば，ITpro Challenge!に登壇したようなハッカーとかアルファギークなどと呼ばれる優れた開発者でなくても，企業内で一人でソフトを作っているケースは思いのほか多いのではないだろうか。 アプリケーションの規模や内容，また開発者のスキルにもよるだろうが，おおむね一人で開発するほうが， ・低コ

最後は，Googleのカレンダー・サービスを使ってマッシュアップ・サイトを作ります。テレビ番組サイトが配信しているRSSデータを取得して，Ruby on Railsでカレンダーのフォーマットに変換します。それをGoogleカレンダーに取り込んで，オリジナルの番組表を作ってみましょう。 ここまで，さまざまなWebサービスを利用してきました。これらはすべて，自作サーバーで稼働するRuby on Railsのプログラムが，Webサービスから取得したデータをブラウザに表示するという仕組みでした。例えばPart3では，Google MapsのWebサービスから取得した地図情報をブラウザに表示しました。 Part4では逆に，Googleのサイトが，自作サイトのWebAPIデータを取得して，ブラウザに表示するという仕組みを体験してみます。 「Googleカレンダー」（写真1）は，「iCalendar」と

あなたは，苦手意識に悩まされたことはないだろうか？　SEであれば，顧客企業のシステム担当者がクレーマーのようにうるさい人物だったり，自分の上司とどうしてもウマが合わなかったり･･････。できればそういう人物には近寄りたくないし，仕事でどうしても会わねばならない時には，何とか事なきを得たいと祈るような気持ちになるに違いない。 だが時として，自分のキャリアをかけるような大型プロジェクトにおいて「苦手な相手」に遭遇してしまうことがある。ビジネスで成功するためには，どうしてもその道を避けて通ることができず，正面から立ち向かわなくてはならないとき，自分の内にある苦手意識をどうやって克服したらよいのだろう。 トップ・アスリートも苦手意識には勝てない 実は，この苦手意識というくせものは誰もが持っている。それは並はずれた精神力を持つトップ・アスリートでも同じことである。いかに優れた能力を持っていたとして

皆さんは，企業のシステムが提供している情報（データ）をどれくらい信用していますか。 例えば，社内の製品担当者に問い合わせをしたい場合，社内システムを使って，製品から担当者を割り出し，担当者名から電話番号を検索，その電話番号に電話をかけてみるでしょう。この場合，社内システムから得られる情報はおおむね信用できるでしょう。製品担当者の変更が更新されていないといったこともあるかもしれませんが，そのような場合は社内であれば引き継ぎ担当者を教えてもらうことで状況を理解できるので，まずは情報を信じて電話をかけてみるのではないでしょうか。 では，社外のお客様へ連絡するときはどうでしょうか。この場合は少し慎重になるでしょう。社内情報を検索するとき以上に各種システムから信用できる必要な情報を慎重に収集し，行動に移すはずです。私の友人のA君もそうでした。 使えないデータたち A君はある電気製品の販売を担当する営

第0回　あらためてRuby入門 まつもとゆきひろ氏自身による「Ruby入門」をお届けします。日経Linuxの連載開始前の特別企画（2005年4月号）として，Rubyが他のスクリプト言語やオブジェクト指向言語とどこが違うのか，なぜ便利なのかを中心に解説してもらったものです。 ● 基本と他言語との違い ● 実装とRuby誕生の秘密 第1回 プログラミングとオブジェクト指向の関係 プログラマを目指す人々の中にも，「オブジェクト指向は難しい」とか，「なかなか分からない」という印象を持つ方が多いようです。そこで，Rubyを題材にオブジェクト指向という考え方について説明していきます。 ● その1 ● その2 ● その3 第2回 抽象データと継承 オブジェクト指向プログラミングを構成する3原則のうち，前回は「ポリモーフィズム」を学びました。今回はオブジェクト指向の歴史を復習した後，残りの「データ抽象」と