今読んでいる本

今読んでいる本・読みたい本をメモしておく。こうやって宣言しておかないと、あっという間に積ん読になってしまうので。

ソフトウェア要求変更プロセス管理の実践法―仕様変更に対処する

ソフトウェア要求変更プロセス管理の実践法―仕様変更に対処する

情報処理学会経由で献本していただいた本。おおよそ、要求工学の概要、要求変更問題の構造、要件変更問題における課題と解決、要求変更のプロセスモデル、要求変更の抑止という考え方、という構成になっている。まだパラ見だが、話が複数の角度で整理されているため、具体的なプロジェクトでの変更要求の理解を得やすい。たとえば生じている問題がプロジェクトの特殊性に起因しているのか、一般的な問題なのかなど。さらに、参考文献が豊富に載っており関連の論文を書こうとする人(俺か)を楽にしてくれる

ビジネス・プロセス・ベンチマーキング―ベスト・プラクティスの導入と実践

ビジネス・プロセス・ベンチマーキング―ベスト・プラクティスの導入と実践

いわゆる「ベストプラクティス適応によってBPRを実施♪」みたいなことをパワポ使って安直に言う人(俺か)が実際のプロジェクトにどのように適用すべきかという手法をケーススタディを含めて解説した本。まだ頭しか読んでないけど、具体的な適応がいかに難しいかという話がずっと書いてあるのでその解決ヒントが書いてあるんでしょう。がんばって読んでみます

デッドライン仕事術 (祥伝社新書)

デッドライン仕事術 (祥伝社新書)

仕事の効率化には仕事の締め切りを明確に切ることが最も早道であるというトリンフ社長の話。あまり残業をしてはいけない人とかいくら残業をしてもお金にならない人(俺か)はいかに仕事を効率化できるか頭を痛めるわけだが、突飛な工夫はなく締め切りを区切るというのが実際的に効率化に寄与するよという話。この本では、仕事の目標に対する妥当なタスク分解が可能であることが前提となっており、そこに問題がある場合はどうしたらいいんだろうとか思うのだが、この本はタイムマネージメント領域のみの話だろうということで大目にみるしかない。
ゴール指向による!!システム要求管理技法

ゴール指向による!!システム要求管理技法

論理学

論理学

TOC思考プロセスを学べと言われたり思ったりしながらはや一年。結局概要しか知らない。が、もうそろそろまじめに学んでおこうと思った。まじめに学ぼうとすると、やはり思考プロセスという解決方法が含まれる領域の理解とほかの解決方法を押さえておきたいし、思考プロセスが使っている手法も押さえておきたい。要するにあるソリューションを勉強するためには、そのソリューションを俯瞰的にまた構造的に押さえておくということが大切なわけですね。ということでこの二冊。どちらもよく読んでいる本ですがこういう観点で読むと面白かったり。実際、MECEだのTOCだの何だのって小難しい話を展開する人で基本的な論理学を正しく利用していない人もいるんじゃないかなあ自分も含めて

ソフトウェアエンジニアリング論文集80's~デマルコ・セレクション

ソフトウェアエンジニアリング論文集80's~デマルコ・セレクション

今、ソフトウェア温故知新という観点でとある話をまとめようと思っているのでまとめるためには過去を知っておかなくてはねえということで読んでいます。

技術の創造と設計

技術の創造と設計

思考の整理学 (ちくま文庫)

思考の整理学 (ちくま文庫)

フェローご推薦&読もうと思って全然読めていない

ユースケース入門―ユーザマニュアルからプログラムを作る (Object Technology Series)

ユースケース入門―ユーザマニュアルからプログラムを作る (Object Technology Series)

  • 作者: ダグローゼンバーグ,ケンドールスコット,Doug Rosenberg,Kendall Scott,長瀬嘉秀,今野睦,テクノロジックアート
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2001/11
  • メディア: 単行本
  • 購入: 1人 クリック: 38回
  • この商品を含むブログ (28件) を見る
実践UML 第3版 オブジェクト指向分析設計と反復型開発入門

実践UML 第3版 オブジェクト指向分析設計と反復型開発入門

  • 作者: クレーグ・ラーマン,依田智夫,今野睦,依田光江
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2007/11/12
  • メディア: 単行本(ソフトカバー)
  • 購入: 8人 クリック: 179回
  • この商品を含むブログ (29件) を見る
最近ユースケースを正しく使うってどういうことで、またユースケースで表現できること・できないこと、ユースケースを用いたプロセスで実施すべきこと・すべきでないこと、とかとかがよくわからなくなってきたので改めて読んでみようかと。 なんかユースケース図として人の絵を書いて楕円書いて「なんちゃらする」って書いて適当に線をくっつけて・・・で、それを詳細化するためにユースケースとしてそれを文章で表せばいいと思いがちなのだが、結局この作業は何のためにしていて、だから何を書くべき気なのかなって。