システム開発の虎ノ巻

プロマネ初級者必見!システム開発の鉄板ノウハウをいつでも使える形に!徐々に充実させていきます!

<基本設計のポイント>【UI設計】コントロール部品の特性を理解する

ユーザーが画面上で扱うコントロール部品にはいくつか種類があります。どんな画面でもそれら数種類のコントロール部品の組み合わせで出来ています。そのため、画面設計をする際にはシステムサイドがそれらのコントロール部品の特性を理解しておかないと、ユ…

<基本設計のポイント>【UI設計】画面設計のポイント

WEBシステムでも業務システムでも、使う側が誤認してしまうような入力ボックス、ボタン、リンクなどに出会ったことってありますでしょうか?最近のホームページなどを含むWEBシステムでは、よくできたテンプレートが用意されていることも多いし、フルスクラ…

<基本設計のポイント>【UI設計】インターフェースの洗い出し

基本設計工程は、ユーザーレビューを繰り返しながら設計仕様を固めていく工程ですが、まずはユーザー・インターフェース(UI)設計が取っつきやすいと思います。ユーザー・インターフェース(UI)設計とは、システムとユーザーの設定となる箇所の設計のこと…

<基本設計のポイント>要件定義工程との違い

基本設計では、要件定義工程で確認された要件をインプットとして進めていきます。要件定義工程では、「何を」行うか?または実現するのか?という観点で整理してきたと思いますが、基本設計では、それらを「どうように」行うのか?を定義していきます。 ポイ…

<要件定義のポイント>資料の作成と承認

要件定義書は、その後の業務受入テストのテストシナリオを作成する際に参照する文書となります。そのため、ドキュメントが最新かつ正確な状態になっていなければ、誤ったテストケースを設定することになってしまい、いざテストを実施して不具合が発生した際…

<要件定義のポイント>ER図の書き方・考え方

ER図は、人、物、情報といった対象をエンティティとして長方形で表し、エンティティ同士をリレーションと呼ばれる線で結んで表現します。また、エンティティは、データ項目やキー項目を属性として表現するようにします。 まず、リレーションについてですが、…

<要件定義のポイント>DFDは上流から作成して下流へブレークダウン

先に述べたDFD(Data Flow Diagram)を作成する手順としては、最上流の(端的に言うと一番大雑把な)業務プロセスから作成していきます。これをレベル1とします。これは通常、業務全体を構成する複数のプロセス・ボックスと、主要なデータ・フローやデータ…

<要件定義のポイント>DFDとユースケース図とER図

要件定義書は、システム側とユーザー側の双方が確認しあうドキュメントとなるので、文章だけでなく図表などで表現することが結構重要になってきます。その図表に相当する中でよく使われる(と思ってる)DFD(Data Flow Diagram)とユースケース図とER(Entit…

<要件定義のポイント>あいまいな表現を排除しよう

要件定義書を眺めてみてください。その文章の中に、「最適な/十分な/簡単に/必要最低限の/常に/数回程度の/速い/~など/ハイアベイラビリティー」などの言葉が使われている場面はないでしょうか?もし、これらの用語が使われているとすれば、その部…

<要件定義のポイント>機能要件と非機能要件

要件定義のまとめ方は本当に人それぞれと言っていいくらいテンプレートと呼べるようなものはあまり見られません。ただし、どれも最低限これだけは、という項目はあるのでそれについて述べたいと思います。 ます、機能要件ですが、「機能」と名のついている通…

<要件定義のポイント>小さく生んで大きく育てる

要件定義工程は、ユーザーが最も自由に「あれもこれも欲しい」と我がままを言える工程です。なので、ユーザーの要望を出来るだけ叶えたいという気持ち自身は大事ですが、お互いにWin-Winの結果にするには、要件を絞りに絞ってコンパクトに開発することも時に…

<要件定義のポイント>費用対効果を考える

要件が多くなりすぎて、コストとの見合いで要件の絞り込みが必要となる場面は、ほとんどのプロジェクトで発生することだと思います。そのような時は当然、重みづけをして優先順位を決めて足切りをしなければなりません。重みづけについては決まりなんてもの…

<要件定義のポイント>追加要件や要件変更は発生することを前提にせよ!

要件定義工程の主な目的は、「業務要件を明確にしてシステム要件に落とし込む」ことで、要件を漏れなく洗い出して明確にすることです。しかし、現実には「人間だもの」、すべてを完璧にこなせる訳ではなく、時間が経てば意見も見方も変わることがあるし、体…

<要件定義のポイント>業務受入テストを意識せよ!

要件定義を行っている今の段階でこそ、業務受入テストをテストシナリオを意識しましょう。みなさんもV字モデルはご存じでしょう。開発したプログラムの妥当性を単体テストで確認するように、要件定義の妥当性は業務受入テスト(組織によって呼び方は多少変わ…

<要件定義のポイント>エンドユーザーのITリテラシーを意識せよ!

要件定義に参加しているユーザーって、多くは業務知識もあってITリテラシーも高いユーザー側の代表者だったりしていますよね?で、システム側はそのユーザー側の代表者がシステムの利用者だと思い込んでることって意外と多いと思います。実際にその通りで合…

<要件定義のポイント>エンドユーザーのITリテラシーを意識せよ!

要件定義に参加しているユーザーって、多くは業務知識もあってITリテラシーも高いユーザー側の代表者だったりしていますよね?で、システム側はそのユーザー側の代表者がシステムの利用者だと思い込んでることって意外と多いと思います。実際にその通りで合…

<要件定義のポイント>コストや納期を柔軟に捉える

ヒアリングの結果、業務要件が膨らむなんてことは日常茶飯事ですよね。しかも、どれも「必須」なんて枕詞がついて回ったりします。 仮に開発しているシステムが、新年度(多くは4月1日)からの利用開始が絶対条件だとしても、「必須」の業務要件のすべてを実…

<要件定義のポイント>HowよりWhatを見逃すな!

要件定義の段階で、「それは難しいです」とか「それなら実現可能です」のようなやり取りをしてしまいがちですが、これはやってはいけないやり取りです。 このようなやり取りが発生する前提は何かと考えてみると、プロマネや開発担当者の頭の中には、どのよう…

<要件定義のポイント>スコープで要件の肥大化を防止する

ユーザーからのヒアリングで業務要件の洗い出しが終わったら次の工程へ、とはいきません。まずは、業務要件を整理・分析することが必要です。 ヒアリングで入手した情報の中には、システムによって実施する方が効率が良い部分もあれば、人間にしか出来なかっ…

<要件定義のポイント>大事なのは「想像力」

要件定義において重要な要素と言われるともちろん色々ありますが、システム部門に必要な要素を3つ挙げよ、と言われたら即座に「業務知識」「ヒアリング力」「想像力」と私は言います。 業務をきちんと理解していなければ、いくら設計や開発のスペシャリスト…

<要件定義のポイント>プロトタイプでニーズを掘り起こす

業務要件をヒアリングしているときにユーザーが語れるのは、その時にユーザー自身が気づいていることについてのみです。それは本当の要件の一部だけかもしれません。要件定義の段階でユーザー要件を出し切ろうと思ったらヒアリングだけでは不足する場合が往…

<要件定義のポイント>ユーザー側に当事者意識を持ってもらう

ユーザー側にシステム開発基準などが整備されていて、ユーザー側の責任が明文化されている場合は、それを盾にすることができますが、そのようなものがあっても無くても、ユーザーには積極的に意見を出してもらい、決めるという判断をしてもらい、最終的にコ…

<要件定義のポイント>シノニムとホモニム

別の記事にも書きましたが、要件定義工程では「用語の統一」が結構大事なことだったりします。例えば、「商品」という言葉1つとっても、商品部の人だと今開発中の商品(つまり、市場に売り出していない商品)のことを指していることが多いですし、営業が商…

<要件定義のポイント>ステークホルダーの重要性

みなさん、システム開発プロジェクトを進めているときにステークホルダーを意識しますよね。ただ単に体制図に載っているよ、てことではなく、ラインの意思決定ルートを確認したり、キーマンはこの人とか政治力学的には誰が上位にいるとか、ベンダーの窓口は…

<要件定義のポイント>ヒアリングで抑えるべき諸条件

業務要件のヒアリングに際しては、業務フローにもとづいて細かい手順についても突っ込んでヒアリングしていると思います。その際に、いつ・誰が・何をインプットとして・どのような条件で・いつまでに・何をアウトプットするのか、などは大体ヒアリングして…

<要件定義のポイント>ヒアリングはオープン・クエスチョンを駆使しよう!

ユーザー側の要件(実現したいこと)を引き出すことは、業務要件を定義するうえでは欠かせません。みなさんは、どんなやり方、どんなことに気をつけてやってますか? まず、業務要件を整理するためには、ユーザーの課題を明らかにしなければいけない訳ですが…

<要件定義のポイント>「用語」と「常識」に注意!

要件定義で最も気をつけるべきものの1つに「用語」があります。 同じ言葉でも、ユーザーと開発担当者、ユーザー同士でも部署によって特定の言葉の持つ意味や範囲が異なる場合です。たとえば、「商品」という用語1つ見てみても、ユーザー同士でも部門が異な…

<要件定義のポイント>ヒアリングの前に現状把握

さあ、システムを開発するにあたって、まず最初は要件定義から入りますよね? 組織によって、場合によっては、「企画工程」みたいなのから入る方もいらっしゃるかもしれませんが、企画なんて(と言っては怒られそうですが)「こんなことしたい」や「こうあっ…