わたしが知らないスゴ本は、きっとあなたが読んでいる: 子どもに死を教える三冊
良い機会があった。遠い親戚が亡くなったのだ。 「良い」なんて不謹慎だけど、このご時世に大往生だから感謝しないと。家族総出で葬式に行く。テレビなどに任せず死の教育をやってきたつもりだが、百聞一見、葬式こそ最高の現場だ。 子どもに伝えたいたった一つのことは、以下に尽きる。 あんたまだ生きてるでしょ だから、しっかり生きて、それから死になさい しっかり生きてないと、ちゃんと死ぬことすらままならない…このメッセージをそのまま言っても分からない。まず、自分の「生」を大切にさせる。できるようになれば、家族の、ひいては他人の「生」へも目配りができるようになる。 自己であれ他者であれ、「生」を大切にできるようになれば、それを支える「生活」も大切にするだろうし、「生」を生み出す「性」も同様に扱えるようになる（はずだ）。 生の反対は死でない。しかし、死について考えることは生きる本質（文字通りの "qualit
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（まとめ）
この連載を始めたのは、Waterfall 2006を見たから。ついカッとなって書いてしまった。今は反省している。この連載は体系的じゃないし、blog よりむしろ出版物の形で問うべき。何よりも、今週の睡眠時間を大幅に犠牲にしてきたので、眠くてたまらん。 …というわけで、ここでは総括＋補足して締める。 ウォーターフォール・モデルとは、プロジェクト構造化モデルと言い換えられる。その特徴として、以下のことが挙げられる。（その1） プロジェクトを構造化し、段階を踏んで要素成果物を構築する 次に、必要な要素成果物を適切なタイミングで持ち寄り、組み上げる 要素成果物を構築する工程はスパイラル・モデルを適用できる。しかし、組み上げる工程は逐次的であることが求められる プロジェクトを構造化することにより、プロジェクトを「見える化」できる。全体と部分、出来てるところと空白のところが分かる。未確定事項がオープン
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その2）
ウォーターフォール・モデルとは一言で説明するなら、「プロジェクトの構造化」だ。逐次実行や先手管理、進捗の予実管理なんざ、特徴的だが本質ではない。それらはキチンと構造化された後に実現できる。プロジェクトの構造化をしないまま先手管理しようとするからおかしくなる。 プロジェクトの構造化はこうやる ウォーターフォールは逐次的な開発技法であり、ウォーターフォール全体として「分析>設計>製造>試験」とはならない。顧客受けしやすいようそんな絵を書くこともあるが、実質は異なる。 「すべきこと」単位に分解して、「すべきこと」同士の順序性を決めた後、「すべきこと」同士では逐次的な関係を守らせるようにすることが本当。 「すべきこと」の分け方は「分析」「設計」「製造」「試験」ではない。これらは分断するものではない。「なんちゃってウォーターフォール」をダメにしているのは、工程（＝フェーズ）ごとにチームを割り、それぞ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
