0.レビューについて書いてみたい お疲れ様です。 現在の現場で他の方が開発されたものの レビューを担当させていただいているへっぽこエンジニアです。 なお、まだまだ経験の浅い初心者なのですが、 自身の今後のためや、他にレビューを担当される方、 今後レビューを受けることが増えるかた、 エンジニアになったばかりの方向けに伝えたいと思い記述してます。 「レビューを担当してる」って話をすると 「そもそもレビューってどうやってるの？」 「複数人のチームでやってるんだよね？どうやるの」 といった「レビューの観点」や「レビューの方法」に 関する議論をしていたので、ちらっと書いてみたいと思います。 1.そもそもレビューって何なんだ？ １ 再調査。再検討。 ２ 批評記事。文芸・芸能などに関する評論。論評。また、評論雑誌。 システム開発において、工程ごとに成果物の品質を検証する会議。レビューの方法には、開発に携

※1　例 A「入力情報をテーブルに登録する」 B「入力された情報をテーブルに登録する」 ※2　例 ×「検索結果が0件の場合はメッセージをを表示する」 ○「検索結果が0件の場合はメッセージを表示する」 1.5　想定読者を決めよう レビューをしていると、内容の良し悪しではなく、わかりやすいかわかりにくいかの議論になることがある。Aさんにはわかりづらいが、Bさんには何も問題がないということがある。その原因が、読者の経験やスキルによるものでかもしれない。読者の経験やスキルが高いことを前提にすれば、説明は少なくて済むことが多い。一方、経験やスキルが低いことを前提にすれば、説明はしっかりしなければならない。どちらを基準にするか。これを事前に決めておくと手戻りが少なくなるだろう。 2　ドキュメント作成で気をつけること 2.1　他ページや他ドキュメントの参照を正しく表記しておこう 作成しているドキュメント

設計書を「使える化」するために 背景 今のままでは設計書は不良債権と化してしまう。 なんとか設計書を「使える化」しないといけない。 すでに設計書はあるが、よくわからない状態を想定しています。 哲学 何か聞くにしても設計書を自分で書く 君が書いたものが設計書なんだよっていうようなことを教えてもらったことがあります。 そこからお客さんに見せる設計書ができるかどうかはわかんないです。 そこにとらわれると何もできなくなってしまうと思います。 今回は詳細設計が終わって以降残骸のような設計書をなんとか「使える化」 する話です。 作るもの 実行計画・・・設計書一覧のこと 機能一覧・・・本当の一覧でいいと思います。 画面遷移図・・・あり物の図をパワーポイントに貼り付ける。無ければ四角をつなぐぐらいで作る。 状態図・・・全て網羅を考えず、主要なものを1つ2つ作る 主要テーブル・またはER・・・処理系・非処理

システム開発に関わる機会が多くなってきたので、仕様書作成に関して色々とメモ。 ウォーターフォールモデルでの上流工程について記述していく。 上流工程は 「要件定義」→「外部設計」→「内部設計」の流れに従って進められていく。 要件定義 開発するシステムに求められている機能などの要件をまとめる事。 例えば 「パスワード認証」「データベース内検索」などの機能要件 「入力データ」「出力データ」の仕様 「保守性」「操作性」などの非機能要件 業務フロー などが挙げられる。 RFP(提案依頼書)作成や事前調査などを行って、本当に必要な要件をじっくりと精査していく。 ココでまとめた内容を元に開発が進められる為、洗礼された要件定義を行うことで見落としによる仕様変更の回数を減らす事が出来る。 要件定義時に扱うのは必ず保証しなければならない項目が中心であり、UIデザインなどのデベロッパー側が決めても構わない部分は

この記事では、基本設計フェーズで作成する各種のドキュメントの中で、特にビジネスロジックに関する基本設計書に関して、よりよいドキュメントを作成したい方のためのノウハウを提供します。 1. はじめに 1.1. 基本設計書は大切なドキュメント 「基本設計」という言葉は、ITシステムに関する仕事をされている方においては、知らない人がいないであろう言葉だと思います。 そしてこの基本設計における各種のドキュメント、特にビジネスロジックを記載した基本設計書（以下、基本設計書）は、業務を担当するユーザ側担当者（以下、ユーザ）とシステムを構築する設計担当者（以下、設計者）の心の架け橋となる、大切なドキュメントです。 1.2. うまくいかない基本設計 しかし世の中のシステム構築の現場では、この基本設計書がうまく書けていないがためにユーザと設計者の間で心が通わず、結果的に完成したシステムがユーザが予想していたも

突然要件定義と基本設計で決めなきゃいけないこと洗い出してーと言われて困ってしまった。 僕はその工程の経験ないんだけど・・・とも言えずに付け焼刃的に勉強した内容をまとめてみる。 個人的に今後ブラッシュアップできればいいなあと思う記事。 必要なドキュメントの洗い出しや自分の作業漏れのチェックに使っていきたい。

要件定義、基本設計、詳細設計の各フェーズで、何を目的に作業するのか、その作業によりどんなメリットがあるのか、設計におけるポイントは何か、といったことを整理するために記事を書きました。 エンジニア1年目の設計初心者が書いたものですので、間違いやご指摘がありましたら教えていただけますと嬉しいです。 要件定義とは、システムやソフトウェアの開発において、実装すべき機能や満たすべき性能を明確にする作業のことです。 開発対象となる機能の一覧を作成する作業と説明しているものもありました。 要件定義の目的 要件定義の目的は、次のようなものかと思います。 要求や要件の漏れによる大幅な手戻りを防ぐ システムで実現できること・できないことを明確にして関係者間で同意を得る 要件を明確にすることで実装やテストをスムーズに進める 要件定義のポイント 要求や要件の漏れを防ぐ 要求や要件に漏れがあることが後になってわかる

はじめに IT企業に転職し、開発に携わる機会が増えてきたのでシステム開発の工程の一つである 『外部設計』と『内部設計』について調べたので記事にします。 システム設計の流れ 基本的な流れとして最初に要件定義を行い、次に外部設計を行い、外部設計を基に内部設計を行う。 要件定義とは クライアントが求めている機能に対して、システムの使用や範囲を決める。 例として、必要な機能、性能、要求されている信頼性や保守性などクライアントの要望に合わせ要件定義書を作成する。要件定義書の精度が高ければ、外部設計が行いやすくなる。 一言まとめ クライアントが求めてる機能を、要件定義書に起こす。 要件定義で定義した、機能、性能、制約条件を基にシステム設計を行う。 主に、UIなどユーザーから見える部分の仕様を決定したり、セキュリティ、運用規定、システム開発のスケジュール、費用などの設計を行う。 一言まとめ ユーザー側の

プロジェクトを始める場合、まず、何をするかというと、プロジェクト計画を行い、プロジェクト計画書を記述します。 ※ 企画、見積もりが終わっている体でのお話です 開発者の皆さんは、プロジェクトはすっと始まり、頑張って設計して、実装して、テストして、リリースして、完了する。というような考えを持っているかもしれませんが、まず、プロジェクトマネージャがプロジェクト計画を始めます。 そのプロジェクト計画について記述します。 各項目で、本が1冊出来るようなものなので、ここではざっくり理解が出来ればと・・・ プロジェクト計画書って何？ プロジェクト計画書とは、読んで字のごとく、プロジェクトの計画をするのもです。 大まかには、「企画をもとに、どんな目的で、どんな風に、どういうルールで、いつまでに、開発しますよ」ということを記述します。 企画に対しての5W1Hを書ければOK 小さいプロジェクトの場合や、歴史が