先に誰もブックマークしてなかった。→ちょっと躊躇する。 え、みんなブックマークしないってことはあんまりすごくない?俺がはしゃいでるだけ? ブコメが盛大についてた。但しものすごい過去に。→無言ブクマ 会話に加わりたかったorz このダジャレ、スターもらえただろうなぁ
先に誰もブックマークしてなかった。→ちょっと躊躇する。 え、みんなブックマークしないってことはあんまりすごくない?俺がはしゃいでるだけ? ブコメが盛大についてた。但しものすごい過去に。→無言ブクマ 会話に加わりたかったorz このダジャレ、スターもらえただろうなぁ
僕が今やってる例のプロジェクト*1で、 この前、設計書を作ってお客さんに確認してもらった。 分厚い設計書で、何回も社内レビューをしてもらって、 メッセージIDのマッピングなど細かい点をイライラしながら直して 何度も印刷して、「最終版」、「最終版2」、「本当の最終版」という お馴染みのサブディレクトリができて、 やっとの思いでお客さんに提出したんだけど、どうやらぜんぜん見てくれてないみたいだ。 しかし、一緒に提出したユーザーマニュアルには、隅々まで目を通してくれていた。 お陰で、重要な仕様の誤解を発見することが出来た。 ユーザーマニュアルはそのままHTML化されて、 システムのHELPボタンから呼び出されるから、 お客さんとしても念入りにチェックしてくれたんだ。 ところで、設計書には大きく3つの役割がある。 ・お客さんが仕様を確認するため ・エンジニアが実装するため ・保守のため 僕は今回、
マニュアルを書くのはオススメ。プログラムの世界以外でもかなり有用だよ。 設計書よりもユーザーマニュアルを書こう! - レベルエンター山本大のブログ 設計書に書かれた処理の手順なんてのを読んでも機能についてピンとこないが、 ユーザーマニュアルなら分かる。 なぜなら、分かるように書かなくてはならないからだ。 分かりやすくなくては、マニュアルの存在意義に関わる。 設計書よりもユーザーマニュアルを書こう! - レベルエンター山本大のブログ こういう要素があるからこそ、書き手にとっていいトレーニングになるんですよ。取り組んでいることへの理解が進むし、ポイントの整理ができる。そして顧客の要望とか、需要なんかをつかみやすくなると思うんですよね。 読む人はプロではない 基本的にですよ、マニュアルというのは説明書なわけですよ。単純に考えてね。でだ、説明書が必要な人ってのは、使い方がわからないわけですな。知識
もしもこの世から「残業」が完全になくなったら 3年ぐらい前に読んだ本を思い出した。 1980−90年代の話ですが、残業について、 「時間外・休日労働の弾力的運用が我が国の労使慣行の下で雇用維持の機能をはたしている」(1985年労働基準法研究会報告)とか、「我が国の労働慣行の実情に合うような上限設定が可能かどうか定かでない」(1992年同報告)と、雇用維持の為のコストとして恒常的な長時間労働を是認する考え方が主流でした。 需要の低下に応じて、生産水準を下げなくてはならなくなっても、バッファがあるから解雇せずに大丈夫でしょ、という。。。 まぁ、 ところが、その後、労働法政策が内部労働市場の雇用維持から外部労働市場における移動促進に徐々にシフトしていったにもかかわらず、この長時間労働哲学には疑問が呈されないまま21世紀に至っているのです。 と著者は問題視しているわけだけど。 話変わって、最近友人
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く