使い回しの提案が目立つ「できます」と簡単に言うな 石川 淳氏 プロントコーポレーション 経営企画室経営企画グループ担当マネージャー ITベンダーの営業担当者にはもっと、当社の業務を理解しようという姿勢を見せてもらいたい。提案書を見て、「使い回している」と感じることが多く、がっかりすることもある。 カフェチェーン「プロント」のPOS（販売時点情報管理）システムの再構築を検討していた4年前もそうだった。この案件では、8社のITベンダーから提案書をもらった。 既存のPOSシステムを構築したSIerや、飲食業向けPOSシステムの構築実績が多数あると聞いていた大手メーカーなどに声を掛けた。会社の規模も実績も申し分ないと思い、優れた提案書が出てくるはずだと考えていた。 ところが、この期待は裏切られた。いずれの提案書も、最新のPOS端末やソフトウエアの機能の説明に、大半のページが割かれていた。あとは開発
SaaSよりPaaSの方がシステム・インテグレータ（SIer）に大打撃を与えるなあ・・・セールスフォース・ドットコムのマーク・ベニオフ会長兼CEOの話を聞きながら、そんなことを考えていた。クラウド・コンピューティングの最終的な勝者がどこになるかは別にして、このパラダイムシフトはSIerのビジネスモデルにトドメを刺す、そのことが妙にリアリティを持ち始めてきた。 PaaSはプラットフォーム・アズ・ア・サービス、つまりサービスとしてのアプリケーション開発・実行基盤のこと。SaaSのようにアプリケーションまで作り込んだサービスではなく、アプリケーションを作って動かす環境をサービスしましょうって話だ。セールスフォース・ドットコムは「Force.com」とか言っているが、PaaSは何もこの会社の専売特許ではない。日本のITベンダーもおっかなびっくりだが似たようなサービスに乗り出そうとしている。 情報シ
ユーザー企業のみなさんは、システム開発プロジェクトを進める際、ITベンダーに次のような依頼をしたことはないだろうか。 経営判断でシステムの稼働日は決まっている。だが、肝心の要件は固まっていない。「何としても納期を守ってくれ。要件定義と並行して、仕様が固まっている部分から、開発作業に着手してくれないか」。 すでに開発が済んだ部分について、利用部門から大きな仕様変更の依頼が来た。「予算はもう増やせない。申し訳ないが、最初に契約した金額のままで修正してくれないか。次の案件も御社に発注するから」。 新システムの予算を何とか確保した。あとはこの予算でシステムを開発してもらうだけ。「ハードウエア込み、要件定義から運用設計まで、すべて一括で契約してほしい」――。 頻繁とは言わないまでも、システム開発を進めるうえでは“よくある話”だ。問題があると分かっていても、経営層や他部門からの要請で、こうした依頼を
ソースがドキュメントだ。バグも完全に記述されている。 ――まつもとゆきひろ[1] はじめに 本連載ではアジャイル開発を「アジャイルに開発する人たち（アジャイル開発者）が開発するからアジャイル開発」と考え、アジャイル開発者に必要なスキルを磨くための習慣を紹介しています。 これまでの3回を費して紹介した「フィードバックを重視する」「仕組みを育てる」「スケール間に連続性を築く」といった習慣は、チームによるシステム開発の現場でアジャイルにプログラムを書くことを重視したものでした。 しかし、これでは開発対象となるシステムを構成する2つの要素のうち主に1つしか説明していません。2つの要素とは、プログラムとドキュメントです。今回は、これまであまり触れてこなかった、2つの要素のうちの1つであるドキュメントに関する習慣を紹介します。 そのためにまず、アジャイル開発者にとってのドキュメントの位置づけを説明
■ 「情報システム信頼性向上のための取引慣行・契約に関する研究会」最終報告書 ～情報システム・モデル取引・契約 書～ の公表について 経済産業省では、「情報システムの信頼性向上のための取引慣行・契約に関する研究会」を設置し、取引・契約モデルの検討を行ってきました。 パブリックコメントによる意見聴取を経て、平成19年4月には、対等な交渉力を有するユーザ・ベンダを契約当事者とし、ウォーターフォールモデルによる重要インフラ・企業基幹システム構築を前提条件とするモデル取引・契約書＜第一版＞を、 また、平成20年4月には、中小企業の取引の多数を占めるパッケージ・SaaS・ASP型の取引について「重要事項説明書」を活用した簡易・透明な取引モデルを前提条件とするモデル取引・契約書＜追補版＞を策定・公表しました。 本モデル取引・契約書の活用により、情報システム取引の可視化、信頼性の向上等が期待されます。
実践的アプローチに基づく要求仕様の発注者ビュー検討会（以下、発注者ビュー検討会）は3月18日、2007年9月に公開した「発注者ビューガイドライン（画面編）」に続き、「同（システム振る舞い編）」と「同（データモデル編）」を策定し、同日から公式Webサイトにて公開すると発表した。 発注者ビュー検討会は、顧客（発注者）とSIベンダ（開発者）間でのコミュニケーションの円滑化を促進すべく、システム開発における仕様記述方法および合意方法を共同で検討し、ガイドライン化することを目的とした団体。NTTデータ、富士通、NEC、日立、構造計画研究所、東芝ソリューション、日本ユニシス、OKI、TISの9社が企業の枠を超えそれぞれのノウハウを惜しみなく提供。一丸となって、外部設計の工程（非機能要件を除く）におけるわかりやすい設計書の書き方、およびそのレビューのコツをガイドラインとして取りまとめてきた。 今回発表さ
ベンダーから見積もりを取っても、その妥当性が分からない――IT部門が以前から抱える課題の1つだ。確かに、ITコストは変動要因が多いために相場がない、業界が未成熟、という面はある。それでも、見積もりの基準を提示する、第三者の客観的評価を利用するなど、主体的にITコストの妥当性を把握しようというユーザー企業が登場してきた。一方のベンダーも、新会計基準である工事進行基準に対応すべく、明朗会計に動き始めている。 （市嶋 洋平、小原 忍） 本記事は日経コンピュータ3月15日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。本「特集1」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしています。 なお本号のご購入はバックナンバーをご利用ください。 「5社から見積もりをとったところ、最も高いベンダーと低いベンダーの差は4億円近かった」。
こんにちは！やまもと＠テスト番長です。 TestingGeekという耳障りの良い名前のサイトをご存知でしょうか？ 総合的にテストの話を取り扱っており、それでいて読みやすいサイトです。 そこのTemplatesのコーナーにWeb Application Testing Checklist という便利そうなものがありましたので、日本語にしてみました。 ちょっとそのままだと物足りない感がありますが、テストポリシー作成の叩き台に使ってみるのも良さそうですね。 この手のリストを他にもご存知の方がいらっしゃれば、是非ご一報ください。 1. 機能テスト 1.1 リンク 1.1.1 記載された通りの先に遷移するか 1.1.2 どこからもリンクされないページは存在しないか 1.1.3 全ての外部リンク 1.1.4 参照しているサイトおよびメールアドレスはハイパーリンクになっているか？ 1.1
最終回です。今回は，ある意味IT業界の禁忌に触れてみます。Web＋DBシステムを発注したときの見積もり額の秘密です。システムが目指す最終的な目的は”利益を上げられる仕組みの構築”です。見積もり額は利益算定の一番わかりやすいコスト判断ですが，果たして構築費用はどういう計算で生まれているのでしょうか。 利益を上げるコツは「身の丈に合った投資」をすること 利益を上げるためにはどうするべきか。私は経済評論家ではありませんから，あれやこれや難しい話はできません。ただ物事の本質は，実はいつだって単純なものです。バサっと単純明快に言い切ってしまいましょう。「自分の身の丈に合った額を投入すること」です。 決して都会とは言い切れない我が家周辺では，冬になると焼き芋の巡回販売車が回ってきます。焼き芋屋さんのほとんどは軽トラックを使っています。なぜ軽トラックなのでしょうか？ つまらないことに見えますが，これがビ
システム・インテグレータなどITサービス会社は間もなく，トップマネジメントから現場の営業，開発に至るまで抜本的な変革に迫られる。これは「そうしなければ勝ち残れない」といった類の話ではない。2009年4月にも予定される会計基準の変更がITサービス業を直撃するためで，顧客との厳格な契約と正確な原価見積もり，精緻なプロジェクト管理などが実践できない限り，事業の継続自体が不可能になりかねないのだ。 今回の会計基準の変更では，SI（システム・インテグレーション）案件などで「工事進行基準」による会計処理が事実上義務づけられる。現行の「完成基準」は，システム開発が完了し検収書を受け取ってから売上を計上する。これに対して，工事進行基準はプロジェクトの進ちょく状況に合わせて売上を“分散計上”する。一見すると，単なる会計処理の方法の変更だが，営業担当者やSEの業務にも多大な影響を及ぼすことになる。 工事進行基
「確かにプロジェクトマネジメント（PM）を持ち上げる記事を沢山書きましたよ。PMって，前向きな話だと思っていたのですが…」。 信頼がおける人，あるいは敬意を抱いている人から面と向かって，「あなたが悪い」「責任は重大だ」ときっぱり言われると正直な話，かなり落ち込む。こうした人には会わないようにすればいいのだが，色々と教えて欲しいことがあり，しばらくしてまたお目にかかると，同じ批判を繰り返される。 何の話かと言うと，PMについてである。もう6年くらい前になろうか，日経コンピュータの副編集長をしていた時，PMについて特集記事をまとめたり，専門家に寄稿を頼んだり，ITproにコラムを書いたり，セミナーを主催したり，本を作ったり，と実に色々なことをした。そうした活動の集大成が日経コンピュータ2002年4月22日号に掲載した特集記事「プロジェクトマネジメントが日本を救う」であった。 この雑誌が出版され
先日のエントリーがアツいことになっており、初のホッテントリ入りに若干興奮している今日この頃です。同じような問題意識を持っておられる方が多くいらっしゃることがわかり、改めて書いてよかったなぁと思っています。 話の流れは相当グダグダなのですがあのエントリーで表現したかったことは、「アメリカにSIerが存在しないのである」⇒「アメリカは素晴らしいのである」というのが骨子ではなく、いわゆるディフェンシブなシステム開発を強いられているSIerというのは、いわば奇形児のような存在ではないかということです。 改めて、ディフェンシブとは 言わずと知れた名エントリから。 ディフェンシブな開発とは、開発途上のリスクを計画上の時点でなるべく潰し、開発側に発生する利益分を減らさないような開発の進め方をすることを言っている。加えて、この場合、開発側はリスク分はなるべく多めに見積もり金額にいれようとしがちだ。 なぜそ
NTTデータなどSIer9社は本日、情報システムの開発における外部設計段階で活用する「発注者ビューガイドライン（画面編）」の公開を始めることを発表した。発注者ビューガイドライン（画面編）は、システム開発における画面を作成するための記述方法や内容の確認の仕方に関する留意点やノウハウをまとめた文書。ユーザー企業とSIerが誤った理解を防いだり、認識のズレが起きないようにしたりするために活用するものである。このガイドラインは 「発注者ビュー検討会」の公式ホームページで公開している。 2006年4月に発足した「実践的アプローチに基づく要求仕様の発注者ビューの検討会」での成果物の第1弾である。NTTデータや富士通、日立製作所、NEC、構造計画研究所、東芝ソリューションが共同で作成した。「普段はライバルである6社が互いにノウハウを出し合うだけでなく、ユーザー企業である東京証券取引所などの強力を仰ぐこと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
