そもそも女は片づけなんてムリ。 「片づける=収納する=仕舞う」という固定観念から逃れることはできない。というのも、「なぜ片付けられないか」について唯一かつ根源的な原因が理解できないから→【答】モノが多すぎる。だから、仕舞うための「棚や箱というモノ」が部屋を占拠しはじめる。 ―― なんて嫁を挑発すると、「君のカイショーがないからだ」と一蹴。ごめんなさいがんばります。それでも、あふれるモノに侵蝕されているのは、わが家だけではない。だから、「持たない暮らし」なんてステキな本が出る。 本書の主張はシンプル。「もったいない」からといって、大量のモノを抱え込み、使いもせず、譲りもせず、捨てることもしない。そのうち、持っていることすら忘れてしまっている。死蔵品が部屋を占領しているのに気づかず、「収納できない…」と悩むのはバカバカしい。 だから、 使っていないものは、「使う人にあげる」、「売る」、「寄付す

長くなりすぎたこのエントリのレジュメ：選本の肝は本ではなく、人を探すこと。わたしが知らないスゴ本は、それこそ百万冊ある。その本そのものを探すのはとても難しい。しかし、百万冊のスゴ本は間違いなく誰かに読まれている（それは"あなた"かもしれない）。だから、スゴ本を読んでいる"あなた"を探す。このblogの究極目的も、そう。 メールやコメントでいただいた、以下の質問に答えてみる。誰かの参考になれば。 【質問】 Q1 たくさん本を読んでるようですが、速読をやっていますか? Q2 あるいは読書術のようなものはありますか? Q3 読む本はどうやって探していますか? 【回答】 A1 速読を練習したことありますが、実践してません A2 「目的を持って読む」に尽きます A3 本ではなく、人を探します 本は目的を持って読む あたりまえだとツッコミがくるだろうが、わたしはできていない。漫然と読んでるとあっという

ソーシャルエンジニアリングの第一歩は、「組織内の人に化けること」にある。イーサン・ハントみたく化けの皮を被る必要もない。もっと重要なのは、機密ではないが、組織内の人しか知りえないような情報を知っていること。例えば座席表やビルドサーバの名前だとか。 ひとたび組織内の人に化ける情報を得たならば、攻略はぐっと楽になる。「欺術」を参考に潜入を進めることができる（ホントにやっちゃダメよ）。ここでは、USBフラッシュメモリを使って最初のハードルを効率的に超える方法を考えてみよう。 オフィスの受付窓口の片隅や、社員食堂（外の人も入れる）の廊下でUSBメモリを拾ったら、どうするよ? USBメモリなんてありふれているし、最近じゃオサレな奴やカワイイ系まで出回っているぐらいだ。誰かが落としたんだろうな… で、何が入っているのだろうか? で、自分のPCに挿してみる…が、すぐに覗けない。それぐらい知ってるって、し

ウォーターフォール・モデルとは一言で説明するなら、「プロジェクトの構造化」だ。逐次実行や先手管理、進捗の予実管理なんざ、特徴的だが本質ではない。それらはキチンと構造化された後に実現できる。プロジェクトの構造化をしないまま先手管理しようとするからおかしくなる。 プロジェクトの構造化はこうやる ウォーターフォールは逐次的な開発技法であり、ウォーターフォール全体として「分析>設計>製造>試験」とはならない。顧客受けしやすいようそんな絵を書くこともあるが、実質は異なる。 「すべきこと」単位に分解して、「すべきこと」同士の順序性を決めた後、「すべきこと」同士では逐次的な関係を守らせるようにすることが本当。 「すべきこと」の分け方は「分析」「設計」「製造」「試験」ではない。これらは分断するものではない。「なんちゃってウォーターフォール」をダメにしているのは、工程（＝フェーズ）ごとにチームを割り、それぞ

IT Pro の開発ドキュメントの最適化で笑わせていただいた。これ書いた人は画面仕様で酷い目に遭ったことがないんだろう。笑った箇所は次の通り。 画面仕様書をプロトタイプ・アプリケーションで代用する方法がある。Webシステムの場合は，HTMLの作り方を工夫すればプロトタイプで実際の入力手順や画面遷移も確認できるようになる。エンドユーザーにとっても，ドキュメントよりは実際の画面で確認した方が分かりやすいので，手戻りが減る。これは帳票にも同じことが言える。 あのな、HTMLで作る画面なんざ、紙芝居だよ。「ふいんき」をかもし出すだけで、そいつは「仕様」じゃねぇ！ボタン配置や文字色を目の前で変えられるものだから、いつまでたっても顧客は「ちょっとコレ直して」と言ってくるんだよ。気軽に直せるものとお金を頂戴しないと直せないものがあることをギッチリと顧客に理解していただくために、画面仕様書はどうしても必要

この記事のまとめ。また長文エントリごめん。“IT”コンサルじゃない、「ファーム」のコンサルタントと一緒に仕事をするハメになったら読む本。 「問題解決プロフェッショナル」を読めば、コンサルタントの土俵で話ができる SEとしての分をわきまえるなら「RFP＆提案書作成マニュアル」で準備しておく SEには、コンサルタントに無い視座がある。その強みを生かす「業務システムのための上流工程入門」 コンサルタントは、知識経験ないけれどキャラとハートがおおまかカバーすることはぶっちゃけありえない。そうなったらどうしようと思い悩む前にメモをどうぞ。 このblogは「それを知らなかった私にとって有益なもの」になるように心がけてる。つまり、その記事の知識・情報を知らなかったとして、「あ、こんな記事を見つけてラッキー」と思えるようなネタ。 で、この記事は一年前の私が見つけたなら「お、タイムリー」と思えるような内容　

「ブログでプロジェクトマネジメントする10の方法」への反応を見ていると、独り考え込むのでなくUPしてみるものだな、と思った。実務に適用している例や、Wikiでの試みがあることを知った。言及していただいた皆様、ありがとうございます。賛否ともども大変参考になり、中の人は感謝多謝することしきり。 Wikiを発展させた開発支援コラボレーションツールMrkrgnao（via:marsのメモ） Wikiを使った「Web向けLotus Notes」Jotspot（via:関心空間ラボ） 社内限定の非公開型ブログイントラブログ さらに、「Wiki との優位性が見えない」「ストレージサービスでええやん」というコメントがあったが、そのとおりだと思う。実際、前のプロジェクトでは Wiki+CVSで「設計書+コード管理」してたし。時系列に情報を積み重ねるのがブログなら、Wikiは樹構造的な展開に向いている。各人の

マーケティングツールとしてのブログが流行らしいが、開発現場のマネジメントとしてブログを使えないかという提案。イントラネットに閉じたローカルブログ導入のヒントとして自分メモでもある。 1.ステークホルダーのコミュニケーションツールとして 進捗報告やマイルストーン毎のレポートなど、プロジェクトでやりとりする情報はかなりのものだが、それらを全て一斉同報メールで送るのは大変かも～というのであれば、ブログが有効かと。 日報、週報、月報のような定期レポートだけでなく、随時更新されるリスクマネジメントリストや、毎時参照されるトラブルレポートも対象となる。更新するタイミングでステークホルダーにお知らせメールを送るのも簡単だし、RSSリーダで読むようにすれば、それすらも要らぬ。その際、以下のルール決めをして浸透させておく必要がある。 どのタイミングで 誰の責任において どのような情報が 公開されるのか（公開