メモを取るのはこの3点だけに絞れ - レベルエンター山本大のブログ
小飼さんのブログ「404 Blog Not Found:メモらぬ阿呆にメモる馬鹿」で、メモについて話題になっている。 仕事ではメモが重要だ、新人はとにかくメモをとれ・・・というのが一般論で、 TB元で話題にしてるのは「メモ不要論」に近い。 僕は基本的には「過剰メモNG」のスタンスだけど ALL or NOTHINGで議論せず、メモの内容を最低限に絞るべきだと考えている。 具体的には、僕はメモを以下の3つだけに絞っている。 1.あとで質問すること、疑問に思った点 2.日時・場所・数値 3."相手が"重要視しているキーワード 前提、メモ魔は結局話を聞いてない IT講師をやっていて思うことがある。 それは、授業にノートをがんばって取っている受講生さんが話を理解しているとは限らない。ということだ。 講義の場合は、うまくノートを作らせてあげたうえで話を理解してもらうのも講師の力量なんだけど、 ビジネ
メンテナンスに必要な設計書を、出来上がったシステムから考えてみる。 - レベルエンター山本大のブログ
かなり前のひがさんのブログを引用 仕様が固まった後に作成するドキュメントは、プログラムと一対一になるようなドキュメントではない。そんなのはプログラムを見ればすむ話だから。メンテナンスする人が必要になるドキュメントを書く。メンテナンスする人にとってはドキュメントは必要ですよ。全部ソース読めはきつい。 http://d.hatena.ne.jp/higayasuo/20080721/1216607451 さて、メンテナンスに必要な設計書ってどんなだろうか。 出来上がったシステムを見ながら考えてみる。 機能概要は必須 機能の概要がわかるものが欲しいけど、 ”機能”の一覧よりは、”要件”の一覧が良い。 例えば、「商品マスタデータのメンテナンス機能」だとしたら、 登録ボタンを押したら、画面の入力に従って商品データが登録される その際に、商品テーブルと価格テーブルと価格履歴テーブルにデータが登録される
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
