今回から「受発注システム」を想定して，データモデルを発注者と合意するためのコツを詳細に説明していきましょう。 前回述べたように，データモデルは発注者にとって難しいものです。このため，詳細なデータモデリングに進んだ時点からいきなりレビューを始めるのではなく，発注者と開発者の双方の理解できる，データモデルの概要がわかる全体図を使ってレビューを始めます。 最初に発注者と開発者がデータモデルの全体像を共有していれば，これがデータモデルの予備知識となり，後に続くレビューをスムーズに実施できるようになります。今回は，データモデルのレビューに欠かせない，2つの全体図を紹介しましょう。 概要図でエンティティの候補を確認する まずデータモデリングの第一段階として，対象となるシステムにはどのような業務があり，それにはどのようなデータが結びついていて，お互いにどのような関連を持っているのかというデータモデルの全

画面設計書について，前回に引き続き，それを書くツールや手法について考えてみましょう。 画面設計書の基本 まずは，画面設計書の中にあるべき情報から見てみましょう。これらすべてがそろっていなければならない，というわけではありませんが，望ましいのではないかと私自身は考えています。 header ページIDやタイトルなど，一目でそのページがどの画面仕様を記述しているかがわかるような「ヘッダー」部分。細かく書くならば，文字コードや対象ブラウザまで記述する場合もある。また，プロジェクトの名前（プロジェクト・コード）や版番号なども記し，似たようなドキュメントの中からも引き出せるようにしておく。 footer 制作サイドのコピーライトやページ番号などを記す。最終的には，クライアントのコピーライトに置き直して，最終納品とする場合もある。 Page Layout 画面内に配置する「ユーザー・インタフェース（U

前回までは，システム振舞いと画面設計に関する工程成果物の書き方のコツとレビューのコツを紹介してきました。今回からは，［データモデル編］と題して，データモデルのレビューのコツを紹介していきます。 始めに，データモデルを表現するための工程成果物を説明しておきましょう。データモデルに必要な成果物は，各社でさまざまな定義をしていますが，「発注者ビュー検討会」では，次の4種類を，データモデルに関する工程成果物として定義しました。 ■ER図 情報のまとまりを「エンティティ（Entity）」，情報の相互関係を「リレーションシップ（Relationship）」で表したものです。

設計書の書き方には絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなる。標準の設計フォームや設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。 一般によく言われることだが，設計書の書き方には「正解」や「こうしなければならない」という絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなり，完成した設計書の内容と質は設計者ごとに大きく異なる――といった結果に陥りやすい。 もちろん，標準の設計フォーム（ひな型）や設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。一

新法で「アプリストアを競争状態に」の現実味、公取委はApple・Googleと長期戦も 2024.05.16

みなさんは，外部設計書を誰に読んでもらい，理解してもらおうとして思って作成していますか？レビューしてもらう開発プロジェクトのリーダー向けですか，後工程でプログラミングを担当してもらう技術者向けですか，それとも自分のためですか？ もちろん外部設計書は，リーダーも読みますし，プログラミングを担当する技術者も見ます。しかし最も大切なことは，「システム開発を依頼してきたお客様」（発注者）に読んでもらい，理解してもらうことです。上の質問に対して，「お客様」と自信を持って回答できることが，今の技術者に求められているのです。 外部設計書を，開発メンバーではなく，発注者に理解してもらうためには，「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。 とはいえこれまでは，「発注者に理解してもらう」という観点での外部設計の体系的なノウハウはほ