機能要件設計書だけで20種類
意図が伝わる設計書を作るには，前提として「それぞれの設計書がどういう役割を担うか」「それぞれの設計書が相互にどういう関係にあるか」を正しく理解しておくことが重要である。豊富なサンプルとともに，設計書の役割と関係，さらには書き方のコツを解説する。 石川貞裕 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 担当本部長 向坂太郎 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 「基本設計書」と聞いて，どんなものをイメージするだろうか。業務フロー図や画面レイアウト，E-R図など様々だろう。大規模，高品質のシステムを開発するなら，図1に示すような多くの設計書を作成することになる。 中心となる機能要件設計だけでも20種類。それぞれの役割や関係をきちんと理解し，過不足なく設計情報を盛り込むことが求められる。 難しいのは，設計書の読み手が開発者だけではないことだ
機能要件は3階層で整理
上はarrowheadの全体機能と利用者や接続システムを示す「全体業務フロー図」。中は業務単位で機能間の連携をまとめた図。下は機能をさらに細分化して要件を記述したもの 最上位層に当たるのが左上の「全体業務フロー図」。arrowheadを中心に配置し、接続先システムやシステムの利用者を周辺に並べて、それらの関係性を図式化した。 全体業務フロー図の狙いは、1枚の資料でシステム全体を俯瞰できるようにすることだ。「注文処理」や「情報配信」「取引規制」などの機能群を、どの粒度でどのように分類するのが最善かを検討しやすくなると期待した。 記述が細かすぎると全体を直感的に把握できない。かといって大ざっぱすぎても意味がないので、粒度には気を配った。今回は外部に位置する接続先システムや利用者などの「アクター」と呼ぶ存在に着目して機能群を分けた。arrowheadが処理するデータはアクターから入ってくる。出力
天然疑惑
テレビ報道によると，クレーマーが増加しているらしい。モンスターペアレントならぬ，モンスターコンシューマの台頭である。ファッションメーカーに勤務する妻も，そうそうその通りという。それも，10年も前に購入して飽きるほど着用した洋服を持ってきて「変色した」と返金を迫る客とか，考えられないようなケースが，考えられないほど多いのだとか。 先日も，フォーマルウエアをオーダーで購入した顧客が返金を要求しに来たのだという。新品のままなら分かるが，明らかに着用済，クリーニングもせず放置されていたかのような状態で，しかも納品してから数カ月が経過している。それを示して「自分が指定した寸法になっていないことが判明した」と主張するのだが，調べてみると寸法はオーダー票の指定通り。それをやんわりと説明すると客は納得するどころか逆ギレし，「その数値は改ざんされている」とわめき始めた。「で，どう対処したの」と聞くと，再オー
デスクトップ・アプリケーションは5年もすれば消える
Webブラウザだけで使えるオフィス・アプリケーション「Zoho」シリーズを提供する米アドベントネット。ワープロや表計算をはじめ，約20種類ものアプリケーションを提供中だ。同社のスリダー・ベムブCEOは「デスクトップ・アプリケーションは今後消えてしまう」と言い切る。 Zohoのビジネス・モデルは。 Webブラウザで利用できるアプリケーションをビジネス・ユーザーに月額料金で提供することだ。個人ユーザーには無償で提供している。現在120万のユーザーがいる。 アプリケーションとしては，メール，エディタ，スプレッド・シート，スライドショー，プロジェクト・マネージメント，データベースなど業務に必要なものを一通りそろえてある。ユーザーが必要とするアプリケーションがあれば，随時追加していく。既存のアプリケーションも永続的に機能強化していく。 なぜ，Webでアプリケーションを提供しているのか。 インターネッ
Rubyを日本から国際標準に，2009年前半に仕様案を完成
Rubyを日本から国際標準に，2009年前半に仕様案を完成 Ruby作者 まつもとゆきひろ氏 IPA Ruby標準化検討WG委員長 筑波大学名誉教授 中田育男氏 プログラミング言語Rubyを国際標準とする作業が進んでいる。独立行政法人 情報処理推進機構(IPA）オープンソフトウェア・センターは，Ruby標準化検討ワーキンググループを設置，2008年末から会合を行っている。委員長にはまつもとゆきひろ氏の恩師でもある筑波大学名誉教授 COINSコンパイラ・インフラストラクチャ協会理事長 中田育男氏が就任。標準仕様草案作成はまつもと氏が在籍するネットワーク応用通信研究所が担当する。2009年の前半には標準仕様の草案を作成し，最終的にはISO（国際標準化機構）に提案する予定だ。中田氏とまつもと氏に，標準化の目的や進め方を聞いた。 標準化の目的は。 中田氏：Rubyは日本で作られ，世界で使われている
第28回 「上流工程に時間を」は正しいか？ つい“楽”を求めるSE心理を知れ
システム開発の世界では「下流工程よりも上流工程に時間をかけろ」という言葉をよく耳にする。これは本当に正しいのだろうか。 「要件定義や設計などの上流工程に資源を集中的に投入し，この段階でバグの芽を摘んでおくことで，コーディングやデバッグ，テストといった下流工程の負担を軽減すると同時に，予想外の手戻り作業を撲滅する。そうすれば，開発期間を短縮できるだけでなく，品質の向上にもつながる」。これが冒頭の言葉の意味するところである。 確かに，デバッグやテストの段階で，設計や要件定義のフェーズまでさかのぼる重大なバグが検出された場合，スケジュールの大幅な見直しを迫られる。ところが，プロジェクトの終盤になってカットオーバーを遅らせるのは現実問題として難しいので，結局デバッグやテストのフェーズが突貫工事になってしまう。そうなると，焦りと疲労が災いしてメンバーがミスを犯しやすくなり，泥沼状態に陥る。これでは，
ITpro読者200人が考えた“うっかりミス”対策
先だって、この「記者の眼」欄で情報システムの“うっかりミス”について書き、読者の皆様にアンケートをお願いした（関連記事『「うっかりミス」は叱っても減らない』。ここでいう、うっかりミスとは、システムの操作ミスやパラメータ設定の誤りなどを指す。アンケート回答の受付期間が1週間と短かったにもかかわらず、184件もの有効回答を頂いた。この場を借りて御礼を申し上げるとともに回答結果と読者から寄せられたコメントを公表する。 アンケートの目的は、読者の皆様が実際に体験した、あるいは職場などで見聞きした、うっかりミスの具体例と発生原因、対策を共有することである。うっかりミスの再発を防ぐために具体例の共有が有効だからだ。これは、心理学や失敗学など人間の失敗を研究する専門家の共通認識である。 7割がうっかりミスに直面 アンケートの最初に、「うっかりミスをしたことがあるか」あるいは「職場で見聞きしたことがあるか
端末が売れずに逆に営業利益4割増，ドコモが2008年度上半期決算を発表
NTTドコモは2008年10月31日，2008年度上半期の決算を発表した。営業収益は前年同期比2.5％減の2兆2678億円，営業利益は同41.2％増の5769億円と減収増益だった。 減収の最大の要因は，携帯料金収入の減少。「ファミ割MAX50」「ひとりでも割」など割引サービスの契約率は9月末で50％以上，端末販売時のバリュープランの契約数は9割以上で推移しており，収益を押し下げた。 一方で，販売奨励金で値引きをしない新たな販売モデルを導入したことで，携帯電話の販売数が大きく落ち込んだ。上半期の端末の総販売数は1026万5000台と，前年同期比でマイナス20％の大幅減である。ただし，これにより，販売奨励金の削減に加え，端末原価と代理店手数料が減少し，利益を押し上げる結果となった。 年度内にmovaの停波スケジュールを決定 2008年度通期の業績予想については，営業利益8300億円に据え置いた
ITサービス会社、3つの大事な忘れ物
「事業の発展に必要な研究開発や人材育成、マーケティングといった機能をあまり重要視していないのでないか」。 NTTデータ経営研究所の三谷慶一郎パートナー・情報戦略コンサルティング本部長は、ITサービス会社やソフト開発会社の現状をこうみている。ITサービス会社の動向に詳しい三谷氏は「感覚的な数字」と断りながらも、次のように指摘する。「ITサービス会社のほとんどが、R＆Dには売り上げの1％程度、人材教育には0.3～から0.4％程度しか使っていない。どちらもすごく小さい額だ」。何でも手掛ける全方位のサービス業なので、マーケティングなど必要ないと思っているのだろうか。 ITサービスの業界団体である情報サービス産業協会（JISA）が平成20年度事業計画で指摘しているように、日本のITサービス市場は今や売上高16兆円超、従業員数82万人という、国内有数の産業に育っている。しかし、1人当たりの売上高は約2
ケータイを買い替える意欲が失せています
記者が利用しているノート・パソコンは5年前に購入したものだ。そろそろ買い替えを考えているのだが，踏み切れないでいる。有償の修理に2回ほど出したし，バッテリーも交換したり（それも量販店での扱いが終了したためメーカーから定価で購入）などと維持費用もかかっている。いま流行のUMPCが買えるくらいの金額だ。それでも買い替えないのは，現在の環境を引っ越すのが面倒だからだ。 5年も利用しているとインストールするアプリケーションは増えていき，キー操作などをカスタマイズするなどしており，もはや新しい機種に同じ環境を構築するとなるとかなりの手間だ。CD-ROMはあっても，ライセンス・コードがが行方不明になっているアプリケーションもある。ネットから入手したソフトなどは，配布元のサイトが閉まっていることもある。実は，これと似た事情で携帯電話の買い替えもためらっている。 記者はどちらかと言えばガジェット好き。PD
早期退職の新入社員を未練がましく追いかけるな
新入社員の早期退職が問題になって久しい。 新規学卒就職者で就職後3年以内で退職する若者が，2002年大卒で34.7％（1992年大卒では23.7％），2002年高卒で48.6％（同じく92年高卒では39.7％）にも上るという（「平成18年版 国民生活白書（内閣府）」より）。 新卒ばかりでなく，若年層の勤続年数が短縮化している。全年齢平均の勤続年数は，95年の12.9年から2005年の13.4年へと，むしろ長期化している。しかし，20歳から24歳では95年の2.7年から2005年の2.3年へ，25歳から29歳では95年の5.1年から2005年の4.8年へと短縮化している（「平成19年版 国民生活白書（内閣府）」より）。 何故，若者たちは簡単に辞めるのか。若者向けのアンケートサイトから，彼らの声を拾ってみよう。 『わが道を行く』という感じの声としては，「そのうち需要過多（＝労働力不足）になるの
静かに強まる中堅・中小SIerの経営への危機感
中堅・中小SIerの間で、思った以上に経営に対する危機感が高まっている。経営者は、生き残りのための手段を真剣に模索し始めた－－。最近、立て続けにこう考えさせられる出来事が二つあった。 敏腕コンサルタントの皮膚感覚 一つは、「IT一番戦略の実践と理論」というタイトルの書籍を編集したことだ。この書籍は、日経ソリューションビジネスで「中堅・中小SIer必読！ビジネスモデルの再構築法」という連載を寄稿してくれた船井総合研究所の経営コンサルタントである長島淳治さんの活動の集大成とも言えるものである。 この書籍で、長島さんは繰り返し中堅・中小SIerの経営が二極化しつつあることを指摘している。元請けから発注価格の低減を要求され、経営不振にあえぎ強い不安を感じる企業。もう一つは、システム開発の世界に可能性を感じ、15パーセントの売上高営業利益率を実現する企業である。 そして、経営不振の企業を中心に、「明
［応用編］第3回 プロジェクト開始前の準備－－やるべき作業は多い 周到に計画を立てスムーズに立ち上げる
プロジェクト開始前の段階からスコープやコスト，スケジュール，組織体制を十分に検討することは，プロジェクトのスムーズな立ち上げに欠かせない。ベテランのプロマネが，提案・契約に至るまでの計画作業を現場の経験を基に解説する。 布川 薫／日本IBM ゲスト執筆者：神野 幸英／日本IBM プロジェクト・マネジャーに任命されたものの，すでに提案・契約が完了しており，プロジェクトのスコープ（範囲）や新システムの稼働スケジュール，コストなども決められてしまっていた…。読者の中にはこんな経験をした人はいないだろうか。 これは請負型のシステム開発プロジェクトのあるべき姿ではない。請負型のシステム開発では，プロジェクトの提案・契約を実施する「プロポーザル・マネジャー」と，実際にプロジェクトを遂行していくプロジェクト・マネジャーを，一貫して同じ人が担当するのが本来の姿だからだ。 プロジェクトの計画を別のプロポーザ
第18回：「テクノロジスト」の社会的認知が必要
「IT革命」について、ドラッカー氏は次のように書いている。 「IT革命とは、実際には知識革命である。諸々のプロセスのルーティン化を可能にしたのも機械ではなかった。コンピュータは道具であり、口火にすぎなかった。ソフトとは仕事の再編である。知識の適用、特に体系的分析による仕事の再編である。鍵はエレクトロニスではない。認識科学である」 引用した下りが出てくる論文は、1999年に発表されたものだ。エレクトロニスで大革命が起きるような報道を続けた日米のメディアは、この論文の発表時に熟読すべきであった。いや、今から読んでも遅くはない。IT革命に代わって最近は、ユビキタスなんとかという言葉が飛び交っているからだ。 引用した文章の直後に、ドラッカー氏は次のように述べている。 まさに出現しようとしている新しい経済と技術において、リーダーシップをとり続けていくうえで鍵となるものは、知識のプロとしての知識労働者
東証のシステム障害、設定ミスをテストでも見抜けず
東京証券取引所は7月22日午後3時半から緊急会見を開き、同日午前に発生した派生売買システムの障害について説明した（関連記事1、関連記事2）。説明に当たった鈴木義伯常務取締役CIO（最高情報責任者＝写真）によると「プログラムが使用するメモリー領域の設定ミスにより、取引の注文状況を表示する板の情報が配信できなくなった」という。ベンダーである富士通の作業ミスをテストでも発見できなかった。 板情報を配信するプログラムは本来、1銘柄当たり1280バイトの作業用メモリー領域を2万8000銘柄分、合計3万5000Kバイト確保するよう記述しなければならない。だが、1銘柄当たりのメモリー領域を誤って4バイトとしてしまったため、プログラムは本来の320分の1の109.375Kバイトしか確保しなかった。結果として89銘柄以上の板情報の問い合わせが同時に発生すると、作業用メモリーが足りなくなり、情報配信システムが
個人のルール違反を撲滅
富士通が全額出資で設立した「富士通アドバンストクオリティ」は、プロジェクトに参加するプログラマ全員がルールに沿ってテストを消化したかを第三者の視点で確かめる役割を担う。例えば単体テストに「実施漏れはないか」や「障害はすべて修正済みか」をチェックする。口頭で「漏れはありません」と申告を受けるのでなく、テスト仕様書やテスト結果、テスト成績書などを提出してもらい、きちんとテストしたかを調べる（図）。 新会社のベテラン技術者がプログラマ一人ひとりと個別に時間を設け議論する。詳細設計とプログラミングの工程で実施する。要件定義や基本設計、総合テストなど、顧客と共同で進める工程は対象から外し、ベンダーが責任を負う「ものづくり」に絞る。「富士通グループでは初の取り組み」（新会社の油井克実社長）と言う。 従来の品質管理手法に限界を感じたことが取り組みの端緒となった。これまでもプロジェクトチーム内の品質担当者
「うっかりミス」は叱っても減らない
システム責任者が顔を真っ赤にして，データセンターに乗り込んできた。ある企業でシステム障害が発生した直後のことである。システム責任者がデータセンターに足を運ぶことはめったにない。トラブルを知って駆けつけたのだ。 障害の原因は，運用オペレータの操作ミスだった。システム責任者は「どうしてミスをしたんだ」と作業者に詰め寄る。オペレータが「申し訳ありません」と頭を下げると，システム責任者は「謝るだけでは分からない」と迫る。 「いつもはきちんとやっていたのですが」「自分でも分かりません」「うっかりミスです」。オペレータが言葉を並べても，システム責任者の怒りは収まらない。「ミスしたのに，さらに言い訳するつもりか」と追及する。 そこに，システム責任者の部下の課長がやってきた。課長もオペレータに怒りをぶつける。課長の後はリーダー，担当者と順番にオペレータをしかりつけ，データセンターを去っていった－－。 怒る
プロジェクトに潜む「悪魔のスパイラル」
先週，プロジェクト・マネジメントをテーマにした日経コンピュータ主催のセミナーに出かけた。この分野における専門家3人の講演をうかがい，いろいろと勉強になった。セミナーを聞き終えて興味深かったのは，講演者3人が3人とも，「システム開発プロジェクトが泥沼にはまり込む過程」を同じような表現で語っていた点だ。3人がそれぞれの経験に基づいて，「負のループ」「悪魔のサイクル」「悪魔のスパイラル」と呼んでいた。 これらの呼び方が示そうとしているのは，初めはプロジェクトに生じた小さな「遅れ」や「問題」だったとしても，悪魔のスパイラルを通じて徐々に深刻化していくという悪循環の存在である。このような指摘に「そうそう」とうなずいたり，「あぁ，確かにそうかもしれない」と気付いたり，あるいは「えっ？」と驚いたりと，読者の方々はさまざまな印象を受けていると思う。この機会に自分が関与するプロジェクトの状況について，点検し
記者が引き継いだ“Excelレガシー”
「日経コンピュータ」の7月1日号で、「"Officeレガシー"は宝に変わる」という特集を執筆した。読者の中には昨年7月、日経コンピュータで特集した「Excelレガシー再生計画」を覚えている方もおられるかもしれない。現場で開発した“Excelシステム”が張本人の異動や退職などで、メンテナンスできなくなっているというものだ。その記事を執筆した記者はこの春に異動したが、当時は読者や取材先から予想以上に大きな反響があった。 レガシーを英和辞書で引いてみると、「（祖先や先人からの）遺産、遺物」。まさに記者も「Excelレガシー再生計画」記事を遺産として先人から引き継いだ格好になった。ロジックを理解して現状に即した記事を書かなければ・・・ 2週間ほど悩み続けた結果、Excelレガシーを「お荷物」ではなく「宝」としてとらえられないかと考えるようになった。現場がそれほどに使い込んでいるExcelシステム。
現場に蔓延する“ひどいRFP”
ITproの読者で「RFP（提案依頼書）」という言葉を知らない人は少ないだろう。それだけ，RFPが市民権を得た結果と言える。しかし，RFPの活用が広がる一方で，悲鳴を上げているベンダー担当者も増えているように感じてならない。悲鳴を上げているのは，コンペによって競争にさらされているからではない。“ひどいRFP”によって不当な提案を強いられたり，迷走プロジェクトに巻き込まれたりしているケースが目立つからである。 現場ではいったい何が起きているのか。記者は5月某日，RFPの読み手であるベンダー担当者3人を招いて，覆面座談会を開いた。テーマは「現場に蔓延する“ひどいRFP”」。すると，実際に出くわした“ひどいRFP”が，次から次へと挙がった。以下では，その典型パターンをいくつか紹介しよう。 ケース（1） 担当者の思いだけで記述 一つめは，担当者の“思い”だけがRFPに書かれていたケースである。大手
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
