エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォータ
僕はこうやって画面設計書を作ってる（Webシステムにおける簡潔な画面設計書の例） - Qiita
Webシステムを作る上で、画面設計書を作成する事は多々あると思うんだけど、みんなどうやってるんだろうか。 取り敢えず、僕はこんな感じで作ってるよってのを紹介したいと思います。 小規模のプロジェクトで、ドキュメントIDとかプロジェクトIDとか使わなくてもいいような、管理が複雑でないプロジェクトを想定しています。 ルールとしては以下を守ってます。 画面設計書には画面遷移図の情報を含めない。 画面設計書は単一の画面の設計を掲載すべきと考える。 DBの操作、ビジネスロジック層に関する処理は画面設計書に記載しない。 別途アクション設計等に作成するべき。 Excel方眼紙を使わない。（←重要） 詳しくは後述。 参考にしたのは、以下のサイト。 ［画面設計］画面の構造は物理的・論理的に示す http://itpro.nikkeibp.co.jp/article/COLUMN/20090108/322455
新人さんに議事録の取り方をレクチャーしたときのメモ - Qiita
新人（とくに新卒）だと、軽率に「じゃ、今日の議事録とっといてね」なーんて頼まれたりする。 が、議事録は実はハードル高いミッションのうちの一つだと思う。 個人的に議事録を取るときに気をつけてることを、備忘録がてらまとめてみた。 ★ 議事録取りに臨む前に。事前準備編 議事録は難しい仕事だ。 5人を越える人数の会議で、しかも定例会議のようなずっと続いている会議の議事録取りは超やっかいなものと心得るべし。 ずっと続いてる過去の議事録あるから、おんなじ感じで取っといたらいいよとか言われる。 ワタシは初めてなんだよ！とは絶対言えないあの空気… 今まで議論してきた歴史があるから、何の話をしているのか、その前提が省略されがち。 ジャーゴン（独特の業界用語）も超出てくる。 前あったあの件はペンディングになったから とか どうやって議事録に取れと。何の件だよ。 上記のような理由のため、向こうの期待＞＞＞自分が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
iodocsで便利なREST APIドキュメントを作成する - Qiita
