要求定義のプロセスにおいて、多くの関係者から要求を引き出して、それを整理して要件としてまとめることが大切です。それには多くの方法や考え方がありますが、ここでは情報処理技術者試験で出題されたものを中心に列挙するだけにします。また、要求分析とはやや離れるかもしれませんが、問題解決技法もここに入れておきます。 専門家の意見聴取 インタービュー ヒアリングともいいます。ユーザから要求を引き出すのに最も広く用いられます。 実施にあたっては、次の事項に留意することが必要です。 適切な回答者の選出：単に現在の担当や職制で選ぶのではなく、業務をよく知っており問題意識の高い人を選ぶことが必要です。 的確な質問の事前準備：回答者の一方的な話を聞くのでは、回答者が気づかなかった（話すのを忘れた）事項が欠けてしまいます。事前に質問リストを作成しておくこと、場合によっては、それを事前に回答者に渡して準備してもらうと

学習のポイント 情報処理技術者試験では，グラフの種類や特徴を聞く問題が多く出題されます。ここでは，よく出題されるものを集めました。 キーワード 棒グラフ，積上げ棒グラフ，ピラミッドグラフ，折れ線グラフ，層グラフ，複合グラフ，円グラフ，ドーナッツグラフ，二重円グラフ，帯グラフ，レーダーチャート，円交差図，Ｚグラフ，ポートフォリオ図，デシジョンツリー，特性要因図，ヒストグラム，パレート図，散布図，管理図，連関図，親和図，系統図，ＰＤＰＣ，ガントチャート，アローダイアグラム 一般に広く用いられるグラフ 大小比較を表すグラフ 棒グラフは，最も基本的なグラフで汎用的に用いられます。 下図のＡは「ほとんど差異がない」ことを示しています。それに対してＢは「差異が大きい」ことを強調するときに用います。このときには図のように，５０より下が省略されていることを明示することが必要です。 このような方法は折れ線グ

過去問題：「プロジェクト管理」（project） テストの方法 出来上がったシステムを実施移行するには、システムが正しく動くか、実際に用いる性能があるかなどをテストする必要があります。初級シスアドでは、この分野からの出題が多いので、別章にて取り扱います。 ●参照：「テストの方法」（kj-test-kiso） ●過去問題：「テストの種類」（test-syurui）、 「テストの方法」（test-houhou） システムの保守・運用 日常的な運用管理 データの入力・修正 誤ったデータがコンピュータに入ると、多様なシステムに影響するし、エラーを探すのが困難なので、入力時のデータチェックシステムを整備することが必要です。 データの入力や修正は、責任を明確にするために、そのデータが発生した現業部門が行うのが適切です。情報システム部門が代行する場合は、処理結果リストをユーザ部門に送付して確認をとること

キーワード グループウェア、プロジェクトチーム、バーチャル組織 社内での電子メールや電子掲示板を主とする利用形態をグループウェアといいます。これを活用することにより、階層や部門の壁を超えて情報が伝達できます。また、上司と部下の情報交換も便利になるため、多数の部下の行動を掌握することができ、管理スパンを大きくすることができます。 グループウェアの効果として「教えて・教えます」の掲示板があります☆。その例を示します。 新しい顧客を訪問することを掲示板に掲げたところ、他の部門の人から、その顧客の購買部門と同級生であることを知らされ、同行してもらった。 営業が顧客から製品の不満を聞いた。その掲示板を見た人から多くのアイデアが寄せられ、それを参考に技術部が改良して特許をとった。 業務改善の提案をしたところ、多くの人から賛同や実現のための方法などについて意見が出され、全社的な運動として取り組むことにな

提案依頼書の作成 発注者とベンダとの間で重要な文書は，提案依頼書と開発契約書です。提案依頼書は，開発するべき情報システムの要件をベンダに示して，提案を依頼する文書です。期待する情報システムを得るには，適切な提案依頼書を作成することが重要ですが，不慣れな中小企業では，それを作成することが困難であること，コンサルタントを利用すべきことを示します。 開発契約での留意点 トラブルを回避するには適切な契約が重要です。契約の標準的なものとしてＪＩＳＡ（情報サービス産業協会）による「ソフトウェア開発委託モデル契約」を紹介し，中小企業がそれを利用するときの留意点を示します。また，ＳＬＡ（サービスレベル合意）が必要なことを示します。 コンサルタントの利用法 提案依頼や開発契約を適切なものにするには，専門家であるコンサルタントの協力が必要です。コンサルタントを利用するときの留意事項を示します。 はじめてのシス

情報活用のためにはエンドユーザ・コンピューティング（ＥＵＣ）が重要だといわれ，多くの企業でＥＵＣの推進が積極的に行われています。私は世界的にも早期な１９７８年に情報検索系システムでのＥＵＣを企画して実現し，その後，その発展に努力してきました。また他社へのアドバイスもしてきましたが，ＥＵＣの推進方法が不適切で期待とは逆の状況になっている例も見聞しました。ここでは，ＥＵＣ推進について，落とし穴に気をつけて事前に回避することが必要であることを，教科書的な事項ではなくノウハウ的に説明します。 そもそもＥＵＣとは？　ＥＵＣの定義と形態 情報システムを利用形態から区分すると，基幹業務系システム，情報検索系システム，コミュニケーション系システム（グループウェア），パソコンの利用の４つになります。そして，ＥＵＣを「情報システム部門以外の人が，コンピュータを自主的に操作することにより，自分あるいは自部門の業

情報化投資にはインフラ投資と個別アプリ投資があり，インフラ投資の評価が難しいことは別章「インフラ投資と個別アプリ投資の違い」で述べました。ここでは，個別アプリ開発での投資に特有なわかりにくさを取り上げます。 また，情報化の効果には定性的・戦略的効果があるがそれを定量的に把握することの問題についても別章「現在価値法やＤＣＦ法の限界」で扱いました。ここでは，情報化投資では，当初の計画と結果との間に大きな違いが発生する危険が多いことについて考えます。将来のことは不確実なので，期待と結果に差異があるのはどの投資でも発生しますが，特に情報化投資ではそれが大きいのが特徴です。 効果把握の複雑性 情報システムの効果がわかりにくいのは，情報システムという無形なものの価値を考えることの難しさでもあります。また，情報システムの発展により複雑性が増加したために，効果そのものが何なのかがわかりにくくなっています。