「増え続けるステークホルダー間の調整や技術の選択肢の多様化など考えるべきことが多く，1人のマネージャではとても回らなくなってきた」。住生コンピューターサービスの小浜耕己氏（品質保証部 品質保証グループ長）は今の開発の難しさをこう語る。 しかし，小浜氏が現場をつぶさに見ていくと，うまくいく人は何があってもうまくいくことに思い当たった。「彼らは他の人には見えぬ潜在リスクに気づく。だから早いうちに問題に対処できる。その人が気づくことを他の人が気づけるような仕組みを作れば，全体のレベルは上がるはずだ」（小浜氏）。 第1の力は問題が「見える力」。すなわち問題発掘の仕組みである。 暗黙知を可視化する 見える力は，まだ表面化していない問題を，表に引きずり出す力である。属人的なその力を仕組みに作り込んだ，小浜氏らの取り組みを三つ紹介しよう。 （1）プロジェクト計画書のひな型 “何があってもうまくいく人”の

設計・実装から運用，メソドロジまで，最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」（アンチパターン）があるだろう。だが，その理由を問われると，うまく説明できないことがあるのではないだろうか。突き詰めて考えると，状況によっては「やっても構わない」こともあるし，技術の進化に伴い「やれるようになってきた」こともある。そこで設計，実装，テスト，運用，メソドロジの各分野について，取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル３～レベル１の３段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編

写真●X-over Development Conferenceでの対談<br>左が日立製作所の石川貞裕氏，右がアイ・ティ・イノベーションの林衛氏。 1月30日に開幕したITpro EXPO 2008では，フォーラムとしてソフトウエア開発をテーマにした「X-over Development Conference」も開催している。「品質は上流から作りこむ」と題したセッションで，日立製作所プロジェクトマネジメント統括推進本部の石川貞裕担当本部長とアイ・ティ・イノベーションの林衛代表取締役社長が対談した。要件定義以前の工程での間違いがテスト工程以降に品質問題として噴出するという問題意識を提示し，間違いの見極め方や対策を披露した。会場は100人を超える聴講者で満席となった。 「開発工程や成果物を定義しているプロジェクトは多い。しかし，成果物の具体的な内容や体系，各工程の完了基準まで定義しているプロ

UMLとはいったい何だ？ 近ごろUML（Unified Modeling Language）が注目を集めています。多くの雑誌にUMLの特集が組まれ、＠ITにもUMLに関する記事がたくさん掲載されています。また、最近ではUMLを知っていることを前提とした文章も珍しくありません。 実際、システム開発の現場でUMLが積極的に使われ始めています。UMLに対応したツールも多く登場し始め、UMLが説明の必要もないほど必須の技術になっているといえます。 本稿ではそんなUMLとは一体どんなものなのか、どのように使われているのかについて、オブジェクト指向の話と併せて取り上げていこうと思います。この5分がUMLに興味を持つきっかけとなれば幸いです。

Software Architecture in Practice (Sei Series in Software En ソフトウェアの方式設計について実践を目的に、丁寧な解説を行っており、我が国のソフトウェア技術者が必... アーキテクトのバイブルとされる本．SWEBOK (Software Engineering Body of Knowledge) でも推奨書籍とされている． タイトルの "in Practice" (実践における) が示す通り，様々なケーススタディを交えつつ，非常に具体性のある内容になっている． こちらがその和訳本． 本書第7章では， - ライフサイクルにおけるアーキテクチャ - アーキテクチャ設計 - チーム構成と，組織がアーキテクチャに及ぼす影響 - スケルタルシステムの構築 を扱っている． それぞれに非常に興味深い内容だが，今回はライフサイクルについて軽く触れ

本題に入る前に三菱化学鹿島事業所の事故で亡くなった4人の方に哀悼の意を表したい。本コラムでも警笛を鳴らしてきた問題である。外れて欲しい予想の一つであった。 さて，2008年の皮切りはソフト屋とハード屋の話である。ソフトの肥大化は大きな問題である。「Windows XP」はC言語で4000万行のソフトだそうである。私の計算では，読むだけで1万時間かかる。年に2000時間労働で，5年である。読んでいる内に「Windows Vista」が開発されるので，すべて読んでいる人はいないだろうと以前のコラムに書いた。携帯電話や高級自動車に搭載されているソフトは約1000万行と言われている。これも技術者一人で読める規模ではない。これだけソフト量が増える要因の一つには，過去の資産の流用がある。蓄積されたソフト群の要，不要を整理せずに新たにソフトを積み重ねるやり方である。 この問題点は昔から指摘されており，解

【IT Service Forum速報】「システムの信頼性向上には可視化が重要」，経産省が新ガイドラインを解説 「情報システムの信頼性を高めるには，信頼性を“可視化”することが重要だ。経済産業省ではそのために有効なガイドラインを公開しているので活用してほしい」――。経済産業省（経産省）商務情報政策局情報処理振興課係長の上原智氏は11月21日，日経BP主催「IT Service Forum 2006」の特別講演において，同省が公開した「情報システムの信頼性向上に関するガイドライン」などを解説した（写真）。 経産省では2006年1月，大規模な情報システム障害が相次いだことを受けて，情報システムの信頼性を高めるためのガイドライン策定を開始。そこでまず実施したのが，ベンダー企業ならびにユーザー企業に対するアンケートとヒアリングだった。 「その結果，開発段階における問題としては，ユーザーとベンダーと

テスト管理ツールには三つの機能がある。1番目は，リポジトリによるテスト情報の一元管理機能。リポジトリで「要件」「テストケース」「テストスクリプト」「不具合情報」などを一元管理する。2番目は，自動テストの実行管理機能。自動テストツールを連携させて，自動テストの実行を管理する。テスト結果はリポジトリに登録される。3番目は，集計/分析機能。リポジトリに蓄積した各種データを様々な角度から集計/分析し，画面や帳票に出力する。 こうしたテスト管理ツールを選定し，うまく活かすにはどうすれば，いいかを解説する。 ＜目次＞ 第1回 テスト管理ツール：表計算ソフトの限界超える 第2回 テスト管理ツール：要件とのひも付けがカギ 第3回 テスト管理ツール：管理者支援型か開発者支援型か 第4回 テスト管理ツール：テスト手順に工夫が必要 「プロダクト賢者の選択」過去の連載-----------------------

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

「必要なテスト項目が漏れてしまった」「時間切れとなり，必要なテスト項目を実施できなかった」――。こんな苦い経験を持つITエンジニアは多いだろう。テストでバグを取り逃がしてしまう“敗北”は，「有効打の不足」と「時間切れ」の二つが大きな原因だ。 有効打の不足には，実施すべきテスト項目が漏れてしまったという数の問題と，より効果的なテスト項目があるのに漏れてしまったという質の問題がある。一方の時間切れとは，限られた工数の中で必要なテスト項目を実施できなかったことを指す。 バグを効率よく狙い撃つ，これが「勝ちにいく! ソフトウエア・テスト」である。では，どうしたら勝てるのか。テスト技術の整備を推進する日立製作所の石川貞裕氏（生産技術本部 担当本部長）は，「テスト設計が決め手になる」と指摘する（図1）。「何をどのようにテストするのかを決めるテスト設計は，テストの成否に大きくかかわる。ところがテスト設計