第28回 日本企業を見限ったインドの“システム屋”から学んだこと
経営者にとって、情報システムは頭痛の種になりがちだ。業務に必須だが投資に見合った効果が出るとは限らない。ほかの設備投資に比べて専門的で難解でもある。 野村総合研究所で約20年間勤務した後に、人材派遣大手スタッフサービスのCIO（最高情報責任者）を務め急成長を支えた著者が、ベンダーとユーザー両方の視点から、“システム屋”の思考回路と、上手な付き合い方を説く。 前回（第27回）で登場したインド人の“システム屋”経営者の言葉をもう1つ紹介したいと思います。彼から「日本企業向けの仕事はもうやりたくない」と言われたことがあります。英語力の問題ではなく、日本人はそもそもシステム開発に向いていないというのが彼の主張です。 これを聞いた私は、その場では苦笑するほかありませんでしたが、日本人の“システム屋”として悔しいという感情が残りました。しかし今ようやく、この意見には反論が可能だという思いに至りました。
上流工程-要件定義---目次：ITpro
10社製品の統合度合いを比較、カバー範囲が広いのはIDaaSを持つMicrosoft 2024.10.24
「漏れ」なく洗い出す知恵
まずは仕様バグの一つ目「漏れ」をなくす知恵を見ていこう。 漏れが起きる理由の一つは，エンドユーザーが要求を言い忘れることにある。例えば，サブシステムを追加したり，新システムにリプレースしたりするような案件の場合「エンドユーザーは新たに追加したい機能についての要求は出す。しかし，現行システムについては言及しない。『今のままで』で済まされてしまう。現行システムの仕様まで含めて要求を洗い出さなければならないので，これでは漏れが起きる」（CSKシステムズ IT生産技術部 副統括担当 白寄徹男氏）。 そのほか，エンドユーザーは“言わずもがな”だと思っていることは言わないし，そもそも要求定義で何を言えばよいかが分からないこともある。 漏れをなくすには，多くの要求をどうやって洗い出すか，業種/業務ごとに常識的な観点はきちんと考慮されているか，違う視点から見たら何か出てこないか――といったことがポイントに
図解を駆使して仕様バグをつぶす
図1●不適切なデータフロー図の例 要求定義と実装は分けて考えなければならないのに，それが交じっている。この段階で，データストアがファイルなのかテーブルなのかなどを定義すべきではない 便利な図解だが，使い方を間違えると役に立たない。まずは専門家に，「やってはいけない」ことを3点指摘してもらおう。 最初は「要求と実装を一緒に考えてはいけない」（オージス総研 取締役 ソリューション開発本部 副本部長 兼 アドバンストモデリングソリューション部 部長 山崎朝照氏）ということである。（図1）は要求定義でよく使われるデータフロー図（DFD）だが，書く内容が間違っている。「こうした不適切な図を前提に設計するとデータ構造がメチャメチャになる。メンテナンスに苦労する可能性が高い」（メタジトリー 取締役 松本聰氏）。 DFDでは，上下の二重線に囲まれた枠を「データストア」と呼び，処理されたデータの格納場所を表
エンドユーザーの要求は間違っている？
ムラウチドットコムの橋本昌巳氏（取締役システム担当）は，自社のECサイトの構築で，かつて次のような経験をした。 ある業務担当者に新機能が欲しいと言われて開発した。しかし，その機能を使うのはその人だけで，他の人は使わない。業務改善に寄与したかどうかも結局，分からなかった。担当者が異動すると，また「違うものを作ってくれ」という要求が出てきた。要求通りの機能を追加するうちにシステムはどんどん複雑化し，保守性が悪くなった。改修のコストも徐々にかさむようになってしまった…。 。 現場を取材していると，こうした要求定義（注1）にまつわる話は事欠かない（図1）。IPA（情報処理推進機構）のアンケート調査（注2）によると，9割の企業が「失敗プロジェクトの原因は要求定義にある」と考えている。野村総合研究所の堀崎修一氏（ITアーキテクチャーコンサルティング部 主任テクニカルエンジニア）は「業務要件の詰めの甘さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
